Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-04.txt

From: [email-masked]
Date: Fri, 27 May 2005 15:42:13 -0400

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 AC-3 Audio
	Author(s)	: J. Flaks, et al.
	Filename	: draft-ietf-avt-rtp-ac3-04.txt
	Pages		: 11
	Date		: 2005-5-27
	
This document describes an RTP payload format for transporting AC-3 
encoded audio data.  AC-3 is a high quality, multichannel audio coding 
system used in US HDTV, DVD, cable and satellite television and other 
media.  The RTP payload format as presented in this document includes 
support for data fragmentation.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-ac3-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-ac3-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 May 2005 11:24:12 +0200

Hi Brian

I have reviewed the updated version and basically think it is fine. 
However I have the following comments. I think only two are really 
significant and probably should be addressed or at least discussed 
before going to working group last call.

1. Clarification on how to determine when the next frame starts. I think 
one should add a sentence clarifying how one determines where the next 
frame begins in payloads with FT=0. After looking at the codec 
specification I determined from the bit-stream syntax that the 
"frmsizecod" in the syncinfo block provides this information for each 
frame. However I think one should point out that one actually on a 
payload depacketizer level has to go in and read these bits to determine 
the length of the AC-3 frame and thus determine where the next starts.

I would suggest the following text to be added to section 4.1 after 
figure 4.

"When receiving AC-3 payloads with FT=0 and more than a single frame (NF 
 > 0), a receiver needs to use the "frmsizecod" field in the 
synchronization information (syncinfo) block in each AC-3 frame to 
determine the frame's length. That way a receiver can determine where 
the next frame will start."

2. The limitation on BSI in section 5.1. Why is BSI limited to not be 
greater than 8? As the RTP payload format provides the parameters to 
negotiate this if using offer/answer two peers can determine the highest 
BSI value supported by the receiver. Thus one could in the future use 
the same payload format for updated bit-stream formats as long as the do 
not violate the basic requirements this payload format is built on 
(frmsizecod field present, 5/8th is decodable).

So please clarify if there is any problem you foresee with above 
proposal. Otherwise I would recommend that the following sentence is 
simply removed: "Values greater than 8 MUST NOT be used with this 
payload format."

Editorial comments:

E1: The bit-numbering in figure 3 is missalinged. Both the tens and 
single numbers needs one space in the beginning.

E2. Section 5.1, Encoding consideration.
Please remove the current two sentenced and replace it with "Framed". 
See section 4.8 in the following draft:

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt

E3. Section 7: I would like to reorder the text in the paragraph for 
better clarify.

"The general congestion control considerations for transporting RTP data 
apply to AC-3 audio over RTP as well, see RTP [RFC3550], and any 
applicable RTP profile (e.g. [RFC3551]).

AC-3 encoders may use a range of bit rates to encode audio data, so
it is possible to adapt network bandwidth by adjusting the encoder
bit rate in real time or by having multiple copies of content encoded
at different bit rates.  Additionally, packing more frames in each RTP 
payload can reduce the number of packets sent and hence the overhead 
from IP/UDP/RTP headers, at the expense of increased delay and reduced 
error robustness against packet losses."

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]