Tmpgenc - Save multipass VBR analyze results in the cache-What does it do ?

[davexnet]

Hello,
this option seems to be off by default and 2-pass encoding still works.
So what happens when you turn it on? I've never found a decent explanation of this -
I was wondering if anybody here knew.

[redwudz]

I haven't used TMPGEnc for a while, but it probably permanently saves the 'stats' file from the first pass of a two pass encode. The first past checks the video and sets the variable bitrate for the different parts of the video. The file is probably dumped normally when the program is closed.

Just guessing, though.

[davexnet]

I think you are right it does save the stats file - but what for?

Is there something you can do again later, that will reuse that stat file? What?

[jagabo]

It does much more than just save the stats file. It saves all motion vector analysis so it doesn't have to do it again during the second pass. It makes the second pass much faster. The temp files are deleted when the rendering is complete.

[davexnet]

Thanks redwudz/jagabo
It's only to speed up the 2nd pass? Based on what I've seen, it fits.
Explains why 2-pass vbr still works without it.
Appreciate it,
Dave

EDIT - I may have spoken too soon.
I encoded a short clip with and without this cache, and the run times were identical,
down to the second. The mystery continues.

[jagabo]

On my system the second pass is more than 6 times faster with the cache enabled (depending on the motion search precision setting). On a small sample video the first pass (analyzing) took 128 seconds with cache disabled or enabled. The second pass took 129 seconds with the cache disabled, 20 seconds with the cache enabled. There's no mystery at all for me. I have the cache set to 8000 MB.

[davexnet]

On my system the second pass is more than 6 times faster with the cache enabled (depending on the motion search precision setting). There's no mystery at all.

Well I'm running version 3.x - I found an old trial on a backup disk, decided to give it a go.
The PC is modest, AMD X2 4200 @ 2.2 GHz.

I selected a 3 minute clip using the cut/edit tool. All the settings are at default.
It took 5 minutes 6 seconds (3 minutes first pass) with the cache enabled, and
5 minutes 22 seconds with the cache disabled. So there's some difference,
but nowhere near what you are seeing.

[jagabo]

How much faster it will be depends on the motion search precision setting you are using. The more motion search the program does the more time the encoding takes, and the more time you will save by using the cache. For the above test I was using TMPGEnc Plus 2.5. I was using the highest quality (slowest encoding) motion search precision setting. Total encoding times in seconds:

MSP setting: no cache, cache:
lowest quality (very fast): 38, 38
normal: 41, 39
high quality (slow): 99, 68
highest quality (slowest): 257, 148

Note that there will also be differences depending on the actual video content. When there's no motion and no noise the encoder can decide very quickly that it doesn't need to do any searching. If the video is noisy or has lots of motion it will spend a lot of time looking for motion vctors. I was using some handheld camcorder footage with a lot of motion and a bit of noise.

By the way, just as a comparison, HcEnc took only 30 seconds to encode the same video at its "Best" setting with results comparable to TMPGEnc's highest quality setting.

[davexnet]

Thanks jagabo,
That's great info. My setting was at standard, I hadn't tried the HQ settings.

Interesting that you mentioned HCEnc. One of the reasons I installed Tmpg 3.x was to do
a comparison to it. I had run an encode in AvsToDvd - which uses HCenc. The source was average
at best,and I wanted to see if I could get a better result using Tmpg 3.x.

I took the AviSynth script created in AvsToDvd and opened it in Tmog 3. One thing about
this product, the vfapiserver/directshow multimedia file reader is enabled by default and it's used when the
avisynth script is opened. But watching it run in task manager, tmpg itself is using 65% cpu, while vfapiserver.exe
is using 35%.

I stopped it and disabled vfapiserver. Now, the cpu consumed was 98% in Tmpg 3.x and encode times at least
30% quicker. According to the program source info, the "avi file reader" is being used now.

It doesn't seem to be any quicker than 2,5, but perhaps I haven't played around with it enough yet.