[MPlayer-dev-eng] [PATCH] CQMs in x264

[Diego Biurrun]

On Wed, Jul 27, 2005 at 02:17:33AM +0100, Robert Swain wrote:
> On 7/27/05, Diego Biurrun <diego at biurrun.de> wrote:
> > On Tue, Jul 26, 2005 at 07:46:20PM +0100, Robert Swain wrote:
> > > +.B cqm4iy=<list>
> > > +Custom 4x4 intra luminance matrix. A list of 16 comma separated values.
> > 
> > Capitalization is funky here, try
> > 
> >   custom 4x4 intra luminance matrix (list of 16 comma separated values)
> 
> Guillaume helped with these issues already, so please see what you
> think of the docs in this patch.

It's OK now.

> > What those values are is still a mystery.
> 
> They are values between 1 and 255. The coefficients of these matrices
> are used for the quantisation stage of h.264 encoding. I guess if you
> don't know what that is or don't use h.264 codecs then it won't really
> matter if you don't know. :) They're exactly the same concept as
> custom quantisation matrices for MPEG-4 ASP (XviD, etc) codecs.

I'd personally mention that somewhere.  However, if you say this is
known to anybody using x264 then maybe it's redundant.

> > Whoever came up with these cleverly inconsistent option names (i vs y vs
> > p) should enter some sort of obfuscation contest...
> 
> It's perfectly consistent. Breaking it down into sections:
> 1) cqm - means custom quantisation matrix
> 2) 4 or 8 - mean the matrix is either 4x4 or 8x8 respectively, hence
> 16 or 64 values are required
> 3) i or p - mean the matrix is intended for intra or inter blocks respectively.
> 4) y or c - mean the matrix is intended for luminance or chrominance
> blocks respectively. That is Y, or U/V. x264 uses the same matrix for
> both U and V as far as I can see but it is possible in the
> specification to use two different matrices. Also note that for the
> 8x8 matrix size there are no chrominance matrices. This is because of
> the h.264 high profile specification.

I was referring to the 8x8 matrices.  If it's absolutely clear that they
are luminance only, then it can be called consistent, yes.

> > > +.RE
> > > +.I NOTES:
> > 
> > .RE ends, not starts, first level suboptions.
> 
> Well this is what I read:
> 
> ".RE [nnn]
>  	This macro moves the left margin back to level nnn; if no argument
> is given, it moves one level back. The first level (i.e., no call to
> RS yet) has number 1, and each call to RS increases the level by 1."
> 
> I wanted it to move back one level such that the notes apply to the
> lists and the cqm=blah stuff.

OK, I'm not entirely happy with the way it's looking now, but I don't
know a good way to improve it off the top of my head.  I'll try to come
up with something once this is committed.  The documentation part of
this patch has my blessing now.

> Thank you for all your comments and assistance by the way Diego.

:) You're welcome.

Diego