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

[Zaheduzzaman Sarker <[e-mail]>]

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" <[e-mail]> wrote:

    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.


    > ----------------------------------------------------------------------
    > 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.

    Thank you for the extensive review.

    > 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.

    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.

    > * 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?

    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.

    > 
    > * 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?

    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 <[e-mail]> 
    Sent: Tuesday 20 July 2021 17:26
    To: The IESG <[e-mail]>
    Cc: [e-mail]; [e-mail]; [e-mail]; Ali Begen <[e-mail]>; [e-mail]; [e-mail]
    Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-payload-rtp-jpegxs-17: (with COMMENT)

    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://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=



    ----------------------------------------------------------------------
    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.