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

[Baptiste Coudurier]

On 4/15/2009 10:33 AM, Michael Niedermayer wrote:
> On Wed, Apr 15, 2009 at 10:22:26AM -0700, Baptiste Coudurier wrote:
>> Hi,
>>
>> On 4/11/2009 3:19 PM, Reimar D?ffinger wrote:
>>> Hello,
>>> attached patch implements this.
>>> It is a bit ugly because it adds a lot of seeking to the demuxer, but I
>>> think for such a fringe format there is no point in extra work for avoiding it.
>>> The patch also adds two helper functions, one to increase the size of a
>>> packet and one that appends data read from a file to a possibly already
>>> filled packet.
>>> I expect that there will be more that a few bugs still, e.g. while the
>>> video looks visually ok in ffplay the FATE regressions do not match at
>>> all.
>> Well it seems that palette could be stored in extradata in it's read in
>> wv3_read_header, a way to pass palette change information through
>> AVPacket would be needed.
>>
>> Also AVPacket could have ->palette_data field which seems a lot cleaner
>> to me and Ronald.
> 
> palette_data would be a nightmare in pretty much every aspect
> first many formats allow multiple palette chunks to update a palette
> for a frame. Yes AVI too which i had forgotten, it too can update
> 2 entries in a palette through 2 pc chunks that each changes just 1
> entry.

Please enumerate the formats. State exactly what the problem is.
Doesn't avi use bmp header ? If so palette -> extradata.

> second, muxers that do not support such palettes (mov/mp4/asf?/rm/mkv/nut/...)
> must somehow merge them and this should really have been done in the demuxer
> already.

I'm not sure about this, in _any_ case -vcodec copy will cause problems
since you have merged the palette and the data in the packet.

If the muxer can handle palette seperatly (mov does) it can create
multiple stsd with correct palette information. It avoids parsing
palette in the packet which is _really_ ugly.

> third its another field that bloats small AVPackets, another field that
> must be handled explicitlyin every user application that does not use
> AVPackets natively

And modifying demuxer require updating every decoder.

AVPacket has a useless ->priv flag already it seems. Adding a field is
_not_ a problem.

There is still the possibility to put in in AVFormatContext.

[...]

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