When a frame_num gap has no earlier reference to copy from, the dummy picture is left holding whatever the frame buffer it was allocated from contained, unless the stream has not recovered yet. It is entered into short_ref either way, so it is predicted from, and the decoded output then depends on which buffer the allocator handed out.
That is observable: seeking into an MVC stream and decoding both views gave different pictures for -threads 1 and for frame threading, deterministically and identically for every thread count above one, because the number of decoding contexts changes which buffers get reused. Fill it in all cases. Base view output is unchanged on the test corpus across seek points and threading modes. Signed-off-by: Dom Cobley <[email protected]> --- libavcodec/h264_slice.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index 9b5ed8f77e..a042616f7b 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -1568,7 +1568,12 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl, ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0); if (h->short_ref[0]->field_picture) ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1); - } else if (!h->frame_recovered) { + } else { + /* No picture to conceal from: the buffer this dummy was just + * allocated from holds whatever the last user left in it, and it + * is about to be predicted from, so it has to be initialised. + * Skipping this once the stream had recovered made the decoded + * output depend on allocator reuse. */ if (!h->avctx->hwaccel) color_frame(h->short_ref[0]->f, c); h->short_ref[0]->gray = 1; -- 2.53.0 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
