Strengthen requirements on SDP format specific parameters?

[garethsb]

At the moment, we require only that the SDP files used with BCP-006-01 MUST comply with the requirements of RFC 9134.

However that spec requires very few format specific parameters, just packetmode (and effectively transmode in that it implies a default when omitted).

That means a Receiver has potentially very little information to decide whether to reject an IS-05 PATCH request.

This differs considerably from e.g. ST 2110-20 SDP requirements for video/raw in which the majority of the format specific parameters are required (or imply a default when omitted).

BCP-006-01 already requires the similar information is present on the Flow, but that isn't provided to a Receiver, only the SDP file.

Therefore should BCP-006-01 "strongly RECOMMEND" or even "REQUIRE" that these format specific parameters are included (a) on the Sender's SDP file, and/or (b) SDP files provided by a Controller in a PATCH request to a Receiver?

• profile, level, sublevel, sampling, depth, width, height, exactframerate, colorimetry (and effectively interlace and segmented)

[pedro-alves-ferreira]

As always, I'd rather say "REQUIRE" and the only reason I have second thoughts about that is when a device is a proxy of a non-NMOS device or a gateway that cannot really get that information without actually parsing the stream. Therefore, I lean towards "strongly RECOMMEND", although I know that means close to nothing in terms of increasing interoperability.

[garethsb]

Summarizing a Slack conversation with @alabou: One issue is whether NMOS should venture at all in adding requirements about the content of SDP transport file. However, in this case we're only talking about making REQUIRED the RFC 9134 OPTIONAL parameters on Senders' /transportfile (and manifest_href) and not inventing any new ones. The suggested list of parameters covers those that ST 2110-20 requires for video/raw plus those that constrain the compression format. Receivers need to be able to be connected using SDP files for non-BCP-006-01 compliant Senders/streams, so we must not require these parameters in PATCH /staged.

[alabou]

Would it be enough to state the NMOS guiding principle as "SDP transport file parameters that correspond to/derive from the REQUIRED Flow properties SHALL be provided in the SDP transport file such that the information provided to an NMOS controller through a Flow is also provided to a Receiver through the SDP transport file". .... or something like this.

This would add profile, level, sublevel, sampling, depth, colorimetry to the REQUIRED SDP transport file parameters for JPEG-XS. Note that segmented and interlace remain optional, as it is for video/raw.

If the criterion is extended to Sender's required properties it would add nothing more for JPEG-XS.

Note that the opposite is not true: a Receiver may receive more information that an NMOS controller would receive ... This will be the case for H.264/H.265 ...

[garethsb]

@alabou I like it! Need to check the details all line up, and decide whether vendors need us to also spell it out, but as a guiding principle this is exactly what I was searching for.

[garethsb]

This would add profile, level, sublevel, sampling, depth, colorimetry to the REQUIRED SDP transport file parameters for JPEG-XS. Note that segmented and interlace remain optional, as it is for video/raw.

You're right, those last two must be omitted to indicate progressive scan, because they are Boolean flags. But if the video is interlaced or PsF they are effectively required. Similarly the Flow interlace_mode is not required since it has a default value of progressive, but is therefore effectively required for any other scan mode.

I think exactframerate should be required according to the principle you expressed as well - Flow grain_rate is optional, but only because it defaults to the Source grain_rate, which is required for periodic Flows such as video.

By the same logic, probably TCS should also be required, since Flow transfer_characteristic is optional but has a default of SDR, so is required for all other systems?

The fact that there is some subtlety here makes me think we need to state your principle AND specify these details in BCP-006-01.

[alabou]

Source grain_rate seems optional to me, even for a periodic source, schema indicate: "Maximum number of Grains per second for Flows derived from this Source. Corresponding Flow Grain rates may override this attribute. Grain rate matches the frame rate for video (see NMOS Content Model). Specified for periodic Sources only." and the property is not required.

[alabou]

My previous comment about the "NMOS guiding principle" was about new BCP-006 specifications. I was not planning to add requirements to pre-existing NMOS formats not covered by BCP-006 or to put requirements to properties that are not new with a BCP-006 document/specification but it is still worth the exercise as you did to look at a larger scope.

[alabou]

"The fact that there is some subtlety here makes me think we need to state your principle AND specify these details in BCP-006-01."

Agreed, BCP-006 documents must be as precise as possible and indicate the general principles in the summary.

[garethsb]

Source grain_rate seems optional to me, even for a periodic source

See https://github.com/AMWA-TV/is-04/issues/124... the "specified for periodic sources only" is interpreted as required for periodic sources, only sources with truly varying grain period should omit this attribute.

[garethsb]

Resolved by #19.