VSF

Video: JT-NM ProAV Technology Roadmap for IPMX – Panel Discussion

Posted on by Russell Trafford-Jones

Building on our coverage of IPMX to date, we see that this push to create a standard for IP for the ProAV market has been growing in momentum. With activity now in AIMS, AMWA, VSF and SMPTE, it’s important to bring together the thinking and have a central strategy which is why the JT-NM have released a roadmap. This has started by defining what is meant by ProAV: “The market for audiovisual (AV) communication equipment used in professional, industrial, commercial, and retail environments as a means to communicate with people.” As is noted by today’s panel, this is a wide definition and helps us understand why this is such a different proposition compared to the related ST 2110 and NMOS work for the broadcast market. There are lots of silos in the Pro AV space with many solutions being developed to cater to just one or two. This makes requirements capture difficult and has led to the fragmentation seen to date and partly why strong manufactures tend to be the ones pushing the market in a certain direction in contrast to the broadcast market where strong, early adopters set the direction for vendors.

 

 

The roadmap itself sets the aims of IPMX, of instance that is secure from the start, it will scale and integrate with 2110/AMWA broadcast installations and be able to be a software only solution. Phase 1 of the roadmap identifies existing standards and specifications which underpin the three IPMX tenents of security, Media, Control. Identified are NMOS IS-10 for access authentication and encryption, relevant 2110 standards, NMOS IS-04,-05, -07 and capabilities to use EDIDs. Phase 2 then adds HDCP support, support for ProAV audio formats, enhanced control such as for audio mapping (IS-08), legacy camera control via RS-232 etc. and then phase 3 will bring in media compression for WAN links, error correction techniques and closed captioning & subtitling. For control, it will add USB HID and a training and certification scheme will be launched.

The panel concludes discussing how IPMX is very much at home with live production which, of course, should help it dovetail well into the broadcast space. IPMX is seen by the panel to simplify the implementation of a 2110-like infrastructure which should allow easier and quicker installations than 2110 which are seen as larger, higher risk projects. IPMX could, it’s suggested, be used as an initial step into IP for broadcasters who seek to understand what they need to do organizationally and technically to adopt IP ahead of perhaps developing 2110 systems. But the technology is seen as going both ways allowing broadcasters to more readily adopt compressed workflows (whether JPEG XS or otherwise) and allow Pro AV players to bring uncompressed workflows more easily into their productions for those that would benefit.

Watch now!
Speakers

Karl Paulsen Karl Paulsen
CTO,
Diversified
Andrew Starks Andrew Starks
Director of Product Management,
Macnica America’s Inc.

David Chiappini David Chiappini
Chair, Pro AV Working Group, AIMS
Executive Vice President, Research & Development,
Matrox Graphics Inc.
Richard M. Friedel Richard Friedel
Executive Vice President, Technology & Broadcast Strategy,
21st Century Fox

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: 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

Video: Creating Interoperable Hybrid Workflows with RIST

Posted on by Russell Trafford-Jones

TV isn’t made in one place anymore. Throughout media and entertainment, workflows increasingly involve many third parties and being in the cloud. Content may be king, but getting it from place to place is foundational in our ability to do great work. RIST is a protocol that is able to move video very reliably and flexibly between buildings, into, out of and through the cloud. Leveraging its flexibility, there are many ways to use it. This video helps review where RIST is up to in its development and understand the many ways in which it can be used to solve your workflow problems.

Starting the RIST overview is Ciro Noronha, chair of the RIST Forum. Whilst we have delved in to the detail here before in talks like this from SMPTE and this talk also from Ciro, this is a good refresher on the main points that RIST is published in three parts, known as profiles. First was the Simple Profile which defined the basics, those being that it’s based on RTP and uses an ARQ technology to dynamically request any missing packets in a timely way which doesn’t trip the stream up if there are problems. The Main Profile was published second which includes encryption and authentication. Lastly is the Advanced Profile which will be released later this year.

 

 

Ciro outlines the importance of the Simple Profile. That it guarantees compatibility with RTP-only decoders, albeit without error correction. When you can use the error correction, you’ll benefit from correction even when 50% of the traffic is being lost unlike similar protocols such as SRT. Another useful feature for many is multi-link support allowing you to use RIST over bonded LTE modems as well as using SMPTE ST 2022-7

The Main Profile brings with it support for tunnelling meaning you can set up one connection between two locations and put multiple streams of data through. This is great for simplifying data connectivity because only one port needs to be opened in order to deliver many streams and it doesn’t matter in which direction you establish the tunnel. Once established, the tunnel is bi-directional. The tunnel provides the ability to carry general data such as control data or miscellaneous IT.

Encryption made its debut with the publishing of the Main Profile. RIST can use DTLS which is a version of the famous TLS security used in web sites that runs on UDP rather than TCP. The big advantage of using this is that it brings authentication as well as encryption. This ensures that the endpoint is allowed to receive your stream and is based on the strong encryption we are familiar with and which has been tested and hardened over the years. Certificate distribution can be difficult and disproportionate to the needs of the workflow, so RIST also allows encryption using pre-shared keys.

Handing over now to David Griggs and Tim Baldwin, we discuss the use cases which are enabled by RIST which is already found in encoders, decoders and gateways which are on the market. One use case which is on the rise is satellite replacement. There are many companies that have been using satellite for years and for whom the lack of operational agility hasn’t been a problem. In fact, they’ve also been able to make a business model work for occasional use even though, in a pure sense, satellite isn’t perfectly suited to occasional use satellites. However, with the ability to use C-band closing in many parts of the world, companies have been forced to look elsewhere for their links and RIST is one solution that works well.

David runs through a number of others including primary and secondary distribution, links aggregation, premium sports syndication with the handoff between the host broadcaster and the multiple rights-holding broadcasters being in the cloud and also a workflow for OTT where RIST is used for ingest.

RIST is available as an open source library called libRIST which can be downloaded from videolan and is documented in open specifications TR-06-1 and TR-06-2. LibRIST can be found in gstreamer, Upipe, VLC, Wireshark and FFmpeg.

The video finishes with questions about how RIST compares with SRT. RTMP, CMAF and WebRTC.

Watch now!
Speakers

Tim Baldwin Tim Baldwin
Head of Product,
Zixi
David Griggs David Griggs
Senior Product Manager, Distribution Platforms
Disney Streaming Services
Ciro Noronha Ciro Noronha
President, RIST Forum
Executive Vice President of Engineering, Cobalt Digital