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

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

Review
review-ietf-payload-rtp-h265-13-opsdir-lc-wu-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




   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