High CPU load, help to implement webRTC with Nvidia GPUs ...

[fabiano182]

Hi @mpromonet,

First, congrats for your good project.

I'm trying to build a media server with a large number of IP cameras, that follows RTSP Protocol and by default are encoded in H264. The cameras are exhibited on demand in a website, but when the numbers of cameras displayed increase, the CPU load increase exponentially, then the server goes down.

I've tried different approaches, increase the number of cores, reduce the image size (it was 4k, now it's simple HD images), run on Docker and on a local machine, even use the option -o. For a moment the load at CPU got lower, but eventually the processor beats 100% or it's very high.

I searched a lot, before ask to you. I have an Nvidia GPU available, and at this moment the code, as it is, don't support hardware acceleration. I'm interested in transfer this load to GPU, to see how the GPU handles. But I don't have any ideia about how to implement this. So, do you have an advice or a way, maybe a guide, to how to use hardware acceleration in your WebRTC? Did you already implemented this project in a GPU?

The figure below explain the main idea, give the task of RTSP/WebRTC to a Docker container, today running on CPU, to a container running with Nvidia GPU. By curiosity, the number of camera is around 20.

Thank you, I hope to hear your expertise.

[mpromonet]

Hi Faber182,

Sure you can implement Nvidia encoding/decoding using similar way used with NullDecode & NullEncode. However using -o there is no more decoding/encoding, then I am not sure GPU will helps you with this approach. What you will win implementing GPU codec, is the capability to adapt webrtc stream bandwidth, resolution, fps,....

You can compare with janus-gateway that implement a lighter approach forwarding the RTP packet.

You can also add a load balancer and use multiple instances of webrtc-streamer.

Best Regards, Michel.

[fabiano182]

Thanks for the quickly reply.

I was thinking that the servers were running with the option -o, but for any reason the image of container was deprecate, and don't had option -o.

Now with the latest image (v0.6.1), the CPU load was lower then I never seen, and the payload was divided equally between the cores.

Again, thanks very much for your time.

Regards