AVDTP简介
AVDTP（ A/V Distribution Transport Protocol）音视频分布传输协议 ，主要用于传输音频/视频数据。在整个协议栈的架构图如下：
1.1 AVDTP协议定位与发展历程
AVDTP是蓝牙核心规范中定义的传输层协议，首次出现在蓝牙1.2版本中，随着蓝牙技术演进不断优化。位于L2CAP（逻辑链路控制与适配协议）之上，为上层音视频应用（如A2DP、AVRCP）提供面向连接的媒体流传输服务。与SDP（服务发现协议）、RFCOMM（串口仿真协议）等其他蓝牙协议不同，AVDTP专门针对音视频数据的实时传输需求设计，具有以下核心特点：
- 双信道架构：分离信令通道与媒体通道，控制命令与实际音视频数据独立传输
- 实时性优化：采用类似RTP的时间戳机制解决播放同步问题
- QoS支持：通过序列号、丢包检测等机制实现流量控制与错误恢复
- 多格式兼容：支持 SBC、AAC、MP3 等多种音视频编码格式
1.2 媒体通道与信令通道的协同工作
AVDTP协议采用独特的双信道传输机制：
- 信令通道（Signaling） ：通过L2CAP的固定信道ID（0x0040）传输控制命令，负责建立、配置、维护和释放流媒体传输信道。使用L2CAP的PSM=0x0019。处理命令如 Discover、GetCapabilities、SetConfiguration、Open、Start、Close、Abort 等。
- 媒体通道：动态分配L2CAP信道（通常为0xA040）传输实际音视频数据
AVDTP 的组件，红框中的内容，了解即可。
AVDTP Signal 信号封包格式,了解即可
AVDTP Media 封包格式，了解即可
AVDTP Service Capablities(具备的服务能力，了解就行)
这些能力在 AVDTP 的 signaling 流程中通过 TLV（Type-Length-Value）格式进行交换，AVDTP_GET_CAPABILITIES_RSP/AVDTP_SET_CONFIGURATION_CMD/AVDTP_GET_CONFIGURATION_RSP/AVDTP_RECONFIGURE_CMD这几种command命令中都会用到
| 能力名称（Service Capability） | 简要说明 |
| Media Transport Capabilities | 表示支持基本的媒体流传输功能，是 AVDTP 的核心能力之一。 |
| Reporting Capabilities | 表示设备支持 QoS 报告机制（类似 RTCP），用于传输质量监控。 |
| Recovery Capabilities | 表示支持数据包恢复机制，用于丢包重传等场景。 |
| Media Codec Capabilities | 表示支持的音频/视频编解码器类型（如 SBC、AAC、aptX 等）。 |
| Content Protection Capabilities | 表示支持内容保护机制（如 DRM），用于版权保护。 |
| Header Compression Capabilities | 表示支持 RTP 头部压缩，提升传输效率。 |
| Multiplexing Capabilities | 表示支持多个传输会话复用一个传输通道（L2CAP channel）。 |
| Delay Reporting Capabilities | 表示支持延迟报告机制，用于同步和延迟控制。 |
综上所述： 在 AVDTP（Audio/Video Distribution Transport Protocol）中，音视频数据的确是以模仿 RTP（Real-time Transport Protocol）方式进行传输的。
✅ 结论总结：
- AVDTP 的媒体数据包格式和传输机制是基于 RTP 设计的；
- 它并不是直接使用标准 RTP，而是借鉴了 RTP 的头部结构和机制，并针对蓝牙链路做了适配；
- 控制信息（如连接建立、参数协商）通过单独的信令通道传输，不经过 RTP。
🔍 详细说明：
- AVDTP 使用 RTP 的思想和结构 AVDTP 的媒体数据包头部设计与 RTP 非常相似，包括：
- 固定 12 字节头部（与 RTP 一致）
- 包含时间戳（Timestamp）、序列号（Sequence Number）等字段
- 用于支持音视频同步、顺序传输、丢包检测等功能
- 但 AVDTP 并不是标准 RTP 虽然借鉴了 RTP，但 AVDTP 做了以下调整：
- 不支持完整的 SSRC/CSRC 机制（或做了简化）
- 时间戳单位根据采样率动态调整
- 运行在蓝牙 L2CAP 上，而非 UDP/IP
- 头部压缩和重传机制更适合蓝牙链路
- 控制信息与媒体数据分离
- 信令通道（Signaling）：用于协商、配置、建立/释放流（如
SET_CONFIGURATION,START,SUSPEND等命令） - 媒体通道（Streaming）：用于传输实际的音视频数据，采用类 RTP 格式
✅ 举例说明（如 A2DP 场景）： 当你用手机（SRC）通过蓝牙给耳机（SNK）播放音乐时：
- 音频数据被封装成 AVDTP Media Packet（格式类似 RTP）
- 通过 L2CAP 的媒体通道发送到耳机
- 耳机根据时间戳和序列号进行播放、同步、缓冲等处理
📌 总结一句话：
AVDTP 的媒体数据传输是基于 RTP 的思想和格式设计的，但不是标准 RTP，而是为蓝牙优化的“类 RTP”机制。
对比如小表：
| 特性 | RTP | AVDTP Media Packet |
|---|---|---|
| 头部长度 | 12 字节（无扩展） | 固定 12 字节 |
| 时间戳单位 | 取决于负载类型 | 基于采样率动态调整 |
| SSRC/CSRC 支持 | 完整支持 | 简化支持（CSRC 数量限制） |
| 链路层适配 | 通用 IP 网络 | 蓝牙 L2CAP 链路（MTU 限制） |
| QoS 机制 | 依赖网络层 | 集成链路层重传与流量控制 |
A2DP 简介
在蓝牙协议中，A2DP（Advanced Audio Distribution Profile）高质量音频分发协议 和 A2DP Sink 各自负责特定的功能，它们之间存在联系，同时也有明显的区别。
A2DP协议主要负责高音质音频的传输。它是一种蓝牙高音质音频传输协议，主要用于传输单声道和双声道音乐（通常在A2DP中用于stereo双声道），其典型应用是蓝牙耳机。A2DP旨在通过蓝牙连接传输高质量的立体声音频流。它使用的默认压缩算法是SBC（Sub-Band Coding），以减小音频数据的大小同时保持高音质。此外，A2DP还支持其他高级编解码器，如AAC、aptX和LDAC，这些编解码器可以提供更好的音质，但具体支持情况取决于设备本身。
高级音频 & 蓝牙音频
大家需要区分开高级音频和蓝牙音频，蓝牙音频一般指传输于蓝牙SCO链路上的音频，也就是蓝牙电话；而高级音频指的传输于蓝牙ACL链路上的高质量音频，即为蓝牙音乐的媒体音频，别再傻傻分不清蓝牙音频和高级音频了哦。
A2DP Sink则是A2DP协议中的一部分，代表数字音频流的接收器。
在A2DP的通信过程中，存在两种角色：SRC（Source，数字音频流的源）和SNK（Sink，数字音频流的接收器）。SRC负责将源数据发送到SNK端，而SNK则负责接收SRC发过来的源数据。例如，在常见的应用场景中，手机蓝牙主要作为SRC存在，而对应的蓝牙耳机、音箱等设备则作为SNK的角色存在。
| 数据源（Source） | 接收器（Sink） |
| 手机，IPad, 电脑 | 车机， 耳机， 音响 |
| 缩写——SRC | 缩写——SNK |
因此，A2DP Sink是A2DP协议中负责接收音频数据的部分，它与A2DP协议紧密相连，共同实现了蓝牙设备间的高音质音频传输。
至于A2DP和A2DP Sink之间的区别，主要在于它们的功能和角色定位上。A2DP是一个更广泛的协议，定义了音频传输的整个过程和相关标准，而A2DP Sink则是这个协议中的一个具体角色，负责接收音频数据。简而言之，A2DP是整体的传输协议，而A2DP Sink是这个协议中的接收部分。
综上所述，A2DP和A2DP Sink在蓝牙协议中各自扮演重要角色，它们之间的联系在于共同实现蓝牙设备间的高音质音频传输，而区别则在于功能和角色定位的不同。
A2DP音频相关内容，音频流， 流向如下图
建立AVDTP协议连接之后，当Source端需要播放时会通过AVDTP协议发送通过类似RTP格式封装的音频数据包，收到数据包之后协议栈中选用连接时约定的编码器以及参数进行解码，解码成PCM数据之后写入到音频模块进行播放。A2DP Profile连接建立过程如下：
- Source端会获取Sink端支持几个解码器（SEP, Stream End Point）。
- Source端获取每个SEP的配置（Capabilites）。
- 根据Source端支持的配置情况选择一个配置设置给Sink端。
- 此时，已经为后面传输音频流做好了准备，需要播放时即可发送音频流进行播放。
1.1 手机 ↔ 车机 蓝牙 A2DP 编解码器能力交换实录
| 时间戳 | 方向 | ACP | 车机回复的音频能力 |
|---|---|---|---|
| 9.566 s | 手机 → 车机 | 1 | 我会 SBC （Mandatory，48 kHz / 2 ch / 328 kbps max） |
| 9.571 s | 手机 → 车机 | 2 | 我会 AAC-LC 44.1 kHz / 2 ch / VBR ~165 kbps |
| 9.578 s | 手机 → 车机 | 3 | 我会 AptX 48 / 44.1 kHz / Stereo |
| 9.614 s | 手机 → 机 | 4 | 我会 AptX-HD 48 kHz / Stereo |
| 9.615 s | 手机 → 车机 | 5 | 我会 Sony LDAC 44.1 / 48 / 88.2 / 96 kHz / Dual / Stereo |
| 9.643 s | 手机 → 车机 | 6 | 我会 AptX Adaptive (Qualcomm 0x00AD) |
手机 正在“面试” 车机 的音频简历——把每个 AVDTP 端点（ACP=x）能用的编解码器、采样率、声道数、延迟报告能力全部问一遍，问完后再决定下一步 SET_CONFIGURATION 选谁（AAC / AptX / LDAC …）来开音乐。
最后选择了 SBC 编解码
AVDTP Set Configuration (ACP=1, INT=1, Media Transport | Audio | SBC: Joint Stereo, 44.1kHz, Loudness, 8 Subbands | Delay Reporting) › Accept
1.2 播放音乐的详细信息
1.3 A2DP Sink 解码过程
android14/packages/modules/Bluetooth/system/stack目录下搜索decode_packet
system/stack/include/a2dp_sbc_decoder.h:42:bool a2dp_sbc_decoder_decode_packet(BT_HDR* p_buf);
system/stack/include/a2dp_aac_decoder.h:42:bool a2dp_aac_decoder_decode_packet(BT_HDR* p_buf);
system/stack/include/a2dp_vendor_opus_decoder.h:34:bool a2dp_vendor_opus_decoder_decode_packet(BT_HDR* p_buf);
system/stack/include/a2dp_vendor_ldac_decoder.h:45:bool a2dp_vendor_ldac_decoder_decode_packet(BT_HDR* p_buf);
system/stack/a2dp/a2dp_sbc_decoder.cc:62:bool a2dp_sbc_decoder_decode_packet(BT_HDR* p_buf) {
system/stack/a2dp/a2dp_aac_decoder.cc:66:bool a2dp_aac_decoder_decode_packet(BT_HDR* p_buf) {
system/stack/a2dp/a2dp_vendor_opus_decoder.cc:91:bool a2dp_vendor_opus_decoder_decode_packet(BT_HDR* p_buf) {
system/stack/a2dp/a2dp_vendor_ldac_decoder.cc:200:bool a2dp_vendor_ldac_decoder_decode_packet(BT_HDR* p_buf) {
system/btif/src/btif_a2dp_sink.cc:541: if (!btif_a2dp_sink_cb.decoder_interface->decode_packet(p_msg)) {
system/stack/test/a2dp/a2dp_opus_unittest.cc:203: decoder_iface_->decode_packet(packet);
system/stack/test/a2dp/a2dp_opus_unittest.cc:240: decoder_iface_->decode_packet(packet);
system/stack/test/a2dp/a2dp_aac_unittest.cc:211: decoder_iface_->decode_packet(packet);
system/stack/test/a2dp/a2dp_aac_unittest.cc:243: decoder_iface_->decode_packet(packet);
system/stack/test/a2dp/a2dp_sbc_unittest.cc:212: decoder_iface_->decode_packet(packet);
system/stack/test/a2dp/a2dp_sbc_unittest.cc:249: decoder_iface_->decode_packet(packet);
从这里你可以看到hfp电话音频也有软解码了
system/stack/include/hfp_msbc_decoder.h:35:bool hfp_msbc_decoder_decode_packet(const uint8_t* i_buf, int16_t* o_buf,
system/stack/test/btm/sco_hci_test.cc:71: return hfp_msbc_decoder_decode_packet(i_buf, o_buf, out_len);
system/stack/btm/hfp_msbc_decoder.cc:64:bool hfp_msbc_decoder_decode_packet(const uint8_t* i_buf, int16_t* o_buf,
system/test/mock/mock_stack_btm_hfp_msbc_decoder.cc:65:bool hfp_msbc_decoder_decode_packet(const uint8_t* i_buf, int16_t* o_buf,
system/test/mock/mock_stack_btm_hfp_msbc_decoder.cc:68: return test::mock::stack_btm_hfp_msbc_decoder::hfp_msbc_decoder_decode_packet(
举例：aac解码器
学习参考文章：
wlink.blog.csdn.net/article/det…
AVDTP Media Packet 报文深度解析：蓝牙音频流的幕后功臣_蓝牙avdtp-CSDN博客 baike.baidu.com/tashuo/brow… author.baidu.com/home?from=b…
