On 02/26/2016 01:16 PM, Mats Peterson wrote:
On 02/26/2016 08:34 AM, Mats Peterson wrote:
On 02/26/2016 08:28 AM, Mats Peterson wrote:
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Forget this one as well. Using AV_RL32() shouldn't be needed, since the
palette is already stored in host byte order as far as I know. And I
don't understand whatsoever why it will fail on a big-endian machine,
Michael.
Mats
Snippet from avidec.c:
ast->pal[i] = 0xFFU<<24 | AV_RL32(pal_src+4*i);
And from qtpalette.c (mov and matroska):
palette[i] = (a << 24 ) | (r << 16) | (g << 8) | (b);
Something obviously goes wrong when storing the palette during yuv420p
to pal8 conversion of that matrix file.
Mats
Michael, with v26 of my patch applied, have you tried "ffmpeg -i
8bpp_129.mov -vcodec rawvideo out.mov" on that mips machine? Does that
one work? If so, there's clearly something wrong with the palette
storage endian-wise during yuv240p to pal8 conversion.
Mats
If it doesn't work, where in the chain from demuxing to muxing does the
palette suddenly change endianness on a big-endian machine? I mean since
it works perfectly on a little-endian one.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
