100% Low Video Quality since version 57, 58 stable
Reported by
sha...@companysocia.com,
Apr 22 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Example URL: appr.tc Steps to reproduce the problem: 1. Suppose WebRTC call: Peer A is located in London and Peer B is located in Amsterdam. 2. Now when connection happen Peer A public ip was: 8.8.8.8 3. But in the connection procedure Peer A public ip was changed to 9.9.9.9. And both were still connected then Peer B get very low bad video quality stream. What is the expected behavior? VIDEO quality cant be low, it has to be crisp and clear image. Even my public ip is changed or not it should not consider my video image to be low quality. What went wrong? While connection period if your public ip is changed then the quality is dropped. but in old version it was not the same. Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? Yes Chrome version: 58.0.3029.81 Channel: stable OS Version: 10 Flash Version: Contents of chrome://gpu: See screenshot here: https://bugs.chromium.org/p/chromium/issues/detail?id=713737#c3, see more details here: https://bugs.chromium.org/p/chromium/issues/detail?id=713737#c5
,
Apr 22 2017
Thanks for the bug report. To help figure out what's causing this, could you go to chrome://webrtc-internals and under "Create Dump" check "Enable diagnostic packet and event recording", then reproduce the issue and upload the resulting file? If possible, from both endpoints? A native log could also be helpful; see https://webrtc.org/native-code/logging/ Also, I have a question: after the public IP changes and the quality is reduced, does it recover?
,
Apr 24 2017
,
Apr 24 2017
deadbeef@: 1 - I will recreate the issue and upload the logs. 2 - once the quality was reduced there was no auto recover. the quality remained same until you disconnect that call and again reconnect (by making sure the IP was not changed this time)
,
Apr 24 2017
deadbeef@: Please find attached logs `chrome://webrtc-internals and under "Create Dump" check "Enable diagnostic packet and event recording"` 1) file PEERA-event_log.6.4 is the problem location with stable Google chrome (who have dynamic public ip, on call connect one public ip and then immediately public ip was changed. On the router public ip was not set to static, which is causing the quality drop for PeerB) 2) file PEERB.zip logs are the receiver who receives low quality from PEERA NOTE: Both locations are different locations. when PeerA is set to public STATIC ip then the quality remain perfect.
,
Apr 25 2017
Thanks for making the graph, deadbeef. Assigning to holmer@ for further investigation.
,
May 11 2017
,
May 18 2017
Cen we have the latest update on this issue?
,
Oct 24
Is this still an issue? |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by guidou@chromium.org
, Apr 22 2017