SRT allows unreliable networks like the Internet be used for reliable, encrypted video contribution. Created by Haivision and now an Open Source technology, the alliance of SRT users continues to grow as the technology continues to develop and add features. This panel, from IBC 2019, is an update on what’s new with SRT and how it’s being used daily in broadcast.
Marc Cymontowski starts with an overview of the new features of SRT, mentioning its active Github repository, pointing to recent advances in the encryption available, upcoming FEC and the beginnings of SMPTE ST 2022-7 like redundancy. He also takes a look at how SRT fares against RTMP, the venerable incumbent technology for contribution of streams over the internet. Official support for RTMP will be coming to an end next year, so there is much interest in what may replace it. Marc makes the case that for the same link, SRT tends to have a latency of a half to a third and also performs better at higher bitrates.
RTP, the Real-Time Transport Protocol, is an important feature when it comes to redundancy. By using RTP’s ability to stamp each packet, the receiver can take two identical RTP streams – say from two separate ISPs and fill in missing packets on one stream from the packets of the other stream. This is a very powerful way of ensuring reliability over the internet so Marc makes the point that using SRT doesn’t stop you using RTP.
Simen Frostad then takes to the stage to explain why Bridge Technologies has added SRT support and how the SRT Hub will be very important step forward. Then it’s Leonardo Chaves’ turn who explains how broadcaster Globo is using SRT to transform its video workflows and reduce OPEX costs to one third satellite costs.
Steve Russell from Red Bee talks about how they use SRT to create new, or lower cost, circuits and services to their customers. They’re able to use the internet not only for contribution from events but also to safely get video in and out of the cloud.
With these use-cases in mind, the panel opens up to thirty minutes of wide ranging technical and non-technical questions.
In the west, RTMP is seen as a dying protocol so the hunt is on for a replacement which can be as widely adopted but keep some of it’s best parts including relatively low latency. SRT is a protocol for Secure, Reliable Transport of streams over the internet so does this have a role to play and how does it work?
Alex Converse from Twitch picks up the gauntlet to dive deep into the workings of SRT to show how it compares to RTMP and specifically how it improves upon it.
RTMP fails in many ways, two to focus on are that the spec has stopped moving forward and it doesn’t work well over problematic networks. So Alex takes a few minutes to explain where SRT has come from, the importance of t being open source and how to get hold of the code and more information.
Now, Alex starts his dive into the detail reminding us about UDP, TS Packets and. Ethernet MTUs has he goes down. We look at how SRT data packets are formed which helps explain some of the features and sets us up for a more focussed look.
SRT, as with other, similar protocols which create their resilience by retransmitting missing packets, need to use buffers in order to have chance to send the missing data before it’s needed at the decoder. Alex takes us through how the sender and receiver buffers work to understand the behaviour in different situations.
Fundamental to the whole protocol is packet the packet acknowledgement and negative acknowledgements which feature heavily before we discuss handshaking as we start our ascent from the depths of the protocol. As much as acknowledgements provide the reliability, encryption provides the ‘secure’ in Secure Reliable Transport. We look at the approach taken to encryption and how it relates to current encryption for websites.
Finally Alex answers a number of questions from the audience as he concludes this talk from the San Francisco Video Tech meet up.
RIST and SRT are gaining more and more traction as they solve the reliability question over internet contribution. Promising cheaper costs than dedicated circuits, so much of our life uses the internet, it seems logical that it helps connect broadcasts as much as it does video conferences.
SRT and RIST are both protocols which allow streaming of video and other media over networks. If any packets go missing then the receiver will let the sender know and the sender will retransmit the missing data. All being well, these missing packets will arrive in time and no one will know that any data loss took place.
SRT was started by Haivision and is now an open source collaboration with a public repository and slack workspace. It goes beyond simple retransmission and actually offers an encrypted link which is so important when it comes to sports and other high value content.
RIST is being developed by the Video Services Forum (VSF) and the specifcation TR-06 defines how it works. This is is released as a freely-available specification and implementations based on the first release were shown at IBC2018. For a video on RIST, check out this talk from Merrick Ackermans
The RIST working group comprises people from Haivision, Zixi, NetInsight and other companies many of whom also have similar technologies. So the question is why is RIST of so much interest and what are the differences and benefits to SRT?
This Webinar from Net Insight sets out to answer just this question as we’ll as looking to the future to see what is yet to come on the RIST roadmap.
With the demise of RTMP, what can WebRTC – its closest equivalent – learn from it? RTC stands for Real-Time Communications and hails from the video/voice teleconferencing world. RTC traditionally has ultra-low latency (think sub-second; real-time) so as broadcasters and streaming companies look to reduce latency it’s the obvious technology to look at. However, RTC comes from a background of small meetings, mixed resolutions, mixed bandwidths and so the protocols underpinning it can be lacking what broadcast-style streamers need.
Nick Chadwick from MUX looks at the pros and cons of the venerable RTMP (Real Time Messaging Protocol). What was in it that was used and unused? What did need that it didn’t have? What gap is being left by its phasing out?
Filling these increasing gaps is the focus of the streaming community and whether that comes through WebRTC, fragmented MP4 delivered over web sockets, Low-Latency HLS, Apple’s Low-Latency HLS, SASH, CMAF or something else…it still needs to be fulfilled.
Nick finishes with two demos which show the capabilities of WebRTC which outstrip RTMP – live mixing on a browser. WebRTC clearly has a future for more adventurous services which don’t simply want to deliver a linear channel to sofa-dwelling humans. But surely Nick’s message is WebRTC needs to step up to the plate for broadcasters in general to enable them to achieve <1 second end-to-end latency in a way which is compatible with broadcast workflows.