Is there a reason for the devices to be on 54? We suspect the issue might be related to the camera entering a bad state and not recovering out of that. I have tried to reproduce the issue on 61 but I do not seem to be able to reproduce this specific issue.

Hi.

I'm not entirely sure why the version was reported with 54 but I have been
able to reproduce this on version 59. I have not tried 60 or 61 yet but I
certainly can.

That would be great!

Will do. I will test on v60 and v61 tomorrow.

Hi.

I was able to recreate this issue on version 60.0.3112.101 on an Asus C301S
Chromebook.

Oddly enough though I was not able to reproduce on version 60.0.3112.80 on
an Acer Chromebook 14 CB3-431.

I'll be testing v61 tomorrow on both these Chromebooks.

Here's the chrome://version from the Asus C0301S

Google Chrome 60.0.3112.101 (Official Build) (64-bit)
Revision 0
Platform 9592.82.0 (Official Build) stable-channel terra
Firmware Version Google_Terra.7287.154.80
Customization ID ASUS-TERRA3
ARC 4263492
JavaScript V8 6.0.286.54
Flash 26.0.0.137 /opt/google/chrome/pepper/libpepflashplayer.so
User Agent Mozilla/5.0 (X11; CrOS x86_64 9592.82.0) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
Command Line /opt/google/chrome/chrome
--ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so
--ppapi-flash-version=26.0.0.137 --ui-prioritize-in-gpu-process
--use-gl=egl --enable-native-gpu-memory-buffers
--gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras
--enable-wayland-server --user-data-dir=/home/chronos
--max-unused-resource-memory-usage-percentage=5 --login-profile=user
--has-chromeos-keyboard
--default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/oem_large.jpg
--default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/oem_small.jpg
--default-wallpaper-is-oem
--guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg
--guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg
--enable-prefixed-encrypted-media --enable-consumer-kiosk
--arc-availability=officially-supported --need-arc-migration-policy-check
--enterprise-enrollment-initial-modulus=15
--enterprise-enrollment-modulus-limit=19 --login-manager
--first-exec-after-boot
--vmodule=*arc/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*plugin*=2,*zygote*=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2

After further testing I was able to create this issue on both Asus C301S
Chromebook and Acer Chromebook 14 CB3-431 on v60 and v61. We are using
https://opentokdemo.tokbox.com/ for testing.

I'm happy to provide any other details or testing if needed.

Thanks for your time.

This issue is still occurring on chromebooks, and we've seen this with various other models now. Are there any updates?

Re-assigning to Emircan for triaging.

We dont have those CrOS devices available any more. Assigning to people from SkyLab for bisect and logs.

Thanks for the detailed description about the issue. I will reproduce it and update here. Thanks!

Hi all,

I have tried to reproduce in 3 devices. I have failed to reproduce the scenario as mentioned in Step 3 in the description.

I have tried to reproduce in M66 dev and M61 versions respectively. Kindly have a look in the steps I have followed.

Steps follow:
1. Open opentokdemo.tokbox.com in Device A and Device B.
2. Join the call from both the devices with the same room,
3. In Device A let the wifi on,
4. In device B Keep switching on and off with 3 seconds interval.
5. repeat step 5 for 5-6 times

[Also tried turning off wifi in both the devices. It did not help either]

What happens?
video feed of A is is stopped in Device B. After a refresh all works fine. Issue is not reproducible in hangouts either. Hangouts not even mutes the remote video alike opentokdemo.tokbox.com. 

I tried the same in all the devices with M66 and M61. I feel I miss a key step to reproduce the issue. Can any one who reproduced the issue can review my steps? 


1. DEVICE A- Swanky device (Toshiba chrome book 2) Baytrail(Rambi)

Operating System:Linux x86_64 (Chrome Book)
Chrome Browser Version: 61.0.3163.140
Chrome OS Version: 9765.89.0
CPU: Intel(R) Celeron(R) CPU N2840 @ 2.16GHz ( x86_64architecture - 2 processors )
Memory: 2.49GB available out of 4.05GB

2. DEVICE B- Quawks Device(ASUS Chromebook C300) Baytrail(Rambi)
 
Operating System:Linux x86_64 (Chrome Book)
Chrome Browser Version: 61.0.3163.140
Chrome OS Version: 9765.89.0
Memory: 2.40GB available out of 4.05GBCPU: Intel(R) Celeron(R) CPU N2830 @ 2.16GHz ( x86_64architecture - 2 processors )

3. Device 3- Sentry[Skylake Family]: 

Operating System:Linux x86_64 (Chrome Book)
Chrome Browser Version: 61.0.3163.140
Chrome OS Version: 9765.89.0
Memory: 8.26GBCPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz ( x86_64architecture - 4 processors )

Crash report from Swanky: [May be interesting]
Uploaded Crash Report ID c981897142be8b96 (Local Crash ID: Chrome)
Crash report uploaded on Tuesday, March 20, 2018 at 1:09:43 PM
Uploaded Crash Report ID f85a56687ac7de08 (Local Crash ID: ChromeOS)
Crash report uploaded on Tuesday, March 20, 2018 at 1:09:14 PM
Uploaded Crash Report ID 5ac6337bcbc29841 (Local Crash ID: ChromeOS)
Crash report uploaded on Tuesday, March 20, 2018 at 1:07:06 PM

Did you use external camera in chrome book? Can you reproduce in M65 which is live now? Thanks a lot!

Hi vasanthakumar - 
Your steps look correct but sometimes it takes longer to trigger.  

If you down the wifi interface on one of the chromebooks, allow it to recover briefly (maybe 3-4 ping replies), and repeat. This will usually trigger the issue within a few minutes.

What is the real use case that triggers this behavior? Surely people do not sit and play with the wifi toggle on a Chromebook.

The use case we have seen is when the internet connection is really poor and repeatedly drops.

It will be hard to discern if its the local network, remote services, OS or the WebRTC in Chrome.

Could you include logs from chrome://webrtc-internals when the issue occurs?

Hi Billy, 

I am not able to reproduce still. Can you please upgrade to the latest chrome and reproduce the issue. Kindly share the logs as mentioned in #20 as well. 

Thank you!

Ping! 

Closing this ticket for now. If reproducible in the latest chrome version, kindly reopen again. Thanks!

Hi vasanthakumar - Yes, the bug still occurs in the latest version of chrome.  I was able to reproduce it today and I've included the requested logs.

Thanks,
Billy

Deleted: webrtc_internals_dump.txt 1.0 MB

webrtc_internals_dump.txt 1.0 MB View Download

Thanks Billy. 

I have reproduced partially the issue on Leon (Toshiba). Chrome: M66.0.3359.137 / 10452.74.0

Leon Configuration:
Operating System: Linux x86_64 (Chrome Book)
CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz ( x86_64architecture - 2 processors )
Memory: 4.08 GB

Santa Configuration:
Intel(R) Celeron(R) CPU N3350 @ 1.10GHz ( x86_64architecture - 2 processors )
Memory: 4.01 GB

Steps to follow:
1. Open opentokdemo.tokbox.com in Device A (Leon) and Device B (Santa).
2. Join the call from both the devices with the same room,
3. In Device A let the wifi on,
4. In device B Keep switching on and off 4-5 seconds interval.
5. repeat step 5 until the incoming video feed stops in Device A. 

After this moment, Leon does not get any incoming feed from Santa. I tried refreshing the browser and restarted the browser. It continues to send video to santa but fails to receive the feed. 

Note: After the state as mentioned above, I can perform hangouts call in Leon device without any flaws. This contradicts the statement as mentioned in step 3 in the original description. That is no webrtc calls can be performed after this state. 

Could this be two different issues?

Deleted: Santa logs.txt 203 KB

Santa logs.txt 203 KB View Download

Deleted: Leon logs.txt 147 KB

Leon logs.txt 147 KB View Download

Unfortunately those webrtc logs dont tell much. This is triggered by turning wifi on/off, probably related to network/bandwidth. deadbeef@ and holmer@ can you help with retriage?

The native log (https://webrtc.org/native-code/logging/) would be more helpful. The Santa internals dump contains 17 PeerConnections, so I'm not sure which one I should be looking at. Only one has send streams, which only sent 19 video frames/21 audio frames, and I don't see a matching SSRC in the Leon internals dump.

But maybe someone more familiar with debugging "blank video" bugs knows what to look for. Adding Video component.

Could you please try to repro and include the native logs?

Thank you! I have attached the logs of santa and leon correspondingly. 

@related to many peer connections: This is for some reason caused by opentokdemo.tokbox.com webapp. I just noticed similar peers are seen in both these devices. 

Deleted: Santa_logs.tgz 3.7 MB

Santa_logs.tgz 3.7 MB Download

Deleted: leon_logs.tgz 558 KB

leon_logs.tgz 558 KB Download

The only messages in the "chrome_system_log" are multiple instances of:

[1:24:0504/162623.570999:WARNING:paced_sender.cc(261)] Elapsed time (274860 ms) longer than expected, limiting to 2000 ms

And:

[1:15:0504/162629.045589:WARNING:srtpsession.cc(135)] Failed to unprotect SRTP packet, err=9
[1:15:0504/162629.046952:ERROR:srtptransport.cc(240)] Failed to unprotect RTP packet: size=919, seqnum=35321, SSRC=2

The former message probably caused by the second.

I believe this is  crbug.com/835958 . It would occur if a new offer/answer is performed after an RTP sequence number rolled over, and I imagine turning Wi-Fi on/off will trigger an ICE restart which would do that.

Can you confirm what versions of Chrome are being used? Looks like it may be 67.0.3396.26, and this issue affects versions 67.0.3387.0 through 67.0.3396.28. 

Hi, 

I have used 67.0.3396.19 build for Santa and 66.0.3359.137 on Leon. Please let me know if you need any help from me. Thanks!

Taylor, please close if you consider this a dupe.

Since 67.0.3396.19 is an affected version, sounds like it is.