Exact frame rate versus tolerances in mappings

[prince-chrismc]

The mapping in question is urn:x-nmos:cap:format:grain_rate where it currently needs to be the "exact frame rate" to match the Sender/Flow/SDP in NMOS Parameter Register. From ST2110-20

exactframerate Signals the frame rate in frames per second. Integer frame rates shall be signaled as a single decimal number (e.g. “25”) whilst non-integer frame rates shall be signaled as a ratio of two integer decimal numbers separated by a “forward-slash” character (e.g. “30000/1001”), utilizing the numerically smallest numerator value possible.

This can be at odds with base-band/EDID workflows were the tolerance of a pixel clock can skew the grain_rate. There is also the Display Range Limits EDID A2 (section 3.10.3.3) which gives the total possible range of values that could be important.

A Display Range Limits Descriptor (which was required in EDID data structure version 1, revision 3) is optional (but recommended) in EDID data structure version 1, revision 4

❓ Is this information required for interoperability

➡️ Proposed Solution: we can spec the min/max of a rational for grain_rate to include the tolerance

    "urn:x-nmos:cap:format:grain_rate": {
      "enum": [ 
        { "numerator": 2403125, "denominator": 40338 } // 1920 x 1200 @ 60Hz
      ],
      // Expressing the tolerance
      "minimum": { "numerator": 9131875, "denominator": 161352 },
      "maximum": { "numerator": 3364375, "denominator": 53784 }
    },

[garethsb]

For sure, urn:x-nmos:cap:format:grain_rate parameter constraints can use minimum and maximum rather than exact match enum values.

[prince-chrismc]

Ahh! I was too slow editing the comment.

As per our call today, this is a near future item which we need to evaluate when making implementations; When bridging ST2110/IPMX/EDID will this need to be specified?