Packet loss when sending screen share
Reported by
pan.dev....@gmail.com,
Aug 30 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:54.0) Gecko/20100101 Firefox/54.0 Steps to reproduce the problem: 1. Send screen sharing from Chrome browser, receive the sharing on another PC. 2. from sharing side, switch the content to create some busy scenes 3. the sharing content on the receiving side is stuck and takes very long to recover; from the sharing chrome browser, the webrtc-internal stats shows high packet loss numbers What is the expected behavior? the sharing should be smooth on the receiving side, and there shouldn't be so much packet loss. What went wrong? Looks like the lost packets are triggered by the high bitrate and high packet rate during the scene change. Attached a screen capture from webrtc-internals, and a webrtc-internals dump file. Did this work before? N/A Chrome version: 60.0.3112.113 Channel: stable OS Version: OS X 10.10 Flash Version: Shockwave Flash 26.0 r0 Firefox seems to be able to handle similar situations better.
,
Aug 30 2017
,
Aug 30 2017
Looks like the Dev channel chrome has much better performance on this. Will keep testing to see if this is resolved.
,
Aug 30 2017
The problem in the other bug is that background tabs get down-prioritized and we start losing packets over IPC in Chrome. WebRTC tabs are supposed to be exempt from backgrounding, but that only applied to tabs with audio (might not be the case for screensharing). This is fixed in 61.
,
Aug 31 2017
,
Sep 6 2017
pan.dev.cisco@, Could you please check this issue as comment#3,4 & update the thread accordingly. Thanks..!!
,
Nov 24 2017
As there is no response from the reporter for comment #6 for more than two months and as per C#3 & C#4, closing the issue as WontFix. pan.dev.cisco@ Please feel free to raise a new issue if the issue is reproduced with latest chrome builds. Thanks...!! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by niklase@chromium.org
, Aug 30 2017