[MPlayer-users] lavc vs. xvid (and improving lavc quality)

[Michael Niedermayer]

Hi

On Sunday 06 June 2004 22:26, Jason Tackaberry wrote:
> On Sun, 2004-06-06 at 21:21 +0200, Michael Niedermayer wrote:
> > could also be caused by different encoding options, its impossible to
> > say, as people who complain about quality rarely upload samples ...
>
> Guilty as charged.
>
> I did some tests with cvs from a few minutes ago (with xvid 1.0.0 final)
> and got some interesting results.  I uploaded a number of files
> (paycheck-clip-*).  paycheck-clip-dvd.avi is an -ovc copy, and each of
> the other files are transcoded from that.
>
> I play these back on my TV with -vf eq2=1.25.  Rich will tell me to turn
> gamma off, but I'll tell Rich that this output yields the same
> brightness/contrast as my set-top DVD player, and everything looks
> awkwardly dark without it.  Turning off the gamma correction is
> tantamount to closing my eyes, sticking my fingers in my ears, and going
> "la la la, there is no problem."
the gamma correction done by eq2 is completly wrong, as gamma correction must 
be done in rgb space, but eq2 does it in YCbCr, though thats not the reason 
for the "blocking" artefacts

>
> Anyway, the frame worth looking at is around 40, where the stopwatch is
> in frame.  Look at the greyish background -- the blockiness is quite
> visible there.
>
> paycheck-clip-lavc-q2.avi:
>   mencoder paycheck-clip-dvd.avi -vf
> pullup,softskip,crop=720:352:0:66,hqdn3d=2:1:2 -ofps 23.976 -ovc lavc
> -lavcopts
> vcodec=mpeg4:vqscale=2:v4mv:mbd=2:trell:mv0:vmax_b_frames=0:autoaspect:psnr
> -o paycheck-clip-lavc-q2.avi -> 1356 kbit: PSNR: Y:47.27, Cb:49.92,
> Cr:50.23, All:48.02
>
> paycheck-clip-xvid-q2.avi:
>   mencoder paycheck-clip-dvd.avi -vf
> pullup,softskip,crop=720:352:0:66,hqdn3d=2:1:2 -ofps 23.976 -ovc xvid
> -xvidencopts fixed_quant=2:chroma_opt:vhq=3:autoaspect:max_bframes=0:psnr
> -o paycheck-clip-xvid-q2.avi -> 3739 kbit:  Average PSNR y : 48.82 dB, u :
> 50.93 dB, v : 51.55 dB
>
> Now, the Paycheck version looks _vastly_ better, but look at the
> bitrate!   Clearly I'm missing something, or xvid's fixed_quant !=
> lavc's vqscale.  I can't even make lavc use that high bitrate if I try.
> Even vqscale=1 is only 1919 kbit and doesn't look much better than
> vqscale=2.
ok, thats funny, xvid isnt doing what u tell it to do, just try mplayer 
-lavdopts debug=1 and look at the qp values, xvid uses qp=1 on every second 
frame, anyway that again isnt the reason why it looks better without 
postprocessing or noise
btw, for libavcodec u need vqmin=1 together with vqscale=1 to get qp=1, this 
is btw a feature not a bug :)
mv0 could theoretically also cause blocking artefacts, but its not the main 
cause here

one way to get rid of the block artefacts is to use 
vqmin=1:vqscale=1:pbias=64:ibias=128:vfdct=6 and disable trell, but that will 
make the file very big, allthough its probably how xvid does it except that 
they use fewer qp=1 frames / a different bias, but then again its just a 
speculation i didnt RTFS

another solution is to get _latest_ libavcodec cvs and use 
cmp=10:subcmp=10:mbcmp=10:dia=3 but this is very new and so might not work as 
expected yet, theres also a coefficient in the code which still needs to be 
finetuned or exported

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en