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

[Benjamin Kaduk <[e-mail]>]

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

On Thu, Jun 17, 2021 at 07:06:29PM +0000, Tim Bruylants wrote:
> > ----------------------------------------------------------------------
> > 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://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).
> 
> > 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.
> 
> Agreed. We changed this to: "Any application that transmits video over RTP (like SMPTE ST 2110)."
> 
> > Section 8
> >
> > nit: s/SPD/SDP in the section heading.
> 
> That's a good catch. Fixed it.
> 
>