The virtualdub pipeline

[davexnet]

Hello - I'm encoding a short xvid file to xvid I'm not using any filters.
When I set the video mode to "fast compress" it took 4 minutes 24 seconds.
I tried it again in the video "full processing" mode and was surprised to see it only took
3 minutes 52 seconds.

I read the Virtualdub help where it describes the pipeline - it seems that it does more stuff in the "full" mode.
I don't understand why the time is less.

[jagabo]

Fast Recompress is usually faster than Full Processing Mode. Did you use the exact same Xvid settings for both? Did you use the same source video in both? (Different videos can take different amounts of time to compress, even if they have the same frame size, running time, and frame rate.)

Some other, less likely, possibilities: If you performed the two conversions one right after the other the source video may have been fully cached in memory during the second encoding, speeding it up. If the source and output videos are both on the same drive processing will be slower than if they are on different drives. Did you change the audio processing?

[davexnet]

Yes, I left everything as-is. Just changed the video processing mode.
In case there is a cache involved, as you mention, I'll try it again and reboot the PC.

I'll put my findings in the post when I get the results.

[jagabo]

You're right. Something is borked with VirtualDub's Fast Recompress mode now. I ran some test with VirtualDubMod (based on VirtualDub 1.5.10) and Fast Recompress mode is faster than Full Processing Mode -- as expected. But with VirtualDub 1.9.5 it's the other way around. Compressing a 5 minute video (several runs were done with the source on one drive, the output on another) from Xvid to Xvid:

VirtualDubMod 1.5.10:
Fast Recompress: 64 seconds
Full Processing: 76 seconds

VirtualDub 1.9.5:
Fast Recompress: 69 seconds
Full Processing: 63 seconds

After some experimenting I found a workaround: Leave VirtualDub in Full Processing mode. Then go to Video -> Color Depth. Set the Decompression Format to 4:2:0 Planar YCbCr (YV12). Set the Output Format to the same. As long as you don't add any filters this will avoid the YUV to RGB conversion you normally get with Full Processing mode. You will not lose black-than-black or whiter-than-white And processing will be faster. The 63 second encoding above dropped to 59 seconds.

[davexnet]

I ran it again and got similar results. I opened up the Windows Task Manager
and noticed that "fast recompress" used 65-70% of the cpu, while
"full processing" used 80-85%.

Perhaps full processing mode utilizes the dual core more efficiently ?

I found this in Vdubs help -
"In previous versions of VirtualDub, enabling full processing mode would always force a conversion to 32-bit RGB. This is no longer the case — if no video filters are used, this conversion step is omitted and the video is directly converted to the output format as in Slow Recompress mode."

So I did a slow recompress (called normal recompress in the menu) encode and it was the slowest of all three.
On my box, encoding the 10,000 frames, I got these times:
full 143 seconds
fast 150 seconds
normal (slow) 167 seconds

[jagabo]

Note I added a workaround in my previous post (force YV12 colorspace).

Xvid works internally in YV12. So asking it to decompress to YV12 is fastest, and feeding it YV12 for compression is fastest. With VirtualDub in Full processing mode and the decompression colorspace set to AutoSelect it looks like VirtualDub is asking Xvid for YUY2. (At least, the conversion time is the same as when you force the decompression to YUY2.) So Xvid has to do extra work to convert YV12 to YUY2 on decompression, then extra work to convert YUY2 back to YV12 for compression. By forcing the input and output colorspaces to YV12 Xvid avoids those two conversions.

I noticed the same CPU usage issue too. And I think you're right, something is wrong with VirtualDub's multithreading in Fast Recompress mode.

[poisondeathray]

Maybe you should report your findings in the vdub forum?

[davexnet]

Jagabo, a nice workaround, that may not have occurred to me at all.
(my understanding of the color spaces is lacking - I guess I need to do some reading)

I gained 9 seconds on my 10,000 frames FP mode forcing yv12.

Thanks for this analysis.