Frameserving to TMPEGEnc in 2 pass mode?

[W_Eagle]

Is it possible to frameserve from VirtualDub to TMPEGEnc in 2 pass VBR mode? If yes, how does it work? Is it being frameserved twice, once for each pass?

[FOO]

Yes, how else would it work ?
If you set a large cache in TMPGenc it may avoid
reading from the frameserver twice.

[bugster]

Yes, it does get frameserved twice.

The way I understand it all works (and I could be wrong) is like this,

You have a client process (TmpGenc) and a server process (virtualdub). The client asks the server to provide each frame, one at a time. With 2-pass, when it reaches the end of the 1st pass, it simply request frame zero a second time, and then continues.

The client process is in control, the server process simply provides the info requested, without any restrictions.

Hope this helps.

[W_Eagle]

Thank you, it definitely helps.

[FOO]

Here's a clue
There are (were) some broken frameservers at one time.
TMPGenc would crash right at 50% on a 2 pass.
The reverse seek was broken on the server.


This also means that there is a lot of time wasted. What if you set a few
filters in Vdub and frameserve to TMPGenc 2 pass. The filters
have to get executed twice .

[SatStorm]

Unfortunatelly, this is a problem with 2 Pass and frameserving....

What is the practical solution IMHO (not as good, but much faster...)

1. See how much you want to burn on a Disc and with which resolution. Example, you want 4 hours per DVD with 1/2 D1.
2. Capture EXACTLY those 4 hours (not a minute more...)
3. Add filters, resize and frameserve to TMPG. On TMPGenc, set CBR @ 9800 KB/s and audio 192kb/s (48000). This gonna end up as a huge file
4. Load this huge file to your authoring application (let's say, TMPGenc author). Author it as normal. Output, even if you know that the vobs gonna be a huge file.
5. Use programs like DVD Shrink or DVD2One on those huge outputed files, to make them okey for a 4.7GB dvd.

You have about the same results (90 - 95%) as with 2 Pass VBR in half time that way.

Of course, you need to be realistic using this method. IMHO, with 1/2D1, this is a good alternative to burn 4 Hours of VHS on 1 DVD-R with minimum (if not at all) artifacts.

[W_Eagle]

@ SatStorm

Thanks for your advice. Though, something doesn't make sense to me: getting the right file size with TMPGEnc in 2 pass VBR -- it will reduce bitrate at no motion, or slow motion scenes and increase bitrate on high motion scenes -- thus it will maintain the best quality possible for any given file size. DVDShrink, on the other hand, will reduce bitrate equally all over. Is that right? If yes, how can DVDShrink possibly compete in quality against TMPGEnc?

[SatStorm]

It is not the same at quality, but it is fair close. Try it and see for yourself if it does the trick to you.

Now how this works? Well, it is like normalise the audio in a way. Just for the info, those programs are using technics based on the DVB transmissions. And if you ever see dvb transmissions, the results are or a 704 x 576 @ 4500 which looks good (not excellent), or a 352 x 576 @ 3500 which looks excellent. Between formats (like 528/544 x 576), 3500 looks like 704 x 576 @ 4500. Good but not excellent...

The other fast way I know, and personally use more often, is to save my captured avis to another avis after the filters. That way, when I frameserve this new filtered avis, it is faster, plus Virtualdub at the proccess has fixed all the errors. But this proccess needs huge HDs...

A third way, is to encode to CQ and then shrink again, if the filesize turn huge. But this is like the first method I already said and with less quality on most cases.

[W_Eagle]

The other fast way I know, and personally use more often, is to save my captured avis to another avis after the filters. That way, when I frameserve this new filtered avis, it is faster, plus Virtualdub at the proccess has fixed all the errors. But this proccess needs huge HDs...

I have no problem with disk size. Only, saving a new filtered avi, why should one frameserve that avi into TMPGEnc?

[SatStorm]

Have you ever tried to feed direct to TMPGenc, files >2 GB?
I don't know for you, but I had always issues doing this.
Frameserving with Virtualdub using fast decompress (not direct copy), is as fast as the built in vfapi of TMPGenc IHMO. And much more stable!

You know, we are doing some things on this hobby, just for that one ******* time, which something strange and "unexplain" pop up and drive us crazy. I prefer doing one - two extra steps, with minnor time pay and be 100% sure that I have the results I worked for, than skip it and that one ******* time cost me in a personal level a lot.
It is like health. You don't expect to get sick to solve problems which might leed you to sickness....

[W_Eagle]

Have you ever tried to feed direct to TMPGenc, files >2 GB?

Dear friend, I do it all the time. For the past 2 years or so I'm feeding TMPGenc with files of about 10GB without any problem. So, please, let me sharpen my question: when having no problem feeding large files into TMPGenc, is there any reason to frameserve?

[bugster]

Have you ever tried to feed direct to TMPGenc, files >2 GB?

Dear friend, I do it all the time. For the past 2 years or so I'm feeding TMPGenc with files of about 10GB without any problem. So, please, let me sharpen my question: when having no problem feeding large files into TMPGenc, is there any reason to frameserve?

I have no problems with large files either.
Only reason to frameserve then would be if you wanted to apply virtualdub/avisynth filters.

If you want/need no external filters, don't bother with frameserving.

@SatStorm, why frameserve with fast recompress rather than direct stream copy?

[SatStorm]

Fast decompress is faster. This is an info I read first in a guide in this site, still it is somewhere in the guide database.

To tell the truth, the last time I feed avi's direct to TMPGenc was 2 years ago. I had issues back then, basicly because of corrupt files (source). Some times it was simply a HD defragment problem, some times a bad source (frame drops for example, while capturing...), sometimes something I didn't have the time to search. Since then, I frameserve just to be sure that my job is done. And it is not take more time than feed direct to tmpegenc (if you use fast decompress)

Now, if you do the job well, and you are happy with the results, keep doing it your way. Just keep in mind, the day a problem pop up, try to frameserve the same source to TMPGenc. I bet it gonna work that way!

[SatStorm]

Oops! Sorry, my mistake!