Subject: [AVTCORE] Zaheduzzaman Sarker's No Objection on draft-ietf-payload-rtp-jpegxs-17: (with COMMENT)

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Tue, 20 Jul 2021 08:26:13 -0700

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-payload-rtp-jpegxs-17: 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:
----------------------------------------------------------------------

Thanks to the authors and Stephan Wenger for prompt action to make the ISO
specification available to us.

I have removed the discuss as the main reason for the discuss was resolved.

I however have one major issue which I think need to be addressed.

* Section 4.1 : the assertion here is that the jpeg xs produces constant
bitrate. However, now I know that this codec can operate on both constant and
variable bitrate mode. This section should clarify that when VBR mode is used
the RTP payload format still holds or not. Also it might be helpful to discuss
the two mode of operations somewhere in the introduction and state if the focus
is only on constant bitrate mode with reasoning. The will level out the scope
of the payload definition and also the impact on section 6.

And more comments:

* I can agree with Martin Duke's comment that the polymorphic use of
"end-to-end latency" need to be explained a bit.

* Section 3:  having the statement that we are describing some terminologies or
naming for this specification like it section 4 does, would help the reader to
understand the context a bit more.

* Section 3.3: I would suggest to add reference to Ppih and Plev at the first
use of them.

* Section 4.3: says --

    "If codestream packetization mode is
      used, L bit and M bit are equivalent."

   does this mean it is enough to set the M bit only in the codestream
   packetization mode?

* Section 4.3: says --
    "In the case of codestream packetization mode (K=0), this
         counter resets whenever the Packet counter resets (see
         hereunder)"

   hereunder? can we give more specific reference instead?

* Section 6: Usually when RTP is used congestion control and corresponding
required rate control is done by the RTP applications. The use of RTP AVPF
profile is the recommended profile to be used for real-time communication when
efficient rate control (nope not the video encoder rate control :-)) is needed.
Hence, I think we should recommend that use of AVPF profile here and also refer
to RFC8888. The inclusion of circuit breaker makes lot of sense here. I also
got to know that jpeg xs is designed to be used in a controller network
environment. Hence, there should be a warning about use of this in a best
effort Internet prior to the requirement on packetloss observation. If there is
any acceptable parameter defined somewhere for packet loss then that also
should be referenced here.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Jul 2021 21:48:17 -0700

Although the DISCUSS has cleared (and thanks for making that happen), does
the WG have anything in response to the comments left in the ballot
position?

-MSK

---

From: Tim Bruylants <[email-masked]>
Date: Wed, 28 Jul 2021 11:44:15 +0000

Hi Murray,

Yes, I’ll be issuing a new draft to address all the comments. However, I’m still on holidays, so I’ll have it ready and uploaded by next week.

Sorry for the delay, but it will be handled asap.

Best regards,
Tim

From: avt <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: Wednesday 28 July 2021 06:48
To: IETF AVTCore WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [AVTCORE] Zaheduzzaman Sarker's No Objection on draft-ietf-payload-rtp-jpegxs-17: (with COMMENT)

Although the DISCUSS has cleared (and thanks for making that happen), does the WG have anything in response to the comments left in the ballot position?

-MSK

On Tue, Jul 20, 2021 at 8:26 AM Zaheduzzaman Sarker via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-payload-rtp-jpegxs-17: No Objection

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=0R4ccdgr1gSEWtLtgXzCbf_lQrw2fAiCc3uTL790VTI&s=yXIM3nfH-La-K5ZAxOAtzeMSk_X1QNAew_Bltp_fIL4&e=>
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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Djpegxs_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=0R4ccdgr1gSEWtLtgXzCbf_lQrw2fAiCc3uTL790VTI&s=3mb4xXqHMO0i-nnPVyxY9LzRMjDNVu2wtAKlVM-PFRU&e=>

And more comments:

* Section 4.3: says --

* Section 4.3: says --

---

From: Tim Bruylants <[email-masked]>
Date: Wed, 28 Jul 2021 15:55:25 +0000

Hi all,

I have uploaded -18 to address all last (and hopefully final) comments. Below is an in-depth reply of the changes made.

Kind regards,
Tim Bruylants

Changes between -17 and -18 were made to address mainly the comments by Zaheduzzaman Sarker, as well as the following:

- Changed Abstract and the Introduction section text about the latency to better represent what is intended: that JPEG XS was designed to have a very low increased latency when compared to uncompressed video. The latency of the network path is not influenced by the codec, and we talk about encoding-decoding latency.

> Thanks to the authors and Stephan Wenger for prompt action to make the ISO specification available to us.
> 

Thank you for the extensive review.

> * Section 4.1 : the assertion here is that the jpeg xs produces constant bitrate. However, now I know that this codec can operate on both constant and variable bitrate mode. This section should clarify that when VBR mode is used the RTP payload format still holds or not. Also it might be helpful to discuss the two mode of operations somewhere in the introduction and state if the focus is only on constant bitrate mode with reasoning. The will level out the scope of the payload definition and also the impact on section 6.

JPEG XS currently defines a buffer model for CBR which does not directly address true VBR scenarios (ignoring the Mathematically Lossless profile here, which obviously produces VBR output, unless some serious zero-padding is added). However, despite CBR being the original focus, XS can also do VBR (as you stated). It just depends on the rate allocation and how the encoder generates the various packets and slices. We plan to issue VBR buffer models and profile support in a future update of the standard, and we do not want to restrict the Payload RFC to only CBR. Moreover, we intended the Payload RFC to address purely the packetization of XS over RTP, but leave buffer models, congestion control and other more complicated matters to external standards (or best effort), such as ST 2110 and VSF TR-08.

We have updated the text of section 4.1 to be more neutral on CBR and VBR.

> And more comments:
> 
> * I can agree with Martin Duke's comment that the polymorphic use of "end-to-end latency" need to be explained a bit.

Yes, this comment was also raised by Martin, and we already prepared some changes to the Abstract and the Introduction to address this (see above). So, JPEG XS was designed with low-latency as one of its core requirements. It is evident that this represents the latency incurred only by encoding and decoding of the video frames. For this, several features of XS help to maintain the low latency requirement (how packetization is done, how rate allocation is done, etc). Of course, the network path latency is something that is out of the control of the codec, and this cannot be considered. So, we changed the wording in the text from "end-to-end low latency" to "encoding-decoding low latency". We hope this provides an adequate correction to address the comment?

> * Section 3:  having the statement that we are describing some terminologies or naming for this specification like it section 4 does, would help the reader to understand the context a bit more.

Yes, this is indeed true. We have added a small text explaining the purpose of section 3.

> * Section 3.3: I would suggest to add reference to Ppih and Plev at the first use of them.

Done.

>    does this mean it is enough to set the M bit only in the codestream

No, both bits MUST always be correctly set (to 0 or 1). This sentence just expresses that their meaning is the same when codestream packetization is employed (marking the last packet or marking that this packet contains the last data of the codestream). We modified the text to make this more clear.

>    hereunder? can we give more specific reference instead?

We replaced "hereunder" by a reference.

> * Section 6: Usually when RTP is used congestion control and corresponding required rate control is done by the RTP applications. The use of RTP AVPF profile is the recommended profile to be used for real-time communication when efficient rate control (nope not the video encoder rate control :-)) is needed.

We added AVPF explicitly as an example profile in this section (it was already mentioned later on).

> Hence, I think we should recommend that use of AVPF profile here and also refer to RFC8888. The inclusion of circuit breaker makes lot of sense here. I also got to know that jpeg xs is designed to be used in a controller network environment. Hence, there should be a warning about use of this in a best effort Internet prior to the requirement on packetloss observation. If there is any acceptable parameter defined somewhere for packet loss then that also should be referenced here.
>

We added rfc8888 for Feedback for Congestion Control.

We reformulated the text to mention that XS is mainly to be used in a controlled network environment.

-----Original Message-----
From: Zaheduzzaman Sarker via Datatracker <[email-masked]> 
Sent: Tuesday 20 July 2021 17:26
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ali Begen <[email-masked]>; [email-masked]; [email-masked]
Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-payload-rtp-jpegxs-17: (with COMMENT)

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=lABbJkTi_k8nlRKSDgb6IQxDFAqulQ5BxeXA83yq3SI&m=9bkyYaOqkUQm5koOCeE4WTO7NEX9fUpWvpylA4QdMHE&s=lC97q7jTkQnez1Ckdg-wDTgax2yodPYhtVDtI5f9NoU&e=
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Djpegxs_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=lABbJkTi_k8nlRKSDgb6IQxDFAqulQ5BxeXA83yq3SI&m=9bkyYaOqkUQm5koOCeE4WTO7NEX9fUpWvpylA4QdMHE&s=jQ4uK7h8WnLzo_p7aiFUD2JQsoIfxrHiWc8REAcjgbc&e=

Thanks to the authors and Stephan Wenger for prompt action to make the ISO specification available to us.

* Section 4.1 : the assertion here is that the jpeg xs produces constant bitrate. However, now I know that this codec can operate on both constant and variable bitrate mode. This section should clarify that when VBR mode is used the RTP payload format still holds or not. Also it might be helpful to discuss the two mode of operations somewhere in the introduction and state if the focus is only on constant bitrate mode with reasoning. The will level out the scope of the payload definition and also the impact on section 6.

And more comments:

* I can agree with Martin Duke's comment that the polymorphic use of "end-to-end latency" need to be explained a bit.

* Section 3:  having the statement that we are describing some terminologies or naming for this specification like it section 4 does, would help the reader to understand the context a bit more.

* Section 3.3: I would suggest to add reference to Ppih and Plev at the first use of them.

* Section 4.3: says --

* Section 4.3: says --

* Section 6: Usually when RTP is used congestion control and corresponding required rate control is done by the RTP applications. The use of RTP AVPF profile is the recommended profile to be used for real-time communication when efficient rate control (nope not the video encoder rate control :-)) is needed.
Hence, I think we should recommend that use of AVPF profile here and also refer to RFC8888. The inclusion of circuit breaker makes lot of sense here. I also got to know that jpeg xs is designed to be used in a controller network environment. Hence, there should be a warning about use of this in a best effort Internet prior to the requirement on packetloss observation. If there is any acceptable parameter defined somewhere for packet loss then that also should be referenced here.

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 28 Jul 2021 21:26:37 +0000

Hi Tim,

Thanks for the update and addressing my comments. I think -18 version looks good.

BR
Zahed

On 2021-07-28, 21:55, "Tim Bruylants" <[email-masked]> wrote:

    Hi all,

    Kind regards,
    Tim Bruylants

    Done.

    -----Original Message-----
    From: Zaheduzzaman Sarker via Datatracker <[email-masked]> 
    Sent: Tuesday 20 July 2021 17:26
    To: The IESG <[email-masked]>
    Cc: [email-masked]; [email-masked]; [email-masked]; Ali Begen <[email-masked]>; [email-masked]; [email-masked]
    Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-payload-rtp-jpegxs-17: (with COMMENT)

    And more comments:

    * Section 4.3: says --

    * Section 4.3: says --