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

[Reimar Döffinger]

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.

> >> Also AVPacket could have ->palette_data field which seems a lot cleaner
> >> to me and Ronald.
> > 
> > Sure it is because you are completely ignoring the cases where it
> > doesn't work (muxing to non-AVI always, and either you have to decode
> > the palette etc. in the demuxer or it won't even work for remuxing into
> > AVI - muxing for almost all these formats in the only way to get an
> > index and thus quick and reliable seeking btw.).
> 
> Please enumerate the formats and problems it might cause.
> Muxing to .mov is pretty much different than .mkv and stream copy case

Well, maybe I am clueless, but I see nothing to enumerate, the issue is
simply "where the heck do you store the data in palette_data when
muxing?".

> is important too, by altering the packet you are causing many sides effects.

Please be more specific. It is the _current_ demuxer code that completely munges
up the data, throwing away information how the palette was encoded,
sometimes even applying (lossy!) gamma correction and in the process,
my patch simply changes that so that the demuxer passes all
video-related data _unchanged_ to the decoder.
The only issue is that the format might looks e.g. like this:
fixed size video-related data
palette size
palette
size
variable size video data

I guess the demuxer could just pick out those sizes via seeking, then
seeking back and read them all in a bunch in a video packet but
1) it's not what I'd consider a better/cleaner solution
2) not sure if there aren't any not-video-related parts in-between
ever...