ffmpeg cut point wrong with 5 reference frames video

[Budman1]

Perhaps someone can shed light on A problem I have been unable to solve myself or through searching the internet. I have a video with 5 reference frames (all of this type seem to fail) and it is a compilation of several smaller segments. I searched for frame change of 0.4 and got a list of beginning and end points.

Referencing just a couple as an example, One segments starts at frame 790 and goes through frame 809. (needs to be 883)
(another starts at 4969 and goes through 5857, 888 Frames but needs 913)

Calling script:

"C:\PathToPlayer\MPC-BEPortable" "C:\PathToVideo\chunks.avs"

AVIsynth script:chunks.avs

ffmpegsource2("D:\PathToVideo\video_Zeroed.mp4", atrack=-1).converttoRGB
x = float(Width) / float(Height)
last.LanczosResize(round(x * 480.0 / 4.0) * 4, 480).trim(790, -809)
ShowFrameNumber(offset=790,scroll=true, x=10, y=127, font="Arial", size=24, text_color=$ffff80)
ShowTime(offset_f=790,x=72, y=144, font="Arial", size=24, text_color=$ffff80)
ScriptClip(Last, """Subtitle("[ "+Chr(FFPICT_TYPE)+" ]"+"  " +string(current_frame+1), size=(Height*56.0/720), align=3)""", after_frame=True)

This plays correctly: However when I attempt to cut with ffmpeg:

ffmpeg -ss 31.6 -i "D:\PathToInputVideo\Video_Zeroed.mp4" -vframes 809 -c:v copy -c:a copy -y "D:\PathToOutputVideo\OutVideo_Zeroed.mp4"

The video is 74 frames shorter and stop cut of 883 must be specified to include all frames of that segment.

This is probably a simple explanation but it has halted my creation of a frame accurate program that works on most other MP4's without 5 reference frames.
Any help or explanation would be greatly appreciated.

MediaInfo:
General
Complete name : D:\PathToVideo\video_Zeroed.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 68.2 MiB
Duration : 11 min 22 s
Overall bit rate : 837 kb/s
Movie name :
Writing application : Lavf58.47.100
Comment : Recorded and Tagged by Replay Media Catcher 7 (www.applian.com)

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 11 min 22 s
Bit rate : 702 kb/s
Width : 854 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.068
Stream size : 57.2 MiB (84%)
Writing library : x264 core 148
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=15 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=90 / keyint_min=46 / scenecut=0 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=2000 / vbv_bufsize=80 / crf_max=25.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : mp4a-40-2
Duration : 11 min 22 s
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 10.4 MiB (15%)
Default : Yes
Alternate group : 1

[ProWo]

FFmpeg cut doesn't start at frame 790 (31.6 seconds), but at the later I-Frame (whith -c copy).

[Selur]

ffmpeg -ss 31.6 -i "D:\PathToInputVideo\Video_Zeroed.mp4" -vframes 809

should tell ffmpeg to jump to position 31.6s = (frame 790, assuming 25fps) and then output 809 frames.
Have you checked that:
a. ffmpeg also reports frame 790 and frame 1509 as key frames? (using '-show_frames')
b. the first frame ffmpeg outputs with '-ss 31.6 -i ...' is frame 790?

Cu Selur

[Budman1]

Thanks for the help and it allowed me to follow your suggestions and found the problem. FFmpeg will indeed cut at other than an I frame ('P' frame) since they made the input -SS frame accurate. I know I'm going to hear a lot of criticism for that last statement but it is true.

In my example the frame 790 is a 'P' frame and FFMpeg will cut that as pts 0.000000 without any freeze frame, audio w/o video, glitches in timing when joining to another segment from that video:

[Attachment 54445 - Click to enlarge]

As you can see the first frame of the resulting cut of 790-1040 shows during playback and ffprobes show_frames as a 'P' frame and plays in all my players without incident.
HOWEVER... it appears like ffmpeg cuts at the 790 'P' frame and makes it's pts 0.000000 but it begins counting the 250 frames from the previous I-Frame. In this case it is at 750 so 40 must be added to the frame count (790-750=40)

Using this method accurately cuts from 790 - 1040. It also appears I was incorrect that only 5 REFerence frame videos fail this was, it's just that most of the videos I have been using have had a GOP of 50 or less so I just never realized i could have been missing up to 2 seconds at the end of the cut.

should tell ffmpeg to jump to position 31.6s = (frame 790, assuming 25fps) and then output 809 frames.
Have you checked that:
a. ffmpeg also reports frame 790 and frame 1509 as key frames? (using '-show_frames')
b. the first frame ffmpeg outputs with '-ss 31.6 -i ...' is frame 790?

Checking the above help greatly in finding thew problem.

Thx so much for you guys help.

[poisondeathray]

FFmpeg will indeed cut at other than an I frame ('P' frame) since they made the input -SS frame accurate. I know I'm going to hear a lot of criticism for that last statement but it is true.

I don't think this is true for "normal" videos, let alone ones with buggy timestamps . Unless they made it "frame accurate" in the last few days?


Here is a sample video. 0,250,500,750.... are IDR frames. It's just default x264 encoding settings, nothing special . I want to cut on frame 398 inclusively, which is a P frame, for an output 120 frame clip. Clip is 24.0 fps . -ss 16.583 should correspond to frame 398

ffmpeg -ss 16.583 -i "blank.mp4" -c copy -vframes 120 cut398_120.mp4

You end up with a glitchy video that does not play at all in some players, and starts at 250 in others

[Selur]

To start a cut (without reencoding) at anything than a key frame is bound to produce a damaged stream,... that's MPEG basic knowledge,...
You can end a cut a P-frame since none of the frames before the P-frame can reference anything behind it.

[poisondeathray]

To start a cut (without reencoding) at anything than a key frame is bound to produce a damaged stream,... that's MPEG basic knowledge,...
You can end a cut a P-frame since none of the frames before the P-frame can reference anything behind it.

Exactly .

I was thinking that there was some "overhang" at the beginning (it actually cuts at the previous IDR frame) , But the timestamps shift so the display actually starts at the later frame . But an "overhang" is going to cause problems with joining/ editing . Anyways, what I see there is it starts at the previous IDR frame

[Budman1]

I know conventional mpeg knowledge is that it must start with a key frame . I'm just saying what gas worked here. Ffmpeg reset the timestamps without recording using a simple script. It also causes the first frame to be a complete frame in that it is playable, merge able, zeroed pts, and in sync. I'm not contradicting standard knowledge, just saying it works for hundreds of videos I have cut and merged without problems barring that which I asked about here. Works here so far...

[davexnet]

I know conventional mpeg knowledge is that it must start with a key frame . I'm just saying what gas worked here. Ffmpeg reset the timestamps without recording using a simple script. It also causes the first frame to be a complete frame in that it is playable, merge able, zeroed pts, and in sync. I'm not contradicting standard knowledge, just saying it works for hundreds of videos I have cut and merged without problems barring that which I asked about here. Works here so far...

Does it re-encode the broken GOP like a smart renderer or is it re-encoding the whole thing?

[Budman1]

I dont believe it is coding the whole thing because it is set to copy and doesnt show in the cmd output and doesnt take long enough to be encoding Everything.

My belief is that ffmpeg is doing something to the first frame of the cut as it were cd extracting that frame or playing it. I also believe ffprobe does NOT always show correctly. This is apparent when you use it to show_frames that have a major frame change difference where it calls everything an I-frame when they are clearly not.

I do know ffmpeg alters frames during a copy function. If you end a cut on say a B-frame, it will throw in a P-frame where it didnt use to be with a duration of twice the frame duration to carry the video to the next non B FRAME. This maintains sync but causes a stutter at that point, especially if you merge another behind it

If you end you cut on a B-frame immediately before a P frame, ffmpeg will add the next P frame and All timings will be correct.