On 03/02/2016 11:19 PM, Mats Peterson wrote:
On 03/02/2016 11:07 PM, Mats Peterson wrote:
On 03/02/2016 10:30 PM, Michael Niedermayer wrote:
+ ret = 0;
+ if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 &&
!trk->pal_done) {
+ const uint8_t *pal;
+ int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
+ if (ret2 < 0)
+ return ret2;
+ if (pal) {
+ memcpy(trk->palette, pal, AVPALETTE_SIZE);
this fails on big endian
AV_PKT_DATA_PALETTE is stored in cpu endianness
in general AVPacket->data is defined byte per byte and can be stored
as is byte per byte
AVPacket->side_data is in whatever endianness
people preferred at the time a specific AV_PKT_DATA_* was added.
in case of AV_PKT_DATA_PALETTE its native cpu endianness
Messy! But alright, thanks for the info.
I just don't understand why the palette when stored in AVPacket->data is
in little-endian format when it is stored byte by byte. And I can't find
the place where this is done. It would be more logical to use big-endian
format.
I'm making an all new patch set, since there are several things to be
fixed, including ff_get_packet_palette().
Mats
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
