Video: NMOS – Ready, Steady, Go!

We have NMOS IS-04,-05, 6, 7…all the way to 10. Is it possibly too complex? Each NMOS specification brings an important feature to an IP/SMPTE ST-2022 workflow and not every system needs each one so life can become confusing. To help, NVIDIA (who own Mellanox) have been developing an open-source project which allows for quick and easy deployment of an NMOS test system.

Kicking off the presentation, Félix Poulin, explains how the EBU Pyramid for Media Nodes shows how SMPTE ST 2110 depends on a host of technologies surrounding it to create a large system. These are such as ‘Discovery and registration; channel mapping, event and tally, Network control, security and more. Félix shows how AMWA’s BCP-003-01 gives guidelines on securing NMOS comms. How IS-09 allows nodes to join the system and collect system parameters and then register itself in the IS-04 database. IS-05 and IS-06 allow end-points to be connected either through IGMP with IS-05 or by an SDN controller, using -06. IS-08 allows for audio mapping/shuffling with BCP-002-01 marking which streams belong to each other and can be taken as a bundle. IS-07 gives a way for event and tally information to be passed from place to place.

There’s a lot going on, already published and getting started can seem quite daunting. For that reason, there is an ‘NMOS at a glance‘ document now on the NMOS website. Gareth Sylvester-Bradley from Sony looks at the ongoing work within NMOS such as finalising IS-10 and BCP-003-02 both of which will enable secure authorisation of clients in the system and explains how AMWA works and ensures the correct direction of the NMOS activity groups with sufficient business cases and participation. He also outlines the importance of the NMOS testing tool and the criteria used for quality and adoption. Gareth finishes by discussing the other in-progress work from NMOS including work on EDID connection management as part of the pro AV IPMX project.

Finally, Richard Hastie introduces the ‘Easy-NMOS’ which provides very easy deployment of IS-04, 05 & 09 along with BCP-003-01 and BCP-002-01. Introduced in 2019, Mellanox – now part of NVIDIA – developed this easy-to-deploy, containerised set of 3 ‘servers’ which quickly and easily deploy these technologies including a test suite. This doesn’t move media, but it creates valid NMOS nodes and includes an MQTT broker. One container contains the NMOS Registry, controller and MQTT broker. One is a virtual mode and the last is an NMOS testing service. Richard walks us through the 4-line install and brief configuration ahead of installing this and demonstrating how to use it.

Watch now!
Speakers

Félix Poulin Félix Poulin
Director, Media Transport Architecture & Lab
CBC/Radio-Canada
Gareth Sylvester-Bradley Gareth Sylvester-Bradley
Principal engineer,
Sony EPE
Richard Hastie Richard Hastie
Senior Sales Director, Mellanox Business Development
NVIDIA

Video: AES67/SMPTE ST 2110 Audio Transport & Routing (NMOS IS-08)

Let’s face it, SMPTE ST 2110 isn’t trivial to get up and running at scale. It carries audio as AES67, though with some restrictions which can cause problems for full interoperability with non-2110 AES67 systems. But once all of this is up and running, you’re still lacking discoverability, control and management. These aspects are covered by AMWA’s NMOS IS-04, IS-05 and IS0-08 projects.

Andreas Hildrebrand, Evangelist at ALX NetworX, takes the stand at the AES exhibition to explain how this can all work together. He starts reiterating one of the main benefits of the move to 2110 over 2022-6, namely that audio devices don’t need to receive and de-embed audio. With a dependency on PTP, SMPTE ST 2110-30 an -31 define carriage of AES67 and AES3.

We take a look at IS-04 and IS-05 which define registration, discovery and configuration. Using an address received from DHCP, usually, new devices on the network will put in an entry into a an IS-04 registry which can be queried by an API to find out what senders and listeners are available in a system. IS-05 can then use this information to create connections between devices. IS-05, Andreas explains, is able to issue a create connection request to endpoints asking them to connect. It’s up to the endpoints themselves to initiate the request as appropriate.

Once a connection has been made, there remains the problem of dealing with audio mapping. Andreas uses the example of a single stream containing multiple channels. Where a device only needs to use one or two of these, IS-08 can be used to tell the receiver which audio it should be decoding. This is ideal when delivering audio to a speaker. Andreas then walks us through worked examples.

Watch now!
Speakers

Andreas Hildebrand Andreas Hildebrand
Ravenna Technology Evangelist,
ALC NetworX

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!
Speakers

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

Video: NMOS: The API for IPMX

IPMX promises a ‘plug and play’ out-of-the-box experience, but with uncompressed SMPTE ST 2110 video and audio underneath. Given many tier 1 broadcasters have invested months or years implementing ST 2110. So how can IPMX deliver on its promise to the Pro-AV market?

Andrew Starks from Macnica presents this talk explaining how NMOS will fit into IPMX. Key to enabling a minimal config environment is the added mandatory specifications and standards within IPMX. For instance, while you can build an ST 2110 system without NMOS, that’s not an option for IPMX. The focus is on consistency and interoperability. Optional parts of IPMX cover HDCP carriage, USB, RS232 and IPV6. Many of the things often used within Pro-AV but may not be appropriate for low-cost, small use-cases.

Andrew gives an overview of IS-04 and IS-05 which allow for discovery and control of devices. He then looks at EDID and USB carriage and finishes by discussing why AMWA is choosing to use open specifications rather than creating standards.

Watch now!
Speakers

Andrew Starks Andrew Starks
Director of Product Management,
Macnica Technology,