What is the best key frame interval

[Tian Yong]

Hey guys

Working on a SFU project.

There's a common problem every SFU/MCU developer should met: when people join a conference in the time between 2 key frames.

After some researches, I think the best solution is to send key frame in a constant interval.

Do you guys have other good solutions?

What's the key frame interval are you guys using? There's a post here can be referred here https://streaminglearningcenter.com/blogs/whats-the-right-keyframe-interval.html

Right now I send fir packets to publish every 3 seconds to request a key frame, anyone knows if there's a js parameter in browser to complement this?

[Francesco Durighetto]

the right way to do is not requesting a keyframe every tot. seconds.

The right way to do this is, whenever a person join, to forward a PLI request (it's an RTCP packet) to senders, whose will send a keyframe to start the decoding process on the new subscriber!

The much keyframe you send, the much congested your network will. 

instead, you need as I said, to send a PLI at the beginning and a NACK for every packet you lose.

if your project is an SFU, none of these are your problem if you forward all RTCP packets from subscriber to sender. 

But if you terminate the RTCP on your SFU, you need to manually implements these mechanism.

[Tian Yong]

We do implement RTCP feedback in SFU. Forward all RTCP form subscribers to publisher is not a good idea.

At first, we request a key frame by sending FIR packet to sender, but as more and more people join the conference(more than one thousand), the SFU received massive of PLIs and FIRs from subscribers all the time, so we at last just send FIR packet every 3 seconds and terminate all PLI and FIR from subscribers.

[Francesco Durighetto]

In my opinion you have to keep a local buffer and be sure to have all seq. number and generate nack until you get the packet loss or generate a pli if you can't recover a packet.

once you have all packets in your buffer, you need to terminate rtcp from all subscribers and send all packets they nack'd from your buffer to be sure all of them continuously playing the stream.

If you look at chrome implementation, the times it send plis are very rare, even with lots of packet loss. It has a robust nack mechanism (it send nack multiple times if needed).

If you make this mechanism robust you avoid requesting periodic plis.

with a 2% packet loss and a 2 or 3 second pli interval (which is the general streaming standard for pli as you said) you probably will see nothing but micro freezes (in chrome) or distorted images (in firefox)