On 01/04/14 02:20, Vittorio Giovara wrote: > On Mon, Mar 31, 2014 at 8:46 PM, wm4 <[email protected]> wrote: >> The only interesting parts are initialization in ff_MPV_common_init and >> uninitialization in ff_MPV_common_end. >> >> ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL >> checks for Picture.f, because these functions can be called on >> uninitialized or partially initialized Pictures. >> --- >> Depends on: >> >> [libav-devel] [PATCH] dxva2: don't assume Picture and H264Picture are the >> same >> >> dxva untested. >> --- >> libavcodec/dxva2_mpeg2.c | 8 +- >> libavcodec/dxva2_vc1.c | 8 +- >> libavcodec/h261dec.c | 10 +-- >> libavcodec/h263dec.c | 18 ++-- >> libavcodec/intrax8.c | 22 ++--- >> libavcodec/motion_est.c | 22 ++--- >> libavcodec/mpeg12dec.c | 34 +++---- >> libavcodec/mpeg12enc.c | 10 +-- >> libavcodec/mpeg4videoenc.c | 12 +-- >> libavcodec/mpegvideo.c | 185 ++++++++++++++++++++------------------ >> libavcodec/mpegvideo.h | 2 +- >> libavcodec/mpegvideo_enc.c | 200 >> +++++++++++++++++++++--------------------- >> libavcodec/mpegvideo_motion.c | 10 +-- >> libavcodec/mpegvideo_xvmc.c | 12 +-- >> libavcodec/msmpeg4.c | 4 +- >> libavcodec/mss2.c | 2 +- >> libavcodec/pthread_frame.c | 2 +- >> libavcodec/ratecontrol.c | 10 +-- >> libavcodec/rv10.c | 6 +- >> libavcodec/rv30.c | 8 +- >> libavcodec/rv34.c | 14 +-- >> libavcodec/rv40.c | 4 +- >> libavcodec/svq1enc.c | 10 +-- >> libavcodec/vaapi.c | 2 +- >> libavcodec/vaapi_mpeg2.c | 4 +- >> libavcodec/vaapi_mpeg4.c | 6 +- >> libavcodec/vaapi_vc1.c | 4 +- >> libavcodec/vc1.c | 2 +- >> libavcodec/vc1dec.c | 134 ++++++++++++++-------------- >> libavcodec/vdpau.c | 2 +- >> libavcodec/vdpau_mpeg12.c | 4 +- >> libavcodec/vdpau_mpeg4.c | 4 +- >> libavcodec/vdpau_vc1.c | 4 +- >> 33 files changed, 399 insertions(+), 380 deletions(-) > > Very cool and very complete. As far as I could tell the only place in > lavc where a static avframe is used is in utils for deprecated stuff > and in h264 which definitely warrants a separate patch. I'm sending > this on oracle for a spin.
I can't reproduce the oracle failure with gcc-asan 4.8 and clang-asan 3.4. So it seems safe. > Thanks > _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
