Uncompressed audio has been in the IP game a lot longer than uncompressed video. Because of its long history, it’s had chance to create a fair number of formats ahead of the current standard AES67. Since many people were trying to achieve the same thing, we find that some formats are compatible with AES67 – in part, whilst we that others are not compatible.
To navigate this difficult world of compatibility, Axon CTO Peter Schut continues the Broadcast 101 webinar series with this video recorded this month.
Peter starts by explaining the different audio formats available today including Dante, RAVENNA and others and outlines the ways in which they do and don’t interoperate. After spending a couple of minutes summarising each format individually, including the two SMPTE audio formats -30 and -31, he shows a helpful table comparing the,
Timing is next on the list discussing PTP and the way that SMPTE ST 2059 is used then packet time is covered explaining how the RTP payload fits into the equation. This payload directly affects the duration of audio you can fit into a packet. The duration is important in terms of keeping a low latency and is restricted to either 1ms or 125 microseconds by SMPTE ST 2110-30.
Peter finishes up this webinar talking about some further details about the interoperability problems between the formats.
PTP, Precision Time Protocol, underpins the recent uncompressed video and audio over IP standards. It takes over the role of facility-wide synchronisation from black and burst signals. So it’s no surprise that The Broadcast Bridge invited Meinberg to speak at their ‘Real World IP’ event exploring all aspects of video over IP.
David Boldt, head of software engineering at Meinberg, explains how you can accurately transmit time over a network. He summarises the way that PTP accounts for the time taken for messages to move from A to B. David covers different types of clock explaining the often-heard terms ‘boundary clock’ and ‘transparent clock’ exploring their pros and cons.
Unlike black and burst which is a distributed signal, PTP is a system with bi-directional communication which makes redundancy all the more critical and, in some ways, complicated. David talks about different ways to attack the main/reserve problem.
PTP is a cross-industry standard which needs to be interpreted by devices to map the PTP time into an understanding of how the signal should look in order for everything to be in time. SMPTE 2059 does this task which David cover.
PTP-over-WAN: David looks at a case study of delivering PTP over a WAN. Commonly assumed not practical by many, David shows how this ways done without using a GPS antenna at the destination. To finish off the talk, there’s a teaser of the new features coming up in the backwards-compatible PTP Version 2.1 before a Q&A.
It’s being closely watched throughout the industry, a long-in-the-making project to deploy SMPTE ST 2110 throughout a fully green-field development. Its failure would be a big setback for the push to a completely network-based broadcast workflow.
The BBC Cardiff Central Square project is nearing completion now and is a great example of the early-adopter approach to bringing cutting-edge, complex, large-scale projects to market. They chose a single principle vendor so that they could work closely in partnership at a time when the market for ST 2110 was very sparse. This gave them leverage over the product roadmap and allowed to the for the tight integration which would be required to bring this project to market.
Nowadays, the market for ST 2110 products continues to mature and whilst it has still quite a way to go, it has also come a long way in the past four years. Companies embarking similar projects now have a better choice of products and some may now feel they can start to pick ‘best of breed’ rather than taking the BBC approach. Whichever approach is taken there is still a lot to be gained by following and learning from the mistakes and successes of others. Fortunately, Mark Patrick, Lead Architect on the project is here to provide an update on the project.
Mark starts by giving and overview of the project, its scale and its aims. He presents the opportunities and challenges it presents and the key achievements and milestones passed to date.
Live IP has benefits and risks. Mark takes some time to explain the benefits of the flexibility and increasingly lower cost of the infrastructure and weighs them agains the the risks which include the continually developing standards and skills challenges
The progress overview names Grass Vally as the main vendor, control via BNCS having being designed and virtualised, ST 2110 network topology deployed and now the final commissioning and acceptance testing is in progress.
The media topology for the system uses an principal of an A and a B network plus a separate control network. It’s fundamentally a leaf and spine network and Mark shows how this links in to both the Grass Valley equipment but also the audio equipment via Dante and AES67. Mark takes some time to discuss the separate networks they’ve deployed for the audio part of the project, driven by compatibility issues but also within the constraints of this project, it was better to separate the networks rather than address the changes necessary to force them together.
PTP timing is discussed with a nod to the fact that PTP design can be difficult and that it can be expensive too. NMOS issues are also actively being worked on and remains an outstanding issue in terms of getting enough vendors to support it, but also having compatible systems once an implementation is deployed. This has driven the BBC to use NMOS in a more limited way than desired and creating fall-back systems.
From this we can deduce, if it wasn’t already understood, that interoperability testing is a vital aspect of the project, but Mark explains that formalised testing (i.e. IT-style automated) is really important in creating a uniform way of ensuring problems have been fully addressed and there are no regressions. ST 2110 systems are complex and fault finding can be similarly complex and time consuming.
Mark leaves us by explaining what keeps him awake at night which includes items such as lack of available test equipment, lack of single-stream UHD support and NMOS which leads him to a few comments on ST 2110 readiness such as the need for vendors to put much more effort into configuration and management tools.
Anyone with an interest in IP in broadcast will be very grateful at Mark’s, and the BBC’s, willingness to share the project’s successes and challenges in such a constructive way.
Black and burst was always a ‘set and forget’ system. PTP, which replaces it, deserves active monitoring – and the same is true of your uncompressed media streams as we hear in this talk from the IP Showcase.
In professional essence-over-IP systems such as based on SMPTE ST 2110, timing needs to be rock solid. Thanks to asynchronous nature of IP many different flows can be carried across a network without having to be concerned with synchronization, but this presents a challenge in the production environment. To provide the necessary “genlock”, there is a need for a precise timing standard which is provided by SMPTE ST 2059 which defines the way broadcast signals relate to the IEEE 1588-2008 Precision Time Protocol, commonly referred to as PTPv2. This protocol is very different from analogue Black Burst and Tri-Level signals used in SDI world, so new tools and skills are required for fault finding.
In the first part of this presentation Thomas Gunkel from Skyline Communications focuses on the best practices to configure, monitor and manage PTP in an all-IP infrastructure covering the following:
Automating PTP configuration (BMCA settings, messaging rate intervals, communication mode)
Automated PTP provisioning (detecting new PDP our devices using IS-04 or proprietary protocols, extracting end-to-end PTP topology with LLDP, applying standard PTP profiles)
PTP monitoring and control (monitor every single metric related to PTP like PTP offset, PTP mean path delay and multicast PTP network traffic for all grandmaster, master and slave devices, prevent slave devices from becoming master)
The second part of this video shows how to track uncompressed media flows in an ST 2110 IP-based media facility using a multi-layer approach and to how to pinpoint any potential issues using Network Monitoring System. Topics covered:
All IP flows vs SDI signals
Essentials for true orchestration (dynamically orchestrated resources and media services, monitoring / controlling infrastructure and media flows, automatic devices detection and provisioning)
Detecting issues (wrong DB entries for multicast essences, broadcast controller and SDN controller DBs out of sync, source not active, IGMP join / leave issues, SSM issues, network oversubscription)
Media flow tracking (reading cross point status from SDN controller, comparing this status with actual network topology, detecting “ghost” streams, using sFlow / NetFlow to track individual multicast flows)
Importance of true end-to-end SDN orchestration rather than SDN control (routing protocols which provides feedback)
All IP routing procedure (resolving multicast flow topology in combination with label management, checking source, checking destination route, presenting data for root cause analysis on each of these steps)