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

[Baptiste Coudurier]

Hi,

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[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?
> 
> no
> 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