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

Michael Niedermayer michaelni
Sat Mar 14 19:09:28 CET 2009


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.


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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20090314/b1582413/attachment.pgp>



More information about the ffmpeg-devel mailing list