Webex chrome app has host's video buffering when host video in thumbnail
Reported by
pan.dev....@gmail.com,
Jun 3 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Steps to reproduce the problem: 1. Host starts a meeting in thinclient13.webex.com site, and send video(do not join audio) 2. Thin client1 joins in meeting using (chrome app/firefox) and join voip 3. Thin client2 joins in meeting using chrome app 4. Check thin client2 whether it can see host's video in thumbnail What is the expected behavior? Thin client2 should see host's video in thumbnail What went wrong? Thin client2 see host's video buffering when host video in thumbnail Did this work before? N/A Chrome version: 52.0.2727.0 Channel: dev OS Version: 7 Flash Version: Shockwave Flash 21.0 r0 No such issue seen on Fiefox
,
Jun 17 2016
Can you check the receive video feeds under webrtc-internals and verify that the channel is receiving data?
,
Jun 17 2016
Yes, the peer-connection is receiving data but sending a lot of PLI requests. There is no such issue on Firefox. Also on Chrome 51 with H264 enabled, there is no such issue, but on Chromebook, it keeps on sending PLI. But as soon as any other event like join audio/video from another client happens, the video is back
,
Jun 23 2016
,
Jun 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/371076858624f9f2619703fa7ef2e1909a8ee733 commit 371076858624f9f2619703fa7ef2e1909a8ee733 Author: emircan <emircan@chromium.org> Date: Thu Jun 30 23:55:16 2016 Consider non-keyframes for RTCVideoEncoder error counter This CL addresses the bug below. Earlier on, we experimented and decided that we would fallback to SW decoded after 50 consecutive HW decode errors. However, after an error in keyframe, non-keyframes would be dropped and not added to the error counter. As a result, we would wait for 50 keyframe errors before SW fallback, which takes a long time. This CL fixes the issues resulting from this. BUG= 616968 TEST=Tried the problematic Cisco stream referred in bug. First 3-5 seconds, we don't get a video(due to HW errors) but works afterwards(falling back to SW). Review-Url: https://codereview.chromium.org/2093823002 Cr-Commit-Position: refs/heads/master@{#403353} [modify] https://crrev.com/371076858624f9f2619703fa7ef2e1909a8ee733/content/renderer/media/gpu/rtc_video_decoder.cc [modify] https://crrev.com/371076858624f9f2619703fa7ef2e1909a8ee733/content/renderer/media/gpu/rtc_video_decoder.h [modify] https://crrev.com/371076858624f9f2619703fa7ef2e1909a8ee733/content/renderer/media/gpu/rtc_video_decoder_unittest.cc
,
Jul 11 2016
Thanks, we have verified with Dev Version 53.0.2785.4, and this issue doesn't occur anymore. Waiting for QA to verify across different chrome-book devices. Will mark it resolved once this has been verified
,
Jul 19 2016
,
Apr 13 2018
What codec does cisco client use? For VP8, #5 CL is too harsh, because iframe of vp8 doesn't know size. Once drop of frame happens, vp8 decoder vary easily fallback to software forever. |
||||
►
Sign in to add a comment |
||||
Comment 1 by rnimmagadda@chromium.org
, Jun 3 2016