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

Video: RIST in the Cloud

Posted on 22nd April 2020 by Adam K

Cloud workflows are starting to become an integral part of broadcasters’ live production. However, the quality of video is often not sufficient for high-end broadcast applications where cloud infrastructure providers such as Google, Oracle or AWS are accessed through the public Internet or leased lines.

A number of protocols based on ARQ (Adaptive Repeat reQuest) retransmission technology have been created (including SRT, Zixi, VideoFlow and RIST) to solve the challenge of moving professional media over the Internet which is fraught with dropped packets and unwanted delays. Protocols such as a SRT and RIST enable broadcast-grade video delivery at a much lower cost than fibre or satellite links.

The RIST (Reliable Internet Streaming Transport) protocol has been created as an open alternative to commercial options such as Zixi. This protocol is a merging of technologies from around the industry built upon current standards in IETF RFCs, providing an open, interoperable and technically robust solution for low-latency live video over unmanaged networks.

In this presentation David Griggs from Amazon Web Services (AWS) talks about how the RIST protocol with cloud technology is transforming broadcast content distribution. He explains that delivery of live content is essential for the broadcasters and they look for a way to deliver this content without using expensive private fibre optics or satellite links. With unmanaged networks you can get content from one side of the world to the other with very little investment in time and infrastructure, but it is only possible with protocols based on ARQ like RIST.

Next, David discusses the major advantages of cloud technology, being dynamic and flexible. Historically dimensioning the entire production environment for peak utilisation was financially challenging. Now it is possible to dimension it for average use, while leveraging cloud resources for peak usage, providing a more elastic cost model. Moreover, the cloud is a good place to innovate and to experiment because the barrier to entry in terms of cost is low. It encourages both customers and vendors to experiment and to be innovative and ultimately build more compelling and better solutions.

David believes that open and interoperable QoS protocols like RIST will be instrumental in building complex distribution networks in the cloud. He hopes that AWS by working together with Net Insight, Zixi and Cobalt Digital can start to build innovative and interoperable cloud solutions for live sports.

Watch now!

Speaker

David Griggs
Senior Product Manager, Media Services
AWS Elemental

Video: NMOS and ST 2110 Pro AV Roadmap

Posted on 12th March 2020 by Russell Trafford-Jones

ProAV and Broadcast should be best buddies, but only a relatively few companies sell into both. This is because there are legitimate differences in what we need. That being said, interoperability is a helpful end goal for any industry. Whilst proprietary solutions can help kickstart new technologies and be a positive disruptive force, standardisation is almost always beneficial to the industry in the medium to long term.

Whilst broadcast is happy to live with 4:2:2 colour subsampling in much of its workflow, then deliver in 4:2:0, this is often not an option for ProAV who need to take full 4:4:4 4K at 60fps and throw it on a monitor. Whilst 4:4:4 has, technically been possible over SDI for a while, adoption even in the broadcast market has been small.

There are many opportunities for both industries to learn from each other, but it’s hard to overstate the difference in approach of the SMPTE 2110 and NMOS approach to the problem of media over IP compared to the SDVoE model. The former relies on detailed documentation published publicly for anyone who is willing to buy the standard to implement in any way they see fit be that in software or hardware. The latter specifies a chip which has a documented API that does all of the heavy lifting with no option for self-implementation. The fact that the same chip is used everywhere provides the guarantee of interoperability.

One technology which has bridged the gap between ProAV and broadcast is NDI from Vizrt’s Newtek which uses the same binary software application wherever it’s implemented thus providing, like in SDVoE, the interoperability required. The same is true for SRT although they have just released their first draft for IETF standardisation.

In this talk, PESA CTO Scott Barella examines the many existing standards within ProAV and examines their needs such as HDCP. Whilst HDCP, the High-bandwidth Digital Content Protection mechanism, has often been grappled with by broadcasters, it is at least a standard. And it’s a standard that any vendor will have to deal with if they want their equipment to be widely used in the industry. Similarly the requirement for full-frame rate, full-colour UHD is not simply done within many boxes.

The use of PTP within SMPTE’s ST 2110 suite works perfectly in the studio, is arguably not necessary in much of ‘the cloud’ and is widely considered too complex for a ProAV environment. Scott explains that he has thoughts on how to simplify it to make it more practical and taking into account the different use cases.

Secondary interfaces are crucial in much ProAV whereby USB, RS 232 serial and GPI/GPO need to be transported along with the media. And whilst security and encryption are increasingly important for the broadcast industry as it comes to grips with the fact that all broadcasters are vulnerable to hacking attempts, their requirements are not as stringent as the military’s which drives a notable part of the ProAV market. All of these aspects are being considered as part of the ongoing work the Scott is involved with.

Watch now! and download the presentation
Speaker

Scott Barella
CTO, PESA
AIMS co-chair.

Video: There and back again: reinventing UDP streaming with QUIC

Posted on 6th January 2020 by Russell Trafford-Jones

QUIC is an encrypted transport protocol for increased performance compared to HTTP but will this help video streaming platforms? Often conflated with HTTP/3, QUIC is a UDP-based way evolution of HTTP/2 which, in turn, was a shake-up of the standard HTTP/1.1 delivery method of websites. HTTP/3 uses the same well-known security handshake from TLS 1.3 that is well adopted now in websites around the world to provide encryption by default. Importantly, it creates a connection between the two endpoints into which data streams are multiplexed. This prevents the need to constantly be negotiating new connections as found in HTTP/1.x so helping with speed and efficiency. These are known as QUIC streams.

QUIC streams provide reliable delivery, explains Lucas Pardue from Cloudflare, meaning it will recover packets when they are lost. Moreover, says Lucas, this is done in an extensible way with the standard specifying a basic model, but this is extensible. Indeed, the benefit of basing this technology on UDP is that changes can be done, programmatically, in user-space in lieu of the kernel changes that are typically needed for improved TCP handling on which HTTP/1.1, for example, is based.

QUIC hailed from a project of the same name created by Google which has been taken in by the IETF and, in the open community, honed and rounded into the QUIC we are hearing about today which is notably different from the original but maintaining the improvements proved in the first release. HTTP/3 is the syntax which is a development on from HTTP/2 which uses the QUIC transport protocol underneath or as Lucas would say, “HTTP/3 is the HTTP application mapping to the QUIC transport layer.” Lucas is heavily involved within the IETF effort to standardise HTTP/3 and QUIC so he continues in this talk to explain how QUIC streams are managed, identified and used.

It’s clear that QUIC and HTTP/3 are being carefully created to be tools for future, unforeseen applications with clear knowledge that they have wide applicability. For that reason, we are already seeing projects to add datagrams and RTP into the mix, to add multiparty or multicast. In many ways mimicking what we already have in our local networks. Putting them on QUIC can enable them to work on the internet and open up new ways of delivering streamed video.

The talk finishes with a nod to the fact that SRT and RIST also deliver many of the things QUIC delivers and Lucas leaves open the question of which will prosper in which segments of the broadcast market.

The Broadcast Knowledge has well over 500 talks/videos on many topics so to delve further into anything discussed above, just type into the search bar on the right. Or, for those who like URLs, just add your search query to the end of this URL https://thebroadcastknowledge.com/tag/.

Lucas has already written in detail about his work and what HTTP 3 is on his Cloudflare blog post.

Watch now!
Speaker

Lucas Pardue
Senior Software Engineer,
Cloudflare

Video: 2019 What did I miss? – Introducing Reliable Internet Streaming Transport

Posted on 3rd January 2020 by Russell Trafford-Jones

By far the most visited video of 2019 was the Merrick Ackermans’ review of RIST first release. RIST, the Reliable Internet Stream Transport protocol, aims to be an interoperable protocol allowing even lossy networks to be used for mission-critical broadcast contribution. Using RIST can change a bade internet link into a reliable circuit for live programme material, so it’s quite a game changer in terms of cost for links.

An increasing amount of broadcast video is travelling over the public internet which is currently enabled by SRT, Zixi and other protocols. Here, Merrick Ackermans explains the new RIST specification which aims to allow interoperable internet-based video contribution. RIST, which stands for Reliable Internet Stream Transport, ensures reliable transmission of video and other data over lossy networks. This enables broadcast-grade contribution at a much lower cost as well as a number of other benefits.

Many of the protocols which do similar are based on ARQ (Automatic Repeat-reQuest) which, as you can read on wikipedia, allows for recovery of lost data. This is the core functionality needed to bring unreliable or lossy connections into the realm of usable for broadcast contribution. Indeed, RIST is an interesting merging of technologies from around the industry. Many people use Zixi, SRT, and VideoFlow all of which can allow safe contribution of media. Safe meaning it gets to the other end intact and un-corrupted. However, if your encoder only supports Zixi and you use it to deliver to a decoder which only supports SRT, it’s not going to work out. The industry as accepted that these formats should be reconciled into a shared standard. This is RIST.

File-based workflows are mainly based on TCP (Transmission Control Protocol) although, notably, some file transfer service just as Aspera are based on UDP where packet recovery, not unlike RIST, is managed as part of the the protocol. This is unlike web sites where all data is transferred using TCP which sends an acknowledgement for each packet which arrives. Whilst this is great for ensuring files are uncorrupted, it can impact arrival times which can lead to live media being corrupted.

RIST is being created by the VSF – the Video Standards Forum – who were key in introducing VS-03 and VS-04 into the AIMS group on which SMPTE ST 2022-6 was then based. So their move now into a specification for reliable transmission of media over the internet has many anticipating great things. At the point that this talk was given the simple profile has been formed. Whist Merrick gives the details, it’s worth pointing out that this doesn’t include intrinsic encryption. It can, of course, be delivered over a separately encrypted tunnel, but an intrinsic part of SRT is the security that is provided from within the protocol.

Despite Zixi, a proprietary solution, and Haivision’s open source SRT being in competition, they are both part of the VSF working group creating RIST along with VideoFlow. This is because they see the benefit of having a widely accepted, interoperable method of exchanging media data. This can’t be achieved by any single company alone but can benefit all players in the market.

This talk remains true for the simple profile which just aims to recover packets. The main protocol, as opposed to ‘simple’, has since been released and you can hear about it in a separate video here. This protocol adds FEC, encryption and other aspects. Those who are familiar with the basics may whoosh to start there.

Speaker