[FFmpeg-cvslog] r25066 - trunk/libavcodec/imgconvert.c

Måns Rullgård mans
Tue Sep 21 16:05:08 CEST 2010


Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:

> On date Tuesday 2010-09-21 14:28:42 +0100, M?ns Rullg?rd wrote:
>> Vitor Sessak <vitor1001 at gmail.com> writes:
>> 
>> > On 09/20/2010 08:50 PM, M?ns Rullg?rd wrote:
>> >> Vitor Sessak<vitor1001 at gmail.com>  writes:
>> >>
>> >>> On 09/10/2010 04:25 PM, Vitor Sessak wrote:
>> >>>> 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 .
>> >>>
>> >>> Any progress on this regression?
>> >>
>> >> Only of the bikeshed variety, which is quite sad.
>> >
>> > Don't we have a policy of reverting commits that introduce
>> > regressions? Stefano?
>> 
>> I'd prefer fixing it properly rather than revert&forget.
>
> +1
>
> I confess that I didn't check, so I'm not yet sure where the problem
> is.
>
> Also this commit may be relevant:
>
> Author: stefano <stefano at 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
> Date:   Thu Mar 4 00:27:46 2010 +0000
>
>     Declare the PIX_FMT_GRAY8 pixel format as a paletted format.  This is
>     consistent with the allocation currently done for PIX_FMT_GRAY8
>     pictures.
>
>     No significant slow-downs have been measured.
>
>     See the thread:
>     Subject: [FFmpeg-devel] [PATCH] Is gray8 a paletted format?
>     Date: Sun, 15 Nov 2009 23:36:03 +0100
>
>     git-svn-id: svn://svn.ffmpeg.org/ffmpeg/trunk at 22191 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b
>
> and I can barely remember the reason of the gray8=PAL thing.

It seems that if anyone is able to remember or understand this bizarre
state of affairs, they are unwilling to explain it to the rest of us.

Whatever the reason may be, we need to fix this mess properly once and
for all, or else this bug will only resurface again at some later time
when the next person fails to imagine anything could be so absurd.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-cvslog mailing list