Log in

View Full Version : encode speed


jerets
25th November 2003, 22:59
im trying to figure out why its taking so long to encode and what i might be able to do to speed the encode process up.

Im working with 40min 704x480 tv cap -> 480x480 svcd with the following filters:
DGBob,undot,temproalsoften,crop,lanczoresize

I noticed the filters page attached to the top (undot and temproalsoften don't add much time to your encode).
I'm doing 5-passes and its taken near 20hours! Its encoding at speed .21
Any ideas or suggestions?
Thanks so much,
Jerets

Manao
25th November 2003, 23:06
Without knowing what is your computer nor the software used for compression ( I guess CCE ), nor the original file type and way of loading it ( AVI / AVISource, AVI / DirectShowSource, MPEG / MPEG2Source), it'll be hard to know if there is something wrong. So post your script and machine type.

However, since you think most of the time is taken by prefiltering, you might encode first to HUFFYUV ( or whatever lossless codec you want ), and then encode the HUFFYUV file directly without filtering. You'll save some time in the 4 latest passes.

jerets
25th November 2003, 23:42
System: 1.4ghz AMD, 1gig PC133
Capture: Huffyvu codec, 704x480
AVS:
DGBob(order=1,mode=0,thresh=12)
Undot()
Temporalsoften(2,3,3,mode=2,scenechange=6)
Crop(2,8,-2,-4)
LanczosResize(480,480)
----------------------
Encode: CCE 5-pass, 2450 bitrate
Time = approx. 20 hours

If I don't use the filters above, my encode won't be progressive and the picture won't be as clear. Filter speed results thread (http://forum.doom9.org/showthread.php?s=&threadid=51181) shows that Undot adds only 1% to encode time and Temporalsoften, 4%.

Thanks for the timely response,
Jerets
=)

Manao
26th November 2003, 00:07
I may not have been understood :

With your avs, encode to Huffyuv. Then encode the Huffyuv file with CCE. So you'll do the filtering only one time.

Now, for the speed issue, with DGBob, you double the number of frames, so you double the time taken to encode, that may explain why you think it's too slow.

jerets
26th November 2003, 00:15
ahh. I follow ya now. Will give that a try.

As for DGBob, what deinterlace filter do you personally recommend. I've been experimenting and researching this for a while now.
I gave TomsMoComp a try and that encoded super fast.. but doesn't it also sacrifice quality by eliminating half the fields?

Thanks so much =)),
Jerets

alucard83
26th November 2003, 01:28
Area deinterlace works well for me

jerets
26th November 2003, 02:38
i believe thats for virtualdub, isn't it? i'd like to try and find a filter for avisynth. I'm hoping to find something that will keep detail, not ghost, keep frame rate and work well with high motion. =/ Any1 know of anything close to that?
Thanks for your help guys,
Jerets =)

Edit: I spent sometime playing with area deinterlace in vdub. i like how it deinterlaces only the necessary areas and does a nice job interpolating the rest. Any1 know of a avisynth filter that is similar to this? Thanks again

manono
26th November 2003, 04:25
KernelDeInt (http://neuron2.net/kerneldeint/kerneldeint.html)

jerets
26th November 2003, 04:30
thanks a ton. ya that does the trick.
just curious, i had an encode going from DGBob (doubles fps).. but when i went to mux the video with the audio (it was reporting only 29fps? This has me all confused. lol
Thanks again guys.
I appreciate all the great responses :)
Jerets

trbarry
27th November 2003, 17:22
I gave TomsMoComp a try and that encoded super fast.. but doesn't it also sacrifice quality by eliminating half the fields?

Not necessarily. TomsMoComp eliminates half the fields only when the search effort parm is 0, say TomsMoComp(1,0,1). Then it does no motion comp and just tries to be sort of a smart bob with some jaggie reduction.

But try TomsMoComp(1,5,1). It will be a tiny bit slower (still fast) but will do enough motion comp to add info from the prev and next fields as long as they haven't moved by more than a pixel or so.

- Tom

PS - But don't just look at the first frame in the clip for comparison. That is always bobbed since there is no prev field to process. ;)