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

Baptiste Coudurier baptiste.coudurier
Thu Apr 16 01:24:34 CEST 2009


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:
> > > > > 
> > > > > [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

If pkt->palette_data then extract_palette ?

if pkt->data ? argh damn does this packet contains palette or not ?
I just don't know.

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

Sorry but I don't think it is the case. I just enumerated 3 solutions
including yours.

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

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

This is not the first time you call trolling people expressing their
opinion which is against yours.

About gif animated, you just did remove the feature.

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

If this discussion didn't happen bug report would be still rotting in roundup.

> also reimar and me asked you several times to describe your alternaitve
> you did not.

Sorry, but I think I just did in the last mail.

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



More information about the ffmpeg-devel mailing list