Creating a media_profile from receiver capabilities information might require schema adjustments
cristian-recoseanu opened this issue · 4 comments
Most properties mentioned in the media_profile schema seem to have counterparts in the receiver capabilities register (NMOS Capabilities - Register).
The issue with media_type was already raised in another issue here: #9
The other two I am worried about are:
- components
- channels
Components
In terms of components the NMOS Capabilities - Register counterpart is urn:x-nmos:cap:format:color_sampling and the suggestion is to be first retrieved from the SDP attribute ‘a=fmtp:’ format-specific parameter ‘sampling’.
Note this parameter is defined as a simple enum Color (sub-)sampling so my inclination would be to modify the schema to allow for this value to be set in the media_profile in this fashion (using one of the values in the enum) and maybe even change the name to match the parameter in the NMOS Capabilities - Register (color_sampling)
Channels
As far as I can tell the NMOS Capabilities - Register counterpart is urn:x-nmos:cap:format:channel_count. Now this is not compatible with the current schema requirement for the channels property in the media_profile so this is impossible to fill in as of right now. My suggestion would be to change this to a channel_count parameter which only requires the count.
It makes sense but slices possibilities a bit (a user may take channel symbols from the raw EDID and put them to channels along with the channel count). I think we need to determine how this slicing is critical for the activity user stories.
I would like some more guidance on those uses cases. If we identify that some of them can be retrieved from sources other than receiver capabilities those need to be highlighted and maybe for those we can make multiple variants of properties (e.g. one can set just the channel count and one more details about the channels). This would give us a better chance of interoperability.
These parameters, in part, are covered in the BCP
urn:x-nmos:cap:format:color_samplingis noted hereurn:x-nmos:cap:format:channel_countis described here
So it would make sense to include them in the API as well 🤔
I would say the audio channel mapping is beyond our current scope but as Andy point out it's an important topic in the near future.
I think it's fair to summarize we need user stories before we can tackle that topic.
Is it acceptable to leave it "undocumented" and thus unsupported?