AES67 is a flexible standard but with this there is complexity and nuance. Implementing it within ST 2110-30 takes some care and this talk covers lessons learnt in doing exactly that.
AES67 is a standard defined by the Audio Engineering Society to enable high-performance audio-over-IP streaming interoperability between various AoIP systems like Dante, WheatNet-IP and Livewire. It provides comprehensive interoperability recommendations in the areas of synchronization, media clock identification, network transport, encoding and streaming, session description, and connection management.
The SMPTE ST 2110 standards suite makes it possible to separately route and break away the essence streams – audio, video, and ancillary data. ST 2110-30 addresses system requirements and payload formats for uncompressed audio streams and refers to the subset of AES67 standard.
In this video Dominic Giambo from Wheatsone Corporation discusses tips for implementing AES67 and ST 2110-30 standards in a lab environment consisting of over 160 devices (consoles, sufraces, hardware and software I/O blades) and 3 different automation systems. The aim of the test was to pass audio through every single device creating a very long chain to detect any defects.
The following topics are covered:
SMPTE ST 2110-30 as a subset of AES67 (support of the PTP profile defined in SMPTE ST 2059-2, an offset value of zero between the media clock and the RTP stream clock, option to force a device to operate in PTP slave-only mode)
The importance of using IEEE-1588 PTP v2 master clock for accuracy
Packet structure (UDP and RTP header, payload type)
Network configuration considerations (mapping out IP and multicast addresses for different vendors, keeping all devices on the same subnet)
Discovery and control (SDP stream description files, configuration of signal flow from sources to destinations)
IT still has catching up to do. The promise of video over IP and ST 2110 is to benefit from the IT industry’s scale and products, but when it comes to bandwidth, there are times when it isn’t there. This talk looks at 25 gigabit (25GbE) network interfaces to see how well they work and if they’ve arrived on the broadcast market.
Koji Oyama from M3L Inc. explains why the move from 10GbE to 25GbE makes sense; a move which allows more scalability with fewer cables. He then looks at the physical characteristics of the signals, both as 25GbE but also linked together into a 100GbE path.
We see that the connectors and adapters are highly similar and then look at a cost analysis. What’s actually available on the market now and what is the price difference? Koji also shows us that FPGAs are available with enough capacity to manage several ports per chip.
So if the cost seems to be achievable, perhaps the decision should come down to reliability. Fortunately, Koji has examined the bit error rates and shows the data which indicates that Reed Solomon protection is needed, called RS-FEC. Reed Solomon is a simple protection scheme which has been used in CDs, satellite transmissions and many other places where a light-weight algorithm for error recovery is needed. Koji goes into some detail here explaining RS-FEC for 25GbE.
Koji has also looked into timing both in synchronisation but also jitter and wander. He presents the results of monitoring these parameters in 10GbE and 25GbE scenarios.
Finishing up by highlighting the physical advantages of moving to 25GbE such as density and streams-per-port, Koji takes a moment to highlight many of the 25GbE products available at NAB as final proof that the 25GbE is increasingly available for use today.
The transition from point-to-point SDI based infrastructure to IP essence flows requires a very different approach to fault-finding. Although new IP diagnostic tools are already available on the market, engineers need combined broadcast and IT knowledge to fully understand the flow of video, audio and data across the switching fabric – including packet jitter, latency, and buffer over/underflows causing dropped packets.
In this video Michael Waidson from Tektronix presents methodologies involved in monitoring IP media networks. The following topics are covered:
Strategies for choosing IP Address, Port Number and Payload Type for easier identification of the streams
Troubleshooting basics (fibres and SFPs types, checking switch ports)
Here to kill the idea of SDNs – Spreadsheet Defined Networks – is TR-1001 which defines ways to implement IP-based media facilities avoiding some typical mistakes and easing the support burden.
From the JT-NM (Joint Taskforce – Networked Media), TR-1001 promises to be a very useful document for companies implementing ST-2110 or any video-over-IP network Explaining what’s in it is EEG’s Bill McLaughlin at the VSF’s IP Showcase at NAB.
This isn’t the first time we’ve written about TR-1001 at The Broadcast Knowledge. Previously, Imagine’s John Mailhot has dived in deep as part of a SMPTE standards webcast. Here, Bill takes a lighter approach to get over the main aims of the document and adds details about recent testing which happened across several vendors.
Bill looks at the typical issues that people find when initially implementing a system with ST-2110 devices and summarises the ways in which TR-1001 mitigates these problems. The aim here is to enable, at least in theory, many nodes to be configured in an automatic and self-documenting way.
Bill explains that TR-1001 covers timing, discovery and connection of devices plus some of configuration and monitoring. As we would expect, ST-2110 itself defines the media transport and also some of the timing. Work is still to be done to help TR-1001 address security aspects.
VP Product Development,