On Sat, Apr 02, 2011 at 10:54:42AM +0100, Måns Rullgård wrote: > Kostya <[email protected]> writes: > > > Situation so far: > > 0) we have codecs that operate in paletted colourspace and palette changes > > may > > be signalled outside codec data (like AVI which has special "palette change" > > chunks) > > 1) we had AVPaletteControl which was broken if application didn't use > > "demux-decode-demux-decode" approach > > 2) certain somebody decided that in AVI case it should be handled by > > appending > > 1024 bytes with changed palette to demuxed packet and codecs should check if > > they have some undecoded data left (commit ID b7c40744). Naturally no codec > > was changed to do that so some codecs relying on it produce pictures with > > broken colours (let alone remuxing): > > http://samples.multimedia.cx/avi/palette_change/toon.avi > > http://samples.multimedia.cx/V-codecs/KMVC/baseball1.avi > > http://samples.multimedia.cx/V-codecs/QPEG/VWbig6.avi > > (raw http://samples.multimedia.cx/game-formats/yop/CIMOVI01.avi works by > > some > > coincidence). > > > > I think this can be resolved by passing new palette in AVPacket in some way: > > 0) do nothing and pretent that problem doesn't exist > > 1a) just add AV_PKG_FLAG_PAL and make codec treat last 1024 bytes of data as > > palette (should be done for muxers too). Alternatively packet size may be > > hacked so palette will be after declared packet end (but that's too hacky to > > my taste). > > 1å) add AV_PKT_FLAG_PAL and pass only palette change in packet (it may break > > timestamp handling, I fear) > > 2) introduce some specific fields in AVPacket for passing such information > > (too hacky IMO) > > Put the new palette in AVPacket.data[1].
Is the fuss with changing all pkt->data to pkt->data[0] worth it? _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
