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

Henk D. Schoneveld belcampo at zonnet.nl
Sat May 2 13:43:03 CEST 2015 

> 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

More information about the ffmpeg-user mailing list