流媒体avb传输协议数据包分析

AV传输协议数据包分析

AB传送协议改进了之前二层通讯协议(如obrNe 或the  Sound的固有“先天性不足”。在控制能力大幅提升的前提下,借鉴了IEE1394技术,在三层协议下传输同步的专业音/视频信号,并将传输延时压缩到微秒级。

AV传送协议对数据流的三个主要定义:

1、 多媒体格式及封装方法。包括原始数据流和压缩音、视频流以及附带传输 EEE   4 I EEE 139 接口是苹果公司开发的串行标准,俗称火线接口 firewi e 。同SB一样,  EE  394也支持外设热插拔,可为外设提供电源,省去了外设自带的电源,能连接多个不同设备支持同步数据传输。火线)的信号。

2、流媒体传送的同步机制。包括基准时钟的同步和丢失重建,以及同步时钟延时控制和优化。

3、 多播地址的分配。包括为VB数据流分配ID以及媒体时钟发生器的分配方式。

AB传送协议在OIS模型中的位置如图一所示

图1 VB协议集在SI模型中的层次

PS:音频视频桥接 IEEE  02.  VB和IEE1  22/  7  )跨过混合使用网络为音视频流提供高服务质量的传输。

MS开发了一种灵活的、纯软件配置的VB音频,该种音频可以被配置成支持超过 00个音频通道(借助以太网)的单立体声对。 MO器件确定性的架构完美地匹配了AVB的低延时和时序同步特性,同时MO器件也拥有了集成数字音频接口、 P IP和DSP处理控制功能的能力。

从图一看出AVB协议组基本上跨越了TC/  协议组的全部层次,而不仅仅是二层协议传输且为可路由协议,这就从传输本质上区别于二层的CobraN 和E  e  So nd协议。尽管AVB可以支持三层路由,但是并非意味着它可以发送到 nterne 公网中去或者架构在I  ter  et架构下的VN上去。这是因为远距离传输的基准时钟延时问题没有根本得到解决,网络直径依然无法超过7个hop。这么说来,那这个三层协议好处在哪里呢由于Q的介入,使得数据管理和传输效率大大提高更多的基于TP/  P的硬件、

管理软件可以支持VB。这使得AB的各方面能力都是非常强大而灵活的。尽管刚才说AVB协议集包含的数据包类型繁多,但是每种不同用途的AV数据包的基本框架结构是一样的,如图二所示。

图2  AVB数据包构成

上述的AB数据包结构只是它的二层结构类型,也就是针对二层以太网传送的协议结构,而针对三层传输和控制协议则封装在AB以太网荷载(P   oa  的 6~150 字节当中另外定义。如果不理解这句话的意思,可以查阅相关TCP/IP数据结构相关书籍或者参考本连载之前的关于CobraNe 数据结构封装的章节。简单来说,网络数据包封装就是一个“嵌套”结构,二层底层是最外层封装,三层结构则被镶嵌在内等等,如图三:

图3. 网络封装的“嵌套”结构

图二中从DA高位地址一直到AVB以太网类型之间的18个字节就是图三的以太网报头部分图二中的AVB以太网荷载4    50 字节,就是对应图三的二层荷载 ay l o ad 。也就是说图二分析了整个以太网数据包的数据结构但是对于二层AB荷载  6~ 500字节)并未展开分析里面包含了什么数据,那么下面我们就单独分析这个AVB荷载的结构,这也是AV技术和以前o  raNe t及Et   ro n技术完全不同的地方。A数据包按照包类型可以分为命令/控制数据包和流媒体数据包两大类,下面我们分两部分展开来讨论。

1、命令控制数据包:

2、

图4 命令控制数据包结构

这种数据包包含了命令发布和控制信号、数据流预约等除流媒体信号以外的其它数据结构包,属于第三层数据封装包(路由器层次 。第一个bit数据位称为C数据位只有两种表示状态,“”表示流媒体数据,“1”表示控制型数据。 4~11这个字节的802  1Qa 预约数据协议ID号码,它相当于TCP/I 协议集中的IP地址比如192.168.0  是4个字节“0xC0A8 0x0  01”,表示的是目的地地址,后面紧接的1  2.1  8.0.1则是发送端地址,这样一共是个字节。在VB协议中,由于发送端和接收端不再使用 P地址的命名方法,而是使用标识D来区别不同的设备,但是其作用和在数据包中的位置是与TC/I 协议集类似的 。最后的1~3个字节的补足位是当荷载数据较短的时候即三层荷载不足 4个字节的时候 ,AV控制设备自动添加足够的“0”来补足位数,称为“Pd in ”,以防止超短帧的形成。超短帧是指以太网数据包低于64字节(或者超过1  18个字节的时候,以太网传送机制CSA/C无法判断相邻接收帧的间距而形成网络冲突,为避免这种冲突出现,以太网规定了每个数据包的最小和最大长度。

3、流媒体数据流包:

图五 流媒体数据包结构

流媒体数据的数据结构显然比控制数据包复杂很多,但是基本含义没有太多的复杂性,和图四类似。以前提过AVB传输的媒体流数据可以是很多种类型,包含压缩和不压缩的音频及视频以及卫星电视数据等不同种类,这些不同类型的数据在媒体流数据包中在7  i 的协议类型中得以体现,参见下图六:

上表中提到的 18  3的全称是IEC  8  3,要想了解这个规范,先简单介绍一下什么是IEC。 I C标准即国际电工委员会 I  tern  tio  a   lectr  c  lCommission ,是由各国电工委员会组成的世界性标准化组织其目的是为了促进世界电工电子领域的标准化。 国际电工委员会的起源是1  04年在美国圣路易召开的一次电气大会上通过一项决议。根据这项决议,1906年成立了IEC,它是世界上成立最早的一个标准化国际机构。 I C对很多电气规范做出国际标准,其中针对工业音频、视频等传输和接口方式作出定义(电脑中常用的1394火线接口就是I   883-6定义的) ,我们现在讨论的AVB以太网传输协议,只是从传输层面上作出一个新的规范,但是在AV内部传输的流媒体数据则是按照IEC    3规定的格式进行的。 IEC61883包含的数据格式有:

· 18832 -CR标清视频记录数据流格式

·6188  4 MPEG2TS压缩视频数据流格式

·6  8  3- 非压缩音频数据格式即 EEE1  94传输格式)

·61  837 卫星电视 MPEG压缩格式

·61   3-8 Bt.6  1/65 视频流格式

·IIC非压缩工业级摄像头视频流传输格式

当然上述的只是几个我们可能会用到的数据格式,还有很多我们没有一一例举。简单地说也就是所有I 6188 定义的音视频数据流都可以通过AVB进行传送。这里我们重点讨论一下非压缩音频数据的传输,也是就是I C61883-6即IEEE1  94格式的数据流是怎样传输的。

由于  94信号和AB传输协议的兼容性,所以直接通过火线转换成以太网信息也是可以加入到AV网络中来,他们的相互传输见图七:

图7. AVB传送 EE1394数据桥兼容性

从图七我们可以看出AB和I E1394之间的兼容性还是相当的不错,无论是从A

发送器还是1394发送器发送的信号,都可以从两者的接收端接受(同步 。这样跨越AVB和 394之间的传输本身并没有太多的实际应用这主要是用来分析IEC61883定义的媒体数据流可以兼容地通过AVB网络。

在AVB发送和接收端,流媒体数据和标准时钟信号是怎样结合起来并打包形成以太网数据包的呢?详细的打包和解包的过程参见图八和图九:

图8.AVB数据流的合成过程

图9.AVB信号的解包过程

图八的AVB数据包合成过程中,本地晶振相对时钟和 EE1  8 绝对时钟之间做时基比较和校正确保时钟上升和下降沿的准确。 由这两个时钟运算形成AVB时间戳,用来和流媒体数据进行绑定。那么图八中的模拟流媒体信号为什么还要和晶振时钟相乘呢这是因为模拟信号在进行AD转换的时候,要必须和采样时钟进行卷积,如果另外再为这个流媒体模拟信号再建一个晶振那么当这个模数转换后的信号又必须重新和时间戳进行相互校正,反而变得复杂了。所以此处巧妙的利用了生成时间戳的本地晶振信号直接发出AD卷积所需的采样频率(例如VB传输音频信号时会按照IEE1   4格式的 8 Hz, 4bi 音频格式进行量化,那么采样频率就直接将AVB时间戳的晶振信号转换到48kHz  ,这样在数据流信号A变换以后就可以无缝地和时间戳合并发送了。

图九的过程基本上是和图八相反的过程接收端接收到的数据和本地晶振时钟做反变换,就可以通过A变化输出模拟媒体流信号了。

在流媒体时钟的管理上,一个接收点可以接收多达256个独立的媒体时钟。这就意味着一个网络中可以同时存在多达 56个完全不同的流媒体文件,例如可以同时存在 48kH音频

采样数据、 44.1kHz音频采样数据以及同步锁相的视频数据流甚至压缩MPE2视频数据流等等。尽管它们之间采用完全不同的B时间戳但是由于每种不同的AVB数据包可以采用不同的本地晶振进行解包,使得不同数据类型的数据在相同的网络中交叉传递称为了现实。这是二层数据传输时代(如Cob  a  et Et  erSound技术)所无法超越的。一般地来说,不同采样的音频数据源在进行AD变化的时候,采用不同的采样频率或者转换采样频率不是很困难的事情但是在很多的实际工程中视频信号的传递格式确实是五花八门,有压缩的,不压缩的,有高清的,标清的,摄像机以及监控系统等等,所以一个大型传输控制系统能同时兼容不同格式的数据确实显得十分重要。

延时控制上,如果一个流媒体源的接收端横跨在不同的hp上面也就是不同接收点在网络的不同位置,经过的电缆长度和交换机数量都不相同 那么在接受一个广播的同源信号在会放上能否保持同步呢?这个也是AV在设计之初已经考虑过的事情了,由于网络的最长容忍延时是2毫秒,所以第一个接收端在收到信号以后不会立刻转换解包,而是要等到网络中所有接收端都在时钟上确认了同步才会一起向外发送流媒体数据。

关于多播地址配置协议。要求媒体流地址必须是唯一的;其次就是多播流媒体地址必须是2层以上的地址,例如IP、RTP、UD等在AVB上可以支持 v或者I v6两种不同的多播地址,以适应未来的需要。

本期我们主要讲述了AVB发送和接受数据流的数据包结构,通过这些包结构和之前的二层传输技术相比主要区别在:

·系统的延时大大降低至2毫秒以下

·系统的传输质量有o保证,包括软件和硬件均支持

·AVB作为流媒体的一个载体,可以传送包括压缩和非压缩等多种音视频流媒体,并能保证同步传输,突破以往的瓶颈

·多达256种不同格式的音视频数据流包括采样频率)可以在同一个网络中共存传输,而互不干扰

·支持其它3层协议的高级功能

这些特点都表明它将是下一代流媒体文件传输的标准之一,无论是专业还是民用领域,都将展现出它的强大魅力。