[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl
Wed Apr 15 20:18:26 CEST 2009
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
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
> 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
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
More information about the ffmpeg-devel