Hi Ronald,
Thank you for the reply.
On Wed, Jul 19, 2017 at 8:56 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote:
> Hi,
>
> On Wed, Jul 19, 2017 at 12:26 AM, Wan-Teh Chang <
> wtc-at-google....@ffmpeg.org> wrote:
>
>> WARNING: ThreadSanitizer: data race (pid=116081)
>> Read of size 4 at 0x7b7000020118 by thread T3 (mutexes: write M2239):
>> #0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
>> (ffmpeg+0x1159c60)
>>
> [..]
>
>> Previous write of size 4 at 0x7b7000020118 by thread T1 (mutexes:
>> write M2234):
>> #0 ff_h264_decode_mb_cabac ffmpeg/libavcodec/h264_cabac.c:2386:31
>> (ffmpeg+0x1475e0a)
>
> I believe this is temporal motion vector prediction (so MV from frame 1 is
> used as a MV predictor in frame 2). The easy solution here is to wait for
> the frame to have completed reconstruction of that block (which fills in
> that mb_type) before accessing the predictor.
In libavcodec/h264_direct.c, there is already an
await_reference_mb_row() call before the read of
sl->ref_list[1][0].parent->mb_type[mb_xy] at line 505:
487 static void pred_temp_direct_motion(const H264Context *const h,
H264SliceCon text *sl,
488 int *mb_type)
489 {
...
501
502 await_reference_mb_row(h, &sl->ref_list[1][0],
503 sl->mb_y + !!IS_INTERLACED(*mb_type));
504
505 if (IS_INTERLACED(sl->ref_list[1][0].parent->mb_type[mb_xy]))
{ // AFL/A FR/FR/FL -> AFL/FL
This seems like the wait you suggested, but I guess it is not?
I also found that there is a similar tsan warning about a data race
between libavcodec/h264_direct.c and libavcodec/h264_cavlc.c:
WARNING: ThreadSanitizer: data race (pid=115630)
Read of size 4 at 0x7b7000030118 by thread T2 (mutexes: write M2283):
#0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
(ffmpeg+0x1159c60)
#1 ff_h264_pred_direct_motion ffmpeg/libavcodec/h264_direct.c:727
(ffmpeg+0x1159c60)
#2 ff_h264_decode_mb_cavlc ffmpeg/libavcodec/h264_cavlc.c:856:17
(ffmpeg+0x11520b2)
#3 decode_slice ffmpeg/libavcodec/h264_slice.c:2641:19 (ffmpeg+0x11936ea)
#4 ff_h264_execute_decode_slices
ffmpeg/libavcodec/h264_slice.c:2748:15 (ffmpeg+0x1192377)
#5 decode_nal_units ffmpeg/libavcodec/h264dec.c:716:27 (ffmpeg+0x792022)
#6 h264_decode_frame ffmpeg/libavcodec/h264dec.c:1006 (ffmpeg+0x792022)
#7 frame_worker_thread ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56cc)
Previous write of size 4 at 0x7b7000030118 by thread T4 (mutexes:
write M2289):
#0 ff_h264_decode_mb_cavlc ffmpeg/libavcodec/h264_cavlc.c:1095:31
(ffmpeg+0x114f2be)
#1 decode_slice ffmpeg/libavcodec/h264_slice.c:2641:19 (ffmpeg+0x11936ea)
#2 ff_h264_execute_decode_slices
ffmpeg/libavcodec/h264_slice.c:2748:15 (ffmpeg+0x1192377)
#3 decode_nal_units ffmpeg/libavcodec/h264dec.c:716:27 (ffmpeg+0x792022)
#4 h264_decode_frame ffmpeg/libavcodec/h264dec.c:1006 (ffmpeg+0x792022)
#5 frame_worker_thread ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56cc)
Wan-Teh Chang
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
