Subject: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

From: "Ben Campbell" <[email-masked]>
Date: Mon, 25 May 2015 17:22:45 -0500

Hi,

This is WGLC feedback for draft-ietf-payload-rtp-h265-09:

*** Substantive ***

-- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a syntax 
violation."

Does that mean that setting the bit is a syntax violation in itself, or 
that it _indicates_ a syntax violation? As worded, it sound like the 
former, but later examples seem to suggest the latter. (e.g. last 
sentence of 4.4.3)

-- 4.4.4, "F1, F2"

Does this paragraph impoy a requirement for the receiver to ignore 
non-zero values? If so, it would be good to state it explicitly.

-- 4.4.4.2 and 4.5:

Has the working group considered whether PACI extensions need a 
registry?

-- 7.1, "max-cbp" "When not present, the value of max-cpb is inferred 
to..."

The analogous statements for previous parameters used a normative MUST.  
Is there a reason not to be consistent, one way or the other?  (Same for 
max-dpb and max-tr)

-- table 1, Legend, last entry: "not usable, when present SHOULD be 
ignored"

Why not MUST? Can you envision circumstances where it might make sense 
to _not_ ignore them?

-- 7.2.3, bullet starting with "Not usable..."

Why not MUST? (same as previous comment)

-- 7.2.5, 2nd sentence:

This is confusing as written. It may not be clear to all readers whether 
  the SHALL NOT after the I.e. Intended as a new normative statement, or 
an example of the bits of 4566 that do not apply.

-- section 9

Please use the updated security considerations boilerplate from 
draft-ietf-payload-rtp-howto-14.

*** Editorial and nits ***

-- General:

There is a running theme of convoluted sentence structure with lots of 
nested clauses. At least for me, that makes reading it harder necessary. 
I've flagged some instances below, but the draft would benefit from an 
editorial pass to reduce these. (This is not a show-stopper, just a 
suggestion for potential improvement.)

Several figures appear to have alignment problems.

-- 1.1.1, "Entropy Encoding"

Can there be an informational reference for CABAC?

-- 1.1.2, "Profile tier and level", last sentence

Long, convoluted sentence. Can it be broken down into a few simpler 
sentences?

-- 1.1.2, "Random access support", first sentence

Missing article before "NAL"?

-- 1.1.2, "Ultra low delay support"

s/ "... these information ..." / "... this information ..."

-- 3.1.1, "coded video sequence" definition

Convoluted sentence structure

-- 4.1, "Marker bit" definition, first sentence.

Convoluted sentence structure. The last sentence of the immediately 
following informative note is also convoluted.

-- 4.1, last paragraph:

The text has already used the term bitstream quite a bit. Perhaps this 
note should occur earlier, possibly in the definitions?

-- 4.2, "Fragmentation Units (FUs) specified in Section 4.4.3. APs MUST 
NOT be nested; i.e. an AP MUST NOT contain another AP."

That construction gives you redundant 2119 keywords. I suggest the 
"i.e." clause be stated descriptively, not normatively.  (Note: This 
construction occurs several times)

-- 7.2.2, informative note after the bullet starting with "The 
parameters sprop-max-don-diff..." :

First sentence is convoluted.

-- 9, 3rd to last paragraph, starting with "Note that the appropriate 
mechanism..."

Isn't this redundant to the first paragraph in section 9?

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 26 May 2015 20:48:06 +0000

Hi Ben,

One quick answer:

On 5/25/15, 15:22, "Ben Campbell" <[email-masked]> wrote:

>[Š]
>[Š]

I can¹t point you to an explicit meeting report that says ³No registry
needed², but most assuredly the point was discussed.  So yes, we did.

The PACI extension mechanism as originally proposed
(draft-wenger-payload-h265-payload-header-extension-00) already included a
reminder that the option of using a registry needs to be discussed.  The
proposal, however, was not to use a registry, as 1) the allocated code
point space was deemed sufficient for future needs, and 2) both H.265 and
the payload format are under tight control of the respective organizations
(JCT-VC/IETF) and therefore code point clashes are unlikely.

Thereafter, Magnus found that the original extension mechanism was broken,
and there was a considerable amount of discussion on this subject on the
mailing list and in private (approximately March/April 2014).  In none of
these discussions a need for the use of a registry was asserted.

Stephan

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 26 May 2015 16:24:42 -0500

Thanks, that answers the question :-)

Ben.

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Fri, 29 May 2015 22:24:22 +0000

Hi Ben,

Thanks for your careful review and the detailed comments. Our answers to your other questions are in below, each starting with "[YK]". We will submit the new version containing these changes soon.

*** Substantive ***

-- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a syntax violation."

Does that mean that setting the bit is a syntax violation in itself, or that it _indicates_ a syntax violation? As worded, it sound like the former, but later examples seem to suggest the latter. (e.g. last sentence of 4.4.3)

[YK]: It is the former from the HEVC spec point of view. The HEVC spec just says that the value of the bit shall be equal to 0. A MANE (in the context of this memo) can use the bit to indicate a syntax violation, as you noticed in the last sentence of 4.4.3. We will change the wording as follows (plus the addition of RFC 3828 as an informative reference) unless there is objection:

[Current wording]
forbidden_zero_bit.  Required to be zero in [HEVC].  HEVC declares a value of 1 as a syntax violation.  Note that the inclusion of this bit in the NAL unit header is to enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S].

[Changed wording]
forbidden_zero_bit.  Required to be zero in [HEVC].  Note that the inclusion of this bit in the NAL unit header was to enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S].  In the context of this memo, the value 1 MAY be used to indicate a syntax violation.  For example, when RTP is transported over UDP-lite [RFC3828] and the receiver decides to feed the video decoder NAL unit(s) where the corresponding UDP-lite packet failed a checksum test, then this bit can be set to alarm the decoder of possible bit errors.

-- 4.4.4, "F1, F2"

Does this paragraph impoy a requirement for the receiver to ignore non-zero values? If so, it would be good to state it explicitly.

[YK]: Yes, receivers need ignore non-zero values and the corresponding extension data. We added the following to the semantics:

Receivers compliant with this version of the HEVC payload format MUST ignore F1=1 and/or F2=1, and also ignore any information in the PHES indicated as present by F1=1 and/or F2=1.
Informative note: The receiver can do that by first decoding information associated with F0=1, and then skipping over any remaining bytes of the PHES based on the value of PHSsize.

Similar change was done to the semantics of the Y bit at the same place.

-- 4.4.4.2 and 4.5:

Has the working group considered whether PACI extensions need a registry?

[YK]: Stephan answered the question in a separate email. It was considered, and no need was identified.

-- 7.1, "max-cbp" "When not present, the value of max-cpb is inferred to..."

The analogous statements for previous parameters used a normative MUST.  
Is there a reason not to be consistent, one way or the other?  (Same for max-dpb and max-tr)

[YK]: I checked throughout the document but did not find inference of a parameter using the MUST wording. When expressing the value ranges, the MUST wording is used. Please let me know if there is indeed such an inconsistency (which should be corrected if yes).

-- table 1, Legend, last entry: "not usable, when present SHOULD be ignored"

Why not MUST? Can you envision circumstances where it might make sense to _not_ ignore them?

[YK]: Good question. I quickly checked one by one and could not think out any such circumstance. Thus I'd agree that using MUST would be better. Is there a different opinion? 

[YK]: Same as above. I'd agree also here that using MUST is better. Is there a different opinion?

-- 7.2.5, 2nd sentence:

This is confusing as written. It may not be clear to all readers whether
  the SHALL NOT after the I.e. Intended as a new normative statement, or an example of the bits of 4566 that do not apply.

[YK]: The text is clarified as follows: "The rules on "hierarchical or layered encoding" with multicast in Section 5.7 of [RFC4566] do not apply.  This means that the notation for Connection Data "c=" SHALL NOT be used with more than one address, i.e. the sub-field <number of addresses> in the sub-field <connection-address> of the "c=" field, described in [RFC4566], must not be present."

-- section 9

Please use the updated security considerations boilerplate from draft-ietf-payload-rtp-howto-14.

[YK]: I think the security considerations boilerplate we used is aligned with draft-ietf-payload-rtp-howto-14 already, but OK, we will make sure it is exactly the same.

-- General:

There is a running theme of convoluted sentence structure with lots of nested clauses. At least for me, that makes reading it harder necessary. 
I've flagged some instances below, but the draft would benefit from an editorial pass to reduce these. (This is not a show-stopper, just a suggestion for potential improvement.)

[YK]: I checked all the figures, and noticed the issue for Fig. 11 and Fig. 12. Corrected in the to-be-submitted next version. 

[YK]: Sure. Added.

Long, convoluted sentence. Can it be broken down into a few simpler sentences?

[YK]: Sure. Changed to the following:

The profile, tier and level syntax structure also includes indications such as 1) whether the bitstream is free of frame-packed content, 2) whether the bitstream is free of interlaced source content, and 3) whether the bitstream is free of field pictures. When the answer is yes for both 2) and 3), the bitstream contains only frame pictures of progressive source.  Based on these indications, clients/players without support of post-processing functionalities for handling of frame-packed, interlaced source content or field pictures can reject those bitstreams that contain such pictures.

[YK]: Good catch. Added.

[YK]: OK, I will replace the two occurrences of "this information" to "those information". Also for the one place in 4.1, I think. Let me know if that is not the case.

[YK]: 3.1.1 contains definitions from the HEVC specification as they are. Thus, I think we should just keep this as is here. The reason for the definition to be a single long sequence in the HEVC spec was because there is a rule of the ISO to have each definition to contain exactly one sentence (don't ask me why :-).

Convoluted sentence structure. The last sentence of the immediately following informative note is also convoluted.

[YK]: We can split the first sentence into two sentences as follows:

Set for the last packet carried in the current RTP stream of the access unit.  This is in line with the normal use of the M bit in video formats to allow an efficient playout buffer handling.

And split the last sentence in the note as follows:

A NAL unit is determined to be the last NAL unit of an access unit if it is the last NAL unit of the bitstream.  A NAL unit naluX is also determined to be the last NAL unit of an access unit if both the following conditions are true: 1) the next VCL NAL unit naluY in decoding order has the high-order bit of the first byte after its NAL unit header equal to 1, and 2) all NAL units between naluX and naluY, when present, have nal_unit_type in the range of 32 to 35, inclusive, equal to 39, or in the ranges of 41 to 44, inclusive, or 48 to 55, inclusive.

-- 4.1, last paragraph:

The text has already used the term bitstream quite a bit. Perhaps this note should occur earlier, possibly in the definitions?

[YK]: Good suggestion. I moved it to 3.1.2, immediately after the definition of Media Transport, where the reference to [I-D.ietf-avtext-rtp-grouping-taxonomy] is firstly made in the document.

-- 4.2, "Fragmentation Units (FUs) specified in Section 4.4.3. APs MUST NOT be nested; i.e. an AP MUST NOT contain another AP."

That construction gives you redundant 2119 keywords. I suggest the "i.e." clause be stated descriptively, not normatively.  (Note: This construction occurs several times)

[YK]: Changed as suggested. Also for two other places (both in 4.4.3 on FUs).

-- 7.2.2, informative note after the bullet starting with "The parameters sprop-max-don-diff..." :

[YK]: We can split the sentence as follows:

The above parameters apply for any RTP stream and all RTP streams the RTP stream depends on, when present, sent by a declaring entity with the same configuration.  In other words, the applicability of the above parameters to RTP streams depends on the source endpoint.

-- 9, 3rd to last paragraph, starting with "Note that the appropriate mechanism..."

[YK]: Agree to remove this paragraph.

Best Regards,
Ye-Kui (on behalf of the authors)

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Tuesday, May 26, 2015 2:25 PM
To: Stephan Wenger
Cc: [email-masked]; [email-masked]
Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

Ben.

On 26 May 2015, at 15:48, Stephan Wenger wrote:

> (draft-wenger-payload-h265-payload-header-extension-00) already 
> included a reminder that the option of using a registry needs to be 
> discussed.  The proposal, however, was not to use a registry, as 1) 
> the allocated code point space was deemed sufficient for future needs, 
> and 2) both H.265 and the payload format are under tight control of 
> the respective organizations
> Thereafter, Magnus found that the original extension mechanism was 
> broken, and there was a considerable amount of discussion on this 
> subject on the mailing list and in private (approximately March/April 
> 2014).  In none of these discussions a need for the use of a registry was asserted.
>
> Stephan

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