Subject: Re: [payload] FW: New Version Notification for draft-wenger-payload-h265-payload-header-extension-00.txt

From: "Wang, Ye-Kui" <[email-masked]>
Date: Fri, 4 Oct 2013 17:03:48 +0000

Hi Stephan, All,

We had a plan to introduce the signalling of the index of pictures with TemporalId equal to 0. Thus thanks for the draft targeting for fulfilling that plan. I think we should agree on one approach for this, and include the agreed approach into draft-ietf-payload-rtp-h265-01. Preferably, to meet the milestone of draft-ietf-payload-rtp-h265, we should have draft-ietf-payload-rtp-h265-02 (with the agreed approach included) submitted before the next IETF meeting.

Among the two approaches included, I prefer option 2 (the one that can save two bytes for each PACI packet), but with a slight change of the order of the bits to largely reduce the irregularity - as the main drawback of the current option 2 is that there is no real PayloadHdr field immediately following the RTP header. This change would be: 
	- Move PayloadHdr of the contained NAL unit immediately after the RTP header, set the Type field to the PACI type value.
	- After PayloadHdr, put the original Type of contained NAL unit, then PHSsize etc. as in the draft.

Some less important comments and nits:
- It seems that PHSsize does not count the bytes of the flags between PHSsize and PHS. It should be slightly better to let it cover the bytes of the flags too, such that parsing of the flags and PHS can be skipped if desirable, e.g. in handling of a recorded RTP stream. 

- In the figure for option 2, the three flags F[0..2] occupy 4 bit positions in the figure.

- The style of the first two figures (depicting options 1 and 2) are not aligned with the payload structure figures in into draft-ietf-payload-rtp-h265-01. The style of last figure (depicting the PHS structure) is aligned. For example, in the first figure, it seems that both PHS and the contained NAL unit contain integer number of 32 bits.

- It is specified that a PACI payload can be a FU or an AP (the wording of "fragment" and "aggregation NAL unit" in sections 6.3 and 6.4 in the draft make these aspects not really clear, but I guess the intent was to mean FU and AP, respectively), but it is not specified whether a PACI payload can be a single NAL unit packet. I think it would be nice to allow a single NAL unit packet to be a PACI payload too.

- Re the following note: Why a larger field is desirable?
   Note: one of the authors' implementation experience suggests that a 
   larger field for TL0PICIDX may be desirable.  The 8 bit field 
   proposed above is aligned with H.265's SEI message.   

- The term "layer representation" used in the draft is not defined in HEVC or draft-ietf-payload-rtp-h265-01. It should be replaced with "picture".

- "Nal unit" in the semantics of the E bit should be changed to "NAL unit".

BR, YK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephan Wenger
> Sent: Thursday, September 26, 2013 1:19 PM
> To: [email-masked]
> Cc: Jonathan Lennox; Jill Boyce
> Subject: [payload] FW: New Version Notification for draft-wenger-payload-
> h265-payload-header-extension-00.txt
> 
> Hi all,
> 
> In Berlin's payload session presentation of the H.265 payload format
> (graciously hosted by AVTcore), I mentioned that we want to include support
> for temporal scalability in the draft H.265 payload format.
> Attached a quick draft showing how this could be done--basically a (we
> believe) improved variant of the PACSI NAL unit of RFC 6190.  There are two
> alternative proposals in the draft, trading off alignment with design principles
> of H.265 one one side and efficiency on the other.
> 
> Vidyo has IPR on this draft, which we will make available under terms like
> this: https://datatracker.ietf.org/ipr/1622/.  I believe that the concepts of this
> draft should be included in the H.265 payload format itself, rather than being
> stand-alone.  Once that happens, or if the group decides the draft to stay
> stand-alone, we will file the official IPR disclosure against the then-current
> and appropriate document, so not to clutter the database.
> 
> Comments welcome.
> 
> Thanks,
> Stephan
> 
> 
> 
> On 9.26.2013 13:08 , "[email-masked]" <[email-masked]>
> wrote:
> 
> >
> >A new version of I-D,
> >draft-wenger-payload-h265-payload-header-extension-00.txt
> >has been successfully submitted by Stephan Wenger and posted to the
> >IETF repository.
> >
> >Filename:	 draft-wenger-payload-h265-payload-header-extension
> >Revision:	 00
> >Title:		 H.265 Payload Header Extension and Temporal Scalability
> Support
> >Creation date:	 2013-09-26
> >Group:		 Individual Submission
> >Number of pages: 10
> >URL:
> >http://www.ietf.org/internet-drafts/draft-wenger-payload-h265-payload-h
> >ead
> >er-extension-00.txt
> >Status:
> >http://datatracker.ietf.org/doc/draft-wenger-payload-h265-payload-heade
> >r-e
> >xtension
> >Htmlized:
> >http://tools.ietf.org/html/draft-wenger-payload-h265-payload-header-ext
> >ens
> >ion-00
> >
> >
> >Abstract:
> >   Proposed are the allocation of a NAL unit type from the
> >   "unspecified" set of NAL units of H.265 [HEVC] for the purpose of
> >   payload header extensions, a generic syntax for the use of that
> >   pseudo NAL unit, and one application for it: the signaling of
> >   temporal scalability support information.  Two alternative designs
> >   are included.  The content of this draft is intended for
> >   incorporation into the H.265 RTP payload [h265-payload].
> >
> >
> >
> >
> >
> >
> >
> >Please note that it may take a couple of minutes from the time of
> >submission until the htmlized version and diff are available at
> >tools.ietf.org.
> >
> >The IETF Secretariat
> >
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload