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

Reimar Döffinger Reimar.Doeffinger
Wed Apr 15 19:43:29 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:
> > 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.

I don't see a point in inventing a new encoding format when it's all
been done already, I am just moving a lot of parsing and decoding
functions from the demuxer to the decoder where they would have belonged
in the first place.
The extradata idea _might_ work for wc3, but it would leave exactly the
"same" issues with other formats like idcin plus due to lack of
specification we don't know if new palettes can't be added in the middle
of the file.

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

More information about the ffmpeg-devel mailing list