Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format

From: "Deshpande, Sachin" <[email-masked]>
Date: Thu, 27 Jun 2013 01:02:54 +0000

Dear All,
I have done a first review of the draft-schierl-payload-rtp-h265-03.txt and 
I support the draft to be adopted as the starting point of the WG item. 
Please find below my comments on the draft. 
Best regards,
Sachin Deshpande

-----

Comments on RTP Payload Format for HEVC
draft-schierl-payload-rtp-h265-03.txt

Typos:
T.1) Missing "as" in the following line on Pg. 14-15:
Parallel processing is possible through parallel decoding of CTU rows, where the start of
the decoding of a row is delayed by two CTUs, so "as" to ensure that data
related to a CTU above and to the right of the subject CTU is 
available before the subject CTU is being decoded.

T.2) Title for Figure 3:
Current title: "The structure of the first aggregation unit in an AP"
I believe it should be something like:
"The structure of a single NAL unit packet"

T.3) Text in Figure 8:
"NALU 2 HRD" should be "NALU 2 HDR"

T.4) Text in last paragraph in section 6:
"remained" -> "remaining"

Discussions:
D.1) In section 4.5 Single NAL Unit Packets-
"The payload header MUST be an exact copy of the NAL unit header of the contained NAL unit." 
My understanding is that The NAL Unit payload data that is shown in Fig. 3 - contained in the single NAL unit packets
does not include the NAL unit header.
So a couple of clarification questions regarding this "MUST" requirement.

a. Does this mean that an entity can not change the payload header of a single NAL unit type compared to the original NAL unit header in the NAL unit? 
e.g. to change the NAL unit type from say BLA_W_LP to BLA_N_LP if it decides to drop LPs? Other similar NAL unit type change examples are possible.
I imagine supporting ability to allow a NAL unit type change such as above may be desirable. 
Thus possibly changing the "MUST" requirement to "SHOULD" may make sense?

b. What is the way to check that the NAL unit header rule above is enforced when an entity receives a single NAL unit packet.
i.e. is there a conformance checking mechanism defined.

D.2) My understanding is that a single NAL unit can be sent either inside a single NAL unit packet
or inside an aggregation packet (containing only one NAL unit). And that the bytes on the wire for these two cases will be different.
Is there a use case envisioned that would benefit by allowing sending one NAL unit (only) in these two different ways?
If there is not then do we want to disallow single NAL unit (only) scenario in an AP?

Editorial Suggestions:
E.1) At a number of places in text and figures (e.g. Fig. 3, 5, 6) DONL and DOND fields are mentioned as "optional".
e.g. section 4.5: "...an optional 16-bit DONL field (in network byte order),...",
section 4.6 "...consists of an optional 8-bit DOND field followed by..."
I have a couple of questions and possible suggestions:
-Is this use of the term "optional" with regards to DONL and DOND in draft-schierl-payload-rtp-h265-03 to be interpreted as described in RFC 2119 ? 
(I believe it should be interpreted that way based on the "2. Conventions" section in draft-schierl-payload-rtp-h265-03)
If so then RFC 2119 says on pg. 2:
"... 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is truly optional..."
-Are the DOND and DONL "optional" as per RFC 2119 definition?
I believe there are conditions where DONL and DOND MUST be present.
e.g. section 4.5: "...If tx-mode is equal to "MST" or sprop-depack-buf-nalus is greater than 0, the DONL field MUST be present...",
section 4.6: "...If tx-mode is equal to "MST" or sprop-depack-buf-nalus is greater than 0, the DONL field MUST be present..."
In this case is it correct to refer to DONL and DOND fields as "optional"?
-In case it is correct to refer to DONL and DOND fields as "optional" should the use of the word in text and Fig. 3, 5, 6 be using upper case "OPTIONAL"?

E.2) The term "header" is referred with different notations (e.g. XHdr, HDR, Header) when referring to different header fields in figures and text e.g.:
Payload header is referred as: "PayloadHdr" (many Figures, text), 
NAL Unit header is referred as: "NALU X HDR" (Fig. 8 and text), 
Fragmentation Unit header is referred as: "FU Header" (figure 9 and text).
A consistent notation for referring to "header" fields may avoid confusion.
As currently it may appear to a casual reader that there is some reason to use different labeling for these different header fields.

E.3) It is mentioned:
"Aggregation Packet (AP) : Contains one or more NAL units within one access unit." (section 4.2)
"An AP aggregates NAL units within one access unit." (section 4.6)
But it seems there is no statement saying a "MUST" requirement on APs regarding all NAL units in it MUST belong to same access units.
e.g. something like:
An AP MUST contain NAL units which belong to the same access unit.

E.4) Perhaps the current "Fragmentation Units" (section 4.7) could be termed "Fragmentation Unit Packets" or "Fragmentation Packets".
This will then be similar to how aggregation "packets" consist of aggregation "units".

-----

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wang, Ye-Kui
Sent: den 11 juni 2013 19:00
To: [email-masked]
Subject: [payload] Submission of new versions of H.265/HEVC payload format

Dear All,

We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265, for which the links are as follows:

Version 02:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-02.txt
Htmlized:        http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-02

Version 03:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-03.txt
Htmlized:        http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-03

Version 02 includes huge changes compared to the earlier submitted version 01. In a short summary, the authors have worked hard to try to make the design complete, from both the payload structure and the signaling points of view. Compared to version 02, version 03 only contains a correction of the email address of an author.

Due to that the industry is eager to deploy H.265/HEVC and other standards bodies such as 3GPP rely on the payload format for support of H.265/HEVC in RTP based video services, we need to progress this draft relatively quickly. Therefore, we would like to request quick reviews from interested parties and also request for the WG status of this draft.

BR, YK (on behalf of the authors)
_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Thu, 27 Jun 2013 05:33:33 +0000

Hi Sachin,

Many thanks for your careful review and valuable comments! Please see below, where I have removed those texts that are not needed any more.

> I have done a first review of the draft-schierl-payload-rtp-h265-03.txt and I
> support the draft to be adopted as the starting point of the WG item.

[YK] Thanks!

> Parallel processing is possible through parallel decoding of CTU rows, where
> the start of the decoding of a row is delayed by two CTUs, so "as" to ensure
> that data related to a CTU above and to the right of the subject CTU is

[YK] Both "so to" and "so as to" seem to be OK. If you make a Googlefight (http://www.googlefight.com/index.php?lang=en_GB&word1=so+to&word2=so+as+to) actually the former wins slightly :-)

> "The structure of a single NAL unit packet"

 [YK] Absolutely! Good catch. Corrected (in what I preparing for the next version).

> "NALU 2 HRD" should be "NALU 2 HDR"

[YK] Corrected.

> "remained" -> "remaining"

[YK] Changed.

> 
> Discussions:
> D.1) In section 4.5 Single NAL Unit Packets- "The payload header MUST be an
> exact copy of the NAL unit header of the contained NAL unit."
> My understanding is that The NAL Unit payload data that is shown in Fig. 3 -
> contained in the single NAL unit packets does not include the NAL unit header.
> a. Does this mean that an entity can not change the payload header of a
> single NAL unit type compared to the original NAL unit header in the NAL unit?
> e.g. to change the NAL unit type from say BLA_W_LP to BLA_N_LP if it decides
> to drop LPs? Other similar NAL unit type change examples are possible.

[YK] Very good point. Indeed, the language should not prohibit entities from changing the NAL unit type value if it is desirable to change for example a CRA picture to be a BLA picture in bitstream switching, splicing or random accessing. I changed the language to be: 

The payload header SHOULD be an exact copy of the NAL unit header of the contained NAL unit.  However, the Type (i.e. nal_unit_type) field MAY be changed, e.g. when it is desirable to handle a CRA picture to be a BLA picture [JCTVC-J0107].

> b. What is the way to check that the NAL unit header rule above is enforced
> when an entity receives a single NAL unit packet.

[YK] No, there is no such conformance checking mechanism defined. Different from those "shall" requirements in the video coding spec that must be verifiable by checking the bitstream (and possibly some external-means-provisioned information), herein the requirement can be simply imposed on the packetizer.

> D.2) My understanding is that a single NAL unit can be sent either inside a
> single NAL unit packet or inside an aggregation packet (containing only one
> NAL unit). And that the bytes on the wire for these two cases will be different.
> Is there a use case envisioned that would benefit by allowing sending one
> NAL unit (only) in these two different ways?

[YK] Good point again. After a bit thinking, I could not find a use case that needs an AP containing only one NAL unit. Unless such a use case is found, I will go ahead to specify requiring the use of single NAL unit packet for carrying exactly one NAL unit in an RTP packet.

> -Is this use of the term "optional" with regards to DONL and DOND in draft-
> schierl-payload-rtp-h265-03 to be interpreted as described in RFC 2119 ?
> (I believe it should be interpreted that way based on the "2. Conventions"
> section in draft-schierl-payload-rtp-h265-03)
> e.g. section 4.5: "...If tx-mode is equal to "MST" or sprop-depack-buf-nalus is
> greater than 0, the DONL field MUST be present...", section 4.6: "...If tx-mode
> is equal to "MST" or sprop-depack-buf-nalus is greater than 0, the DONL field
> MUST be present..."
> -In case it is correct to refer to DONL and DOND fields as "optional" should
> the use of the word in text and Fig. 3, 5, 6 be using upper case "OPTIONAL"?
> 

[YK] Hmm. I think this is again a good point. However, I am not sure what exactly the best way is. Checking RFC 6184 and RFC 6190, there are also such optional fields, and both "OPTIONAL" and "optional" are used. Insights from those who are more experienced on this would be appreciated!

> E.2) The term "header" is referred with different notations (e.g. XHdr, HDR,
> Header) when referring to different header fields in figures and text e.g.:
> Payload header is referred as: "PayloadHdr" (many Figures, text), NAL Unit
> header is referred as: "NALU X HDR" (Fig. 8 and text), Fragmentation Unit
> header is referred as: "FU Header" (figure 9 and text).
> As currently it may appear to a casual reader that there is some reason to
> use different labeling for these different header fields.
> 

[YK] Another good point. However, I tried to unify but found that we'd better keep them as they are. For example, "HDR" is only used inside Figures, changing of some occurrences would destroy figures, which have to be drawn using ASCII symbols.

> E.3) It is mentioned:
> "Aggregation Packet (AP) : Contains one or more NAL units within one access
> unit." (section 4.2) "An AP aggregates NAL units within one access unit."
> (section 4.6) But it seems there is no statement saying a "MUST" requirement
> on APs regarding all NAL units in it MUST belong to same access units.
> e.g. something like:

[YK] This requirement to me is obvious. For example, if we should add such a MUST requirement, should we also add a MUST requirement to say that a single NAL unit packet MUST contain exactly one NAL unit? And I believe there are many more such cases.

> E.4) Perhaps the current "Fragmentation Units" (section 4.7) could be termed
> "Fragmentation Unit Packets" or "Fragmentation Packets".

[YK] We could do this. However, I guess keeping the term here to be consistent with RFC 6184 and RFC 6190 is probably more preferable.

BR, YK