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

Sat May 2 11:38:38 CEST 2015

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.

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
>