Subject: [AVT] RE: AAC payload format rfc

From: "Amit Yedidia" <[email-masked]>
Date: Sun, 20 May 2007 09:36:00 +0300

You can use RFC 3016 

Amit Yedidia.

Message: 1
Date: Fri, 18 May 2007 21:39:08 +0500
From: "Ajmal, Humayun" <[email-masked]>
Subject: [AVT] AAC payload format rfc
To: <[email-masked]>
Message-ID:
	
<[email-masked]
	
Content-Type: text/plain; charset="us-ascii"

Hi list, 

Which rfc specifies the AAC payload format for RTP?

Thanks

Humayun 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/avt/attachments/20070518/2db83b4f/attachm
ent.html

------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

End of avt Digest, Vol 37, Issue 17
***********************************

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Dave Singer <[email-masked]>
Date: Mon, 21 May 2007 08:56:10 -0700

>Amit Yedidia.

No, that's not the best option.  3016 uses LATM which has serious 
signalling problems.  It also has no options for interleave etc. for 
error resilience.

3016 *is* used in 3GPP, so if you need compatibility with 3G, then 
use it.  But otherwise 3640 is a better option, as used in ISMA 1.0 
and 2.0.

-- 
David Singer
Apple Computer/QuickTime

---

From: Keith Lantz <[email-masked]>
Date: Mon, 21 May 2007 11:29:43 -0700

FYI, below is the related prose that has just been added (via an 
Engineering Change Notice) to the PacketCable 2.0 Codec & Media 
Specification. This may help explain the preference for RFC 3640.

>For Packet-switched Streaming Service (PSS) [TS 26.234], 3GPP 
>specifies the payload format described in [RFC 3016] for Enhanced 
>aacPlus and other forms of AAC [RFC 3016].  This choice was made 
>mainly for the reason of backwards compatibility with older versions 
>of PSS.  For new 3GPP services, which do not have this constraint of 
>backwards compatibility, such as Multimedia Broadcast/Multicast 
>Service (MBMS) [TS 26.346], 3GPP specifies a more flexible payload 
>format described in [RFC 3640].  ISMA [ISMA-2] and DVB [TS 102 005] 
>also mandate the use of [RFC 3640] for the carriage of AAC over 
>IP.  Besides broader applicability, [RFC 3640] provides additional 
>features, such as interleaving.  User Equipment and Media Servers 
>supporting AAC in streaming services MUST support the payload format 
>specified in [RFC 3016] and MAY support the payload format specified 
>in [RFC 3640].  For any other service using AAC, User Equipment and 
>Media Servers MUST support the payload format specified in [RFC 3640].
>
>[RFC 3016] applies when using the MPEG-4 Low-overhead Audio 
>Transport Multiplex (LATM).  When used with RTP, LATM allows for the 
>concatenation of multiple audio frames into one stream and the 
>addition of configuration information.  LATM streams consist of a 
>sequence of MPEG-4 audioMuxElements that each include one or more 
>audio frames.  Where possible, User Equipment and Media Servers 
>SHOULD map one complete audioMuxElement into an RTP packet.  When an 
>audioMuxElement exceeds the maximum RTP packet size, User Equipment 
>and Media Servers MAY fragment the audioMuxElement across multiple 
>packets and the RTP Marker bit MUST be set to 0 on all but the last 
>fragment of audioMuxElements.
>
>[RFC 3640] defines an RTP payload structure to transport MPEG-4 
>Elementary Streams, of which audio is one type.  It can be used for 
>any MPEG-4 codec and can be configured in a flexible way to match 
>the need of individual codecs.  Similar to the LATM, multiple MPEG-4 
>Access Units may be mapped into one RTP packet but they may not be 
>split across packet boundaries at the same time, i.e., a packet 
>contains either several complete Access Units or a single fragmented 
>Access Unit.  Mixing complete and fragmented Access Units in one RTP 
>packet is not allowed, which simplifies implementation and improves 
>interoperability.
>
>The choice of payload format is made through SDP negotiation.
>
>User Equipment and Media Servers SHOULD set the timestamp resolution 
>to the audio sampling rate subject to specifying this via the SDP 
>exchange.  If the audio sampling rate is unknown, User Equipment and 
>Media Servers SHOULD set the timestamp resolution to 90 kHz.

The complete ECN, which adds a number of superwideband audio codecs 
to PC 2.0 (and contains all the references cited above), can be found 
at 
http://www.cablelabs.com/specifications/ecns/packetcable/CODEC-MEDIA-N-07.0412-3.doc. 
If you have any questions or suggestions re that ECN, I'd be happy to 
forward them to the PacketCable codec focus team.

Keith

At 08:56 AM 5/21/2007, Dave Singer wrote:
>use it.  But otherwise 3640 is a better option, as used in ISMA 1.0 and 2.0.
>
>>
>>
>>Message: 1