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 <[email protected]> wrote: > > > On 02 May 2015, at 06:27, Anatol <[email protected]> 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 <[email protected]> > > wrote: > > > >> > >>> On 01 May 2015, at 20:43, Haris Zukanovic <[email protected] > > > >> 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" <[email protected]> > wrote: > >>> > >>>> > >>>>> On 01 May 2015, at 13:06, Haris Zukanovic < > [email protected] > >>> > >>>> 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 < > >>>>>> [email protected]> 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 > >>>>>>> [email protected] > >>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> ffmpeg-user mailing list > >>>>>> [email protected] > >>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >>>>> > >>>>> -- > >>>>> -- > >>>>> Haris Zukanovic > >>>>> > >>>>> _______________________________________________ > >>>>> ffmpeg-user mailing list > >>>>> [email protected] > >>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >>>> > >>>> _______________________________________________ > >>>> ffmpeg-user mailing list > >>>> [email protected] > >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >>>> > >>> _______________________________________________ > >>> ffmpeg-user mailing list > >>> [email protected] > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >> > >> _______________________________________________ > >> ffmpeg-user mailing list > >> [email protected] > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > >> > > _______________________________________________ > > ffmpeg-user mailing list > > [email protected] > > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > _______________________________________________ > ffmpeg-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
