DO NOT MERGE: Basic extended Receiver caps

[andrewbonney]

Incomplete, but a basic way to extend Receiver caps based upon attributes of Sources/Flows/Senders which they may consume from.

Doesn't currently expose caps for video components, and can't go down to the degree of very specific frame size/rate support (ie. 1920x1080p25@10-bit).

[garethsb]

I assume you're thinking the currently empty schema objects for each of those new caps would be fleshed out, e.g. some of them would be array-of-enum, some of them would be integer?

The different styles of limitation make sense, but the variation makes me wonder whether e.g. "min_frame_width" and "max_frame_width" are always preferable to a "frame_width" which is array-of-enum ([1280, 1920]), or... intake of breath... mini schema that could have any of "minimum", "maximum", "enum"...

[andrewbonney]

Yes, this was mostly just to try and tease out what the most relevant names would be on the caps side of things.

The main reason for avoiding a form of enum was to ensure that very flexible Receivers didn't end up with an enormous caps list. It's debatable how much of a problem this would be in practice.

The mini-schema thing would be an interesting one to investigate. I suspect we could make that compatible with IS-05 constraints etc if useful, subject to the current conflict(s) that the existing Receiver caps definition creates.

[garethsb]

I've run the list of proposed caps by some colleagues, and I think it's looking pretty comprehensive.

The mini-schema thing may be interesting, but I realise we should also consider whether the way we choose to express caps allows an appropriate Query API basic or RQL query to be constructed to return the matching Receivers. Does that make sense? (Broadcast controllers may well do client-side filtering of unfiltered WebSocket-received data, but it'd be great if that wasn't required.)

[andrewbonney]

Additional caps to consider: Whether an audio receiver supports particular packet times (1ms, 125us etc). There are likely other similar constraints which Senders/Receivers expose in this area.

[garethsb]

AMWA-TV/nmos-testing#494 presents a user story for why min and max constraints may not be sufficiently descriptive (in that case, support for 8, 16 or 64 audio channels only).