Opened 5 months ago

Last modified 5 months ago

#7222 new defect

inaccurate -ss seek

Reported by: ryonsabouni Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: -ss before input seeks accurately for audio, not video. Seeks forward but output has same length as input with the final video frame "frozen" for however many seconds were seeked forward.
How to reproduce:

% ffmpeg -ss 00:00:03 -i input.mp4 -c copy output.mp4

Attachments (3)

input.mp4 (2.3 MB) - added by ryonsabouni 5 months ago.
output.mp4 (2.3 MB) - added by ryonsabouni 5 months ago.
ffmpeg-20180521-145006.log (93.5 KB) - added by ryonsabouni 5 months ago.

Change History (13)

Changed 5 months ago by ryonsabouni

Changed 5 months ago by ryonsabouni

Changed 5 months ago by ryonsabouni

comment:1 Changed 5 months ago by cehoyos

  • Priority changed from critical to normal

comment:2 follow-ups: Changed 5 months ago by mkver

  • Priority changed from normal to critical
  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.

comment:3 Changed 5 months ago by mkver

  • Priority changed from critical to normal

Sorry, I saw that cehoyos changed the priority, but I was unaware that sending my answer would restore the priority to what it was at the time that I started my answer.

Last edited 5 months ago by mkver (previous) (diff)

comment:4 Changed 5 months ago by ryonsabouni

Last edited 5 months ago by ryonsabouni (previous) (diff)

comment:5 Changed 5 months ago by ryonsabouni

Last edited 5 months ago by ryonsabouni (previous) (diff)

comment:6 Changed 5 months ago by ryonsabouni

Ok so the error here is that the movie header box has the incorrect length. I understand your explanations and was able to draw some of the same conclusions using ffprobe. Is setting the length in the movie header box something that is done by ffmpeg? If so, then this seems to be a slight bug with ffmpeg. Is that an error that can be fixed or am I misunderstanding something here?

Last edited 5 months ago by ryonsabouni (previous) (diff)

comment:7 in reply to: ↑ 2 Changed 5 months ago by ryonsabouni

Replying to 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.

comment:8 in reply to: ↑ 2 Changed 5 months ago by ryonsabouni

Last edited 5 months ago by ryonsabouni (previous) (diff)

comment:9 Changed 5 months ago by mkver

FFmpeg/Lavf created output.mp4 and this of course includes the the length field in header. Of course this is potentially fixable. But don't think that this will fix the other players.
Oh, and the situation is actually a little bit different than I said. There are more duration fields than I have mentioned: Each track has a duration field in the track header box; both of them indicate a length of 30s (all numbers are rounded), although these duration fields should be equal to the sum of the durations of the edits in the edit lists (which indicate 27s). That the overall movie header duration indicates 30s is only consequential.

Last edited 5 months ago by mkver (previous) (diff)

comment:10 Changed 5 months ago by ryonsabouni

Hmm so seems like the edits lists aren't being accounted for correctly

Note: See TracTickets for help on using tickets.