Video: Progress Update for the ST 2110 WAN VSF Activity Group

2110 Over WAN Update

Is SMPTE ST 2110 suitable for inter-site connectivity over the WAN? ST 2110 is moving past the early adopter phase with more and more installations and OB vans bringing 2110 into daily use but today, each site works independently. What if we could maintain a 2110 environment between sites. There are a number of challenges still to be overcome and moving a large number of essence flows long distances and between PTP time domains is one of them.

Nevion’s Andy Rayner is chair of the VSF Activity Group looking into transporting SMPTE ST 2110 over WAN and is here to give an update on the work in progress which started 18 months ago. The presentation looks at how to move media between locations which has been the primary focus to date then introduces how controlling over which media are shared will be handled which is new to the discussions. Andy starts by outlining the protection offered in the scheme which supports both 2022-7 and FEC. Andy explains that though FEC is valuable for single links where 2022-7 isn’t viable, only some of the possible ST 2022-5 FEC configurations are supported, in part, to keep latency low.

The headline to carrying 2110 over the WAN is that it will be done over a trunk. GRE is a widely used Cisco trunking technology. Trunking, also known as tunnelling, is a technique of carrying ‘private’ traffic over a network such that a device sending into the trunk doesn’t see any of the infrastructures between the entrance and the exit. It allows, for instance, IPv6 traffic to be carried over IPv4 equipment where the v4 equipment has no idea about the v6 data since it’s been wrapped in a v4 envelope. Similarly, the ipv6 equipment has no idea that the ipv6 data is being wrapped and carried by routers which don’t understand ipv6 since the wrapping and unwrapping of the data is done transparently at the handoff.

In the context of SMPTE ST 2110, a trunk allows one port to be used to create a single connection to the destination, yet carry many individual media streams within. This has the big benefit of simplifying the inter-site connectivity at the IT level, but importantly also means that the single connection is quite high bandwidth. When FEC is applied to a connection, the latency introduced increases as the bit rate reduces. Since ST 2110 carries audio and metadata separately, an FEC-protected stream would have variable latency depending on the type of the of traffic. Bundling them in to one large data stream allows FEC to be applied once and all traffic then suffers the same latency increase. The third reason is to ensure all essences take the same network path. If each connection was separate, it would be possible for some to be routed on a physically different route and therefore be subject to a different latency.

Entering the last part of the talk, Andy switches gears to talk about how site A can control streams in site B. The answer is that it doesn’t ‘control’, rather there is the concept of requesting streams. Site A will declare what is available and site B can state what it would like to connect to and when. In response, site A can accept and promise to have those sources available to the WAN interface at the right time. When the time is right, they are released over the WAN. This protects the WAN connectivity from being filled with media which isn’t actually being used. These exchanges are mediated and carried out with NMOS IS-04 an IS-05.

Watch now!

Andy Rayner Andy Rayner
Chief Technologist, Nevion,
Chair, WAN IP Activity Group, VSF
Wes Simpson Moderator: Wes Simpson
Co-chair RIST Activity Group, VSF

Video: Reliable, Live Contribution over the Internet

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!

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

Video: SRT Protocol Overview

SRT’s ability to make lossy networks seem like perfect video circuits is increasingly well known, testified to by the SRT Alliance having just surpassed 400 member companies. But this isn’t your average ‘overview’, it dispenses with the technology introductions and goes straight into the detail so is ideal for people who already know the basics and want some deeper knowledge plus a look at the new features to come.

For those wanting an introduction, this article What is SRT? is a good starter which also links to two other intro videos. But today we’re going to join Haivision’s Maxim Sharabayko to look below the surface of SRT.

Maxim starts by introducing the open-source Git repository and the open-source integrations available before heading into the feature matrix. This shows what is and isn’t in SRT. We see that on top of ARQ, it has FEC, encryption, stream multiplexing and, soon, connection bonding. Addressing the major feature areas one by one, we start with connectivity.

SRT has two modes to establish a connection which Maixm shows on handshake diagrams. We can see that establishment need only take 2x round trips so is quick to establish. This allows Maxim to show how firewall traversal is accomplished, though NAT traversal is not yet implemented.

Next on the list of topics is access control whereby we need to ensure that only authorised users can gain access. This is achieved using the Stream ID field within SRT control packets which can contain up to 512 characters meaning it can be used to transfer usernames, passwords (in the form of keys) and requests. Maxim then explains the AES PSK encryption function and discusses the potential implementation of TLS and DTLS.

Content delivery is next under the magnifying glass starting with the structure of SRT packets and the difference between the two types: Data and Control, the former being restricted to only containing payload or FEC data. Maxim covers the positive acknowledgement which is contained with SRT with the range of received packets being acknowledged every 10ms and, where 64 packets come in less than 10ms, a low-overhead acknowledgement being sent for each group of 64 data packets. But of course, it’s the NAK packets which are the most important part of the protocol. Maxim explains they are able to send back one sequence number or a range of lost packets and talks about when they are sent. We see how this then fits into the Timestamp Based Packet Delivery (TSBPD) mechanism which itself is a feature of SRT which delivers packets to the receiver with the same timing as they arrived at the sender. The last thing we look at in the section is a worked example of Too-Late Packet Drop which explains when and why packets are dropped.

ARQ isn’t the only recovery mechanism in SRT, it also provides FEC and, soon, channel bonding. FEC’s can be useful but do have downsides which should be understood. There is a permanent bandwidth overhead, even when the circuit is working well, and a further latency is needed in order to generate the necessary recovery packets. Bonding allows you to stream the same stream over more than one circuit and use data from circuit B to fill in any gaps in circuit A, this technique is used in SMPTE ST 2022-7. Connection bonding, though, can also be used with multiple connections at once and having dynamic balancing across them. Maxim sums up the pros and cons of the different techniques in the table below.

Pros and cons of different packet recovery techniques. Source: Haivision

The talk finishes with a look at stream multiplexing, congestion control and ways in which you can use the SRT statistics which are constantly updated to manage your connectivity.

Watch now!

Maxim Sharabayko Maxim Sharabayko
Senior Software Developer,

Video: A Study of Protocols for Low Latency Video Transport Over the Internet

Contribution via the internet is tricky but has great promise. With packet loss and jitter all over the place, how can you deliver perfect video?

Ciro Noronha from Cobalt Digital explains the two ways people get around the unreliability of the internet: FEC and retransmission. Forward Error Correction uses some maths to transmit extra data on top of the stream which allows the receiver to correct for any packet losses. This method is standard in satellite transmission where it is always used to add robustness.

Retransmission is different in that it requires a return channel. When a receiver spots a missing packet, it asks for it to be resent. Being that it has to wait for a reply, retransmission protocols like SRT, ARQ and RIST run with a configurable buffer which needs to be big enough for at least one round trip. FEC schemes also require a buffer as it needs to wait for a number of packets before it can complete the maths required.

Ciro introduces FEC and ARQ before presenting work showing experiments he’s run on both FEC and ARQ to see the limits of their signal-correcting capabilities and latency. He finishes explaining what RIST is and its status.

Bring yourself up to date with RIST!
Watch now!


Ciro Noronha Ciro Noronha
Director of Technology,
Cobalt Digital