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.zukanovi...@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 <belca...@zonnet.nl> >> wrote: >> >> On 02 May 2015, at 06:27, Anatol <anatol2...@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 <belca...@zonnet.nl> >>>> wrote: >>>> >>>> On 01 May 2015, at 20:43, Haris Zukanovic <haris.zukanovi...@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" <belca...@zonnet.nl> >>>>>> >>>>> wrote: >>> >>>> On 01 May 2015, at 13:06, Haris Zukanovic < >>>>>>>> >>>>>>> haris.zukanovi...@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.zukanovi...@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@ffmpeg.org >>>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> ffmpeg-user mailing list >>>>>>>>> ffmpeg-user@ffmpeg.org >>>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Haris Zukanovic >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> ffmpeg-user mailing list >>>>>>>> ffmpeg-user@ffmpeg.org >>>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> ffmpeg-user mailing list >>>>>>> ffmpeg-user@ffmpeg.org >>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>>> >>>>>>> _______________________________________________ >>>>>> ffmpeg-user mailing list >>>>>> ffmpeg-user@ffmpeg.org >>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>>> >>>>> _______________________________________________ >>>>> ffmpeg-user mailing list >>>>> ffmpeg-user@ffmpeg.org >>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>>> >>>>> _______________________________________________ >>>> ffmpeg-user mailing list >>>> ffmpeg-user@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>>> >>> _______________________________________________ >>> ffmpeg-user mailing list >>> ffmpeg-user@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >>> >>> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> > > -- > -- > Haris Zukanovic > > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user