H264 Profile

[vishalr...@gmail.com]

Hi,

I was using Janus 0.7.3 and now upgrading to 0.12.2

I am facing one issue in my iOS clients.

My client is sending two H264 profiles in SDP as below

a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c34

a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e034

0.7.3 is sending back below as answer

a=fmtp:96 profile-level-id=42e01f;packetization-mode=1

0.12.2 is sending

a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c34

Is there any way to force 42e01f like 0.7.3 because some of my android clients are not able to decoce 640c34 and this failing to render video.

I tried setting up h264_profile while creating room but since 42e01f is not offered by iOS client it is not setting that in answer.

Thank you

[Lorenzo Miniero]

No, the plugin will either check what was offered, or check what the plugin is asking for. If you have endpoints that are confused by that, you'll have to munge the SDP, so put the value you want in the SDP yourself: you can do this either on the publisher side (so that Janus gets an SDP with 42e01f in it) or on the subscriber side (you replace whatever profile there is with 42e01f, before calling setRemoteDescription).

L.

[vishalr...@gmail.com]

Thank you for the response.

I am using RabbitMQ as client. Is that ok if i modify SDP before sending it to Janus i.e. iOS will still send 640c34 and I will modify it before sending to Janus to 42e01f, this will make Janus see only 42e01f.

My concern here is, will it be creating problem while relaying media ?

[Lorenzo Miniero]

Munging SDPs (which means modifying before sending/handling) is a common thing, that's often done for different reasons. No problem relaying, since this only impacts the negotiation phase.

L.