Networked Media Open Specifications

AMWA BCP-005-01: EDID to NMOS Receiver Capabilities Mapping [Work In Progress]


Extended Display Identification Data (EDID) is a metadata format for an apparatus to describe its capabilities as a video source (e.g. graphics card or set-top box). The data format is defined by a standard published by the Video Electronics Standards Association (VESA). This document is targeted against E-EDID A2 which consist of EDID 1.4 (and covers EDID 1.3) and is referred to as Base EDID and the CTA-861-G Extension Block imposed by HDMI. The information present in the EDID is subject to the requirements of the Display Monitor Timing (DMT) specification Version 1 Rev 12.

BCP-004-01 Receiver Capabilities defined a methodology for describing the Receivers with constraints on the properties of streams which related to IS-04 Senders. This is used to populate Receiver Capabilities for use with IS-11 Sink Metadata Processing.


This document provides Best Current Practice guidelines for how to implement a mapping of EDID fields to Receiver Capabilities in order to have a specific way of representing an EDID Sink’s Device through an associated IS-04 Receiver.

Use of Normative Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Normative References

These appear at the end of the Markdown source for this document, and are referenced as hyperlinks within the main body.


See also the NMOS Glossary, and definitions within RFCs.

Gateway Device

A device which encapsulates a digital video or/and audio signal (usually, from a physical connection) into IP packets. Conversely, the device MAY perform the reverse operation for IP packets to a digital signal.


A media consuming unit described by an EDID which can be associated to a Receiver.


Gateway Devices which bridge a NMOS Receiver to baseband connection need to expose the capabilities of the baseband interface through the NMOS resource to enable connection management. This can be obtained by mapping a Sink’s EDID to a Receiver’s Capabilities and factoring the abilities of the Gateway Device.

The mapping is affected when a Gateway Device is:

The Gateway Device SHALL include any types of conversion, omit any restrictions, or reflect the internal processing in the capabilities of the Receiver.

Video Receivers

If an IS-04 Video Receiver is associated with a Sink which has EDID, its supported video formats MUST be mapped into Receiver’s Capabilities according to the rules below.

Video Timings

Video timings, described in E-EDID, provide information about the video frame size and rate. There are multiple blocks which keep information about timings each with their own mapping requirements.

Each video timing SHOULD be present in the Receiver’s Capabilities as a Constraint Set with a non-empty

The timing descriptors MAY include one or more of the following mappings:

Video timings with Reduced Blanking MAY be determined by the exact urn:x-nmos:cap:format:grain_rate.

Established Timings I, II & III

Each Established Timing is an ID associated with a predefined frame width, height and rate and interlace mode. Mapping the first two types are defined in E-EDID section 3.8 and the last in E-EDID section

Example: Established Timings I & II For example, given the three bytes of Established Timings I & II were `20 08 00` then the receiver capabilies could contain the following in its constraint sets ```json [ { "urn:x-nmos:cap:format:frame_width": { "enum": [ 640 ] }, "urn:x-nmos:cap:format:frame_height": { "enum": [ 480 ] }, "urn:x-nmos:cap:format:interlace_mode": { "enum": [ "progressive" ] }, "urn:x-nmos:cap:format:grain_rate": { "enum": [ { "numerator": 60 } ] } }, { "urn:x-nmos:cap:format:frame_width": { "enum": [ 1024 ] }, "urn:x-nmos:cap:format:frame_height": { "enum": [ 768 ] }, "urn:x-nmos:cap:format:interlace_mode": { "enum": [ "progressive" ] }, "urn:x-nmos:cap:format:grain_rate": { "enum": [ { "numerator": 60 } ] } } ] ```

Standard Timings

Standard Timing Definitions (STD) format is defined in E-EDID section 3.9. The mapping is as follows:

Additionally, defined in DMT section 1 are the interlace mode for (STD) codes

Example: Standard Timings For example, given the bytes of Standard Timings were `D1 C0 01 01 01 01 01 01 01 01 01 01 01` then the receiver capabilies could contain the following in its constraint sets ```json [ { "urn:x-nmos:cap:format:frame_width": { "enum": [ 1080 ] }, "urn:x-nmos:cap:format:frame_height": { "enum": [ 1920 ] }, "urn:x-nmos:cap:format:interlace_mode": { "enum": [ "progressive" ] }, "urn:x-nmos:cap:format:grain_rate": { "enum": [ { "numerator": 60 } ] } } ] ```

Detailed Timing Descriptors (18 Byte Descriptors)

Defined in E-EDID section 3.10, there are 4 possible descriptors which can be provided. The first, Prefered Timing Mode is an obligation and MUST have a urn:x-nmos:cap:meta:preference value of 100. Any Detailed Timing Descriptors in CTA-861 Extension BLock (section 7.2.1) MUST follow the mapping.

The mapping is defined in section 3.10.2 and is applied as follows:

3 Byte CVT Codes

3 Byte CVT Code structure is defined in E-EDID section

Preferred Vertical Rate united with the frame width and height makes a Constraint Set and SHOULD have a urn:x-nmos:cap:meta:preference value off 50

Each Supported Vertical Rate, except Preferred Vertical Rate, MUST be extracted to a new Constraint Set with the same frame width and height.

DMT Standard Codes & IDs Summary

DMT Codes are used to augment the Standard Timing Descriptors and CVT Codes for some EDID IDs. Extra calcuations are REQUIRED to obtain the exact frame rate as per DMT section 2 and section 4.

Example: DMT Standard Codes For example, the EDID with ID `DMT ID: 45h; Std. 2 Byte Code: (D1, 00)h; CVT 3 Byte Code: (57, 28, 28)h` then the receiver capabilies could contain the following in its constraint sets ```jsonc [ { "urn:x-nmos:cap:format:grain_rate": { "enum": [ { "numerator": 2403125, "denominator": 40338 } // When reduced by GCD of 80 ] } } ] ```

Video Data Block

Video Data Block is defined in CTA-861 section 7.5.1.

It operates with Video Identification Codes (VICs), each of them is associated with a union of frame width, height and rate and interlace mode. This mapping is defined in CTA-861 section 4.1.

Color subsampling

If EDID doesn’t have the CTA-861 Extension Block, color subsampling formats MUST be taken from Base EDID, otherwise from the Extenstion Block.


The origin of supported color subsampling formats in Base EDID is the Feature Support in E-EDID A2 section 3.6.4.

It has one of four possible values:

This value MUST be transformed into urn:x-nmos:cap:format:color_sampling with enum values according to those permitted by the NMOS Parameter Registers - Capabilities section and added to each Constraint Set.

CTA-861 Extension Block

The supported color subsampling formats in the CTA Extension Header (CTA-861 section 7.5) indicates whether the Sink supports YCbCr-4:2:2 and YCbCr-4:4:4 respectively in addition to RGB.

YCbCr 4:2:0 Capability Map Data Block (CTA-861 section 7.5.11) shows which timings support YCbCr-4:2:0 in addition to subsampling formats listed in the CTA Extension Header. These timings MUST contain YCbCr-4:2:0 within the possible values for urn:x-nmos:cap:format:color_sampling with associated Constraint Set.

YCbCr 4:2:0 Video Data Block (CTA-861 section 7.5.10) marks timings as supporting only YCbCr-4:2:0. Constraint Set associated with these timings MUST have urn:x-nmos:cap:format:color_sampling limited to YCbCr-4:2:0.

Audio Receivers

If Basic Audio support bit is active in the CTA Extension Header, audio receiver MUST have Receiver Capabilities.

When no descriptors are provided, the capabilities MUST contain:

Short Audio Descriptors

If there are Short Audio Descriptors (see CTA-861 section 7.5.2), then each of them MUST be transformed into a Constraint Set.