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@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/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
