Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-03.txt

From: [email-masked]
Date: Tue, 17 May 2005 15:44:14 -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 ATRAC Family
	Author(s)	: M. Romaine, et al.
	Filename	: draft-ietf-avt-rtp-atrac-family-03.txt
	Pages		: 22
	Date		: 2005-5-17
	
This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Codec (ATRAC) family of codecs.  Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, auxiliary
   data, and elementary redundancy measures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-03.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-atrac-family-03.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-atrac-family-03.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: Matthew Romaine <[email-masked]>
Date: Wed, 18 May 2005 14:42:57 +0900

Hi all,

As noted below, there is a new revision of the ID outlining a payload  
for ATRAC content.  Key changes include clarifying the SDP parameters  
and Offer/Answer exchange.  An auxiliary data section has also been  
added.

Would appreciate any comments from the community.  We have most of  
the draft implemented, so whatever else needs to happen before last  
call I'm ready to address.

Cheers,
Matt

Begin forwarded message:

> From: [email-masked]
> Date: 2005年5月18日 4:44:14:JST
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-03.txt
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>

-------------------------------------------
Tel: +81-3-5448-6065
Fax: +81-3-5448-5617
ITCNC PCD Audio Codec Dev Dept.1
Sony Corporation, Japan
-------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Wed, 18 May 2005 21:02:03 +0100

Matthew,

On 18 May 2005, at 06:42, Matthew Romaine wrote:
> As noted below, there is a new revision of the ID outlining a  
> payload for ATRAC content.  Key changes include clarifying the SDP  
> parameters and Offer/Answer exchange.

These changes are a definite improvement.

> An auxiliary data section has also been added.

The auxiliary data section was introduced in the -02 revision. I  
think the presence of this section is a mistake: it's better to  
signal extensions in the signalling protocol, rather than allowing  
undocumented auxiliary data. We don't typically allow such undefined  
extension fields in RTP payload formats.

> call I'm ready to address.

I have a few details, in addition to the major issue noted above:

In section 4.2 it's stated that "ATRAC frames may be of fixed or  
variable octet sizes". It might be clearer to explain that "ATRAC  
frames may be of fixed or variable length", to avoid the implication  
that the size of the octet varies.

In section 5.1, "defined out-of-bounds" should read "defined out-of- 
band".

In section 5.2.1, it should be sufficient to say "The ATRAC family  
payload header is two octets" rather than "The ATRAC family header is  
a scant two octets. This should make processing very simple".

In section 5.2.1, would it make sense for FrgNo to start from 0 for  
the first fragment, for consistency with NFrames?

The FrOff field is introduced in section 5.2.1, but not explained  
until section 5.2.3. You should include a reference from section  
5.2.1 forward to section 5.2.3.  That said, I recommend the FrOff  
field is removed, as it can be inferred from the RTP timestamp and  
the number of ATRAC frames included in each packet.

In section 5.2.4, it would be clearer to say "This section MUST NOT  
be empty" rather than "This section is never empty".

In section 5.2.4.1, it is stated that redundancy "SHOULD NOT" be used  
in the event of fragmentation. In what circumstances is redundancy  
useful with fragmentation? You either need to explain those  
circumstances, or  to note that redundancy "MUST NOT" be used with  
fragmentation and that the Frame Offset field MUST be ignored.

In section 6, it would be clearer if the full headers were included  
with the examples. We have no need for brevity here.

In section 7.1, it is stated that if maxRedundantFrames is not used,  
a value of 15 "SHOULD" be assumed. You either need to explain when  
other values are assumed, or change this to a "MUST". (Similar in  
section 7.2)

In section 7.1, the last two sentences of the definition of maxptime  
can be removed. Also, is there a reason why this is not defined as  
"MUST be a multiple of the frame size" for this codec? (We can be  
more specific than the general definition here)

In section 7.3, please include some explanation for the table.

Colin

---

From: Matthew Romaine <[email-masked]>
Date: Mon, 23 May 2005 19:27:43 +0900

Colin, thanks for your input; I've implemented the changes suggested  
as well as inlined a response to the auxiliary data issue.

On 2005/05/19, at 5:02, Colin Perkins wrote:

> undocumented auxiliary data. We don't typically allow such  
> undefined extension fields in RTP payload formats.

There have been a few requests from internal groups in Sony for this  
part of the payload, as a) it minimizes resources otherwise used  
externally (i.e. if another separate payload would be used), and b)  
some groups have not solidified the parameters they might be using.   
These groups are requesting a mechanism to send data with the payload  
rather than at, say, the SDP level.  Since there will be a level of  
generality somewhere in the pipeline, I modeled this section after  
the mpeg4 payload (RFC 3640) since that was an accepted method.

Is that enough of a justification?

- Matt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 May 2005 09:47:18 +0100

Matthew,

On 23 May 2005, at 11:27, Matthew Romaine wrote:
> Colin, thanks for your input; I've implemented the changes  
> suggested as well as inlined a response to the auxiliary data issue.

Thanks!

> There have been a few requests from internal groups in Sony for  
> this part of the payload, as a) it minimizes resources otherwise  
> used externally (i.e. if another separate payload would be used),  
> and b) some groups have not solidified the parameters they might be  
> using.  These groups are requesting a mechanism to send data with  
> the payload rather than at, say, the SDP level.  Since there will  
> be a level of generality somewhere in the pipeline, I modeled this  
> section after the mpeg4 payload (RFC 3640) since that was an  
> accepted method.
>

No, I don't think so. This is one of the (many) problematic features  
of the MPEG-4 payload format, which I do not recommend copying.   
There are several unused bits in your payload header which can be  
used in a standard way from a revised payload format in future,  
should they be needed.

Colin

---

From: Matthew Romaine <[email-masked]>
Date: Thu, 26 May 2005 19:40:58 +0900

Colin,

Thanks for your input.  The need for the auxiliary field is to have a  
mechanism to transmit metadata regarding the current stream, for  
example track name, artist, album title, etc.  While we might try to  
specify every entry, there will eventually be a field we miss.  I am  
thinking XML could be a solution as it allows tag defining.  Would it  
be alright if we specified the field to be of XML data?  We would  
like to retain the information under one session and hence payload  
since the streamed content may be relayed to devices unable to handle  
more than one session....

Regards,
Matt

>>> signal extensions in the signalling protocol, rather than  
>>> allowing undocumented auxiliary data. We don't typically allow  
>>> such undefined extension fields in RTP payload formats.
>>
>> and b) some groups have not solidified the parameters they might  
>> be using.  These groups are requesting a mechanism to send data  
>> with the payload rather than at, say, the SDP level.  Since there  
>> will be a level of generality somewhere in the pipeline, I modeled  
>> this section after the mpeg4 payload (RFC 3640) since that was an  
>> accepted method.
>>
> No, I don't think so. This is one of the (many) problematic  
> features of the MPEG-4 payload format, which I do not recommend  
> copying.  There are several unused bits in your payload header  
> which can be used in a standard way from a revised payload format  
> in future, should they be needed.
>
> Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 May 2005 11:54:43 +0100

Matthew,

On 26 May 2005, at 11:40, Matthew Romaine wrote:
> Thanks for your input.  The need for the auxiliary field is to have  
> a mechanism to transmit metadata regarding the current stream, for  
> example track name, artist, album title, etc.  While we might try  
> to specify every entry, there will eventually be a field we miss.   
> I am thinking XML could be a solution as it allows tag defining.   
> Would it be alright if we specified the field to be of XML data?   
> We would like to retain the information under one session and hence  
> payload since the streamed content may be relayed to devices unable  
> to handle more than one session....

This would seem to be a more general problem that should be solved in  
a manner that can be used by other payload formats. It would also  
seem to be something that could be conveyed in new RTCP SDES packets,  
since their purpose is to convey metadata about the source.

Would you consider writing up a general proposal? This is sounding  
less and less like something which should be conveyed as auxiliary  
data in the ATRAC payload format.

Colin