Codecs call ff_find_unused_picture() to get the index of
an unused picture; said picture may have buffers left
from using it previously (these buffers are intentionally
not unreferenced so that it might be possible to reuse them;
this is mpegvideo's version of a bufferpool). They should
not make any assumptions about which picture they get.
Yet somehow this is not true when decoding OBMC: Returning
random empty pictures (instead of the first one) leads
to nondeterministic results; similarly, explicitly
rezeroing the buffer before handing it over to the codec
changes the outcome of the h263-obmc tests, but it makes it
independent of the returned pictures. Therefore this commit
does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
---
libavcodec/mpegpicture.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 88b4d5dec1..06c82880a8 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -245,6 +245,10 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic,
MotionEstContext *me,
for (i = 0; i < 2; i++) {
pic->motion_val[i] = (int16_t (*)[2])pic->motion_val_buf[i]->data
+ 4;
pic->ref_index[i] = pic->ref_index_buf[i]->data;
+ /* FIXME: The output of H.263 with OBMC depends upon
+ * the earlier content of the buffer; therefore we
+ * reset it here. */
+ memset(pic->motion_val_buf[i]->data, 0,
pic->motion_val_buf[i]->size);
}
}
--
2.40.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
