[FFmpeg-devel] [PATCH] mov.c: factorize ff_mov_read_stsd_entries()

Ronald S. Bultje rsbultje
Sat Mar 14 18:27:36 CET 2009

Hi Michael,

On Sat, Mar 14, 2009 at 1:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> you cant do this, data[1] is native endian, the codec bitstream must not
> depend on the cpu endianness

Well, that's why it's an ugly proof-of-concept, right? It just shows
how it can be done, not how to do it correctly.

> what you can do is,
> store the string "Palette" at AVPacket.data[0]
> then 1 byte indicating which first palette entry changed, and then a byte
> indicating how many are updated (0=256)
> and store 4 byte RGBA for each entry changed.
> the decoder can then check for "Palette" and extract it if one is there.
> The rest of the packet would be the normal frame.

It would be nice if I could do it without having to touch the actual
demuxer-decoder bitstream. Could we do something like AVPacket.flags =
PKT_FLAG_PALETTE; and then include a palette as packet or have a
second buffer (palette) in the AVPacket or something along those
lines? Whoever calls the decoder calls could then sync these packets
with data packets and extract them to update
st->codec->palctrl.palette anytime something changed, and this would
be in sync with demuxing/decoding evne when they're in different
threads. also, it wouldn't affect the bitstream, which I personally
consider dirty. I'm just saying random stuff here, but that's sort of
the direction that I'd be thinking of.


More information about the ffmpeg-devel mailing list