[FFmpeg-devel] maintainer duties (was: Re: [PATCH] fix speex sample)

Reimar Döffinger Reimar.Doeffinger
Sat Apr 11 15:36:39 CEST 2009

On Sat, Apr 11, 2009 at 09:23:49AM -0400, Ronald S. Bultje wrote:
> On Sat, Apr 11, 2009 at 7:49 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > It has been decided to put the palette in the AVPackets
> > how to do this is a question per decoder and per demuxer, some may have a
> > natural way to pass the palette, some might even say in a spec how to do it
> > (though i guess that would be the exception if it applies to any at all)
> > the rest could just have a 'P'<len> vs. 'D' prefixed to packets
> I think I said this before, I don't like this (conceptually). Can't we
> just add a PKT_FLAG_PALETTE? It's exactly the same as a prefix, except
> that it does not actually touch the bitstream. Now that Thilo added
> all these AVPackets to the decode() functions, let's use them.

It does not solve remuxing into containers that do not support separate
palette packets.
It also does not solve the case of e.g. ipmovie.c where a "palette
packet" is allowed to change a single palette entry, unless you want to
allow PKT_FLAG_PALETTE packets to contain anything they want the demuxer
would still have to keep a copy of the palette around, modify it and
send the full palette on. Not only is that something a demuxer IMO
should not do, but it also loses information and can bloat the size a
Also I think it would already be quite simple to fix if we just allowed
packets to contain only palette (without any PKT_FLAG_PALETTE), since
allocating a buffer and merging the palette stuff together with a video
buffer is just a pain to implement. The problem though is that no
keyframes at all would exist then.

More information about the ffmpeg-devel mailing list