Receivers supporting multiple formats

[matthewdicken]

What is the best practice is for advertising receivers on a device that can accept both ST 2110-20 and ST 2022-6 streams? The AMWA schemas appear to separate "video/raw" and "video/SMPTE2022-6" media_types into the "video" and "mux" format types respectively. Since a receiver can only be of one format at a time, how should the device's resources be advertised? Two separate receivers, only one of which can be in use at any time? Or could "SMPTE2022-6" be included in the list of media_types under the "video" format? Ideally it should be possible at any point in time to route either a 2022-6 or 2110-20 sender to this receiver.

[garethsb]

See AMWA Workshops Slack thread https://amwaworkshops.slack.com/archives/C0379EM7DND/p1685451575627929?thread_ts=1685451575.627929&cid=C0379EM7DND. On @AMWA-TV/nmos-architecture-review backlog.

[garethsb]

Summarizing initial ARG input:

• As it stands, the format of a Receiver is fixed, so you can't define one Receiver that accepts both ST 2110-20 and ST 2022-6. I don't think it's right to put video/SMPTE2022-6 media type on a urn:x-nmos:format:video format Receiver. But as you say, having two Receivers only one of which can be active/enabled at once, without any metadata that declares that, also seems problematic. You could go a step further, start with two Receivers and delete the other one when either is activated with master_enable true, and recreate it when the first is disabled. But it doesn't seem very satisfactory.
• I'll raise with NMOS Architecture Review group, but input very welcome. FWIW, we have other Device resource-constraints issues on the backlog, e.g. similar cases where a Device can have either a Sender or a Receiver, or can have 4 x HD Senders or 1 x UHD Senders.

[peterbrightwell]

Architecture Review Group review: place on backlog