[FFmpeg-trac] #7222(undetermined:new): inaccurate -ss seek
FFmpeg
trac at avcodec.org
Tue May 22 01:51:27 EEST 2018
#7222: inaccurate -ss seek
-------------------------------------+-------------------------------------
Reporter: ryonsabouni | Owner:
Type: defect | Status: new
Priority: critical | Component:
Version: git-master | undetermined
Keywords: | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Changes (by mkver):
* priority: normal => critical
Comment:
1. For video tracks, the first frame (in decoding order) must (usually) be
a keyframe (there are cases like periodic-intra-refresh where this is not
so, but we can ignore them here). Therefore one generally can't cut the
stream as one wishes. Your file has a keyframe interval of about 5s, so in
general if the user wants to have the first 3s of video cut off, one can
discard all the video up to 5s or nothing at all.
2. But some containers like mp4/mov have a feature (called edit lists)
that makes accurate cutting possible: One keeps all the data of the video
track beginning with the keyframe preceding the desired point and writes
in the edit list that a part of the video should be decoded, but not
output. This is what ffmpeg did during the remuxing: It simply added an
edit list for both the video track and audio tracks stating that
presentation should begin at 3s and lasting for 27s. The problem with this
approach is that it only works if the player actually handles the edit
list correctly. A quick test shows that MPC-HC shows the full 30s of video
with audio being silent for the first three seconds; VLC shows a frame
that shouldn't be shown at all for a few seconds at the beginning. But
these are bugs in other players, not ffmpeg.
3. With ffplay (the only player supported here) the video of output.mp4
starts at 3s in the input file (timecode 3.003; number 180). If I reencode
output.mp4 everything's fine, too.
4. Btw: output.mp4 actually has some flaws:
a) The duration in the movie header box indicates a length of 30s,
although the duration should be the maximum of the duration of the tracks
in the file. Because of the edit lists, each track is only 27s long and
hence the same is true for their maximum.
b) All the audio data is still there and the first three seconds are
declared not to be played by an edit list, but one could save some bytes
by leaving them out in the first place.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7222#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list