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

[Michael Niedermayer]

On Sun, Mar 15, 2009 at 12:23:41AM +0100, Michael Niedermayer wrote:
> 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

but as ronald says it doesnt work, i see not much advantage of either
placement over the other.
Infront is closer to mpeg1/2/4/h264 placement of things like quantization
tables

about flag vs. string.
The advanatge of a string might be that it is slightly more robust, i mean
a decoder checking of 'p' vs 'd' would have problems when neither is
there. While "Palette" will not occur by mere chance, then again
"Palette" & "Frame" could be used or fourccs ;)
what does matter is that we decide on one way and apply it consistently
for all codecs & demuxers that need it. (i think for demuxers its only avi and
mov, the others would just keep the palette with flag or string in the frame)

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/f373a6e6/attachment.pgp>