IS-04

Video: IPMX for Broadcast Installations?

Posted on by Russell Trafford-Jones

IPMX, the new ProAV IP challenger spec, is taking shape promising to tame SMPTE’s ST 2110 standards, make PTP useable and extend AMWA into managing HDCP. Is this a tall order and can it actually deliver? Taking us through the ins and out is Jean Lapierre from Matrox.

With or without IPMX, ProAV is moving to IP whether with SDVoE, ZeeVee or something else. There are a number of competing technologies, but we hear from Jean that IPMX is the only software-defined one. This is important because if you don’t require a chip to be an IPMX product and participate in ProAV workflows, then anything can support IPMX such as PCs, Laptops and mobile phones.

 

 

IPMX based on RTP, ST 2110, ST 2059 PTP and AMWA specifications IS-04, IS-05, IS-08 (audio channel mapping), IS-11 for EDID handling as well as NMOS security and best practice guidance. This seems like a lot, but to cover media transfer, registration, control, security and interfacing with display screens, this is the range of tech needed.

Compared to SMPTE ST 2110, the PTP profile is easier to deploy and produces less traffic, explains Jean, and IPMX even works without PTP which support for asynchronous signals. Support of HDCO is included along with a lower-latency FEC mode for those that find 2022-7 too costly or impractical to deploy. Lastly, Jean points out that thanks to the in-built support for JPEG XS, IPMX can support UHD workflows within a 1GbE infrastructure.

Jean continues by discussing the compatibility between 2110 and IPMX. In principle IPMX and 2110 senders and receivers are interchangeable. Jean goes into more detail, but the example would be that IPMX is managing the HDCP encryption of the source using AMWA NMOS IS-11. IS-11 is, naturally available to be used with any other technology including ST 2110. If it’s adopted, then HDCP-protected material can flow between the two systems.

Watch now!
Speaker

Jean Lapierre Jean Lapierre
Senior Director, Advanced Technologies,
Matrox

Video: A Frank Discussion of NMOS

Posted on by Russell Trafford-Jones

What NMOS isn’t is almost as important as what NMOS actually is when it comes to defining a new project implementing SMPTE ST 2110. Written by AMWA, NMOS is a suite of open specifications which help control media flow hence the name: Network Media Open Specifications. Typically NMOS specifications are used alongside the ST 2110 standards but in this hype-free panel, we hear that 2110 isn’t the only application of NMOS.

AMWA Executive Director Brad Gilmer introduces this ‘frank’ panel with Imagine’s John Mailhot explaining the two meanings ‘NMOS’ has. The first is the name of the project we have just introduced in this article. The second is as shorthand for the two best-known specifications created by the project, IS-04 and IS-05. Together, these allow new devices to register their availability to the rest of the system and to receive instructions regarding sending media streams. There are plenty of other specifications which are explained in this talk of which two more are mentioned later in this video: IS-08 which manages audio channel mapping and IS-09 which allows new devices to get a global configuration to automatically find out facts like their PTP domain.

 

 

Security is “important and missing previously,” says Jed Deame from Nextera but explains that since NMOS is predominantly a specification for HTTP API calls, there is nothing to stop this from happening as HTTPS or another protocol as long as it provides both encryption and authorisation. The panel then explores the limits of the scope of NMOS. For security, its scope is to secure the NMOS control traffic, so doesn’t stretch to securing the media transport or, say, PTP. Furthermore, for NMOS as a whole, it’s important to remember it defines control and not more than control. Brad says, though, that even this scope is ambiguous as where does the concept of ‘control’ stop? Is a business management system control? What about scheduling of media? Triggering playback? There have to be limited.

Imagine Communications’ John Mailhot explores the idea of control asking how much automation, and hence NMOS-style control, can help realise one of the promises of IP which is to reduces costs by speeding up system changes. Previously, Brad and John explain, changing a studio from doing NFL to doing NHL may take up to a month of rewiring and reprogramming. Now that rewiring can be done in software, John contends that the main task is to make sure the NMOS is fully-fledged enough to allow interoperable enumeration, configuration and programming of links within the system. The current specifications are being reinforced by ‘modelling’ work whereby the internal logical blocks of equipment, say an RGB gain control, can be advertised to the network as a whole rather than simply advertising a single ‘black box’ like an encoder. Now it’s possible to explain what pre and post-processing is available.

Another important topic explored by NVIDIA’s Richard Hastie and Jeremy Nightingale from Macnica, is the use of NMOS specifications outside of ST 2110 installations. Richard says that NVIDIA is using NMOS in over 200 different locations. He emphasises its use for media whether that be HEVC, AV1 or 2110. As such, he envisages it being used by ‘Twitch streamers’ no doubt with the help of the 2110-over-WAN work which is ongoing to find ways to expose NMOS information over public networks. Jeremy’s interest is in IPMX for ProAV where ‘plug and play’ as well as security are two of the main features being designed into the package.

Lastly, there’s a call out to the tools available. Since NMOS is an open specification project, the tools are released as Open Source which companies being encouraged to use the codebase in products or for testing. Not only is there a reference client, but Sony and BBC have released an NMOS testing tool and EasyNMOS provides a containerised implementation of IS-04 and IS-05 for extremely quick deployments of the toolset.

Watch now!
Speakers

Brad Gilmer Brad Gilmer
Executive Director, Video Services Forum
Executive Director, Advanced Media Workflow Association (AMWA)
John Mailhot John Mailhot
CTO Networking & Infrastructure
Jed Deame Jed Deame
CEO,
Nextera Video
Richard Hastie Richard Hastie
Senior Sales Director,
NVIDIA
Jeremy Nightingale
President
Macnica Americas, Inc.

Video: How to Deploy an IP-Based Infrastructure

Posted on by Russell Trafford-Jones

An industry-wide move to any new technology takes time and there is a steady flow of people new to the technology. This video is a launchpad for anyone just coming into IP infrastructures whether because their company is starting or completing an IP project or because people are starting to ask the question “Should we go IP too?”.

Keycode Media’s Steve Dupaix starts with an overview of how SMPTE’s suite of standards called ST 2110 differs from other IP-based video and audio technologies such as NDI, SRT, RIST and Dante. The key takeaways are that NDI provides compressed video with a low delay of around 100ms with a suite of free tools to help you get started. SRT and RIST are similar technologies that are usually used to get AVC or HEVC video from A to B getting around packet loss, something that NDI and ST 2110 don’t protect for without FEC. This is because SRT and RIST are aimed at moving data over lossy networks like the internet. Find out more about SRT in this SMPTE video. For more on NDI, this video from SMPTE and VizRT gives the detail.

 

 

ST 2110’s purpose is to get high quality, usually lossless, video and audio around a local area network originally being envisaged as a way of displacing baseband SDI and was specced to work flawlessly in live production such as a studio. It brings with it some advantages such as separating the essences i.e. video, audio, timing and ancillary data are separate streams. It also brings the promise of higher density for routing operations, lower-cost infrastructure since the routers and switches are standard IT products and increased flexibility due to the much-reduced need to move/add cables.

Robert Erickson from Grass Valley explains that they have worked hard to move all of their product lines to ‘native IP’ as they believe all workflows will move IP whether on-premise or in the cloud. The next step, he sees is enabling more workflows that move video in and out of the cloud and for that, they need to move to JPEG XS which can be carried in ST 2110-20. Thomas Edwards from AWS adds their perspective agreeing that customers are increasingly using JPEG XS for this purpose but within the cloud, they expect the new CDI which is a specification for moving high-bandwidth traffic like 2110-20 streams of uncompressed video from point to point within the cloud.

John Mailhot from Imagine Communications is also the chair of the VSF activity group for ground-cloud-cloud-ground. This aims to harmonise the ways in which vendors provide movement of media, whatever bandwidth, into and out of the cloud as well as from point to point within. From the Imagine side, he says that ST 2110 is now embedded in all products but the key is to choose the most appropriate transport. In the cloud, CDI is often the most appropriate transport within AWS and he agrees that JPEG XS is the most appropriate for cloud<->ground operations.

The panel takes a moment to look at the way that the pandemic has impacted the use of video over IP. As we heard earlier this year, the New York Times had been waiting before their move to IP and the pandemic forced them to look at the market earlier than planned. When they looked, they found the products which they needed and moved to a full IP workflow. So this has been the theme and if anything has driven, and will continue to drive, innovation. The immediate need provided the motivation to consider new workflows and now that the workflow is IP, it’s quicker, cheaper and easier to test new variation. Thomas Edwards points out that many of the current workflows are heavily reliant on AVC or HEVC despite the desire to use JPEG XS for the broadcast content. For people at home, JPEG XS bandwidths aren’t practical but RIST with AVC works fine for most applications.

Interoperability between vendors has long been the focus of the industry for ST 2110 and, in John’s option, is now pretty reliable for inter-vendor essence exchanges. Recently the focus has been on doing the same with NMOS which both he and Robert report is working well from recent, multi-vendor projects they have been involved in. John’s interest is working out ways that the cloud and ground can find out about each other which isn’t a use case yet covered in AMWA’s NMOS IS-04.

The video ends with a Q&A covering the following:

  • Where to start in your transition to IP
  • What to look for in an ST 2110-capable switch
  • Multi-Level routing support
  • Using multicast in AWS
  • Whether IT equipment lifecycles conflict with Broadcast refresh cycles

    • Watch now!
    Speakers

    John Mailhot John Mailhot
    CTO & Director of Product Management, Infrastructure & Networking,
    Imagine Communications
    Ciro Noronha Ciro Noronha
    Executive Vice-President of Engineering,
    Cobalt Digital
    Thomas Edwards Thomas Edwards
    Principal Solutions Architect & Evangelist,
    Amazon Web Services
    Robert Erickson Robert Erickson
    Strategic Account Manager Sports and Venues,
    Grass Valley
    Steve Dupaix Steve Dupaix
    Senior Account Executive,
    Key Code Media

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

    Posted on by Russell Trafford-Jones

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

    Andreas Hildebrand Andreas Hildebrand
    Ravenna Technology Evangelist,
    ALC NetworX