2023 was a busy year for the development of Broadcast Bridge, run by our sister company Everycast Labs. We completely rewrote the desktop app and released a host of new features.
Everycast Labs’ aim is to make Broadcast Bridge as flexible as possible for video professionals, and this includes supporting several ways to input media streams.
We’ve built support in their cloud media server for the two main protocols for secure, low-latency media streaming: WHIP and SRT. You can read about what WHIP is and the details of their WHIP input feature in the Everycast Labs blog.
Today, I’d like to talk about what SRT is and how we built support for it in the Broadcast Bridge media server.
What is SRT?
SRT stands for Secure Reliable Transport and is an open source protocol for the transmission of media and data across unreliable networks, namely, the Internet. The protocol was developed by Haivision and the SRT Alliance now includes hundreds of companies.
SRT uses UDP as the transport layer, offers a latency buffer for packet loss recovery and supports encryption. Additionally, SRT is codec-agnostic, so it offers great flexibility for video professionals wanting to transfer their own media.
SRT transmission options can be set by adding parameters to the endpoint URL, for example:
srt://192.168.0.5:5000?mode=caller&streamid=12345&passphrase=secret
This will make a connection with a local address at port 5000, enforcing caller mode, specifying a stream ID of “12345” and a bearer token of “secret”.
More info about options can be found in the SRT documentation.
One commonly-used option is the latency buffer, which can be set from a value of milliseconds to prioritise low latency, to a few seconds to maximise packet loss recovery.
Why use SRT?
Low latency, resilience to poor network conditions and flexibility are driving a widespread adoption of SRT streaming among video producers and AV companies, from small teams to major players like Fox News and the NFL, as seen in the video on the SRT About page. Its main uses vary from video contribution from remote sites to broadcast return feeds.
Traditionally, resilient, flexible, low latency feeds would be achieved with satellite transmission or a private fibre link. While these methods mean they are much less likely to incur in data loss compared to the public Internet, they are also very expensive. SRT (like WebRTC), on the other hand, can get almost the same end result for a much lower cost, so it is a great choice for smaller productions with a lower budget, as well as a good fallback for those who are using satellite or fibre.
How Broadcast Bridge supports SRT
It all starts with Donut, which is a Pion-based open source project that takes an SRT stream and converts it to WebRTC to display it in a browser.
We made a fork to add WHIP support, so that the WebRTC stream can be easily sent to a compatible destination; in our case, the Broadcast Bridge media server. In this way, when a Broadcast Bridge SRT endpoint receives a request, Donut immediately converts the stream to WebRTC and sends it to the correct WHIP endpoint in the media server. As both the Donut and media server instances run on the same server, there is no quality degradation in this step.
What about codec support? While SRT is technically codec-agnostic, it is most commonly used to stream H264 video, which means there is no need to transcode for WebRTC. Currently, Broadcast Bridge supports H264 for video and Opus for audio with SRT, but Everycast Labs are looking at adding support for more codecs, and possibly even transcoding ability, if there’s a demand for it.
There’s also an opportunity for user-specified latency with SRT, which Broadcast Bridge may incorporate in future. Currently SRT latency in Broadcast Bridge is fixed at 300ms.
The repo is public, so feel free to have a look at how we added WHIP to Donut, and keep up to date with the project.
What it looks like for the user
Destination
Let’s take a look at the user journey to start streaming a video to the Broadcast Bridge media server using SRT.
To create an endpoint, the user navigates to a Broadcast Bridge Room’s settings and adds a stream input from a dialog. In the background, this generates the URL needed to point the stream to the media server. The URL is automatically assigned the streamid and passphrase options so it can be accepted by the broadcast bridge server, and it looks something like:
srt://srt.uk.broadcastbridge.dev:5000?streamid=<streamID>&passphrase=<passphrase>
The stream ID identifies a media stream in a user’s room, while the passphrase contains the bearer token needed to authenticate with the media server.
The user adds a stream input type from the room settings to generate the endpoint. Both SRT and WHIP inputs are supported.
Once the stream input has been created, the user can copy the endpoint URL and use it for streaming, as it already contains all the options needed.
Click a button to copy the SRT endpoint and paste it into your stream source (e.g. ffmpeg or a vision mixing software) for streaming.
Source
Now, let’s send an SRT stream to Broadcast Bridge! Let’s use ffmpeg for this example: The following command will take the video from the device’s default webcam and stream the media to the SRT endpoint. In the command, <stream ID> and <passphrase> should be replaced with the correct values:
ffmpeg -f avfoundation -framerate 30 -i "0" -pix_fmt yuv420p -c:v libx264 -b:v 1000k -g 30 -keyint_min 120 -profile:v baseline -preset veryfast -f mpegts "srt://srt.uk.broadcastbridge.dev:5000?streamid=<streamID>&passphrase=<passphrase>"
The image below shows the result: My main webcam is streamed directly to the media server and is shown in the room under the name ‘SRT-ffmpeg’. I joined the room sharing my secondary webcam (m/local) from the browser.
The SRT stream is visible inside the room as a remote stream.
SRT or WHIP?
So which one is better: SRT or WHIP? Last year, Dan gave a talk about this at the London Video Technology meetup. The answer: Choose whichever is best for you!
Everycast Labs are building Broadcast Bridge to be as flexible as possible. When it comes to video productions, be it hybrid events, broadcasts with remote talent or a podcast episode, every use case is different. Their goal is for Broadcast Bridge to integrate into their users’ setup, rather than dictate what they can and can’t do.
When it comes to streaming a feed with low latency into a media server, both SRT and WebRTC with WHIP are great solutions. And despite their technical differences, they can be quite similar from the user’s point of view: All they need is a URL, an authentication token and a software capable of streaming with the right protocol.
It’s up to the final user to decide which option gives the best solution to their needs.
Need help?
If you’re working with SRT and need some extra support, we’re happy to help. Nimble Ape has been consulting on real-time media projects for a decade, building products for clients big and small all over the globe.
Why not drop us a line on [email protected]
- Marco and the Nimble Ape team