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

[D Richard Felker III]

On Mon, Jun 07, 2004 at 12:05:19AM -0400, Jason Tackaberry wrote:
> On Mon, 2004-06-07 at 05:29 +0200, Michael Niedermayer wrote:
> > 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
> 
> I guess doing it in RGB space would be really impractical.  Gamma
> correction with eq2 might not be precise, but at least it helps.  It's
> better than increasing brightness. :)

Better to do nothing at all. Then you don't create blocks!

> > 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 
> 
> Just based on the bitrate alone I figured xvid was doing something
> terribly strange.

Haha, xvid cheats...figures...

> > btw, for libavcodec u need vqmin=1 together with vqscale=1 to get qp=1, this 
> > is btw a feature not a bug :)
> 
> Hey, that explains a lot. :)

:)

> > mv0 could theoretically also cause blocking artefacts, but its not the main 
> > cause here
> 
> Hmm.  Do you think mv0 is worth it for high bitrates?

IMO mv0 has no point for high bitrate. The only purpose is to check if
encoding with a (0,0) vector is better (in a rate*distortion sense)
than using the actual vector from motion est.

> > 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
> 
> Wow.  WOW.  Did I mention: _WOW_!  This is an _amazing_ improvement.
> 
> You're my new deity for this week. :)

WOW! What I'm impressed at is that Michael was able to please the
"block whiners" so fast! :)

BTW, could we have an explanation of why the "noise preserving" sse
function is better?

Rich