[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl
Wed Apr 15 19:33:54 CEST 2009
On Wed, Apr 15, 2009 at 10:22:26AM -0700, Baptiste Coudurier wrote:
> 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
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
third its another field that bloats small AVPackets, another field that
must be handled explicitlyin every user application that does not use
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel