[FFmpeg-cvslog] r25066 - trunk/libavcodec/imgconvert.c
Måns Rullgård
mans
Fri Sep 10 17:36:19 CEST 2010
Vitor Sessak <vitor1001 at gmail.com> writes:
> On 09/07/2010 11:23 PM, stefano wrote:
>> Author: stefano
>> Date: Tue Sep 7 23:23:52 2010
>> New Revision: 25066
>>
>> Log:
>> Reimplement av_picture_data_copy() avoiding the use of PixFmtInfo
>> information.
>
> This commit introduced an invalid read in the fate-lavf-pixfmt test,
> see for example
> http://fate.ffmpeg.org/x86_32-linux-gcc-valgrind/20100910052959 .
The error is caused by the pixdesc for PIX_FMT_GRAY8 quite dishonestly
claiming it has a palette when in fact it has nothing of the kind:
[PIX_FMT_GRAY8] = {
.name = "gray",
.nb_components= 1,
.log2_chroma_w= 0,
.log2_chroma_h= 0,
.comp = {
{0,0,1,0,7}, /* Y */
},
.flags = PIX_FMT_PAL,
},
Compare this with the descriptor in imgconvert.c:
[PIX_FMT_GRAY8] = {
.nb_channels = 1,
.color_type = FF_COLOR_GRAY,
.pixel_type = FF_PIXEL_PLANAR,
.depth = 8,
},
Prior to this commit, av_picture_data_copy() used the imgconvert.c
descriptor, which is accurate. After this change, it uses the pixdesc
version, and attempts to copy a non-existing palette.
Why the FUCK do all 8-bit pixel formats claim they have a palette?
The code is full of hacks to skip the palette for these formats,
except for here. Isn't about time we fixed this nonsense once and for
all?
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-cvslog
mailing list