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)
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)
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)
SMPTE Timecode, created in the 1970s, has been a tremendous success – so is there reason to reinvent it? SMPTE says yes, and SMPTE Fellow Peter Symes explains why.
SMPTE Timecode is in constant use globally in the broadcast industry, but also in many other industries. The standard SMPTE ST12 is still much he same as the first version of the standard, but it has been updated over the years to deal with new frame rates and to adapt to new technology. However there are limits to what it can achieve without being re-defined and some of the original technologies and restrictions that originally guided the way it was created are outdated and superseded.
Peter Symes explains the TLX project which is in progress to create a successor to ‘SMPTE Timecode’. The new requirements pushing the TLX project forward are moving away from ST 12’s audio-based format, supporting any frame rate, having no 24-hour duration limit and work with the legacy timecode.
TLX stands for Time Label Extensible and is delivering on its promise of an extensible standard – as so many are nowadays – and already has ways of working with ST 2059 (PTP synchronisation) and ST 2110 (for uncompressed video over IP).