Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.
Roni Even <Even.roni@huawei.com> Mon, 23 May 2011 14:02 UTC
Return-Path: <Even.roni@huawei.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A55CE0788 for <ietf-types@ietfa.amsl.com>; Mon, 23 May 2011 07:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.332
X-Spam-Level:
X-Spam-Status: No, score=-105.332 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO7SOkOKqAxN for <ietf-types@ietfa.amsl.com>; Mon, 23 May 2011 07:02:07 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 1942DE0782 for <ietf-types@ietf.org>; Mon, 23 May 2011 07:02:04 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4NE1fml015695 for <ietf-types@iana.org>; Mon, 23 May 2011 10:02:02 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN00AQ7HZJD5@szxga03-in.huawei.com> for ietf-types@iana.org; Mon, 23 May 2011 21:40:31 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN008PGHZJ1I@szxga03-in.huawei.com> for ietf-types@iana.org; Mon, 23 May 2011 21:40:31 +0800 (CST)
Received: from windows8d787f9 (bzq-79-181-15-76.red.bezeqint.net [79.181.15.76]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLN00EDKHXCIB@szxml12-in.huawei.com>; Mon, 23 May 2011 21:40:31 +0800 (CST)
Date: Mon, 23 May 2011 16:37:38 +0300
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <4DDA12DE.6090505@it.aoyama.ac.jp>
To: "'\"Martin J. Dürst\"'" <duerst@it.aoyama.ac.jp>
Message-id: <004201cc194e$c23be370$46b3aa50$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="ISO-8859-1"
Content-language: en-us
Content-transfer-encoding: quoted-printable
Thread-index: AcwZHtFqNTAqvB7ARHSSIsfWJZF6oQALs1RA
References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> <4DDA12DE.6090505@it.aoyama.ac.jp>
X-Greylist: Delayed for 00:16:59 by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 23 May 2011 10:02:03 -0400 (EDT)
Cc: 'Pete Resnick' <presnick@qualcomm.com>, "'Ali C. Begen (abegen)'" <abegen@cisco.com>, ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2011 14:02:09 -0000
Hi, Good comment about AVT and the references , I will the authors to change before the registration. Regards Roni > -----Original Message----- > From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Monday, May 23, 2011 10:55 AM > To: Roni Even > Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; ietf- > types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and > "MP4V-ES" media sutypes. > > Just some minor nits: > > Instead of things like "Security considerations: See Section 9 of this > document." and "Author: See Authors' Address section at the end of this > document." it would be better to replace "this document" with e.g. > something like [RFCxxxx], with an note to the RFC Editor/IANA to > replace > [RFCxxxx] with the eventual RFC number. That way, the template can > stand > alone. > > Also, while "Change controller: IETF Audio/Video Transport working > group > delegated from the IESG." is quite a good description of the current > reality, it's not necessarily future-proof. You don't want to go > through > the registration process again just because a WG gets closed. These > registrations usually just have "The IETF" as a change controller, with > the implicit assumption that this may involve a WG and the IESG. > > Regards, Martin. > > On 2011/05/21 16:25, Roni Even wrote: > > Hi, > > No problem. > > Here are the two registration templates and a link to the relevant > section. > > Note that it an update to existing RFC3016 registrations > > http://www.iana.org/assignments/rtp-parameters adding optional > parameters. > > > > The new optional parameters are only for MP4A-LARM and they are: > > MPS-profile-level-id, MPS-asc and SBR-enabled. > > > > thanks > > > > Roni > > > > 1. MP4V-ES > > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section- > 6.1 > > > > Type name: video > > > > Subtype name: MP4V-ES > > > > Required parameters: none > > > > Optional parameters: > > > > rate: This parameter is used only for RTP transport. It > indicates > > the resolution of the timestamp field in the RTP header. If > this > > parameter is not specified, its default value of 90000 (90kHz) > is > > used. > > > > profile-level-id: A decimal representation of MPEG-4 Visual > > Profile and Level indication value > (profile_and_level_indication) > > defined in Table G-1 of [14496-2]. This parameter MAY be used > in > > the capability exchange or session setup procedure to indicate > > MPEG-4 Visual Profile and Level combination of which the MPEG- > 4 > > Visual codec is capable. If this parameter is not specified > by > > the procedure, its default value of 1 (Simple Profile/Level 1) > is > > used. > > > > config: This parameter SHALL be used to indicate the > configuration > > of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be > > used to indicate the codec capability in the capability > exchange > > procedure. It is a hexadecimal representation of an octet > string > > that expresses the MPEG-4 Visual configuration information, as > > defined in subclause 6.2.1 Start codes of [14496-2]. The > > configuration information is mapped onto the octet string in > an > > MSB-first basis. The first bit of the configuration > information > > SHALL be located at the MSB of the first octet. The > configuration > > information indicated by this parameter SHALL be the same as > the > > configuration information in the corresponding MPEG-4 Visual > > stream, except for first_half_vbv_occupancy and > > latter_half_vbv_occupancy, if exist, which may vary in the > > repeated configuration information inside an MPEG-4 Visual > stream > > (See 6.2.1 Start codes of [14496-2]). > > > > Published specification: > > > > The specifications for MPEG-4 Visual streams are presented in > > [14496-2]. The RTP payload format is described in this > document. > > > > Encoding considerations: > > > > Video bitstreams MUST be generated according to MPEG-4 Visual > > specifications [14496-2]. A video bitstream is binary data > and > > MUST be encoded for non-binary transport (for Email, the > Base64 > > encoding is sufficient). This type is also defined for > transfer > > via RTP. The RTP packets MUST be packetized according to the > > MPEG-4 Visual RTP payload format defined in this document. > > > > Security considerations: > > > > See Section 9 of this document. > > > > Interoperability considerations: > > > > MPEG-4 Visual provides a large and rich set of tools for the > > coding of visual objects. For effective implementation of the > > standard, subsets of the MPEG-4 Visual tool sets have been > > provided for use in specific applications. These subsets, > called > > 'Profiles', limit the size of the tool set a decoder is > required > > to implement. In order to restrict computational complexity, > one > > or more Levels are set for each Profile. A Profile@Level > > combination allows: > > > > * a codec builder to implement only the subset of the > standard he > > needs, while maintaining interworking with other MPEG-4 > devices > > included in the same combination, and > > > > * checking whether MPEG-4 devices comply with the standard > > ('conformance testing'). > > > > The visual stream SHALL be compliant with the MPEG-4 Visual > > Profile@Level specified by the parameter "profile-level-id". > > Interoperability between a sender and a receiver may be > achieved > > by specifying the parameter "profile-level-id", or by > arranging a > > capability exchange/announcement procedure for this parameter. > > > > Applications which use this Media Type: > > > > Audio and visual streaming and conferencing tools > > > > Additional information: none > > > > Person and email address to contact for further information: > > > > See Authors' Address section at the end of this document. > > > > Intended usage: COMMON > > > > Author: > > > > See Authors' Address section at the end of this document. > > > > Change controller: > > > > IETF Audio/Video Transport working group delegated from the > IESG. > > > > > > 2. MP4A-LATM > > > > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section- > 6.3 > > > > > > Type name: audio > > > > Subtype name: MP4A-LATM > > > > Required parameters: > > rate: the rate parameter indicates the RTP time stamp clock > rate. > > The default value is 90000. Other rates MAY be indicated only > if > > they are set to the same value as the audio sampling rate > (number > > of samples per second). > > > > In the presence of SBR, the sampling rates for the core en-/ > > decoder and the SBR tool are different in most cases. This > > parameter SHALL therefore NOT be considered as the definitive > > sampling rate. If this parameter is used, the server must > > following the rules below: > > > > * When the presence of SBR is not explicitly signaled by the > > optional SDP parameters such as object parameter, profile- > > level-id or config string, this parameter SHALL be set to > the > > core codec sampling rate. > > > > * When the presence of SBR is explicitly signaled by the > optional > > SDP parameters such as object parameter, profile-level-id > or > > config string this parameter SHALL be set to the SBR > sampling > > rate. > > > > NOTE: The optional parameter SBR-enabled in SDP a=fmtp is > useful > > for implicit HE AAC / HE AAC v2 signaling. But the SBR- > enabled > > parameter can also be used in the case of explicit HE AAC / HE > AAC > > v2 signaling. Therefore, its existence itself is not the > criteria > > to determine whether HE AAC / HE AAC v2 signaling is explicit > or > > not. > > > > Optional parameters: > > > > profile-level-id: a decimal representation of MPEG-4 Audio > Profile > > Level indication value defined in [14496-3]. This parameter > > indicates which MPEG-4 Audio tool subsets the decoder is > capable > > of using. If this parameter is not specified in the > capability > > exchange or session setup procedure, its default value of 30 > > (Natural Audio Profile/Level 1) is used. > > > > MPS-profile-level-id: a decimal representation of the MPEG > > Surround Profile Level indication as defined in [14496-3]. > This > > parameter indicates the support of the MPEG Surround profile > and > > level by the decoder to be capable to decode the stream. > > > > object: a decimal representation of the MPEG-4 Audio Object > Type > > value defined in [14496-3]. This parameter specifies the tool > to > > be used by the decoder. It CAN be used to limit the > capability > > within the specified "profile-level-id". > > > > bitrate: the data rate for the audio bit stream. > > > > cpresent: a boolean parameter indicates whether audio payload > > configuration data has been multiplexed into an RTP payload > (see > > Section 5.1). A 0 indicates the configuration data has not > been > > multiplexed into an RTP payload and in this case the "config" > > parameter MUST be present, a 1 indicates that it has. The > default > > if the parameter is omitted is 1. If this parameter is set to > 1 > > and the "config" parameter is present, the multiplexed > > configuration data and the value of the "config" parameter > SHALL > > be consistent. > > > > config: a hexadecimal representation of an octet string that > > expresses the audio payload configuration data > "StreamMuxConfig", > > as defined in [14496-3]. Configuration data is mapped onto > the > > octet string in an MSB-first basis. The first bit of the > > configuration data SHALL be located at the MSB of the first > octet. > > In the last octet, zero-padding bits, if necessary, SHALL > follow > > the configuration data. Senders MUST set the StreamMuxConfig > > elements taraBufferFullness and latmBufferFullness to their > > largest respective value, indicating that buffer fullness > measures > > are not used in SDP. Receivers MUST ignore the value of these > two > > elements contained in the config parameter. > > > > MPS-asc: a hexadecimal representation of an octet string that > > expresses audio payload configuration data > "AudioSpecificConfig", > > as defined in [14496-3]. If this parameter is not present the > > relevant signaling is performed by other means (e.g. in-band > or > > contained in the config string). > > > > The same mapping rules as for the config parameter apply. > > > > ptime: duration of each packet in milliseconds. > > > > SBR-enabled: a boolean parameter which indicates whether SBR- > data > > can be expected in the RTP-payload of a stream. This > parameter is > > relevant for an SBR-capable decoder if the presence of SBR can > not > > be detected from an out-of-band decoder configuration (e.g. > > contained in the config string). > > > > If this parameter is set to 0, a decoder MAY expect that SBR > is > > not used. If this parameter is set to 1, a decoder CAN > upsample > > the audio data with the SBR tool, regardless whether SBR data > is > > present in the stream or not. > > > > If the presence of SBR can not be detected from out-of-band > > configuration and the SBR-enabled parameter is not present, > the > > parameter defaults to 1 for an SBR-capable decoder. If the > > resulting output sampling rate or the computational complexity > is > > not supported, the SBR tool can be disabled or run in > downsampled > > mode. > > > > The timestamp resolution at RTP layer is determined by the > rate > > parameter. > > > > Published specification: > > > > Encoding specifications are provided in [14496-3]. The RTP > > payload format specification is described in this document. > > > > Encoding considerations: > > > > This type is only defined for transfer via RTP. > > > > Security considerations: > > > > See Section 9 of this document. > > > > Interoperability considerations: > > > > MPEG-4 Audio provides a large and rich set of tools for the > coding > > of audio objects. For effective implementation of the > standard, > > subsets of the MPEG-4 Audio tool sets similar to those used in > > MPEG-4 Visual have been provided (see Section 6.1). > > > > The audio stream SHALL be compliant with the MPEG-4 Audio > Profile@ > > Level specified by the parameters "profile-level-id" and "MPS- > > profile-level-id". Interoperability between a sender and a > > receiver may be achieved by specifying the parameters > "profile- > > level-id" and "MPS-profile-level-id", or by arranging in the > > capability exchange procedure to set this parameter mutually > to > > the same value. Furthermore, the "object" parameter can be > used > > to limit the capability within the specified Profile@Level in > > capability exchange. > > > > Applications which use this media type: > > > > Audio and video streaming and conferencing tools. > > > > Additional information: none > > > > Personal and email address to contact for further information: > > > > See Authors' Address section at the end of this document. > > > > Intended usage: COMMON > > > > Author: > > > > See Authors' Address section at the end of this document. > > > > Change controller: > > > > IETF Audio/Video Transport working group delegated from the > IESG. > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] > >> Sent: Saturday, May 21, 2011 9:46 AM > >> To: Roni Even > >> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; > ietf- > >> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > >> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" > and > >> "MP4V-ES" media sutypes. > >> > >> Hello Roni, > >> > >> I fully agree with Pete. I have often told people asking for review > on > >> this list to post the registration templates themselves. I have also > >> been on this list long enough to be able to tell you *for sure* (not > >> just 'probably' as Pete wrote) that posting the template(s) > themselves > >> really helps. > >> > >> So if you haven't done it up to now, it's never too late to change > that > >> practice. Copying the template once is a little bit more work for > you > >> than just posting some pointers, but it will make it easier for all > >> reviewers on this list, because they don't have to follow your > >> instructions. > >> > >> Many thanks in advance and kind regards, Martin. > >> > >> > >> P.S.: You didn't even bother to give a direct link to the relevant > >> section(s), which would easily be possible using > http://tools.ietf.org. > >> Of course copying the actual template is still highly preferable. > >> > >> > >> > >> On 2011/05/21 7:59, Roni Even wrote: > >>> Pete, > >>> > >>> This is what we have been doing for all payload specifications. We > >> point at > >>> the sections with the registration templates. > >>> > >>> Regards > >>> > >>> Roni > >>> > >>> > >>> > >>> From: Pete Resnick [mailto:presnick@qualcomm.com] > >>> Sent: Friday, May 20, 2011 9:56 PM > >>> To: Roni Even > >>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > >>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > >>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" > >> and > >>> "MP4V-ES" media sutypes. > >>> > >>> > >>> > >>> On 4/28/11 3:30 AM, Roni Even wrote: > >>> > >>> > >>> > >>> > >>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > >> the AVT > >>> Working Group (currently Payload). The document updates the media > >> subtypes > >>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations > are > >> in > >>> Section 6.1 and Section 6.3 of the document. > >>> > >>> Comments on the registration are welcome. > >>> > >>> > >>> Roni, it would probably help if you posted the registration > templates > >>> themselves instead of pointing to the draft. > >>> > >>> Thanks, > >>> > >>> pr > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> ietf-types mailing list > >>> ietf-types@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-types > > > >
- [ietf-types] updating the registeration of "MP4A-… Roni Even
- Re: [ietf-types] updating the registeration of "M… Pete Resnick
- Re: [ietf-types] updating the registeration of "M… Pete Resnick
- Re: [ietf-types] updating the registeration of "M… Roni Even
- Re: [ietf-types] updating the registeration of "M… Martin J. Dürst
- Re: [ietf-types] updating the registeration of "M… Roni Even
- Re: [ietf-types] updating the registeration of "M… Martin J. Dürst
- Re: [ietf-types] updating the registeration of "M… Roni Even
- Re: [ietf-types] [payload] updating the registera… Colin Perkins