View Full Version : Disabling slow filters in first pass to speed up encode
jmartinr
10th April 2008, 20:35
After some experimenting I found a reasonably simple method to speed up encoding.
I encode through batch files in windows (using x264 and the slow profile from MeGui). Setting an environment variable during first pass and using GetSystemEnv in the avisynth script enables me to disable the slow fft3dgpu filter during the first pass. Frame rate in first pass (turbo mode) went up from 12 to more than 50. Second pass is done the normal way.
Results seem to be as good as before using this method.
Any comments on this trick?
unskinnyboy
10th April 2008, 21:03
A multi-pass encoder relies on the stats collected in the (n-1)th pass to do the nth pass. If you are disabling a filter in the (n-1)th pass, but reenabling it in the nth pass, the information collected during the (n-1)th is not truly valid for the nth pass anymore, and hence this process is not recommended.
I'm quite surprised that your results seem fine. Did it also hit the right file size (assuming you were trying to hit a target file size)?
mikeytown2
11th April 2008, 03:18
You can do the opposite, if you have a lot of hard drive space. 2 pass encode, first pass outputs lossless file, second pass uses lossless file. Details Here
http://forum.doom9.org/showthread.php?p=1073371#post1073371
Used successfully with HCenc, because HCenc has a *AVSRELOAD option.
jmartinr
11th April 2008, 07:28
@unskinnyboy
Yes, bitrate was good.
@mikeytown2
Tried that. Gives you quiet a big intermediate file. But more important, gives a slow first pass and a slow second pass.
The gain comes from using fft3dgpu. In a first pass fft3dgpu will be the bottleneck, making it slow. In a second pass the gpu can keep up with the rest so there's no real speed cost from using this filter in second pass.
Difference for me is aproximately 200%(1st pass)/300%(2nd pass) encoding time doing it the normal way, using intermediate file only makes a small difference, 50%/300% using my trick.
squid_80
11th April 2008, 07:50
I don't think you understand, the video data fed to the encoder should be *exactly* the same for both passes. Like unskinnyboy said, if this isn't the case then the stats created during the first pass aren't valid.
Note that if the filter wasn't actually having any effect you wouldn't notice a difference. Maybe you should try dropping fft3dgpu for both passes.
foxyshadis
11th April 2008, 08:35
Bah, first pass can be a lousy, mediocre hack encode compared to the final pass. All this exactly business is bunk; replacing with a much faster denoiser like removegrain, degrainmedian, fluxsmooth, or even x264's --nr option will make nearly zero useful difference in the stats file, and it's so coarse that even removing denoising completely can have minimal effect. Motion search is too simple to catch the difference most of the time.
If you really cared about perfection, you'd run a full first pass and not a fast one, but stats don't really have to be perfect to be good enough.
jmartinr
11th April 2008, 09:44
@ foxyshadis
Thanks for your reply. I think I'll put a removegrain in the first pass and stick with the rest.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.