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

Video: Low Latency Live Streaming At Scale

Posted on 1st September 2020 by Russell Trafford-Jones

Low latency can be a differentiator for a live streaming service, or just a way to ensure you’re not beaten to the punch by social media or broadcast TV. Either way, it’s seen as increasingly important for live streaming to be punctual breaking from the past where latencies of thirty to sixty seconds were not uncommon. As the industry has matured and connectivity has enough capacity for video, simply getting motion on the screen isn’t enough anymore.

Steve Heffernan from MUX takes us through the thinking about how we can deliver low latency video both into the cloud and out to the viewers. He starts by talking about the use cases for sub-second latency – anything with interaction/conversations – and how that’s different from low-latency streaming which is one to many, potentially very large scale distribution. If you’re on a video call with ten people, then you need sub-second latency else the conversation will suffer. But distributing to thousands or millions of people, the sacrifice in potential rebuffering of operating sub-second, isn’t worth it, and usually 3 seconds is perfectly fine.

Steve talks through the low-latency delivery chain starting with the camera and encoder then looking at the contribution protocol. RTMP is still often the only option, but increasingly it’s possible to use WebRTC or SRT, the latter usually being the best for streaming contribution. Once the video has hit the streaming infrastructure, be that in the cloud or otherwise, it’s time to look at how to build the manifest and send the video out. Steve talks us through the options of Low-Latency HLS (LHLS) CMAF DASH and Apple’s LL-HLS. Do note that since the talk, Apple removed the requirement for HTTP/2 push.

The talk finishes off with Steve looking at the players. If you don’t get the players logic right, you can start off much farther behind than necessary. This is becoming less of a problem now as players are starting to ‘bend time’ by speeding up and slowing down to bring their latency within a certain target range. But this only underlines the importance of the quality of your player implementation.

Watch now!
Speaker

Steve Heffernan
Founder & Head of Product, MUX
Creator of video.js

Video: Low Latency, Real-Time Streaming & WebRTC

Posted on 24th August 2020 by Russell Trafford-Jones

Can any stream be too low-latency? For some matching broadcast latency, is all they need. But for others, particularly for gaming, gambling or more interactive services, sub-second is a must and they are happy to swap out parts of their technology stack to make that happen. WebRTC is often seen as the best choice for anyone wanting to go achieve an almost instant stream. Started by Google in 2011 for video conferencing applications, WebRTC hit a 1.0 release in 2018 and has been adopted by a number of companies catering to the broadcast market.

WebRTC stands out among the plethora of streaming protocols since it is an actual stream of data and not a series of files transferred just in time. Traditionally buffers have been heavily used in streaming because it was so hard to get data to the player when the mainstream internet was starting out in the 90s and as the mobile internet was establishing itself 10 years later. Whilst those buffers are very helpful in dealing with delayed data, they are a big set back in delivering a low-latency stream. With WebRTC, there is very little buffering, so when using the protocol you have to understand that you may not get all your data delivered and if packets are missing glitches will be seen. This is one significant difference since MPEG DASH and HLS will either show you a blank screen or a perfect rendition of the file chunk that was sent thanks to TCP. This is an example of the compromises of going to sub-second latency; there are no second chances to get the packet again. And whilst this compromise may be a great exchange for an auction site or betting service, for other streaming services, it may be better to use CMAF with 3-second latency.

In this talk, Limelight Networks Video Architect Andrew Crowe introduces WebRTC and explains how it can be deployed. He starts by talking about the video codecs it contains. VP9 has recently been added to the options and for a long time, it was a VP8 technology. Andrew explains how the codecs it carries does have a knock-on effect on its compatibility with browsers. UDP is the underlying technology to all low-latency technologies since the bureaucracy of TCP/IP gets in the way of real-time media streams. Andrew also explains how security pervades WebRTC from its use of DTLS (which is like HTTPS/TLS for UDP) to secure RTP and SRTCP.

The last part of the talk discusses the architectures that CDN LimeLight uses to enable large-scale WebRTC streams including the need to get through firewalls. Andrew discusses how some features of the technology suit small-scale events, but can’t be used with thousands of viewers. He also discusses how adaptive bitrate streams can be delivered, although not within WebRTC itself, there is enough information to implement ABR in addition to the standard stream.

Watch now!
Speakers

Andrew Crowe
Video Architect,
Limelight Networks

Video: Reliable, Live Contribution over the Internet

Posted on 20th August 2020 by Russell Trafford-Jones

For so long we’ve been desperate for a cheap and reliable way to contribute programmes into broadcasters, but it’s only in recent years that using the internet for live-to-air streams has been practical for anyone who cares about staying on-air. Add to that an increasing need to contribute live video into, and out of, cloud workflows, it’s easy to see why there’s so much energy going into making the internet a reliable part of the broadcast chain.

This free on-demand webcast co-produced by The Broadcast Knowledge and SMPTE explores the two popular open technologies for contribution over the internet, RIST and SRT. There are many technologies that pre-date those, including Zixi, Dozer and QVidium’s ARQ to name but 3. However, as the talk covers, it’s only in the last couple of years that the proprietary players have come together with other industry members to work on an open and interoperable way of doing this.

Russell Trafford-Jones, from UK video-over-IP specialist Techex, explores this topic starting from why we need anything more than a bit of forward error correction (FEC) moving on to understanding how these technologies apply to networks other than the internet.

This webcast looks at how SRT and RIST work, their differences and similarities. SRT is a well known protocol created and open sourced by Haivision which predates RIST by a number of years. Haivision have done a remarkable job of explaining to the industry the benefits of using the internet for contibution as well as proving that top-tier broadcasters can rely on it.

RIST is more recent on the scene. A group effort from companies including Haivision, Cobalt, Zixi and AWS elemental to name just a few of the main members, with the aim of making a vendor-agnostic, interoperable protocol. Despite, being only 3 years old, Russell explains the 2 specifications they have already delivered which brings them broadly up to feature parity with SRT and are closing in on 100 members.

Delving into the technical detail, Russell looks at how ARQ, the technology fundamental to all these protocols works, how to navigate firewalls, the benefits of GRE tunnels and much more!

The webcast is free to watch with no registration required.

Watch now!
Speakers

Russell Trafford-Jones
Manager, Support & Services, Techex
Director of Education, Emerging Technologies, SMPTE
Editor, The Broadcast Knowledge

Video: Getting Your Virtual Hands On RIST

Posted on 5th August 2020 by Russell Trafford-Jones

RIST is one of a number of error correction protocols that provide backwards error correction. These are commonly used to transport media streams into content providers but are increasingly finding use in other parts of the broadcast workflow including making production feeds, such as multiviewers and autocues available to staff at internet-connected locations, such as the home.

The RIST protocol (Reliable Internet Stream Protocol) is being created by a working group in the VSF (Video Services Forum) to provide an open and interoperable specification, available for the whole industry to adopt. This article provides a brief summary, whereas this talk from FOSDEM20 goes into some detail.

We’re led through the topic by Sergio Ammirata, CTO of DVEO who are members of the RIST Forum and collaborating to make the protocol. What’s remarkable about RIST is that several companies which have created their own error-correcting streaming protocols such as DVEO’s Dozer, which Sergio created, have joined together to share their experience and best practices.

Press play to watch:

Sergio starts by explaining why RIST is based on UDP – a topic explored further in this article about RIST, SRT and QUIC – and moves on to explaining how it works through ‘NACK’ messages, also known as ‘Negative Acknowledgement’ messages.

We hear next about the principles of RIST, of which the main one is interoperability. There are two profiles, simple and main. Sergio outlines the Simple profile which provides RTP and error correction, channel bonding. There is also the Main profile, which has been published as VSF TR-06-2. This includes encryption, NULL packet removal, FEC and GRE tunnelling. RIST uses a tunnel to multiplex many feeds into one stream. Using Cisco’s Generic Routing Encapsulation (GRE), RIST can bring together multiple RIST streams and other arbitrary data streams into one tunnel. The idea of a tunnel is to hide complexity from the network infrastructure.

Tunnelling allows for bidirectional data flow under one connection. This means you can create your tunnel in one direction and send data in the opposite direction. This gets around many firewall problems since you can create your tunnel in the direction which is easiest to achieve without having to worry about the direction of dataflow. Setting up GRE tunnels is outside of the scope of RIST.

Sergio finishes by introducing librist, demo applications and answerin questions from the audience.

Watch now!
Speaker