How to force the first frame to be key-frame?

Question

I want to encode after seeking to a certain position, and i want to make the first frame a key-frame, here the command i used:

ffmpeg -ss 300  -i howimet.mp4 -acodec libfaac -ar 48000 -ab 128k -ac 2  -vcodec libx264 -vf "scale=480:270" -f mpegts -force_key_frames 300 -t 120 howimet2.ts

the -force_key_frames is set to seek position to make a key frame there. I use the following script (from here) to check if the first frame is key-frame

ffprobe -show_frames -v quiet howimet2.ts | awk -F= '   /pict_type=/ { if (index($2, "I")) { i=1; } else { i=0; } } 
  /pkt_pts_time/ { if (i && ($2 >= 0)) print $2; }  
' | head -n 1

The result show the first key-frame is not locate at second 0.

I guess my command is not correct. what am I missing?

Solution

When encoding video, the first frame has to be a keyframe. It will be the first one fully encoded, and subsequent frames may use it for inter-frame prediction. Also, at the beginning of the coded video sequence, you will have an H.264 access unit that tells the decoder to refresh.

So, regardless of what you're doing: Unless you just copy the bitstream, you're re-encoding the video and your first frame has to be a keyframe.

Now, for whatever reason your stream has an offset in its start time. This means that all the presentation timestamps are also shifted according to this offset. If you inspect the head of the ffprobe -show_frames output, you'll see that frame 0 will indeed be a keyframe, but with a different PTS.

To compensate for this, you can subtract the start time from all PTS.

Comments

[slhck]

You shouldn't need to do anything to force the encoder to create the first frame as a keyframe. Anything else wouldn't make sense, really. Also note that -force_key_frames should be relative to the input, so 300 doesn't make sense either—it should be 0 if I'm not mistaken. Does the video play alright, or why are you asking? (Put differently, why is it so important, or what is the background of your question?)

[jackode]

i got the same result with -force_key_frames 0. The reason i want that be cause I implement a ffmpeg segmenter that will generate HSL segment on the fly. When user seek to a position, segmenter should be able to generate proper segment; the segment will be sent to client's player (ios movie player); by default, player will start play from first key-frame in the received segment. I want player to start playing from the first frame. Hope my explanation makes sense

[slhck]

I see. I have to admit I'm not an expert when it comes to streaming, but there's really no reason for an encoder not to use a keyframe as the first frame. If you use -vcodec libx264, FFmpeg will take whatever decoded picture it gets, feed it to x264, and the first thing x264 will do is create a keyframe. You can't start a video with a non-reference frame. If you manually check the output of ffprobe, what does it say about the first frame?

[jackode]

the above ffprobe script code said the first kframe is somewhere at second 1.441711. ffprobe -v quiet -print_format json -show_streams howimet2.ts tells me that "start_time": "1.400000", is it the reason?

[slhck]

Yes, then in your case the start PTS (and time) have an offset. I don't know why this happens, but you should be able to just compensate for the offset by subtracting it.

[jackode]

I think i got the answer for my question. In fact, the first frame is a key-frame, but the reported timestamp was not 0.0 because of the offset. If you re-compose and put your comments as an answer i will accept it.

[Jonas]

The first frame doesn't have to be an I-Frame (KeyFrame), it can be a B-Frame (dependent on future frames, one of which is likely to be an I-Frame).

[slhck]

@Adisak That's incorrect. If the first coded frame is not an I-frame, the decoder cannot start to decode because all it has is prediction differences, but no actual signal. A B or P picture always has at least one reference frame that has to be decoded first.