Hi, On Mon, Apr 3, 2017 at 10:24 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote:
> This tries to handle cases where separate invocations of decode_frame() > (each running in separate threads) write to respective fields in the > same AVFrame->data[]. Having per-field owners makes interaction between > readers (the referencing thread) and writers (the decoding thread) > slightly more optimal if both accesses are field-based, since they will > use the respective producer's thread objects (mutex/cond) instead of > sharing the thread objects of the first field's producer. > > In practice, this fixes the following tsan-warning in fate-h264: > > WARNING: ThreadSanitizer: data race (pid=21615) > Read of size 4 at 0x7d640000d9fc by thread T2 (mutexes: write M1006): > #0 ff_thread_report_progress pthread_frame.c:569 > (ffmpeg:x86_64+0x100f7cf54) > [..] > Previous write of size 4 at 0x7d640000d9fc by main thread (mutexes: > write M1004): > #0 update_context_from_user pthread_frame.c:335 > (ffmpeg:x86_64+0x100f81abb) > --- > libavcodec/h264_slice.c | 8 +++++--- > libavcodec/pthread_frame.c | 18 ++++++++++-------- > libavcodec/thread.h | 2 +- > libavcodec/utils.c | 7 ++++--- > 4 files changed, 20 insertions(+), 15 deletions(-) > Ping. (I realize this patch is probably very hard to review, but I'd really appreciate a second set of eyes/brains on my proposed solution, exactly because it's hard - and also because it touches a very fundamental core element of frame-mt design.) Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
