RTSP Broadcasting
Video surveillance nowadays is rarely left to USB or analog cameras, as broadcasting over a network allows for easier connection of multiple cameras to a single server. No wires, no input-output compatibility issues, no hardware limitations – all of that puts IP cameras at the top. However, there is one weak link in that seemingly flawless chain of technology – the network itself. Video files contain a lot of information and their data transmission between many sources and receivers requires a powerful stable network – something many cannot afford.
So is there a way to have a high-quality video without overloading a common network? And can USB and analog cameras be used in a similar fashion – broadcast now without any additional technology? In this article we’ll look at one of the ways to do that.
First of all, the video parameter that shows us exactly how “heavy” this stream is for the network is called bitrate, measured in bits per second (mostly Kb/s or Mb/s). Routers often provide the user with 100 Mb/s total (though more expensive models can boast an impressive 1 Gb/s). Thus our goal is to keep the bitrate low without sacrificing the quality. This is achieved by using video compression standard H.264 that we covered in a separate article. URLs that carry compressed videos usually start with RTSP – Real Time Streaming Protocol – instead of HTTP (e.g. rtsp://192.168.0.14:554/h264). However, not all the IP cameras support it (although the majority of modern ones do), while USB and analog ones don’t utilize compression in principle, as they weren’t intended for data transmission in the first place.
Enter Xeoma’s “RTSP Broadcasting” module – it allows to convert any stream into RTSP (including H.264), be it analog, USB or IP camera. First of all, let’s add it to the chain:
The broadcast is almost ready to start, now to configure the module:
If we use mpeg4 or mjpeg, everything is ready – copy-paste the path (sometimes it will include the port: rtsp://localhost:30001/RtspTranslator.10) to a “Universal camera” on another Xeoma and swap “localhost” for the first machine’s IP – you are ready to broadcast now:
If the second machine is located within a different network, the first one will require a static external IP (or its alternatives) with the right port forwarded (if no port is present in the path, forward 554 – this is the default RTSP-port).
 |
Starting with Xeoma release version 21.3.4, the RTSP Broadcasting module will display a warning if the specified port is already taken. |
However, both mpeg4 and mjpeg are quite “heavy” for the network. If you’d like to stream in H.264 and reduce the network load, choose libx264 as Encoder type. You will also need a specific version of ffmpeg for this to work properly, downloadable here:
Windows: https://felenasoft.com/xeoma/downloads/ffmpeg/win/ffmpeg_win.exe
Linux: https://felenasoft.com/xeoma/downloads/ffmpeg/linux/ffmpeg_linux
Please note that this option is unavailable for Mac OS, as there are no ffmpeg versions for it. Indicate the path to that file on your machine:
To minimize the bitrate choose High compression rate. As a result, you will get a compressed broadcast now with a significantly lowered bitrate without losing the quality.
This method does have a downside – compressing and encoding a stream is a task meant for the CPU, one that has to be performed continuously. As such, the server’s CPU load is going to rise the higher the compression.
This showcases the underlying choice a video surveillance administrator needs to make: CPU load or network load? This in turn boils down to: powerful server or powerful network? With only a few cameras there is little to consider, as even ancient technology will be able to handle that much, but the higher grows the scale (50-80 cameras per server) the more substantial become the requirements. The most common solution to this is, naturally, the middle ground: MJPEG stream for the preview and H.264 stream for the archive – this way the server won’t have to decode the image in real time, while the network will hold only 1 unencoded stream per camera.
Tip: Starting from version Xeoma 20.11.30, an option has been added to broadcast H264 stream in the same format without re-encoding.
Tip: Starting from version Xeoma 21.3.4, you can specify your custom final URL for the broadcast.
Tip: Starting from version Xeoma 22.10.12, RTSP Broadcasting, that was initially added as a Xeoma Pro feature, becomes available as part of the Xeoma Standard edition as well.
Tip: Starting from version Xeoma 22.11.25, Xeoma offers choice of a tool to use for broadcasts: the traditional ffserver that has more options and more operating systems supported, or the newer and more stable live555 that works only on 32- and 64-bit Windows and Linux.
Data transmission over long distances is being improved, as new ways of facilitating this process are introduced (e.g. H.265), and Xeoma is keeping its eyes on the ball, ready to embrace the new technology.
October, 6 2017. Updated: November, 25 2022
Read also:
How to Admin
How to make a wireless video surveillance system