diff options
author | wm4 <wm4@nowhere> | 2016-02-11 16:01:11 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2016-02-11 16:14:30 +0100 |
commit | d3f32cba32d0cd5a46af00b2c176b177de36e074 (patch) | |
tree | e49f5f691dab25426e976ffa92c614bf93b20014 /stream/stream_lavf.c | |
parent | eff2e575f1d83f7fae2b4e2270ee20671e5d7107 (diff) |
video: approximate AVI timestamps via DTS handling
Until now (and in mplayer traditionally), avi timestamps were handled
with a timestamp FIFO. AVI timestamps are essentially just strictly
increasing frame numbers and are not reordered like normal timestamps.
Limiting the FIFO is required because frames can be dropped. To make
it worse, frame dropping can't be distinguished from the decoder not
returning output due to increasing the buffering required for B-frames.
("Measuring" the buffering at playback start seems like an interesting
idea, but won't work as the buffering could be increased mid-playback.)
Another problem are skipped frames (packets with data, but which do
not contain a video frame).
Besides dropped and skipped frames, there is the problem that we can't
always know the delay. External decoders like MMAL are not going to
tell us. (And later perhaps others, like direct VideoToolbox usage.)
In general, this works not-well enough that I prefer the solution of
passing through AVI timestamps as DTS. This is slightly incorrect,
because most decoders treat DTS as mpeg-style timestamps, which
already include a b-frame delay, and thus will be shifted by a few
frames. This means there will be a problem with A/V sync in some
situations.
Note that the FFmpeg AVI demuxer shifts timestamps by an additional
amount (which increases after the first seek!?!?), which makes the
situation worse. It works well with VfW-muxed Matroska files, though.
On RPI, the first X timestamps are broken until the MMAL decoder "locks
on".
Diffstat (limited to 'stream/stream_lavf.c')
0 files changed, 0 insertions, 0 deletions