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

[Roni Even <[e-mail]>]

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