Bug 1690832 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Michael Froman [:mjf] from comment #7)
> (In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)
> > Mjf, what do we think is going on here? This is happening to regular non-simulcast video.
> 
> My first guess is that since the mitigation for Bug 1674463 involved lowering the min bitrate for HD, a different (higher) resolution is picked.  If stopping the transceiver makes the problem better, it may that multiple higher-resolution video tracks are continuing to fight for available bandwidth in the non-stop case.
> 
> I'll try to add some ad-hoc logging on my end to see if this theory holds up.

Well, resolution was the wrong thing to key on here, but I suppose it makes sense that if our min bitrate is allowed to drop to 200kbps, the frame rate will drop for a given resolution.  I've run both cases (with the patch from Bug 1674463 included and not), and we're choosing the same line from kResolutionAndBitrateLimits[1].  Given that, I guess the question becomes what is causing the available bandwidth to decrease?

[1] https://searchfox.org/mozilla-central/source/dom/media/webrtc/libwebrtcglue/VideoStreamFactory.cpp#34
(In reply to Michael Froman [:mjf] from comment #7)
> (In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)
> > Mjf, what do we think is going on here? This is happening to regular non-simulcast video.
> 
> My first guess is that since the mitigation for Bug 1674463 involved lowering the min bitrate for HD, a different (higher) resolution is picked.  If stopping the transceiver makes the problem better, it may that multiple higher-resolution video tracks are continuing to fight for available bandwidth in the non-stop case.
> 
> I'll try to add some ad-hoc logging on my end to see if this theory holds up.

Well, resolution was the wrong thing to key on here, but I suppose it makes sense that if our min bitrate is allowed to drop to 200kbps (whereas previously only allowed to drop to 600kbps), the frame rate will drop for a given resolution.  I've run both cases (with the patch from Bug 1674463 included and not), and we're choosing the same line from kResolutionAndBitrateLimits[1].  Given that, I guess the question becomes what is causing the available bandwidth to decrease?

[1] https://searchfox.org/mozilla-central/source/dom/media/webrtc/libwebrtcglue/VideoStreamFactory.cpp#34

Back to Bug 1690832 Comment 11