The Secure Reliable Transport protocol (SRT) is an industry standard for point to point media transport over Internet. This year YouTube announced that they are joining the SRT Alliance so we would expect they will provide support for SRT as ingest transport protocol in addition to RTMP quite soon. The open source video production software OBS that is very popular among streamers now also supports SRT as the output transport protocol.
SRT protocol is an extension to the User Datagram Protocol (UDP) and thus not possible to use directly in a standard web browser. One of the options for streaming video to a browser in real-time latency is to use WebRTC. A set of standard that the majority of web browsers support today. However, until recently a standard protocol for consuming media using WebRTC has been missing and with the IETF initiative of WebRTC HTTP Egress Protocol (WHEP) that gap will be filled. Should be noted though that this is in an early draft and the protocol details are still being discussed and changes are made.
We have developed and open sourced a tool, srt-whep, that combines these two protocols and technologies to enable a number of use cases that we will walk through in this post.
Program Output Monitor
One use case is to provide web browser based program output monitor to monitor what is being streamed to the streaming platform. This gives you a real-time feedback stream that for example a reporter on the field can use to know when to come in. That reporter can just go to a web page using the web browser in their mobile phone without having to install any application.
In this example we are using OBS and the SRT output in caller mode (default) and the srt-whep application running in listener mode.
srt-whep -i 0.0.0.0:1234 -o <streaming-platform>:<port> -p 8080 -s listener
Configure the OBS stream output to point to the server where the srt-whep application is running and port 1234 in this example. The WHEP channel URL is then available on http://<srt-whep-server>:8080/channel and can be played back using a WHEP web player. A demo of a WHEP web player is available here: https://webrtc.player.eyevinn.technology/
Another use case is to display a multiview / mosaic rendered and transported over SRT in a standard web browser and with a standard WHEP web player.
In this example the multiview renderer service is running in SRT listener mode and that means we will need to run the srt-whep application in caller mode.
srt-whep -i <multiview-renderer-ip>:<multiview-port> \
-o 0.0.0.0:1234 \
-p 8080 \
The WHEP channel URL is the same but the pass-through SRT is available in SRT listener mode.
And another use case is to be able to monitor the incoming media to a streaming platform in a standard web browser. A setup that could look like this.
And where you would run the srt-whep application with these arguments and in listener mode.
srt-whep -i 0.0.0.0:1234 -o <transcoder-ip>:<port> -p 8080 -s listener
As mentioned the WHEP standard is still a moving target and there are an active discussion about whether the server or the client should initiate the SDP offer. We have chosen to implement this application with the server-side initiated offer as in this scenario there are no real room for negotiation as the application just pass-through what it receives and no transcoding is taking place.
The benefit of a solution based on standard protocols is that you are not locking yourself into a specific vendor, neither on the playback side or the components on the backend side.
This application is available as open source on our GitHub and we welcome you to try it out and provide feedback or pull requests.