I would like to know what are the meaning of this SDP lines as I am trying to get the smoothest framerate posible with 5% to 10% packet losses.
The lines i don´t know are: a=rtcp-fb:100 goog-remb a=rtcp-fb:100 transport-cc
I don´t know why firefox (for example) is removing "transport-cc" capability, is it something I want to make stream framerate smooth even if I have to decode incomplete video frames?
Bests regards, I hope someone can help me on that :)
Gustavo García wrote a blog post about this called Bandwidth Estimation in WebRTC (and the new Sender Side BWE).
To summarize: goog-remb and transport-cc are both congestion control mechanisms, goog-remb being an older method and transport-cc being a newer method.
My best guess is that firefox is stripping out transport-cc because firefox hasn't adopted the transport-cc changes yet. In my experience, Chrome is always ahead of Firefox in webrtc changes.
In a lossy network, these congestion control algorithms could tell the sender to lower the send bit rate. Lowering the send bitrate may reduce loss (at the expense of quality). However, if the network is always 10% lossy, like a noisy WiFi network, you still might suffer from video frame decode problems.
Handling video decode failures is a function of the vp8/h264 video encoding parameters, not of congestion control. As I said, congestion control might help reduce loss (in the event you are overwhelming your network with WebRTC packets), but if you just have a lossy network (e.g., poor wifi) the congestion control algorithms will just reduce quality without improving decode failures.