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