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)
42) some other solution.

Please give your opinions so I can choose a way to implement it. And it's not
only AVI, some game container-codecs will benefit from it too.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to