[MPlayer-dev-eng] [PATCH] CQMs in x264
Robert Swain
robert.swain at gmail.com
Wed Jul 27 11:13:06 CEST 2005
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>
More information about the MPlayer-dev-eng
mailing list