On 02/26/2016 06:40 AM, Mats Peterson wrote:
On 02/26/2016 06:24 AM, Mats Peterson wrote:
On 02/26/2016 05:26 AM, Mats Peterson wrote:
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
Not that I understand why. I thought the palette was already in
"big-endian" order, with the A, R, G, B bytes in that order, and that
the previous patch would rather fail instead, so to say. But alright.
Mats
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
After applying this patch, would you like to try "ffmpeg -i 8bpp_129.mov
-vcodec rawvideo out.mov" with the file below on that mips machine, just
to see that nothing is wrong with the palette storage on the demuxer
side?
https://drive.google.com/open?id=0B3_pEBoLs0fabUdRcTVxRl9yVWM
Mats
Look at this snippet from libavformat/qtpalette.c that stores a palette
entry (palette[] is uint32_t):
palette[i] = (a << 24 ) | (r << 16) | (g << 8) | (b);
The way it is stored in memory is obviously dependent on the endianness
of the machine. For little-endian machines, it will be BGRA, and for
big-endian ones ARGB.
Mats
This shouldn't have any relevance, though. Something is possibly wrong
with the palette storage endian-wise when converting that matrix file
from yuv420p to pal8.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
