[FFmpeg-devel] [RFC] Missing rawvideo pixel format FourCC tags

[Michael Niedermayer]

On Sat, May 08, 2010 at 02:23:48AM +0200, Stefano Sabatini wrote:
> On date Friday 2010-05-07 14:27:26 +0200, Michael Niedermayer encoded:
> > On Fri, May 07, 2010 at 12:54:32PM +0200, Stefano Sabatini wrote:
> > > On date Friday 2010-05-07 12:18:52 +0200, Michael Niedermayer encoded:
> > > > Hi
> > > > 
> > > > whats the status of the avfilter regtests?
> > > > ive just commited avfilter support for ffmpeg.c so the main obstacle should
> > > > be out of its way
> > > 
> > > http://thread.gmane.org/20100322225212.GF2826 at geppetto
> > > 
> > > |Note that many of the issued files *cannot be reproduced* by ffplay, as
> > > |for many of them there is no support by nut.
> > > 
> > > We need to find a way to tell ffplay/nut how to recognize
> > > rawvideo+pixfmt files for which currently there is not a FourCC
> > > defined.
> > 
> > define one, docs/nut4cc.txt lists them
> > but even without that theres no reason not to test the ones that are
> > supported
> 
> Some of the missing rawvideo tags are already defined in nut4cc.txt,
> for others we can follow some common pattern, for others we rely on
> common sensem, for others I have no idea (maybe use some hash?).

nothing is supposed to be missing from nut4cc


> 
> Anyway since these are not going to be legal FourCC tags (that is they
> will be used *only* by Nut) we should find some way to make them
> accessible only to nut.

is it really neccesarry that you drag a redesigns into everything
you change? And by extension of that drag a new redesign in every
redesign ;)
just set them in the rawvideo encoder like API demands and override it in
riff/avi
the alternative will require spliting CODEC_ID_RAWVIDEO per pixel format
this would be none the cleaner and it would be lots of work
I want to move forward not redesign apis all day long even though they
where perfectly suficent to begin with.


[...]
> Follow the list of missing tags and suggestions.
> I'm using the "*" symbol to mark teh tags which are already defined in
> nut4cc.txt.
> 
> rgb24 -> RGB[24]*
> bgr24 -> BGR[24]*
> yuv444p -> ?

444P


> monow -> MOWH ?
> monob -> MOBL ?

> yuvj420p -> ?
> yuvj422p -> ?
> yuvj444p -> ?

these are deprecated hacks specific to libav*
they are identical to yuv4XYp


> uyyvyy411 -> none

y411


> bgr8 -> BGR[8]
> bgr4 -> BGR[4]
> rgb8 -> RGB[8]
> rgb4 -> RGB[4]

> bgr4_byte -> ?
> rgb4_byte -> ?

i dont care, these are subsets of 8bit paletted data


> nv12 -> NV12
> nv21 -> NV21
> argb -> ARGB*
> rgba -> RGBA*
> abgr -> ABGR*
> bgra -> BGRA*
> gray16be -> [16]Y00

> gray16le -> Y00[16]

Y16 see fourcc.org


> yuv440p -> ?
> yuvj440p -> ?
> yuva420p -> ?
> rgb48be -> [48]RGB
> rgb48le -> RGB[48]

> rgb565be -> ?
> rgb555be -> ?
> bgr565be -> ?
> bgr555be -> ?

see nut4cc


> yuv420p16le -> ?
> yuv420p16be -> ?
> yuv422p16le -> ?
> yuv422p16be -> ?
> yuv444p16le -> ?
> yuv444p16be -> ?
> rgb444be -> ?
> rgb444le -> ?
> bgr444be -> ?
> bgr444le -> ?
> y400a -> ?

i will think about these, you can until then submit a patch that implements
the ones that exist

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100508/85e70370/attachment.pgp>