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 a video compression standard called 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 analog ones don’t utilize compression in principle, as they weren’t intended for network data transmission in the first place. Some USB cameras do support H.264 but they are uncommon.
Enter Xeoma’s “RTSP Broadcasting” module – it allows to convert any stream into RTSP (including H.264), be it analog, USB or IP camera. For convenience, we will be referring to the original video as “input” and the resulting broadcast from the module – as “output”. The module is available for Xeoma Standard and Xeoma Pro. First of all, let’s add the module to the chain:
The are 2 distinct ways to run the broadcast, each with its own pros and cons. You can switch between them using the “Broadcasting tool” option at the top. Let’s look at each of the ways in detail.
ffserver
Want to skip to the other option now? Click here!
ffserver is an old but robust open source solution for turning any existing video into an rtsp broadcast. N.B.: official support for ffserver ended in 2018.
Here is what you will see once this option is selected:
The port is set by default to a value that isn’t already occupied by something else on the server. If your input is not H.264 but the ouput should be H.264, the process that allows for this transition is called transcoding. ffserver does not handle the transcoding on its own, it needs another piece of software to handle that step. This is where FFmpeg comes in – you can tell Xeoma which version of FFmpeg should be used to transcode via the “Full path to an alternative version of ffmpeg” box and pick “libx264” as “Encoder type”. Here is where you can get the right version of ffmpeg for this task:
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.
On the other hand, if mpeg4 or mjpeg is suitable, then everything is ready to go without ffmpeg – just copy-paste the path (e.g. rtsp://192.168.0.51:8555/RtspTranslator.34) to a “Universal camera” on another Xeoma (or any other system that supports rtsp), and you are ready to broadcast now.
In some cases, when the input is already H.264, you may want to avoid any direct changes between input and output. This is a good opportunity to pick “No transcoding: Low Resolution Stream (Preview)” or “No transcoding: High Resolution Stream (Archive)” as “Encoder type”. This will instruct ffserver to take the H.264 stream from the “Universal Camera” module’s preview box or archive box respectively and to broadcast it as is, no transcoding applied. This will not work for H.265, though.
live555
Want to go back to the previous option now? Click here!
LIVE555 is a modern open source solution for making rtsp broadcasting as simple and as ubiquitous as possible.
Here is what you will see once this option is selected:
Similarly to the previous option, the port is picked for you automatically, but you can still assign your own, if you wish. By default, the module is set to “No transcoding: Low Resolution Stream (Preview)”, so the input and output will match. This is true for MJPEG, H.264, H.265.
However, if you have MJPEG as input and wish to get H.264 as output, you can click the “Download OpenH264 Video Codec provided by Cisco Systems, Inc.” button and then pick “Transcoding to H264: Low Resolution Stream (Preview)” or “Transcoding to H264: High Resolution Stream (Archive)”. This will instruct live555 to take an MJPEG stream from the “Universal Camera” module’s preview box or archive box respectively, transcode it to H.264, and broadcast the result over rtsp.
Note that this will not work for H.265 input.
When this is done, all you need to do is copy-paste the output path to anything that needs to be receiving the broadcast (another Xeoma, VLC player, OBS, etc.).
Additionally, you can broadcast the already recorded archives from your server – this can be achieved with Xeoma’s JSON API, even if “RTSP Broadcasting” module is not present on the server. Here is an example of the relevant command:
http://192.168.0.51:10090/api?login=Administrator&password=notpassword&archive=Preview%2bArchive.18&archive_date=2025-09-22&archive_minute=14%3a30%3a05&archive_millis=0&start_rtsp_archive=
Use cases and considerations
“RTSP Broadcasting” can be useful in situations where a server has an average USB camera (MJPEG) that needs to be broadcasted to one or several receivers over a network that has very limited bandwidth. Here transcoding to H.264 would be a good fit.
Sometimes a server needs to work as a hub, collecting multiple cameras and allowing multiple other devices to have centralized access to these cameras. If the resulting video is needed for more than just viewing, then a standard client connection would be insufficient, so “RTSP Broadcasting” with no transcoding helps to fill that niche.
Another way to take advantage of this module is to use it for integration between Xeoma and another piece of software. Sometimes other software may need dynamic access to cameras’ video streams through Xeoma – “RTSP Broadcasting” is an efficient way to achieve exactly that.
However, this technology comes with certain limitations, which we will explain down below:
- It’s important to note that, in order for all of the options discussed above to work, the server with “RTSP Broadcasting” requires a way for other devices to reach it over the network (e.g. static external IP and its alternatives).
- Options that use transcoding compress and encode the given stream using the server’s CPU, and this work needs to be performed continuously. As such, the server’s CPU load is going to rise the higher the compression for each camera that uses this feature.
- The “live555” option is not available for servers running on MacOS, Android, or 32-bit Windows.
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: December, 05 2025
Read also:
How to Admin
How to make a wireless video surveillance system