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 Executive Director, Video Services Forum Executive Director, Advanced Media Workflow Association (AMWA) |
 |
John Mailhot CTO Networking & Infrastructure |
 |
Jed Deame CEO, Nextera Video |
 |
Richard Hastie Senior Sales Director, NVIDIA |
 |
Jeremy Nightingale President Macnica Americas, Inc. |
Whenever there’s a step change in technology, we need early adopters and moving to SMPTE’s ST 2110 is no exception. Not only do early adopters help show that the path ahead is good, but they often do a lot to beat down the bushes and make the path easier to pass for all that follow. For larger companies whose tech refresh or building move comes at a time when the industry is facing a major technology change, there comes a time when whilst the ground may not be firm ahead, the company can’t justify investing in technology that would soon be out of date or in technology which won’t support the needs of the company in several years’ time. This is just the situation that BBC Cymru Wales found themselves in when it was time to move out of their old property into a purpose-built national HQ in the heart of Cardiff.
In this video from the IP Showcase, Mark Patrick and Dan Ashcroft guide us through ‘whys’ and the ‘hows’ of the relocation project. It’s important to remember that this project was long in the making with the decision on location taking place in 2014 with the technology decisions taking place in 2016 and 2017. The project took an open approach to the IP/SDI question and asked for RFP responses to include a fully-SDI and a fully-IP option. It was clear during the selection process that IP was the way to go not because the solution was cheaper in the short term, but because it was much more future-proof and the costs would come down over time giving a much better total cost of ownership. Don’t forget that the initial costs of HD video equipment were much higher than those now. For more on the pros and cons of SDI, watch ‘Is IP really better than SDI?‘ by Ed Calverly.
Mark and Dan talk through the thinking for the IP choice and their decision to pick a vendor who would be their partner in the project. The theory being that given the standards were still very young, it would be important to work closely to ensure success. In addition to Grass Valley equipment, they chose a Cisco network with Cisco SDN control and operational control by BNCS. The talk references architectures we’ve featured on The Broadcast Knowledge before with Arista’s Gerard Phillips discussing the dual-network spine-leaf architecture chosen and noting the difficulty they had incorporating the Dante network into the 2110 infrastructure and their choice of a third network purely for control traffic.
We often hear about the importance of PTP in a SMPTE ST 2110 network for live production because it is vital to keep all the essences in sync. For more information about the basics of ST 2110 check out this talk by Wes Simpson. PTP is both simple and complex so Mark explains how they’ve approached distributing PTP ensuring that the separate networks, amber and blue, can share PTP grandmasters for resilience.
Other topics covered in the talk include
Watch now!
Speakers
 |
Mark Patrick Lead Architect, BBC |
 |
Dan Ashcroft Senior Project Manager, BBC |
 |
Moderator: Wes Simpson LearnIPVideo.com |
Who better to dig below the surface of WebRTC, which delivers sub-second latency, than Sean DuBois, creator of the Pion WebRTC library? This video takes a different look at WebRTC to others that focus on latency or scaling. Rather Sean looks at congestion control and managing the impacts of congestion noting that people remember how bad the video got and not how nice your sign-up page was.
Congestion is inevitable in large ‘unmanaged’ networks such as the internet and on wifi and cellular networks. Sean points out that the use of MPEG codecs which add dependencies between frames magnify the effect of lost packets. With frame-by-frame codecs, dropping a frame and repeating the last one is barely noticeable, but with MPEG, many more could be damaged. WebRTC was implemented over UDP so it could use its own congestion control.
RTP and RTCP are the key to WebRTC’s congestion control. RTP is well known for carrying real-time media as it’s used for AES67 audio, SMPTE ST 2110 and ST 2022-6 to name just a few standards. RTCP is RTP’s sidekick. Whilst RTP does the legwork of carrying the media, the RTP Control Protocol (RTCP) passes messages to control the flow. In this case, Sean explains, the RTCP channel is used to tell the sender that it’s sending too much video or which packets it’s lost. In terms of mitigating congestion, the source can adjust the bitrate directly or change the resolution or the framerate of the video to bring the bitrate down indirectly.
Sean shows a summary diagram of congestion controller flow which is built to handle jitter and out of order packets. Buffers are the normal way of fixing out-of-order packets but they have a big downside of adding latency and exacerbating timing problems. WebRTC has to use the RTCP channel to make sure it can map packet timing with NTP, using Sender Reports, as each packet’s timing information is only relative. When packet loss is spotted NACK (negative acknowledgements) are sent via RTCP or if things are worse, a Picture Loss Indication is sent which request a new keyframe. Fixing any impairments that do occur can be done either with FEC or by concealing the error with some form of masking, nowadays this may be based on machine learning.
The talk finishes with a look at a number of innovative projects which use WebRTC in one way or another, including for file transfer.
Watch now!
Speakers
 |
Sean DuBois Creator, Pion WebRTC Developer, Apple |
| Views and opinions expressed on this website are those of the author(s) and do not necessarily reflect those of SMPTE or SMPTE Members. This website is presented for informational purposes only. Any reference to specific companies, products or services does not represent promotion, recommendation, or endorsement by SMPTE |  |
