On 17.10.2019 23:59, James Almer wrote:
On 10/17/2019 6:43 PM, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.

Should effectively fix ticket #8300.

Signed-off-by: James Almer <jamr...@gmail.com>
---
   libavcodec/libdav1d.c | 21 ++++++++++++++++++++-
   1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 8aa248e6cd..87abdb4569 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -191,6 +191,24 @@ static int libdav1d_receive_frame(AVCodecContext
*c, AVFrame *frame)
                 pkt.buf = NULL;
               av_packet_unref(&pkt);
+
+            if (c->reordered_opaque != AV_NOPTS_VALUE) {
+                AVBufferRef *reordered_opaque =
av_buffer_alloc(sizeof(c->reordered_opaque));
+
+                if (!reordered_opaque) {
+                    dav1d_data_unref(data);
+                    return AVERROR(ENOMEM);
+                }
+
+                *reordered_opaque->data = c->reordered_opaque;

This slices int64_t to uint8_t. Should memcpy instead.

Good catch. Changed locally to

*(int64_t *)reordered_opaque->data = c->reordered_opaque;

Doesn't that violate strict aliasing rules?
I'd just use memcpy.
_______________________________________________
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".

Reply via email to