[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 11:31:00 CEST 2015


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



More information about the ffmpeg-user mailing list