Packet loss handling in webrtc

[Quang Nguyen]

Dear everyone, 

As I know, currently webrtc handle packet loss by a hybrid approach called NACK/FEC (http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41611.pdf) 

My question is, when a video frame is encapsulated to RTP packets and additional FEC packets, do the FEC packets have sequence numbers increase consecutively? And when one of those FEC packets loss, does webrtc NACK it? 

Thanks and regards,

Quang Nguyen.

[Peter Boström]

They're both encapsulated in RED packets and should not be NACKed if the original payload can still be recovered.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c55bf56e-ad0a-4bff-b9e2-d1be3363f7cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan Holmer]

We may send NACKs for lost FEC packets since we can't know if the lost packet contained media or FEC. The WebRTC sender will however by default only retransmit lost media packets.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sH8rq8wm2uw_mXcjKspDg8p5vR3bhbv%3Dmdj7xC0q3BKvA%40mail.gmail.com.

[Quang Nguyen]

@stefan: do you know how the Webrtc sender know if this RED packet is Media or FEC packet? As I know, in Video Coding module, the jitter buffer only store missing sequence numbers for lost packets, so if FEC packet was lost, it will be NACKed.

[Stefan Holmer]

If the packet is received it's possible to read the encapsulated payload type to see if it's FEC or media. If it's not received this isn't possible, and a NACK will likely be sent both for media and FEC. The sender can however choose not to retransmit the packet if it is an FEC packet, and thereby avoid wasting bandwidth. A better option is to send FEC on a separate stream and simply not negotiate NACK/RTX for that stream, which is possible with the flexfec draft (not currently supported by Chrome).

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d0ab848f-6c88-4dbc-9cf7-94c8a4039d65%40googlegroups.com.