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

[Robert Swain]

On 7/27/05, Diego Biurrun <diego at biurrun.de> wrote:
> 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.

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

Hmm. I suppose I should at least add that they're between 1 and 255.

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

I could call them cqm8iy and cqm8py if you prefer. I had to check that
they were luminance only before writing the descriptions.

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

:D Thank you.
 
Has anyone spotted anything wrong in lines 131-157 of the patch? :s

Regards,
Robert Swain (superdump)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer.x264.cqm.14.diff
Type: application/octet-stream
Size: 7087 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050727/b2560518/attachment.obj>