[FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Mats Peterson]

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 at 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/