Videos NMOS - Networked Media Open Specifications Fundamentals ​ An Introduction to the AMWA Networked Media Incubator project 4:47 Brad Gilmer, AMWA 1. Introduction to Networked Media Open Specifications 9:08 Andrew Bonney and Alex Rawcliffe, BBC R&D An introduction to the current specifications in progress, their data model and key concepts. 2. NMOS: Discovery and Registration 8:39 Andrew Bonney and Alex Rawcliffe, BBC R&D A robust and scalable approach to Discovery is essential element of real-world management networked media. This presentation describes how to use NMOS's Node, Registration and Query APIs for discovery, from small peer-to-peer cases to large installations. 3. NMOS: Connection Mangement 2:52 Andrew Bonney and Alex Rawcliffe, BBC R&D NMOS allows Senders and Receivers to be connected in a transport-agnostic way. Andrew and Alex describe how to do this using the Node API. 4. NMOS: In-stream Identity and Timing 4:18 Andrew Bonney and Alex Rawcliffe, BBC R&D NMOS provides a universal identity model for content and an end-to-end timing model, both important elements of a future-proof networked media architecture. This presentation explains these contents, and how they are mapped to media streams. Demonstration of NMOS Registration and Discovery 3:40 Alex Rawcliffe, BBC R&D An example of NMOS Registration and Discovery in action using software and hardware from multiple manufacturers. ​ Public presentations IBC 2019, IP Showcase, curated by the Video Services Forum ​ NMOS Now and Next 28:43 Peter Brightwell, BBC R&D An introduction to the AMWA Networked Media Open Specifications, including an outline of the specifications themselves, how they have been developed and tested, the state of industry adoption, and broadcaster perspectives. ​ AMWA NMOS Automated Testing 30:41 Andrew Bonney, BBC R&D and Gareth Sylvester-Bradley, Sony Europe An introduction to the open source AMWA NMOS Testing Tool, which can be used to automatically ensure that Media Nodes and other appliances are adhering to the NMOS specifications. ​ NMOS IS-07 – GPI Replacement and Much, Much More 23:58 Miroslav Jeras, Pebble Beach Systems IS-07 Event & Tally is part of the NMOS suite that defines how states and state changes are communicated in an IP environment. It is not only a GPI replacement but it also provides a platform for resolving many other problems broadcasters are facing in the IP transition. ​ Security for Discovery and Connection management of ST 2110 Media Devices 25:30 Arne Bönninghoff, Riedel Communications This session describes the current workflow of the BCP-003 Security best practices, including proposed mechanisms to encrypt NMOS APIs with TLS to prevent man in the middle attacks. Furthermore, AMWA IS-10 is reserved to specify authorization mechanisms to secure access to NMOS APIs like IS-04, -05, or -08. ​ Using AMWA IS-06 for Flow Control on Professional Media Networks 26:15 Rob Porter, Sony Europe and Sachin Vishwarupe, Cisco Systems AMWA IS-06 is an open specification for setting up and modifying flows on a professional media network, allowing the use of Software Defined Networking to both authorise and optimise network usage. This presentation describes the current IS-06 APIs and some of the future areas of development. ​ NAB 2019, IP Showcase, curated by the Video Services Forum ​ AMWA NMOS: The Whole Story 31:25 Brad Gilmer, AMWA and Peter Brightwell, BBC R&D This talk serves as an introduction to AMWA NMOS, covering all parts of this suite of interface specifications and best practices. It also touches on why we’re creating it, the approach we’re taking, and how it’s being implemented. The AMWA IS-04 and IS-05 interfaces are now recognized as being essential to the industry’s move to interoperable live IP infrastructure. They allow control applications to automatically discover and connect networked media devices and are now mature specifications featured in many products. ​ A MWA NMOS IS 04 and IS 05: Things You Might Not Know 29:31 Andrew Bonney Did you know for example, that there is no requirement for every node in a system to run the same IS-04 version? This presentation will take a look at some of the lesser-known and more advanced features of IS-04 and IS-05, along with how they may assist you in deploying anything from a small ad-hoc setup through to a large-scale multi-format facility. ​ AMWA BCP 003 NMOS API Security 17:03 Simon Rankine, BBC R&D BBC Research and Development’s Simon Rankine presents an update from AMWA’s NMOS API Interoperable Security Group which is working to apply tried and tested web technologies to the APIs in order to provide APIs that are simultaneously secure and cross-vendor interoperable. ​ NAB 2019, AMWA Booth ​ Cisco IP fabric for Media 16:28 Rahul Parameswaran, Cisco ​ SMPTE Annual Technical Conference 2018 Scalability and Performance of the AMWA NMOS IS-04 and IS-05 Specifications 27:53 Rob Porter and Gareth Sylvester-Bradley, Sony Europe A key requirement is that APIs such as those used for AMWA IS-04 and IS-05 scale successfully in the very large installations, typical of real world deployments. To help address this, Sony has been leading an AMWA NMOS Scalability study to test these protocols for installations comprising thousands of media devices. ​ SMPTE Webinar, May 2018 ​ Exploring the Role of NMOS: Discovery and Connection in an IP World 1:32:52 Peter Brightwell SMPTE ST 2110 specifies how to stream video, audio, and data between devices for professional applications using IP networks. How best to discover, connect, and monitor those devices? That is addressed by the Advanced Media Workflow Association (AMWA) Networked Media Open Specifications (NMOS). This SMPTE Technology Webcast will focus on how different parts of the AMWA NMOS work, in theory as well as in practice, and on how NMOS can be used in a range of applications, whether within a broadcast control room or a cloud-based workflow. ​ Agile Media Workflows ​ Introducing the AMWA Agile Media Blueprint 25:33 Richard Cartwright, Streampunk Media Introducing the Agile Media Blueprint (AMB), a plan for how to use the same technology platform as used for the Internet to make television, OTT media systems and to enable new kinds of creativity. A Demonstration of ZeNMOS and SDPoker 10:31 Richard Cartwright, Streampunk Media A brief demonstration of open-source testing tools ZeNMOS and SDPoker, designed to help users and suppliers to test products that support the latest IP Standards (SMTPE ST 2110) and Specifications (AMWA NMOS IS-04). ​ MXF - Media Exchange Format AS-10: MXF for Production - Acquisition to Air & Archive 8:08 Dan Shockley, CNN A presentation by Dan Shockley from NAB 2012 on the AMWA specification 'MXF for Production', AS-10 Webinar: AMWA AS-11: Introducing the New Rules-Based Specifications 38:16 Thomas Heritage, BBC and Kevin Burrows, Channel 4 The AMWA AS-11 family of Specifications define constrained media file formats for the delivery of finished media assets to a broadcaster or publisher. The business case for AS 11, MXF for Contribution. pt 1 of 2 13:11 Ian Wimsett, Red Bee Media Part 1 of a presentation given by Ian Wimsett at NAB 2012. The AMWA application specification was designed to meet the needs of publisher broadcasters who may need to process content, for example segmentation, before it is ready for air. The Business Case for AS-11: MXF for Contribution, pt 2 of 2 7:51 Ian Wimsett, Red Bee Media A presentation by Ian Wimsett given at NAB 2012 What AS-11 DPP Product Certification Means for Your Business 23:33 IBC Panel Discussion

AS-11 AS-11 X5: MXF Program Contribution - DPP UHD Commercials & Promotions ​ This is a Specification in the AS-11 family of Specifications . It defines an MXF file format for the delivery of finished UHD Commercials & Promotions to UK Digital Production Partnership (DPP) broadcasters. ​ See the specification - Full Specification on GitHub ​​ At present, there is no Certification program set up for this specification.

NMOS View the NMOS At A Glance page For a Business Overview (Read Below) For a Technical Overview (start here) To see the Specifications (start here) For the NMOS Wiki (Start Here) BusinessOverview This page provides a non-technical overview of the AMWA’s work to create Networked Media Open Specifications. The information has been provided in the form of Frequently Asked Questions. If you have any further questions, don’t hesitate to Contact Us . ​ Technical information which has been published, is available at https://amwa-tv.github.io/nmos/ ​ What are Networked Media Open Specifications? Who is supporting this initiative? What is the technical basis for the NMOS project? What is the Networked Media Incubator? What are IS-04, IS-05, IS-06, etc? Where can I find technical details of the specifications? How can my company participate? Is there an NMOS compliance / certification process? When will NMOS specifications become standards? ​ What are Networked Media Open Specifications? The Networked Media Open Specifications (NMOS) have been developed for use in IP-based infrastructures to provide a control and management layer in addition to the transport layer provided by SMPTE ST2110. The goal is to provide a means for straightforward interoperability between products from a wide range of manufacturers, in order that end users and service providers can build best-of-breed systems. ​ As in the past, successful sales by a supplier will depend on matching their customer’s needs for functionality. NMOS simply seeks to make the interconnection of products from competing suppliers as simple as possible. ​ The NMOS family of specifications began with projects for Discovery & Registration, Device Connection Management and Network Control. It has grown to include important subjects such as Event & Tally, Audio Channel Mapping and Interoperable Security. Additional working groups become active as new operational / business needs are identified. ​ They are a growing family of specifications which are available to both suppliers and end users, at no cost, to support the development of products and services which work within an open industry framework. Wherever possible, the specifications are being developed using Internet standards or Internet-friendly techniques. Back to the top Who is supporting this initiative?​ The NMOS initiative is supported by the Joint Task Force on Networked Media (JT-NM), comprised of four organisations; the AMWA, EBU, SMPTE and VSF. http://www.jt-nm.org/ The work of the AMWA complements and, in turn, supports the contributions from the other organisations. ​ More than 70 AMWA members, end users and their suppliers, have signed up as participants in this project and are active in the working groups that most directly affect their business. The list ranges from large, multinational suppliers to single person consultancies. The list of end users and suppliers . The JT-NM works closely with the Alliance for IP Media Solutions (AIMS) to provide education and advocacy across our industry. Back to the top What is the technical basis for the NMOS project? In 2015, the JT-NM published a Reference Architecture which describes a conceptual model for interoperability. It is designed for contribution that will allow end users and manufacturers to truly benefit from the cost saving, flexibility and scalability of an Internet-based approach. ​ However, the Joint Task Force did not go as far as working on specifications or encouraging implementations. Instead, they laid out the Reference Architecture and a collection of best practices, leaving it to initiatives such as NMOS and the AMWA Networked Media Incubator project to work out the details and to get implementers together to create interoperable solutions. Back to the top ​ What is the Networked Media Incubator? This is a key project set up to enable the creation of a family of Open Specifications. ​ The Networked Media Incubator project is sponsored by the AMWA to enable open, multi-vendor interoperability in professional media networks. The activity is focused on getting early tangible results by concentrating on specific technical areas through a series of collaborative development activities and facilitating virtual and physical interchanges between system developers. The technical goals of the group are guided by the JT-NM’s Reference Architecture. ​ The Networked Media Incubator (also simply called the "Incubator”) was set up in September 2015 as an “umbrella” project, under which the working groups could operate. The number of working groups has grown steadily and most hold weekly or fortnightly conference calls in addition to technical discussions on the Basecamp project forum. ​ Regular developer workshops take place throughout the year. These are open to any AMWA member which has software to test. The workshops provide a supportive environment where developers share experiences to the mutual benefit of all participants. To encourage openness and discussion, there is strict rule not to speak negatively about any other participant who takes part in a workshop. Back to the top ​ ​ What are IS-04, IS-05, IS-06, etc? These are Interface Specification (IS) identifiers assigned to the NMOS specs. Specifications are formally given an IS number once they reach Specification status. Other supporting specifications may have different numbering, such as "BCP", for Best Current Practice. Details of all specifications can be found by the link at the top of this page. NMOS APIs are built on widely adopted patterns used on the Internet/Web, using open-source components wherever available. Back to the top Where can I find technical details of the specifications? An overview can be found at https://amwa-tv.github.io/nmos/ with more detailed documentation starting at https://github.com/AMWA-TV/ . ​ NMOS specifications are made publicly available (Apache 2 licence) as early as is practical, and at the latest on elevation to AMWA Specification. Note that some specifications are in private repos in their early stages. These are accessible to AMWA NMOS participants (if you are a member who needs access, please contact the Incubator or activity lead). ​ As well as proprietary implementations, several open-source implementations of IS-04 and IS-05 are available. These are available via the first link above. At the time of writing, they all use the Apache 2.0 license, which matches the NMOS specifications themselves. If you have an implementation you would like added, please create an issue against this repository indicating where it is available from. Back to the top ​ ​ How can my company participate? Any company can join this work by becoming a member of the AMWA and signing the Rules document **. Membership provides access to all current NMOS projects and a shared IPR framework through the AMWA’s IPR policy. ​ There are three company membership levels plus an individual membership. Details of the range of membership benefits are available via the JOIN button at the top of this page. If you have questions of any sort, please use the CONTACT button above. Please note that the NMOS Incubator project is "RAND-Z" so it requires any contributions to be made available on a reasonable and non-discriminatory basis at zero cost. ​ ** The Rules document exists simply to support open, honest communication and ensure that no participant speaks negatively about a competitor following discussions and / or developer workshops. Back to the top Is there an NMOS compliance / certification process? At present, there are interoperability checklists at workshops and in preparation for public demonstrations but these are for use for testing by suppliers and do not let vendors formally claim compliance. ​ The AMWA does not currently provide a certification process for NMOS implementations. Back to the top When will NMOS specifications become standards? Development of an Interface Specification reaches a point where it is sufficiently advanced to be formally elevated to an “AMWA Specification”. ​ However, further versions of NMOS specifications are likely, for example, to support the additional requirements of newer, later specifications. Also, as the professional networked media industry matures we can expect end user requirements to evolve so, although individual versions will become “Stable” and widely implemented, NMOS will not stand still. ​ This need to accommodate evolving end user requirements does not allow as easy fit with the traditional standards processes which have worked so well for transport streams such as SMPTE ST2110. Back to the top ​ ​ ​ NMOSfaq1 NMOSfaq2 NMOSfaq3 NMOSfaq4 NMOSfaq5 NMOSfaq6 NMOSfaq7 NMOSfaq8 NMOSfaq9

White Papers & Reference Documents NETWORKED MEDIA OPEN SPECIFICATIONS (NMOS) Networked Media Systems - The Big Picture (528kb) Pebble - Navigating from SDI to IP (11.8Mb) ​ AGILE MEDIA Live Cloud Requirements (pdf) Agile Media Blueprint (AMB) Discussion Document (pdf, 1.58Mb) ​ MATERIAL EXCHANGE FORMAT (MXF) A Quick Tour of Wrappers and MXF (pdf, 651k) The AMWA Family of Application Specifications for MXF (pdf, 298k) AAF to Application Specifications: How They Fit An Advanced Media Workflow (pdf, 123k) Quick Introduction to MXF AS02 and AS03 (pdf, 944k) Business Drivers for AS02 and AS03 (pdf, 691k) MXF: Joined-Up Workflows & Business Efficiencies (pdf, 414k) Accelerating Standards Development (pdf, 269k) Avid Viewpoint: The Promise of AS-02 (pdf, 223k) MXF for Program Contribution, AS-11 (pdf, 533k) The Life of a Commercial, AS-12 provides solutions to the problems that arise in existing workflows (pdf, 372k) Are Fully Digital Workflows A Pipe Dream? (pdf, 295k) Smooth Asset Workflows, Bigfoot, and UFOs (pdf, 888k) The pipe dream becomes real: Advertising workflows have come of age (pdf, 523k) Encoding Data into MXF files: BER and KLV encoding (pdf, 669k) The Structure of an MXF file: The Physical view (pdf, 669k) ​ ADVANCED AUTHORING FORMAT (AAF) "AAF" - EBU Technical Review (pdf, 270k) Enabling Better Media Workflows: An Overview of the Advanced Authoring Format (pdf, 530k) ​ ​

Dodo Reference Manual ​ Dodo .DOD source files are simply a set of macros ​ These macros are expanded differently depending on the macro file used, so the same DOD file can produce both a COM API header and a COM wrapper for the related Impl function with a similar name. ​ Return to Developers In some Macro files a lot of the macros are simply null. Macro Arguments The arguments passed to Macros can be several lines long (especially in the case of comments). Occurrences of ( ) parentheses and , commas in the arguments passed to macro have to be escaped with a backslash. Some macros such as AD_METHOD1 are nested because AD_METHOD1 with 6 arguments invokes AD_XMETHOD1 with an extra argument in the base.mac file, as a result of this, escaped characters in AD_METHOD1 have to be escaped twice, an open parentheses in a comment has to be preceded by three back slashes \\\( . A \ (backslash) character immediately before a newline, indicates a continuation line escaped so that it will not appear in the output. Usage: dodo -f macro_file ​ Expects input .dod file on standard input, writes the expanded output to standard out. The macro files also include the base.mac file which contains common definitions. Some of the macro files are only used once to generate an initial framework for an implementation file, for instance once you have a constructed a .dod file for your interface you can generate a empty implementation with the command: dodo -m macros/cpp.mac < AAFMyInterface.dod Comments ​ The comments for methods and interfaces follow a pretty repetitive format, since they are extracted from the IDL file by the DocJet tool to generate the COMAPI manual it is best to follow the existing style of indentation and line breaks. The macros subdirectory contains the following different variants: All Dodo directives in the macro file start at the beginning of a line, and start with the '#' character. Macro Arguments The arguments passed to a macro are substituted in the body with the notation %n, where n is a digit starting at 1 for the first argument. Comments Dodo comment lines begin with #c Directives the #import directive will include another macro file Macro definitions are delimited with #startm ... #endm Whenever the macro_name() is encountered in the source file, it will be replaced with the multi-line macro expansion in the output file. Special Macros conventionally defined at the top of each dod file .this-module expanded to the class or interface name such as C.this-module and Impl.this-module ​ .parent-module the parent class for public inheritance at the implementation level, used to aggregate the interfaces at the COM API level by importing the methods of the parent. Special Rules Any arguments specified within a macro expansion specification using the %n syntax must have numbers that are 1 or greater, and are less than or equal to the num_args value for that macro. Any macro invocation in the input file must be given precisely the number of arguments given in the num_args field of the macro's definition. ​ ​ ​

Rebuilding Derived headers on Windows ​ This page describes the procedure for running dodo on Windows using the Cygwin GNU tools. It is also possible to build dodo with Visual Studio and the commercial MKS tools running AAF/dodo/makefile rather than AAF/dodo/GNUmakefile. Required tools (all part of cygwin ): Gnu Make C++ compiler Perl Bash Shell0 ​ If you add an extra interface file, you need to follow this procedure: if you don't already have it, checkout the dodoWin module from CVS, this should give you the dodo directory and the extra make files required. create your AAFmyInterface.dod macro file by editing a similar example generate a new UUID for your COM interface add your Implementation and Unit Test for your interface (you can use dodo to manually generate the basic files) add the AAFmyInterface to dodo/aafobjects.mk run GNUmakefile in the dodo directory by simply typing 'make' add the AAFmyInterface.dod macro file to CVS run the midl compiler ?? add the new derived files to CVS ref-impl/src/com-api/: CAAFmyInterface.cpp CAAFmyInterface.h Rebuild the Mac and Win SDKs to copy ref-api headers to their sub-directories (Win build MakeSDK target, Mac run MakeSDK MPW script) CVS checkin all the affected derived files such as ref-impl/include/com-api AAF.idl, AAF.h, AAF_i.c The following table shows the steps that the main Dodo makefile goes through to update the Derived files: Return to Developers GNUmakefile ​ ../build/common.mk determines platform/environment ../build/Pdefs-Win.mk used by common.mk after checking OS type tool/GNUmakefile builds the DODO executable Runs PERL script sync_copyright.pl to update the copyright text in macros/base.mac ​ dodotargets.mak creates a list of DODO targets using aafobjects.mk as the input file and running GenTargets.sh on this to create targets.mk NOTE: new Target *.dod files must be added manually to aafobjects.mk dododepend.mak creates DODO dependency information in its output file depend.mk , using aafobjects.mk as input and running in sequence GenDepend.sh and then GenDepend2.sh on this file. depend.mk included in maketargets.mak to provide the dependencies for the targets. maketargets_gnu.mak where the bulk of the work is done (builds all the targets). Creates all *.idl files using shell scripts: GenAafPrivateIdl.sh GenAafIdl.sh GenPluginIdl.sh Creates various headers (*.h) using shell scripts: GenAafPrivateh.sh GenAafh.sh GenPluginh.sh Creates various *_i.refh files using shell scripts: GenAafPrivate_i.sh GenAaf_i.sh GenPlugin_i.sh Creates AAFClassIds.impl file with GenClassIds.sh Creates AAFClassIds.comh file with GenClassIds.sh Creates AAFObjectTable.comh file with GenObjectTable.sh Creates AAFObjectTable_i.refh file with GenObjectTable_i.sh Creates CAAF*.h and CAAF*.cpp files for each corresponding input *.dod file Uses the Microsoft IDL compiler to generate ref-impl/include/com-api files (only available under Windows NT, it says) Thanks to Dudley Beenham at Sony for tracing out this summary. ​ ​

Defining the business need Developing open specifications Ensuring interoperability Enabling networked media NMOS AT A GLANCE Benefits to end users, vendors and integrators Free downloads and test tools Proven products from a range of suppliers How to specify NMOS in your procurement process And more Advanced Authoring Format A file interchange format designed for the video post-production and authoring. ​ ​ ​ ​ Material Exchange Format AMWA Application Specifications define a set of rules that constrain the MXF standard for a particular application, includes AS-11. ​ Networked Media Open Specifications Networked Media Open Specifications result from the development of interoperable protocols for control and monitoring of media devices in an IP-based environment. Business Agility in Media Workflows ​ A new research initiative to understand the evolving requirements of media companies ​ ​ ​ News AMWA WORKSHOP ON SECURITY IN MEDIA INFRASTRUCTURES. Click through. More Information ​ Developers Brochures White Papers & Reference Documents Videos Newsletter Archive Logos ByLaws, Policy Documents & Licenses Subscribe to our newsletter Liaison Organisations

Contact CONTACT THE ADVANCED MEDIA WORKFLOW ASSOCIATION Location: Advanced Media Workflow Association, Inc. PO Box 1925 Bothell WA 98041 USA Contacts: Tina Lipscomb, Operations Manager Voice: +1 425-870-6574 Email: Tina.Lipscomb@AMWA.tv Neil Dunstan, Director, Membership & Marketing Email: Neil.Dunstan@AMWA.tv Brad Gilmer, Executive Director Email: Brad.Gilmer@AMWA.tv Contact Us Send

Agile Media successful use of "it thinking" in a media environment ​ The media industry is going through a period of rapid change, which shows no sign of slowing down. The use of cloud-based services and storage for acquisition, management and delivery of content promises to offer great flexibility, without the need for traditional investment in specialised media devices. There is currently no quick or easy way to achieve this using open standards or specifications, and careful planning is required to deliver against end users’ needs. The most likely way to meet the demanding and ever-changing requirements of end viewers will be to employ more “IT-Thinking”, employing IT best practices and approaches to our industry, combined with the experience our industry has gained over the years about how best to deliver media to consumers. The AMWA has some resources that may help in this journey. First, there is a presentation by Brad Gilmer on IT Thinking for Professional Media . This highlights core concepts from the IT industry that may help us, as we seek to adapt IT techniques to our industry. Another resource is the Agile Media Blueprint , co-authored by Dr. Richard Cartwright and Brad Gilmer. This document, subtitled, “Creating and monetizing content using the Internet technology platform”, introduces concepts, along with an architectural blueprint that may be used as the basis for “cloud-fit” professional media facilities of the future. ​ AGILE MEDIA WORKFLOWS PRESENTATION ​ Given in the fall of 2019, this presentation provides the chance to learn about steps towards Agile Media Workflows. ​ To ensure that everyone has the same understanding of our goals and how the project would move forward, in the 45 minutes we cover the following topics:- Brief overview of the AMWA; What we are and what we do. Why business agility and agile workflows are a hot topic. What we mean by “agile”, “cloud” and “COTS” in this context. Further industry reading on this subject. AMWA projects and processes / how we work. Conditions to join this project. The next step - discovering and analysing end user’s most urgent needs. ​ Agile Media Workflows Presentation ​

Certification AS-11 DPP AMWA CERTIFICATION AUTHORITY AS-11 DPP ​ What is AS-11 DPP? As the SMPTE standard for MXF gained adoption, around 2012 it was recognised that a specific subset would be valuable to UK broadcasters for the delivery of finished programs. In support of the Digital Production Partnership (DPP), comprising the BBC, Channel Four and ITV, and with the support of Sky and BT Sport, the AMWA developed the DPP subset of AS-11 to constrain the media format and to add the extra metadata required for their workflows. ​ To provide confidence for customers wishing to buy AS-11 compliant products, the DPP set up a Test Lab. In conjunction with this, the AMWA established a Certification authority to authorize the use of logos and grant the rights to manufacturers to make appropriate claims regarding the compliance of their products. Please note - MXF is seen by many as a mature technology and the DPP’s Test Lab and the AMWA Certification Authority are not operating at the present time. ​ What does an AS-11 DPP Certificate mean? The DPP have been very specific in stating what an AS-11 DPP certificate means within the context of their compliance tests. ​ Important Notes about this Certification It is very important that the user reads the Test Report for the product/version they are interested in. The AS-11 UK DPP shim specification hosted by AMWA now also hosts the Rules for Conformance. The Rules for Conformance are used as the final point of reference in cases of discrepancy with the AS-11 specification or ambiguity in the specification. Products are tested against the HD Shim only (at this time), and for the file format only, and so are completely content agnostic. Further details about DPP testing leading to Certification can be found on the DPP website. www.thedpp.com ​ What a Certificate means The capability of a product/version to read and/or write files to “AMWA AS-11 UK DPP” HD Shim (SD Shim files are not yet covered) has been tested by the DPP Compliance Lab and all the tests performed, as documented in the Test Report under the specified operating conditions have either “Passed” or “Passed with Conditions”. What a Certificate does NOT mean All modes and features of the product have been tested. All files produced by a Certified Writer are always fully conformant to the “AMWA AS-11 UK DPP” Shims. All files from Certified Writers will always work correctly with Certified Readers. ​ ​ AMWA AS-11 UK DPP HD – Format Conformance Testing Certificates ​ The table below provides summary information regarding certificates granted by the AMWA CA to manufacturers. Please note that certificates are granted for a specific version of a product (or for products on a continuous release schedule, for a specific product as of a specific date and time), tested against a specific set of DPP test criteria as of a specific date. ​ The DPP test lab issues a test report to vendors who have submitted products for testing. The vendor may then choose to submit that test report to the AMWA CA in order to obtain a certificate. The DPP test report may be downloaded by clicking on the test report corresponding to the product in the table below. ​ OEM Prod. Name Prod. Version Report Date Issue Date Cert. ID Test Results Report Contact Avid Technology Media Composer MC 7.0.4.1 + AMA AS-11 v.1.0.3 plugin 12-Nov-14 25-Dec-14 R1010 Pass Randy Martens Prime Focus Technologies Clear Media ERP Version 08 Feb 2017 8-Feb-17 1-Aug-17 R3001 Pass Vimalesh Melwani Rohde & Schwarz Clipster 5.1 23-Mar-15 22-Jun-15 R1019 Pass Jennis Meyer-Spradow Rohde & Schwarz Venice Venice3.2.0.34 27-Mar-15 22-Jun-15 R1023 Pass Jennis Meyer-Spradow Sony Corporation Catalyst Browse/ Catalyst Prepare 2016.3 27-Jan-17 5-Nov-17 R3002 Pass Keiichiro Miyakawa Sony Corporation Catalyst Edit 2016.3 27-Jan-17 5-Nov-17 R3002 Pass Keiichiro Miyakawa Tedial Tarsys MAM 23-Feb-15 11-Mar-15 R1011 Pass Julian Fernandez-Campon Telestream Switch 1.1 9-Sep-14 13-Sep-14 R1002 Pass John Pallett Telestream Vantage 6.3 9-Sep-14 13-Sep-14 R1001 Pass with Conditions John Pallett Venera Technology, Inc. Pulsar 6.3.1.35 30-Aug-20 30-Aug-20 R5001 Pass Fereidoon Khosravi Vidcheck, Ltd. Vidchecker/Vidfixer (Vidchecker capabilities) 6.2.7 17-Mar-15 19-Mar-15 R1017 Pass Simon Begent

AS-11 AS-11 X6: MXF Program Contribution - DPP HD Commercials & Promotions ​ This is a Specification in the AS-11 family of Specifications . It defines an MXF file format for the delivery of finished HD Commercials & Promotions to UK Digital Production Partnership (DPP) broadcasters. ​ See the specification - Full Specification on GitHub ​ At present, there is no Certification program set up for this specification.

Join AMWA - General Membership Online Application for AMWA General Membership Please complete and submit the online application below for membership to the Advanced Media Workflow Association (AMWA). Membership rights and privileges will commence when AMWA has received full payment of membership fees. ​ If you prefer, download the membership form (PDF) and send a scanned file to info@AMWA.tv *Preferred Invoice Billing Cycle ​ Payment of Fees Invoice Amount: $5,200 Payment Method: You will be invoiced for membership dues. ​ Acknowledgement * I agree to the payment of fees for AMWA Principal membership. (For future marketing purposes, provide the name of the person and/or company who referred you for membership.) ​ Applicant Authorization By clicking the "Submit" button below, the applicant acknowledges and agrees that, when accepted by AMWA, this application represents a binding contract between the parties. More specifically, by clicking the "Submit" button, the Applicant: Certifies that it meets the conditions of Membership specified in the By-laws. Commits to (i) payment of annual membership dues and fees as determined from time to time by the Board of Directors and (ii) comply with all the terms and conditions of AMWA Certificate of Incorporation, By-laws, Intellectual Property Rights Policy (the applicant hereby acknowledging its review of these documents which can be found on the Bylaws, Policy Documents & Licenses page) and such other rules and policies as the Board of Directors and/or committees may from time to time adopt. Acknowledges that the AMWA has elected to avail itself of certain protections offered by the National Cooperative Research and Production Act of 1993, as amended, which requires disclosure of the names of all members of AMWA, and hereby appoints such person who shall be the Executive Director or acting Executive Director of AMWA as the undersigned's true and lawful attorney-in-fact and authorizes him or her to: ​ Notify government agencies of the undersigned's membership in AMWA, make, approve the form of, execute and deliver filings with government agencies on behalf of AMWA and on behalf of the undersigned as a member of AMWA, receive notifications, including without limitation, notifications pursuant to the National Cooperative Research and Production Act on behalf of AMWA and on behalf of the undersigned as a member of AMWA, and authorize and direct other officers of, and/or counsel to AMWA, to do any of the foregoing acts. * I have read and accept the applicant authorization terms Submit Your Application

Dodo and its place in the Evolution of AAF Dodo is a Macro processor written specifically for the AAF SDK, dodo is just a C++ program it'll run anywhere. The makefiles for executing dodo are GNUmakefiles. It performs a function similar to MIDL in the Windows environment and generates header and wrapper files for different compilers and layers of the code. A large number of the core source files for the SDK are in fact derived rather than original. This is to overcome differences in Compiler syntax on the various platforms as well as to support an abstract Data Model layer and a COM API on top. Since the generated files are checked in to SourceForge you don't need to run dodo unless you are adding a new interface (you aren't allowed to change existing interfaces) or changing the generated code (in a compatible way) e.g. updating a comment. The main derived files are shown in the following diagram: all of the ref-impl/src/com-api wrappers and particular files: ref-impl/src/impl/ImplAAFRoot.cpp and ImplAAFRoot.h The AAF.h and AAF.idl files are effectively made by concatenating all the individual interface header files into one. The AAF COM API manual is automatically generated from the AAF.idl file. the AAF.h files in the Platform-specific directories The derived files all have the word GENERATED in the initial comment and license info. Although nobody can stop you adding new interfaces to the local include directory of your particular SDK while developing and debugging new code, at some stage of the checkin process you will have to go further back up the evolutionary chain and generate a Dodo file for your interface so that it can be used under all the supported platform variants of the SDK. The AAF/dodo directoryn is not part of the standard platform modules checked out of CVS. You will need to specifically checkout dodo with a cvs co dodo command either at the top level (in the directory above AAF) or in the AAF directory itself. ​ Adding Interfaces ​ You cannot extend individual interfaces, rule number one of the COM-style interface is Invariance of interface you can however extend the API by adding new interfaces. You may not remove or change existing interfaces, this is in order to maintain compatibility of older applications with newer libraries. When a new interface is added it gets a new IID, only the new applications know that they can successfully QueryInterface() for that new IID. The new interface does not respond to both the new and the old UUIDs, it would break binary compatibility to get the new interface in response to a QI() for the old one. Typically new interfaces are interfaces to new functionality, However, there's a common special case of adding a new interface to existing functionality. Let's say I have (in no particular syntax) interface foo { method a(); method b(); .. lots of methods ... method p(); method q(); } But you want to add an r() method. You could address this by adding the following new interface: interface foo1 { method r(); // only } foo1 has a different IID than foo . However new clients would have to use both foo and foo1 . Another way I could address this would be to add the following new interface: interface fooEx { method a(); method b(); .. lots of methods ... method p(); method q(); method r (); } fooEx has the same methods as foo except with the addition of r(). This way new clients can ignore foo and only use fooEx . Note that, just as for foo1 , fooEx has a different IID than foo. For the convenience of new clients we've repeated all the methods of foo (at least the ones we didn't want to change) in fooEx . Now since foo and fooEx are very similar interfaces we can (and probably should in AAF) have foo and fooEx share the same implementation. Note that this is an issue for implementors, not for clients, and is a different concept than having "the new interface respond to both the new and the old UUIDs". For an example of how this is done in AAF see interface IAAFTypeDefVariableArray and interface IAAFTypeDefVariableArrayEx . The naming convention seems to be foo fooEx fooEx1 ... With Dodo you make fooEx.dod by copying foo.dod , giving it a new IID, and modifying it. If you want to share implementations, dodo knows, if you tell it, how to have an implementation support more than one interface, again see IAAFTypeDefVariableArray and IAAFTypeDefVariableArrayEx . Dodo also knows how to have the same interface supported by more that one implementation, see IAAFEndian . Rebuilding Derived Headers For specific information on running Dodo see the preliminary Dodo Reference Manual or the platfrom-specific make instructions for a Dodo Make . ​ ​ Return to Developers

AS-11 AS-11 UK DPP SD: MXF Program Contribution – UK DPP SD This is a Specification in the AS-11 family of Specifications . It defines an MXF file format for the delivery of finished SD programs to UK Digital Production Partnership (DPP) broadcasters. ​ See the specification - Full Specification on GitHub ​ AS-11 DPP Certification: Certification Authority – AS-11 DPP AS-11 DPP Certificates This rules based Specification supersedes the original defined in a PDF document, with no material differences. ​

There’s Nothing Here... We can’t find the page you’re looking for. Check the URL, or head back home. Go Home