connection 19293-4 is the one which shows the issue in the attached dump. The peerconnection stays up and continues to receive video, local video is also shown. But no video is sent. Looks like audio is sent but might not be played due to lip sync requirements?

Deleted: androidfreeze.json 459 KB

androidfreeze.json 459 KB View Download

note: its not clear if the turnonly and bandwidth=500 flags affect it. I've also seen it on direct p2p connections.

if there are any logs I can collect to help analyzing this i need instructions how to get them.

oh... android 7.1.1 on a nexus 9 (which were handed out at i/o 2014)

By writing "this is not the issue where video on android freezes", do you mean that you think this issue is not a dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=769148 ?

I just tried on 61.0.3163.98 on Android 8.0.0, but could not repro after 5 min of calling. How long does it take you to get the freeze?

#7: yes, its different from that
#8: typically less than a minute. I can't reproduce after a reboot though some it might be related to some flags.

It seemed quite similar to  issue 762527  but that only happened with the native addTrack which is still behind a flag and should not be used by us in M61 even when that flag is on.

can repro again after activating experimental web platform features -- which is good since it makes it less likely that a user is affected.

Need to double check on "should not be used by us in M61", hold on...

I still cannot reproduce with Chrome stable on neither S8+ or Nexus 6.

Did you use the experimental features?

yes, experimental web platform features is on.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I also saw this in the adb output but that seems like a result of receiving an RR for the own video and the sequence number did not increase:
10-23 18:47:22.892  6091  6296 W chromium: [WARNING:rtp_rtcp_impl.cc(205)] Process: Timeout: No increase in RTCP RR extended highest sequence number.

Currently using adb logcat chrome:V per https://chromium.googlesource.com/chromium/src/+/master/docs/android_debugging_instructions.md#Log-output

Tested the issue on Chrome Stable# 61.0.3163.98 / 62.0.3202.73 using Android 7.0 using Samsung SM-J710F and could not reproduce the issue.

Opened the URL, "appear.in/some-room-name?turnonly&bandwidth=500" on Mac and connected with Android. Continued the video call for more than 30 minutes and could not observe any freeze on Android OS.

@fippo@appear.in -- Could you please let me know if I have missed anything else.
Thanks in Advance.

#17: the experimental web platform features flag is set (which is somewhat tricky)

I can easily reproduce and am happy to gather logs. But see #3

Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue in Android. 

Steps Followed:

1. Launched the Chrome Browser.
2. Navigated to the 'appear.in/some-room-name?turnonly&bandwidth=500' on Desktop Chrome and Android.
3. Joined the same room.

Observations: 
1. Video and audio didn't hang and call worked normally.

Chrome versions tested:
62.0.3202.84

OS:
Android 8.01.0 & 7.0.0

Android Devices
Pixel XL Build/OPR3.170623.008 & SM-G928G Build/NRD90M

As issue is not reproduced from TE's end, could someone from WebRTC team kindly look into this issue.

Thanks!

fippo, I tried chrome on android with "experimental web platform features" enabled and haven't been able to reproduce so far (pixel phone to chrome linux) with M62.

Can you confirm it's still an issue?

You mentioned that enabling the "experimental web platform features" is tricky. Are there more steps required than to go into chrome://flags, enable it, and restart the browser?

can't reproduce anymore (61.0.3163.98). Instead I get very odd decoding errors now *on* android. Will file another bug if those persist.

now that I gave up it happened again... might be packet loss.

@fippo -- Can this issue be closed as per your comments #22 & 23.

yes, lets close it as it no longer reproduces.

Marking this issue as WontFix as per the comments #22, 23, 25. Please feel free to file a new issue if reproduced on latest builds.

Thanks!