Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
    
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?) –  slhck Feb 27 '13 at 6:54
    
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 –  jackode Feb 27 '13 at 8:07
    
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? –  slhck Feb 27 '13 at 8:13
    
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? –  jackode Feb 28 '13 at 1:19
1  
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. –  slhck Feb 28 '13 at 9:19

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
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). –  Adisak Apr 24 at 21:13
    
@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. –  slhck Apr 24 at 21:57

Like mentioned, the first frame of your video has to be an I-Frame. Your issue comes from not the encoding (or copy if that's your flavor) but from the decoding. Having -ss before the input is inexact so ffmpeg is doing the best it can to get you to about where you wanted. Ffmpeg passed that location and thus tells you a non-zero first timestamp.

I would recommend trying a second -ss after your -i. Along the lines -ss 299 -i input -ss 1.

This says go to about the location you wanted, then decode for 1 second before processing. I am not sure if this will fix your pts issue but hopefully it will move you in the right direction.

To point out, I don't think the force_key_frames command is doing what you think it is. If its doing anything, it's likely just telling it to add a key frame in the output every 300 seconds but that is just a guess. Meaning only the first frame of your output would be a key frame (t=120).

https://ffmpeg.org/ffmpeg.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.