alksandr.v@: Can you provide a URL for easier testing?

https://77485303.myownmeeting.net
MODBC7DBE2D 1L6R3R5H
MODD81827C5 3R1H5I5M
guest login is also possible

I note again, it's hard to trigger a bug. The more camera bitrate and client load the easier to trigger it. webrtc-internals stops to draw graphs just in foreground, background myownmeeting tab stops to receive data in websockets according to devtools network tab, no JS timers are running and so on, the only working thing on background myownmeeting tab is webrtc. As soon as I switch back to myownmeeting tab - JS starts to respond, websockets receive some data and disconnect due to timeout.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Does this only happen on Mac? I'm working with a different freeze bug relating to unmuting the camera in a webrtc call and it only happens on OSX and only in release builds.

This one: https://crbug.com/813574

>Does this only happen on Mac?
We still not able to reproduce this issue on Win

Unable to test this issue with test file given as we are seeing "OOPS 500 error" on signing to https://77485303.myownmeeting.net with credentials given in comment#2. Attaching screencast for reference.

@Reporter: Could you please give us alternate URL or credentials to test this issue from TE end.

Thanks!

Deleted: 821378.mp4 3.9 MB

	821378.mp4 3.9 MB View Download

@sindhu.chelamcherla
We fixed OOPS 500, sorry about it. Can you pls test now?

Thank you for providing more feedback. Adding the requester to the cc list.

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

Here is screen capture 2 min video with bug https://vimeo.com/260930832 . MacOS 10.13.3, Chrome Version 65.0.3325.146 (Official Build) (64-bit)

hbos@: Can you take a look and see if this could be a duplicate of bug 813574?

#11: Thanks for the video.

#12: I'm guessing it's not a duplicate because the tab unfreezes when you return to it and "Similar behavior on Chrome 64". Bug 813574 is more recent and does not unfreeze or involve multiple tabs.

How hard is this to repro? Is it possible to repro on a small testpage like a jsfiddle.net/ ?

>How hard is this to repro?
It's easier to reproduce under heavy load, like high bitrate camera and high resolution screen sharing. We cannot reproduce it with appr.tc.
 
> Is it possible to repro on a small testpage like a jsfiddle.net/ ?
I don't think so

NextAction Reminder to myself to check back if this is fixed in canary after https://crbug.com/813574 is fixed (change in commit queue)

The NextAction date has arrived: 2018-04-03

There has been similar issues where the tab is freezing for a long time (e.g. 86s) and then unfreezes, like  https://crbug.com/829831 , which I can't repro and looks unrelated to code I am familiar with. I will try to reassign these.

aleksandr.v@ can you go to chrome://tracing and record a trace while you repro the problem, then attach the file here?

>can you go to chrome://tracing and record a trace while you repro the problem, then attach the file here?
Will do it as soon as reproduce the bug

Web developer trace  attached, had to re-compress with XZ, as default gz doesn't fit 10MB limit

Deleted: trace_bug.json.xz 6.9 MB

trace_bug.json.xz 6.9 MB Download

Thanks. Hmm... I don't see any obvious culprit.

Should I recreate trace with some specific options?

Are you able to create a dump for when it is stuck and attach it here?
https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs

Cannot find crash file under  ~/Library/Application Support/Google/Chrome/, no Crash report directory. Crash uploaded as crash/5da7c32c048e0f38 crbug.com/837249 , Chrome 66 is still affected. Do you able to access it ?

Issue 837249 has been merged into this issue.

The crash is showing thread 34 is doing h264 encoding and thread 0 crashes inside a mach_msg call (essentially idle). So my guess here is some type of memory corruption by the H264 encoder? Seems to still be a WebRTC issue.

Original description said it was just frozen. Did you crash the browser while it was frozen or is this a different issue?

The crash (crash/5da7c32c048e0f38) is in the OpenH264 encoder, assigning to sprang@.

> Did you crash the browser while it was frozen?
Yes, as noted on https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs ,  kill -ABRT , it produces crash dump. 

Ok great :)

ssilkin@ could you triage?

aleksandr.v, is the issue still reproducible in later chrome versions (e.g. 67)?

yes, we still can reproduce this bug

aleksandr.v, would it be possible to restore the access to myownmeeting.net (#2)?

yes, you can test it at our test account
https://38915599.myownmeeting.net
login: MODFDB44133, password: P2H4B6B2
login: MOD37D137A9, password: 1P5H3J1P

I successfully logged in. How can I run video capturing and streaming?

click "Talk Now" please

or go to Desktop tab and click "Start Sharing"

It seems it only allows one-way video. I get 'Speakers limit reached' message on attempt to send video from the second client. How do I send video from both clients simultaneously?

updated - now you can use several speakers in one time

I got video floating in both ways. I joint the meeting from Linux machine and from Mac. I couldn't repro the issue on Mac with Chrome 68.0.3440.84. I managed to get 1mbps received video bitrate. Also, tried to apply packet loss (you had some according to your recordings in #11).

Is H264 only supported codec in your conferencing? If not, then could you please try VP8/9 and see if you still get the issue?

Deleted: Screen Shot 2018-08-02 at 5.24.28 PM.png 985 KB

	Screen Shot 2018-08-02 at 5.24.28 PM.png 985 KB View Download