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]. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
