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

[Reimar Döffinger]

On Wed, Apr 15, 2009 at 12:21:57PM -0700, Baptiste Coudurier wrote:
> On Wed, Apr 15, 2009 at 09:00:36PM +0200, Reimar D?ffinger wrote:
> > On Wed, Apr 15, 2009 at 11:42:55AM -0700, Baptiste Coudurier wrote:
> > > On 4/15/2009 11:18 AM, Reimar D?ffinger wrote:
> > > > On Wed, Apr 15, 2009 at 10:54:01AM -0700, Baptiste Coudurier wrote:
> > > >> I'm pretty this av_grow_packet ugliness is useless.
> > > > 
> > > > It is needed because the formats were never designed for split demuxer
> > > > and decoder.
> > > > Without this you get stuff like in ipmovie:
> > > >> av_new_packet(pkt, s->decode_map_chunk_size + s->video_chunk_size)
> > > >> url_fseek(pb, s->decode_map_chunk_offset, SEEK_SET);
> > > >> get_buffer(pb, pkt->data, s->decode_map_chunk_size);
> > > >> url_fseek(pb, s->video_chunk_offset, SEEK_SET);
> > > >> get_buffer(pb, pkt->data + s->decode_map_chunk_size, s->video_chunk_size)
> > > > 
> > > > Or in most cases simply an  incomplete and sometimes subtly
> > > > broken but at least inconsistent ad-hoc reimplementation of it.
> > > > Suggestions of better solutions are of course welcome, I already asked
> > > > for them. Twice.
> > > 
> > > Well I already gave one: use extradata if possible.
> > 
> > There is no palette at all involved here.
> 
> In WC3 ? I thought you were talking about this.

I was talking about the code I was quoting, as an example that I never
intended this to be the only use for those API functions.

> > I don't really consider it worth the effort.
> 
> I really consider it worth the effort.

Then please go ahead.

> I understand the problem with race condition is because the demuxer
> actually updates AVCodecContext palette directly, but IMHO that can be
> fixed by letting application dealing with palette change.

So your solution is just to remove the only way to pass the palette that is
there?
Sorry, I really don't see the point of continuing discussion if you only provide
solutions that are so much simpler because they don't even half-work and in
some other cases because you are free to choose whichever way is more convenient
for them problem but exclude each other (e.g. "compressed" vs. uncompressed
palette data). It's just another bikeshed like that and I'm really tired of the
endless discussions it causes with in the end nobody doing any fix whatsoever,
just like in the DV demuxer case.

> If formats didn't judge pertinent to store the palette within the frame,
> why are we obsessed in doing this ?

_I_ am not talking about AVI, for the other formats they can be just as much
considered "within" the frame as they could be considered separate IMO.

> Well, your patch assumes that libavcodec is used unfortunately,

No.

> and that libs are updated at the same time too.

As would any change removing AVPaletteControl

> If we don't decode palette in demuxer, we could pass raw data to
> decoder in some way. 

For example in the way my patch does

> I just don't like appending palette in packet data because this forces
> parsing.

Again, _I_ am not considering AVI/ASF and I make no claim as to what the
proper solution for them is, but _my_ patch mostly only _moves_ code from
the demuxer to the decoder.