Log in

View Full Version : vdub fast recompress not so fast!


nalooti
10th August 2006, 08:16
Hi,

i've been using vdub in full processing mode without any filtering until i knew i could do it much faster in fast recompress since i don't use any filter.
But the time was not any lesser than in full processing mode, compressing a 250MB Mjpeg file to Divx6 and at the same time compressing the PCM audio to Lame Mp3 192 Kbps (after converting it to 44.1Khz, 16bit, mono).

In both cases, it took 6min with my P4, 3Ghz PC (CPU above 90%).

Could it be because i compress the audio at the same time?

Anyway i see no reason to compress the audio later because:
- adding both compression times may give the same resulting time
- additional manipulations for splitting the audio and video, then compressing and joining them together again takes also time
-in theory, time sharing and multi threading (even with one CPU) should be done by the processor and should do it faster than doing each task sequentially.

Any reason i forgot to still prefer processing audio and video separately in my case ?

thanks
nalooti

LoRd_MuldeR
11th August 2006, 11:35
"fast recompress" means the decoder will be directly connected to the encoder, without any filters and (if possible) without any color-space conversion. This can be faster, but it not necessarily is...

Awatef
11th August 2006, 15:06
Yeah, your original file is probably in RGB or something, so a color conversion to YV12 happened anyway, that's why you didn't notice a speed difference.
It's different from DVD source, where the video is already in YV12. If you encode such a source with Full Processing Mode, you would enforce a YV12-RGB-YV12 conversion that would just waste time if you're not using any filters.

nalooti
13th August 2006, 09:44
thanks very much Awatef,

you're probably right as you know what am i talking about: my videos come from my digicam producing mjpeg files. I'm not doing a dvd rip.

how could i check that my colorspace is in RGB?

are all divx compressed files converted to YV12 ? why ?

thanks

Yeah, your original file is probably in RGB or something, so a color conversion to YV12 happened anyway, that's why you didn't notice a speed difference.
It's different from DVD source, where the video is already in YV12. If you encode such a source with Full Processing Mode, you would enforce a YV12-RGB-YV12 conversion that would just waste time if you're not using any filters.

LoRd_MuldeR
13th August 2006, 12:21
RGB and YUV are different color models: RGB divides the information into the fundamental colors (Red, Green and Blue) while YUV divides the information into Luma (Brightness) and Chroma (Color). MPEG and all similar methods of video compression use the YUV model, because compression can be done more efficient. That's because the human eye can see Brightness-Information more detailed than Color-Information. This fact is very usefull for video compression.

Blue_MiSfit
15th August 2006, 00:07
Roger that. Some commercial MPEG encoders like CCE etc... accept YUY2 for input, presumably to do their own internal stuff since YUY2 has more info that YV12.

It all ends up as YV12 though :)

~MiSfit

Awatef
18th August 2006, 16:36
Yup, it all ends up in YV12, and DivX is no exception, because YV12 is the most economical color space.

YV12 is 4:2:0. MJPEG uses one of three: 1:1:1, 4:2:2 or 4:1:1 (at least these are the options allowed in the Pegasus Codec). So a color space conversion is going to happen anyway if you compress an MJPEG source to DivX ;)