[FFmpeg-trac] #7222(undetermined:new): inaccurate -ss seek

[FFmpeg]

#7222: inaccurate -ss seek
-------------------------------------+-------------------------------------
             Reporter:  ryonsabouni  |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by ryonsabouni):

 Replying to [comment:2 mkver]:
 > 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:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker