[stable30] Fix (known) false positives in connection warning #14251
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![backportbot[bot]](https://avatars.githubusercontent.com/in/60201?s=60&v=4){kind=small}
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Chromium does not provide "packetsReceived" in "remote-inbound-rtp" Signed-off-by: Daniel Calviño Sánchez <[email protected]>
When the initial stats reports are added the first value of cumulative stats is used as a base when converting the rest of values to relative. Therefore, that initial value is not meaningful and should not be used in calculations, as otherwise the reported quality would be off. Due to that now no quality is reported until the values of the first report added were shifted. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
In the past it was observed that the timestamp and round trip time were updated when the stats stalled (so only the received packets actually stalled). However, nowadays it seems that the timestamp and round trip time can also stall. This caused the stalled timestamp to be computed as 0, and that in turn messed with the rest of calculations (for example, generating a NaN for the number of packets per second) and causing a "very bad quality" to be wrongly reported. To solve that now the timestamps are evenly distributed when they unstall. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
In the past it was observed that, even for small videos, 10 packets per second was a reasonable threshold to detect connection issues even if there were no lost packets. However, nowadays it seems that it can sometimes trigger a false positive (typically when the background blur is enabled and the video quality is reduced due to being in a call with several participants), so for now the connection problem is no longer reported to the user but just logged. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Due to a bug in Firefox and/or Janus, when using simulcast video the remote report for one of the streams (typically the lowest quality one) may start with garbage values. This causes the received packet count to be reported the maximum integer value minus the packet lost count (which is usually around a few thousands). When newer stats arrive the received packets start to increase from that extremely high value, and eventually it overflows, causing the received packet count to go back from ~4294967295 to ~0. In other cases it was seen that the received packet count can regress a few values, although it is not clear when or why (this was much rarer and not reproducible, unlike the scenario described above). To prevent the regressed value from distorting the analysis due to the packet count being < 0, and as in both cases once the packet count regressed the received packet count in all following stat reports increase from the regressed value, now the stats are reset when a lower packet count is found. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of PR #14095