Last Call Review of draft-ietf-payload-rtp-h265-13
review-ietf-payload-rtp-h265-13-opsdir-lc-wu-2015-08-23-00

I have reviewed draft-ietf-payload-rtp-h265-13 as part of the Operational
directorate's ongoing effort to review all IETF

documents being processed by the IESG.  These comments were written

with the intent of improving the operational aspects of the IETF

drafts. Comments that are not addressed in last call may be included

in AD reviews during the IESG review.  Document editors and WG chairs

should treat these comments just like any other last call comments.



Short Summary

This document specifies RTP Payload format for H.265. there are no operational
or

management concerns in this document. I believe it is ready for publication
with tiny nits. I also have a few minor comments which authors of this document
might consider.



1.Section 1.1.1, in-loop filtering bullet

Suggest to add a short name “DBF” for deblocking filter and provide a reference
to it.

2.Section 1.1.1, in-loop filtering bullet

Suggest to give a definition for de-ring filter or add a reference to it. In
addition, it is better to have a consistent term, e.g., deblocking and
deringomg or de-blocking and de-ringing

3.Section 1.1.2, 1st paragraph said

“

In the following, a list of differences in these

aspects compared to H.264 is summarized.

……

”

The introduction is too long, Would it be great to have this non-normative part
on difference between H.264 and H.265 moving to appendix of this document

And add an anchor point pointing to the appendix.

4.Section 1.1.2

Suggest to add a short name for picture order count



5.Section 1.1.3 , 1st paragraph said:

“

The reportedly significantly higher encoding computational demand

   of HEVC over H.264, in conjunction with the ever increasing video

   resolution (both spatially and temporally) required by the

   market

”

Is this marketing promotion? Is there any other technical reason for that?
Suggest to remove “required by the market”.

6.Section 1.1.3, 2nd paragraph said:

“

Specifically, for parallelization, four

   picture partition strategies are available.

”

What are four picture partition strategies? Where are they specified?

7.Section 1.1.4 said:

“

   TID: 3 bits

      nuh_temporal_id_plus1.  This field specifies the temporal

      identifier of the NAL unit plus 1.  The value of TemporalId is

      equal to TID minus 1.

”

is the temporal identifier TemporaId ? Is the temporal identifier a full name
of TID?

8.Section 1.1.4 also said:

“

A TID value of 0 is illegal to ensure

      that there is at least one bit in the NAL unit header equal to

      1, so to enable independent considerations of start code

      emulations in the NAL unit header and in the NAL unit payload

      data.

”

Which bit is set to 1 in the NAL Unit Header?

9.Section 4.3 said:

“

Informative Note: While this specification enables the use of

  MRST within the H.265 RTP payload, the signaling of MRST within

  SDP Offer/Answer is not fully specified at the time of this

  writing. See [RFC5576] and [RFC5583] for what is supported

  today as well as [I-D.ietf-avtcore-rtp-multi-stream] and [I-

  D.ietf-mmusic-sdp-bundle-negotiation] for future directions.



”

It looks like an open issue? Would it be good to add a statement to replace
this informative note, e.g., we can say how SDP Offer/Answer is extended to
support signaling of MRST is a generic issue that should be tackled by
[I-D.ietf-avtcore-rtp-multi-stream] and
[I-D.ietf-mmusic-sdp-bundle-negotiation], is not in the scope of this document.

10.Section 4.3 also said:

“

When an RTP stream A depends on another RTP stream B, the RTP

 stream B is referred to as a dependee RTP stream of the RTP

 stream A.

”

Why have the last sentence when the definition of dependee RTP stream has
already been given in the section 3.1.2? It seem the last sentence is redundant.

11.Section 7.2.5

Miss a blank space between “7.2.5” and “Dependency” in the title of section
7.2.5

12.Section 8.3,2nd paragraph said:

“

even a decoded picture buffer size

   of two would work for the approach described in the previous

   paragraph.

“



Buffer size of two? Two bytes or other buffer size in other unit?

13.Section 9, 3rd paragraph:

I don’t understand the last part of this sentence, what does domain or
presentation stand for in this context? How are they corresponding to
parameters defined RTP payload format for H.264?

Would it be great to add some explanation text to clarify this?



14.Run IDNits tool, it produce

  Checking references for intended status: Proposed Standard

  ----------------------------------------------------------------------------



     (See RFCs 3967 and 4897 for information about using normative references

     to lower-maturity documents in RFCs)



  -- Looks like a reference, but probably isn't: '0' on line 1749



  == Unused Reference: 'RFC6190' is defined on line 3841, but no explicit

     reference was found in the text



  == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on

     line 3878, but no explicit reference was found in the text



  -- Possible downref: Non-RFC (?) normative reference: ref. 'HEVC'



  == Outdated reference: A later version (-08) exists of

     draft-ietf-avtcore-rtp-multi-stream-05



  == Outdated reference: A later version (-23) exists of

     draft-ietf-mmusic-sdp-bundle-negotiation-02



  == Outdated reference: A later version (-08) exists of

     draft-ietf-avtext-rtp-grouping-taxonomy-02



Best Regards!

-Qin Wu