When FEC packets are being sent ?

[ftv dev]

When I enable the FEC mechanism using SDP, are the FEC going to be sent always or they are going to be send only when there is a packet loss? 

[André Susano Pinto]

Why do want to know that?

I don't think you can do any assumptions other than when enabled webrtc can use it as it wants to improve the experience.

E.g. even if enabled, it might not be used, it might be used all the time, it might be used only when packet loss is detected, it might be used only when rtt is high, etc...

On Mon, Jan 13, 2014 at 7:03 PM, ftv dev <ftv...@gmail.com> wrote:

When I enable the FEC mechanism using SDP, are the FEC going to be sent always or they are going to be send only when there is a packet loss? 

--
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[ftv dev]

I need this information for doing some tests for a research work. I need FEC packet to be used all the time event there is no packet loss and no delays.
So are the packet sent all the time or I have to spend some time on modifying the source code to get what I need ?

[ftv dev]

No answers ?!!

[Stefan Holmer]

WebRTC sends FEC packets (if negotiated) when packet loss has been present and the RTT is above a threshold (20 ms if I remember correctly).

See this paper for more details on how we handle packet loss.

[ftv dev]

Thank you for your response. Is there a way to force it to send them all the time ?

[Stefan Holmer]

Not that I know of. I think you'd have to make a custom Chromium build for that.

[German Korovkin]

What kind of research with webrtc you are intent to do ?

Anyway, 

I would recommend before any researches start from this document before doing any experiments.

AFAIK, chrome ftp ulpfec is fully rfc complain, so it might be more effective to start from understanding forward error correction mechanism and do any experimental part after.

Doing experimental part - a little advice on that: run chrome on desktop via WiFi box and moreover, run some downloader in background( to fill up bandwidth ).

After that you shall see how almost all webrtc RTP recovery algorithms works: nack signalling about losses, FEC overhead and within RTCP - SLI/PLI signalling.

I think the most advantages of this media will be shown, when VP9 will be here with full SVC.

Best regards,

German

среда, 22 января 2014 г., 0:34:55 UTC+4 пользователь ftv dev написал:

[ftv dev]

I have read the RFC5109 and I don't remember that they are indicating that the FEC should be send when there is a packet loss and/or the RTT is above some threshold.

I already tested the different algorithms and I know that they works. However, I think that they still need more optimization.

All the best.

[Robert Jongbloed]

I have been doing some work with this too, and am totally mystified as to the criteria used for when FEC packets are sent.


I am trying to add WebRTC support to me VoIP library. Using SIP stack over WebSocket, the SDP negotiation indicates that red and ulpfec are enabled, and yet, Chrome only ever sends the raw VP8 video on payload type 100. Never the red packets.

Chrome offer:
m=video 1 RTP/SAVPF 100 116 117
...
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
...

My answer:
m=video 44094 RTP/SAVPF 100 116 117
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack pli
a=rtcp-fb:* goog-remb
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
...

Which to the best of my knowledge is correct to all the relevant RFC's, and there are a few!

As an aside Chome does not advertise support for PLI in it's SDP, and yat as far as I can determine it doe, in fact, support it.


As a lot of people talked about FEC only happening when there is packet loss, I hacked my code to fake packet loss in the RTCP-SR records sent back to Chrome for it's transmitted video. Even at 25% packet loss, no FEC packets were forthcoming. At 50%, Chome seemed to deem the link unusable and disconnected, though not at all sure that was the reason.

I have tried sending many PLI packets. I have tried sending REMB packets in case that was required.

Nothing works.


Now, the final kicker, when I do a call between two computers running Chome (Mac to PC, if it matters) using https://apprtc.appspot.com, and observe the RTP traffic using Wireshark, I can see that Chrome is sending red packets, and, by implication ulpfec, via the payload type (116) which you can still see as the RTP header not encrypted in SRTP.

As Chrome was sending red packet while over my LAN, the statements that it only does so in the presence of packet loss does not seem correct. It is certainly possible it is not putting in the redundant ulpfec part or the red packet until a certain level of packet loss, but it is sending red packets. And I have not managed to get it to do that.

There is some criteria that Chrome needs, which has so far eluded me, does anyone have a clue as to what that is?

Robert Jongbloed
OPAL/OpenH323/PTLib Architect and Co-founder.
Commercial support at http://www.voxlucida.com.au

[German Korovkin]

Exacly! There are no such thing as a "now we should send FEC due to the losses". 

WebRTC using FEC via RED mechanism, so If FEC/RED has been successfully negotiated then you should always see FEC packets in RED feed.

Offtopic:

Btw, could you please share your thoughts on "more optimisation" that you think could help? 

среда, 22 января 2014 г., 23:43:14 UTC+4 пользователь ftv dev написал:

[Fakher Oueslati]

By combining the answer of Stephan and German, you will have the correct answer.

I think that webRTC have two modes:

1. HybridNackFEC mode: in this mode:
• If RTT is low, only NACK will be used (FEC rate is set to 0).
• If RTT is high, only FEC will be used.
• If RTT is medium, Hybrid mode is used; In Hybrid mode webRTC will only nack packets that cannot be recovered from FEC packets.
2. FEC mode: This FEC is conform to the RFC 5109. So FEC packet will be send always at the negotiated rate.

I got this information from the webRTC internals API documentation: http://www.webrtc.org/reference/webrtc-internals/viertp_rtcp

And from the source code file webrtc/modules/video_coding/main/source/media_opt_util.cc

Best regards,
Fakher

[Robert Jongbloed]

Yes, I have seen this info. Everything I have read says it should do work.

And yet, no RED packets are sent.

Robert Jongbloed
OPAL/OpenH323/PTLib Architect and Co-founder.
Commercial support at http://www.voxlucida.com.au