[FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote:
> On 02/27/2016 09:21 PM, Mats Peterson wrote:
> >On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
> >>Well, then we know I can only blame Mats for "only" making it
> >>better instead of perfect :)
> >>_______________________________________________
> >
> >Well, before my patches, there was no palette inclusion whatsoever in
> >AVI or QuickTime on muxing. Anyway, you're right about the stream
> >copying not working. Just tried it here. Another issue to take care
> >of... phew.
> >
> 
> Solving the stream copying issues obviously requires using side data packets
> in the muxers, correct me if I'm wrong.

Well, that is one option.
It is also possible for the demuxers to (possibly even just in
addition) append the palette - but I think that is problematic
when palette isn't provided for every frame.
Probably better would be for muxers to have a little magic
function.
const uint8_t *ff_update_get_palette(AVFormatContext *, AVFrame *, bool);
That function would then do something like (possibly a bit overkill
as I describe it):
1) Check if it's a paletted raw format and the palette is appended.
   If so extract it, possibly expand it, store it in the context
   and return the pointer.
2) Check if there is side data palette, and if so store it in the
   context too and return the pointer
3) If palette is not available in any way right now, return the
   one we previously stored in the palette if any.

The bool could then be used to configure whether the return value
should be NULL instead in case of 3) or when in 1) and 2) the
new palette is identical (that way it is selectable if the
palette gets stored with every frame or not, it could probably
even expanded to track actual changed entries).

As said, that is overkill, but it shouldn't hurt to at least
have possible future "nice to haves" in mind from the start.