Attaching offer/answer SDP files for S7 and S8

Deleted: S7_to_Chrome64_green_screen.log 6.9 KB

S7_to_Chrome64_green_screen.log 6.9 KB View Download

Deleted: S8_to_Chrome64_green_screen.log 6.9 KB

S8_to_Chrome64_green_screen.log 6.9 KB View Download

Unable to reproduce this issue on reported version 64.0.3282.186 using Windows 10 and One plus x. Tried video calling using both Hangouts and webrtc experiment (https://www.webrtc-experiment.com/video-conferencing/#8114301136889). Video is clear without any green screen on both desktop and mobile.

As mentioned in above comments this might be related to Samsung s6/s7/s8. As ET team do not have these mobiles handy forwarding this to Inhouse team. Hence adding TE-NeedsTriageFromHYD label. Could someone from Inhouse team please have a look at this issue. 

Thanks!  

I thinks it's related to Android HW codecs.

Prior to Chrome 64 we had to change profile in Chrome offer to device to 42e01f. That worked. Video on both sides. In Chrome 64 if we change profile then Chrome crashes after we apply answer SDP to remote description. We have removed logic and keep profiles in the offer without change. After this change all Samsung devices have green video screen. 

Is the call made from Chrome on Android device? The SDP doesn't look like the one from Chrome on Android.

it is from Samsung to Chrome. In log files i have separated offer from device to Chrome.

I know it's from Samsung device. But is it Chrome on the Samsung device which makes the call? Or other APPs?

there is offer from device then answer from Chrome, then re-invite from device and answer from Chrome

Chrome is on Win10

So what's the APP on Samsung device?

Samsung is native video over LTE

Thanks. That's I want to know. :)

It's not Chrome on Android side. So this problem is more likely at Chrome Desktop on Windows, HW or SW H264 or multi-profile-negotiation, depends on the platform Chrome runs on. 
emircan@, could you please have a check first? Probably it's HW H264 on Win.

PS: If it's HW H264, then most probably it won't encode CBP.

Can you try "disable-accelerated-video-encode" on Windows to see if that fixes the issue?

how do i disable it?

You can start chrome with --disable-accelerated-video-encode flag, i.e. chrome.exe --disable-accelerated-video-encode.

Tried your suggestion. See no difference. 

I just double checked, that flag is available after 65. Can you try --disable-webrtc-hw-encoding and --disable-accelerated-video-decode as well? You can try them separately.

Testes with suggested flags:
64 -> S6 - OK
S6 -> 64 - OK

64 -> S7 - OK
S7 -> 64 - OK

64 -> S8 - OK
S8 -> 64 - OK

This is working. But, I cannot ask end users to change command line to run Chrome with these params. How can this be done form my JavaScript code? Or maybe WebRTC API function/flag?

Ran another test with only --disable-webrtc-hw-encoding para. Looks good as well.

Thanks, this means S6 has trouble decoding Media Foundation HW encoder output coming from Windows. It is available when there is an Intel GPU. 

AFAICT, this is an S6 only issue on the decode side based on #3. I dont have a S6 setup to test right now. Can you help by checking if S6 decoder is printing any logs indicating what is the trouble? We need to find out why decoder doesn't properly parse this.

This is Samsung S 6/7/8 issue

Thanks, but unfortunately I don't have any of those right now. Some debug logs explaining what is happening on decoder would really help. Also, Chrome in Windows offers CBP as well in the SDP negotiation, which is OpenH264 based (42e01f is OpenH264 and 42001f is MediaFoundation codec). You can change SDP negotation to use CBP codec. I think in your first offer if you do not offer 429016, it should fall back to CBP automatically. Or you can skip 42001f offer coming from chrome.

What do you mean by skip 42001f offer coming from chrome? Remove it form SDP? Or change it to 42e01f? Leave all other profile IDs as is?

Chrome offers 42001f and 42e01f in SDP.

It also offers 4d0032, and 640032 profiles

429016 profile is only offered by S6. S7/8 do not offer this profile. But they also have green screen.

42800C is offered by S7 and S8. But Chrome responds with 42001f

Any suggestions? What do i do with Chrome multi profiles to force OpenH264?

moysha@ -- Thanks for reporting this issue. Could you please share the details of the application through which video call is made as we were unable to reproduce the issue by performing the video call using hangouts on Samsung S7 Android 6.0.1 Build/MMB29K and Chrome Desktop #64.0.3282.186.

Steps Followed:

1. On Chrome Desktop navigate to https://hangouts.google.com/
2. Initiate a call to hanouts app on Samsung S7 device.
3. Answered the call on Samsung device.
4. Observed that user is able to perform the video call without any issues.

Perform the above steps vice-versa by initiating the call from application to desktop and no issues observed during the call.

Also, verified with the flag --disable-webrtc-hw-encoding enabled and didn't notice the issue

If we can know the application through which the issue is noticed, we can reproduce and triage the issue further.

Thanks in advance!

I just want to add a piece of information I got from the other thread in https://bugs.chromium.org/p/chromium/issues/detail?id=810173. Everything works when H264 CBP is negotiated. The green screen problem is only when H264 BP is negotiated.

pnangunoori@ can you post SDP that was exchanged between Chrome and S7 in your test.

Thanks.

> What do you mean by skip 42001f offer coming from chrome? Remove it form SDP? Or change it to 42e01f? Leave all other profile IDs as is?

Yes, I am suggesting removing it from SDP(You can follow "SDP munging" guides for examples). I cannot see that in #1, but Chrome should be offering 2 profiles: profile-level-id 42e0* is OpenH264 based CBP and 4200* is MediaFoundation based BASELINE codec. If you negotiate CBP, it would skip HW encoder all together.

Thanks. Let me try.

Tried your suggestion. Removed all H264 codec section with exception of one. Then changed profile ID to 42e01f. S6 works. No Chrome crash. Will test later today on S 7/8. 

When removing H264 profile section had to remove rtx/9000 section as well that has a reference to H264 section, otherwise get set local description error:

a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:125 cmm tmmbr
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032

a=rtpmap:107 rtx/90000
a=rtcp-fb:107 cmm tmmbr
a=fmtp:107 apt=125

Is this a permanent solution to force H264 CBP? Or you guys will have more elegant fix?

Unfortunately, it's the way to go right now for Chrome users to select video codec, we have no other interface.

Instead of removing or changing codecs, it might be easier for you to re-order the list of video codec payload types, i.e. the "m=video" line. If you place H264 CBP first it will prioritized.

Thanks, glad to see you have SDP going.

Still we need to investigate what is going on in S* decoder when it receives MediaFoundation encoded stream. If you have any logs that decoder outputs that you can share, that would be a great start. It will take me couple more days to get a device where I can test. Additionally, can you explain how we can test this, considering #31 couldn't repro?

I do not have logs from Samsung devices.

This is video Digits project for T-Mobile. It is not released yet, only audio was released to T-Mobile customers. So, video release is still internal to us. I would like to see SDP exchange for #31. If you can upload them, i can compare to what we send/receive.

Unfortunately, I cannot make any more progress on this if it isn't testable on our end. 

Assigning to pnangunoori@ for the requested logs.

Can someone provide the command/steps to grab SDP exchange information.

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

Magnus, do you have the requested instructions?

The app in question is a custom Android app, apparently video Digits project for T-Mobile according to comment #39. Someone from that project need to provide the information.

Is this issue still available in the latest chrome?