On 02/27/2016 02:44 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:
On 02/27/2016 02:03 PM, Mats Peterson wrote:
Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I have
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
movenc.c for calculating the number of palette entries in packets
containing a palette at the end, rather than just assuming 256 entries.
If we can agree on using this 1 << bits_per_coded_sample logic overall
for packets containing a palette, in the same way as it is done in AVI
and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it
somewhat more future-proof.
On the other hand, perhaps we should leave the palette in the packets fixed
at 256 entries (1024 bytes), since it's somewhat irrelevant whether this
"internal" palette contains 256 or less entries. It's when writing the files
that the number of palette entries becomes important.
That is the intention. How many palette entries are saved in the format
is up to the format (many QT formats for example don't save one at all
but instead refer to standard ones if possible).
Also there would be a (minor) advantage if shorter palettes were required
to be repeated in those 256 byte entries.
It would save on bit masking when expanding to a non-paletted format.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Yes, Reimar. I suppose that's the intent, and we agree on the file
format determining the number of entries that will be written to the
file for each bit depth.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel