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

[Baptiste Coudurier]

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 don't think that deliberately forcing your opinion is constructive
in any way.

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

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

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA    
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org