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

[Michael Niedermayer]

On Sat, Mar 14, 2009 at 02:26:16PM -0700, Baptiste Coudurier wrote:
> 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 ?

i see no problem with extradata use if the palette doesnt change

> 
> Maybe a flag is better than a string ?


> Appending the palette might not break, no ?

Appending the palette instead of putting it in front seems a good/better idea
ideed if the following would work:

no flag,no string, the deocoder just decodes the frame and if something is
left afterwards its treated like a palette

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090315/ab007129/attachment.pgp>