Latency with Logitech C930e camera during apprtc loopback call on device jerry |
||||||||||||||||||||||
Issue descriptionChrome Version: 50.0.2661.14 / 7978.5.0 dev Device: Jerry What steps will reproduce the problem? Precondition - Plug-in a Logitech c930e webcam to the device Steps: 1. Join an AppRTC loopback call https://appr.tc/?debug=loopback ond evice Jerry 2. Ensure the call uses Logitech webcam (media settings in chrome) 3. Open chrome://webrtc-internals in another tab 4. Expand the Stats graphs for ssrc_*_recv (video) and scroll down to the googTargetDelayMs graph. Observe that googTargetDelayMs graph shows 400ms constantly Expected results: Latency should stay under 200ms and should not keep increasing forever (Reference bug: https://bugs.chromium.org/p/chromium/issues/detail?id=584015) Actual result: Latency is constantly around 400ms during the apprtc loopback call Please find attached javascript logs during apprtc loopback call and generate_logs from device Jerry
,
Mar 6 2016
+pbos: even if this is not an AVsync problem (I think), could this be related to https://bugs.chromium.org/p/webrtc/issues/detail?id=5456 ? Or do we think it's a Chrome OS or driver issue?
,
Mar 7 2016
srcv@ - for this issue, and any future ones where you cite chrome://webrtc-internals data, instead of taking a screenshot of that page, please attach the raw data file (Create Dump->Download the PeerConnection updates and stats data). For this specific issue, it's suspicious that so many stats are at a fixed value, but I can't dig deeper without more data. :) I'm assigning this back to you for now; once you've attached the raw webrtc-internals data, please set this back to "Untriaged." Thanks!
,
Apr 7 2016
Tested apprtc calls on device Jerry with M50 50.0.2661.67 / 7978.48.0 beta build and Logitech 930e camera plugged in. Observed that latency(googTargetDelayMs) i sunder 200ms through out the apprtc call.
,
Sep 23 2016
Observed this issue on device Jerry with M54 54.0.2840.36 / 8743.38.0 beta WebRTC internal dump from device Jerry : https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/592128/
,
Sep 26 2016
,
Sep 27 2016
mflodman@ can you triage this one since I'm no longer on the team? :)
,
Sep 27 2016
+ some people who might know something about timestamps if it rings a bell
,
Sep 28 2016
Note that camera timestamp handling was changed considerably in https://codereview.chromium.org/2270723002, which was landed after the M54 branch cut. The new code is intended to handle clock drift in camera timestamps well, but I haven't got to test it with any problematic camera. So if you can test with a more recent Chrome, that would be great. Are there any end-to-end tests of Chrome that monitors this delay? It would be good to have some fake camera for testing, where tests can tweak the clock drift of camera timestamps. But I'm not at all familiar with this level of the testing frameworks.
,
Sep 28 2016
Re #9: All the machines in http://build.chromium.org/p/chromium.webrtc/waterfall and http://build.chromium.org/p/chromium.webrtc.fyi/waterfall have webcams equipped so any test that runs there be configured to gather perf data from the stdio output (content_browsertests and browser_tests already do this). I don't know the details on what existing perf metrics that are already in place for this. I think you'll have to dig into the source code to see that. Code search like https://cs.chromium.org/search/?q=%22perf_test::%22+file:%5Esrc/chrome/browser/media/webrtc/&sq=package:chromium&type=cs and https://cs.chromium.org/search/?q=%22perf_test::%22+file:%5Esrc/content/browser/webrtc/&sq=package:chromium&type=cs should give you an idea.
,
Sep 30 2016
,
Feb 9 2017
This issue is not observed with M57 57.0.2987.35 / 9202.20.0 beta. Closing this issue for now and will be reopened if it is observed again. |
||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||
Comment 1 by srcv@chromium.org
, Mar 5 2016