[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