[QUESTION] Default Android/iOS SDK does not include profile 42e01f in Offer

[suggestedfixes]

From our Mobile Team

---

We’d like to integrate the iOS/Android KVSWebRTC SDK sample to our project to view the video from the camera, and the camera used KVSWebRTC_C SDK. From the log of the camera and mobile app, the video data has been returned from the camera, but the video cannot be rendered on the mobile app side. And we also refer to the KVSWebRTC SDK sample and the video can be rendered successfully. So we analyzed the offer sent to the camera and answer received from the camera, and found codec type might be not matched. The attachments are the logs of offer and answer, please kindly advise how to fix this codec issue.

On the camera side, the supported codec type is H264, so the mobile app and the web need to send H264 type to the camera in the offer.

From the iOS log, the sent offer includes the H264, but the profile-level-id is different between iOS and Camera, profile-level-id is 640c2a and 42e02a in the app, but profile-level-id is 42e01f in the camera.

---

Possible Suggestions on the next steps?
What we can think of:
Approach A

• Grab an H264 decoder library that supports 42e01f profile on Android/iOS.
• Update Android/iOS SDK to include 42e01f profile into the offer.

Approach B

• In response to the 42e02a offer, try answering with 42e02a profile supplying 421e01f codec and see if the 42e02a decoder can decode it.

More possible approaches?

[disa6302]

@suggestedfixes ,

Cannot think of any other approach. I am unfamiliar with the Android/iOS SDK implementation. Perhaps @MushMal can give some insight.

I would suggest to try approach A because the SDK is expected to respond positively when the profile matches.

[suggestedfixes]

@disa6302 Our android team is having trouble generating H264 profiles into the offer. Is it something we have to code from scratch or can we have a feature request to serialize that into the offer?

[suggestedfixes]

In addition, the default iOS SDK comes with a 42e02a decoder, so there might be video artifacts when viewing with iOS SDK?

[disa6302]

@suggestedfixes ,

In the android SDK, we use the capabilities of org.webrtc:google directly. The KVS webrtc android SDK itself has the signaling implementation only. I would say write override methods for the decoder functions in the android and iOS SDK to see if the profile can be supported. Will need some time to investigate this further.

[suggestedfixes]

We got android working, now the question is whether it's possible to generate a 42e01f offer on the iOS side.

[disa6302]

@suggestedfixes ,

One thing I would suggest is to see if it is possible to override the decoder/encoder function in the webrtc core SDK for iOS. I have not looked at the SDK myself, so I will not be able to help you immediately. Need to look into it.

[suggestedfixes]

@disa6302 We made sure the C SDK side properly parses the trickle ice option and the answer contains the last baseline profile in SDP. This seems to work for the device we are testing. We will do more testing.

[suggestedfixes]

There might be video artifacts due to profile mis-match, but we will do more testing.

[suggestedfixes]

We don't have any residual problems for now. Closing this ticket.