[FFmpeg-user] Use force_key_frames to obtain keyframes at exactly the same positions as in the input stream?

Haris Zukanovic haris.zukanovic74 at gmail.com
Sat May 2 18:00:32 CEST 2015 

My case is live streaming.
I have tried it and definitely keyframes are not aligned between input 
and output streams.
For all encoded output streams it is very simple to obtain alignement 
with setting the fixed GOP size. But the PTS and keyframes of input are 
never aligned with that.

Sometimes, PTS of the output streams are not aligned, and it seems that 
encoding does not start "at the same time", like there is a delay to 
startup different for different output streams. I have seen this very 
often using the "tee" output




On 5/2/15 1:43 PM, Henk D. Schoneveld wrote:
>> On 02 May 2015, at 11:38, Anatol <anatol2002 at gmail.com> wrote:
>>
>> I don't think that 'keep source keyframes' might impose any a/v sync issues
>> that differ from any other encoding flows.
>> AFIAK, 'force_key_frames' acts on the output/encoding, it does not aware of
>> the decoding processing. For that matter - scene cuts are evaluated from
>> post-decoding/raw frames.
> Did you try without thinking of alignment what happens ?
> Take a source file of several minutes and do your encoding for several bitrates with HLS and then test see if problems do really show up. Meaning maybe you try to solve a potential problem, looking at recuirements, that in reality don’t exist ?
>> On Sat, May 2, 2015 at 12:31 PM, Haris Zukanovic <
>> haris.zukanovic74 at gmail.com> wrote:
>>
>>> My "simple" idea was that instead of deducing from a "formula" like
>>> -force_key_frames 'expr:gte(t,n_forced*5)'
>>> force_key_frames somehow took this kind of info directly from the input
>>> stream and passed onto all output streams
>>>
>>> This could be called something like
>>>
>>> -force_key_frames 'from_source'
>>>
>>>
>>> Do you think it is possible to do?
>>>
>>>
>>>
>>>
>>>
>>> On 5/2/15 10:41 AM, Anatol wrote:
>>>
>>>> It does not matter the type of the incoming protocol.
>>>> And slight un-alignment tolerated by the CDN providers and Apple HLS
>>>> validation tools.
>>>> Therefore the source live stream can be used in an adaptive-bitrate sets,
>>>> IF the other streams match their key frames.
>>>> By the way Wowza has this option ("keep Source key frames") in its
>>>> Transcoder add-on.
>>>> But Wowza also has other problems ...
>>>>
>>>>
>>>> On Sat, May 2, 2015 at 11:06 AM, Henk D. Schoneveld <belcampo at zonnet.nl>
>>>> wrote:
>>>>
>>>> On 02 May 2015, at 06:27, Anatol <anatol2002 at gmail.com> wrote:
>>>>>> The idea is to gain the option to use the H264 source stream along with
>>>>>> live transcoded streams in an adaptive bitrate delivery modes (HLS, HDS,
>>>>>> etc), that require aligned keyframes on ALL participating streams.
>>>>>>
>>>>> Could it be ALL, except the livestream itself ?
>>>>> Or is the livestream also available via HLS ?
>>>>> If yes, then you’ll have to encode this one as well.
>>>>> This can only be achieved if the source stream is encoded with the same
>>>>> version of the encoder you’re using your self. I can imagine that
>>>>> different
>>>>> encoders could behave slightly different.
>>>>> BTW what is your source ? Is it predictable like DVB-S from the same
>>>>> broadcaster ?
>>>>>  From the top of my head BBC broadcast has an I-frame every 12 or 13
>>>>> frames.
>>>>> Another potential issue could be the delay between the video and audio
>>>>> stream, which would force you to also encode the source stream.
>>>>> Hope it helps.
>>>>>
>>>>>> On Sat, May 2, 2015 at 2:48 AM, Henk D. Schoneveld <belcampo at zonnet.nl>
>>>>>> wrote:
>>>>>>
>>>>>> On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovic74 at gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Indeed force-ing keyframes at certain positions is meant to keep
>>>>>>>>
>>>>>>> multiple
>>>>>> output encodings keyframe aligned. The input stream is already h264 in
>>>>>>> our
>>>>>>>
>>>>>>>> case.
>>>>>>>> Moreover, if one could "copy" all iframe positions, and possibly also
>>>>>>>>
>>>>>>> all
>>>>>> other frametypes from the input stream there would not be any need for
>>>>>>>> scene detection if that was already done in the input stream. I am not
>>>>>>>>
>>>>>>> sure
>>>>>>>
>>>>>>>> how much heavy lookahead calculations and perhaps other heavy
>>>>>>>>
>>>>>>> calculations
>>>>>>>
>>>>>>>> could also be skipped?
>>>>>>>>
>>>>>>> What are you trying to achieve ? A performance boost ? I don’t think
>>>>>>>
>>>>>> that
>>>>>> you’ll achieve improvement worthwhile, if anything at all. The working
>>>>>> of
>>>>>> the encoder should need to be totally rewritten to make something like
>>>>>> this
>>>>>> happen at all. Encoding of a frame depends on former and following
>>>>>> frames,
>>>>>> the result I P or B frame is the result. Your source is h264  already,
>>>>>> so I
>>>>>> think you’ll rescale and re-encode to achieve that. The calculation has
>>>>>> to
>>>>>> be done. Knowing in advance that it will be en I P or B frame won’t make
>>>>>>> any difference in the amount of calculations in my opinion.
>>>>>>>
>>>>>>>> On May 1, 2015 7:42 PM, "Henk D. Schoneveld" <belcampo at zonnet.nl>
>>>>>>>>
>>>>>>> wrote:
>>>>>> On 01 May 2015, at 13:06, Haris Zukanovic <
>>>>>>>>> haris.zukanovic74 at gmail.com
>>>>>> wrote:
>>>>>>>>>> Is the decision about exactly which frame to make an IDR frame made
>>>>>>>>>>
>>>>>>>>> in
>>>>>> x264 or ffmpeg?
>>>>>>>>> In general I-frames are placed at scene-changes, this can happen
>>>>>>>>>
>>>>>>>> random.
>>>>>> Additionally you can can force an I-frame every arbitrary amount of
>>>>>>>> frames
>>>>>>>> by specifying the gop-size. The function of an I-frame is to hold max
>>>>>>>> frame
>>>>>>>> info P and B frames build on that complete I-frame. It doesn’t make
>>>>>>>> sense
>>>>>>>> from an encoding viewpoint to skip an I-frame at a scene-change, it’s
>>>>>>>> just
>>>>>>>> impossible.
>>>>>>>>> Adding more than ‘a minimum amount’ of I-frames only makes sense for
>>>>>>>>> seeking purposes, at the cost of less compression/higher then
>>>>>>>>>
>>>>>>>> necessary
>>>>>> bitrate.
>>>>>>>>>> Any pointer or advice on where to look for this in the code?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/29/15 8:54 PM, Anatol wrote:
>>>>>>>>>>
>>>>>>>>>>> No responses on that one?
>>>>>>>>>>> It is very important issue.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 27, 2015 at 11:47 PM, Haris Zukanovic <
>>>>>>>>>>> haris.zukanovic74 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>> Can I use force_key_frames in some way to produce keyframes (IDR,
>>>>>>>>>>>>
>>>>>>>>>>> not
>>>>>> I-frames) at exactly the same PTS in output streams as they are
>>>>>>>>>>> found
>>>>>> in
>>>>>>>>>> the live input stream? Both input and output are h264 and live
>>>>>>>>>>> streaming.
>>>>>>>>>> Something analogous to using 2 pass encoding for VOD and in the
>>>>>>>>>>> second
>>>>>>>> pass keyframes are inserted exactly where they are recorded in the
>>>>>>>>>>> first
>>>>>>>>>> pass... Is that something like that even theoretically doable for
>>>>>>>>>>> live
>>>>>>>> streaming?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> thanx
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> --
>>>>>>>>>>>> Haris Zukanovic
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> ffmpeg-user mailing list
>>>>>>>>>>>> ffmpeg-user at ffmpeg.org
>>>>>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> ffmpeg-user mailing list
>>>>>>>>>>> ffmpeg-user at ffmpeg.org
>>>>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> Haris Zukanovic
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> ffmpeg-user mailing list
>>>>>>>>>> ffmpeg-user at ffmpeg.org
>>>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ffmpeg-user mailing list
>>>>>>>>> ffmpeg-user at ffmpeg.org
>>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> ffmpeg-user mailing list
>>>>>>>> ffmpeg-user at ffmpeg.org
>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ffmpeg-user mailing list
>>>>>>> ffmpeg-user at ffmpeg.org
>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> ffmpeg-user mailing list
>>>>>> ffmpeg-user at ffmpeg.org
>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>>
>>>>> _______________________________________________
>>>>> ffmpeg-user mailing list
>>>>> ffmpeg-user at ffmpeg.org
>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>>
>>>>> _______________________________________________
>>>> ffmpeg-user mailing list
>>>> ffmpeg-user at ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>
>>> --
>>> --
>>> Haris Zukanovic
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> ffmpeg-user at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

-- 
--
Haris Zukanovic

More information about the ffmpeg-user mailing list