On 02/27/2016 04:07 PM, Mats Peterson wrote:
On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
On 02/27/2016 03:37 PM, Mats Peterson wrote:
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I suppose this is what you mean, Reimar. Treating the palette, if a
packet
contains one at the end of the video data, as being AVPALETTE_SIZE bytes
exclusively.
Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anyway, I have accepted the facts. For
the record, the new ff_reshuffle_raw_rgb() function written by Michael
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
will set a CONTAINS_PAL flag if the packet size is larger than the
actual video data. He has hardcoded the palette size to 1024 bytes in
that file.
Mats
The nut format stores the PALETTE after the video data in the packets,
nothing else :)
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
