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

Mats Peterson matsp888 at yahoo.com
Sat Feb 27 14:58:39 CET 2016


On 02/27/2016 02:55 PM, Mats Peterson wrote:
> 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
>

And yes, QuickTime has a "default palette" for each bit depth that it 
can use, and no palette will be stored in the video sample description 
in that case. But that's only sensible to use for 1 bpp black & white or 
8 bpp grayscale (and that's what I'm doing in movenc.c), since in other 
cases comparing each color of the current palette with the default 
Macintosh palette is a bit of overkill in my book.

Mats

-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


More information about the ffmpeg-devel mailing list