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

From: "Jonathan Lennox" <[email-masked]>
Date: Mon, 2 Mar 2009 12:42:46 -0500

This looks good.  No substantive comments, but a few editorial ones:

* In the description of in-band-parameter-sets, it should probably be
made clear that a sender MAY choose to send parameter sets in-band even
if a receiver said in-band-parameter-sets=0.  This is clear in the
description later, but having it up front might help prevent interop
difficulties.

* Two wording issues in new text:

Section 7:
 The same output means that the number of NAL units and their order	
 are both identical respectively.

I don't think "respectively" is correct here, and "both" is redundant.
I'd also question "the number of", since it's not just the number of NAL
units, but actually the NAL units themselves.  Suggested wording:

 The same output means that the resulting NAL units, and their order,
are identical.	

In the description of in-band-parameter-sets:

	When the parameter is not present, this receiver	
	capability is not specified, and therefore the sender MAY send	
	out-of-band parameter sets only, or it MAY send in-band-	
	parameter-sets only, or it MAY send both to make sure the	
	system work.

"to make sure the system work" is not grammatical (the verb would need
to be "works"), and also is a bit informal in tone for a standards
document.   Suggested replacement: "for robustness".

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> -----Original Message-----
> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Monday, February 23, 2009 1:29 PM
> To: [email-masked]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-03.txt
> 
> 
> 
> We have addressed all the WGLC comments sent to the mailing list. Here
> is a
> summary of main changes related to -02:
> 
> - Updated the boiler template
> - Updated the definitions of "default sub-profile" and "default level"
> - Added an optional media type parameter, in-band-parameter-sets, to
> enable
> a receiver to indicate that it needs in-band parameter sets
> - In section 8.4 (parameter set considerations), added a reference of
> the
> rules of in-band and out-of-band parameter sets in section 8.2.2
> - Updated section 11 (IANA Consideration)
> - Updated authors' addresses (Ye-Kui is now with Huawei Technologies)
> - Updated sections 17 (Backward Compatibility to RFC 3984) and 18
> (Changes
> from RFC 3984)
> 
> Thanks again to everyone who has reviewed the draft and provided WGLC
> comments!
> 
> BR, YK
> (on behalf of all authors)
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of [email-masked]
> > Sent: Monday, February 23, 2009 12:15 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-03.txt
> >
> > 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-03.txt
> > 	Pages           : 97
> > 	Date            : 2009-02-23
> >
> > 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-rfc3984
> > bis-03.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.
> >
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 02 Mar 2009 13:19:08 -0500

Thanks for your comments. See inline, please. 

> From: Jonathan Lennox [mailto:[email-masked]] 
> Sent: Monday, March 02, 2009 12:43 PM
> To: Ye-Kui Wang; [email-masked]
> Subject: RE: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-03.txt
> 
> * In the description of in-band-parameter-sets, it should 
> probably be made clear that a sender MAY choose to send 
> parameter sets in-band even if a receiver said 
> in-band-parameter-sets=0.  This is clear in the description 
> later, but having it up front might help prevent interop difficulties.
> 

OK.

> I'd also question "the number of", since it's not just the 
> number of NAL units, but actually the NAL units themselves.  
> Suggested wording:
> 

Very good description - accepted. 

> "to make sure the system work" is not grammatical (the verb 
> would need to be "works"), and also is a bit informal in tone 
> for a standards

Sending both is helpful for robustness, but that is not the only one. It is
also helpful for a topology wherein a node has multiple nodes in behind,
some of which want out-of-band parameter sets, and the others want in-band
parameter sets. Therefore, we can just remove "to make sure the system
work". 

BR, YK