Last Call Review of draft-ietf-payload-rtp-h265-13

Request Review of draft-ietf-payload-rtp-h265
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-14
Requested 2015-08-09
Authors Ye-Kui Wang, Yago Sanchez, Thomas Schierl, Stephan Wenger, Miska Hannuksela
Draft last updated 2015-08-23
Completed reviews Genart Last Call review of -13 by Brian Carpenter (diff)
Genart Telechat review of -14 by Brian Carpenter (diff)
Genart Telechat review of -15 by Brian Carpenter
Opsdir Last Call review of -13 by Qin Wu (diff)
Assignment Reviewer Qin Wu 
State Completed
Review review-ietf-payload-rtp-h265-13-opsdir-lc-wu-2015-08-23
Reviewed rev. 13 (document currently at 15)
Review result Has Issues
Review completed: 2015-08-23


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



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



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




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



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



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



Best Regards!

-Qin Wu