[LONG] new results & bugs report (was: Re: [MPlayer-dev-eng] lavcopts PSNR comparison) [ENGLISH]

[D Richard Felker III]

On Sun, Jun 13, 2004 at 09:18:38PM +0200, Romain Dolbeau wrote:
> Jan Knutar wrote:
> 
> >I've had interesting results wrt PSNR with the *dia functions. I used a 
> >range from -3 to 2, when testing with a similar script, iirc.
> 
> D Richard Felker III wrote:
> 
>  > Yes. qprd is definitely useful. mv0 and cbp might also be good. Also
>  > different choices for *cmp... Can't think of other important ones..
> 
> I've tried again, with some more options, on the same scene.
> 
> Common options: 
> "vcodec=mpeg4:vqmin=2:vqmax=31:keyint=125:vbitrate=650:psnr:"
> video filters: "-vf crop=720:432:0:72,scale=544:230"
> (audio was -ovc copy, and output file /dev/null ;-)
> 
> The other options were:
> 
> vme: 1, 4 (I hadn't noticed that the man page says "0 to 3 is low quality" 
> :-( )
> {pre,,sub}cmp: 0, 1, 2, 3, 6
> {pre,}dia: 1, 2, -1, -2, -3
> vmax_b_frames: 0, 1
> mbd: 1, 2
> qpel or nothing
> mv0 or nothing
> qprd or nothing
> v4mv or nothing
> trell, trell:cbp or nothing
> 
> That was 9600 combinations. The bad news is that only 5634 of
> those outputed a PSNR value. As soon as the jobs started, some
> crashed with a segmentation fault, so i guess it was useful
> at least as a stress test... For the record, that binary
> was configured & compiled on a bunch of dual 2.8 Ghz Xeon,
> running an unknown rpm-based distro (I'm not the admin),
> with kernel "2.6.5-1.358smp" and compiled with
> "gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)" (I guess
> it's a Redhat, then ;-). The running machines were the same.
> 
> One picked at random: the combination
> "vme=1/cmp=0/precmp=0/subcmp=0/dia=1/predia=1/vmax_b_frames=0/mbd=1/qprd/v4mv"
> died on the first frame. Is there something dumb with that combination ?
> Or is it a straight bug ?
> 
> Of the finished result, the best of the best was:
> vme=4/cmp=3/precmp=3/subcmp=3/dia=-2/predia=-2/vmax_b_frames=1/mbd=2/qpel/mv0/v4mv/trell
> 
> Of course the results need to be examined more carefully than
> with "sort", as in the top 10 alone figure 3 *cmp, all 5 *dia,
> both b_frames (although with a 9:1 advantage to 1). mv0,
> trell, qpel and v4mv are always there, with vme=4 and
> mbd=2. In the top 25, cbp is there 3 times near the bottom,
> and b_frames is less clear-cut. qprd isn't there, but
> as over 60% of the result with qprd are missing...
> 
> Speaking of that, it seems that there's no result for
> "mbd=1 & qprd". I guess there's a problem here, assuming
> the combination is legal (the man page doesn't say otherwise).
> That's 2400 failures accounted for...

Makes sense. qprd = qp rate distortion optimal. Hard to do if you're
not using rd-optimal (mbd=2) mode to begin with. IIRC the man page
says you need mbd=2 for qprd.

> More interesting: "vme=4" has 3528 results, only 72 short
> of the 3600 one would have after removing the 1/4 "mbd=1 & qprd".
> Guess vme=1 is more of a problem (2106 results). With vme=4,
> those 72 failures happened "*dia=2 & *cmp=1 & qpel". Is that
> an invalid combination ?
> 
> (I haven't checked where "vme=1" fails).


Ignore it, vme=1 is sucky and broken.

Rich