As media facilities become increasingly software-defined, distributed, and IP-based, the future depends on manufacturers, broadcasters, systems integrators, and standards organizations working together to create solutions that are practical, interoperable, and ready for real-world deployment. That collaboration is exactly what you'll see at IBC on the EBU stand (10.D21). There, the EBU and AMWA will showcase how industry collaboration is delivering real results today while helping shape the next generation of media infrastructure. Whether you're looking for practical solutions you can deploy now, or want to understand where the industry is heading next, these demonstrations offer a unique opportunity to see both in one place. Multi-Vendor Interoperability with NMOS Monitoring Broadcast engineers and operators know that monitoring systems generate plenty of alarms. The challenge is knowing which ones are actually critical. The NMOS BCP-008 Minimum Status Reporting demonstrations will show how standardized status reporting across equipment from multiple manufacturers helps operators identify, understand, and troubleshoot issues more quickly by reporting issues only when they actually matter. The demos will bring together products from multiple vendors using NMOS BCP-008 to show consistent, meaningful status information across an interoperable system. Developed collaboratively by broadcasters, manufacturers, and systems integrators, BCP-008 helps accelerate the adoption of open monitoring and control while reducing operational complexity. Participating companies are: Arkona, DirectOut, EVS, Leader, Nevion, Pebble, Providius, Riedel, SRF, Simplexity, and Sony. JT-DMF: Making the Vision a Reality While BCP-008 demonstrates what's possible today, the Joint Task Force on the Dynamic Media Facility (JT-DMF) area of the stand will explore what's coming next. JT-DMF is a joint initiative between AMWA and the EBU that brings together broadcasters, manufacturers, systems integrators, and technology partners to define how media facilities can become more flexible, scalable, and software-defined through open collaboration across the industry. At IBC, you'll have the opportunity to find out more through dedicated "Ask Me Anything" sessions with members of the JT-DMF community. You’ll be able to explore how the vision is continuing to evolve through collaborative industry effort. Whether you're just beginning to explore what DMF can mean for you, or you're already participating in the work, this is a great opportunity to get your questions answered, find out about the latest developments, and discover how you can get involved. See Collaboration in Action When the industry comes together around open specifications and shared architectures, everyone benefits. Broadcasters gain greater flexibility and interoperability. Manufacturers can innovate on a common foundation. Systems integrators can build more predictable, interoperable solutions. And the entire industry moves forward together. If you're heading to IBC, be sure to visit AMWA on the EBU stand (10.D21). Come see how open collaboration is delivering real-world results today through NMOS BCP-008, explore the latest JT-DMF developments, ask questions, meet the people behind the work, and discover how these initiatives can help shape the future of your media infrastructure.

Modern broadcast facilities are increasingly distributed, software-defined, and multi-vendor. As systems become more complex, diagnosing problems quickly becomes just as important as preventing them. NMOS BCP-008 Minimum Status Reporting gives manufacturers a common way to communicate device health and status while giving users the consistent information they need to identify problems faster, reducing troubleshooting time, and improving operational resilience. It provides meaningful, standardized status information directly from end devices, making it easier to diagnose and resolve issues before they impact operations. Even experienced engineers benefit because they can pinpoint problems more quickly, while operators get clear, actionable status information with no setup required. BCP-008 is designed to grow. Manufacturers can report additional device-specific conditions using the same standardized framework, giving users even greater visibility into the health of their systems. The following real-world examples illustrate the kinds of IP operational challenges broadcasters face every day and how vendor-agnostic standardized status reporting can dramatically reduce the time it takes to identify and resolve them. These examples are based on the NAB presentation by Stefan Ledergerber from Simplexity about NMOS BCP-008 Minimum Status Reporting. Watch the full presentation here. 1. When Your Backup Network Isn't Really a Backup A journalist was editing audio using redundant network A and network B connections. Everything appeared normal until network A went down. Only then did he discover that an IT update had silently disabled one of the network interfaces in its operating system. The control and monitoring system still showed everything as connected, so no one knew there was a problem until the backup path was actually needed. With NMOS BCP-008 Minimum Status Reporting, the device could have immediately reported conditions such as packet loss on the backup network, allowing the issue to be corrected before it disrupted operations. 2. Connected... But No Audio An audio engineer connected several audio streams to a console. Everything showed as connected, and the network monitoring system confirmed traffic was flowing. Yet one receiver had no audio. The cause was a latency configuration mismatch. Packets were arriving, but they were too late because the receiver had been configured for a very low-latency local connection while the sender was actually located at another site. BCP-008 could have reported late packets in a standardized way, allowing engineers to identify the problem almost immediately. 3. The Problem Already Went Away A system was reported to be having problems. An operator checked, and everything was working normally. (Service had already been restored). But a status indicator showed the operator that a network link had gone down twice earlier in the day. Even though the fault had cleared, that historical information provided valuable context for troubleshooting and suggested someone had disconnected a cable or that another intermittent event had occurred. Instead of guessing what happened, BCP-008 preserves useful operational information until it can be reviewed. 4. A Small Problem That Kept Coming Back Another operator noticed a status indicator showing that a network link had gone up and down repeatedly. The system was still operating, but the repeated events suggested something very different from a one-time interruption. A failing connector, aging SFP, or another hardware issue could now be investigated before it resulted in an outage. Standardized status reporting helps engineers identify recurring problems while they're still small – without a full-blown monitoring system. 5. The Once-a-Month Mystery A broadcaster experienced occasional audio and video glitches that occurred only about once a month. The cause turned out to be subtle. One playout system was configured according to the 2015 version of SMPTE ST 2059-2, while the rest of the facility used the 2021 version. Because the two versions use different default PTP announce intervals and timeout values, the playout system would occasionally assume the PTP master had disappeared and briefly attempt to become the master itself. Without standardized reporting, the issue took significant effort to diagnose. With BCP-008, the behavior would have been visible immediately. 6. Understanding PTP Changes An engineer noticed a small status counter indicating that something had happened four times. A quick mouse hover with NMOS Control revealed the answer: the device had previously switched to a different PTP grandmaster. No vendor-specific software. No custom configuration. Just standardized status information that immediately explained what had changed and helped the engineer understand the system's behavior. 7. The Spare System That Took Down Everything One television station suddenly lost all of its playout channels overnight. The main and backup playout systems appeared healthy. The real culprit was a spare playout system that wasn't even on air. After being rebooted, it began transmitting malformed packets that overwhelmed a downstream changeover device, affecting every channel of the station. Even a team of experts needed several hours to identify the root cause. It led to an early morning panic at the station. With standardized status reporting from the affected devices, engineers could have quickly narrowed their search to the correct part of the system instead of chasing symptoms. Better Visibility, Less Configuration One of the strengths of NMOS BCP-008 is that it works independently of large monitoring systems while complementing them. Devices can provide meaningful, standardized status information with no manual setup. Engineers spend less time configuring monitoring systems and more time solving problems. The framework is extensible. Manufacturers can report additional device-specific conditions using the same standardized mechanism, providing even greater visibility into system health. If you're developing broadcast products, now is the time to add support for BCP-008 to your devices. Explore the developer resources for NMOS Minimum Status Reporting. And if you’re heading to IBC, be sure to visit AMWA on the EBU stand (10.D21) to check out a live demo of BCP-008.

Monday, August 31 16:00 CEST / 15:00 BST / 10:00 AM ET / 7:00 AM PT How do you get from today's broadcast infrastructure to tomorrow's Dynamic Media Facility? As broadcast infrastructure continues to evolve – from analog to SDI to ST 2110 and now toward Dynamic Media Facilities – what changes, what stays the same, and what will define the next generation of media infrastructure? Join Willem Vermost from the European Broadcasting Union (EBU) and Pedro Ferreira from Bisect as they explore the technologies, design principles, and practical first steps that can help engineers begin experimenting with DMF without starting from scratch. On this 40-minute live event, you’ll find out about: The core technologies and architectural principles behind DMF, including compute, virtualization, timing, networking, and MXL Real-world ways to begin experimenting with evaluating, testing, and adopting DMF in broadcast environments What will carry over from analog, SDI, and ST 2110, and what’s completely new How DMF can integrate within your existing facility

If I were still working as a station engineer in Albuquerque, NM, and I heard people talking about Dynamic Media Facilities, I’d probably think: “Okay, what problem is this actually solving for me?” Because from where I’d be standing, the facility might look fine at first glance. It’s doing what it was designed to do. I’ve built a workflow that supports the evening news, some local programming, and maybe production of a few commercial spots every now and then. But when you really look at it, you start to notice the limitations. A lot of that expensive equipment is sitting idle most of the day. It’s there for the morning and evening newscast, but not much else. Or maybe there is a color corrector that only gets used every once in a while for commercial production. And if you want to use the space for other purposes – let’s say to launch a high-end podcast, produce digital content, or reconfigure the space for a different kind of production – it may not make sense to go through the trouble of reconfiguration just to support a few extra production hours. Even though the facility has a lot of capability, it’s not optimized for what you need, or it is sitting idle. This is really the key point. Even as more processing moves into software and servers, many of us are still thinking about it the old way, like we’re just replacing one box with another. But what broadcasters need now is something more flexible. You want to be able to chain together resources for different types of productions at different times, and you don’t want to pay for capabilities you don’t need. That’s the pressure a lot of facilities are under right now. And that’s where Dynamic Media Facilities (DMF) comes in. Broadcast engineers are starting to ask: are our facilities actually working as efficiently as they could be? What does a Dynamic Media Facility look like? Instead of fixed, hardware-defined workflows, DMF introduces a fundamentally different model. As shown in the figure below, workflows are built from modular, autonomous functions. They perform one and only one function. These atomic functions can be chained together to create different workflows. Because resources are shared, not dedicated, facilities can be reconfigured on demand. That means the same space can produce a commercial in the morning, switch to a podcast in the afternoon, and run the evening news at night, drawing the appropriate resources from a pool, and then orchestrating the workflow you need, when you need it. No more expensive equipment sitting idle most of the day. You only use what you actually need. Instead of investing in dedicated CAPEX hardware, DMF uses resources mostly on a SaaS basis: Available on demand Invisible when not in use Scalable up or down Scheduled as needed The missing pieces: interoperability and orchestration Once you move into a world of software-based processing, shared compute, IP-connected devices, and dynamic workflows, the challenge isn’t just having the resources. It’s knowing what’s available, where it is, what it does, whether it’s in use or can be scheduled, and how it connects to the rest of the signal chain. If you’re going to build a facility that can shift dynamically from one workflow to another, you need a way to automatically discover, identify, and connect the right resources every time. Interoperability and orchestration become essential. You can’t rely on custom integrations and one-off vendor silos when dealing with a large number of endpoints and fluid workflows. You need a common way to discover resources, call up the right function, connect workflow components dynamically, and do it all in a way that works across systems and vendors. You need to be sure you don’t spin up functions that consume more compute resources than you have available, and you also need a way to keep things synchronized across the workflows you create. These are exactly the problems the JT-DMF is tackling. A word about MXL and DMF While MXL has attracted significant attention in recent months, it represents just one piece within a much broader industry effort: DMF. The real story is the growing collaboration around Dynamic Media Facility, where broadcasters, vendors, and systems integrators are working together to define the interoperable frameworks that will underpin the next generation of media infrastructure. MXL is a critical building block, but DMF is the bigger picture that’s being developed. Joint Task Force on Dynamic Media Facilities (JT-DMF) A joint project between the Advanced Media Workflow Association (AMWA) and the European Broadcasting Union (EBU), JT-DMF brings together broadcasters, vendors, and systems integrators to work toward a shared goal: Make dynamic media facilities real and interoperable. The JT-DMF aims to answer questions like: how do you share production resources on a common compute instance, or across instances? How do you connect a flow coming out of one software application to the input of the next function in the chain? How do you preserve timing in these software-only, faster-than-realtime environments? What does orchestration look like? What are the core pieces? Is there a common approach across the industry that makes sense? To make DMF possible, major industry players including broadcasters and vendors are coming together via the JT-DMF to actively shape the conversation in 4 critical areas: 1. End-to-End Synchronization Working Group Creating a unified model for timing and synchronization across dynamic, distributed facilities. 2. Flow Connection Working Group Establishing how media flows are discovered, described, negotiated, and connected within a dynamic environment. 3. Compute Resources Management Working Group Defining how compute, storage, networking, and specialized media functions can be provisioned, orchestrated, scaled, and released. 4. Business Track Identifying the business drivers, commercial models, and organizational changes required to adopt dynamic media architectures. Where JT-DMF stands right now (and why it matters) Initially, there was a meeting held at the CBC to bring together interested parties and determine what shape developments might take. Technical groups known as “tiger teams” met several times and were looking to find key technical points. The Joint Task Force was formed in the fall of 2025 in Geneva with a kick off meeting. JT-DMF Working Groups started to organize in the beginning of 2026. The first version of MXL, the media exchange layer, was released at the Video Services Forum (VSF) meeting in February 2026. In March of 2026, the first meeting of the JT-DMF in the United States was held at the Paramount offices in New York City. The second version of the DMF Reference Architecture will be released by the EBU. In June of 2026, there was a face-to-face JT-DMF in Geneva at the EBU. See the latest DMF info and talk with subject matter experts at the AMWA demo area on the EBU's stand at IBC. Details to follow. You can be a part of the shared vision of DMF. Open questions around how DMF works, what challenges it can solve, and who stands to benefit from it are being shaped now. JT-DMF is the organization answering those questions and shaping the vision. If you want to be a part of those conversations, now’s the time to get involved. Momentum is building. Whether you work for a vendor, systems integrator, or end user, the shift to software-defined infrastructure is already underway. The move toward dynamic facilities is not theoretical. It’s inevitable and it’s happening now. Are you ready to join the conversation? Get involved in a JT-DMF working group by joining AMWA. AMWA members can join and contribute to any technical or business working groups. For membership info or to join, contact cindyz@AMWA.tv.

The Dynamic Media Facility is the agile broadcast ecosystem of the future – and it’s being shaped today. Watch this webinar to discover: What DMF is Why it will be important going forward What it can solve for you How to get involved in shaping DMF On this 30-minute live event, Willem Vermost from the European Broadcasting Union (EBU) , Mike Strein from Disney–ABC, and Naveed Aslam from Paramount talk about the combined efforts of the EBU and AMWA that have taken shape as the Joint Task Force on the Dynamic Media Facility (JT-DMF). This session is for you if you’re an engineer or executive at a broadcast or media company, vendor, manufacturer, or integrator, and you want to know more about where media facilities are headed.

Headed to NAB? It'd be great to see you there! Come see us for the latest on JT-DMF, DMF, & NMOS. • Visit team AMWA on the IP Showcase booth W1355 for latest on JT-DMF and NMOS •SMPTE VIBE: OGraf — Making Broadcast Graphics Open and Interoperable Willem Vermost, Senior Media Technology Architect at the European Broadcasting Union (EBU) Saturday18 April, 2:55pm, N259, SMPTE Visual Innovation and Brilliant Engineering Conference • Troubleshooting ST 2110 Systems with NMOS BCP-008 Stefan Ledergerber, Simplexity Monday 20 April, 3:30, IP Showcase As more SMPTE ST 2110 systems move into on-air production, operational visibility for non-experts becomes critical. This presentation reviews real-world issues observed in IP-based broadcast systems and demonstrates how NMOS BCP-008 (Minimum Status Reporting) helps operators quickly identify faults and better understand system health in modern distributed production infrastructures. • Dynamic Media Facilities Brad Gilmer, AMWA, and Cindy Zuelsdorf, AMWA Tuesday 21 April, 9:15 am, SBE Ennes Emerging Technology track, room N250 Broadcast facilities are being asked to support more workflows, formats, and distribution paths, often with fewer resources and tighter budgets. Concepts such as flexible production systems and dynamic media facilities (DMF) are becoming part of everyday infrastructure discussions. Real facility design choices and shift to software-based infrastructure will be covered. • NABA: How the Dynamic Media Facility Initiative Will Re-Shape Television Production and Delivery Naveed Aslam, Senior Vice President of Production Technology & Engineering for CBS / Paramount, and Willem Vermost, Senior Media Technology Architect at the European Broadcasting Union (EBU) Sunday 19 April,10:00, N261, Broadcast Engineering and IT (BEIT) Conference • SMPTE ST 2110 IP Media Roadshow Gerard Phillips, Systems Engineer at Arista Networks, and Willem Vermost, Senior Media Technology Architect at the European Broadcasting Union (EBU) Tuesday 21 April, sometime during the 10:00 a.m. to 5:00 p.m session. N252, SMPTE Roadshow: ST 2110 Bootcamp •From Idea to Production Ready SDK: The Rapid Evolution of the EBU MXL Project Vincent Trussart, Grass Valley Wednesday 22 April, 10:00, IP Showcase The EBU MXL project represents a good example of an industry-wide initiative progressing from concept to production-grade technology at unprecedented speed. Conceived as a pragmatic response to the need for efficient media exchange between software-defined media functions, MXL evolved from a simple idea into a production-quality SDK in less than 18 months–an exceptional achievement for a collaborative industry effort. This rapid pace reflects both a focused technical vision and strong alignment across broadcasters, manufacturers, and technology partners around concrete, real-world requirements. •Real-world Usage of DMF Principles - Lessons Learned During the MiCo 2026 Games Francois Legrand, CBC/Radio Canada Wednesday 22 April, 10:30, IP Showcase Close to a decade ago, CBC/Radio-Canada jumped in the IP train with the clear objective to transform audio/video production and to open the door to software based production. Thanks to the EBU's Dynamic Media Facilities Reference Architecture, this vision is now becoming a reality. This presentation will explain how the DMF-RA was used by CBC/Radio-Canada during the Milano-Cortina Olympic Games, what lessons where learned and what are the next steps. •DMF Connection Management: Applying NMOS to MXL Gareth Sylvester-Bradley, NVIDIA, Jonathan Thorpe, NVIDIA, and Simon Lo, Sony Wednesday 22 April, 11:30, IP Showcase This session includes a live demonstration of NMOS applied to the Media eXchange Layer (MXL) for discovery and connection management. We show how MXL flow writers and readers map naturally to AMWA IS-04 and IS-05, and discuss what a Best Current Practice might look like to formalize this approach. • Lining Up the Digital Ducks: Everything We Need to Make Hybrid Live Production Workflows a Complete Solution Andy Rayner, Appear Monday 20 April, 3:00, IP Showcase The world of live production is evolving quickly and we are embracing more and more software components alongside traditional hardware infrastructure. These Hybrid workflows will be here for a long time if not forever. In the meantime there are several technical initiatives being worked on by many industry organisations that are seeking to make the whole solution more joined up ‚Äì and more as it should be. This presentation will outline the challenges that exist and unpack relevant technical work being done in SMPTE, VSF, EBU & AMWA to address many of these. • Dynamic Media Facility: Resource Planning and Orchestration, Possibilities Today and Challenges Ahead Thomas Gunkel, Skyline Wednesday 22 April, 12:30, IP Showcase This paper explores how Dynamic Media Facility architectures enhance flexible, usage-based media production by orchestrating resources across vendors and workflows. Drawing on real-world collaborations, it highlights current capabilities and challenges in advance planning of compute, bandwidth, and licensing. It outlines practical approaches and templated planning to support efficient, scalable resource lifecycle management.

You know NMOS BCP-008 Minimum Status Reporting provides a simple way to know what’s working (and what’s not) quickly. It makes it easier to get a handle on connectivity, time synchronization, and stream validation. What you may not know is that BCP-008 has come a long way lately.  That’s what you’ll find out about on this webinar, which is for you if you’re an engineer at a vendor, manufacturer, or integrator.  NMOS BCP-008 Minimum Status Reporting: Progress, Next Steps & Why It Matters For You AMWA Webinar Replay (< 24 min) You’ll hear from Cristian Recoseanu of Pebble and Jonathan Thorpe of NVIDIA as they talk about the successes that came out of the BCP-008 workshop in Portugal, and then you’ll hear them answer questions from attendees.  Cristian reported that the participating vendors had excellent interoperability results. There were 3 media nodes passing the NMOS testing tools, so passing the IS-12 test suite, the BCP-008-01 test suite, and BCP-008-02 test suite. They had 3 controllers and 2 simple clients that were monitoring BCP-008 in an interoperable way, interacting with the media nodes.  There was also interoperability beyond BCP-008, including control and vendor-specific control, which is controlling things that a vendor explicitly enables and exposes for their particular device, and that has to be discovered and used in a generic way.  Watch to discover: The experiences of native NMOS implementers, and of those using nmos-cpp What developer resources are available for you and how to get started The robust NMOS testing suites and why you should use them in your integration pipeline What the outcomes of interoperability testing are Example devices and clients available to you After you watch, if you’d like to check out more about BCP-008 Minimum Status Reporting, visit www.amwa.tv/post/nmos-control-device-monitoring-bcp008 .  And if you’re ready for developer resources, you’ll find what you need here . Sign up for the next live Introduction to NMOS online session  on April 29. You’ll gain a clear and practical understanding of how NMOS works in real systems. From IS 04 and IS 05 flows to REST APIs and WebSockets, we break down the concepts so you can reduce risk when deploying SMPTE ST 2110 or IPMX environments. Or are you ready to go further? Our in-person NMOS Hands on Workshop  will take place on July 7-8 in Switzerland. EBU Technology & Innovation and AMWA are joining together for this immersive session designed for engineers, system integrators and all IP transition stakeholders who want real experience configuring and testing NMOS in practice.

Here are developer resources for NMOS BCP-008 Minimum Status Reporting Implementers guide ( INFO-006 ) where helpful developer checklists can be found nmos-control-scripty-client  – IS-12/BCP-008 example client in Typescript/NodeJS nmos-device-control-mock  – IS-12/BCP-008 example mock device in Typescript/NodeJs (also available as Docker container) nmos-js  – IS-12/BCP-008 prototype client in Javascript nmos-cpp  – fully tested library implementing IS-12/BCP-008 (Here's the branch from the Nov 2025 BCP-08 workshop: jonathan-r-thorpe/nmos-cpp at amwa-workshop-2025 ) sony/nmos-cpp: An NMOS (Networked Media Open Specifications) Registry and Node in C++ (IS-04, IS-05) sony/nmos-js: An NMOS (Networked Media Open Specifications) Client in Javascript (IS-04, IS-05) nmos-control-rusty-device  – IS-12 example device in Rust nmos-control-serpenty-device  – IS-12 example device in Python nmos-testing  – API testing framework –––––––––––––––––––––– A Bit About NMOS BCP-008 Minimum Status Reporting When something stops working in a complex IP environment, the last thing you want to have to do is troubleshoot every piece of equipment – and likely go about 12 menus deep on each – to see what went wrong.  Instead, if you had a simple dashboard that could show you the status of every device in your entire facility, you could root out the cause of the problem in seconds. With NMOS’s BCP-008, minimum status reporting – this simple traffic light system, you can have exactly that.   The simple traffic light system goes beyond discovery, registration, and connection management (IS-04 and IS-05) to solve the problem of what happens when you don’t have a working signal, and you need to figure out why quickly.  The NMOS Reporting domains are: 1- Connectivity , which includes 2 traffic lights: physical link and packet level. This could be a link down or some of the links down, or packets missing, being late, or lost (on receivers) or transmission errors of any kind (on senders). 2 - Synchronization , so is the expected synchronization present? If PTP is expected, is it there?. 3 - Stream Validation , which include issues with decoding the stream (on receivers) or invalid baseband signal to transmit (on senders). If these 3 status reports are supported in every end device, you will be able to find most of your problems and target them quickly.

Releases, Publications, Updates February 2026 IPMX Updates! NMOS Support for IPMX/HKEP and NMOS Support for IPMX/PEP have been published. NMOS Support for IPMX/HKEP, BCP-005-02, establishes a standardized mechanism for NMOS Senders and Receivers to declare support for HDCP over IP streaming using IPMX/HKEP (VSF TR-10-5). NMOS Support for IPMX/PEP, BCP-005-03, establishes a standardized mechanism for NMOS Senders and Receivers to declare support for Privacy-encrypted streaming using IPMX/PEP (VSF TR-10-13). ## September 2025 NMOS Support for IPMX/USB, NMOS Support for IPMX/HKEP, and NMOS Support for IPMX/PEP are underway! Stay tuned for updates. ## New NMOS Publication: BCP-008 NMOS Minimum Status Reporting A persistent challenge in IP media systems is that monitoring and control tools often receive inconsistent or incomplete status information from devices. Vendors may expose data differently, rely on varying models, or require manual configuration before systems can interpret the information. This fragmentation makes it difficult for end-users to validate streams, confirm synchronization, and troubleshoot connectivity in multi-vendor environments. The BCP-008 initiative tackles this by defining a clear baseline for minimum status reporting across NMOS receivers and senders. The goal is to ensure that all NMOS-enabled devices provide a common set of status information covering three key areas identified in the white paper “Standardised Status Monitoring on NMOS Systems” (SRF): stream validation, synchronization, and connectivity. BCP-008 (NMOS Minimum Status Reporting) adds a simple, standardized way to check if NMOS devices are truly working after they’re connected. It uses a “traffic light” system—green for good, yellow for “check later,” and red for service impact now—so users can quickly see device health at a glance. Status is reported across four domains: connectivity, packets, synchronization, and stream level, with the overall state reflecting the most serious issue. This helps operators spot problems quickly, understand whether they need immediate action, and know who to call if something goes wrong. By completing consultation, aligning on scope, and selecting the technical framework, AMWA has laid the groundwork for consistent minimum status reporting. The activity is now entering the wider adoption and certification stage with further workshops and events planned. 🔗https://specs.amwa.tv/bcp-008-01/ 🔗https://specs.amwa.tv/bcp-008-02/ ## New NMOS Publication: BCP-006-04 MPEG Transport Stream Although NMOS specifications are widely used for uncompressed IP-based workflows, many facilities and services rely on compressed MPEG Transport Streams (MPEG-TS) as part of their infrastructure. A persistent challenge has been ensuring that NMOS controllers can configure and manage connections between TS senders and receivers in a reliable, interoperable way. Without standardization, end-users face uncertainty around stream compatibility, while vendors must implement ad hoc methods to represent capabilities. The BCP-006-04 initiative addresses this by defining how NMOS can support configuration and interoperability for MPEG-TS devices, particularly for SMPTE ST 2022-2 streams including for VSF TR-01 (JPEG 2000) and TR-07 (JPEG XS). The first phase focuses on describing sender and receiver capabilities in a manner that controllers can use to automatically determine interoperability. AMWA progress includes: - Release of BCP-006-04, which enables registration, discovery, and connection management of MPEG TS endpoints using the AMWA IS-04 and IS-05 NMOS specifications. - Refined the BCP-006-04 documentation to define the model for MPEG-TS support. - Designing and beginning implementation of a dedicated test plan within the NMOS testing framework. - Securing commitments from multiple implementers, including Pebble Control (controller), Appear (node), nmos-cpp, and additional vendors, to ensure a diverse test base. - Planning an interop remote workshop (via VPN) to validate implementations and confirm interoperability across real-world devices. Through this work, AMWA is enabling MPEG-TS devices to be managed consistently alongside other NMOS-enabled equipment. For users, this means simplified configuration and greater confidence in interoperability. For vendors, it reduces the need for custom integration while ensuring alignment with the broader NMOS ecosystem. 🔗https://specs.amwa.tv/bcp-006-04/ ## AMWA Publishes IS-14: NMOS Device Configuration Configuring IP-based media devices is often complex, with each vendor offering unique approaches to saving, restoring, or automating device settings. This fragmentation creates challenges for system integrators and engineers who need reliable ways to back up configurations, roll them back, or deploy them consistently at scale. Without a common method, operators face added effort in both day-to-day operations and long-term system maintenance. The IS-14 specification, recently published by AMWA, addresses this need by defining a standard mechanism for saving and restoring the configuration of NMOS Devices. The goal is to give system configurators and engineers a simple, consistent, and API-driven way to manage device states. User needs range from basic backup and versioning to advanced CI/CD integration, where configuration data can be delivered automatically to multiple systems in large-scale environments and Dynamic Media Facilities (DMF). IS-14 builds on MS-05-02 models, exposing them via an HTTP-based API with emphasis on efficient bulk Get and Set operations. It also considers context-dependent configurations, ensuring that fragments requiring specific device states can still be restored safely and intuitively. AMWA progress includes: Publishing the IS-14 specification with reviewed and confirmed conformance language. Adding nmos-testing coverage, so IS-14 can be validated as part of the broader NMOS Test Suite. With IS-14 now available, the industry gains a standardized, interoperable approach to device configuration—simplifying operations, enabling automation, and strengthening system resilience. 🔗https://specs.amwa.tv/is-14/ ## Open Source Sender Receiver Framework (OSSRF) Released One of the key challenges for vendors developing NMOS-enabled devices is bridging the gap between the control plane and the media/transport plane. Many vendors already have proprietary control protocols and data planes, but it is not obvious how integration with NMOS can be achieved, leading to increased development cost and slower time to market. The Open Source Sender Receiver Framework (OSSRF) addresses this challenge, providing an open-source reference sender/receiver with NMOS control (IS-04, IS-05) and media plane integration. Built on the widely adopted nmos-cpp project, OSSRF exposes both a bare media API and GStreamer plugins, enabling real-time streaming with low-resolution ST 2110-20 (video) and ST 2110-30 (audio) flows. The framework demonstrates seamless NMOS operation on both commodity and cloud-based hardware platforms. OSSRF serves multiple purposes: as a foundation for NMOS integration in commercial products, as a test target for interoperability, and as a development tool for control application testing. By reducing barriers to entry and promoting open development, OSSRF aims to accelerate adoption, foster innovation, and deliver a flexible, community-driven alternative to proprietary systems. ##

AMWA is so pleased to announce that we’ve received a Technology & Engineering Emmy® Award for SMPTE ST 2067 — Standardization of Interoperable Master Format (IMF) from the National Academy of Television Arts & Sciences.  We’d like to thank colleagues across our industry who contributed to the formation of this technology. IMF would not exist without Annie Chang and her colleagues at Disney, and we were delighted to collaborate with her. Clyde Smith at Turner Broadcasting System drove adoption, Bruce Devlin (Mr. MXF), and Phil Tudor and Philip de Nier from BBC R&D provided critical components of the technology which AMWA contributed to the IMF effort. We also recognize the ongoing support from CBC/Radio-Canada R&D who supported this work. We thank our colleagues at SMPTE, which harmonized the contributions from Annie and the cinema world with contributions from Turner and the television industry.  It was an outstanding collaboration across organizations and industry segments. Watch Brad Gilmer, Executive Director of AMWA, accept the Emmy® Award.  AMWA is a co-honoree along with SMPTE, Digital Cinema Initiatives (DCI), and the University of Southern California’s Entertainment Technology Center.  IMF is a file-based media format that simplifies the delivery and storage of audio-visual masters intended for multiple territories and platforms. Using open-source, proven technology, IMF works with any finished audio-visual masters, including long-form movies, episodic content, advertisements, and short-form content.  “This is a great example of how trade associations, industry partnerships, and standards bodies can work together to achieve great things,” said Brad Gilmer, AMWA Executive Director. “On behalf of AMWA, we're thrilled to have been a part of it. You can find out more about SMPTE ST 2067 at SMPTE.org .  Keep up to date on all of the latest AMWA news at amwa.tv/blog .

Find out how to stop the flood of alarms to focus on what’s actually important. When something stops working in a complex IP environment, the last thing you want to have to do is troubleshoot every piece of equipment – and likely go about 12 menus deep on each – to see what went wrong.  Instead, if you had a simple dashboard that could show you the status of every device in your entire facility, you could root out the cause of the problem in seconds. With NMOS’s BCP-008 simple traffic light system, you can have exactly that.  That’s the topic of a recent AMWA webinar: Cut Your IP Troubleshooting Time With NMOS’s BCP-008 Traffic Light System .  When you watch, you’ll hear from Stefan Ledergerber of Simplexity and Willem Vermost of the EBU as they talked about what NMOS BCP-008 minimum status reporting is and does for you, and then they answered questions from the audience.  “Everyone still compares IP and SDI, and the most significant difference is before you had one unit you'd talk to, and it would make the connection from X to Y,” Stefan Ledergerber said, putting the central challenge of IP in context. “And now this central unit from one manufacturer has turned into a distributed system, made up of many different manufacturers. So in order to make one signal connection, you have multiple manufacturers who need to be talking to each other, and only if they do, you get your working signal. This is a much more complex task.” The simple BCP-008 traffic light system goes beyond discovery, registration, and connection management (IS-04 and IS-05) to solve the problem of what happens when you don’t have a working signal, and you need to figure out why quickly.  Watch the recording  to discover: — How you can stop the flood of alarms to focus on what’s actually important — Why minimum status reporting makes troubleshooting easier — How you can have more confidence that everything is working as it should — What BCP-008 indicates for stream validation, packets, synchronization, and connectivity — How you can use the simple, open-source traffic light system After you watch, if you want more information about BCP-008, visit www.amwa.tv/nmos-getting-started . If you’d like to find out about upcoming AMWA events, head to go.amwa.tv/nmos-workshop .

In this implementers guide video Cristian walks us through the Implementers guide for NMOS Control & Monitoring (INFO-006) and how some of its recommended checklists have been implemented in the open source NMOS control mock device example implementation. The video starts with a quick NMOS Specs overview of the NMOS categories or themes and then goes over the NMOS Control & Monitoring ecosystem including a diagram covering how interoperability and conformance was achieved and maintained whilst preserving vendor freedom. The next section introduces the NMOS control mock device open source project on GitHub and how to use it. This is a fully compliant and tested example implementation of IS-12 and BCP-008 written in TypeScript/NodeJS. Following on from this, the video dives more deeply into the INFO-006 guidance including its checklists for both device and controller implementations. Then the majority of the checklists are matched between the INFO-006 guidance and how they have been implemented in the mock device code base. Finally, the end of the video brings everything together by running the mock device application and utilizing a compatible IS-12 / BCP-008 controller showcases an operational demo of the device being monitored. ----------------- 4:07 AMWA NMOS specs overview and Control & Monitoring ecosystem diagram 6:15 NMOS device control mock introduction 11:25 INFO-006 introduction and device implementation tutorial 13:56 INFO-006 controller implementation tutorial 14:25 INFO-006 how to practical examples and how to get started 15:45 Device implementation checklist 21:40 Device implementation Blocks 28:42 Device implementation Managers 33:10 Device implementation IS-12 Protocol, IS-04 & IS-05 interactions, Commands, Subscriptions, Events & Notifications. 45:40 Status monitoring (BCP-008) 47:40 Other more advanced topics: NMOS control features sets, Nested blocks, Non-standard classes 58:20 Operational demo with compatible Controller ____ (auto-generated partial transcript) Hello everyone. This is Cristian here from Pebble. I'm here to talk to you about NMOS device control and monitoring. I'm one of the main contributors in the activity group and just wanted today to talk to you a bit about some of the resources available to implementers. This is a very important area for the NMOS community and it's progressed very quickly in the last few months. We want to let you know about the resources we have in place. Today, we're going to look at some actual code and the implementers guide. Before we go into that, I just wanted to give you a brief little overview of the ecosystem. Most of you will know about NMOS IS-04 Discovery & Registration and IS-05 Connection Management. Today, however, we're going to focus on Device Control and Monitoring. I'm going to briefly show you a diagram that I enjoy, which is this squid diagram depicting the ecosystem of control and monitoring. [00:01:21.02] It relies on different parts, different logical parts, playing really nicely together and splitting the problem space into different layers that we can then solve with the best tools available. We've got MS-O5-02 on the left-hand side, which is the modeling language. This is how we define what data types and what object entities, what classes you can create. There are core classes that are really needed for everything. But then vendors can also define their own classes. They can create their own vendor-specific objects with their own vendor-specific data types, and all need to be discoverable by the same means. Anyone can use those as well, but they are not part of the standard set. MS-O5-02 establishes these rules. Then you need a way to interact with those models in a device structure. You have IS-12, which is our communication protocol. That relies on the WebSocket transport, and we send JSON payloads over that. It's bi-directional. It allows for both control and notifications to flow backwards and forwards. That is how you interact with those models. It's really efficient, really compact, and also straightforward to debug and to view.   [00:02:42.24] Also, you can create a web app entirely in a browser that can control one of those endpoints. You can use a WebSocket extension for a browser to interact with devices. We thought about some of these nonfunctional requirements. The other element of this is BCP-008. That establishes monitoring behaviors of some of these media devices at a feature-specific level. For example, we have BCP-08-01 receiver monitoring which defines how to describe receiver statuses via this framework. Then we have BCP-08-02, which is the counterpart for senders. Those all establish requirements and behavior on top of having the transport conformance, the message payload conformance, and data types and classes. And all of these fit really nicely together in one big set allowing conforming devices which are still very distinctive. They have their own features they can do, but they are all advertised and interactable using the same protocol and offer the same discovery means to a controller. That's where we are. I'll show you briefly where everything is again. If you go to specs.amwa.tv, that forwards you to this nice portal.   [00:04:14.20] You can also go directly to specs.amwa.tv/nmos, or you can just click here on the NMOS tab, and that directs you to the NMOS portal. Here, you have a rendition of the diagram I just showed with the columns in a table format with all the links and the versions. You've got resource management, connection management, device control and monitoring. The one that we're going to focus today is actually here: device control and monitoring. Specifically, we're going to focus on the implementer's guide. So INFO-006 which you can view as the point of entry into this. So you've got references and guidance for all of the other subparts in there. We're going to look at that as one of the main resources for today's video. We're also going to use a controller to show you some of the operational feel of the ecosystem and we're going to use what we call the NMOS device control mock.   [00:05:29.10] This is another open-source application. It's a TypeScript NodeJs application that you can use. It's rendered here as documentation, but the codebase is available on GitHub. If you navigate to this link, there are links throughout the specs as well. Once you have NodeJs installed, you can install all its dependencies using "npm install", and then you can build it or you can build and start it. Or if you want to make changes to the code base, you run "npm run serve", which effectively recompiles the application if you make any changes. We're going to see that today. There's the specs.amwa.tv link. If you search for this, you will find the GitHub repo as well. All of that documentation is here as well. The way you grab this is by doing a clone of it. It's all in the public domain, or you can just grab a zip file if you want, or whichever way you want to do it. Once you pull that in, you're going to have something that looks a bit like this. I'm going to grab this across the screen so you can see. I'll go to the main folder.  [00:06:43.15] You get something like this. It's got some of the documentation, but what we're interested in is the code there. If you go to the code directory, and for this session, I'm just going to open it in Visual Studio Code. I've opened it here. Okay, so we've opened that in Visual Studio Code, and I'm in the code subfolder. I'm just going to wait for the Terminal to load here just to show you how you can run this in those two ways. So if I run through the first one "npm run build-and-start". This will compile the application and run it up. It'll take a couple of seconds, but it will show you what it's doing in there. We'll wait for that to finish and that should run up. I should have said for this, I've also got an NMOS registry running in the background. You can configure this. If you look at the documentation, you can run this without a registry. You just have to change one of the configuration items in there.   [00:08:15.13] For this demo, I've got the nmos-cpp-registry running here. Now, it's just going to copy those compiled files to the distribution folder and then hopefully run it. Then we can look at our controller just to establish the environment we're in and give you a brief look at what we have for the mock device. Then we're going to go back to the implementer's guide. That's all up and running. It's on port 49999, and it's registered in the registry, and it's already starting to communicate with the controller. Let's have a look at that. We got our controller up and running here, and that shows up as this NC-O1 node. This is our IS-04 node. It's got a device, and it's got a receiver and a sender. You'll see that device has a control endpoint. We're going to look at this through the lens of implementation guide checklist in a second. This is the IS-12 control endpoint in here. This is how the controller interacts with our device. If I briefly do a little exploration of that, you'll see this is our device model structure.   NMOS Control and Monitoring: Implementers Guide and Device Mock

AMWA has won a Technology & Engineering Emmy® Award! We are honored to announce that AMWA is the recipient of a Technology & Engineering Emmy® Award for SMPTE ST 2067 — Standardization of Interoperable Master Format (IMF) by The National Academy of Television Arts & Sciences.  AMWA is a co-honoree along with SMPTE, Digital Cinema Initiatives (DCI), and the University of Southern California’s Entertainment Technology Center. On December 4th, 2025 in New York, AMWA and our fellow honorees will be recognized at the 76th Annual Technology & Engineering Emmy® Awards ceremony.  IMF is a file-based media format that simplifies the delivery and storage of audio-visual masters intended for multiple territories and platforms. Using open-source, proven technology, IMF works with any finished audio-visual masters, including long-form movies, episodic content, advertisements, and short-form content.  “This is a great example of how trade associations, industry partnerships, and standards bodies can work together to achieve great things,” said Brad Gilmer, AMWA Executive Director. “On behalf of AMWA, we're thrilled to have been a part of it. You can find out more about SMPTE ST 2067 at SMPTE.org .  Keep up to date on all of the latest AMWA news at amwa.tv/blog .

Partnership to address business and technical challenges of DMF adoption September 13, 2025 – The Advanced Media Workflow Association (AMWA) and the European Broadcasting Union (EBU) today announced the formation of the Joint Task Force on Dynamic Media Facilities (JT-DMF), a groundbreaking collaboration designed to facilitate an industry-wide transition to the Dynamic Media Facility (DMF) concept and software-based media production. The JT-DMF aims to establish an industry council bringing together vendors, end-users, and systems integrators to discuss critical business, technical, and strategic questions and challenges. Initial focus areas include developing timing models to support the Media Exchange Layer (MXL) Software Development Kit (SDK) open-source project, establishing a business-level advisory council, and addressing orchestration challenges through AMWA's expertise in media workflows and Networked Media Open Specifications (NMOS). The task force will operate as workgroups composed of members of EBU and AMWA, ensuring broad industry representation and expertise, with a governance committee composed of leadership from both organizations. Félix Poulin, Director of Global Innovation Collaborations, CBC/Radio-Canada, emphasized the significance of the task force, stating, "This initiative will be at the forefront of this emerging technology and represents a pivotal next step in our industry's evolution toward more flexible, efficient media production environments." “This is a major milestone toward an open, efficient, software-defined future, as key players in the industry join together,” said Willem Vermost, Senior Media Technology Architect, EBU. "At EBU, we are proud to work with AMWA on this joint task force because our organizations share a common vision for a scalable, interoperable, agile media landscape." "This collaboration leverages the collective expertise of our member organizations to drive meaningful industry transformation," said Brad Gilmer, Executive Director, AMWA. "It represents the ideal place for these critical discussions to happen, bringing together business and technical perspectives to address the complex challenges of dynamic media facility implementation." Phil Tudor, Head of Applied Research, BBC R&D, emphasized the broad nature of the effort: "The Task Force will bring together a wealth of experience to ensure that the next wave of live production infrastructure can benefit users and vendors alike. We are looking forward to working with EBU and AMWA on what promises to be an exciting set of challenges for the industry." For more information on the JT-DMF, contact Cindy Zuelsdorf of AMWA at cindy.zuelsdorf@amwa.tv or Patrick Wautier of EBU at wauthier@ebu.ch. See the EBU article here. About AMWA The Advanced Media Workflow Association (AMWA) is a membership organization that brings together the media industry to collaborate on open standards and best practices for media workflows. AMWA develops the Networked Media Open Specifications (NMOS) and promotes vendor-neutral approaches to media technology implementation. Find out more at https://www.amwa.tv/. About EBU The European Broadcasting Union (EBU) is the world's foremost association of national public media organizations, representing 113 members from 56 countries. The EBU promotes the interests of public media and facilitates the exchange of program content, best practices, and technical standards among its members. Find out more at https://www.ebu.ch/home. # # # JT-DMF JT DMF JTDMF

If you're involved in media production technology — whether you’re a broadcaster planning your next equipment purchase, a manufacturer developing new products, or a systems integrator architecting systems for the future — knowing the industry’s preferences for control plane standards will help you make decisions that align with where the market is clearly moving. The results from a comprehensive survey conducted by AMWA and EBU reveal critical insights that could shape your technology decisions and strategic planning for years to come. The survey explored how professionals across our industry view control, which is defined as the ways users interact with and manage media devices, including hardware equipment and software applications.  With 97 responses representing 75 different organizations — including everything from small media companies to the largest, most prominent manufacturers, systems integrators, and broadcasters — these findings offer a representative snapshot of where your peers and competitors see the industry heading. One methodology note before diving into the data is that when there were multiple responses from the same company, those responses were aggregated to count as a single response per organization. For the purposes of this survey, Control is defined by the ways users interact with and manage Media Devices - including hardware equipment as well as software applications. Those interactions include: Dynamic Operations: Adjusting live operational parameters through user interfaces like knobs, faders, buttons, and selectors. Device Observation: Monitoring Device status and alarms via monitoring systems. Initial Configuration: Configuring static parameters to establish a Device's initial or default state. An Open Control Specification is the Priority When asked to rank what’s most important to respondents, the top choice was an open control specification. The overall ranking was the same for all categories of respondents.  Respondents were less interested in conforming to the same spec, or a limited number of control specs. Because the least popular response was that only some devices should have a control specification, that could be interpreted as the industry wanting all devices to be controllable. NMOS-Control is the Top Choice for Interoperability When asked how we can best achieve control interoperability, the most popular answer is NMOS-Control APIs (IS-12, BCP-008, MS-05, and IS-14). This was the top choice among all categories of respondents. The second most popular response in all categories was any open specification or API. Combined, the vast majority of survey respondents (74%) are clear in wanting an open solution.  Catena was only selected by 7% of manufacturer respondents as their choice for interoperability, but it wasn't a preferred option for end users or systems integrators. Open specifications for the purposes of this survey means: Publicly Available: It is freely accessible to anyone, typically without a charge for the document itself. This means it can be read, downloaded, and distributed by all interested parties. Well-Documented: The specification is comprehensive, clear, and unambiguous, providing all necessary details for multiple independent implementations to achieve interoperability. It avoids intentional secrets or ambiguities that would hinder implementation. Royalty-Free/Compensation-Free: There are no royalties or fees required to implement or use the technology described by the specification. This means that anyone can develop products or services based on the specification without paying licensing fees for intellectual property (like patents or copyrights) essential to its implementation. While certification for compliance might incur a fee, the core use of the specification for development remains free. Vendor-Neutral & Non-Discriminatory: It is not controlled by a single company or individual. Its development and maintenance typically involves a collaborative, consensus-driven process overseen by an association, standardization body or open-source framework, ensuring fair competition and preventing vendor lock-in. When asked about using NMOS Minimum Status Monitoring (NMOS BCP-008),  which defines an easy-to-follow traffic light system to monitor the health of IP media facilities, 75% of all respondents were very or somewhat interested. As you might expect, twice the number of end users are very interested in NMOS Minimum Status Monitoring compared to manufacturers, clearly showing that it is the end users who feel the pain trying to monitor faults in real-world multi-vendor installations.  For more about Minimum Status Reporting and how it could simplify your workflow, check out this 2.5-minute video .  Three out of Four Are Moving Toward Software Finally, when asked how prepared respondents are for a transition to software-based (or cloud-based) production, 76% say they are fully or partially prepared. Manufacturers are the most likely to indicate that they’re ready, with nearly half saying they are fully prepared. Among end users and systems integrators, 25% say they are in the early stages of preparation.  These surprisingly strong data points may indicate a self-selection bias among respondents to a survey about a Media Control Plane. However, we can safely conclude that our industry is well aware of this next major transition.  Conclusions As the industry transitions to software-based production, it’s clear there is a real need and desire for control plane interoperability. And an open control plane is the most-wanted approach, with NMOS- Control as the top choice, followed by any open specification. There’s also a lot of interest in using NMOS Minimum Status Reporting.  Want to find out more about NMOS-Control? Read this blog post: NMOS: What’s In It For You? Device Monitoring, Minimum Status Reporting, and More.   The AMWA and EBU survey shows that the industry wants an open media control plane to achieve interoperability. Your Input! Take 30 seconds and let us know if you’d like to attend a workshop, participate in a tested event, or something more: https://forms.gle/wFXi11DWnrNN1PAK7

If you’d like to quickly pinpoint 80-90% of the problems that are encountered in IP systems, you will want to read this part 2 blog post to find out how NMOS device monitoring – just one of the useful benefits covered below – can save you time, costs, and errors. See how NMOS Control and BCP-008 give you the minimum status reporting you need. If you haven’t read the first blog post, which covered NMOS Connect – discovery, registration, device management, and signal management – you can read part 1 here.   Generic Control Protocol There’s a part in NMOS that allows you to read, write, or send any kind of settings of any device. It’s an open generic layer where you can send and read all kinds of settings and it could replace a lot of legacy control protocols.  Editor’s note: This is part 2 of a blog post based on the 2024 NAB presentation of Stefan Ledergerber at Simplexity  in Zurich, Switzerland. You can view the full presentation NMOS: What’s In It For Me? on YouTube . Connect with Stefan on LinkedIn . NMOS specifies a generic control protocol that defines a certain rule set of how to communicate with each other. It is open to define what are called device models. If you’re a manufacturer, you can model all of your products and parts inside that spec. Any device model distinguishes between:  Properties , which are device settings. Methods , which execute a functionality, so for example, hitting a play button on a machine would be a method.  Notifications , so you can subscribe to certain elements that you are interested in knowing about, and then if a value changes, you would be notified from the device.   The last one, notifications, is very important. As you know, right now, many systems require you to pole, reading out values repeatedly in order to find out whether it has changed. That's not very efficient and doesn't scale very well across big installations.  Device Monitoring On the device monitoring side, AMWA members  are about to finish standardizing IP-related status reporting mechanisms. It's not just a question of whether you get access to information. It goes beyond that and it's about minimizing the amount of information you're actually sending across the world. Less is more. Because nothing is more boring than looking at a screen with hundreds of messages. And in many practical cases, people operating MCR get stormed with messages, and assume they’re not relevant so they start ignoring them. NMOS allows you to reduce the storm of messages down to what’s most important.  By looking at 3 simple domain statuses that follow the analogy of traffic lights, you could probably find 80-90% of the problems you encounter in an audio/video-over-IP system. These traffic lights could at least allow an operator to call the right person quickly and address issues more efficiently.  The NMOS Reporting domains are: Connectivity , which includes 2 traffic lights: physical link and packet level. This could be a link down or some of the links down, or packets missing, being late, or lost (on receivers) or transmission errors of any kind (on senders). Synchronization , so is the expected synchronization present? This includes issues like PTP unlock or grandmaster change. Stream Validation , which include issues with decoding the stream (on receivers) or invalid baseband signal to transmit (on senders). If these 3 status reports are supported in every end device, you will be able to find most of your problems and target them quickly.  On top of these, every sender and receiver is indicating an “overall status,” as a summary of the 3 domain statuses. It takes the worst state of the 3 domains contained. By using a traffic light symbol again, this overall status could be indicated straight in your user interface. If every sender and receiver in use is indicating green, it will give you confidence that your IP system is working just fine. A yellow state would say that you should possibly check the system during the next break, but all audio/video signals are still perfectly fine. However, a red state on a sender or receiver should trigger immediate action, first by checking the 3 domain status lights, then by calling the expert on the respective domain. Minimum Status Reporting with NMOS BCP-008 Since this overall status is a summary, manufacturers are welcome to add more states to the 3 “minimum status” reports, as this AMWA initiative is called. The overall status would still take those extensions into account and indicate the worst of them. Initial Setup of Devices The third part of Device Settings and Monitoring is an initial setup of devices. These specs explain how you take the device out of the box and get it to a default setup. There's also a backup restore functionality that’s described. Network Security The fourth and final focus of NMOS is security. They describe the standard mechanisms IT uses:  Control encryption of commands using HTTPS Access authorization – how to use an authentication server How to handle certificates  None of this is news to IT folks, but there is a need for describing how to use it in the context of NMOS, and that’s what these specifications do.  So, as an overview, what’s in the web in the image above is what NMOS describes. It's basically everything. And most of it is ready and clearly defined. And yet, out of all of this, all that people are primarily familiar with IS-04 and IS-05. That’s what’s in the purple ovals.  Now in the next image, you can see the numbers that correspond to each function of NMOS. There's a whole channel of documents, best practices, and specifications on the NMOS website  that you can read. The documents are public, and even the meeting notes are public. Get started at https://specs.amwa.tv/nmos/ .  What’s In It For Me? So to sum up, if you’re an end user, NMOS can shorten your requirements engineering phase. You can leverage work done by others and actually use that work when you write your RFPs. You don't have to think it all through yourself.  With that being said, it is important to ask vendors for NMOS, but don't just write in your RFP, “It has to do NMOS.” That's just not enough. Now that you see everything that NMOS can do, you can appreciate why it’s important to get more specific with what you need.    Ultimately, it will help you build an open system with no vendor lock-in, and that will save you on costs. And if you’re a manufacturer, NMOS shortens your requirements engineering phase. You can also leverage work already by others – specifications, coding, and testing. You don't have to do that all yourself. You can become part of a complete solution rather than just offering products. And ultimately, all of these benefits add up to saving on costs, which means you can increase your profit.  If you’re surprised to find out that NMOS can save you time, costs, and many common problems and errors, you’re invited to find out even more by joining AMWA . As a member, you can take part in working groups and the NMOS community that provide a place for open technical discussions and consensus between a wide range of end users and suppliers. Join today and be a part of the future of NMOS.  Resources Download Download Download Info for Purchasers and decision-makers   Info for strategic technical people and details on business efficiencies   Info for those responsible for making everything work together, integrators, end users   Find out about IPMX and NMOS   Get started with NMOS here: Open source sender and receiver framework (GitHub) Want to start implementing NMOS Control in your products? See tutorials, info on IS-12, BCP-008, and more . Ready to join AMWA?