• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products"

  • Subject: Re: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products"
  • From: John Westing <email@hidden>
  • Date: Thu, 11 Apr 2013 11:04:36 -0400
Apologies, I mis-spoke. RFC 3016 says that the RTP Market Bit will specify AudioMuxElement() boundaries, not the muxConfigPresent argument. This is the part of the spec that Apple does not follow: they do not set the RTP Market Bit to 1 which signals that a complete AudioMuxElement() has been received. If you are writing an application-specific LATM depayloader then that is fine, but existing LATM depayloaders that follow the spec will not be able to decode the data unless the RTP Market Bit is forced to one before being passed to the depayloader. Pretty weak.




On Tue, Apr 9, 2013 at 9:47 AM, John Westing <email@hidden> wrote:
I was never able to find the document ISO/IEC 13818-3:2005, but ISO/IEC 14496-3:2005 contained the information I needed to decode AudioMuxElement(). It does seem however that Apple does not follow the RTP spec, RFC 3016, correctly though. Apple's Bluetooth Design Guidelines document states that: "The muxConfigPresent argument to the AudioMuxElement is set to 1 (in-band mode), as recommended in Section 4.1 of RFC 3016." And if you look at RFC 3016 it states that the RTP Marker Bit is used to specify muxConfigPresent, but in the Apple's case the RTP Market Bit received is always 0, which makes existing RTP LATM parsers unable to parse Apple's packet. Either an Apple-specific LATM parser must be written which assumes muxConfigPresent is always 1, or the bit must be set to 1 at higher level before passing to the LATM parser.




On Thu, Apr 4, 2013 at 4:40 PM, John Westing <email@hidden> wrote:
Shawn,

Did you ever find the answer to your question? I am stuck in a similar situation, but it sounds like you have gotten further than me. I don't understand the explanation of the packet header given in https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf, and like you I can't find a document titled ISO/IEC 13818-3:2005, the latest version I could find was from 1998.

If the AVDTP header is the header found in Figure 4 of RFC 3016 then the RTP Market Bit (audioMuxElement for LATM) should always be 1 according to the Bluetooth Design Guidelines PDF. I'm not seeing that, I decoded the data with Wireshark (v1.9.2) and the bit is always 0.

Do I have something configured wrong? How did you figure out how to bypass the RTP header and get to the AAC audio? I took a look at the document you mentioned, ISO/IEC 14496-3:2005, but it looks like this document gives an algorithm for decoding the packet and does not give the actual breakdown of fields in the packet.

I'm trying to use built-in GStreamer elements to decode the RTP but I'm not having any luck. I'm wondering if I need to write own GStreamer plugin. I tried the rtpmp4adepay element to decode the data but the element gets hung waiting for the Market Bit/audioMuxElement bit.

Any help is appreciated.

Thanks,
Sam



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >RE: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products" (From: John Westing <email@hidden>)
 >Re: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products" (From: John Westing <email@hidden>)

  • Prev by Date: Re: data transmission rate...to slow...
  • Next by Date: Re: data transmission rate...to slow...
  • Previous by thread: Re: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products"
  • Next by thread: Using CoreBluetooth from Command Line Tool
  • Index(es):
    • Date
    • Thread