Re: [AVTCORE] [Internet] Comments (was: FW: [jvet] FW: WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”)

[Stephan Wenger <[e-mail]>]

Hi Hendry,

Regarding your first comment, I propose not to act on it.  IETF RFCs tend to tolerate a lot more explanatory text and redundancies than video coding specs tend to do—in fact, explanatory text is usually encouraged.  The redundancy you mentioned is not uncommon, and, to me, improves readability of the text.

Ye-Kui and Yago, can you please also take a look at the second comment?  My hunch is that Hendry’s “minimum” solution is the design intention, hence we may have a terminology issue here.
I’m not quite sure what to do about sub-pictures.  Perhaps an informative note like the following: “If a sender employs sub-pictures and the system envisions sub-picture-based compressed domain modification of the NAL unit stream in a MANE, for example by removing sub-pictures, a good design choice on the sender’s side would be to aggregate NAL units belong to individual sub-pictures in their own respective aggregation packet.”.  Is that what you are after?  I don’t mind adding such a note, but will remark that such sub-picture processing would certainly require signaling, and that signaling is currently undefined.  I think such signaling would be non-trivial and would likely require something similar as the CLUE framework, defining which would be heavy lifting indeed.  Also, unpacking and re-packing APs is a trivial operation compared to other stuff a MANE needs to do, hence I’m not overly worried.

Regarding the third comment, I believe our design intention is aligned with your preference.  I think we will implement that as proposed.

AVT WG, how does above sound?

S.


From: "shuaiizhao(Shuai Zhao)" <[e-mail]>
Date: Monday, August 23, 2021 at 09:11
To: "[e-mail]" <[e-mail]>
Cc: Stephan Wenger <[e-mail]>, Dr Hendry <[e-mail]>
Subject: Re: [Internet][AVTCORE] Comments (was: FW: [jvet] FW: WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”)

Thanks, Hendry, for your comments. For easy communication with other reviewers, I copy/paste the content in the xlsx file here.

1
General / Editorial
4.3.2
Figure 5 and 6
The difference between the first aggregation unit and the rest of aggregation unit is that the first aggregation unit may contain DONL (Conditional).
Move the illustration of DONL (Conditional) to Figure 4. With that change, Figure 5 and Figure 6 are the same so one of them can be removed and text can be made shorter.
2
Technical
4.3.2
Page 24 / Line 1
Currently it is specified that "An AP aggregates NAL units of one access unit". It seems that this allows an AP to contain NAL units from multiple pictures in the case there are multiple layers in the stream. Further, it also allow an AP to contain some NAL units of a picture and some of NAL units of the following picture. This is not desirable since it requires MANE to perform extra works when it needs to drop certain picture.

Further, VVC has subpicture that may be independently coded which means it can be extracted as well. Consider making life easier for MANE to extract / drop NAL units based on subpicture as well.
At minimum, constraint that an AP can aggregate NAL units of one picture unit, instead of one access unit.

Further, consider having constraint that an AP can aggregate NAL units of one subpicture, if present.
3
Technical
4.3.3
Page 28 & 29
The semantics of P bit in FU header when equal to 1 say the FU contain the last NAL unit of a coded picture. Is it the last VCL NAL unit or simply NAL unit (i.e., non-VCL NAL unit)?

Note that the last NAL  unit in a picture unit can be non-VCL NAL unit as well (e.g., the last one is a suffix SEI NAL unit or a suffix APS NAL unit). If the last NAL unit is a non-VCL NAL unit (e.g., a suffix NAL unit), which may be dropped, it may cause a burden to MANE since it may need to update the previous packet containing the NAL unit that immediately preceed the drop NAL unit in decoding order to change the value of P bit from 0 to 1.
Clarify the semantic of P bit.

If it can be equal to 1 only for FU containing the last fragment of the last VCL NAL unit of a picture, add explation that there may be packet(s) containing non-VCL NAL unit that is associated with the picture as well.

Otherwise, if it can be equal to 1 for either VCL or non-VCL NAL unit, then add explanation that in the case that the NAL unit is dropped / not forwarded to the receiver and the NAL unit that immediately precede the last NAL unit is also contained in FUs, the value of P bit in the FU header of the last FU of that NAL unit need to be updated to be equal to 1.

Preferrence: P bit can be equal to 1 for the last FU of the last VCL NAL unit of a picture.




Best,
Shuai

From: avt <[e-mail]> on behalf of Dr Hendry <[e-mail]>
Reply-To: Dr Hendry <[e-mail]>
Date: Monday, August 23, 2021 at 9:04 AM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [Internet][AVTCORE] Comments (was: FW: [jvet] FW: WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”)


Dear sir,



Upon reviewing the available draft RTP payload format for VVC (draft-ietf-avtcore-rtp-vvc-10), I have sent several comments to the editors but was requested to send them to you instead.

Please find the comments in the attached file.



best regards,

Hendry



---------- Original Message ----------

From : Stephan Wenger <[e-mail]>
To : Dr Hendry Principal Research Engineer(dr.hendry)
Cc : [e-mail], [e-mail], [e-mail]
Date : 2021/08/20 15:49:22 [GMT-07:00]
Subject : Re: [jvet] FW: [AVTCORE] WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”
Hi Hendry,  could you put the content of the xls into plain ascii and send to [e-mail]?  At this point, public evidence of review is important.
Tnx, S.
Sent from my iPhone

On Aug 20, 2021, at 15:34, Dr Hendry <[e-mail]> wrote:

Dear Stefan, all,



After reviewing the draft, I have few comments for it. I am not familiar with the process but I hope the comments can be addressed.



Best regards,

Hendry



---------- Original Message ----------

From : Stephan Wenger <[e-mail]>
To : [e-mail]
Date : 2021/08/16 22:57:24 [GMT-07:00]
Subject : [jvet] FW: [AVTCORE] WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”

All:

Please see below the announcement for the Working Group Last Call (WGLC) of the VVC RTP payload format in the IETF.  The WGLC is the first of a two-step approval process.  If you have interest and bandwidth, please comment as described below.

Stephan





From: avt <[e-mail]> on behalf of Bernard Aboba <[e-mail]>
Date: Monday, August 16, 2021 at 13:30
To: IETF AVTCore WG <[e-mail]>
Subject: [AVTCORE] WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”



This is an announcement of WG last call on "RTP Payload Format for Versatile Video Coding (VVC)”.



The document is available for inspection here:

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/





WG Last Call will end on August 30, 2021.



In response, please state one of the following:



* I support advancing the document to Proposed Standard



* I object to advancement to Proposed Standard, due to Issues

described below <Issue description or link>.



Bernard Aboba



For the Chairs



_______________________________________________

jvet mailing list -- [e-mail]

To unsubscribe send an email to [e-mail]

https://lists.rwth-aachen.de/postorius/lists/jvet.lists.rwth-aachen.de