ffmpeg cutting: how to get negative start time?

[Luke M]

I'm cutting AVC video with this command (ffmpeg 4.0):

ffmpeg -ss 48:07 -to 56:45 -i input.mkv -c copy output.mkv

This cuts at the nearest preceding key frame, which is fine. But the starting time is 0.0. From various tutorials, I expected the start time to be negative (unless avoid_negative_ts option is used), which should cause players to perform a seek to 0.0 (skipping the unwanted video between the key frame and the -ss position).

Is my understanding wrong, or did ffmpeg behavior change, or...? How do I get a negative starting time?

[Budman1]

It did change some time back. FFprobe used to display the start as a negative value up to the cut point, at which time it changed to the 0.000000 time. Recent versions display the start as 0.000000 up to the cut point which is a positive value now. For the most part, players handle -5.000000------>-4.000000----------------->0.000000---------->+2.000000 as well as with +0.000000------>+1.000000----------------->+5.000000---------->+7.000000
The problem arises if you try to join or edit further.

I usually use Zeranoes FFmpeg but I downloaded FFmpeg 4.0.1 to test and it does note the start frame as 0.00000 and APPEARS to play from the preceding I-Frame (key Frame) but if you check the full information that 0.00000 is not an I-Frame:

FFmpeg -ss 325 -to 328 -i ClosedGop.mp4 -c copy output.mp4

No. pts_time type
0 0.000000 0 B <---Cut point 325
1 0.033367 0 B
2 0.066733 0 P

61 2.035369 0 P
62 2.068735 0 P
63 2.102102 1 I <---327.127127
64 2.135469 0 B
65 2.168836 0 P
66 2.202202 0 P

Notice 63 full frames (29.97 FPS-->0.033367*63=2.102121) (325+2.102121=327.102121) is almost the exact position of the real NEXT I-Frame after cut point. So the video was cut at exact frame value but somehow plays longer. Again, it may or may not play in certain players and may or may not cause issues if you join it to itself several times, since any audio sync problems are cumulative after joining cut segments..

It gets even weirder if you use -to or -vframes as an Output option. First -to must be referenced as distance from -SS because recent versions made -SS input option reset the Timestamp to Zero (0.000000). In this case -t and -to are basically the same.

BOTH cases below have a Key Frame at 327.127127

ffmpeg -ss 327.127127 -i cgop.mp4 -to 8.341750 -c copy output.mp4

will play a 16 second video (even though it is supposed to be 8.341750 seconds long) from approximately the 318.785452 I-Frame up to the 335.468802 I-Frame. But FFprobe reports it as 8+ seconds

ffmpeg -i cgop.mp4 -ss 327.127127 -t 8.341750 -c copy output.mp4

will play a freeze frame 8 second video frozen on 335.468802 image

There is a method that I will post later after I get it written up, where you can use a peculiar method to cut EXACTLY at a Key Frame using -c copy and then reset the timestamp to 0, if necessary, with no loss of sync that I have found so far. Otherwise the results are different depending on where you cut between Key Frames.

Using FFprobe to get the exact frame timestamp and then trying to cut from exactly on the I-Frame and then each preceding frame, frame by frame before the Key yields drastically different different almost every time. The only stable effect is -SS as Input or Output option are basically frame accurate (input reset timestamp to 0.000000) and Input seeks to the PRECEDING Key Frame and Output seeks to the FOLLOWING Key Frame.


I know... long winded answer given but short answer is yes it was changed for a fact because I had two different version in different location on my computer and it caused me no end of trouble trying to figure out why the timestamp was positive one time and negative another when I used the same script. I finally realized it depended on which folder I ran my test in.