Bugzilla

Thanks Finn for the detailed report! — Could you do me a favor and test Firefox 95? We did a major libwebrtc update in 96, and if this is a regression in behavior it would significantly improve our chances of locating the problem and prioritizing a fix.

> Our webrtc application is relying on adaption preference "maintain-resolution"

Firefox does not yet implement [degradationPreference](https://w3c.github.io/mst-content-hint/#dom-rtcrtpsendparameters-degradationpreference), so if this isn't a regression, this may be a duplicate of  bug 1329847.

But I'd like to understand better what is going on, and answer your questions.

> The timed condition seems to depend on client (!) system time and can be recreated by adjusting it into a time frame of occurrence

That certainly seems bizarre. What services are you able to reproduce this with? Is it using simulcast? Does it reproduce on a LAN or local loop 
connection? Have you replicated this on multiple machines?

Also, what does speedtest say your upload speed is? If it is limited then Firefox is sharing that with any other networking apps on the local system, or even cron jobs, and Firefox will reduce resolution if "estimated bandwidth"  (observable in about:webrtc) is low due to these other activities. I'm not aware of any studies being run within Firefox itself, but I'm on the WebRTC team so I wouldn't know for sure.

> set local system time to the equivalent of March 2nd 1:00am UTC

To follow these instructions, I tried March 1st 8PM since I'm Eastern US. Do you have reason to believe it is relative to on UTC rather than client local time?

I wasn't immediately able to reproduce, but can try again after the weekend.

Thanks Finn for the detailed report! — Could you do me a favor and test Firefox 95? We did a major libwebrtc update in 96, and if this is a regression in behavior it would significantly improve our chances of locating the problem and prioritizing a fix.

> Our webrtc application is relying on adaption preference "maintain-resolution"

Firefox does not yet implement [degradationPreference](https://w3c.github.io/mst-content-hint/#dom-rtcrtpsendparameters-degradationpreference), so if this isn't a regression, this may be a duplicate of  bug 1329847.

But I'd like to understand better what is going on, and answer your questions.

> The timed condition seems to depend on client (!) system time and can be recreated by adjusting it into a time frame of occurrence

That certainly seems bizarre. What services are you able to reproduce this with? Is it using simulcast? Does it reproduce on a LAN or local loop 
connection? Have you replicated this on multiple machines?

Also, what does speedtest say your upload speed is? If it is limited then Firefox is sharing that with any other networking apps on the local system, or even cron jobs, and Firefox will reduce resolution if "estimated bandwidth"  (observable in about:webrtc) is low due to these other activities. I'm not aware of any studies being run within Firefox itself, but I'm on the WebRTC team so I wouldn't know for sure.

> set local system time to the equivalent of March 2nd 1:00am UTC

To follow these instructions, I tried March 1st 8PM since I'm Eastern US. Do you have reason to believe it is relative to UTC rather than client local time in the local timezone?

I wasn't immediately able to reproduce, but can try again after the weekend.