AVB传输协议数据包分析Word文件下载.doc
《AVB传输协议数据包分析Word文件下载.doc》由会员分享,可在线阅读,更多相关《AVB传输协议数据包分析Word文件下载.doc(7页珍藏版)》请在冰点文库上搜索。
![AVB传输协议数据包分析Word文件下载.doc](https://file1.bingdoc.com/fileroot1/2023-4/30/7a3be828-116d-49b3-b4af-0fe121c62862/7a3be828-116d-49b3-b4af-0fe121c628621.gif)
包括基准时钟的同步和丢失重建,以及同步时钟延时控制和优化。
3、多播地址的分配。
包括为AVB数据流分配ID以及媒体时钟发生器的分配方式。
AVB传送协议在OIS模型中的位置如图一所示
图1AVB协议集在OSI模型中的层次
PS:
音频视频桥接(IEEE802.1AVB和IEEE1722/1733)跨过混合使用网络为音视频流提供高服务质量的传输。
XMOS开发了一种灵活的、纯软件配置的AVB音频,该种AVB音频可以被配置成支持超过100个音频通道(借助以太网)的单立体声对。
XMOS器件确定性的架构完美地匹配了AVB的低延时和时序同步特性,同时XMOS器件也拥有了集成数字音频接口、TCP/IP和DSP处理控制功能的能力。
从图一看出AVB协议组基本上跨越了TCP/IP协议组的全部层次,而不仅仅是二层协议传输,且为可路由协议,这就从传输本质上区别于二层的CobraNet和EtherSound协议。
尽管AVB可以支持三层路由,但是并非意味着它可以发送到Internet公网中去,或者架构在Internet架构下的VPN上去。
这是因为远距离传输的基准时钟延时问题没有根本得到解决,网络直径依然无法超过7个hop。
这么说来,那这个三层协议好处在哪里呢?
由于QoS的介入,使得数据管理和传输效率大大提高,更多的基于TCP/IP的硬件、管理软件可以支持AVB。
这使得AVB的各方面能力都是非常强大而灵活的。
尽管刚才说AVB协议集包含的数据包类型繁多,但是每种不同用途的AVB数据包的基本框架结构是一样的,如图二所示。
图2.AVB数据包构成
上述的AVB数据包结构只是它的二层结构类型,也就是针对二层以太网传送的协议结构,而针对三层传输和控制协议则封装在AVB以太网荷载(Payload)的46~1500字节当中另外定义。
如果不理解这句话的意思,可以查阅相关TCP/IP数据结构相关书籍,或者参考本连载之前的关于CobraNet数据结构封装的章节。
简单来说,网络数据包封装就是一个“嵌套”结构,二层底层是最外层封装,三层结构则被镶嵌在内等等,如图三:
图3.网络封装的“嵌套”结构
图二中从DA高位地址一直到AVB以太网类型之间的18个字节就是图三的以太网报头部分,图二中的AVB以太网荷载46~1500字节,就是对应图三的二层荷载(Payload)。
也就是说图二分析了整个以太网数据包的数据结构,但是对于二层AVB荷载(46~1500字节)并未展开分析里面包含了什么数据,那么下面我们就单独分析这个AVB荷载的结构,这也是AVB技术和以前CobraNet及EtherSound技术完全不同的地方。
AVB数据包按照包类型可以分为命令/控制数据包和流媒体数据包两大类,下面我们分两部分展开来讨论。
1、命令/控制数据包:
2、
图4.命令/控制数据包结构
这种数据包包含了命令发布和控制信号、数据流预约等除流媒体信号以外的其它数据结构包,属于第三层数据封装包(路由器层次)。
第一个bit数据位称为CD数据位,只有两种表示状态,“0”表示流媒体数据,“1”表示控制型数据。
4~11这8个字节的802.1Qat预约数据协议ID号码,它相当于TCP/IP协议集中的IP地址(比如192.168.0.1是4个字节“0xC0A80x0001”,表示的是目的地地址,后面紧接的192.168.0.1则是发送端地址,这样一共是8个字节。
在AVB协议中,由于发送端和接收端不再使用IP地址的命名方法,而是使用标识ID来区别不同的设备,但是其作用和在数据包中的位置是与TCP/IP协议集类似的)。
最后的1~3个字节的补足位是当荷载数据较短的时候(即三层荷载不足34个字节的时候),AVB控制设备自动添加足够的“0”来补足位数,称为“Padding”,以防止超短帧的形成。
超短帧是指以太网数据包低于64字节(或者超过1518个字节)的时候,以太网传送机制CSMA/CD无法判断相邻接收帧的间距而形成网络冲突,为避免这种冲突出现,以太网规定了每个数据包的最小和最大长度。
3、流媒体数据流包:
图五流媒体数据包结构
流媒体数据的数据结构显然比控制数据包复杂很多,但是基本含义没有太多的复杂性,和图四类似。
以前提过AVB传输的媒体流数据可以是很多种类型,包含压缩和不压缩的音频及视频以及卫星电视数据等不同种类,这些不同类型的数据在媒体流数据包中在7bit的协议类型中得以体现,参见下图六:
上表中提到的61883的全称是IEC61883,要想了解这个规范,先简单介绍一下什么是IEC。
IEC标准即国际电工委员会(InternationalElectricalCommission),是由各国电工委员会组成的世界性标准化组织,其目的是为了促进世界电工电子领域的标准化。
国际电工委员会的起源是1904年在美国圣路易召开的一次电气大会上通过一项决议。
根据这项决议,1906年成立了IEC,它是世界上成立最早的一个标准化国际机构。
IEC对很多电气规范做出国际标准,其中针对工业音频、视频等传输和接口方式作出定义(电脑中常用的1394火线接口就是IEC61883-6定义的),我们现在讨论的AVB以太网传输协议,只是从传输层面上作出一个新的规范,但是在AVB内部传输的流媒体数据则是按照IEC61883规定的格式进行的。
IEC61883包含的数据格式有:
·
61883-2SD-DVCR标清视频记录数据流格式
61883-4MPEG2-TS压缩视频数据流格式
61883-6非压缩音频数据格式(即IEEE1394传输格式)
61883-7卫星电视MPEG压缩格式
61883-8Bt.601/656视频流格式
IIDC非压缩工业级摄像头视频流传输格式
当然上述的只是几个我们可能会用到的数据格式,还有很多我们没有一一例举。
简单地说也就是所有IEC61883定义的音视频数据流都可以通过AVB进行传送。
这里我们重点讨论一下非压缩音频数据的传输,也是就是IEC61883-6即IEEE1394格式的数据流是怎样传输的。
由于1394信号和AVB传输协议的兼容性,所以直接通过火线转换成以太网信息也是可以加入到AVB网络中来,他们的相互传输见图七:
图7.AVB传送IEEE1394数据桥兼容性
从图七我们可以看出AVB和IEEE1394之间的兼容性还是相当的不错,无论是从AVB发送器还是1394发送器发送的信号,都可以从两者的接收端接受(同步)。
这样跨越AVB和1394之间的传输本身并没有太多的实际应用,这主要是用来分析IEC61883定义的媒体数据流可以兼容地通过AVB网络。
在AVB发送和接收端,流媒体数据和标准时钟信号是怎样结合起来并打包形成以太网数据包的呢?
详细的打包和解包的过程参见图八和图九:
图8.AVB数据流的合成过程
图9.AVB信号的解包过程
图八的AVB数据包合成过程中,本地晶振相对时钟和IEEE1588绝对时钟之间做时基比较和校正,确保时钟上升和下降沿的准确。
由这两个时钟运算形成AVB时间戳,用来和流媒体数据进行绑定。
那么图八中的模拟流媒体信号为什么还要和晶振时钟相乘呢?
这是因为模拟信号在进行AD转换的时候,要必须和采样时钟进行卷积,如果另外再为这个流媒体模拟信号再建一个晶振,那么当这个模数转换后的信号又必须重新和时间戳进行相互校正,反而变得复杂了。
所以此处巧妙的利用了生成时间戳的本地晶振信号,直接发出AD卷积所需的采样频率(例如AVB传输音频信号时,会按照IEEE1394格式的48kHz,24bit音频格式进行量化,那么采样频率就直接将AVB时间戳的晶振信号转换到48kHz),这样在数据流信号AD变换以后就可以无缝地和时间戳合并发送了。
图九的过程基本上是和图八相反的过程,接收端接收到的数据和本地晶振时钟做反变换,就可以通过DA变化输出模拟媒体流信号了。
在流媒体时钟的管理上,一个接收点可以接收多达256个独立的媒体时钟。
这就意味着一个网络中可以同时存在多达256个完全不同的流媒体文件,例如可以同时存在:
48kHz音频采样数据、44.1kHz音频采样数据以及同步锁相的视频数据流甚至压缩MPEG2视频数据流等等。
尽管它们之间采用完全不同的AVB时间戳,但是由于每种不同的AVB数据包可以采用不同的本地晶振进行解包,使得不同数据类型的数据在相同的网络中交叉传递称为了现实。
这是二层数据传输时代(如Cobranet,EtherSound技术)所无法超越的。
一般地来说,不同采样的音频数据源在进行AD变化的时候,采用不同的采样频率或者转换采样频率不是很困难的事情,但是在很多的实际工程中,视频信号的传递格式确实是五花八门,有压缩的,不压缩的,有高清的,标清的,摄像机以及监控系统等等,所以一个大型传输控制系统能同时兼容不同格式的数据确实显得十分重要。
延时控制上,如果一个流媒体源的接收端横跨在不同的hop上面(也就是不同接收点在网络的不同位置,经过的电缆长度和交换机数量都不相同),那么在接受一个广播的同源信号在会放上能否保持同步呢?
这个也是AVB在设计之初已经考虑过的事情了,由于网络的最长容忍延时是2毫秒,所以第一个接收端在收到信号以后不会立刻转换解包,而是要等到网络中所有接收端都在时钟上确认了同步,才会一起向外发送流媒体数据。
关于多播地址配置协议。
要求媒体流地址必须是唯一的;
其次就是多播流媒体地址必须是2层以上的地址,例如IP、RTP、UDP等;
在AVB上可以支持IPv4或者IPv6两种不同的多播地址,以适应未来的需要。
本期我们主要讲述了AVB发送和接受数据流的数据包结构,通过这些包结构和之前的二层传输技术相比,主要区别在:
系统的延时大大降低至2毫秒以下
系统的传输质量有QoS保证,包括软件和硬件均支持
AVB作为流媒体的一个载体,可以传送包括压缩和非压缩等多种音视频流媒体,并能保证同步传输,突破以往的瓶颈
多达256种不同格式的音视频数据流(包括采样频率)可以在同一个网络中共存传输,而互不干扰
支持其它3层协议的高级功能
这些特点都表明它将是下一代流媒体文件传输的标准之一,无论是专业还是民用领域,都将展现出它的强大魅力。