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
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