Stats graphs for send(video) in two-way apprtc call shows negative values in bitsSentperSecond graph on device Pit |
|||||||
Issue descriptionChrome Version: 52.0.2727.0 / 8302.0.0 dev Device: Pit What steps will reproduce the problem? 0. Browse to https://appr.tc/ from device Pit and desktop (Linux) 1. Open chrome://webrtc-internals in another tab 2. Listen for audio disruptions and watch for video stutter What is the expected output? Audio and video quality should be good without any disruptions. Actual result: 1. Device outgoing video is sometimes unclear 2. Chrome://webrtc internals shows low FrameRateSent in Stats graphs for send(video) = 5-10fps and sometimes as low as 0 fps and bitsSentperSecond graph shows negative values 3. Apprtc call freezes and system hangs resulting in a crash. Logs and Webrtc-internal dumps are here: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/611147/ Notes: This issue is observed 2/2 times of apprtc calls on device Pit but without any consistent repro steps. This bug will be updated with further details if it is observed again.
,
May 16 2016
glanced at the stats graphs, the packet loss number seems way high - if you're losing that many packets the sender will be generating new I-frames *all* the time (which is consistent with the high bandwidth usage). What's a pit, and what kind of connection was used for this test?
,
May 16 2016
Pit is an ARM based chromebook made by Samsung. Used "Google Guest" network for testing.
,
May 18 2016
This doesn't appear to be a recent regression, so I'm just going to set this to Available. cc'ing mflodman & jansson in case they know if this is a dupe. I'm pretty sure I've seen this on other non-ChromeOS platforms in the past too.
,
May 20 2016
Looking at the data in the "device-pit-hangout-with-desktop" file, I find this stat:
"ssrc_174872269_send-bytesSent": {
"startTime": "2016-05-11T20:22:53.414Z",
"endTime": "2016-05-11T20:28:27.432Z",
"values":
with the jumps
26700784,14640,
29735282,27908
6492608,10482,
So it's pretty certain something's zeroing the byte counter 3 times during the session. That shouldn't happen, ever.
Another "shouldn't happen":
"ssrc_174872269_send-codecImplementationName": {
"startTime": "2016-05-11T20:22:53.414Z",
"endTime": "2016-05-11T20:28:27.432Z",
"values":
"SimulcastEncoderAdapter (unknown, unknown, unknown)\",\"unknown\",\"SimulcastEncoderAdapter (unknown, unknown, unknown)\",\"SimulcastEncoderAdapter (unknown, unknown, unknown)\",\"SimulcastEncoderAdapter (unknown, unknown, unknown)\"
ie the codec implementation switches briefly to "unknown" , while normally being "SimulcastEncoderAdapter". This makes me want to CC pbos.
GoogleGuest in what network environment?
,
May 20 2016
,
May 22 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2017
,
Jun 21 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 2
I'm going to close this as I haven't heard of any recent issues with getStats and poor performance. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by phoglund@chromium.org
, May 16 2016