I had to remove log file. It had too much info. Here is snapshot from initial log file. After i get Message that call is connected this is what takes place.

Deleted: chrome_debug_Partial.log 18.0 KB

chrome_debug_Partial.log 18.0 KB View Download

Thanks for filing the issue!

Checked the issue on reported chrome version 64.0.3282.140 and on the latest canary 66.0.3343.0 using Windows 10 Desktop and Surface Pro. 
We are able to connect the call through WebRTC and video is proper.

@Reporter: Could you please mention whether the issue is specific to mobile device and please let us know whether Chrome in Windows is crashing or on Mobile. Your Feedback helps us to triage the issue in a better way.

Thanks! 

moysha@: Is it possible to send any crash ID? They are available in chrome://crashes

Answer for comment 3: the crash is on Chrome for windows 10.  I was just upgraded to Version 64.0.3282.167 (Official Build) (64-bit).  It took four calls to get it to crash.

Answer for comment 4: here's a crash id:
Uploaded Crash Report ID 8b922958d2c886e2 (Local Crash ID: 16bf9389-bf1d-4089-906d-f33c0f6bbaad)
Crash report captured on Thursday, February 22, 2018 at 8:46:50 PM, uploaded on Thursday, February 22, 2018 at 8:46:51 PM

Contact me, I can help you recreate the problem.

Seems related to injectable video codecs. Anders, you seem to have been working on this, can you take a look?

holmer@ - can you point to what makes you think this is related to injectable video codecs (injectable SW codecs I guess?). I looked at the crash report and the log attached in this thread but couldn't find anything relevant.

We're hitting a CHECK here:
https://chromium.googlesource.com/external/webrtc/+/d60d5c4479d2a01bcf56224bbaddf4b8c3e9c0d2/media/engine/webrtcvideoengine.cc#2240

which was added here:
https://chromium.googlesource.com/external/webrtc/+/063f0c0d3ac62f9110d54c7fea8aed7722264600

Ok, now I see. If we hit that check it means that we are trying to create two identical decoders. Can we get the log for the SDP negotiation? Would we ever want to support creating e.g. two identical VP8 decoders? We could probably easily support that if we change the map to a multimap, but I would like to understand the use case first. Or is this bug easy to reproduce?

You have been busy.  I just tried version 64.0.3282.186, so far it hasn't crashed yet. I'm attaching a file with offer/answer SDP's, per your request.  Thank you for your hard work.  I will keep testing and let you know the results.

Deleted: sdp_digits_20180223.txt 6.4 KB

sdp_digits_20180223.txt 6.4 KB View Download

I just realized that we have not mentioned the case that we change profile ID in SDP before setting local description. We had issues with Samsung devices and in version 63 changed profile ID to 42e01f. That worked well since 63 had only one codec section with one profile ID. In 64 I noticed that it has 4 codec sections with 4 different profile IDs. So, our logic changed all profile IDs to the hard coded value. Set local description was successful, but after setting remote description we got this crash. If we do not change profile IDs, then no crash. But Samsung devices have green video screen.

Ok, that's why it's crashing - it's assuming there are no duplicate codecs. We should fix that. For now, can you make sure you don't create duplicate codecs when you modify the profile IDs? That should solve your problem.

We did it already. However, this change causes green video screen on all Samsung devices. S6/S7/S8. How do we solve this?

The green video is a separate issue from the crash reported here. I sounds like it's a problem with the HW encoder on Android encoding H264 high profile. Can you file a separate bug for the green video issue and assign it to braveyao@ who works with the Android HW encoder?

I looked at the SDP a bit more and the SDP answer which you say is generated by Macbook pro, Electron client (Chromium 59), returns profile-level-id=42C00C, which is H264 Constrained Baseline, but it's using the payload 100 which in the offer (from Windows 10, Chrome Version 64) is H264 Baseline. What kind of code is generating this answer? It doesn't seem to be correct. Maybe that's related to the problems you are seeing.

I will file a new bug for green screen. Thanks.

I submitted new issue for green screen: Issue 817403. But i do not see how to assign it to someone.

Here is SDP exchange between Win10 Chrome 64.0.3282.186 and Samsung S6+ Edge. S6 is native video over LTE. The same issue is applicable for Samsung S 7/8.

Please note that only test 4 is successful when i force profile to 42e01f.

1) Test1.log Chrome 64 makes a video call to S6. No profile changes. 
   Video OK on Chrome, green screen on S6

2) Test2.log Chrome 64 makes a video call to S6. With profile changes. 
   Chrome crashes.

3) Test3.log S6 makes a video call to Chrome 64. No profile changes.
   Video on Chrome OK, S6 green screen

4) Test4.log S6 makes a video call to Chrome 64. With profile changes.
   Video OK on both sides.

Deleted: Test1.log 6.1 KB

Test1.log 6.1 KB View Download

Deleted: Test2.log 6.1 KB

Test2.log 6.1 KB View Download

Deleted: Test3.log 7.7 KB

Test3.log 7.7 KB View Download

Deleted: Test4.log 7.5 KB

Test4.log 7.5 KB View Download

It's crashing in 2) because of the duplicate codecs. The reason it works in 4) is because there is only one H264 codec. Anders will land a fix for the crash soon, but that will only help newer version of Chrome. If you want a short term workaround, you can change your SDP filtering so you remove all H264 codecs except one.

The issue with the green screen is tracked in the other bug. The difference between 1) and 4) is that H264 Baseline profile is negotiated in 1) while H264 Constrained Baseline Profile is negotiated in 4). I added this information to the other bug.

Thanks for your help. I will try your suggestion for sort term workaround.

Do you have Chrome version that will have this crash fix?

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/7dbb701076f33e459cd3bc89a49bfec43b359545

commit 7dbb701076f33e459cd3bc89a49bfec43b359545
Author: Anders Carlsson <andersc@webrtc.org>
Date: Wed Mar 07 09:57:16 2018

Fix crash when setting duplicate receive codecs.

Instead of crashing, log a warning.

Bug:  chromium:810173 
Change-Id: I7e43889fdab429fcb231657f5770b0ff26f34a8f
Reviewed-on: https://webrtc-review.googlesource.com/59020
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22322}
[modify] https://crrev.com/7dbb701076f33e459cd3bc89a49bfec43b359545/media/engine/webrtcvideoengine.cc

The fix just landed and will go into Chrome 67. I'm going to mark this issue as fixed since the green screen issue is tracked in a separate bug.

It would be nice if you can verify that the fix is working. You can download Chrome Canary on Mac and try it out.

Thanks. Will do.

Do you have Chrome Canary for Win10 available with this fix?

Yes, you can download it from here: https://www.google.com/chrome/browser/canary.html