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

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 16 Jun 2021 13:32:36 -0700

Martin Duke 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:
----------------------------------------------------------------------

In the abstract and intro, it promises "end-to-end latency confined to a
fraction of a frame".

I am not sure what to make of this guarantee. Latency is a measure of time and
a frame is measured in ... bytes?

Moreover, end-to-end latency is mostly a property of the path, and not
something an encoding format can promise.

---

From: Tim Bruylants <[email-masked]>
Date: Thu, 17 Jun 2021 18:59:27 +0000

> In the abstract and intro, it promises "end-to-end latency confined to a fraction of a frame".
>
> I am not sure what to make of this guarantee. Latency is a measure of time and a frame is measured in ... bytes?
>
> Moreover, end-to-end latency is mostly a property of the path, and not something an encoding format can promise.

Indeed, in the context of an RTP protocol specification, the word "frame" is ambiguous. In this case, we refer to "video frames" and we have modified the text accordingly. It is common to express latency in terms of video frames, as this translates to a time (given the video frame rate). We have updated the text to use "video frame" instead.

---

From: Martin Duke <[email-masked]>
Date: Thu, 17 Jun 2021 12:04:43 -0700

Thanks! But how is this guaranteeing end-to-end latency, which is a
property of the path?

On Thu, Jun 17, 2021 at 11:59 AM Tim Bruylants <[email-masked]> wrote:

> > I am not sure what to make of this guarantee. Latency is a measure of
> time and a frame is measured in ... bytes?
> >
> Indeed, in the context of an RTP protocol specification, the word "frame"
> is ambiguous. In this case, we refer to "video frames" and we have modified
> the text accordingly. It is common to express latency in terms of video
> frames, as this translates to a time (given the video frame rate). We have
> updated the text to use "video frame" instead.
>

---

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

Yes, I see now what you are referring to. The end-to-end latency definition that we refer to is the latency introduced by the compression-decompression cycle of applying XS to a video sequence. It is, as you state, evident that the network path (and other factors) introduces additional latency in to total grand scheme of things. But it is not exactly what the introduction is trying to convey.

I updated the draft to -17 and did not really clarify this in more detail, as it is simply introductory text which is not essential for the RTP payload specification itself. If you insist, we can still edit this, but otherwise we prefer to keep it as is.

Best regards,
Tim

From: Martin Duke <[email-masked]>
Sent: Thursday 17 June 2021 21:05
To: Tim Bruylants <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Ali Begen <[email-masked]>; [email-masked]
Subject: Re: Martin Duke's No Objection on draft-ietf-payload-rtp-jpegxs-16: (with COMMENT)

Thanks! But how is this guaranteeing end-to-end latency, which is a property of the path?

---

From: Martin Duke <[email-masked]>
Date: Thu, 17 Jun 2021 12:22:15 -0700

I agree that this is not a dealbreaker. However, if there is another edit,
it would be good if the introduction expanded the definitions a bit to
clarify what you mean.

On Thu, Jun 17, 2021 at 12:18 PM Tim Bruylants <[email-masked]> wrote:

> Yes, I see now what you are referring to. The end-to-end latency
> definition that we refer to is the latency introduced by the
> compression-decompression cycle of applying XS to a video sequence. It is,
> as you state, evident that the network path (and other factors) introduces
> additional latency in to total grand scheme of things. But it is not
> exactly what the introduction is trying to convey.
>
>
>
> I updated the draft to -17 and did not really clarify this in more detail,
> as it is simply introductory text which is not essential for the RTP
> payload specification itself. If you insist, we can still edit this, but
> otherwise we prefer to keep it as is.
>
>
>
> Best regards,
>
> Tim
>
>
>
> *From:* Martin Duke <[email-masked]>
> *Sent:* Thursday 17 June 2021 21:05
> *To:* Tim Bruylants <[email-masked]>
> *Cc:* The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Ali Begen
> <[email-masked]>; [email-masked]
> *Subject:* Re: Martin Duke's No Objection on
> draft-ietf-payload-rtp-jpegxs-16: (with COMMENT)
>
>
>

---

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

Agreed, I will put it on the list of potential changes.

Thanks for the feedback.

Sent: Thursday 17 June 2021 21:22

I agree that this is not a dealbreaker. However, if there is another edit, it would be good if the introduction expanded the definitions a bit to clarify what you mean.

On Thu, Jun 17, 2021 at 12:18 PM Tim Bruylants <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I see now what you are referring to. The end-to-end latency definition that we refer to is the latency introduced by the compression-decompression cycle of applying XS to a video sequence. It is, as you state, evident that the network path (and other factors) introduces additional latency in to total grand scheme of things. But it is not exactly what the introduction is trying to convey.

Best regards,
Tim

From: Martin Duke <[email-masked]<mailto:[email-masked]>>
Sent: Thursday 17 June 2021 21:05
To: Tim Bruylants <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ali Begen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Martin Duke's No Objection on draft-ietf-payload-rtp-jpegxs-16: (with COMMENT)