How should PLI packets be used in WebRTC video recording

Question

We are using the licode MCU to streaming video from Google Chrome to the server and record it. The tricky part here is that there is only one Chrome browser involved so the server-side code has to handle sending feedback to the client.

We added server-side code to send REMB (bandwidth) packets every 5 seconds to the client. This causes the client to increase bitrate so that the video quality is good.

We did something similar with PLI packets to attempt to improve video quality. The recorded video had blocky artifacts and didn't look good. The current code sends a PLI every 0.8 seconds which causes the client to send a keyframe (full frame of video). This fixes the poor video quality because it forces a keyframe but when there is packet loss (wifi network) it quickly gets bad again.

My question is how should these PLI packets be used?

I think PLI means:

PLI    - Picture Loss Indication

Triclinium

You may want to try the legacy FIR rtcp requests. PLI is payload specific, even though it SHOULD work, I have seen it not work in certain situations. – Flapjack

The PLI requests are working. I'm just wondering if this is the correct way to use them. Can you explain what you mean by 'payload specific'? – Triclinium

PLI is not a standard RTCP packet type, it is specifically related to the media payload. However, PLI should give you a new key frame with vp8. Also, every 0.8 seconds is a huge amount of key frames. Why do you need to send REMB to increase the bandwidth? Webrtc in chrome natuarally goes up to 2 Mb/s over time if the network supports it. (Sources for PLI and FIR) – Flapjack

The PLI packets are indeed creating keyframes. We did this to as a workaround to poor video quality we were seeing. What about NACK packets? From what I've read this is how a receiver should deal with packet loss, but I've been unable to get the client to register a NACK sent from the server. We noticed that with the licode MCU with one Chrome browser recording to server bandwidth didn't ramp up unless the server sent REMB packets. – Triclinium

Answer 1

Your application should send at least three kinds of RTCP feedback:

• an accurate receiver report (RFC 3550) every second or so, indicating packet loss and jitter rates to the sender; this will cause the sender to adapt their throughpout to the link characteristics;
• a generic NACK (RFC 4585) whenever it misses a packet; this will avoid corruption by causing the sender to resend any packet that is lost;
• a PLI (RFC 4585) whenever it hasn't seen a keyframe in a given interval, for example two seconds.

Sending REMB is only necessary to limit throughput if it grows too fast, for example if the feedback provided in receiver reports is inaccurate.

Outwardbound