AIMS

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: Live Media Production – The Ultimate End Game

Posted on by Russell Trafford-Jones

A lot of our time on this website is devoted to understanding the changes we are going through now, but we don’t adopt technology for the sake of it. Where’s this leading and what work is going on now to forge our path? Whilst SMPTE ST 2110 and the associated specifications aren’t yet a mature technology in that sense SDI, we’re past the early adopter phase and we can see which of the industry’s needs aren’t yet met.

Andy Rayner from Nevion is here to help us navigate the current technology space and understand the future he and Nevion envision. The beginning of the video shows the big change in process from the workflows of the 90s where the TV station moved to sports events to now where we bring the event to the broadcaster in the form of a light connectivity truck turning up and deploying cameras at the event leaving most people either at home or back at base doing the production there. Andy has been involved in a number of implementations enabling this such as at Discovery’s Eurosport where the media processing is done in two locations separate from the production rooms around Europe.

 

 

Generalising around the Discovery case study, Andy shows a vision of how many companys will evolve their workflows which includes using 5G, public and private clouds as appropriate and including control surfaces being at home. To get there, Andy lays out the work within AMWA and SMPTE creating the specifications and standards that we need. He then shows how the increasing use of IT in live production, the already IT-based NLE workflows are able to integrate much better.

Looking to the future, Andy explains the work ongoing to specify a standard way of getting video into and out of the cloud including specifying a way of carrying 2110 on the WAN, helping RIST and formalising the use of JPEG XS. Andy anticipates a more standardised future where a best of breed system is possible down to individual logical components like ‘video keyer’ and ‘logo insertion’ could be done by separate software but which seamlessly integrate. Lastly, Andy promises us that work is underway to improve timing within 2110 and 2110-associated workflows.

Watch now!
Speaker

Andy Rayner Andy Rayner
Chief Technologist
Nevion

Video: PTP Over Wan

Posted on by Russell Trafford-Jones

Work is ongoing in the IPMX project to reduce SMPTE ST 2110’s reliance on PTP, but the reality is that PTP is currently necessary for digital audio systems as well as for most ST 2110 workflows. There are certainly challenges in deploying PTP from an architectural standpoint with some established best practices, but these are only useful when you have the PTP signal itself. For the times when you don’t have a local PTP clock, delivery over a WAN may be your only solution. With PTP’s standards not written with a WAN in mind, can this be done and what are the problems?

 

 

Meinberg’s Daniel Boldt describes the work he’s been involved with in testing PTP delivery over Wide Area Networks (WANs) which are known for having higher, more variable latency than Local Area Networks (LANs) which are usually better managed with low latency which users can interrogate to understand exactly how traffic is moving and configure it to behave as needed. One aspect that Daniel focuses on today is Packet Delay Variation (PDV) which is a term that describes the difference in time between the packets which arrive the soonest and those that arrive last. For accurate timing, we would prefer overall latency to be very low and for each packet to take the same amount of time to arrive. In real networks, this isn’t what happens as there are queuing delays in network equipment depending on how busy the device is both in general and on the specific port being used for the traffic. These delays vary from second to second as well as throughout the day. Asymmetry can develop between send and receive paths meaning packets in one direction take half the time to arrive than those in the other. Finally, path switching can create sudden step changes in path latency.

Boundary Clocks and Transparent Clocks can resolve some of this as they take in to account the delays through switches. Over the internet, however, these just don’t exist so your options are to either build your own WAN using dark fibre or to deal with these problems at the remote site. If you are able to have a clock at the remote site, you could use the local GNSS-locked clock with the WAN as a backup feed to help when GNSS reception isn’t available. But when that’s not possible due to cost, space or inability to rack an antenna, something more clever is needed.

Lucky Packet Filter
Source: Meinberg

The ‘lucky packet filter’ is a way of cleaning up the timing packets. Typically, PTP timing packets will arrive between 8 and 16 times a second, each one stamped with the time it was sent. When received, its propagation time can be easily calculated and put in a buffer. The filter can look at the statistics then throw away any packets which took a long time to arrive. Effectively this helps select for those packets which had the least interference through the network. Packets which got held a long time are not useful for calculating the typical propagation time of packets so it makes sense to discard them. In a three-day-long test, Meinberg used a higher transmit rate of 64 packets per second saw the filter reduced jitter from 100 microseconds to an offset variation of 5 microseconds. When this was fed into a high-quality clock filter, the final jitter was only 300ns which was well within the 500ns requirement of ST 2059-2 used for SMPTE ST 2110.

Daniel concludes the video by showing the results of a test with WDR where a PTP Slave gateway device was fed with 16 packets a second from a master PTP switch over the WAN. The lucky packet filter produced a timing signal within 500ns and after going through an asymmetry step detection process in the clock produced a signal with an accuracy of no more than 100ns.

Watch now!
Speaker

Daniel Boldt Daniel Boldt
Meinberg

Video: AES67 Beyond the LAN

Posted on by Russell Trafford-Jones

It can be tempting to treat a good quality WAN connection like a LAN. But even if it has a low ping time and doesn’t drop packets, when it comes to professional audio like AES67, you can help but unconver the differences. AES67 was designed for tranmission over short distances meaning extremely low latency and low jitter. However, there are ways to deal with this.

Nicolas Sturmel from Merging Technologies is working as part of the AES SC-02-12M working group which has been defining the best ways of working to enable easy use of AES67 on the WAN wince the summer. The aims of the group are to define what you should expect to work with AES67, how you can improve your network connection and give guidance to manufacturers on further features needed.

WANs come in a number of flavours, a fully controlled WAN like many larger broadacsters have which is fully controlled by them. Other WANs are operated on SLA by third parties which can provide less control but may present a reduced operating cost. The lowest cost is the internet.

He starts by outlining the fact that AES67 was written to expect short links on a private network that you can completely control which causes problems when using the WAN/internet with long-distance links on which your bandwidth or choice of protocols can be limited. If you’re contributing into the cloud, then you have an extra layer of complication on top of the WAN. Virtualised computers can offer another place where jitter and uncertain timing can enter.

Link

The good news is that you may not need to use AES67 over the WAN. If you need precise timing (for lip-sync for example) with PCM quality and low latencies from 250ms down to as a little as 5 milliseconds do you really need AES67 instead of using other protocols such as ACIP, he explains. The problem being that any ping on the internet, even to something fairly close, can easily have a varying round trip time of, say, 16 to 40ms. This means you’re guaranteed 8ms of delay, but any one packet could be as late as 20ms. This variation in timing is known as the Packet Delay Variation (PDV).

Not only do we need to find a way to transmit AES67, but also PTP. The Precise Time Protocol has ways of coping for jitter and delay, but these don’t work well on WAN links whether the delay in one direction may be different to the delay for a packet in the other direction. PTP also isn’t built to deal with the higher delay and jitter involved. PTP over WAN can be done and is a way to deliver a service but using a GPS receiver at each location is a much better solution only hampered by cost and one’s ability to see enough of the sky.

The internet can lose packets. Given a few hours, the internet will nearly always lose packets. To get around this problem, Nicolas looks at using FEC whereby you are constantly sending redundant data. FEC can send up to around 25% extra data so that if any is lost, the extra information sent can be leveraged to determine the lost values and reconstruct the stream. Whilst this is a solid approach, computing the FEC adds delay and the extra data being constantly sent adds a fixed uplift on your bandwidth need. For circuits that have very few issues, this can seem wasteful but having a fixed percentage can also be advantageous for circuits where a predictable bitrate is much more important. Nicolas also highlights that RIST, SRT or ST 2022-7 are other methods that can also work well. He talks about these longer in his talk with Andreas Hildrebrand

Nocals finishes by summarising that your solution will need to be sent over unicast IP, possibly in a tunnel, each end locked to a GNSS, high buffers to cope with jitter and, perhaps most importantly, the output of a workflow analysis to find out which tools you need to deploy to meet your actual needs.

Watch now!
Speaker

Nicolas Sturmel Nicolas Sturmel
Network Specialist,
Merging Technologies