amwa-tv / bcp-006-01 Goto Github PK

Before publishing, this needs a careful review of MUST vs. SHOULD, and any conditional conformance language ("if X, the widget MUST do Y").
Also there are one or two sentences which are written as simple facts, "the widget does Z".

Every item of conformance language SHOULD be testable in the NMOS Testing Tool.

The Example SDP file uses TP=2110TPN while SMPTE2110-22 states the value should be either 2110TPNL or 2110TPW.

https://github.com/AMWA-TV/bcp-006-01/blob/v1.0-dev/examples/jpeg-xs.sdp

The Flow bit_rate property links to Bit Rate which is described for jxsv as including IP headers,etc ...

Maybe the description of Bit Rate must define it in the context of Flow and Sender property/capability ...

SORRY, this is probably a non-issue as we are still in a dev branch.

The Flows section currently says:

Nodes implementing IS-04 v1.3 or higher MUST indicate the stream bit rate in the Flow resource using the bit_rate attribute also defined in the Flow Attributes register.
The bit rate value also appears in the SDP file, per RFC 9134.

In fact, putting the bit rate value in the SDP file using the b=AS: application-specific bandwidth line is a requirement of ST 2110-22 (and VSF TR-08), not RFC 9134. So, should the the requirement of the first sentence above be predicated on the Node trying to conform with ST 2110-22?

The spec currently makes ST 2110-22 compliance a MUST. We've been asked whether this NMOS stream mapping would work with vanilla RFC 9134.

I thought we'd be able to distinguish this case by the presence or absence of the SSN (SMPTE Standard Number) format-specific parameter... But, I actually don't see SSN in ST 2110-22. It's in ST 2110-20 which requires e.g. SSN=ST2110-20:2017.

The current example SDP file is almost certainly wrong because it has SSN=ST2110-20:2017 here:
https://github.com/AMWA-TV/nmos-jpeg-xs/blob/80307b78875510bd0dc2a3e6d0cd1db4cc9d19d6/examples/jpeg-xs.sdp#L9

I notice that VSF TR-08 includes SSN=ST2110-22:2019 in its example, which would be perfect if ST 2110-22 required that!

As discussed on Incubator 2021-12-08: This referenced in the document but doesn't yet exist.

We recently ran into a case where we two venders with correct implementation of different versions of RFC-9134 (https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-18) did not opererate together. Since the JPEG-XS specification for packetization is evolving does it make some sense to put into the receiver caps and parameters the specific range or specific values for RFC 9134 version supported by a receiver?

The controller could then "reason" about what common format spans the target receivers and adjust to send that version of packetization with the SDP file containing the specific version of JPEG-XS packetization employed. This would give us maximum flexibility for supporting a wide range of hardware.

Thoughts?

At the moment, BCP-006-01 draft focuses on the requirements on Nodes that transmit or receive JPEG XS streams.
This includes making REQUIRED all the Flow and Sender attributes, and Receiver parameter constraints, that enable a Controller to ascertain whether those Senders and Receivers are compatible.

We've learnt from the Controller spec activity (viz. recent INFO-005 and IS-04, IS-05 and BCP-003-01 updates) that we need to bring together and clearly state requirements for Controllers too.

Seems like we could add a Controllers sub-heading, and e.g. state that a Controller MUST be capable of using these Flow/Sender attributes and Receiver caps to determine compatibility?

The packetmode and transmode format-specific parameters for JPEG XS are defined in RFC 9134.

• packetmode (K=0 codestream, K=1 slice)
• transmode (T=0 any order, default T=1 sequential order)

These parameters could affect whether a particular Receiver can handle a given stream.

Packetmode and transmode have dependencies: Default packetmode is 0 (codestream) and this packetmode
implies sequential transport mode (transmode is 1). If packetmode is 1 (slice), then transmode can be either 0
(any order) or 1 (sequential, in order).

However, the default (codestream/sequential) is appropriate for most use cases, and VSF TR-08 currently only supports this default.

Therefore, it could be appropriate to hold off adding these as Flow (or Sender?) attributes and Receiver parameter constraints and assume the default in both cases? In that case, do we want to be explicit about this in BCP-006-01 so that we have a path to adding these in the future?

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)

VSF TR-08 defines Capability Sets and Interoperability Points.

I hope we can add examples of how these may be represented in Receiver caps to this spec.