Subject: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-payload-rtp-jpegxs-16: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 17 Jun 2021 00:45:40 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-payload-rtp-jpegxs-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'll echo the sentiment of other reviewers that the scope of review
possible is limited witout access to the underlying ISO specification.
I further note that in the recent case of
https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ (for which the
underlying specification is freely available), there was an error in
replicating the chroma subsampling details from the underlying reference
to the internet-draft.  Any such errors are undetectable for this draft.

Section 4.3

Does the value of the T and K bits need to be identical for all packets
of a given RTP stream?

Section 4.4

It's perhaps needlessly confusing to have the human-readable slice
labels in Figures 8 and 9 start at 1 but the SEP counter start at 0.

nit: if SLH is an acronym it should be expanded somewhere (it only
appears in the figures, at present).

In the slice packetization modes, do we have reasonable guarantees that
the JPEG XS header (including all markers and marker segments) will fit
into a single RTP packet?

Section 7.1

   Applications that use this media type:
      For example: SMPTE ST 2110, Video over IP, Video conferencing,
      Broadcast applications.

I think bland declarative statements like "applications that transmit
video over RTP" tend to be more common than longer "for example"
listings, in this type of registration.

Section 8

nit: s/SPD/SDP in the section heading.

---

From: Tim Bruylants <[email-masked]>
Date: Thu, 17 Jun 2021 19:06:29 +0000

> I'll echo the sentiment of other reviewers that the scope of review possible is limited witout access to the underlying ISO specification.
> I further note that in the recent case of https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Dvp9_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=lABbJkTi_k8nlRKSDgb6IQxDFAqulQ5BxeXA83yq3SI&m=EUpYAiLAgXylCuqQrCOWa_FavJHgm4h934uh2eTmjF8&s=Pdi60gBr_pxE6ALbEjNia0vvwAW1nUHIjda7-wGs8UE&e= (for which the underlying specification is freely available), there was an error in replicating the chroma subsampling details from the underlying reference to the internet-draft.  Any such errors are undetectable for this draft.

Indeed. See comment of "Francesca Palombini". This is a valid comment. We are unsure how to resolve this. ISO is very strict about distribution of documents outside of the working groups (i.e. it is not allowed at all).

> Section 4.3
>
> Does the value of the T and K bits need to be identical for all packets of a given RTP stream?

Indeed, the T and K bits are not allowed to change in the RTP stream session. We clarified this.

> Section 4.4
>
> It's perhaps needlessly confusing to have the human-readable slice labels in Figures 8 and 9 start at 1 but the SEP counter start at 0.

We chose to start the human counting with 1. The actual algorithm counter values for SEP and P however do indeed start at 0. It would be tricky to change the figures this late in the review process.

> nit: if SLH is an acronym it should be expanded somewhere (it only appears in the figures, at present).

SLH is an XS marker. We added this in Section 2 (without repeating its definition from ISO 21122-1).

> In the slice packetization modes, do we have reasonable guarantees that the JPEG XS header (including all markers and marker segments) will fit into a single RTP packet?

Yes. Slice packetization mode essentially states that each RTP packet contains data from only ONE slice. But slices can be split (at arbitrary boundaries) over multiple RTP packets (and this will almost always happen). Markers and marker segments can only occur in the first RTP packet of a slice (and these are very small -- 6 bytes for the SLH marker).

> I think bland declarative statements like "applications that transmit video over RTP" tend to be more common than longer "for example"

Agreed. We changed this to: "Any application that transmits video over RTP (like SMPTE ST 2110)."

> nit: s/SPD/SDP in the section heading.

That's a good catch. Fixed it.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jun 2021 18:46:52 -0700

Hi Tim,

Just to close the loop: your replies all make sense to me, and thanks for
providing the additional explanation and updating the draft as appropriate.

-Ben