search

AMWA-TV / bcp-005-01

AMWA BCP-005-01 NMOS EDID to Receiver Capabilities Mapping
https://specs.amwa.tv/bcp-005-01
Apache License 2.0
3 stars 4 forks source link

EDID Policies #34

Closed andrewstarks closed 1 year ago

andrewstarks commented 3 years ago

We may need to consider certain scenarios that involve mismatched capabilities in multicast. This is a cut and paste of a work-in-progress document that I've been working on internally. I've decided to include the entire document (except the part that is discussed in Issue #32). The section that is not background material and is relevant to policy starts with Handling Native Modes in Multicast.

EDID Policy Notes for Default Behavior

EDID, Hot Plug Detect (HPD), and InfoFrames (in HDMI at least) are the primary mechanisms that baseband devices and monitors use to establish an optimal and compatible video flow upon connection. These methods are also used to change video modes, should the device request it, e.g. user changes video modes or the device requires it due to content change or an application request.

IPMX operates on IP networks with uni and multicast flows. This introduces many scenarios that were not contemplated when VESA was designing EDID. Therefore, we must:

Terms

IPMX Source: A device that supports IPMX as a sender. This could be a source device (streaming box, DVD, computer) or an IPMX Gateway between baseband and IPMX.

IPMX Sink: A device that supports IPMX receiving. This could be a monitor, capture device, or an IPMX Gateway between Baseband Sinks and an IPMX system.

Baseband Source: A source that supports HDMI, DisplayPort, DVI, or another baseband signal. In this document, this is the device that is typically plugged into an IPMX Gateway.

Baseband Sink: A monitor or other receiving device that supports HDMI, DisplayPort, DVI, or another baseband signal. In this document, this is the device that is typically plugged into an IPMX gateway.

IPMX Gateway: A device that receives or sends IPMX flows and supports IPMX APIs to represent and support Baseband Sources and Sinks. Specifically, this includes the MPA1000 and ME10.

Baseband Connections (EDID, Normally)

Normally, a baseband connection is one output device sending to one display/sink device and EDID is designed for this scenario:

  1. A cable is plugged into the device and HPD is asserted.
  2. After .2 seconds (?), the EDID binary payload is being requested by the source.
  3. The source reads the EDID file and picks any resolution that is reported to be supported by that file or does not connect.
  4. If a match is made, video and/or audio data starts. This includes InfoFrames, which advertise the format of the video.
  5. The monitor sets its timing to support the video and audio.

Note that the source is the sole decider for what the video should be. The monitor cannot request a specific setting or change what it reports, apart from special circumstances regarding latency, which involves CEC control.

Preferred Timing and the Nominal Case

EDID structures define the first mode listed as preferred or native. In addition, Video Data Blocks may contain one or more Short Video Descriptors (SVDs), which may mark the resolution as native.

Whether it is the first mode or listed as native, each communicates that these video modes will be produced with the best quality on the given display device. Typically, it's expected that the connected source will use one of these modes unless it cannot support it, or the user overrides that choice by selecting a different, yet still compatible mode.

IPMX Connections

For AV over IP generally, and IPMX in particular, there are additional use cases and issues to consider. Most notably, it is more often the case that there is a one-to-many relationship between source and receivers in the IP world. This was always possible with EDID, especially with HDMI distribution amplifiers (DA), but it was never handled well because EDID was not designed to handle DAs and switchers. With IPMX, we intend to give the user more deterministic access and control over how the video profile is selected in scenarios with multiple monitors/sink devices.

Furthermore, since EDID was designed for baseband connections, it does not include all of the relevant information relevant to making a connection. There may be constraints related to the network capabilities of each device, or potentially network bandwidth available between devices. Also, supported codecs (or no codec at all), supported profile codecs, and other similar data are relevant to the connection in the same way as EDID data.

Finally, HDCP support is not represented in EDID but is relevant in the same way as EDID is and should also be included in the information communicated to the sender and receiver.

For IPMX, we need to include all of the relevant data to make a connection, including EDID, and establish reasonable default behaviors so that users of IPMX systems can come to expect a certain behavior in their devices.

What is that behavior?

In 1:1 connections

A connection between a monitor and a source should result in the same resolution being selected, regardless of whether the connection is DisplayPort, HDMI, or IPMX, accepting that each transport is capable of the same set of timing and profiles.

Note: Here and in the following sections, the exact procedure for what happens is grossly oversimplified. The actual process is documented in the AMWA NMOS EDID Connection Management GitHub repository.

  1. The user connects the Source and Display directly, or through IPMX Gateway devices if the Source Device and/or Display Device do not support IPMX. Hereinafter IPMX Source or IPMX Sink
  2. The relevant data from the source is collected and received by an API endpoint on the IPMX Source.
  3. Source makes a selection and starts the video, producing InfoFrames.
  4. InfoFrames are used to create the correct stream profile and the NMOS components are updated (Flow, Sender, ...) (the exact API process is part of the AMWA NMOS EDID Activity group.)
  5. The connection is made or error.

In One to Many connections

When more than one EDID is present, only the modes supported by all EDID representations (XOR) shall be used to determine the set of legal modes.

When no legal modes are possible, an error is returned.

  1. The user connects Source and Displays (more than one).
  2. The relevant data from all sources are collected, XOR’d to a set that supports all IPMX Sinks (Native modes are handled in the way described in the next section)
  3. The IPMX Source receives a constrained set of capabilities.
  4. Source creates InfoFrames and NMOS components are updated.
  5. The connection is made or error.

Handling Native Modes in Multicast

Handling multiple EDID structures with different sets of native modes presents a challenge when multiple monitors of different makes and models are used. There are multiple reasonable approaches to handling some of these scenarios and it's assumed that others may have their own opinions. Some things to consider:

EDID has only one level native. It may be interpreted that the first mode listed is more native than the modes listed in SVDs, but the specification is not defined that way.

Should the best native mode be used, if it's supported by all but is native in only a minority?

Should the majority always win out? What if 20 monitors support 3840 by 2160 natively and one projector supports 4096 x2160 natively?

What if some modes are native to all and some are supported by all, but native to only some?

What if no modes are native to all?

What if no modes are supported by a majority of monitors? (all tied)

Proposed Rules

The following rules shall apply to modes that are supported by all connected monitors:

  1. If all EDID structures support a mode as native, then that mode shall be listed as native.
  2. If some modes are matched as native for all displays, then only those modes should be considered native. For modes that are native for only some displays, they should not be included in the list of native modes.
  3. If no modes match as native for all displays, modes that are supported as native in the majority of monitors should be listed as native.
  4. If there is only a tie, then the highest pixel count should be listed as native. If the modes don’t differ by pixel count, then the highest framerate should be listed as native. If framerate does not differ, then the highest bit-depth. If this is a tie, then the choice is undefined and any mode is acceptable as native.

Adding Monitors to an Existing Multicast Group

When adding monitors to an existing multicast group, there are scenarios that need consideration. Below is a list of scenarios and proposed default actions:

  1. A monitor is added that natively supports the current Flow. a. Add the monitor without resetting the current connection.
  2. A monitor is added that does not support the current Flow. a. Is there an alternate mode that is supported by all? i. Yes. Reset the connection using the new aggregated EDID structure. ii. No. Error and refuse to add the Monitor.
  3. A monitor is added that supports the current connection, but not natively. a. Is the current stream native to the aggregate EDID of the connected displays? i. If yes, then would the new aggregate change what is native and would that change include a mode that is native in the new display?
    1. Yes. Reset the connection.
    2. No. Do not reset the connection. ii. No. Add the monitor without resetting the connection.

Removing Monitors from an Existing Multicast Group

Similar issues arise when removing monitors from a multicast group. In each case, the monitor is removed, but whether or not the connection must be reset is answered:

  1. A monitor is removed and the set of native modes does not change. a. Do not reset the connection.
  2. A monitor is removed and the set of native modes changes. a. Does the current stream match a native mode for the remaining monitors? i. If yes, then does the new aggregate EDID include the current stream in the native set?
    1. Yes. Do not reset.
    2. No. Reset. ii. If no, then does the new aggregate EDID include the current stream in the native set?
    3. Yes. Reset.
    4. No. Do not reset.

Other Capabilities

Beyond the default behavior, the user may wish to force certain behavior. For example, a laptop and a monitor may otherwise negotiate a certain profile, but because a projector is calibrated in a particular way, the user may choose to force a certain timing or video mode using a controller or the gateway's web interface. Also, the above logic might not be ideal in certain scenarios and the user's preferences might be difficult to achieve by manipulating the source.

Depending on the policy established by the IPMX Controller and the connection and disconnection (HPD) events it receives, the controller may do any of the following:

Because it's impossible to guess what may be the "correct" policy, it should be possible to replace the default policy with customized versions and to override policy by specifying profiles or new constraints within the web interface.

andrewstarks commented 3 years ago

Note that the numbering above is kind of confusing in that the deeper levels are not being read correctly

peterbrightwell commented 2 years ago

@andrewstarks What's the current status of this issue (including taking into account recent terminology changes)?

N-Nagorny commented 2 years ago

I went through this text and that's my opinion.

Such baseband scenarios as changing video mode on a source, plugging/unplugging a monitor and video mode negotiation between a source and a monitor are covered in the current text of IS-11.

The Terms are obsolete. All these concepts live under other names now.

Native modes are covered in BCP-005-01. An NMOS Controller works with Constraint Sets and their preferences which is not the same but lets the NMOS Controller to apply Proposed Rules to native modes of a monitor and other modes preferred by a Receiver for some reason.

The bottom line of Handling Native Modes in Multicast as I understood it is that the user says the last word. I believe https://specs.amwa.tv/is-11/branches/v1.0-dev/docs/Behaviour_-_Client_Side.html states the same.

So I think it can be closed but I surely would like to hear what @andrewstarks thinks about it.