> On 02 May 2015, at 11:38, Anatol <anatol2...@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.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
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user