[MEncoder-users] new doom9 codec comparission

[Corey Hickey]

I never got around to responding to this. I've been too busy testing in
my spare time. :)

Rich Felker wrote:
>>>And why such small vratetol?
>>
>>It's favorable for a codec to meet the requested bitrate precisely, and I've
>>been using vratetol=1000 on my own testing for a while without noticing
>>anything wrong. If you have, then please tell me and I'll relax it. For that
>>matter, tell me if you even have misgivings. The default of 8000 would be
>>ok, but if there are no ill effects to using 1000 then I figure we might as
>>well.
> 
> 
> IMO don't mess with ratetol unless the file size is very bad without
> changing it.

Ok.

>>>>* I need to test vqcomp=0.7 or vqcomp=0.6
>>>
>>>Rich said something about keeping it at the default level of 0.5 on IRC
>>>the other day.
>>
>>I've never tested this parameter, but at this point I think vqcomp=0.7
>>assists encoding this material. Go to this page:
>>
>>http://www.doom9.org/index.html?/codecs-203-2.htm
>>
>>...and take a look at how many of the screenshot frames are in the midst of
>>lots of motion. In particular, look at the last shot with all the blue-green
>>lightning, and look at how well the different codecs have preserved the
>>texture of the concrete while the lightning jumps to a different place every
>>frame. My own encodes aren't much of an improvement over the "ffvfw"
>>screenshot.
> 
> I recommend low value of qcomp because: when encoding I often notice
> that in the first pass, all the low motion scenes look beautiful,
> while the high motion ones look anywhere from slightly bad to very
> bad. During the second pass, if qcomp is very high, all the bits from
> the low motion scenes get wasted on trying to make the high motion
> scenes look good, and:
> - low motion scenes look like blocky shit
> - high motion scenes barely look better in all but a few extreme cases

>From what I saw with vqcomp=0.7, the low-motion parts looked very
slightly worse (and not really bad), while the high-motion parts looked
slightly better (and not really good).

> So personally I prefer qcomp=0.5 or even 0.4. Of course if you're
> using very high bitrates and insist that still frames look good even
> during high motion, you may want qcomp=0.6 or 0.7.

I agree with you as a matter of personal preference. I've never messed
with vqcomp before because I've always been satisfied with the default
ratecontrol. I'm still under the impression, however, that performing at
least reasonably well in scenes with very high motion is imperative for
this comparison.

In any case, as a compromise, I've backed down to vqcomp=0.6 on all my
tests and investigated other options. vqcomp=0.7 only affected the video
very subtly; adding b-frames, for instance, did far more good to the
high-motion scenes.

>>>Oh, one more thing: what about B-frames?
>>
>>vmax_b_frames=2 helps PSNR significantly, but mencoder still doesn't
>>properly maintain a-v sync when b frames are present. I'd like to use them,
>>but it doesn't seem right to recommend an option that, although it helps the
>>video itself, doesn't work properly with mencoder.
> 
> Sure, it's fine. No one will use mencoder for serious a/v sync anyway.
> Instead they'll disable a/v sync entirely, encode audio & video
> separately, and then remux. :)

Ok, then.

-Corey