On 1/20/14, Janne Grunau <[email protected]> wrote:
> On 2014-01-20 15:27:46 +0100, Anton Khirnov wrote:
>> The default get_buffer2() implementation (and possibly some
>> user ones) does not allocate edges when this flag is set, which may
>> expose bugs in some decoders. Until the 10 release is out, it is safer
>> to remove this part.
>> ---
>> libavcodec/utils.c | 5 -----
>> 1 file changed, 5 deletions(-)
>>
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index 2e418ec..044413a 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1091,11 +1091,6 @@ int attribute_align_arg
>> avcodec_open2(AVCodecContext *avctx, const AVCodec *code
>> ret = AVERROR(EINVAL);
>> goto free_and_end;
>> }
>> -
>> -#if FF_API_EMU_EDGE
>> - /* force the emu edge flag on, since it's now always active */
>> - avctx->flags |= CODEC_FLAG_EMU_EDGE;
>> -#endif
>> }
>> end:
>> entangled_thread_counter--;
>
> Fix for the h264 fate failure sent. Do you still want this committed as
> protection against possible other bugs? fate-h264 seems to pass here now
> with AddressSanitizer. One thing I've noticed though is that the default
> get_buffer2() doesn't even allocate a little padding at the end of a
> picture plane. I think at least some NEON code can read past the image.
>
> Janne
It would not surprise me if AltiVec is similarly affected.
This test has been failing on all the valgrind FATE stations (ppc64
and x86_{32,64}) for quite some time now -- but I suspect for
different reasons.
-- Sean McG.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
