[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl

Michael Niedermayer michaelni
Thu Apr 16 01:08:41 CEST 2009


On Wed, Apr 15, 2009 at 03:39:50PM -0700, Baptiste Coudurier wrote:
> On Wed, Apr 15, 2009 at 11:55:48PM +0200, Michael Niedermayer wrote:
[...]
> 
> > [...]
> > > > > [...]
> > > > > 
> > > > > IIRC the race condition happens because demuxer sets palette to
> > > > > AVCodecContext _directly_.
> > > > > 
> > > > > Storing it in AVFormatContext should avoid this race, or is there
> > > > > something I'm forgetting ?
> > > > 
> > > > you forget that the palette from AVFormatContext must reach the decoder
> > > > and what you do is that you would just remove the code that does that
> > > > that fixes the race condition but it removes palette support pretty much
> > > 
> > > I don't forget, application will update AVCodecContext palette
> > > accordingly, of course. This does not remove palette support at all,
> > > and avoids changing decoders and fixes the race condition IMHO since
> > > now AVCodecContext does not get updated by the demuxer but the application.
> > 
> > Which application?
> > 
> 
> One you don't know about ? ;)

Yes, exactly it will not work with any application i do know about
ffplay, ffmpeg, vlc, mplayer, xine, ...


> This is still one solution.
> 
> There are at least 3 solutions:
> - append palette to pkt->data

yes, thats what i suggested


> - use pkt->palette_data

this is the same as using pkt->data, it needs grow and append and parsing
read what reimar wrote
and it does not work with most muxers as is


> - use AVFormatContext palette

This is equivalent to what we do currently as i said already


> 
> If the third is not ok for anybody then fine.
> 
> I find the second reasonable and should satisfy everybody IMHO.
> Palette is passed through AVPacket and it avoids parsing in pkt->data,
> though it grows a bit AVPacket struct. It's not like we are afraid of
> growing structs usually ;)

you really arent reading what others write

let me repeat
formats store several compressed palette chunks that update the previous
these need merging at the demuxer and parsing at the decoder no matter if
they are in data or palette_data
also the palette stuff no matter where it is need to be decompressed before
you have 256 entries you can pass to the video out
Decompression belongs to the decoder.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- 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/20090416/66a46463/attachment.pgp>



More information about the ffmpeg-devel mailing list