Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-07.txt

From: [email-masked]
Date: Thu, 10 Sep 2009 10:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : RTP Payload Format for H.264 Video
	Author(s)       : Y. Wang, et al.
	Filename        : draft-ietf-avt-rtp-rfc3984bis-07.txt
	Pages           : 104
	Date            : 2009-09-10

This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec, excluding the
Scalable Video Coding (SVC) extension and the Multivew Video Coding
extension, for which the RTP payload formats are defined elsewhere.
The RTP payload format allows for packetization of one or more
Network Abstraction Layer Units (NALUs), produced by an H.264 video
encoder, in each RTP payload.  The payload format has wide
applicability, as it supports applications from simple low bit-rate
conversational usage, to Internet video streaming with interleaved
transmission, to high bit-rate video-on-demand.

This memo obsoletes RFC 3984.  Changes from RFC 3984 are summarized
in section 18.  Issues on backward compatibility to RFC 3984 are
discussed in section 17.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984bis-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 10 Sep 2009 14:52:04 -0400

Changes compared to -06:
- Added media type parameters max-recv-level, and level-asymmetry-allowed,
to allow for level upgrade in SDP offer/answer.
- Updated out-of-band and in-band transport of parameter sets, partly due to
the addition of level upgrade support. 
- Added Randell Jesup as a co-author. 
- Resolved comments from Ali Begen and Aaron Wells on transmission of
picture timing SEI messages and an informative not related to decoding
order, RTP timestamps and inter-arrival jitter. 

BR, YK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, September 10, 2009 1:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-07.txt
> 
> Recommendation H.264 video codec and the technically 
> identical ISO/IEC International Standard 14496-10 video 
> codec, excluding the Scalable Video Coding (SVC) extension 
> and the Multivew Video Coding extension, for which the RTP 
> payload formats are defined elsewhere.
> The RTP payload format allows for packetization of one or 
> more Network Abstraction Layer Units (NALUs), produced by an 
> H.264 video encoder, in each RTP payload.  The payload format 
> has wide applicability, as it supports applications from 
> simple low bit-rate conversational usage, to Internet video 
> streaming with interleaved transmission, to high bit-rate 
> video-on-demand.
> 
> This memo obsoletes RFC 3984.  Changes from RFC 3984 are 
> summarized in section 18.  Issues on backward compatibility 
> to RFC 3984 are discussed in section 17.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 10 Sep 2009 21:46:29 -0400

I would like to initiate a second Working Group Last Call for this document. 
Let's make it 10 days, to September 20.

Tom Taylor

Ye-Kui Wang wrote:
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 17 Sep 2009 15:46:39 -0400

I have spotted some minor bugs when working to align the SVC payload draft
with this draft, listed below. Should a new version be submitted for these
changes (as received WGLC comments)?

1) Section 4.1: The definition of "maximum receive level" is not referenced
in the text, and therefore should be removed.

2) Section 8.1, semantics of profile-level-id: In the sentence "If
max-recv-level is present it indicates the highest level the codec supports
for receiving, for use in asymmetric exchanges.", the latter part, i.e., ",
for use in asymmetric exchanges" should be removed, as the use of the
parameter should not be limited only to asymmetric exchanges. This was
agreed earlier between co-authors, but for some reason it did not get
removed.

3) Section 8.1, semantics of max-rece-level: The semantics did not take into
account that level 1b for profiles other than Baseline, Main and Extended
profiles is signaled using level_idc equal to 9. Therefore, the sentences 

"If the level_idc byte of max-recv-level is equal to 11, and bit 4 of the
profile-iop byte of max-recv-level is equal to 1, the highest level the
receiver supports is level 1b.  If bit 4 of the profile-iop byte of
max-recv-level is equal to 0, the highest level the receiver supports is
equal to the level_idc byte of max-recv-level divided by 10."

should be changed to

"If (the level_idc byte of max-recv-level is equal to 11 and bit 4 of the
profile-iop byte of max-recv-level is equal to 1) or (the level_idc byte of
max-recv-level is equal to 9 and bit 4 of the profile-iop byte of
max-recv-level is equal to 0), the highest level the receiver supports is
level 1b.  Otherwise, the highest level the receiver supports is equal to
the level_idc byte of max-recv-level divided by 10."

4) Section 8.1, semantics of max-br:  In the sentence "The value of max-br
replaces the MaxBR value n Table A-1 of [1] for the highest level.", 'n'
should be changed to "in".

5) Section 8.2.2, usage of max-recv-level: The following sentence 

" "max-recv-level" MUST be higher than the default level. "

should be changed to 

" "max-recv-level", when present, MUST be higher than the default level. "

6) Section 8.2.2, usage of sprop-parameter-sets and
sprop-level-parameter-sets: A ')' is missing in the following sentence and
should be added after "... in the offer".

"Otherwise (the level to use in the offerer-to-answerer direction is not
equal to the default level in the offer, the following applies."

7) Section 8.2.2, usage of sprop-parameter-sets and
sprop-level-parameter-sets: A ')' is missing in the following sentence and
should be added after "... in the answer".

"Otherwise (the level to use in the answerer-to-offerer direction is not
equal to the default level in the answer, the following applies."

8) Section 8.2.2, usage of sprop-parameter-sets and
sprop-level-parameter-sets: There is a typo in the following sentence, the
word "in" should be removed from "in as specified in section 6.3 of [9]".

" When "sprop-parameter-sets" or "sprop-level-parameter-sets" is conveyed
using the "fmtp" source attribute in as specified in section 6.3 of [9], the
receiver of the parameters MUST store the parameter sets included in the
"sprop-parameter-sets" or "sprop-level-parameter-sets" for the accepted
level and associate them to the source given as a part of the "fmtp" source
attribute. "

9) Section 15.1, reference [9]: The reference should be updated as the RFC
number, 5576, is now available. 

BR, YK 

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Thursday, September 10, 2009 9:46 PM
> To: Ye-Kui Wang
> Cc: [email-masked]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-07.txt
> 
> > - Added media type parameters max-recv-level, and 
> > level-asymmetry-allowed, to allow for level upgrade in SDP 
> offer/answer.
> > - Updated out-of-band and in-band transport of parameter 
> sets, partly 
> > due to the addition of level upgrade support.
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> [email-masked]
> >> This draft is a work item of the Audio/Video Transport 
> Working Group 
> >> of the IETF.
> >>
> >>
> >> Network Abstraction Layer Units (NALUs), produced by an
> >> H.264 video encoder, in each RTP payload.  The payload format has 
> >> wide applicability, as it supports applications from simple low 
> >> bit-rate conversational usage, to Internet video streaming with 
> >> interleaved transmission, to high bit-rate video-on-demand.
> >>
> summarized

---

From: Tom Taylor <[email-masked]>
Date: Thu, 17 Sep 2009 15:54:53 -0400

Thank you. Please handle these as WGLC comments along with any others you receive.

---

From: Roni Even <[email-masked]>
Date: Mon, 21 Sep 2009 17:44:29 +0300

Hi Tom,
I think that we can ask YK to put a draft with his editorial changes and
send it to publication
Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Taylor
> Sent: Friday, September 11, 2009 4:46 AM
> To: Ye-Kui Wang
> Cc: [email-masked]
> >> Working Group of the IETF.
> >>
> >>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 21 Sep 2009 14:34:58 -0400

Agreed.