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

[Baptiste Coudurier]

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.

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

Well, IMHO you need to enumarate which codecs use palette and how do
they store this information. After that you check how palette is
supposed to be stored in the destination container, because containers
may have a standard way to store palette.

You can then decide how it seems usual and simple to store the palette.

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

AVPacket->palette_data is still simpler IMHO.

Also now that we pass AVPacket to decode_video, we may put AVPalette in
AVFormatContext and use the same api, and instruct that palette changed
to the decoder with a flag in AVPacket.

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

Well, I'd say it depends on the way palette is stored.

Also, IMHO a clear distinction must be done between libavformat and
libavcodec, nothing should mandate the use of libavcodec decoder,
although for these game formats libavcodec may be the only software
decoder available.

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