summaryrefslogtreecommitdiffstats
path: root/video
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-11-28 15:10:45 +0100
committerwm4 <wm4@nowhere>2013-11-28 15:20:33 +0100
commitdc0b2046cdeb0bbf78e7012d9eafa29a2888b1ec (patch)
treee8fdb97e22f2ef067ded7f53a9b21153432b998e /video
parentd9b5dedfe95dc9b24e6c59c33044396187918bc2 (diff)
downloadmpv-dc0b2046cdeb0bbf78e7012d9eafa29a2888b1ec.tar.bz2
mpv-dc0b2046cdeb0bbf78e7012d9eafa29a2888b1ec.tar.xz
video: add insane hack to work around FFmpeg/Libav insanity
So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
Diffstat (limited to 'video')
-rw-r--r--video/decode/dec_video.c11
1 files changed, 8 insertions, 3 deletions
diff --git a/video/decode/dec_video.c b/video/decode/dec_video.c
index 1ec0bab241..bfdeb2c3a7 100644
--- a/video/decode/dec_video.c
+++ b/video/decode/dec_video.c
@@ -262,9 +262,12 @@ static double retrieve_sorted_pts(struct dec_video *d_video, double codec_pts)
d_video->num_unsorted_pts_problems++;
d_video->unsorted_pts = codec_pts;
- if (opts->user_pts_assoc_mode)
+ if (d_video->header->video->avi_dts) {
+ // Actually, they don't need to be sorted, we just reuse the buffering.
+ d_video->pts_assoc_mode = 2;
+ } else if (opts->user_pts_assoc_mode) {
d_video->pts_assoc_mode = opts->user_pts_assoc_mode;
- else if (d_video->pts_assoc_mode == 0) {
+ } else if (d_video->pts_assoc_mode == 0) {
if (codec_pts != MP_NOPTS_VALUE)
d_video->pts_assoc_mode = 1;
else
@@ -292,7 +295,9 @@ struct mp_image *video_decode(struct dec_video *d_video,
int drop_frame)
{
struct MPOpts *opts = d_video->opts;
- bool sort_pts = opts->user_pts_assoc_mode != 1 && opts->correct_pts;
+ bool sort_pts =
+ (opts->user_pts_assoc_mode != 1 || d_video->header->video->avi_dts)
+ && opts->correct_pts;
double pkt_pts = packet ? packet->pts : MP_NOPTS_VALUE;
double pkt_dts = packet ? packet->dts : MP_NOPTS_VALUE;