WebRTC in Xeoma

WebRTC. Literally.

Being cluttered with applications is a problem modern devices (be it mobile or desktop) struggle with on a regular basis. As a result, we often find ourselves searching for solutions that would keep everything we need within a single application. Fortunately, the saving grace already exists – browsers have a nearly limitless potential for integration. This is one of the key reasons Xeoma has a module dedicated to working with all kinds of browsers – Web Server. And, as of version 18.6.5, this module acquired a significant update – WebRTC support.

Let’s get the obvious question out of the way first: what is WebRTC? It stands for Web Real-Time Communication and represents a new way of allowing browsers to work with video and audio, one that does not require additional plugins or separate apps. Its most noticeable feature is cross-platform compatibility: whatever browser you may have, chances are WebRTC will find a way to work with it.
However, for a software developer, the real gold-mine of WebRTC is the simple APIs it uses. What this implies is best shown with examples.

Before version 18.6.5, if the original stream camera provided was H.264, it had to be transcoded (transformed) by the server into MJPEG – only then you could see the footage in a browser using Web Server. Transcoding implies higher CPU load for the server. This was unavoidable, since a browser couldn’t decode a stream on its own, if it arrived as is (H.264). WebRTC makes this last statement no longer applicable.

Now you can find these boxes in the Web Server settings:

Choosing the side for transcoding

WebRTC broadcasting with sound (transcoding on browser side) – this enables Xeoma’s server to send the video (and sound, if present) directly in H.264 to the web page.
Transcoding on Xeoma side for WebRTC broadcasting if browser doesn’t support the streaming format – this checks if the browser currently working with the Web Server supports WebRTC, and if it doesn’t – the browser still gets the picture (instead of a black screen) but the server does the transcoding for it.
“Hold on! Haven’t you just said that any browser can be used?” At present there are exceptions: Internet Explorer (also Edge) and Safari do not natively support WebRTC, they require special plugins.

As of Xeoma version 23.12.7, all these options are available for Linux ARM as well.

To actually view the streams via WebRTC make sure to switch to the right mode using Preferences tab in the browser:

WebRTC in its natural habitat - a browser

This brings 3 main advantages:

Less network load – as H.264 is a compressed video, the network between the server and the web-client (browser) will have to move significantly less data than with MJPEG. This can mean the world of difference for saving bandwidth (and, consequently, money), if the web-clients are plentiful and connect from afar.
Higher quality – H.264 streams tend to carry higher FPS and overall yield better performance for video than MJPEG.
Less CPU load for the server – since no original transcoding is required, the server has to do very little processing to send the video to the web page. Ultimately, this means more cameras per server, especially if Xeoma works in foreground (server only) and doesn’t analyze the streams (e.g. no Motion Detector) – this allows even older CPUs to handle a multitude of web-clients with ease.

There is, however, one downside: the hardware on the side of the browser will have to handle the decoding – higher CPU load for the client. On the other side, the browser is often used to view a specific camera, not all of them at once; this will reduce the load.

N.B. If you are using Apache or nginx for http/https back end and have Xeoma version 23.12.7 or higher, you can open the file config.json in “XeomaWeb” folder and set the parameter isNotUsePortForWebrtcCameraViewing to true. This will let Xeoma use the default ports for http (80) and https (443) when handling WebRTC.

updated on December, 19 2023