Low-Latency & Real-Time Streaming: SRT vs WHIP
Recently we started receiving questions from some of our customers about WHIP/WHEP streaming. After researching the topic, we decided to add support for such streaming to our products. To make our customers understand when to use SRT or WHIP, we decided to write this article with a brief overview of both options.
Low-Latency and Real-Time
Let's first define what Real-Time and Low-Latency streaming are. They are nothing but gradations of Glass-to-Glass delay. For brevity we will use the abbreviations RT, LL and g2g.
RT-streaming is understood as streaming where the g2g delay is not more than 300-400 milliseconds.
Next in grading is LL-streaming. This is such a streaming, in which the delay is higher than in RT, but remains within 1000 milliseconds.
A vivid representative of the protocol for RT-streaming is the WebRTC protocol, which is actively used in various teleconferencing systems and works in most browsers. Well, a bright representative of LL-streaming is the SRT protocol, in which you can achieve g2g delay within 400-800 milliseconds.
Ok, what is WHIP?
For a long time WebRTC, as a standard, did not describe the procedure for starting a session. It was assumed that developers of WebRTC-based systems, themselves determine how 2 nodes will start communicating with each other. For this reason, developers of streaming programs in a sense were constrained: they could not send a WebRTC stream to a third-party WebRTC-server, because the mechanism of interaction was not unified.
But relatively recently there was a simple solution to this issue. Someone said, let's use HTTP protocol to start communication and formalize it as a standard. This standard was called WHIP/WHEP.
WHIP: WebRTC-HTTP Ingest Protocol (for streaming to the server)
WHEP: WebRTC-HTTP Egress Protocol (for streaming from the server)
Accordingly, developers of streaming programs now have a protocol to start communicating with WebRTC server. For example, in the latest release of OBS Studio there is already a possibility to stream using WHIP protocol. Similarly, we have added this feature to our SRT Streamer Pro encoder. Due to the simplicity of the WHIP/WHEP protocol their implementation was quickly added to various WebRTC servers.
Thus WebRTC-based RT streaming has become more accessible to video streaming teams.
What makes RT possible
The question arises as to why WHIP streaming achieves ultra-low latency compared to SRT streaming.
The answer is quite simple: WHIP streaming requires the encoder to encode the stream in a format that is immediately played in the viewers' browsers. If this condition is met, the encoder encoded packet is instantly forwarded to the viewer unchanged when it reaches the server, resulting in ultra-low latency.
As you probably already guess, the “cost” for this scheme is the constraint in the choice of encoding modes, because the packet must initially be encoded so that the browsers of all users can decode it.
Recently we started receiving questions from some of our customers about WHIP/WHEP streaming. After researching the topic, we decided to add support for such streaming to our products. To make our customers understand when to use SRT or WHIP, we decided to write this article with a brief overview of both options.
Low-Latency and Real-Time
Let's first define what Real-Time and Low-Latency streaming are. They are nothing but gradations of Glass-to-Glass delay. For brevity we will use the abbreviations RT, LL and g2g.
RT-streaming is understood as streaming where the g2g delay is not more than 300-400 milliseconds.
Next in grading is LL-streaming. This is such a streaming, in which the delay is higher than in RT, but remains within 1000 milliseconds.
A vivid representative of the protocol for RT-streaming is the WebRTC protocol, which is actively used in various teleconferencing systems and works in most browsers. Well, a bright representative of LL-streaming is the SRT protocol, in which you can achieve g2g delay within 400-800 milliseconds.
Ok, what is WHIP?
For a long time WebRTC, as a standard, did not describe the procedure for starting a session. It was assumed that developers of WebRTC-based systems, themselves determine how 2 nodes will start communicating with each other. For this reason, developers of streaming programs in a sense were constrained: they could not send a WebRTC stream to a third-party WebRTC-server, because the mechanism of interaction was not unified.
But relatively recently there was a simple solution to this issue. Someone said, let's use HTTP protocol to start communication and formalize it as a standard. This standard was called WHIP/WHEP.
WHIP: WebRTC-HTTP Ingest Protocol (for streaming to the server)
WHEP: WebRTC-HTTP Egress Protocol (for streaming from the server)
Accordingly, developers of streaming programs now have a protocol to start communicating with WebRTC server. For example, in the latest release of OBS Studio there is already a possibility to stream using WHIP protocol. Similarly, we have added this feature to our SRT Streamer Pro encoder. Due to the simplicity of the WHIP/WHEP protocol their implementation was quickly added to various WebRTC servers.
Thus WebRTC-based RT streaming has become more accessible to video streaming teams.
What makes RT possible
The question arises as to why WHIP streaming achieves ultra-low latency compared to SRT streaming.
The answer is quite simple: WHIP streaming requires the encoder to encode the stream in a format that is immediately played in the viewers' browsers. If this condition is met, the encoder encoded packet is instantly forwarded to the viewer unchanged when it reaches the server, resulting in ultra-low latency.
As you probably already guess, the “cost” for this scheme is the constraint in the choice of encoding modes, because the packet must initially be encoded so that the browsers of all users can decode it.
On the other hand, the SRT protocol does not impose restrictions on encoding formats. But when using it, the encoder encoded packet must undergo some processing to display it in the browser. As a rule, for further distribution to viewers the stream is converted into HLS or DASH format, sometimes into WebRTC.
WHIP Restrictions
In order for a WHIP stream to be displayed in client browsers, there are recommendations (sometimes in the form of restrictions) on the format used.
Example of requirements from AWS IVS can be seen at the link
Of course you may not follow these recommendations, but be prepared that some viewer browsers will not be able to display your content.
When SRT is used and when WHIP is used
From the above, the obvious conclusion is when to use SRT and when to use WHIP.
In order for a WHIP stream to be displayed in client browsers, there are recommendations (sometimes in the form of restrictions) on the format used.
- Resolution up to 1080
- Progressive only
- No more than two audio channels in the OPUS codec
- Lightweight parameters for video codecs (no b-frames for example)
- Bitrate not more than 8.5 Mbs
Example of requirements from AWS IVS can be seen at the link
Of course you may not follow these recommendations, but be prepared that some viewer browsers will not be able to display your content.
When SRT is used and when WHIP is used
From the above, the obvious conclusion is when to use SRT and when to use WHIP.
- SRT: is used to transmit a high quality signal between locations and the Studio for further processing and preparation of the final signal.
- WHIP: used for streaming the final signal to the end viewers.
Where to try WHIP
You can use encoders that support the WHIP protocol:
As a server part you can use such media servers as:
For quick familiarization with WHIP/WHEP streaming you can use a trial period of Milicast service.
How to start streaming to it using SRT Streamer Pro can be seen in this simple guide
You can use encoders that support the WHIP protocol:
- OBS Studio
- SRT Streamer Pro
- Gstreamer
As a server part you can use such media servers as:
- RustXUI
- Janus
For quick familiarization with WHIP/WHEP streaming you can use a trial period of Milicast service.
How to start streaming to it using SRT Streamer Pro can be seen in this simple guide
