[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-05.txt
Hatanaka-san,
On 5 Dec 2005, at 02:09, Mitsuyuki Hatanaka wrote:
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-05.txt
Pages : 26
Date : 2005-12-2
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, elementary
redundancy measures, and a variation on scalable streaming.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-
family-05.txt
I have submitted draft -05 of our ATRAC family payload.
The main changes are:
- labels for each figure and table
- change the start value of FrgNo (fragment number variable) to 0
Thank you for making these changes.
And the rest issue is about "Intended usage".
Although Mr.Collin pointed out that "LIMITED_USE" should be used for
"Intended usage", we still think "COMMON" is appropriate.
Mr.Magus mentioned that "LIMITED_USE" is for experimental codecs,
which is not the case for ATRAC. Therefore, we have chosen "COMMON".
Also, our licensing scheme is similar to AAC/MP3, which also have
their
"Intended Usage" as "COMMON".
Okay, this is fine.
I noticed two other issues with this draft:
1) Sections 7.2 and 7.3 use a "sampleRate" parameter, but other RTP
payload formats call use a "rate" parameter. Is it possible to
change the name of the parameter to match the other formats?
2) Section 7.1, 7.2 and 7.3 use an old form of the media type
registration template. Drafts must now use the media type
registration template described in RFC 4288, and RTP payload formats
should also reference RFC 3555. In particular, payload formats now
need to state:
Encoding considerations:
This media type is framed and contains binary data.
Restrictions on usage:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP [3].
in the relevant parts of their media type registration. It should
also be stated at the start of section 7 that "These registrations
use the template defined in RFC 4288 and follow RFC 3555" (and RFCs
4288 and 3555 should be cited added to the references).
Colin
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt