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
