search

AMWA-TV / bcp-004-01

AMWA BCP-004-01 NMOS Receiver Capabilities
https://specs.amwa.tv/bcp-004-01
Apache License 2.0
1 stars 2 forks source link

Preference metadata schema #9

Closed garethsb closed 4 years ago

garethsb commented 4 years ago

Adds schema for #8 on top of label and core constraints schemas of #6.

garethsb commented 4 years ago

Rebased without most of #6 following discussion in 2-Nov-2020 meeting to approve only the meta attributes to be included in the spec itself (see https://github.com/AMWA-TV/nmos-receiver-capabilities/issues/5#issuecomment-720544547)

jasperpeeters commented 4 years ago

Something regarding preference came into my mind today. While the constraint_sets is an array - do we want to ignore the ability that we technically could sort our preferred sets? E.g. Sorting the sets by their preference-value? If a controller whishes it could partially decode the constraint and immediately stops when it finds a match on the top, knowing the following are lower rated anyways?

garethsb commented 4 years ago

Interesting... We'd have to make that a "MUST" requirement for that to be useful. And the controller most likely needs to have parsed the entire JSON in order to extract the array, so I'm not sure how useful it would be in practice. A controller should probably make two passes through the list to rule out "meta:enabled": false and order by "meta:preference", before evaluating the constraint sets.

jasperpeeters commented 4 years ago

And the controller most likely needs to have parsed the entire JSON in order to extract the array

Yes, but it does not have to re-check multiple times if the first (= best) match was already OK.

IMO this just saves a couple extra steps / checks for not quite a small effort. As a receiver you only have to sort your stuff before putting it into the array.

garethsb commented 4 years ago

In the spirit of being "liberal in what you accept, and conservative in what you send", I suspect that putting the onus on Controllers is simplest to ensure the right behaviour.

We have already recommended Controllers MAY check the version (updated by PR #11), and pre-filtering on meta:enabled (added by PR #12) and pre-sorting on meta:preference also makes sense, before re-evaluating any Constraint Sets.

A real system could involve thousands of Senders and Receivers, so scalable Controllers are likely to maintain their own data structures for the results of Constraint Set evaluation, rather than perform NSenders * NReceivers evaluations directly.

jasperpeeters commented 4 years ago

Hm, I'm not really sure if that principle (although I support it) should be used as an hard argument pro / contra something while defining technical details. In the end, it is about the behavior and if you really want to be that liberal, a controller later on can ignore the fact that the array should be sorted and check the preference values by itself neglecting the order.

The fact that the sets have to be sorted in the array by their preference value would be a very easy thing to test with the testsuite. What will happen if it's not sorted correctly? You can figure it out quickly with the testsuite, and during production the controller might use / apply a less-preferred (but working!) sender / configuration, or has a couple repeated checks more (which we would have always in the case of having an unsorted array). Of course, the latter is not ideal, but when we require sorted sets, the error here is clearly on the receiver side, not the controller.

Don't get me wrong, it is ok for me to not require a sorted constraint_sets-array. It just feels wrong for me to ignore the fact that the array is on its own already sorted and we are putting some prio-values in it in a mixed order...

garethsb commented 4 years ago

I think I understand your argument and I agree it has merit.

We would probably need to specify whether meta:enabled should also influence the sort order, and to draw attention to the fact that constraint sets without meta:preference should be sorted 'in the middle' (after sets with positive values, with sets that have explicit 0, before ones with negative values). Receivers would have to re-sort the list every time any of these meta values changed by a reconfiguration. Which, as you say, didn't ought to be hard for the Receiver, but it is an area that would be hard to test.

Several constraint sets could have the same meta:preference value, which a Controller may wish to consider all together?

In the future, might there be another meta value that would also be useful to sort on?