AMWA-TV/is-11

Media Profiles filtering the Sender's EDID may not be sufficient to cover all use cases

prince-chrismc opened this issue · 12 comments

prince-chrismc commented

Reviewing this in in engineering, they brought a concern to my attention

When there's

  1. A Monitor with a wide screen timing (not found to the Sender's EDID)
  2. A number of monitor where is one is more sensitive than the others, such that's it's EDID timing should be used as is (not found to the Sender's EDID)

➡️ In this case, we need to pass the raw EDID of the monitor and applying the media-profiles filtering on this "override" EDID.

Additionally we noted, when a new version of EDID/DisplayID is released and is not known to the device, it would be possible to pass this new EDID via an extended API would be an solution to this problem... Though we would also need to update our BCP(s) in that case.

In order to avoid aggressively changing the source, it would be advantageous to expose everything in one API call.

  • PUT /media-profiles
{
   "edid": "0x129684681...", // null | "auto" return to "initial state" (factory)
   "profiles": [
      {
          // ...
      },
      // ...
   ]
}
N-Nagorny commented

Two possible solutions:

  1. Improve Sink schema to express more necessary info from EDID.
  2. Expand Sender with an endpoint which takes raw EDID (hard to describe exact behavior).

Maybe utilize Sink in addition to Receiver Caps in some way?
Passing raw EDID to sender only in unicast? (it's not transparent)
If accept EDID in Sender, let's have a separate endpoint for this.
How to understand how Receiver modifies a stream on its way from Receiver to Sink?

prince-chrismc commented

I think we all agree ideally we could round trip the EDID but is that achievable? This concept is not new and is used throughout the industry, so what merits does it offer?

1. schema to express more necessary info
Maybe utilize Sink in addition to Receiver Caps

Since the devices covered by IS-11 will almost exclusively be gateway devices (ST2110 <--> HDMI), it does not need to know all the possible settings.
↪️ The desired behavior, today in ProAV, is to let the source adjust it's configuration (color, image size, etc) to the monitor. These settings are not properties of the stream, or NMOS, so the device would not need to change its Flow to transmit different content.

Another use case which limits the feasibility of this is proprietary EDID extensions... If a company makes a HDMI player it could pass extra setting within the EDID to the Monitor... If our devices are used as the Gateways, there's no convincible way for spec that in a schema.

The alternative proposed would required BCP-005-01 to change very frequently, by allowing the raw EDID new EDID feature and/or extension blocks could be "added" to the gateway without require an update and new specification and upgraded controllers.

Lastly, the amount of combinations is already an issue, we have AMWA-TV/bcp-005-01#56 which is just a variant of #44 and we saw this in Pebble's demo... At which point does the media profile become to large for low-powered device to solve for?

2. Expand Sender with an endpoint which takes raw EDID
If accept EDID in Sender, let's have a separate endpoint for this.

Having a separate endpoint greatly complexifies the implementation since it does not know when to signal to the source when to change... ⏬ How does the device know when the controller finished configuring it?

  • Separate endpoint's would require an "activate" command, similar to IS-05 where information can be staged and activated explicitly. IS-08 matches what we have currently and what we'd love to see added.

Having a single endpoint has a few advantages:

  • single step configure and active
  • EDID and Media Profiles are always set in tandem (I thinks it's very explicit this way, no "oh I forgot what was there last time" problems)
  • 🆕 DisplayID is an extension and is transported within an EDID such that this mechanic is durable (with current technologies)
N-Nagorny commented

When there's
1. A Monitor with a wide screen timing (not found to the Sender's EDID)
2. A number of monitor where is one is more sensitive than the others, such that's it's EDID timing should be used as is (not found to the Sender's EDID)

Could you explain these cases in detail please? Does item 1 describe >4K monitors?

I think we all agree ideally we could round trip the EDID but is that achievable?

I think we don't need to cover the whole EDID but read User Stories and provide a common and transparent solution which can use EDID or anything similar as underlying component. From my point of view, proprietary EDID extensions are out of scope. If they describe information covered in BCP-005-01, they are closer to the scope and vendor can stay with IS-11 but handle such extensions itself.

Regarding separate endpoints for Media Profiles and EDID, the idea behind it is proposing two alternative ways to configure Sender. PUT /media-profiles -> Sender's configured, then PUT /edid -> Sender lost its Media Profiles and is configured with the EDID.

Passing raw EDID instead of Media Profiles breaks two use cases:

  1. Multicast connections (What gamma, display_size etc. should Sender choose? How to calculate intersection?)
  2. User's intention when selecting Media Profiles (with the current spec it's possible to build a Controller which presents the intersection of Receivers' operating points with checkboxes to let user choose they want the highest resolution or the least bitrate or anything else).
prince-chrismc commented

Could you explain these cases in detail please?

As a ProAV user.... based on 1

I have connected a source and monitor which is a 16:10 display. The image looks great! 🖼️ I need to connect them over my IPMX network. And setup the following:

is-11-needs-raw-edid

The need for media profiles comes in when I have two different sized screens which need to show the same content.

If I buy a 16:10 capable encoder gateway who's EDID by default includes resolutions for 16:9 (missing the wide 16:10 resolutions) ➡️ Because of the limited nature of an EDID means I am not able to describe all the capabilities of the device.

Assuming a perfect decoder gateway, there's a few spots this can go wrong

  • The Sender rejects the request
  • The Source begins working in a non-native, unpreferred and lower quality manner than is anticipated
  • The Receiver or Sink adds black bars to the sides to compensate for the smaller image

The only way for my installation to work is to "override" the encoders EDID with another one (most sensibly that of the Sink)... Having the flexibility in IS-11 would be hugely advantageous

prince-chrismc commented

Regarding separate endpoints for Media Profiles and EDID, the idea behind it is proposing two alternative ways to configure Sender. PUT /media-profiles -> Sender's configured, then PUT /edid -> Sender lost its Media Profiles and is configured with the EDID.

Without media profiles, we break the use case of having multicast between different monitors as you point out. The workflow in #32 (comment) is just as important with multicast, we still have the need for profiles even with the raw EDID.

↪️ Both the EDID and the Profile covers the largest intersections of use cases

2. User's intention when selecting Media Profiles (with the current spec it's possible to build a Controller which presents the intersection of Receivers' operating points with checkboxes to let user choose they want the highest resolution or the least bitrate or anything else).

Again keeping both is key. The user should (if he so chooses) can select the EDID to which the Media Profiles are applied to. Currently there's an EDID involved between the Source and Sender but the user is completely unaware of what that is.
By exposing it in the API the users could make a better selection in terms of profiles which are relevant.

cristian-recoseanu commented

I have two major points to add to this conversation:

  1. I still think we should leave the /media-profiles endpoint alone and have it as the plug & play way of doing things and add the new EDID file as a separate endpoint. The way I see it you will only use this to adjust particular scenarios when the plug and play behaviour has resulted in sub par results.

  2. I think we need to consider the future viability of having something like raw EDID being passed around. How will this work with DisplayID? Should this new endpoint be a /metadata_file endpoint where we can signal its type via the Content-Type header?

  • 👍1
prince-chrismc commented

From our meeting notes...

Since Media Profiles may be not enough to get what baseband connection would give, /media-profiles could be renamed and have root properties media_profiles (required) and metadatafile (optional). If both are passed, metadatafile is applied to Sender by vendor and then filtered with the Media Profiles.

N-Nagorny commented

We have discussed two options for passing Sink Metadata Binary to Sender:

  1. A separate endpoint with PUT method
  2. /senders/{senderId}/media-profiles expansion

Advantages of option 1 are disadvantages of option 2 and vice versa so let me analyze only one of them.

Pros of the separate endpoint:
a. It separates Sink Metadata Binary and Media Profiles logically and increases flexibility. You can put Profiles and don't want to use the Binary at all. You can put Profiles and adjust video putting Binary then. You can put Binary of a single or main Receiver and then select a desired mode putting Profiles. If error, you know what of them is incorrect even without reading a server response.
b. It lets user PUT Binary without any additional steps (base64 encoding, insertion into JSON) which simplifies implementations and makes processing fail risks lower.

Cons of the separate endpoint:
c. If using Profiles and Binary together is the main use case, then it multiplies work by two.

Also, a question. Does Receiver ID and Sink ID of Binary passed to Sender really matter? Is this bad if Controller puts a Binary from a USB stick as we discussed before?

prince-chrismc commented

To counteract some of the cons for having one endpoint, what if we used PATCH method instead

  • GET Currently active settings
  • PATCH modify the current setting to match this subset of settings (similar to IS-05)

This permits our two most common scenarios.

  • Setting both the EDID and Media Profiles we creating new connections
  • Changing only the Media Profiles when adding/removing Receivers
  • 👍1
N-Nagorny commented

@prince-chrismc, if PATCH implies JSON Patch, then it's not what we wanted for Media Profiles. We choose PUT to overwrite them completely instead of PATCHing them.

prince-chrismc commented

I do not mean JSON Patch the RFC 6902 and application/json-patch+json.

I mean it in a similar way IS-05 describes it

https://specs.amwa.tv/is-05/releases/v1.1.1/APIs/ConnectionAPI.html#body-13
https://specs.amwa.tv/is-05/releases/v1.1.1/docs/2.2._APIs_-_Server_Side_Implementation.html#staged-requests-precedence

Where properties replace one another

Perhaps in our case we just need a line that says "the array of Media Profiles replaces the existing content in it's entirety" or it's for the all the top level properties... I am sure we can add a test to the test-suite for to ensure interoperability there since it's an implementation detail

N-Nagorny commented

It's covered in the API now.