You searched for SRT – Page 5 of 14 – The Broadcast Knowledge

Video: AES67 Beyond the LAN

Posted on 27th April 2021 by Russell Trafford-Jones

It can be tempting to treat a good quality WAN connection like a LAN. But even if it has a low ping time and doesn’t drop packets, when it comes to professional audio like AES67, you can help but unconver the differences. AES67 was designed for tranmission over short distances meaning extremely low latency and low jitter. However, there are ways to deal with this.

Nicolas Sturmel from Merging Technologies is working as part of the AES SC-02-12M working group which has been defining the best ways of working to enable easy use of AES67 on the WAN wince the summer. The aims of the group are to define what you should expect to work with AES67, how you can improve your network connection and give guidance to manufacturers on further features needed.

WANs come in a number of flavours, a fully controlled WAN like many larger broadacsters have which is fully controlled by them. Other WANs are operated on SLA by third parties which can provide less control but may present a reduced operating cost. The lowest cost is the internet.

He starts by outlining the fact that AES67 was written to expect short links on a private network that you can completely control which causes problems when using the WAN/internet with long-distance links on which your bandwidth or choice of protocols can be limited. If you’re contributing into the cloud, then you have an extra layer of complication on top of the WAN. Virtualised computers can offer another place where jitter and uncertain timing can enter.

Link

The good news is that you may not need to use AES67 over the WAN. If you need precise timing (for lip-sync for example) with PCM quality and low latencies from 250ms down to as a little as 5 milliseconds do you really need AES67 instead of using other protocols such as ACIP, he explains. The problem being that any ping on the internet, even to something fairly close, can easily have a varying round trip time of, say, 16 to 40ms. This means you’re guaranteed 8ms of delay, but any one packet could be as late as 20ms. This variation in timing is known as the Packet Delay Variation (PDV).

Not only do we need to find a way to transmit AES67, but also PTP. The Precise Time Protocol has ways of coping for jitter and delay, but these don’t work well on WAN links whether the delay in one direction may be different to the delay for a packet in the other direction. PTP also isn’t built to deal with the higher delay and jitter involved. PTP over WAN can be done and is a way to deliver a service but using a GPS receiver at each location is a much better solution only hampered by cost and one’s ability to see enough of the sky.

The internet can lose packets. Given a few hours, the internet will nearly always lose packets. To get around this problem, Nicolas looks at using FEC whereby you are constantly sending redundant data. FEC can send up to around 25% extra data so that if any is lost, the extra information sent can be leveraged to determine the lost values and reconstruct the stream. Whilst this is a solid approach, computing the FEC adds delay and the extra data being constantly sent adds a fixed uplift on your bandwidth need. For circuits that have very few issues, this can seem wasteful but having a fixed percentage can also be advantageous for circuits where a predictable bitrate is much more important. Nicolas also highlights that RIST, SRT or ST 2022-7 are other methods that can also work well. He talks about these longer in his talk with Andreas Hildrebrand

Nocals finishes by summarising that your solution will need to be sent over unicast IP, possibly in a tunnel, each end locked to a GNSS, high buffers to cope with jitter and, perhaps most importantly, the output of a workflow analysis to find out which tools you need to deploy to meet your actual needs.

Watch now!
Speaker

Nicolas Sturmel
Network Specialist,
Merging Technologies

Video: WebRTC: Mostly the video bits

Posted on 16th April 2021 by Russell Trafford-Jones

Who better to dig below the surface of WebRTC, which delivers sub-second latency, than Sean DuBois, creator of the Pion WebRTC library? This video takes a different look at WebRTC to others that focus on latency or scaling. Rather Sean looks at congestion control and managing the impacts of congestion noting that people remember how bad the video got and not how nice your sign-up page was.

Congestion is inevitable in large ‘unmanaged’ networks such as the internet and on wifi and cellular networks. Sean points out that the use of MPEG codecs which add dependencies between frames magnify the effect of lost packets. With frame-by-frame codecs, dropping a frame and repeating the last one is barely noticeable, but with MPEG, many more could be damaged. WebRTC was implemented over UDP so it could use its own congestion control.

RTP and RTCP are the key to WebRTC’s congestion control. RTP is well known for carrying real-time media as it’s used for AES67 audio, SMPTE ST 2110 and ST 2022-6 to name just a few standards. RTCP is RTP’s sidekick. Whilst RTP does the legwork of carrying the media, the RTP Control Protocol (RTCP) passes messages to control the flow. In this case, Sean explains, the RTCP channel is used to tell the sender that it’s sending too much video or which packets it’s lost. In terms of mitigating congestion, the source can adjust the bitrate directly or change the resolution or the framerate of the video to bring the bitrate down indirectly.

Sean shows a summary diagram of congestion controller flow which is built to handle jitter and out of order packets. Buffers are the normal way of fixing out-of-order packets but they have a big downside of adding latency and exacerbating timing problems. WebRTC has to use the RTCP channel to make sure it can map packet timing with NTP, using Sender Reports, as each packet’s timing information is only relative. When packet loss is spotted NACK (negative acknowledgements) are sent via RTCP or if things are worse, a Picture Loss Indication is sent which request a new keyframe. Fixing any impairments that do occur can be done either with FEC or by concealing the error with some form of masking, nowadays this may be based on machine learning.

The talk finishes with a look at a number of innovative projects which use WebRTC in one way or another, including for file transfer.

Watch now!
Speakers

Sean DuBois
Creator, Pion WebRTC
Developer, Apple

Video: Creating Interoperable Hybrid Workflows with RIST

Posted on 7th April 2021 by Russell Trafford-Jones

TV isn’t made in one place anymore. Throughout media and entertainment, workflows increasingly involve many third parties and being in the cloud. Content may be king, but getting it from place to place is foundational in our ability to do great work. RIST is a protocol that is able to move video very reliably and flexibly between buildings, into, out of and through the cloud. Leveraging its flexibility, there are many ways to use it. This video helps review where RIST is up to in its development and understand the many ways in which it can be used to solve your workflow problems.

Starting the RIST overview is Ciro Noronha, chair of the RIST Forum. Whilst we have delved in to the detail here before in talks like this from SMPTE and this talk also from Ciro, this is a good refresher on the main points that RIST is published in three parts, known as profiles. First was the Simple Profile which defined the basics, those being that it’s based on RTP and uses an ARQ technology to dynamically request any missing packets in a timely way which doesn’t trip the stream up if there are problems. The Main Profile was published second which includes encryption and authentication. Lastly is the Advanced Profile which will be released later this year.

Ciro outlines the importance of the Simple Profile. That it guarantees compatibility with RTP-only decoders, albeit without error correction. When you can use the error correction, you’ll benefit from correction even when 50% of the traffic is being lost unlike similar protocols such as SRT. Another useful feature for many is multi-link support allowing you to use RIST over bonded LTE modems as well as using SMPTE ST 2022-7

The Main Profile brings with it support for tunnelling meaning you can set up one connection between two locations and put multiple streams of data through. This is great for simplifying data connectivity because only one port needs to be opened in order to deliver many streams and it doesn’t matter in which direction you establish the tunnel. Once established, the tunnel is bi-directional. The tunnel provides the ability to carry general data such as control data or miscellaneous IT.

Encryption made its debut with the publishing of the Main Profile. RIST can use DTLS which is a version of the famous TLS security used in web sites that runs on UDP rather than TCP. The big advantage of using this is that it brings authentication as well as encryption. This ensures that the endpoint is allowed to receive your stream and is based on the strong encryption we are familiar with and which has been tested and hardened over the years. Certificate distribution can be difficult and disproportionate to the needs of the workflow, so RIST also allows encryption using pre-shared keys.

Handing over now to David Griggs and Tim Baldwin, we discuss the use cases which are enabled by RIST which is already found in encoders, decoders and gateways which are on the market. One use case which is on the rise is satellite replacement. There are many companies that have been using satellite for years and for whom the lack of operational agility hasn’t been a problem. In fact, they’ve also been able to make a business model work for occasional use even though, in a pure sense, satellite isn’t perfectly suited to occasional use satellites. However, with the ability to use C-band closing in many parts of the world, companies have been forced to look elsewhere for their links and RIST is one solution that works well.

David runs through a number of others including primary and secondary distribution, links aggregation, premium sports syndication with the handoff between the host broadcaster and the multiple rights-holding broadcasters being in the cloud and also a workflow for OTT where RIST is used for ingest.

RIST is available as an open source library called libRIST which can be downloaded from videolan and is documented in open specifications TR-06-1 and TR-06-2. LibRIST can be found in gstreamer, Upipe, VLC, Wireshark and FFmpeg.

The video finishes with questions about how RIST compares with SRT. RTMP, CMAF and WebRTC.

Watch now!
Speakers

	Tim Baldwin Head of Product, Zixi
	David Griggs Senior Product Manager, Distribution Platforms Disney Streaming Services
	Ciro Noronha President, RIST Forum Executive Vice President of Engineering, Cobalt Digital

Video: Tweaking Error Correction Protocol Performance: A libRIST Deep Dive

Posted on 9th March 2021 by Russell Trafford-Jones

There’s a false assumption that if you send video with these new error-correcting protocols like RIST or SRT that you just need to send the stream, it’ll get healed and everything will be good. But often people don’t consider what actually happens when things go wrong. To heal the stream, more data needs to be sent. Do you have enough headroom to cope with these resends? And what happens if part of your circuit becomes temporarily saturated, how will the feed cope? The reality is that it could kill it permanently due to re-request storms.

In this video from VidTrans21, Sergio Ammirata from SipRadius talks about how the error correcting protocol within RIST works and how it’s been improved to cope even better in a crisis. Joined by Adi Rozenberg they remind us of the key points of RIST and the libRIST. As a reminder, RIST is one of many protocols which allows the receiver to let the sender know which packets its missed and for them to be resent. For a proper overview of RIST and SRT, have a look at this talk explaining RIST and SRT or the multitude of talks here on The Broadcast Knowledge on RIST or SRT. Today’s video is not so much about why people use RIST, but how to make it performant with difficult circuits.

libRIST is an open-source, free, library which implements the RIST specification. The aim of libRIST is to allow companies to easily implement RIST within their own commercial and free programmes. Sergio points out that it’s an active project with over 675 commits in the last year bringing RIST to many platforms including ARM, AWS, Darwin, iOS, windows etc. and is now on version 0.2.0, plus is soon to be in VLC 4.0 and FFmpeg 4.3.

To understand why getting error correction is important, we can look at the effects of a simplistic implementation of the negative acknowledgement error recovery method. When the receiver doesn’t receive a packet it sends back a request for a resend of that packet. The sender will send that and, hopefully, it will be received. Let’s imagine, though, that you’re in a data centre sending to someone on a 100Mbps leased line. If the incoming bitrate of your receiver’s internet connection started getting close to 100Mbps due to the aggregate traffic coming into the site, the receiver may start missing out on occasional packets leading it to ask for more packets from the sender. The sender’s bitrate then increases which reduces the margin available in the incoming circuit resulting in more lost packets. This cycle continues until the line is saturated. It’s important to remember that saturating an incoming link doesn’t mean traffic can’t get out. It’s quite possible there are hundreds of megabits available outgoing so there’s plenty of bandwidth to shout for more and more re-requests. The sender is quite happy to send these re-requests as it’s on a 10Gbe link and has plenty of headroom left. Only by stopping the receiver would you be able to break this positive-feedback loop.

Now, all protocols deliver some form of control over what’s re-requested to try to manage difficult situations. Sergio agrees that other implementations of RIST work well in normal situations with less than 10% packet loss, for example. But where bursts of packet loss exceed 20% or the circuit headroom dips below 20%, Sergio says implementations tend to struggle.

As a lead-up up to the recent improvements made in congestion management, Sergio outlines how libRIST uses internal QOS to maintain a bandwidth cap. It will also monitor the RTT every tenth of a second to help spread retries over time. By checking how the RTT is changing in these extreme conditions, libRIST is able to throw away redundant re-requests leaving more bandwidth for useful requests. The fact that the sender is doing this work means that even if the receiver is on an older version of libRIST or on another implementation, the link can still benefit from the checking the libRIST 0.2.0 is doing. The upshot of all this work is that no longer can libRIST deal with 50% packet loss, it can now deliver an unblemished stream up to just shy of 70% packet loss.

Watch now!
Speaker