On 1/20/14, Janne Grunau <janne-li...@jannau.net> 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 libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel