path: root/common
diff options
authorwm4 <wm4@nowhere>2016-10-18 16:56:50 +0200
committerwm4 <wm4@nowhere>2016-10-18 16:57:02 +0200
commitb86a2316df260de70012fb05dbddf06118b00611 (patch)
tree5c6e4423cd7b99e6b0d2a481337628f1551a9482 /common
parent912d668ea892285c142b52534177f70fe2a7ba28 (diff)
demux_lavf: "support" mov edit lists and log errors if used
FFmpeg recently got "support" for mov edit lists. This is a terrible hack that will fail completely at least with some decoders (in particular wrappers for hardware decoding might be affected). As such it makes no point to pretend they are supported, even if we assume that the "intended" functionality works, that there are no implementation bugs (good luck with all that messy code added to the already huge mov demuxer), and that it covers enough of the mov edit list feature to be of value. So log an error if the FFmpeg code for mov edit lists appears to be active - AV_PKT_FLAG_DISCARD is used only for "clipping" edit list segments on non-key frame boundaries. In the first place, FFmpeg committed this only because Google wanted it in, and patch review did not even pick up obvious issues. (Just look how there was no lavc version bump when AV_PKT_FLAG_DISCARD was added.) We still pass the new packet flag to the decoders (av_common.c change), which means we "support" FFmpeg's edit list code now. (Until it breaks due to FFmpeg not caring about all the details.)
Diffstat (limited to 'common')
1 files changed, 1 insertions, 0 deletions
diff --git a/common/av_common.c b/common/av_common.c
index 3a424b0c62..95c6947eb7 100644
--- a/common/av_common.c
+++ b/common/av_common.c
@@ -160,6 +160,7 @@ void mp_set_av_packet(AVPacket *dst, struct demux_packet *mpkt, AVRational *tb)
dst->side_data_elems = mpkt->avpacket->side_data_elems;
if (dst->data == mpkt->avpacket->data)
dst->buf = mpkt->avpacket->buf;
+ dst->flags |= mpkt->avpacket->flags;
if (mpkt && tb && tb->num > 0 && tb->den > 0)
dst->duration = mpkt->duration / av_q2d(*tb);