Workable Key frame cutting/copying test

[Budman1]

There are literally tens of thousands of search hits, on the internet and on this site that suggest, infer, inform and mandate that videos must be cut with ffmpeg at Key Frames (I-Frame) or re-encoded. They all contain truth but ffmpeg does not act like you think. This is why after explanations, people complain of wrong size problems, sync problems, unplayable segments and more.

I am sure there are many here that can correct me and I welcome more information since I need more in order to automate this in a GUI application, already half done.

After extensive research I thought I'd give my findings to be refuted or further explained. I am doing this because I must find a way to correctly cut videos. I used a 29.97 FPS MP4 with a constant 250 frames, I-Frame to I-Frame, video and created a correct Closed GOP MP4 (CGOP.MP4) and an open GOP (OGOP.MP4) The frame format is CGOP -> (IBBBPBBBP...PBBPI). OGOP -> (IBBBPBBBP...PBBBI).

IMPORTANT: Notice the BBB preceding the I frame in the Open GOP that reference preceding B/P frames AND the following I frame, absent in the Closed GOP video. The Open GOP is still being reasearched since FFMPEG does not like to cut at exact boundays no matter what you specify for time/frames. What you get is PBBBP or PBBBPI or PBBBPPI or PBBBI, it will not end at a B frame for obviousd reasons (No following I frame to reference.)

I use automated batch files to run FFPROBE and FFMPEG (latest versions) for a listing of information. FFPROBE gives all Frame information which is then parsed to the needed items:

SUMMARY
No. pts_time type
9802 327.060394 0 P
9803 327.093760 0 P
9804 327.127127 1 I
9805 327.160494 0 B
9806 327.193861 0 P
...
10051 335.368702 0 P
10052 335.402069 0 B
10053 335.435435 0 P
10054 335.468802 1 I
10055 335.502169 0 B
10056 335.535536 0 B

KEY FRAMES
40 310.443777 I
41 318.785452 I
42 327.127127 I
43 335.468802 I
44 343.810477 I
45 352.152152 I

The segment I want to extract is 327.127127 - 335.435435 (10054-9804=250 frames). I use -vframes because I have found no combination or position of either -t or -to that works. Bear in mind, if you use -ss as an input option it resets the pts to 0 so your -t or -to means almost the same thing since you start counting at 0 not 327+. If you enter the I-Frame 327.127127 as either input or output option:

ffmpeg -i cgop.mp4 -ss 05:27.127127 -vframes 250 -c copy "text327.mp4"

I get a 16 second( not 8+ like it should be) that freezes frame 335.468802 for 8+ seconds with audio and then plays for the 8+ segment following the one intended. Thumbnail of first frame shows frame 335 not 327

ASSUMPTION: FFMPEGS -ss used as an output option apparently goes to the NEXT I frame because of any -t, -to, -vframe reference but takes it's start as the Previous I frame.

FFMPEG from the previous frame gives the same results:

ffmpeg -i cgop.mp4 -ss 05:27.093760 -vframes 250 -c copy "text327.mp4"

CORRECT METHOD:
set the FFMPEG -ss to the 2ND frame preceding the one you want (327.060394)

ffmpeg -i cgop.mp4 -ss 05:27.060394 -vframes 250 -c copy "text327.mp4"

This is partially correct except, the video is 8.342 seconds and and thumbnail is correct but the PTSSTART time is not 0 causing problems if you were to join it to itself (or any others you cut with the same issue). This amount will vary on different videos and I do not know why but in my case 2 frames gave a PTSSTART time of 0.065983. Earlier FFPROBE showed this as a Minus time and I believe it is because in order to correct this you have to enter -ss as an INPUT option and 'use it up'

You would think you can just add 0.065983 to 05:27:060394 but that is not the case. All tests I have done show there is a 0.001000 window or 1 MS within which that you can enter the -ss input time but I have not found how to determine this since the PTSSTART time varies video to video. There is a fix, however by taking 0.65983 and multiplying by .667 (2/3) and getting 0.044010 sneaking up on the constant FFMPEG apparently reserves. Specify this as an INPUT option in FFMPEG against the new file test327.mp4, which sets PTS to 0 instead of .044010 :

ffmpeg -ss 0.044010 -i test327.mp4 -vframes 250 -c copy "text327_final.mp4"

Using FFPROBE on Test327_final I found start PTS to be 0.006006. Now Add THIS to the previous gives:

ffmpeg -ss 0.050016 -i test327.mp4 -vframes 250 -c copy -y "text327_final.mp4"

Now i have a 250 frame 8+ second video with a STARTPTS of 0.000000 that can be joined to itself without pause or sync problems. This works with an automated batch file with MP4(264,AVC) MPG with IPPPPI format. Still working on TS and Open GOP files.

If anyone has information on the eluding issues or something I have wrong, Please, let me know. This methods works in all automated batches for me including extracting images with their timestamp embedded. I am attempting to automate in a GUI so the more I get right the easier it will be. Next is how to re-encode those nasty Open GOP B frames and frames cut prior to I-frames.

Thanks

[jagabo]

Maybe Selur can help you. He has a smart mkv cutter that uses ffmpeg. He may have dealt with the same issues...
https://forum.selur.net/showthread.php?tid=6

[Selur]

MKV Cutter isn't using ffmpeg.
+ Cutting at key frames worked fine the last time I used it, but I use '-noaccurate_seek' and specify as start time shortly before the key frame.
You might want to read https://trac.ffmpeg.org/wiki/Seeking#Cuttingsmallsections (read the whole thing not just the cutting part at the end).

As a side not cutting the source is the easy part when writing a smart cutter. Figuring out the settings that need to be used for the reencoding is the tricky part.

Cu Selur

[Budman1]

I am very interested in the inaccurate option. Did you use as as an input or output option. I found it cuts a segment that looks like it is correct except has a wrong length or dies not start at timecode or picture 0 which causes joining problems using just copy even if cut at key frames. (I used ffprobe on all cut segments)

I will try that option since it would make cutting simpler.

UPDATE
Just tea the article and the part about setting negative timecode is correct. Previous ffprobe versions displayed this negative time but latest versions show a positive timecode. This timecode not equal to zero is why cutting causes join problems. I eill try the no accurate seek and see if yhus works for me. Thanks selur for the information.