AVB音视频传输协议简介

  • 一、音视频传输面临的主要问题
  • 二、如何解决这些问题
    • 1. 网络传输问题
    • 2. 媒体时钟同步问题
  • 三、AVB体系
    • 1.协议框架
    • 2. 网络拓扑
    • 3. 典型应用场景
      • a. 车载娱乐系统
      • b. 大型演唱会现场
  • 四、参考资料

本文是AVB系列文章的第一篇,简单介绍车载以太网中的AVB技术。

一、音视频传输面临的主要问题

大家想一下,在观看网络视频的时候,经常遇到的问题是什么?

  1. 卡顿
  2. 花屏
  3. (实时直播)延时大
  4. 音视频不同步

假设音视频源正常的,造成以上问题的原因是什么呢?

  1. 卡顿:网络不流畅、数据不能及时到达。
  2. 花屏:视频数据丢失、错误。然而这只是表面原因,根本原因也是网络不流畅、数据不能及时到达。
  3. (实时直播)延时大:网络不流畅、数据不能及时到达。
  4. 音视频不同步:网络网络不流畅、数据不能及时到达会造成这种现象,另外,媒体时钟不同步也会造成这种现象。

这样看来,影响网络音视频观看体验的主要原因基本上就下面两点:

  1. 网络不流畅,数据丢失或不能及时到达
  2. 媒体时钟不同步

这也是AVB要解决的主要问题。不同的是,我们观看网络视频一般是经由广域网传输,而AVB解决的是局域网内的音视频传输问题。

二、如何解决这些问题

1. 网络传输问题

我们知道,传统以太网是基于竞争的“尽最大努力传输”的分组报文网络。有人可能会说TCP是可靠的,不错,但它的可靠性是建立在重传机制上的,带来的副作用是延时加大。

另外,中间转发节点(比如网络中的交换机、路由器)对报文的传输影响比较大。比如:

  • 传输过程中,如果中间的转发节点缓存队列已满,会导致后续数据包丢失。
  • 传输时延受转发节点的缓存状态影响,如果缓存队列中数据较多,传输延时就较大,缓存队列中数据较少,传输延时就较小。

如果可以构建这样一个网络,它可以为音视频数据预留带宽(类似高速公路上的专用应急车道),那么不仅解决了竞争问题,还保证了音视频数据可以在规定的时间内从源头传输到目的地(时间敏感网络的概念)。

没错,带宽预留是AVB的一个重要组成部分。

2. 媒体时钟同步问题

以太网中传输的音视频都是离散的数字信号,而现实世界中的音视频都是连续的模拟信号。在音视频采集设备中,需要对模拟信号进行采样、量化、编码,才能转换为数字信号(简称模数转换,即A/D转换)。A/D转换过程中涉及到采样频率,即间隔多久采样一次。接收端收到数据后,按同样的频率进行播放。这就是媒体时钟同步

媒体时钟必须有个参考时钟,这样它才能知道从上次采集到现在过了多久,是否该进行下次采样。有的采集系统以系统时钟作为参考时钟,而有的采集系统以外部信号作为参考时钟。不同参考时钟很有可能是不同步的,比如A时钟的1ms可能对应实现世界的0.9ms,B时钟的1ms可能对应现实世界额1.1ms。另外,时钟都不是绝对稳定的,受温度、运行时间等因素影响都会产生漂移(就像手表,有的过段时间变慢了,有的过段时间变快了)。

问题来了,接收端怎么保证自己的播放速率和采集端的采集频率一致(即如何恢复媒体时钟)?如果没有一个统一的参考时钟,这是很难做到的。如果参考时钟不同步,就有可能导致本来该先播放的音频后播放,或者本该先播放的视频后播放,在观众看来就是音视频不同步。

AVB中的精确时钟同步技术,可以让所有节点的时钟保持同步,进而为媒体时钟同步提供了条件。

三、AVB体系

AVB被称为时间敏感网络,主要包含两方面含义:

  • 延时小,实时性好
  • 延时可控,最坏情况下的延时不超过一定的阈值

1.协议框架

AVB的全称是Audio Video Bridging,由一系列IEEE标准组成,目的是在局域网中高效传输音视频数据。

AVB协议栈如下图所示:

可以看出,AVB主要是链路层的协议,它和传统的TCP/IP协议栈是并列共存的关系。

AVB协议栈不仅包括了前面提到的带宽预留和时钟同步协议,还包括其他一些辅助协议,主要协议如下:

  1. IEEE Std 802.1AS-2011:精确时钟同步协议(Generalized Precision Time Protocol,简称gPTP),用来将网络内所有节点的时钟同步同步到同一个主时钟。
  2. IEEE Std 802.1 Qat:带宽预留协议(Stream Reservation Protocol,简称SRP),目前被整合在IEEE Std 802.1Q-2011 第35章。
  3. IEEE Std 802.1 Qav:流量整形协议(Forwarding and Queuing for time-sensitive streams,简称FQTSS),负责对流量进行排队、转发管理,目前被整合在IEEE Std 802.1Q-2011 第34章。
  4. IEEE Std 1722-2016:音视频传输协议(Audio Video Transport Protocol,简称AVTP)。
  5. IEEE Std 1722.1-2013:音视频管理协议(Audio Video Discovery, Enumeration, Connection management, and Control protocol,简称AVDECC),负责服务发现,节点能力遍历,链接管理等控制功能。
  6. IEEE Std 1733-2011:基于AVB的RTP/RTCP传输协议(Transport Protocol for Time-Sensitive Applications in Local Area Networks),它主要用于协调网络中的多个设备,比如以下场景:网络中有多个Talker且位于不同设备,接收端需要同步播放这些Talker的音视频数据。

2. 网络拓扑

AVB的网络拓扑如下所示:

它主要由两类节点组成:

  • End Station: 有时候也称为endpoint,它又分为Listener和Talker两种:
    • Listener:接收音视频数据的节点
    • Talker:输出音视频数据的节点
  • AV Bridge: 音视频网关

说明:

  • 一个节点可以包含多个Talker,即产生多条音视频数据流
  • 一个节点可以具有Talker和Listener的双重身份,既对外输出,又接收别人的数据

3. 典型应用场景

目前AVB主要应用在对时间敏感的场景中,比如工业控制,车载娱乐系统。下面简单举两个例子。

a. 车载娱乐系统

如上图所示,车内的DVD Player播放音视频文件,音频传输到扬声器,视频分别传输到后排座椅的两个显示器上。如何保证扬声器和两个显示器的同步,实现音视频同步?

  • 首先,gPTP协议保证了网络中所有节点的时钟是同步的。
  • 其次,SRP协议为音视频数据预留了带宽,保证都能在一定的时间内到达目的地。
  • 那么,如果在Talker端(DVR Player)就约定好,不同目的地的音视频数据在未来的同一时刻播放,是不是就实现了音视频同步?这就是AVTP协议中展示时间戳的意义所在。
b. 大型演唱会现场

大型演唱会现场都会布置多个扬声器来传输声音,可以简化成下面的模型。 那么如何控制这些扬声器同时“发声”? 道理一样,大家约定好在未来的同一时刻同时播放,先收到数据的节点把数据缓存起来,等待播放时刻的到来,然后产生“共鸣”。

四、参考资料

  1. https://avb.statusbar.com/page/developer-faq/
<think>嗯,用户想了解IEEE1722AVBTP协议的实现方案。用户应该是在做音视频传输相关的开发,可能是车载系统或专业影音设备领域的工程师,需要具体的技术实现细节而非理论概述。从引用内容看,用户之前关注过AVB协议栈(引用1和2提到802.1AVB标准)和时间同步(引用3的gPTP),说明对底层协议有基础认知。这次聚焦在1722协议实现,需要提供可落地的方案框架。核心要点应包括:1.协议定位:要强调1722是传输协议,基于802.1AS时间同步(引用3的gPTP相关),这点在引用2提到过AVB协议族独立性2.数据封装:引用1提到AVTP协议压缩传输,需展开说明1722的帧结构3.关键实现模块:时钟同步必须依赖gPTP(引用3的测量机制),流预留需用802.1Qat(引用1的流预留协议)4.延迟控制:引用1强调实时性,需说明时间戳机制用户可能真正需要的是如何把麦克风/摄像头数据通过1722可靠传输。考虑在实现方案里加入媒体采集到网络发送的流程,并提示硬件要求(时间感知网卡)。需要警告常见陷阱:时间同步偏差会导致音画不同步(引用3标题提到的时间戳问题)。最后补充测试建议,因为用户问“实现方案”必然涉及验证。</think>以下是关于**IEEE 1722 AVBTP协议实现方案**的详细介绍,结合技术原理与工程实践展开: --- ### **IEEE 1722 AVBTP协议概述** IEEE 1722(**音视频传输协议AVBTP**)是AVB协议栈的核心传输层标准,专为**低延迟、时间敏感型音视频流**设计。其核心功能包括: 1. **时间戳同步**:基于802.1AS的gPTP时钟同步(精度达微秒级)[^3] 2. **数据封装**:将音视频流按时间序列封装为AVTPDU(AVTP Data Unit) 3. **流量整形**:通过802.1Qav队列协议保障实时性[^1] --- ### **实现方案关键模块** #### **1. 协议栈架构** ```plaintext 应用层 (音视频编解码器) ↓ IEEE 1722 AVBTP (传输封装) ↓ IEEE 802.1Qav (流量整形) ↓ IEEE 802.1AS (gPTP时间同步) [^3] ↓ 物理层 (车载以太网/千兆以太网) ``` #### **2. 核心实现步骤** **(1) 时间同步初始化** - 设备通过gPTP协议与主时钟同步: $$ t_{slave} = t_{master} + \frac{(t_2 - t_1) + (t_4 - t_3)}{2} $$ 其中 $t_1, t_4$ 为发送/接收时间戳,$t_2, t_3$ 为响应时间戳[^3] **(2) 流媒体封装** - **AVTPDU帧结构**: ```c struct avtpdu_header { uint8_t subtype; // 流类型 (如IEC 61883-6) uint64_t stream_id; // 全局唯一流标识 uint32_t timestamp; // gPTP同步时间戳 uint16_t seq_num; // 序列号(抗丢包) uint8_t payload[]; // 压缩音视频数据 }; ``` - **封装规则**: - H.264/MPEG-TS等格式按**传输时间间隔**切片 - 每个AVTPDU携带精确的呈现时间戳(PTS) **(3) 流预留协议(SRP)** - 通过802.1Qat协议声明带宽需求: ```plaintext Talker声明流属性 → Listener注册请求 → 交换机带宽预留 ``` 确保端到端延迟 ≤ 2ms(Class A标准)[^1] **(4) 实时传输控制** - **队列调度**:使用Credit-Based Shaper (CBS)算法: $$ \text{credit} = \text{credit} - \Delta t \cdot \text{send_slope} $$ 当credit ≥ 0时才允许发送,保障高优先级流[^2] --- ### **典型实现方案** #### **Linux系统实现案例** ```c // 1. 初始化gPTP时钟 struct gptp_port *port = gptp_init("eth0"); // 2. 创建AVB流 struct avb_stream *stream = avb_stream_create( AVB_STREAM_TYPE_AUDIO, // 流类型 48000, // 采样率 AVB_CLASS_A // 延迟等级 ); // 3. 封装并发送数据 void send_avb_frame(void *data, size_t len) { uint64_t now = gptp_get_time(port); // 获取同步时间 avtpdu_header *pdu = build_avtpdu(stream, data, len, now); netdev_send(pdu); // 通过Qav队列发送 } ``` #### **硬件加速方案** - **FPGA实现核心模块**: - gPTP时间戳硬件提取(降低CPU负载) - AVTPDU零拷贝封装引擎 - **交换机支持**:需支持802.1BA标准转发规则 --- ### **性能优化关键** 1. **时间戳精度**:使用PHY级时间戳(如Intel I210 NIC) 2. **内存管理**:预分配DMA缓冲区避免动态内存申请 3. **中断合并**:启用NAPI减少接收路径延迟 4. **CPU亲和性**:绑定实时线程至独立核心 --- ### **测试验证指标** | 指标 | 目标值 | 测试工具 | |---------------|-------------|---------------| | 端到端延迟 | ≤ 2ms (Class A) | Wireshark TSN插件 | | 时钟偏差 | ≤ ±1μs | PTP4l / linuxptp | | 丢包率 | < 10⁻⁸ | AVTP Pipeline | --- ### **常见问题与解决** - **问题1:音视频不同步** **原因**:gPTP同步偏差 > 1μs **解决**:启用硬件时间戳(配置`ptp4l -H -i eth0`) - **问题2:突发流量导致丢包** **原因**:CBS信用值耗尽 **解决**:调整流量的`max_interval`参数(减小数据包间隔) --- ### **应用场景** 1. **车载娱乐系统**:多屏4K视频分发(需≥100Mbps预留带宽)[^2] 2. **专业音控台**:512通道音频传输(延迟要求≤250μs) 3. **工业视觉**:机器视觉实时流(帧抖动 < 10μs) ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值