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".