Which is faster: AVISynth, or TMPGEnc...

[kschang]

When it comes to effects like filtering, cutting and joining, resizing, and such?

Let me explain my full setup and why... I have a bunch of 82 meg RMVB's, which I'm feeding to TMPGEnc via AVISynth as a DirectShowSource. I already got the procedure down pat, but I really want to minimize the time spent, as I have a slow PC, and even over night it's taking about, oh, 2:45:00 to convert ONE RMVB file, even after I decided I don't want the intro and outtro.

Then I realized source material is 640x480 @ 30 fps. I'm converting to VCD, which is 354x240. Previously, I was letting TMPGEnc to do the resizing, nothing wrong with that. So last night I decided to add the resize line "Lanczos4Resize(352,240)" into the AVISynth script and in TMPGEnc leave the input as 1:1.

The result... was invalidated when I forgot to set TMPGEnc to High-Priority even when NOT in foreground, but I think I got like 2:10:00, which is a noticeable improvement. The result is virtually identical.

So, is AVISynth actually faster in resizing? Would I save even MORE time if I did the regular LanczosResize instead of Lanczos4Resize? And is there something else that can help speed up the encoding process?

[kschang]

Well, llooks like I'm going to answer my own question.

Last night, I setup a test with LanczosResize instead of Lanczos4Resize, and ran another 3 RMVB conversion. This time, the conversion took 1:40:00 to 1:48:00. That's almost 1 hour saved from previous efforts. And since the resolution is low enough I don't think I'll notice any artifacts or such from the resizing.

I think we can conclude that AVISynth is pretty darn fast for anything that it does, and it's better to let it do most of the filtering/processing.

[celtic_druid]

Been saying that for years. I doubt TMPGEnc uses lanczos either, so as well as faster encoding, you should get better quality.

TMPGEnc converts to RGB24, so you are resizing RGB24 instead of YV12. Could be other reasons, like AVISynth has better resize code. But RGB24 basically means twice as much info to resize.

[manono]

Hi-

Lanczos4Resize is better for upsizing than downsizing, so switching to LanczosResize was a good choice, and not only for the speed gains.

Also, since you seem to be satisfied with TMPGEnc's resize (which uses Bilinear resizing), you could also gain more speed by using Bilinear resizing. Don't know if I'd recommend that, but your output resolution is so low that I don't guess it makes much difference.

You've proven to yourself (although it's been well known in AviSynth circles for a long time) that the best speed gains will result from doing all the filtering in the original colorspace. Don't use TMPGEnc for anything but encoding. This also means that doing a ConvertToRGB24() in the last line of the AviSynth script file should also speed things up a bit, as well as probably improve the quality.

[kschang]

Which kinda brings up an ancillary question...

I was playing with QuEnc a bit since I want to make SVCDs (and I did not register TMPGEnc so the MPEG2 is expired) and I keep getting a note that QuEnc wants YV12 (though the source is in XVID, which shoudl already be in YV12 colorspace!?) it is DirectShowSourced to QuEnc. A 195 meg XVID file turned into a 500+ meg MPEG2 file (of which, the audio cannot be played by VLC, strangely!) I tried to cut down on the bit rate a bit and such, but haven't had much luck cutting down on encoding time, esp. when I have to convert the aspect ratio. FitCD kinda helped, but it ended up chopping off the bottom with its trimming.

[Soopafresh]

If you're using DirectShowSource, I'm guessing the output isn't coming out as YV12. Just add


ConverttoYV12()


at the end of your script.


If the file is XVID, you ought to be able to do AVISource .

Also, consider trying out HC v0.16. Quenc is great, but it isn't upgraded very often. HC is actively developed.