[FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()

[Mats Peterson]

On 03/03/2016 07:22 AM, Mats Peterson wrote:
> On 03/03/2016 07:15 AM, Mats Peterson wrote:
>> On 03/03/2016 06:52 AM, Mats Peterson wrote:
>>> On 03/03/2016 06:39 AM, Mats Peterson wrote:
>>>> On 03/03/2016 06:33 AM, Mats Peterson wrote:
>>>>> On 03/03/2016 03:05 AM, Michael Niedermayer wrote:
>>>>>> with this API each muxer must convert the palette from native endian
>>>>>> to whatever the format requires
>>>>>> feels a bit odd to extact the palette from AVPacket.data where its
>>>>>> stored as the container needs (for some containers) and then
>>>>
>>>> Exactly for the reason that the AVPacket.data is stored in
>>>> "container-specific" (exclusively little-endian, i hope) format, it has
>>>
>>> Well, exclusively little-endian in the case of raw nut, at least. That's
>>> the only format that appends the palette to the video data in each frame
>>> in the file, as far as I know.
>>>
>>> Mats
>>>
>>> _______________________________________________
>>
>> By the way, would you mind telling me why the palette in AVPacket.data
>> is always little endian (regardless of using nut or not)? And where in
>> FFmpeg is conversion from native endian to little endian done?
>>
>> Mats
>>
>> _______________________________________________
>
> I found it in av_image_copy_to_buffer() in libavutil/imgutils.c. I
> suppose that's the right place:
>
> if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
>          uint32_t *d32 = (uint32_t *)dst;
>
>          for (i = 0; i<256; i++)
>              AV_WL32(d32 + i, AV_RN32(src_data[1] + 4*i));
>      }
> }
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


So much more logical to convert this fixed little-endian storage in 
AVPacket.data to native endian for use by the outside world.

Mats

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