Re: [payload] [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.

[Roni Even <[e-mail]>]

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:[e-mail]]
> Sent: Monday, May 23, 2011 10:55 AM
> To: Roni Even
> Cc: 'Pete Resnick'; [e-mail]; ietf-
> [e-mail]; 'Ali C. Begen (abegen)'; [e-mail]
> 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:[e-mail]]
> >> Sent: Saturday, May 21, 2011 9:46 AM
> >> To: Roni Even
> >> Cc: 'Pete Resnick'; [e-mail];
> ietf-
> >> [e-mail]; 'Ali C. Begen (abegen)'; [e-mail]
> >> 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:[e-mail]]
> >>> Sent: Friday, May 20, 2011 9:56 PM
> >>> To: Roni Even
> >>> Cc: [e-mail]; 'Ali C. Begen (abegen)';
> >>> [e-mail]; [e-mail]
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ietf-types
> >
> >