Update MethodCallHandlerImpl.java

[mb1shka]

Problem, that was solved:
When I made a call from IOS to Android, IPhone didn't see remote video from Pixel/Samsung/OnePlus (other brands I didn't check).

It all was because H264 was disabled and video couldn't be properly encoded.

[ycherniavskyi]

I want to clarify the modified third parameter with the actual name enableH264HighProfile.
First of all, it is not enable/disable H264 - it switches high/baseline profile modes of H264.
Also, after investigating the source code of HardwareVideoEncoderFactory class in WebRTC SDK, I could agree that assigned in this PR default value for this parameter is the correct fix. Here is some evidence:

• TODO in code

// TODO(sakal): Always add H264 HP once WebRTC correctly removes codecs that are not // supported by the decoder. 

• isH264HighProfileSupported check if high profile mode of H264 is available and apply it only in such case

@hiroshihorie do you agree with this with modification (with blame I identify that your are the author of current default value of enableH264HighProfile parameter)?

[ycherniavskyi]

Sorry for accidental close ☺️.

[hiroshihorie]

@davidliu Can you take a look (is this needed) ? thanks !

[davidliu]

Hmm, this is weird; High Profile is a "should" supported format, while Baseline is a "must" supported format according to WebRTC spec. High Profile shouldn't be needed just to get video running (and seems to be working fine on the LiveKit example apps calling between iPhone and Android). I wonder if there's something else causing the original issue?

[davidliu]

With regards to the PR itself, it should be fine to enable High Profile.

[davidzhao]

I think this will be challenging for web/compatibility. Firefox (and perhaps others) does not support high profile.. It doesn't seem that it should be the default?

Could the issues be related to the simulcast fixes you've made to our native android SDK?

[davidliu]

@davidzhao the flag here seems only enable the codec as a supported codec, but it wouldn't be used if the SDP offer/answer profiles negotiate not to use it (e.g. if the other end couldn't support it), if I understand it correctly.

The other change is confirmed unrelated to this issue.

[davidzhao]

@davidzhao the flag here seems only enable the codec as a supported codec, but it wouldn't be used if the SDP offer/answer profiles negotiate not to use it (e.g. if the other end couldn't support it), if I understand it correctly.

The other change is confirmed unrelated to this issue.

oh got it! thanks for the clarifications.

[hiren3897]

Hello,
is this merge releated to #1274 ?