February 16, 2018
Transmitting low delay, high quality video over the Internet is hard. The trade-off is normally between video quality and transmission delay (or latency). Internet video has up to now been segregated into two segments: video streaming and video calls. On the first side, streaming video has taken over the world of the video distribution using segmented streaming technologies such as HLS and DASH, allowing services like Netflix to flourish. On the second side, you have VoIP systems, which are generally targeted a relatively low bitrate using low latency technologies such as RTP and WebRTC, and they don't result in a broadcast grade result. SRT bridges that gap by allowing the transfer of broadcast grade video at low latencies.
The SRT protocol achieves these goal using two techniques. First, if a packet is lost, it will retransmit it, but it will only do that for a certain amount of time which is determined by the configured latency, this means that the latency is bounded by the application. Second, it tries to guess the available bandwidth based on the algorithms from UDT, this means that it can then avoid sending at a rate that exceeds the link's capacity, but it also makes this information available to the application (to the encoder) so that it can adjust the encoding bitrate to not exceed the available bandwidth ensuring the best possible quality. Using the combination of these techniques, we can achieve broadcast grade video over the Internet if the bandwidth is sufficient.
At Collabora, we're very excited with the possibilities created by SRT, so we decided to integrate it into GStreamer, the most versatile multimedia framework out there. SRT is a connection oriented protocol, so it connects 2 peers. It supports 2 different modes, one in which there is a caller and a listener (so it works like TCP) and one called "rendez-vous mode" where both sides call each other so as to make it friendly to firewalls. A SRT connection can also act in two modes, either as a receiver or a sender, or in GStreamer-speak as a source or as a sink. In GStreamer, we chose to create 4 different elements: srtserversink, srtclientsink, srtserversrc, and srtclientsrc. We decided on the client/server naming instead of caller/listener as we think it's easier to understand and it matches the naming we have to TCP based elements. We also chose to implement the rendez-vous mode inside the client elements as after the initialization, the codepaths are the same.
A typical example would be to have have an encoder which is also a server with a pipeline like:
gst-launch-1.0 v4l2src ! video/x-raw, height=1080, width=1920 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=high ! mpegtsmux ! srtserversink uri=srt://:8888/
And a receiver on the other side would receive it with a pipeline like this one:
gst-launch-1.0 srtclientsrc uri=srt://192.168.1.55:8888 ! decodebin ! autovideosink
Using tools like gst-launch, it's very easy to prototype SRT and it's integration into real world pipeline that can be used in real applications. Our team at Collabora would love to help you integrate SRT into your platform, using GStreamer, ffmpeg, VLC or your own multimedia framework. Contact us today to see how we can help!
In GStreamer 1.16, we've decided to merge the clientsrc and serversrc srt elements into a single source element, and the same for the server. So the example pipelines in 1.16 are:
gst-launch-1.0 -v videotestsrc ! video/x-raw, height=1080, width=1920 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=high ! mpegtsmux ! srtsink uri=srt://:8888/
gst-launch-1.0 srtsrc uri=srt://192.168.1.55:8888 ! decodebin ! autovideosink
Earlier this year, from January to April 2021, I worked on adding support for stateless decoders for GStreamer as part of a multimedia internship…
In our previous post, we presented a project backed by INVEST-AI which introduces a multi-stage neural network-based solution. Now let's…
Initiated as a joint effort by the Google Chrome OS team and Collabora, the recent KernelCI hackfest brought the addition of new tests including…
There's a lot that has happened in the world of Zink since my last update, so let's see if I can bring you up to date on the most important…
Panfrost, the open source driver for Arm Mali, now supports OpenGL ES 3.1 on both Midgard (Mali T760 and newer) and Bifrost (Mali G31, G52,…
Collabora has been investing into Perfetto to enable driver authors & users to get deep insights into driver internals and GPU performance.…