Force SDP negociation of h264 over vp8 when possible

[RLinc]

Hi,

Is it possible to 'prefer' h264 streaming during browser SDP negotiation within the MCU server?

I see that a few browsers accept this format during the SDP negotiation phase, why does the MCU server then opt for VP8 'software' encode when it has all the GPU grunt to output h264 encode?

Why does the MCU server pass up on this great offer to save resources?

Or am I missing something..?

Cheers,

Rich.

[RLinc]

Can anyone point me at the stack layer within the MCU to investigate this further?

Cheers.

[Jianjun_Z_Intel]

Hi Rich,

Codec preference is configured at client side. For JavaScript SDK, please take a look at conferenceClient.publish and conferenceClient.subscribe method. If preferred codec is not available in current browser, other codec may be used.

[RLinc]

Thanks Jianjun,

Does this mean that VP8 is mandated by WebRTC? If the MCU server only offered h264 during connection, a standard browser should negotiate h264 as the only option? How do we configure the MCU to essentially know nothing about VP8..

We are looking at a very large deployment using h264 RTSP feeds as input mainly. I'm aware how good h264 performance is using the GPU, It seems a shame use so much software encoding.

Cheers,

Rich.

[Jianjun_Z_Intel]

Hi Rich,

VP8 is always enabled at MCU side. However, when H.264 is the preferred codec at client side, and it does support H.264, H.264 will be used.

[RLinc]

Cheers,

I see you have control over selection in conferenceClient.publish, I was under the impression that it was the browser binary itself that dictated the CODEC format.

Rich.

[Dave_T_]

Jianjun,

Is there a mechanism either to disable VP8 on the MCU side or to use the GPU to encode in VP8?  It appears that even where H.264 is supported by the browser, the MCU defaults to offering VP8.

We want to force H.264 to be sent to the browser.

Thanks

Dave