Regarding indication of intra frames, draft-berger-avtext-framemarking proposes a header extension for intra and other critical info for codec agnostic switching. It will be discussed in avtext.
Mo On Mar 15, 2015, at 1:47 PM, Sergio Garcia Murillo <[email protected]> wrote: Hi, Based on my hands-on-experience, RTP mixer should not depend on periodic Intras for working, instead they should send an RTCP FIR/PLI request to the new active speaker and wait until the I-Frame is received before switching the RTP stream. In fact, in my mcu I configure the encoders to not send periodic i frames at all and only send them by request (on received RTCP FIR/PLI). I agree with Harald on the other use cases for non-initial I-frames, especially the seeking on storing media one. But I think there could be other alternatives that provide viable solutions while not having a big impact on quality/bitrate as Iframes have. BTW, not sure if it is the right place/thread, but as an implementator, I find it quite important to be able to tell if a frame is iframe/recovery/seekable without to deep diving into the encoded frame bitstream. Best regards Sergio > On 15/03/2015 14:26, Mo Zanaty (mzanaty) wrote: > Another reason for testing with periodic intra is the recent rise in RTP > mixers which switch rather than transcode media. Setting the intra interval > to the average active speaker switching time gives a good estimate of > real-world codec efficiency in these topologies. > > Mo > > > > On Mar 15, 2015, at 6:36 AM, Harald Alvestrand <[email protected]> wrote: > > Forking the subject.... > > Den 03. mars 2015 10:10, skrev Mohammed Raad: >> At MPEG we use this to determine the codec performance for the "random >> access" case. I don't know why the 1 second interval was chosen and >> don't think that its relevant in many use cases, but MPEG codecs are >> aimed at satisfying a broad range of applications and so this test case >> has been maintained. Members of the potential IETF activity may find >> that this is an irrelevant test case. > The reasons for having non-initial I-frames that I know of: > > - To allow seeking in stored media. To jump to a specific point, you > locate the last I-frame before the point you want to go to and run the > decoder from that point to the point where you really want to go. > > With DASH being a prevalent mode of delivering stored media, and each > DASH chunk starting with an I-frame, 5 seconds would be realistic for this. > > - To allow recovery from a known good state in streaming media. > For interactive two-way media, you can explicitly ask for an I-frame and > have the headend produce it; for other media, such as broadcast (the > original use case for half-second intervals, as mentioned above), more > complex schemes are needed (I've heard of technologies for storing a > reference frame in some other form and transferring it out of band so > that the decoder can initialize its state and start decoding without an > I-frame, but I don't know if these are used in practice.) > > > > _______________________________________________ > video-codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/video-codec > > _______________________________________________ > video-codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
