Skip to content

AMWA Increments (IN) Index

AMWA Increments (IN-xxx) record incremental outputs of AMWA activity phases. They may stand on their own or be referenced by other AMWA documents such as the NMOS specifications.

The authoritative machine-readable index is index.yml in the AMWA-TV/in-index repository. New Increments are created via a Pull Request on that repo; see its CONTRIBUTING.md for the process.

Issued Increments

NumberTitleRepositorySiteStatus
IN-001API Requirements – Control of MXL v1.0What does it do?• Defines the functional and non-functional requirements for a control API that manages MXL Readers and Writers in a DMF environment.Why does it matter?• MXL does not define a control API, so documenting requirements will help promote interoperability.How does it work?• Gives requirements for setting paramters and querying status of MXL Writers and Readers.API Requirements – Control of MXL v1.0AMWA-TV/in-001specs.amwa.tv/in-001AMWA Increment
IN-002Time and Identity in the Dynamic Media FacilityWhat does it do?• Defines principles and rules for time alignment and stable media identity within a Dynamic Media Facility (DMF).Why does it matter?• DMF processing is asynchronous, so preserving timing relationships and unique Source and Flow identities is essential for interoperable media workflows.How does it work?• Establishes a common workload time domain, defines the Indexing Time Stamp (ITS), and specifies how timestamps and Source and Flow identities are propagated or changed through Media Functions.Time and Identity in the Dynamic Media FacilityAMWA-TV/in-002specs.amwa.tv/in-002AMWA Increment
IN-003Compute Resource Management Manifest and ExamplesWhat does it do?• Defines a common, platform-agnostic description of the compute, memory, storage, network, and accelerator resources required by a Media Function.• Provides a manifest schema and working examples for expressing those resource requirements in a portable way.• Connects profiling, benchmarking, and deployment workflows into a repeatable CRM process.Why does it matter?• Media Function workloads need predictable resource allocation across heterogeneous infrastructure.• A standardized manifest helps orchestration systems place workloads accurately and validate resource availability.• It enables consistent, interoperable resource declarations across vendor implementations and deployment environments.How does it work?• The repository defines a resource manifest model and example payloads for Media Functions.• It shows how profiling and benchmarking results can be translated into portable declarations of required resources.• The resulting manifests can be consumed by orchestration and deployment systems to validate placement and scheduling decisions.Compute Resource Management Manifest and ExamplesAMWA-TV/in-003specs.amwa.tv/in-003Work In Progress
IN-004Flow Connection Phase 2 Requirements and GapsWhat does it do?• Defines the functional and non-functional requirements for a control API that manages MXL Readers and Writers in a DMF environment.• Builds on IN-001• Identifies gaps for further workWhy does it matter?• MXL does not define a control API, so documenting requirements will help promote interoperability.How does it work?• Gives requirements for setting paramters and querying status of MXL Writers and Readers.Flow Connection Phase 2 Requirements and GapsAMWA-TV/in-004specs.amwa.tv/in-004Work In Progress
IN-005[Timing] Principles of External Signal Ingress for DMF Media WorkloadsWhat does it do?• Defines principles for ingesting external media Signals into a Dynamic Media Facility (DMF) Media Workload and conforming them into usable, time-aligned Flows.• Identifies the timing provenance, metadata, and registry information needed to manage Signals as they enter the Media Workload.Why does it matter?• External Signals may have different frequency and timestamp provenance, so consistent ingress conformance is needed to align media Flows and support interoperable processing.• Clear conformance principles help avoid unnecessary buffering and make timing adjustments traceable.How does it work?• Uses Signal frequency and timestamp provenance, together with the Media Workload clock, to determine how Indexing Time Stamps are created or adjusted.• Applies frame synchronisation or audio sample-rate conversion when required, and records relevant Signal attributes and timing offsets in an ingress registry.[Timing] Principles of External Signal Ingress for DMF Media WorkloadsAMWA-TV/in-005specs.amwa.tv/in-005Work In Progress
IN-006DMF Business User StoriesWhat does it do?• Captures eleven business-oriented user stories covering financial models, deployment options, production tiers, scaling, licensing, portability, and other concerns for Dynamic Media Facilities (DMFs).• Provides common terminology, reference diagrams, and examples such as rate cards to support business discussions about DMF adoption and operation.Why does it matter?• DMF decisions involve more than technical capability: cost, risk, staffing, licensing, support, scalability, and the value of a production all affect the appropriate solution.• A shared set of business perspectives helps technical teams, vendors, producers, and executives compare options and make better-informed deployment decisions.How does it work?• Describes each user story using a role, desired function, business value, objective, and unique requirements.• Examines the financial and technical trade-offs between platforms, production tiers, resource models, and lifecycle options, including how solutions can scale, migrate, or be shut down.DMF Business User StoriesAMWA-TV/in-006specs.amwa.tv/in-006Work In Progress