Subject: Re: [payload] WGLC for H.265 - RTP Payload Format for High Efficiency Video Coding - comments

From: "Wang, Ye-Kui" <[email-masked]>
Date: Wed, 2 Jul 2014 00:11:52 +0000

Hi Roni,

Thanks a lot for your review and comments. Please find my replies inline below. Some of the replies were from both Stephan (Wenger) any myself, as we discussed how to reply together in Sapporo Japan.

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Monday, June 30, 2014 6:10 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [payload] WGLC for H.265 - RTP Payload Format for High Efficiency Video Coding - comments

Hi,
I reviewed the documents and have some comments as individual!!!!

In section 1.1.4 "forbidden_zero_bit.  MUST be zero.". What does the MUST mean if in section 4.8 the f bit can be set to 1. What is the behavior in this case when the bit is set to 1?

[YK]: Good spotting. Stephan and I discussed this, and we think that we can just change "MUST be zero" in section 1.1.4 to say that the value is required to be equal to 0 in the HEVC spec. Section 1.1.4 is anyway a part of an introduction and overview of the HEVC specification.  We will do the same for the nuh_layer_id semantics as well in Section 1.1.4.

In section 7.1 missing person & email address to contact

[YK]: OK, will add that in the next version.

In section 7.2.2 "The profile-compatibility-indicator, when offered as sendonly,  describe bitstream properties.  The answerer MAY accept an RTP payload type even if the decoder is not capable of handling the  profile indicated by the profile-space, profile-id, and interop- constraints parameters, but capable of any of the profiles  indicated by the profile-space, profile-compatibility-indicator, and interop-constraints.  However, when the profile-compatibility-indicator is used in a recvonly or sendrecv media description, the bitstream using this RTP payload type is required to conform to all profiles indicated by profile-space, profile-compatibility-indicator, and interop-constraints."  I do not understand this case can you explain why this behavior?

[YK]: This is because of the semantics of the profile related parameters profile-space, profile-id, interop-constraints, and profile-compatibility-indicator as specified in the HEVC spec.

Let me use an example to explain.

Firstly on the part before "However". Let's say the profile-compatibility-indicator have two flags set, corresponding to profiles A and B, respectively. Meanwhile, the profile indicated by the profile-space, profile-id, and interop-constraints parameters may be just profile A. When such profile-compatibility-indicator indicates a bitstream property, that means the bitstream is encoded using only tools that are common for profiles A and B, and thus a decoder conforming to either profile A or profile B can decode the bitstream, i.e. the decoder does not have to be conforming to profile A.

Now, on the part starting with "However". When such profile-compatibility-indicator indicates decoder capability, it really indicates that the decoder implements only the common tools of profiles A and B. This part just says that this is the case.

Please let us know if you think some clarification such as this should be added to the draft.

In section 7.2.2 "see the semantics of sprop-vps on one video parameter set being consistent with another video parameter set". Please provide reference.

[YK]: OK, will provide a cross reference to the section for the semantics of sprop-vps.

In section 7.2.2 "rules apply to transport of parameter set in the answerer-to-offerer direction" . What happens when the RTP is received before the SDP answer?

[YK]: I guess you meant in the early media cases for reduced start up delay.  Stephan and I agreed that we can just say something like, in case some RTP stream(s) are sent before SDP offer/answer settles down, in-band parameter sets MUST be used for those RTP stream parts sent before the SDP offer/answer.

In section 7.2.4 Parameter Sets Considerations what about the different multipoint topologies?

[YK]: Roni, Stephan and I tried to understand what you might mean, but we could not figure it out. Could you please clarify? Thanks!

Thanks

Roni

From: Roni Even [mailto:[email-masked]]
Sent: 11 June, 2014 12:59 PM
To: [email-masked]'
Cc: [email-masked]<mailto:[email-masked]>
Subject: WGLC for H.265 - RTP Payload Format for High Efficiency Video Coding

WG,

This is to start the WGLC for the RTP Payload Format for High Efficiency Video Coding (H.265) draft http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-04
The WGLC is for three weeks till July 3rd

Please send your comments and approvals to the payload list.

Authors, please let the WG chairs know if you are aware of any undeclared  IPR related to this draft. It is needed for the publication request.

Thanks

Roni Even

Payload co-chair