inaccurate -ss seek

[ryonsabouni]

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

[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.

[mkver]

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.

[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.

[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.

[ryonsabouni]

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