蓝牙音频视频传输协议规范V1.0

需积分: 13 200 浏览量更新于2024-07-20 1 收藏 2.74MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"AVDTP SPEC V10.pdf" AVDTP（Audio/Video Distribution Transport Protocol）是蓝牙技术联盟（Bluetooth Special Interest Group, SIG）制定的一种协议，用于在蓝牙设备之间传输音频和视频流。该协议定义了A/V流的协商、建立和传输过程，以及设备间交换的用于传输A/V流的消息格式。AVDTP V1.0版本是在2003年5月22日被采纳并发布的，它经过了一系列的修订和内部反馈，旨在为A/V分布应用提供稳定可靠的传输机制。在AVDTP中，主要涉及以下几个关键知识点： 1. **流媒体协商**：协议允许设备之间协商传输的媒体类型、编码格式、比特率等参数，确保双方设备能够兼容并有效地传输音频或视频数据。 2. **连接建立**：AVDTP定义了如何建立和管理蓝牙设备间的连接，包括发现、配对、连接和断开连接的过程。 3. **服务发现**：在A/V设备之间，AVDTP允许发现和选择可用的服务，如音频播放、视频流等，以便于选择合适的传输通道。 4. **配置与设置**：协议支持配置和设定传输参数，例如媒体编码、同步和错误校正机制，以优化传输性能和质量。 5. **控制与管理**：AVDTP提供了对传输流的控制功能，包括暂停、播放、停止、快进、快退等操作，以及错误处理和恢复机制。 6. **消息格式**：AVDTP定义了一套消息结构，用于在设备间交换控制信息，这些消息包括但不限于发现请求、连接请求、配置请求和释放请求等。 7. **版本历史**：从草案0.95a到最终的1.0版本，AVDTP经历了多次修订，逐步完善了协议的各个方面，确保了其稳定性和兼容性。 8. **贡献者**：AVDTP的制定过程中，有多位专家参与，如Morgan Lindqvist（来自Ericsson），他们的工作为协议的开发和完善做出了重要贡献。 AVDTP V1.0的发布，标志着蓝牙设备在音频和视频传输领域的标准化进程迈出了重要一步，为蓝牙A/V设备之间的互操作性奠定了基础，促进了蓝牙在多媒体应用中的广泛应用。

资源详情

资源推荐

BLUETOOTH SPECIFICATION

Audio/Video Distribution Transport Protocol Specification Page 16 of 145

3 Functional Requirements

The following capabilities have been identified as requirements of the A/V Distribution

Transport Protocol.

1. AVDTP shall provide the means to discover the capabilities of the devices, as

well as the means to negotiate for A/V stream set up.

2. AVDTP shall provide the mechanism to establish and tear down a stream.

3. AVDTP shall provide for the mechanism and the message formats for real-time

streams, which are:

• Mechanisms to minimize the transmission delay

• Mechanisms to attach data that provides timing information required for

playback of media streams on the receiver side

• Mechanisms for reporting the Quality of Service and status of transport of

Media packets to application level

• Mechanisms to optimise the use of available bandwidth

4. AVDTP shall be flexible by its independent functions for use on devices of limited

complexity.

5. AVDTP shall provide recovery mechanisms.

6. AVDTP shall provide mechanisms to reduce the overhead of the headers in the

transport protocol

Release Date: 2003-02-07

BLUETOOTH SPECIFICATION

Audio/Video Distribution Transport Protocol Specification Page 17 of 145

4 Terminology and Definitions

4.1 Stream

A stream (Bluetooth A/V Stream) represents the logical end-to-end connection of

streaming media data (audio or video) between two A/V devices. Stream data is

interfaced with the upper layer. The A/V transport layer provides this stream

connection to the application. More strictly, streaming data is source-encoded data,

as the audio or video encoder and decoder conceptually reside in the upper layer.

In a multimedia application context, a stream typically corresponds to a single media

channel. Exceptions apply where multiple media channels are encoded to an

aggregate bit stream; e.g., in case of joint stereo encoding.

Although a streaming connection is unidirectional, bi-directional use of the transport

channel is possible in case the transport layer exchanges feedback information. A

stream handle (see Section 4.9) is used to uniquely distinguish one stream.

4.2 Source (SRC) and Sink (SNK)

As the stream represents unidirectional media data, the peer devices explicitly

assume the roles of either a SRC or a SNK, depending on the application.

4.3 Initiator (INT) and Acceptor (ACP)

The device that initiates a procedure is considered as the INT of this procedure. The

device addressed is the procedure's ACP.

The role of INT/ACP of a stream is independent of a device's role as SRC/SNK. The

INT and ACP roles in the A/V transport protocol are not to be confused with the

corresponding roles in the underlying L2CAP layer.

4.4 Application and Transport Service Capabilities

The A/V transport protocol represents a scalable architecture with different support

levels of mechanisms used in the transport, or services provided to the upper layer.

The support levels are described by a variable set of capabilities. The ACP typically

exposes its capabilities to the INT that selects a configuration. The support of certain

capabilities may also be mandated by a profile.

Application Service Capabilities correspond to services provided to the application

layer. These comprise of, for example, the negotiation and configuration of source

codecs, content protection systems and support of media synchronization.

Release Date: 2003-02-07

BLUETOOTH SPECIFICATION

Audio/Video Distribution Transport Protocol Specification Page 18 of 145

Transport Service Capabilities correspond to more specifically transport-related

"services" inside the transport layer. These comprise, for example, framing and

segmentation, encapsulation, reporting of delivery performance, packet loss

detection, packet recovery, robust header compression, and multiplexing transport

sessions to transport channels.

4.5 Services, Service Categories, and Service Parameters

These terms are related to the transactions during the negotiation phase of the

stream set-up procedure. To simplify the specification of transactions, the term

service may refer to both Application Service Capabilities and Transport Service

Capabilities, which are thus treated equally during the negotiation.

The description of services is organized in a hierarchy of Service Categories and

Service Parameters. The Service Category represents the top-level structuring

element. Examples of Service Categories are media transport, reporting, media

recovery, media codec, content protection, robust header compression, and

multiplexing mode.

Each Service Category can comprise of one or multiple Service Parameters, which

may apply various options. For example, the Service Category audio streaming may

imply Service Parameter as "SBC" and its options like "Sampling Frequency " and

"Channel Mode".

An implementation may not support all Service Categories, or all Service Parameters

within a Service Category, or all options of a Service Parameter. A stream handle

(see Section 4.9) is used to refer to a stream context.

4.6 Media Packets, Recovery Packets, and Reporting

Packets

The A/V transport layer interfaces streaming media with a packet-oriented bearer.

Different AVDTP packet categories can occur. Streaming media is encapsulated in

Media packets (RTP packet format defined by [3]). Media packets travel

downstream; i.e., from the SRC to the SNK device.

Exception: when robust header compression is used then compression-related

feedback packets can also travel upstream.

Depending on the supported services, the peer AVDTP entities can exchange further

information. If packet recovery is used, Recovery packets containing recovery data

are sent by the SRC. Recovery packet format is specified by [4]. If QoS reporting is

used, information is encapsulated in reporting packets. RTCP packet format is

specified by [3]. Reporting packets containing sender reports travel downstream,

whereas those containing receiver reports travel upstream.

Release Date: 2003-02-07

BLUETOOTH SPECIFICATION

Audio/Video Distribution Transport Protocol Specification Page 19 of 145

4.7 Stream End Point (SEP)

The Stream End-Point (SEP) is a concept to expose available Transport Services and

AV capabilities of the Application in order to negotiate a stream. The Application

registers its SEPs in AVDTP in order to allow other devices to discover and connect

to them. A more detailed description can be found in § 5.3

4.8 Stream Context (SC)

In the course of a stream set-up procedure, both peer devices attain a common

understanding of the configuration of the streaming, including the selected services,

parameters, and the transport channel assignment.

Conceptually, a stream context exists in both end-points of a stream. Being

associated to a single stream, the stream context, which could be seen as a kind of

table, serves to collect and maintain all of this information. It is important that the

stream contexts in both devices remain consistent and synchronized.

4.9 Stream Handle (SH)

A Stream Handle (SH) represents a top-level reference to a stream. The stream

handle is exposed to the application layer, especially on the Upper Streaming

Interface and the Reporting Interface. Moreover, the stream handle refers to the

stream context associated with that stream.

The stream handle is a device-local identifier. It is independently assigned by the

AVDTP entities of the INT and the ACP during the establishment of the stream

connection. The scope of the stream handle is not local to a connection to a specific

peer device (not connection-local). The stream handle is never exchanged on the air

interface.

4.10 Stream End Point Identifier (SEID)

In contrast to the stream handle, the Stream End-Point Identifier (SEID) represents

a cross-device reference to a specific stream. This reference is used in the signalling

transactions; i.e., on the air interface, between the peer AVDTP entities.

A SEID is assigned at application level, of a device that responds to a stream

discovery procedure. Here, the responding device exposes its basic stream end-

points and basic capabilities, audio/video, SNK/SRC, and assigns the SEID as a

unique reference for the further transactions. To prevent conflicts, the scope of the

SEID shall be both device-local and connection-local. The application is responsible

for assigning a SEID, which is not in use on the connection to the same peer device.

In the course of a stream set-up procedure, both AVDTP entities create the

association between the local SEID and the local Stream Handle and typically store it

Release Date: 2003-02-07

BLUETOOTH SPECIFICATION

Audio/Video Distribution Transport Protocol Specification Page 20 of 145

in the Stream Context. Both SEID and Stream Handle appear on the Upper

Signalling Interface.

Note: A unique mapping exists in each AVDTP entity between the Stream Handle

and the pair of remote device address and SEID.

4.11 Stream End Point State

Various operations and transactions apply to a stream. A state machine is related to

each stream and serves to control these operations. Aspects influencing the Stream

State are, for example, if the negotiation procedure is in progress or complete, if

transport channels are being established and assigned, if applications are expected

to send or receive data on an available stream connection.

4.12 Transport Session

Internally to the A/V transport layer, a stream can be decomposed into one, two, or

three transport sessions, which exist between the peer AVDTP entities. Each

transport session can be used for only one AVDTP packet category, which means

Media, Recovery, or Reporting packets.

Thus, each stream connection comprises at least one-transport session containing

Media packets. If packet recovery (RTP-FEC) is supported on a stream connection,

another transport session contains the recovery packets. If QoS reporting (RTCP) is

supported on a stream connection, another transport session contains the Reporting

packets. A Transport Session Identifier (TSID, see Section 4.13) is used to refer to a

transport session.

4.13 Transport Session Identifier (TSID)

The Transport Session Identifier (TSID) represents a reference to a Transport

Session. Only in case of the Multiplexing Mode, the TSID is exchanged on the air

interface (as part of the Media, Recovery, or Reporting packet header). In other

terms, if the Multiplexing Mode is not configured on a stream connection, the TSID is

not explicitly used.

The TSID is a cross-device reference, though its scope is connection-local. It is

assigned by the AVDTP entity of the INT and shall be adopted by the AVDTP entity

of the ACP.

The association of the contents type of a specific Transport Session (either Media,

Recovery, or Reporting packets) is signalled by the INT during the stream

establishment procedure. After that, the association is maintained in the Stream

Context of both devices.

Release Date: 2003-02-07

剩余144页未读，继续阅读

zzluohe

粉丝: 0
资源: 10

蓝牙音频视频传输协议规范V1.0

A2DP协议中文精简版

AVDTP_SPEC_V13.rar

CSR蓝牙A2DP协议

android avdtp start流程

怎么让bluedroid建立AVDTP前发起SDP服务查询

AVDTP怎么调节音量

一个完整的AVDTP数据包

怎么让bluedroid协议栈AVDTP连接前不跳过SDP查询

AVDTP avrcp

A2DP/AVDTP/AVRCP

如何在bluedroid避免蓝牙两端同时发起AVDTP 的L2CAP连接

Android手机连接蓝牙耳机后，点击播放音乐，是先startoutput还是先avdtp start

bluedroid协议栈中怎么修改 让AVDTP的l2cap通道建立前先发起SDP l2cap通道的建立

Frame62：Master->AVDTP_DISCOVER 00000001 00000000 00000110 00000000 00000010 00000000 01000010 00000000 00000000 00000001逐个字节解释

bluedroid协议栈在哪个函数判断，当前等待队列中有AVDTP 的l2cap连接，从而以No resources的理由拒绝连接

怎么让bluedroid协议栈在发起AVDTP的l2cap通道建立前，先发起sdp audio sink/source查询。

linux蓝牙协议栈

蓝牙协议栈中，安卓9与安卓12的AVDT有什么不一样，修改了什么内容 具体体现在哪些代码中

蓝牙协议栈中#ifndef AVDT_SINK_DELAY_MS #define AVDT_SINK_DELAY_MS 300 #endif这个延时主要用于哪些功能

BlueZ和Wireshark分别支持哪些蓝牙协议？

最新资源

bluedroid协议栈中怎么修改让AVDTP的l2cap通道建立前先发起SDP l2cap通道的建立

蓝牙协议栈中，安卓9与安卓12的AVDT有什么不一样，修改了什么内容具体体现在哪些代码中