Cannot cut MPG at first frame

[Budman1]

The problem I am having at least with 3 of the MPG videos I am trying to edit is I cannot cut, seek, copy from the first frame. Using -ss as the input or output option with all seek point of all frames fails to produce correct video segment. It consistently begins at the next I-Frame. I can extract the the first frame but only by seeking to a weird PTS/DTS point.

I am using ffmpeg since I need a CLI program . The videos, all of them, are GOP 12, first frame DTS is 0.540000. One is 25 FPS and one is 29.97 FPS.The MediaInof of one is:

General
Complete name : C:\Users\Bud\Documents\Applian\Replay Media Catcher\Funny Video Clips - Horse karate kick.mpg
Format : MPEG-PS
File size : 800 KiB
Duration : 3 s 500 ms
Overall bit rate mode : Constant
Overall bit rate : 1 873 kb/s

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 1
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=9
Duration : 2 s 970 ms
Bit rate mode : Constant
Bit rate : 1 643 kb/s
Maximum bit rate : 2 000 kb/s
Width : 320 pixels
Height : 240 pixels
Display aspect ratio : 1.185
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.714
Time code of first frame : 00:00:00;00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 596 KiB (74%)

Audio
ID : 192 (0xC0)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 3 s 500 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 1 channel
Sampling rate : 44.1 kHz
Frame rate : 38.281 FPS (1152 SPF)
Compression mode : Lossy
Delay relative to video : 67 ms
Stream size : 82.0 KiB (10%)

Any help or methods would be greatly appreciated
Thanks.

[veresov]

Give us a link to your stream for analysis.

[Budman1]

Think I found A probblem.. The link is https://files.secureserver.net/0sqaAIeXkdb1Lt and ffprobe says that the first frame is not an I-Frame???
I've seen this before from recoding a recode with -ss options but why it plays but will not seek is beyond me. I was able to seek to frame 0 but trying to go to any other key frame such as
20 gives erroneous output. I was using a player to output the frame and time but, playing B-frame 0 gave a false time and frame number.

Even encoding o a new size gave duplicate frames at 22 even though this does not show in the ffrobe DTS/PTS times

If anyone knows a way too accurately seek to the third keyframe, please let me know.

Thanks
No. pts_time type
0 0.166156 0 B
1 0.199522 0 B
2 0.166156 1 I
3 0.266256 0 B
4 0.299622 0 B
5 0.332989 0 P
6 0.366356 0 B
7 0.399722 0 B
8 0.433089 0 P
9 0.466456 0 B
10 0.499822 0 B
11 0.533189 1 I
12 0.566556 0 B
13 0.599922 0 B
14 0.633289 0 P
15 0.666656 0 B
16 0.700022 0 B
17 0.733389 0 P
18 0.766756 0 B
19 0.800122 0 B
20 0.833489 1 I

[sophisticles]

Have you considered simply re-encoding to a lossless I frame format and editing that? For instance AVC Intra or ProRes Lossless?

[jagabo]

Think I found A probblem.. The link is https://files.secureserver.net/0sqaAIeXkdb1Lt and ffprobe says that the first frame is not an I-Frame???...

No. pts_time type
0 0.166156 0 B
1 0.199522 0 B
2 0.166156 1 I
3 0.266256 0 B
4 0.299622 0 B
5 0.332989 0 P
6 0.366356 0 B
7 0.399722 0 B
8 0.433089 0 P

I don't have a solution for you, only an explanation. That clip was trimmed from an open GOP source. The first two B frames are part of the previous GOP. They appear here because they are stored after the I frame of the current GOP. For example, in presentation order (the order in which they should be viewed) the original video had:

...pbbIBBP...

I used lower case for the previous GOP, upper case for the current GOP. But they were not stored in that order. The storage order was:

...pIbbPBB

They are stored in that order because that is the order in which they are decoded (the decoder reorders them to presentation order during playback). When the clip was trimmed from the original source those two b frames were retained:

...p  <cut> IbbPBB

Ie, the b frames are not part of this clip. Many programs have problems with this.

<oops, forgot>

If you put that remaining sequence back in presentation order:

bbIBBP

The two leading b frames cannot be reconstructed since they may reference the p frame which is no longer available.

</oops, forgot>

[veresov]

jagabo on top of things as usual.

[Budman1]

@sophisticles... Thanks for that suggestion but I was really trying to understand why it was the way it played and copied. I will keep your suggestion in mind in the future for sure in case my workaround fails on some other MPG.

@Jagabo... Thanks a lot for that explanation and it makes perfect sense now. It is indeed Open GOP and, with further trial and error it appears the players does in deed play the frames in the order 2,1,0,4.

key_frame pkt_pts pkt_dts_timeDuration Pict_type coded_picture_number
frame video 0 0.166156 0.166156 0.033367 B 1
frame video 0 0.199522 0.199522 0.033367 B 2
frame video 1 0.166156 0.232889 0.033367 I 0
frame video 0 0.266256 0.266256 0.033367 B 4

With your information mind, I was able to extract the segment starting with the first frame, even though it was again a B-Frame.
I just had to play a game with FFMpegs -ss setting.

key_frame pkt_pts pkt_dts_time duration pict_type coded_picture_number
frame video 0 0.533367 0.533367 0.033367 B 1
frame video 0 0.556733 0.566733 0.033367 B 2
frame video 1 0.533367 0.6001 0.033367 I 0
frame video 0 0.633467 0.633467 0.033367 B 4

I would like to have gotten the PTS/DTS the same as original but MPG seems to have more overhead than MP4. MP4's can be made to
reset PTS/DTS to 0.000000 and still play without problems, frozen screen, missing frames, and delays in the video with audio playing.
There does not seem to be any delay in this copied MPG so that is probably not a problem.

Jagabo and sophisticles Thanks again