[MPlayer-dev-eng] Re: [MPlayer-DOCS] [PATCH] "quicky" mode (was: complete documentation)
lorenm at u.washington.edu
Tue Sep 14 12:01:57 CEST 2004
On Tue, 14 Sep 2004, Guillaume POIRIER wrote:
> Le sam 11/09/2004 à 23:19, Guillaume POIRIER a écrit :
>> I understand you point, though I still think a "turbo" wouldn't harm
>> lavc; in fact, it's more likely to improve lavc usability.
> Nobody responded, so since nobody told me that I should forget about it,
> and that I'm quite a stubborn, here's a patch that implements a "quicky"
> mode (which is triggered by the ":quicky" flag on the list of options,
> that disables some CPU-hungry options to speed-up total two-pass
> encoding automagically.
> Please not the name of this options is temporary, so should that patch
> get merged (not now, I'm sure it still needs some work) I can come up
> with a better name ;-)
> It's definitely more a prof of concept than a revolutionary idea! ;-)
> I haven't tested it intensively, but so far it works fine with me. The
> impact on PSNR would be worth studding I guess.
> I had a rip that was running at 2fps on first pass, and now is running
> at 35fps.
> Any feedbacks welcome
1) You might want to enable quicky only if vpass==1 (so that you don't
have to remove it when you run the second pass.)
2) I would also disable dia, predia, qprd, and mv0.
On a speed vs quality tradeoff for a normal (fast) encode, I would
replace mbd with mbcmp=2 before disabling trellis or subcmp, but I
haven't tested how much that affects the 2nd pass.
3) I have done something similar (just using different options on each
pass), but I ran 3 passes: first with almost nothing enabled (30 fps),
then with most options enabled (6 fps), then with everything (2.5 fps).
(This required setting both vpass=1 and vpass=2 for the middle pass.)
The result is about .10 psnr higher than just running 2 passes on slowest,
and is essentially identical to a full 3 passes on slowest.
More information about the MPlayer-dev-eng