转自：AVB简介--第三篇：AVTP简介

本文是AVB系列文章的第三篇，主要介绍AVB协议族中的音视频传输协议AVTP(IEEE Std 1722-2016)。

AVTP是个链路层传输协议，其主要作用有两个：

1. 音视频数据封装：将音视频数据封装成相应的格式在链路层传输。
2. 媒体同步：
   • 媒体时钟同步：不同的媒体类型有自己的媒体时钟，这些媒体时钟都映射到gPTP时间（同一个时间坐标系），接收端可以轻松进行媒体时钟恢复。
   • 展示时间同步(播放时间同步)：数据发送时指示接收方在未来的某个时间点播放，如果有多个接收者，它们就会在未来的同一时刻同时播放。

一、音视频数据封装

AVTP是链路层的传输协议，并且是基于VLAN的，在以太网帧中的位置如下所示：

 

针对不同的音视频格式，AVTP有不同的Header和Payload格式。（注：AVTP的Header其实是分了几个层级的，包含通用部分和随音视频格式变化部分，这里不再详细介绍。）

本文主要基于H264介绍AVTP。

1. 头部结构

下图是AVTP封装H264视频数据时的头部结构：

 

我们结合实际报文重点关注图中编号了的几个字段，上图编号和下图抓包中的编号一一对应：

1. subtype：AVTP子类型，本例为压缩视频格式，一般简称为CVF
2. tv:它用来指示字段5是否有效， 0代表无效，1代表有效；这是因为一个视频单元（NALU)会被拆分为多个AVTP包，规范要求只需要在最后一个AVTP包中添加时间戳即可。
3. sequence_num：包序号，供接收端判断是否丢包、乱序
4. stream_id：流id，用来标识本数据流。长度为64bit, 前48字节定义和MAC地址定义规则一致，大部分直接拿MAC地址作为前48bit，后16bit根据需要自定义分配。
5. avtp_timestamp: AVTP Presentation Time，后面专门介绍
6. format: 用来表明payload承载的音视频数据是自定义格式还是RFC规范定义的格式，本例中是RFC格式的视频。
7. format_subtype: payload承载的音视频数据子类型，本例中是H264格式。
8. M标志位：代表一个NALU的结束。如果一个NALU被拆分为多个AVTP报文，只有最后一个需要把M标志填写成1。
9. h264_timestamp: h264时间戳，后面专门介绍。
10. ptv：用来指示h264_timestamp字段是否有效。本例中未填写h264_timestamp，所以ptv均为0（抓包中未标记）。

 

2. payload结构

为了便于理解后续部分，我们首先简单介绍下H264和RTP相关知识。

2.1 H264基础知识

H264帧由多个NALU单元组成，如下图所示，其中Start Code就是0x000001或0x00000001，NALU Header中包含该NALU的类型。

 

H264帧分为I帧、P帧、B帧三类，其中：

• I帧不存在帧间依赖，可以单独解码成像；
• P帧依赖本帧前面的I帧或P帧（这种依赖是从I帧依次传递过来的，所以中间任何一帧出错都会导致后续帧出错）；
• B帧不仅依赖前面的帧，还依赖后面的帧

如果一个码流中只有I帧和P帧，这种码流属于非交叉编码模式（Non-interleaved mode），帧的解码顺序和显示顺序是一致的；如果码流中包含了B帧，就成为了交叉编码模式（Interleaved mode），帧的解码顺序和显示顺序就不一定是一致的了。

下图中红色为I帧，蓝色为P帧，绿色为B帧。可以看到，第一个B帧在码流中的位置是2（Number in Stream order， 即解码顺序，从0开始），而显示顺序是1（Number in Display order，即显示顺序)。也就是说，它前面的P帧先解码，但要在它之后显示。

B帧使得解码顺序和显示顺序不再一致。记住这一点对后面理解AVTP中的两个时间戳有帮助。

2.2 RTP基础知识

 

RTP封装H264数据是以NALU为单位进行的，而不是以帧为单位进行的，相应规范是RFC 6184规范（RTP Payload Format for H.264 Video）。

RTP打包模式有下面三种：

• Single NAL unit mode：单NALU模式，适用 H.241。
• Non-interleaved mode：非交叉模式，NALU的解码顺序和显示顺序是一致的，先解码的NALU先显示。
• Interleaved mode： 交叉模式，本模式下NALU的解码顺序和显示顺序是不一致的，比如有B帧的情况下。

RTP打包使用哪种模式，是由编码器决定的，不能随便填。

RTP包类型又包含以下几种：

• a. 单个NALU：一个数据报文包含一个完整NALU的
• b. 聚合多个NALU：一个数据报文中包含多个NALU，根据这些NALU的时间戳是否相同，又分为下面两种
  • STAP：一个数据报文包含多个NALU，这些NALU时间戳相同，又分为STAP-A方式和STAP-B方式
  • MTAP：一个数据报文包含多个NALU，这些NALU时间戳不同，又分为MTAP16方式和MTAP24方式
• c. 分片方式：NALU太大，无法用一个数据包传输，需要分片，又分为FU-A和FU-B方式

打包模式与包类型之间的关系如下，并不能随便使用：

 

我们的视频数据是Non-interleaved mode模式，所以理论上可以使用上图中的NAL unit、STAP-A和FU-A三种包类型，但通常情况下不会把多个NALU聚合在一起发送（增加复杂度），所以实际只使用了NAL unit和FU-A两种包类型，前者用来封装较小不需要分片的NALU，后者用来封装需要分片的NALU。

2.3 AVTP封装h264_payload

AVTP的h264_payload是遵循RFC 6184规范（RTP Payload Format for H.264 Video）的。
前面提到，我们只使用了NAL unit和FU-A两种包类型，前者用来封装较小不需要分片的NALU（下图左半部分），后者用来封装需要分片的NALU（下图右半部分）。

 

二、媒体同步

3.1 AVTP Presentation Time

AVTP Presentation Time的含义是呈现时间，表示接收方在该时刻需要将AVTP数据包payload中的音视频数据送到应用层进行处理，比如解码播放。

假设报文经过下图发送参考平面（Ingress Time Reference Plan）的时刻是t1（基于gPTP时间），那么Presentation Time的值就是t1 + Max Transit Time。 假设该Presentation Time用gPTP表示为AS_sec(秒) + AS_ns(纳秒)， 实际打在AVTP头部的时间戳为：(AS_sec × 109 + AS_ns) mod 232。

注：这个时间戳为什么要对gPTP时间做取模处理，规范中并未说明，猜测应该是为了节省字节。因为表示完整的gPTP时间需要占用10个字节，其中6字节用来表示秒，4字节用来表示纳秒，而现在只需要4字节即可。当然，该时间戳4秒就轮回了。

 

那么，Max Transit Time是如何定义的呢？如下图所示，如果音频源到两个扬声器的传输时间分别是t1、t2，Max Transit Time就是二者中的最大值。

 

Max Transit Time的通用定义如下，其中tn为Talker到第n个Listener的最大传输时间。

Max Transit Time = MAX(t1, t2, …, tn)

接下来以H264为例讲解AVTP的媒体同步机制，下图是H264 Over AVTP典型的处理流程：

 

3.2 展示时间同步（播放时间同步）

结合AVTP Presentation Time和Max Transit Time的定义，可以看到：它可以指示接收端在未来的某一时刻处理音视频数据；数据可以提前到（提前到的要等待，直到时刻AVTP Presentation Time到来才能被处理），但绝不能迟到（你说你在时间点AVTP Presentation Time到达，结果迟到了，只有被丢弃）。就像是一次准时开始的会议，提前到的要等待会议开始，迟到者无法听到前面的内容。在这种机制保障下，考虑下面的两个场景，是不是都可以达到同步效果？

3.3 媒体时钟同步

 

媒体时钟同步，解决的是按采集速度和播放速度一致的问题（相对时间同步的问题）。

视频的媒体时钟一般都是90KHz，理想情况下，大家以同样的频率震荡，但是随着时间的流逝或者环境影响，会漂移，这样就会导致talker和Listener的媒体时钟不同步，进而表现为播放不正常（播放的太快或太慢）。

媒体时钟恢复，是指Listener根据AVTP Presentation Time重建媒体时钟，使之和采集端保持同步，进而指导音视频以采集时的速率播放，流程如下：

1. AVTP假设网络中各个节点的媒体时钟都是自由运行的（也就是相互之间不同步）。为了便于接收端恢复媒体时钟，在发送端，Talker把媒体时钟嵌入在展示时间戳中的（采样点对应gPTP的某个时刻），如下图所示：

    

2. 在接收端，媒体时钟从展示时间戳中恢复（AVTP Presentation Time和本地gPTP时间对比，二者同步的时刻对应一个Media Clock的采样点），进而控制音视频的播放。

    

3. 媒体时钟恢复模块示意图如下所示：

    

AVTP中也可以定义专门的Media Clock Stream，用来同步相关节点的媒体时钟，这里不再展开介绍。

3.4 h264_timestamp

AVTP中有了展示时间戳，为什么还要加上h264_timestamp时间戳？

在交叉编码模式（Interleaved mode）下，解码顺序和显示顺序是不一致的。如下图所示，视频数据是按照Frame0、Frame1的顺序依次采集的，接收端也要按这个顺序显示。

 

但是，由于存在B帧，编码器实际的输出顺序如下，接收端也要按照下面的顺序解码：

 

从上面的章节可以了解到，AVTP Presentation Time的作用是DTS（Decoding Time Stamp），在非交叉模式（Non-interleaved mode）下，是可以正常工作的；但是在交叉模式（Interleaved mode）下，由于解码顺序和显示顺序不一致，虽然能按正确的顺序解码，但是不能按正确的顺序显示。

为了解决这个问题，才加上了h264_timestamp，它也是遵循RFC 6184规范的（其实就是RTP头部的时间戳）。它充当的是PTS（Presentation Time Stamp）的角色，用以指示正确的显示顺序。

在非交叉模式下，该值可填充也可不填充。

三、参考资料

1. H264 over RTP 的打包
2. Understanding IEEE’s deterministic AV bridging standards
3. 参考报文：gstream工具生成的报文