[FFmpeg-devel] [PATCH] mov.c: factorize ff_mov_read_stsd_entries()
Sat Mar 14 22:26:16 CET 2009
On 3/14/2009 11:09 AM, Michael Niedermayer wrote:
> On Sat, Mar 14, 2009 at 01:27:36PM -0400, Ronald S. Bultje wrote:
>> Hi Michael,
>> On Sat, Mar 14, 2009 at 1:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> you cant do this, data 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
>>> 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
> The first thing is that the demuxer-decoder bitstream really is incomplete
> currently by passing palettes secretly behind in a thread unsafe way.
> placing the palettes in the bitstream and making it possible for the decoder
> to identify what part of the bitstream is a palette fixes it.
> adding a flag is again not fixing it, there still is a "out of bitstream"
> thing needed that must be passed together with the packets. This really
> isnt bette then currently, its actually maybe even worse because you change
> the bitstream _and_ leave the bug.
If I understand correctly, you mean that even extradata way is not wanted ?
Maybe a flag is better than a string ?
Appending the palette might not break, no ?
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel