On Monday, January 20, 2014, Sean McGovern <[email protected]> wrote: > 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. >
I should really check my facts better before clicking Send -- the failure I've been seeing on this test is not via valgrind. Its the one I documented in Bugzilla #552. -- Sean McG. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
