AMWA-TV/is-11

Time between passing EDID to HDMI Source and InfoFrame change is unknown

N-Nagorny opened this issue · 6 comments

N-Nagorny commented

Now PUT /senders/{senderId}/media-profiles is an atomic operation which immediately returns a response showing whether Media Profiles were applied successfully. In terms of HDMI it's needed to build an EDID from Media Profiles and pass it to HDMI Source. Then it changes video format and notifies about it with a new InfoFrame. The problem is that we don’t know time between passing EDID to HDMI Source and new InfoFrame appearance which may lead us to another PUTting approach.

A possible solution is prohibiting PUTting while streaming for implementations which can't handle such change on the fly. In this case PUT response code is 202 instead of 200 which means the change wasn't applied immediately and Controller needs to wait for a Flow change. After the change Controller GETs /senders/{senderId}/media-profiles (whether it's 205).

prince-chrismc commented

In terms of HDMI it's needed to build an EDID from Media Profiles and pass it to HDMI Source. Then it changes video format and notifies about it with a new InfoFrame. The problem is that we don’t know time between passing EDID to HDMI Source and new InfoFrame appearance

Having spoken in depth on the subject, it seems the operations is always asynchronous so perhaps a 202 Accepted is the appropriate solution.

  • Media Profiles take effect immediately
  • Sender changes it's flow (following the 205 Reset Content if needed) when the source completes

The added work is controller need to monitor for sender/flow changes, this is similar to IS-05 and is partly covered in IS-11 "Client behavior"

  • 👍1
N-Nagorny commented

Unfortunately, we have to take into account both the synchronous and the asynchronous approaches until we figured out if the timeout between HPD high and HDMI Source waking up saves the current spec.
The asynchronous approach we discussed on the call is avaliable on Basecamp but it changes the API crucially. I went through the reasons we came to this approach and prepared minimal changes to the existing spec to make it asynchronous.

GET /media-profiles returns an empty array by default which means IS-11 is inactive. From putting Media Profiles for the first time until deleting them it returns the last put Media Profiles.
PUT /media-profiles returns success code if new EDID is prepared for an HDMI Source and passed to it.
DELETE /media-profiles turns IS-11 off.
GET /status returns Inactive after the last DELETE and if Media Profiles were never put ever. It returns Active if there are Media Profiles put and Flow follows them. It also returns Out of Media Profiles and Flow is absent.

If HDMI Source goes offline, Flow disappears and flow_id of Sender becomes null.
If HDMI Source goes online, Flow appears back and flow_id of Sender takes the Flow's id.

If Flow goes out of Media Profiles while streaming, Node stops the stream.

Controller can PUT /media-profiles anyway there is or is not stream.
IS-05 returns 500 on activating master_enable if Flow is out of Media Profiles.
IS-05 allows to connect Sender with flow_id equal to null.

prince-chrismc commented

Does it make sense to wait some short time for HDMI Source awakening after 13?

So after some long discussions, there has to be a delay between 13 and 14, however there's no way to characterize it.
The example we have is "the HDP high can arrive monday and the timing change tuesday without contradicting any spec"
➡️ This does not save the synchronous spec sadly.

The idea I've been playing with is "only synchronous + disable on timeout" diagram

One a PUT either

  • the source will have changed timing in the Media Profiles (200 OK scenario) or more generally meets the required formats (nothing changing could be normal.
  • the device will not be able to support the request (422 Unable to process)
  • the source did not response (504 Gateway Timeout case)
    1. Here we can disable IS-11, "I tried but failed", next time the operator looks "oh its off, let me correct that"
    2. Or we might accept the Media Profiles and disable the streams (which gets us to the IS-05 500 scenario we liked)

The reason I am suggesting turning IS-11 off is because the source can always eventually come back and change.

For the second option, once a 504 is return... devices MAY enable streaming once the Source/Flow meet the media profile.
It sounds reasonable, it was programmed to work in that mode and left like that so perhaps the operator manually fixed something? However it seems to introduce some risks.

The original JT-NM model declared senders have 1 flow, which has cause interoperability problems in the past, so I am cautions about deleting flows like that.
It does provided another way indicating that however and the same logic could be applied on the Sender. If there is no source there is no sender? Then doing a GET would return 404 and the controller knows something went wrong?

N-Nagorny commented

GET /media-profiles returns [] if never activated or last Media Profiles put otherwise.

GET /status
Inactive - returned after the last DELETE and if Media Profiles were never put ever.
Active - if there are Media Profiles put and Flow follows them.
Out of Media Profiles - if there are Media Profiles put and Flow doesn't follow them.
Flow is absent - if there are Media Profiles put and Flow doesn't exist.

  1. The physical source disappears.
    The Flow disappears, Sender's flow_id becomes null.
    GET /status returns Inactive if never activated or Flow is absent otherwise.
    PUT /media-profiles returns Flow is absent, IS-11 state (Active/Inactive) stays the same.
    IS-05 connection is kept if existed and can be made if not.
  2. The physical source appears.
    A new Flow appears, Sender's flow_id becomes equal to Flow's ID.
    See 3.
  3. Source and/or Flow change so that they don't match Media Profiles.
    GET /status returns Out of Media Profiles.
    If there's an IS-05 connection, Node breaks it.
    IS-05 doesn't allow to make a new connection.
N-Nagorny commented

It's covered with Sener Status.