[Ffmpeg-devel] AVPaletteControl removal from libavf (was Re: [MPlayer-dev-eng] [PATCH] (bit hackish) palette support for libav*)

Reimar Doeffinger Reimar.Doeffinger
Tue Jan 30 13:56:00 CET 2007


Hello,
On Tue, Jan 30, 2007 at 12:13:11AM +0100, Michael Niedermayer wrote:
> On Mon, Jan 29, 2007 at 11:03:26PM +0100, Reimar D?ffinger wrote:
> > @@ -498,6 +497,13 @@
> >      /* make a note of where the stream is sitting */
> >      s->next_chunk_offset = url_ftell(pb);
> >  
> > +    if (palette_changed) {
> > +        if (av_new_packet(pkt, AVPALETTE_SIZE))
> > +            chunk_type = CHUNK_NOMEM;
> > +        memcpy(pkt->data, s->palette, AVPALETTE_SIZE);
> 
> are you aware that you put endian specific data into the AVPacket? this is
> not good at all
> i would rather pass the palette as it is stored to the decoder (unless of
> course the specific codec can be stored in several containers and expects
> some specific format)

The way it is stored is a partial and in additon 6 bit per component
palette. Though honestly I don't get why the palette is in host
endianness in the first place. I may simplify the conversion to RGB32
but (probably) complicates all other cases.
I can use the palette as MPlayer expects it (always LE), which has the
advantage that the swscale functions actually work with it (though it
does help much as long as the format in AVFrame stays endian-dependant). 

> also i would pass the palette like a normal video frame into the decoder
> instead of using AVCodecContext

Sure, that would be preferable, but how to tell the decoder this is a
palette? Adding a flag parameter to the decode function? That would make
for quite a huge patch a (and a lot of work to make it)...
Advantage: that way could also be used for some other kinds of "extradata".

Greetings,
Reimar D?ffinger




More information about the ffmpeg-devel mailing list