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).
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:
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.
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