[MEncoder-users] new doom9 codec comparission

[Corey Hickey]

>> for i in $1 $2 ; do
>>   mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \
>>   -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \
>
> Loren has recommended lanczos swscaler for scaling (-sws 9). Isn't it what
> Doom9.org said should be used anyway?

I have been... see below.

>>   vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\
>                                                       ^
> What is this lonely '1' doing here? ------------------|

Yeah, apparantly I mangled the command somehow when I constructed it for the
email. I'll try again, and be careful not to do that for the final, which I
will of course send here for proofreading. :) This command is a bit updated
based on recent testing.

for i in 1:turbo 2 ; do
  mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \
 -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \
 -lavcopts vcodec=mpeg4:vbitrate=581:vratetol=1000:vpass=$i:\
mbd=2:mv0:trell:cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:\
preme=2:v4mv:last_pred=2:vqcomp=0.7:threads=2 \
  -ofps 24000/1001
done

> 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.

>>   cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv:\
>
> Why vme=5? According to the manpage it's "aliased to 4", which is the
> default.

...because I forgot about it. The message in the manpage wasn't there before
and, when I tested it a long time ago, I thought it gave better performance
at no loss of PSNR. Now I know that was just experimental error. Also, vme=5
managed to get into DOCS/xml/en/encoding-guide.xml, probably based on my
mistaken recommendation.

>>   vpass=$i -ofps 24000/1001
>> done
>> --
>> * qns=2, unfortunately, is prohibitively slow
>> * I'm hoping to add turbo for pass 1 with little negative effect
>> * 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.

For a movie with lots of action and a reviewer who is rating the codecs
based largely on how well they retain detail during that action, I think it
will be beneficial if we can find a way to make the ratecontrol be more
willing to spend more data on those parts. The sequences with less motion
already look great. vqcomp=0.7 is a slight improvement, and I'd like to go
further and see if that helps.

I won't be back at my main computer until late tonight or perhaps tomorrow,
but I'll try increasing vqcomp and see what happens. Is there a better way
to do it? I was wondering about vqblur, but I haven't tried it yet.

>> * I need to test last_pred=2
>> * I need to test NSSE (*cmp=10)
>
> If there's any noise in the source, maybe add nr=400?

Some noise. I'll try it, thanks.

> 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.

-Corey