ST 2110 Commissioning CLI Reference: Arista EOS, Cisco NX-OS, and NVIDIA Spectrum Summary This is not a CLI manual to read end to end. The goal is more practical: A second-screen reference for ST 2110 commissioning, answering “which command should I check on this platform?” quickly. Scope: Arista EOS Cisco Nexus / NX-OS NVIDIA Spectrum / Cumulus Linux Mellanox / NVIDIA Onyx Focus areas: PTP / ST 2059 readiness IGMP snooping and multicast membership PIM-SSM and multicast routing QoS / DSCP / queue behavior Interface counters, drops, and buffer checks A/B fabric validation Important note: These commands are not production configuration templates.

STP, RSTP, MSTP, and ST 2022-7 in ST 2110 Networks: Which One Do We Use Where? Summary This article is written for network engineers, broadcast technicians, and system designers moving from SDI infrastructure to ST 2110/IP-based broadcast architectures. The goal is to remove the confusion that appears when STP/RSTP/MSTP, multicast, and ST 2022-7 are mentioned in the same design conversation. One of the most common ST 2110 design questions is this:

What Did PTP Kill in Broadcast? Summary The short answer is a bit sharp: PTP killed the era of separate physical synchronization infrastructure in broadcast. Black burst, tri-level sync, LTC, VITC, word clock, and SDI ANC timecode are still historically important. Some of them still live in certain facilities, and some are still required for gateways and legacy devices. But they are no longer the main timing model of an ST 2110 system.

PTP and SMPTE ST 2059 in ST 2110 Systems: There Is No IP Broadcast Without Time Synchronization Summary PTP is the clock of an ST 2110 system: it keeps video, audio, and ANC flows locked to the same time reference SMPTE ST 2059 defines how IEEE 1588 PTP is used in professional broadcast environments ST 2110-10 connects the system timing model to PTP time ST 2110-21 describes the timing behavior of video RTP packets as they leave the sender TAI/UTC/leap seconds and ST 2059-1 explain how PTP time maps into video frames, audio samples, and RTP timestamps Grandmaster selection, BMCA, boundary clocks, and transparent clocks are critical production design decisions When PTP is wrong, video may appear to exist, but audio drift, lip-sync issues, buffer problems, jitter, and receiver lock failures can follow Note: This article complements the timing layer of the ST 2110 campus, ST 2110 routing, ST 2110 monitoring, NMOS, and Intel MTL articles.

Intel Media Transport Library (MTL) for ST 2110: Software-Based Media Transport with FFmpeg and OBS Summary Intel Media Transport Library (MTL): a software data-plane library for ST 2110-compliant media transport on COTS servers Core problem: uncompressed streams such as ST 2110-20 have strict packet pacing, PTP timing, jitter, throughput, and packet loss requirements MTL approach: user-space packet processing and low-latency RTP/UDP media transport using DPDK PMD, AF_XDP, or kernel socket backends FFmpeg integration: the MTL plugin adds an mtl_st20p input/output device to FFmpeg, allowing direct ST 2110-20 raw video receive/transmit OBS integration: the MTL ecosystem includes OBS Studio plugin support, allowing OBS-based production/test workflows to connect to ST 2110 environments Positioning: MTL is not an NMOS control plane; it is the ST 2110 media packet TX/RX data-plane layer Note: This article complements the data-plane side of ST 2110 campus, NMOS, MXL, and FFmpeg/GStreamer.

What Is MXL? From SDI and ST 2110 to Software-Based Broadcast Summary SDI: the deterministic physical signal world for carrying baseband video/audio between devices ST 2110: a standards suite for carrying separate video, audio, and ancillary essence flows over an IP fabric MXL: a high-performance media exchange layer between software media functions inside the EBU Dynamic Media Facility (DMF) Core idea: MXL does not replace ST 2110; it aims to share media more directly inside compute clusters after ST 2110 has brought media to the facility or edge Why it matters: entering and leaving stream formats such as ST 2110 or NDI at every processing step creates packetization, serialization, buffering, and sync overhead Practical model: ST 2110 for ingest/output, MXL for exchange between graphics, AI, mixer, encoder, and other software functions Note: This article follows naturally from ST 2110 television campus, NMOS control plane, ST 2110 monitoring, and the FFmpeg/GStreamer decision guide.

FFmpeg and GStreamer: Where to Use Which, and When to Run Both Summary FFmpeg: ffmpeg / ffprobe CLI and libav* libraries — format conversion, transcoding, filtering, rapid prototyping GStreamer: Element–pad–pipeline architecture — 24/7 live streams, low latency, hardware acceleration, in-app integration Relationship: Often alternatives for the same job; frequently complements in one facility (direct hybrid via gst-libav) Goal: Not to rank FFmpeg against GStreamer, but to show which one fits which problem, and when using both is the better architecture Broadcast: While ST 2110 core paths use vendor SDKs, FFmpeg/GStreamer are common in gateways, OTT bridges, monitoring, and transcoders Decision: Files/offline and CLI → FFmpeg; continuous live pipelines and embedded services → GStreamer Operations model: FFmpeg favors process-oriented workflows (CLI, worker fleet, supervisor restarts); GStreamer favors in-process pipeline orchestration (state machine, bus, dynamic pads) Note: This article expands the short FFmpeg vs GStreamer section in Real-time video edge processing with Go.

A High-Level Overview of a Television Campus with ST 2110 Summary Campus architecture: Single-fabric design with PTP, media, and control planes Sources & destinations: Cameras, encoders, playout as sources; monitors, decoders, recorders as destinations Media flows: ST 2110-20 (video), ST 2110-30 (audio), ST 2110-40 (ANC/data), all over RTP multicast PTP: IEEE 1588-2008 PTPv2 with grandmaster, boundary clocks, and sync to every device Switch orchestration: NMOS IS-06 / SDN for flow provisioning; IGMP, PIM, QoS on switches Switch design: VLANs, DSCP mapping, PTP-aware ports, and full configuration examples Note: This article describes a full end-to-end ST 2110 television campus: timing (PTP), sources/destinations, switch orchestration, and concrete switch structures and configurations.

Monitoring SMPTE ST 2110 Systems: A Deep Dive with Prometheus, Grafana, and Beyond Summary Why Monitor ST 2110: Real-time requirements, packet loss detection, timing accuracy, and business continuity Critical Metrics: RTP stream health, PTP synchronization, network bandwidth, buffer levels, and SMPTE 2022-7 protection switching NMOS Control Plane: Monitoring IS-04 registry, IS-05 connections, node health, and resource integrity Prometheus Architecture: Time-series database, exporters, PromQL queries, and alerting framework Custom Exporters in Go: Building ST 2110-specific exporters for RTP analysis, PTP status, and gNMI network telemetry gNMI for Modern Switches: Streaming telemetry with sub-second updates replacing legacy SNMP polling Grafana Dashboards: Real-time visualization, alert panels, and production-ready dashboard templates Scale Strategies: Federation, Thanos, cardinality management for 1000+ streams Alternative Solutions: ELK Stack, InfluxDB, Zabbix, and commercial tools (Tektronix Sentry, Grass Valley iControl) Production Best Practices: High availability, security hardening, CI/CD automation, and compliance requirements Note: This article provides production-ready monitoring strategies for both data plane (ST 2110) and control plane (NMOS) in broadcast systems.

AMWA NMOS: Building the Control Plane for SMPTE ST 2110 with Go Summary NMOS Overview: Open specifications for networked media control and management IS-04: Discovery and Registration of devices and resources IS-05: Device Connection Management for automated routing IS-06: SDN control for switches and network infrastructure IS-08: Channel Mapping for audio routing within devices IS-09: System Parameters for global network timing Go Implementation: Production-ready NMOS client and registry server Real-world Use Cases: Automated workflows, resource discovery, connection management, SDN integration Note: This article provides comprehensive coverage of AMWA NMOS specifications with practical Go implementations.