Should distinguishing info of Inputs and Outputs be PATCHable?

[garethsb]

See https://specs.amwa.tv/is-13 for background and AMWA-TV/is-13#17.

[garethsb]

Use cases were discussed in ARG today.

Some Controllers will (a) not be interested in Inputs and Outputs (because their view of the system stops at network streams/interfaces) and/or will (b) not use any such PATCH API because they manage their own database of names/categories/etc. for Users.

However, it does seem useful at least during commissioning to be able to e.g. associate user-specified distinguishing info with each IS-11 Input or Output, such as the user-friendly name of a display or source it is currently connected to?

[andrewstarks]

I spoke with NIkita, who asked me to look at this. If I understand correctly, the question is: Should IS-11 allow changing info related to inputs and outputs?

My answer is yes. Example:

I run a rental house. I send out video systems in fly packs that my customers use in their productions. Very often, these fly packs are connected up to other equipment, and so these are not strictly self-contained units where everything is used the same way every time. Within the fly pack I have gateway devices that are plugged into a switcher, monitors, HDMI inputs, etc. There is a small "controller" that the user can access, which is included within the fly pack, but this is not always used. This controller speaks NMOS and is what is used to connect inputs and outputs from/to the equipment in this unit.

I want my customer to be able to see, within their NMOS compatible software, the correct labels for the input and output devices that are "behind" the NMOS sender and receiver. That way the "HDMI GREEN LEFT" input will show up on the NMOS node with the same name, even if they are using an NMOS that is not part of the fly pack's controller. The point is, my engineer can change the name to something that makes sense for the fly pack and it shows up on any controller, using that name.

---

Is the above use case is on target for what is being discussed? If so, I can provide other scenarios where knowing the label of the input / output would be useful. Please let me know if that would be helpful.

[N-Nagorny]

@garethsb, I see that IS-13 currently goes the way of /node base path. Is it a subject to change in future or we can assume that /streamcompatibility base path may be added there as well?

[garethsb]

@garethsb, I see that IS-13 currently goes the way of /node base path. Is it a subject to change in future or we can assume that /streamcompatibility base path may be added there as well?

IS-13 is of course still work in progress... Yes, the /node base path has currently been added with the idea that other API base paths could be added later... But, that would require a new version of IS-13, and it is also not clear how to handle Node services-discovered APIs vs Device controls-discovered APIs. I.e. if Annotation API is a Node service, how should it be used with Device control APIs of which there may be many per Node.

There is also still discussion as to whether a Registry-based API would better serve the industry.

[garethsb]

Is the above use case is on target for what is being discussed? If so, I can provide other scenarios where knowing the label of the input / output would be useful. Please let me know if that would be helpful.

I think so. It would be good to document these and discuss in the activity group.

Should IS-11 allow changing info related to inputs and outputs?

The decision for the activity group is then whether to add e.g. PATCH method to endpoints in the Stream Compatibility Management API or whether to push this off to another API.

[N-Nagorny]

June 26, 2023 call: agreed to postpone adding these PATCH method after IS-11 1.0 release.