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

[Michael Niedermayer]

On Wed, Apr 15, 2009 at 04:24:34PM -0700, Baptiste Coudurier wrote:
> On Thu, Apr 16, 2009 at 12:53:53AM +0200, Michael Niedermayer wrote:
> > On Wed, Apr 15, 2009 at 03:21:53PM -0700, Baptiste Coudurier wrote:
> > > On Wed, Apr 15, 2009 at 11:43:12PM +0200, Michael Niedermayer wrote:
> > > > On Wed, Apr 15, 2009 at 01:51:32PM -0700, Baptiste Coudurier wrote:
> > > > > On Wed, Apr 15, 2009 at 10:32:29PM +0200, Michael Niedermayer wrote:
> > > > > > On Wed, Apr 15, 2009 at 01:22:10PM -0700, Baptiste Coudurier wrote:

[...]
> > > 
> > > > the global context doesnt work as the palette isnt global, and
> > > > using the context is what we do currently and that causes race conditions,
> > > > which is why its currently not working ...
> > > 
> > > No, we do not use a separate context for format _and_ codec currently. That's
> > > one other option.
> > 
> > Its of no relevance at all if the context is seperate, an application could
> > take the palette out of AVCodecContext as much as it could out of
> > AVFormatContext, theres no difference at all both are available to an
> > application. But applications do NOT do it because its a huge mess to
> > implement this in a way that works, instead applications take the
> > palette out of AVFrame.data which is not thread safe and does not work.
> 
> Well internalizing because it is a big mess to implement can IMHO be a
> good think of course.
> 
> Now if you buffer pkt you buffer pkt->palette_data and packet is
> passed to the decoder using avcodec_decode_video2.
> 
> What's the problem here ?

That user apps that are not based on libav* (mplayer, xine, vlc at least)
dont use AVPacket internally, and i suspect many players will rather drop
palette support or even libavformat support before redesigning their
internal buffer and fifo handling to pass vectors of arrays between
demuxers and decoders.
Also there are systems (maybe dshow?) that are not going to be redesiged
to allow passing of vectors of arrays between layers

we are not in power to choose any arbitrary interface between demuxer and
decoder because players likely have their own interface and just use
libavcodec and libavformat in addition to their own native system.
Besides we should not change the interface without exceedingly good reason


> 
> > > 
> > > > [...]
> > > >
> > > > I do NOT ignore suggestions that have advantages but I do ignore equivalent
> > > > suggestions that have no advantages, i rather move forward if noone has a
> > > > better suggestion.
> > > > 
> > > 
> > > Well, I think you are.
> > 
> > You had trolled around like this in the past
> > mjpeg, gif palette, ...
> 
> You call discussing, trolling. The discussion was justified IMHO.
> Besides this was not about gif palette, it was how to implement
> animated gif in the decoder.

there where multiple gif trollings i guess ;)
one was about how the bugs in the gif decoder where twisted by you into
bugs in swscale and effectively forced me to fix your code to proof you
wrong.

[...]


> > and in no case did the discussions lead to anything
> 
> Of course it did, mjpeg interlacing is somehow fixed, not correctly
> since it forces a multiple of 2 height, but it somehow works.

its fixed because i fixed it

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/db196e39/attachment.pgp>