[FFmpeg-devel] [RFC] Missing rawvideo pixel format FourCC tags
Sat May 8 20:07:21 CEST 2010
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
just set them in the rawvideo encoder like API demands and override it in
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
> rgb24 -> RGB*
> bgr24 -> BGR*
> yuv444p -> ?
> monow -> MOWH ?
> monob -> MOBL ?
> yuvj420p -> ?
> yuvj422p -> ?
> yuvj444p -> ?
these are deprecated hacks specific to libav*
they are identical to yuv4XYp
> uyyvyy411 -> none
> bgr8 -> BGR
> bgr4 -> BGR
> rgb8 -> RGB
> rgb4 -> RGB
> 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 -> Y00
> gray16le -> Y00
Y16 see fourcc.org
> yuv440p -> ?
> yuvj440p -> ?
> yuva420p -> ?
> rgb48be -> RGB
> rgb48le -> RGB
> rgb565be -> ?
> rgb555be -> ?
> bgr565be -> ?
> bgr555be -> ?
> 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel