本文是AVB系列文章的第三篇,主要介绍AVB协议族中的音视频传输协议AVTP(IEEE Std 1722-2016)。
AVTP是个链路层传输协议,其主要作用有两个:
AVTP是链路层的传输协议,并且是基于VLAN的,在以太网帧中的位置如下所示:
针对不同的音视频格式,AVTP有不同的Header和Payload格式。(注:AVTP的Header其实是分了几个层级的,包含通用部分和随音视频格式变化部分,这里不再详细介绍。)
本文主要基于H264介绍AVTP。
下图是AVTP封装H264视频数据时的头部结构:
我们结合实际报文重点关注图中编号了的几个字段,上图编号和下图抓包中的编号一一对应:
为了便于理解后续部分,我们首先简单介绍下H264和RTP相关知识。
H264帧由多个NALU单元组成,如下图所示,其中Start Code就是0x000001或0x00000001,NALU Header中包含该NALU的类型。
H264帧分为I帧、P帧、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中的两个时间戳有帮助。
RTP封装H264数据是以NALU为单位进行的,而不是以帧为单位进行的,相应规范是RFC 6184规范(RTP Payload Format for H.264 Video)。
RTP打包模式有下面三种:
RTP打包使用哪种模式,是由编码器决定的,不能随便填。
RTP包类型又包含以下几种:
打包模式与包类型之间的关系如下,并不能随便使用:
我们的视频数据是Non-interleaved mode模式,所以理论上可以使用上图中的NAL unit、STAP-A和FU-A三种包类型,但通常情况下不会把多个NALU聚合在一起发送(增加复杂度),所以实际只使用了NAL unit和FU-A两种包类型,前者用来封装较小不需要分片的NALU,后者用来封装需要分片的NALU。
AVTP的h264_payload是遵循RFC 6184规范(RTP Payload Format for H.264 Video)的。 前面提到,我们只使用了NAL unit和FU-A两种包类型,前者用来封装较小不需要分片的NALU(下图左半部分),后者用来封装需要分片的NALU(下图右半部分)。
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典型的处理流程:
结合AVTP Presentation Time
和Max Transit Time
的定义,可以看到:它可以指示接收端在未来的某一时刻处理音视频数据;数据可以提前到(提前到的要等待,直到时刻AVTP Presentation Time到来才能被处理),但绝不能迟到(你说你在时间点AVTP Presentation Time到达,结果迟到了,只有被丢弃)。就像是一次准时开始的会议,提前到的要等待会议开始,迟到者无法听到前面的内容。在这种机制保障下,考虑下面的两个场景,是不是都可以达到同步效果?
媒体时钟同步,解决的是按采集速度和播放速度一致的问题(相对时间同步的问题)。
视频的媒体时钟一般都是90KHz,理想情况下,大家以同样的频率震荡,但是随着时间的流逝或者环境影响,会漂移,这样就会导致talker和Listener的媒体时钟不同步,进而表现为播放不正常(播放的太快或太慢)。
媒体时钟恢复,是指Listener根据AVTP Presentation Time重建媒体时钟,使之和采集端保持同步,进而指导音视频以采集时的速率播放,流程如下:
AVTP中也可以定义专门的Media Clock Stream,用来同步相关节点的媒体时钟,这里不再展开介绍。
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)的角色,用以指示正确的显示顺序。
在非交叉模式下,该值可填充也可不填充。