New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 3050 link

Starred by 8 users

Issue metadata

Status: Archived
Owner:
Closed: Aug 2017
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

Issue description

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 2017

Status: Archived (was: Assigned)
[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