New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users
Status: Archived
Owner:
Closed: Aug 4
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment
Bandwidth utilization around FEC enable/disable is inaccurate
Project Member Reported by andresp@webrtc.org, Mar 13 2014 Back to list
See attached screenshot... which is a webrtc client producing a 1mbps stream and that everytime it enables FEC send bitrate goes as high as 1.7mbps.


 
Screenshot from 2014-03-07 15:40:13.png
138 KB View Download
Project Member Comment 1 by andresp@webrtc.org, Mar 13 2014
Cc: stefan@webrtc.org andresp@webrtc.org
Status: Available
Comment 2 by vrk@webrtc.org, Oct 14 2014
Labels: Area-Video
Project Member Comment 3 by tnakamura@webrtc.org, Nov 4 2015
This bug hasn't been modified for more than a year. Is this still a valid open issue?
Project Member Comment 4 by stefan@webrtc.org, Nov 5 2015
It hasn't been fixed, but I think it's by design, although it can probably be improved. We may want to look at improving allocation of bitrates when we look at doing FEC improvements.
Project Member Comment 5 by mflodman@webrtc.org, Dec 10 2015
Cc: mflodman@webrtc.org
Owner: pbos@webrtc.org
Peter,
Since you recently looked into FEC bitrates, are there any next actions on this?
Project Member Comment 6 by pbos@webrtc.org, Dec 17 2015
Status: WontFix
I think we landed on b=AS being global maximum (which is correctly enforced through Call now), and that FEC is allowed to add to the total bitrate. I don't think there's anything left actionable (unless the FEC rate is too aggressive, but if that's the case that sounds like a separate bug).
Project Member Comment 7 by pbos@webrtc.org, Dec 17 2015
Ok, think I understand the bug, the encoder isn't responding quick enough to the rate change here I guess. Not feasible (?), but the pacer should help prevent overshooting rates by smearing out the spike.
Project Member Comment 8 by stefan@webrtc.org, Dec 17 2015
Yes, this isn't related to what you wrote in #6. The problem is that we compensate for FEC bitrate by reducing the target rate of the encoder, but this happens after the fact, and it takes us 1 second to measure what the actual FEC bitrate ended up being. NACK compensation works the same way.

We can improve this by instead allocating bitrate for FEC in the bitrate allocator and not compensate after the fact.

The pacer will help in reducing the number of packets in the network, but we will pay with added send-side delay.
Project Member Comment 9 by stefan@webrtc.org, Dec 17 2015
Status: Assigned
Project Member Comment 10 by pbos@webrtc.org, Dec 18 2015
Spending additional bits on FEC also makes sense since it's a more effective padding scheme than retransmitting packets (or dummy padding). Maybe we shouldn't only do it when it's packet loss, but so long as encoded rate < target transmit rate.
Project Member Comment 11 by mflodman@webrtc.org, Dec 21 2015
Agree, but this bug is around avoiding the overshoot the first second when we are BW limited and encounter packet loss. Right?

The question, as Stefan wrote, is if this should be handled by the bitrate allocator or per stream.
Project Member Comment 12 by pbos@webrtc.org, Dec 28 2015
I think filling with FEC after the fact makes sense regardless, since the underlying VideoEncoder implementation might not respond as fast as we want it to.

I think that's what's happening now unless the underlying code was very different when this was reported. We do set new encoder parameters on the next encoded video frame through ::SetChannelParameters in VideoSender when these rates change in MediaOptimization.

Would moving this setting to the bitrate allocator change anything? We're not waiting for a timer to pick this up, so I think we can't rely on that setting half the target rate to instantly-ish cut the bitrate in half. Am I missing something?
Project Member Comment 13 by stefan@webrtc.org, Jan 11 2016
I think you are missing the point.

The way our FEC works is that it produces X% redundancy based on the protection factor computed by our media optimization. It will always try to create this amount of FEC. The rtp module then measures the FEC and NACK bitrates sent the last second, and feeds back those rates to the media optimization, which subtracts those rates when computing the encoder target bitrate:

  video_target_bitrate_ = target_bitrate * (1.0 - protection_overhead_rate);

The problem with this is that there will be a lag of 1 second in protection_overhead_rate, which causes us to overshoot for a second for instance when the FEC is enabled due to packet loss.

This could be improved either by allocating a bitrate for FEC instead of a fraction. Or we could subtract the FEC bitrate that we expect to be generating (based on the fraction).
Project Member Comment 14 by mflodman@webrtc.org, Mar 1 2016
Cc: -stefan@webrtc.org pbos@webrtc.org
Owner: stefan@webrtc.org
Over to Stefan to re-triage and decide next step.
Project Member Comment 15 by stefan@webrtc.org, May 18 2016
Cc: marpan@webrtc.org stefan@webrtc.org perkj@webrtc.org
 Issue 5897  has been merged into this issue.
Project Member Comment 16 by brandtr@webrtc.org, Jul 20 2016
Cc: brandtr@webrtc.org
Project Member Comment 17 by mflodman@webrtc.org, Aug 4
Status: Archived
[Bulk edit] This issue was created more than a year ago and hasn't been modified the last six months -> archiving.

If this is still a valid issue that should be open, please reopen again.
Sign in to add a comment