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

[Michael Niedermayer]

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:
> > > > 
> > > > [very boring "discussion"]
> > > > 
> > > > > public API, nor av_shrink_packet but it's too late.
> > > > 
> > > > a patch moving av_shrink_packet() to ff_shrink_packet() in lavf is welcome
> > > > av_shrink_packet() could be put under the appropriate #if version and removed
> > > > from the public header
> > > > 
> > > > i have no real oppinion on doing this or not doing this
> > > > 
> > > > but, this has absolutely nothing to do with palettes ...
> > > > 
> > > > ontopic:
> > > > ill fix the avi demuxer as soon as the append packet code is in
> > > > svn. A solution with extradata is not possible for avi, nor is one
> > > > based on passing the palette through AVFormatContext practical.
> > > > 
> > > 
> > > How is this contructive at all ? What are you trying to achieve here ?
> > > Deliberately ignoring people ?
> > 
> > Its constructive in the sense that implementing it will lead to working
> > palette support.
> > This discussion did not lead to any new insights in how palette support
> > could be implemented in a way that works.
> >
> > I have considered the extra field and extra flag in AVPacket years
> > ago,
> 
> What are the disadvantages of pkt->palette_data ?
> It's one more field which Ronald and me would prefer vs
> merging palette with pkt->data which requires parsing.

i alraedy said it needs parsing too


> 
> I don't think that deliberately forcing your opinion is constructive
> in any way.

And i think deliberately blocking a solution without offering any consistent
alternative is very trollish behavior.


> 
> > 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.

> 
> > [...]
> >
> > 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, ...
and in no case did the discussions lead to anything
also reimar and me asked you several times to describe your alternaitve
you did not.
Theres nothing i ignore you just did not describe anything that is self
consistent and non ambigous.

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/a71e7e28/attachment.pgp>