[FFmpeg-devel] [PATCH] Make nut muxer and demuxer recognize the extended nut tags associated to rawvideo pixel formats

[Stefano Sabatini]

On date Tuesday 2010-03-23 04:23:01 +0100, Michael Niedermayer encoded:
> On Tue, Mar 23, 2010 at 01:05:49AM +0100, Stefano Sabatini wrote:
[...]
> > > the codec_tag-pix_fmt mapping is in libavcodec/raw*
> > > add it there where the avi and quicktime mappings already are.
> > 
> > I thought that that mapping would be nut-specific, so I fail to see
> > why it should be implemented in
> > libavcodec/raw.c:ff_raw_pixelFormatTags.
> 
> because thats how its done. And thats how all non raw video decoders
> set the pix_fmt.
> the mpeg-ps muxer doesnt set pix_fmt to yuv420p or 422p depending on the
> mpeg-es headers
> Iam not interrested in redesigning this, its fine as it is, it works.
> Find a bug and we can talk but not because you dont like the design
> and that doesnt mean anyone would like the alternative more.

I don't care about the design, I just want the thing working, it this
can be done with the current design I'm all fine.

> > Also that would introduce the possibility for the AVI/QT muxer to use a
> > tag which is not valid for it, no?
> 
> depends on how you add the tags

Please elaborate. 

> > That said, I really don't mind into putting these nut tag definitions
> > in ff_raw_pixelFormatTags, but that sounds odd/wrong to me.
> 
> setting pix_fmt in the mpeg-ps demxuer sounds wrong to me
> setting pix_fmt for some cases in the demxuer and for some cases in the
> decoder sounds like something i dont want to have to maintain.
> so whats left is what we have. The least ugly IMHO but iam sure some
> will disagree ...

Now I have this problem:
libavcodec/raw.c:
    { PIX_FMT_GRAY8,   MKTAG('G', 'R', 'E', 'Y') },
    { PIX_FMT_RGB555,  MKTAG('R', 'G', 'B', 15) },
    { PIX_FMT_BGR555,  MKTAG('B', 'G', 'R', 15) },
    { PIX_FMT_RGB565,  MKTAG('R', 'G', 'B', 16) },
    { PIX_FMT_BGR565,  MKTAG('B', 'G', 'R', 16) },
    { PIX_FMT_RGB565,  MKTAG( 3 ,  0 ,  0 ,  0 ) },

Now I want to add these entries, which are specific to nut:
    { PIX_FMT_RGB555LE,  MKTAG('R', 'G', 'B',  15) },
    { PIX_FMT_BGR555LE,  MKTAG('B', 'G', 'R',  15) },
    { PIX_FMT_RGB565LE,  MKTAG('R', 'G', 'B',  16) },
    { PIX_FMT_BGR565LE,  MKTAG('B', 'G', 'R',  16) },
    { PIX_FMT_RGB555BE,  MKTAG( 15, 'B', 'G', 'R') },
    { PIX_FMT_BGR555BE,  MKTAG( 15, 'R', 'G', 'B') },
    { PIX_FMT_RGB565BE,  MKTAG( 16, 'B', 'G', 'R') },
    { PIX_FMT_BGR565BE,  MKTAG( 16, 'R', 'G', 'B') },

as the RGB5X5 is NE, in a BE machine we'll end-up with a non valid
tag for nut, as I'm supposed to append these entries.

In general there is no guarantee that the tag<->pix_fmt mapping in
libavcodec/raw.c won't conflict with the mapping used by nut (or other
formats as well).

Also adding such mapping in ff_raw_pixelFormatTags will result into
making the other formats use tags which are reserved to nut, so I
still fail to see how I can fix this problem without to use a nut
specific table (check attached patch series - yet untested but posted
just to show the approach).

Regards.
-- 
FFmpeg = Free & Furious Mega Pitiful Ecstatic Gadget