IP化视频制播系统中音视频监测方法

摘要

本发明提供IP化视频制播系统中音视频监测方法，可打破国外专业设备一体机的限制，在软件层面实现了便于我们的研究与数据包层面的控制更改。发明采用采集缓存、解析、播放多线程并发的高效形式，通过视频数据流捕获、计算具备不同视频格式适应性初始队列长度、阻塞队列数据缓存、视频数据处理、视频监测与显示五个主要步骤实现IP化视频流的实时解析与监测。本发明可根据不同视频格式适应性队列长度的阻塞队列来缓存视频数据，以及针对视频封装标准的精准解封装和数据处理，达到了低时延、低丢包率的实时视频解析和监测。该方法适用于SMPTE ST 2022‑6或SMPTE ST 2110‑20标准下的标清、高清、超高清不同清晰度的视频格式。

说明书

技术领域：

本发明主要涉及媒体视频制作IP化过程中的基带视频流解析和监测，主要考虑IP基带视频流解析系统的解析监测方法及其装置问题。

IP基带视频流解析监测技术是视频制作全IP化中的一项关键技术，目前仅国外厂商掌握该项技术方法，利用专业设备一体机，监测IP层信号传输、解析的准确性及系统延时，并实时观测视频解析效果。这种专业一体机具有非常高昂的价格，且是基于国外电视媒体系统标准进行解析监测，采用硬件板卡烧制固定程序，不便于我们的研究与数据包层面的控制更改。SMPTE ST 2022和SMPTE ST 2110系列协议的标准，不仅规范了专业视频封装成IP数据包格式，还提供了通过IP方式传输高质量视频信号方法。其中SMPTE 2022-6定义了SDI格式的封装，基于实时传输协议(RTP)和高比特率媒体传输协议(HBRMT)。HBRMT是高比特率传输流的缩写，这里的高比特率是为了跟其他的传输压缩信号区分开来。每一个IP数据包含有1376字节的 SDI数据，为了使每一帧的IP包排列整齐，每帧的最后一个包用零字节填充。 SMPTE ST 2110系列标准将信号的视频、音频及辅助数据各个部分放入不同的流中，单独发送，接收方可以直接单独获取他们想要的流。其中ST 2110-20 规定了在IP网络上基于实时，基于RTP的未压缩活动视频基本的封装及传输格式。ST 2110-20和ST 2022-6传输视频流的区别之在于，为接收和解释流所必需的图像技术元数据定义了专门的基于SDP(会话描述协议)的信令方法，主要传输的内容有采样结构、比特深度、帧率等必需的媒体类型参数和隔行扫描、逐行分段、TCS等带默认值的媒体参数类型。SMPTE ST 2022和SMPTE ST 2110标准使得在现有广播电视基础上，通过IP网络灵活地传输未压缩的视频、音频与辅助数据成为可能。

我们研究团队设计研发了一套具有自主知识产权的运行在普通性能通用计算机上的软件装置，实现数据缓存及处理机制可控制化，低门槛与低成本实现IP基带视频流的解析与系统监测。下面将提出IP视频解析的实现方法及监测指标，并且以我们的系统为例介绍实际使用装置及数据结果。

发明内容

本发明目的在于提供一种新的基于通用计算机运行的软件装置实现IP视频流实时解析与监测的方法，以解决IP视频系统的数据处理透明可控制化、视频流解析技术国产化、通用化的问题。

实现IP视频的解析与监测，需视频数据流捕获、数据存储、视频数据处理(包括解封装、提取像素、缓存像素处理)、视频监测与显示几项复杂操作。其中视频数据流捕获主要依赖于WinPcap实现，可将数据存储在本地 PCAP文件，并实时读取本地PCAP文件进行数据处理，视频数据处理依赖 ST 2022-6、ST 2110等封装协议实现，视频监测与显示通过SDL实现，但是这些仅能在软件方面实现高延时、高丢包率视频的解析与播放，效果较差。

因此，实现一种基于通用计算机运行的软件装置的低延时、低丢包率实时IP视频流解析与监测则为本发明的一大重点和亮点，它需要对数据存储进行更深层次的复杂操作，即需要一个可以实时缓存视频流数据包的装置，来保证IP视频流的实时输入和输出，并且该装置可以自动判断是否为视频流数据包。该装置可打破国外专业设备一体机的限制，在软件层面实现了便于我们的研究与数据包层面的控制更改。

为此，本发明自主设计了一个具备不同视频格式适应性初始队列长度的阻塞队列作为数据实时缓存装置，并采用采集、解析、播放多线程并发的高效形式。阻塞队列缓存数据解决了三个线程之间速率匹配问题，通过该装置实现了在软件方面的IP视频流实时解析与监测。本发明自主设计的队列长度设计算法根据不同的视频格式，如清晰度，扫描格式等来得到具备不同的初始队列长度的阻塞队列，具备很强视频格式的适应性。该算法适应于高清、超高清等不同清晰度的视频格式，但在超高清格式中只有逐行扫描格式。通过将视频数据流捕获和视频数据处理分别准确接入该阻塞队列的输入输出端，紧密配合视频监测与显示，来实现IP化视频流的解析与播放，保证实时视频播放的质量。

在视频流数据处理解析层面，本发明在遵从ST 2022-6和ST 2110-20标准的基础上，通过自主研发的程序设计解封装协议头，获取协议头中的视频信息，判断、筛选、排列视频数据中有效的视频帧像素信息，进行视频帧图像信息的拼接，最后将一帧帧视频信息传入播放器。

衡量超高清IP化视频采集解析及监测系统的性能，我们可基于数据完整性、传输稳定性以及实时性三个方面提出以下5个指标，分别是丢帧率、丢包率、帧间隔分布(帧间抖动)/包间隔抖动、首包处理时延、端到端时延。由本发明自主设计的阻塞队列和队列长度设计算法的加入在实现实时效果的同时，也使丢帧率、丢包率、端到端时延大幅度改善。

以下为本发明的各项操作实施方法及原理：

一、视频数据流捕获

高效监听网络中的数据包是解析数据的第一步，我们利用WinPcap 这种捕获网络流量、进行网络分析的体系结构，在Windows系统下截获底层数据包并完成过滤。

(1)首先，我们确定即将嗅探的目标接口，利用文件句柄对不同接口加以标识，以区别各个不同的嗅探任务。

(2)接着，新创建一个嗅探任务，将目标网卡设备的文件句柄赋值给变量，同时设定所需捕获的数据最大字节数。除非出现错误，否则该嗅探任务将一直执行下去，而对于错误也应利用errbuf字符串进行保存，方便我们定位分析问题。

(3)其次，对流量进行过滤。一般情况下，嗅探任务只对特定的流量进行捕获，这时就可以使用过滤器。虽然足够多的if/else条件语句罗列也可以达到相同的效果，过滤器仍旧是最佳选择，原因是WinPcap的过滤器直接调用BPF过滤器，非常高效；另外BPF驱动可以直接进行很多操作。

(4)一次抓取一个包，每嗅探到一个数据包就调用回调函数对数据包进行相应的处理及存储。

二、数据存储

为方便多线程间的数据通信，利用阻塞队列进行数据的中间存储。阻塞队列的特性是：当队列已满时会等待队列中的数据消耗，当队列为空时则等待数据填充。通过一个共享的阻塞队列，固定队列的数据出入口，数据由入口进入、出口处被取出，同时采用先进先出(FIFO)模式，保证队列中的数据被取出时的顺序与进入时的顺序是一致的。在多线程编程环境中，阻塞队列是一种非常高效的实现线程通信的方式。另外，阻塞队列也可以解决某个时间段内产生数据的线程与消耗数据的线程之间速度不匹配的问题。如果数据产生的速度大于被消耗的速度，并且持续了一段时间，使得累积的数据大小超过了阻塞队列的长度，那么产生数据的线程将会进入休眠，以等待数据消耗线程处理累积的数据；与之相对地，如果数据被消耗的速度大于产生的速度，使得阻塞队列中已经没有累积的数据了，则消耗数据的线程将会进入休眠，等待数据的生产。

三、队列长度设计算法

衡量超高清IP化视频采集解析及监测系统的性能中的丢帧率、丢包率、端到端时延的大小和阻塞队列长度密切相关。队列越长，帧均丢包率、丢帧率越小，时延越大；队列越短，帧均丢包率、丢帧率越大，时延越小。因此，对于丢包敏感而实时性不敏感时可采用队列无限存储方案，该方案相比实时写读PCAP文件数据共享方案(即将视频流数据存储在本地PCAP文件，而非在阻塞队列缓存)可得到零丢帧率和零丢包率；对于丢包不敏感而实时性要求较高时，应采用队列有限存储方案，该方案相比实时写读PCAP文件数据共享方案可得到更低的端到端时延。

针对队列有限存储的长度方案，本发明自主设计一种算法，根据不同视频流格式在网络条件下的输入输出速率与变化，设计相应的队列长度，来得到低丢包率和低时延。

需再强调的是该算法适应于高清、超高清等不同清晰度的视频格式，但在超高清格式中只有逐行扫描格式。

阻塞队列的输入速率λ是指每秒采集经网络传输后到达队列的视频数据包的速率，可由计算机直接根据一段时间内接收的数据包个数n除以相应时间t得到；输出速率μ是指视频播放时每秒解析播放数据包的速率，可由视频播放的帧频(F)*每帧的数据包数得到。每帧的数据包数计算分两种情况：第一种情况，由ST 2022-6标准封装的视频(包含逐行扫描和隔行扫描)和由ST 2110-20标准封装的逐行扫描视频每帧的数据包数等于两个连续帧中具备标志位M的数据包序列号Seq_num2和 Seq_num1的差值。其中标志位M在代表这一个数据包为这一帧的最后一个数据包。第二种情况，由ST 2110-20标准封装的隔行扫描视频中标志位M表示一场的最后一个数据包，因此该隔行扫描的一帧数据包数需要一场的数据包数再乘2，其中超高清格式的视频没有隔行扫描格式。我们设计的监测计算机性能足够高，视频流进入程序后的解析播放是稳定的，即队列的输出速率是稳定的。视频流的采集速率是恒定的，但是在 IP网络传输过程中，存在网络抖动等因素的影响，因此队列的输入速率是变化的，长期稳态条件下小于或等于输出速率。在实际网络情况中，网络状态变化复杂，需根据队列长度算法自适应调整队列长度，来保证良好的丢包率和时延。

当输入速率小于输出速率时，队列长度L1等于视频流输出速率μ减去输入速率λ后，乘实时视频时长duration：

L1＝(μ-λ)*duration (1)

第一种情况：

L1_first＝[(Seq_num2-Seq_num1)*F-n/t]*duration (2)

第二种情况：

L1_second＝[(Seq_num2-Seq_num1)*F*2-n/t]*duration (3)

当输入速率约等于输出速率时，队列长度L2等于输入抖动 input_jitter,加初始解析播放延迟delay_len。在PTP同步前提下，网络的输入抖动可由数据包中携带的RTP时间戳与接收到包的实际时间差表示。网络的输入抖动是指分组延迟的变化程度，变化具备随机性，因此本算法采用一种最大抖动时延处理，具体实现为通过对到达数据包的时间间隔抖动测量和预测获得最大抖动队列长度input_jitter。或将一段时间的视频数据历史输入拟合多种数学模型，求出拟合度最高的到达数学模型，求出最大抖动队列长度input_jitter。初始解析播放延迟是指在视频流到来时，为防止网络抖动，先缓存一部分数据所需要的队列长度，再进行视频解析播放，以保障视频的输出流畅。在本算法中，初始解析播放延迟大小根据网络抖动和播放实时性需求而优化设计，一个基本方法是初始解析播放延迟设计为缓存相应视频格式的一帧数据包的队列长度 delay_len，即为两个连续帧中具备标志位M的数据包序列号Seq_num2 和Seq_num1的差值(ST 2110-20封装的隔行扫描视频时需*2，超高清不包括隔行扫描)，这样基本保证了播放过程中队列不会出现清空的状态。

L2＝input_jitter+delay_len (4)

第一种情况：

L2_first＝input_jitter+(Seq_num2-Seq_num1) (5)

第二种情况：

L2_second＝input_jitter+(Seq_num2-Seq_num1)*2 (6)

伪代码如下：

四、数据处理

以3G-SDI的源数据是由两个10bit并行数据流组成的虚拟接口为例说明SDI数据格式。虚拟接口符合SMPTE 425M标准。虚拟接口将数据流1、2的每一行的数据分为四个区域:EAV(有效视频结束)时钟参考、数字消隐区、SAV(有效视频开始)时钟参考、数字有效行，格式如图1 所示。EAV与SAV两种均属于时钟参考信号(TRS)。视频每帧起始行的TRS及其后表示行号的数据取值固定不变的，因此可以用来搜寻一帧图像的起始点数据包。

在应用了多路复用，并行到串行转换和加扰之后，虚拟接口的两个并行数据流以位串行形式在单个通道上传输。虚拟接口的数据流1和数据流2应按以下顺序逐字多路复用为单个10位并行流：数据流2、数据流 1、数据流2以此类推，如图2所示，其中图像对应像素的亮度和色度顺序为Cb0、Y0、Cr0、Y1、Cb1、Y2……。

从以太网中捕获的数据包根据SMPTE ST 2022-6标准或ST 2110系列标准封装而成，从外到内包装的次序依次为：以太网、IP、UDP、RTP、最内部为无压缩的视频数据、音频和辅助数据。其中ST 2022-6标准中最内层封装的为上述描述的SDI数据格式，即HBRMT(高比特率媒体传输协议)，而在ST 2110系列标准中视频、音频、辅助数据根据相应的标准单独封装传输。比如在ST 2110-20标准最内层数据仅封装视频内容，即SDI数据格式中的数字有效行内容。

在获取数据包后，根据SMPTE ST2022-6标准(或ST2110系列标准)，验证数据包格式是否符合标准规定，用数据包对应位置数值赋值结构体内各个字段及数组，完成视频数据参数的传递，包括视频宽高、帧率、色度采样、隔行/逐行参数的传递，根据宽高并新建相应字节大小的图像缓存区。在ST 2022-6标准中，通过对SDI数据格式中TRS的判断得到图像起始行的数据包，进而读取属于同一帧的数据包。然后根据SAV中的数字消隐信息封装格式，来剥除辅助数据、音频数据、其他数据，仅剩数字有效行的图像数据。在ST 2110-20标准中，可直接根据图6RTP 有效载荷标头的封装标准，通过长度、行数、偏移量的判断来获取视频帧的首包及同一帧的所有数据包。接着通过相邻字节拼接恢复出原始取样像素值元组，再结合计算机显示图像的特性，将原始元组像素数据进行处理，以方便图像显示。最后将图像对应像素的Y、Cb、Cr亮度色度进行赋值，直到图像缓存区完全被填满，我们便得到了一帧完整图像。重复数据处理过程，不断更新图像缓存区内的图像。

五、视频监测与显示

我们的监测系统装置中采用SDL(Simple DirectMedia Layer)，SDL是一套由C语言写成的开源跨平台多媒体开发库，它提供了丰富的控制图像、声音、输入输出的函数。其他函数库特别是支持10比特以上HDR 的函数库可用于视频监测显示。

SDL显示视频的流程主要可以分成两大部分：初始化和循环显示画面。初始化的流程又可以细分为初始化SDL、创建窗口(Window)、基于窗口创建渲染器(Render)、创建纹理(Texture)四个大步骤。循环显示画面包括设置纹理的数据、纹理复制给渲染目标、显示。

SDL初始化需要使用SDL_Init()函数，用来确定希望激活的子系统，可以选择定时器、音频、视频、摇杆、触摸屏、游戏控制器、事件或者全部子系统。利用SDL_CreateWindow函数创建一个视频播放的窗口 (Window)，指定窗口标题、窗口位置坐标、宽高。使用SDL_CreateRender() 函数基于窗口创建渲染器，参数需指定所渲染的目标窗口、用于初始化的渲染设备、硬件/软件渲染和同步显示器刷新率。如果创建成功，则会返回渲染器的ID。接着需要使用SDL_CreateTexture基于渲染器创建一个纹理，需要指明纹理的格式，每种格式包括以下属性：像素分量的存储方式，各像素分量是一起存储还是分开存储；像素分量的存储顺序，即大端小端的问题，对于Windows这样的小端系统，“ARGB”格式在内存中的存储顺序依次是B、G、R、A；每个分量占据的比特数；每个像素占据的比特数和字节数。使用SDL_UpdateTexture()设置纹理的像素数据，SDL_RenderCopy()将纹理数据复制给渲染目标，视频播放时后一帧会完全覆盖前一帧，最后用SDL_RenderPresent()显示画面。

附图说明：

图1：并行数据流格式

图2：10bit串行数据流

图3：系统物理拓扑及数据逻辑图方案

图4：视频显示画面

图5：RTP有效载荷标头(SMPTE ST2022-6)

图6：RTP有效载荷标头(SMPTE ST2110-20)

图7:一帧由2022-6标准封装视频的帧尾数据包

图8:丢帧率三个方案对比

图9：帧内丢包率三个方案对比

图10：端到端时延三个方案对比

具体实施方式：

下面结合附图，对IP基带视频流解析监测方法与装置进一步说明细节。

一、实验系统物理拓扑

一套完整的IP化视频流采集解析系统由三部分组成：视频信号源(IP化网关)、传输交换网络以及信号采集解析终端。

实验系统物理拓扑的搭建如图3所示的物理拓扑。本实验拓扑中应用到的设备主要包括：高清摄像机(SDI格式输出)、SMPTE 2022-6/ST 2110网关、Intel 82599ES万兆网卡、以及通用计算机。

摄像机通过SDI同轴电缆实时输出拍摄的高清视频画面，并与IP网关相连接。IP网关根据SMPTE ST 2022-6/ST 2110标准规范，对接收到的信号进行包分割、添加协议头等封装处理，从而变为能够在包交换网络中传输的IP流信号。结合其他交换机及路由节点，未压缩的基带视频便可以在十分庞大的网络中灵活传播，从而突破传统同轴电缆传输布线复杂、单流传输等限制。IP网关通过万兆网口输出，光纤传输，与终端万兆网卡网口相连接，从而使数据包能够被我们所捕获。

二、实验框架

本产品的实验设计，在充分分析SMPTE ST 2022-6/ST 2110标准等IP 化协议规范的基础上，通过10G(万兆)网卡和WinPcap实现IP化视频信号采集，于VS2015开发环境下完成IP信号解析及视频显示，以低成本实现市面上昂贵的商业现成品硬件终端功能，数据处理可控。

为更加清晰地体现本发明IP基带视频流解析监测方法与装置的优越性，在实验框架方面，本部分介绍两个实现实时视频的解析与播放实验框架，分别是通过实时写读PCAP文件数据共享的初始方案与我们自主设计研发的阻塞队列数据共享改进方案。

本说明书视频内容以高清标准1920*1080 60i、帧频30Hz、4:2:2采样结构、10bit取样，ST 2022-6封装标准为例，每个以太网数据包大小为1442字节。当视频为4K/8K超高清格式时对装置硬件性能要求会更高，但是监测方法可以相同。

1.监测方案

如图3所示，系统终端的采集与解析功能从逻辑上可以分为3个并行任务，结合实际应用考虑，我们选择多线程并发的形式实现线程1为采集线程，线程2和线程3分别负责数据解析与视频播放，下面详细介绍每个线程内的处理。

线程1利用WinPcap嗅探网卡捕获数据包，首先创建一个网络设备链表以获取本机的适配器，并得到适配器的详细信息(包括名称、掩码、源/目的地址、广播地址)，从命令行键入万兆网卡适配器所属的编号，打开该适配器并开始捕获数据。指定捕获长度为65535(大于最大MTU)，以保证得到完整包，设置混杂模式确保没有遗漏的数据包。使用PCAP_loop函数以及回调函数持续不断地捕获数据包，在初始方案中，打开一个本地磁盘中的堆文件(若路径原先不存在则会新建一个堆文件)，通过PCAP_dump函数将每次捕获到的数据包写入指定的堆文件中保存，格式为PCAP文件。至此线程1便完成了实时采集数据并将其存储至文件的使命。PCAP文件由文件头、数据包头、数据包、数据包头、数据包、数据包头、数据包……组成。PCAP文件只有一个文件头，文件头包含7个字段，数据包头包含4个字段，而实际网络中传输的数据则位于数据包头后的数据包中,在实际解析中，解析多余的数据包头需耗费时间。各数据包单独写入PCAP文件时，每秒钟就要写入数十万个数据包。写入磁盘本身便是一个比较耗时的操作，而多次写入少量数据又比一次写入大量数据所需时间更长，因此初始方案系统的整体数据处理耗时相当大。在我们自主设计研发的改进方案中，对于实时监测，用PCAP_setbuffer和 PCAP_setuserbuffer函数分别调整内核缓存区和用户缓存区的大小，均设置为 10MB，通过扩大缓存区以解决抓包时丢包漏包的问题。并用阻塞队列存取数据来代替文件读写实现线程间通信，减少了数据写入磁盘和解析数据包头的时间，大大提升了数据读写的速度，提高了数据共享的便利性。

由于线程1与线程2、3速度不匹配，作为缓存的阻塞队列的长度控制在此处也是十分重要的变量。我们将长度分别设置为无限长和能够根据不同视频格式适应性的队列长度两种，并通过实验验证其效果上的区别。

本例中2022-6标准封装的高清视频格式为60i，帧频30Hz，以此为示例来描述阻塞队列长度的计算方法。

1)当输入速率小于输出速率时，有限队列长度计算公式为：

L＝[(Seq_num2-Seq_num1)*F-n/t]*duration

为方便观察理解，使用wireshark抓取实时IP视频数据包来进行队列长度的计算。如图7所示的抓包数据已通过过滤，只显示标志位Mark为True的数据包。图7中两个相邻具有标志位M的数据包中间的所有数据包和第二个具有标志位M的数据包组成一帧的数据包(不包括图7中第一个具有标志位的数据包，它为上一帧的最后一个数据包)，一帧所有数据包数等于Seq差值：Seq_num2-Seq_num1＝4691-194＝4497。

输入速率可以由图7中绿色框内的首末数据包的序列号和时间戳两列得出：(159902-146411)/(1.254768-1.154743)＝134876。在实际中，应取更多的数据包，求取输入速率的平均值。

设定视频时长为10分钟，即600s，所以本例视频队列长度的实际值为： [4497*30-134876]*600＝20400个数据包。

2)当输入速率约等于输出速率时，有限队列长度的计算公式为：

L＝input_jitter+(Seq_num2-Seq_num1)

因网络抖动的数学模型众多，在此不进行具体的模型计算，而是提前采取观察统计的方法获取最大抖动队列实际长度input_jitter。首先将队列长度设置为无限长，通过观察队列里缓存数据包个数的变化，记录数据包个数最大值，并去除个别突发流量，该值即为input_jitter，假设大小为20000(仅为示例，实际值应根据实际情况获得)。视频帧的大小由图7中两个相邻数据包 Seq_num差值可得：(Seq_num2-Seq_num1)＝(4691-194)＝4497

故本例视频的队列长度为：20000+4497＝24497

线程2在完成各数据结构的初始化后，便以只读的方式打开缓存队列或存储捕获数据的PCAP文件，读取第一个数据包头，并读取数据包头后长度为caplen的数据，这便得到了第一个数据包的数据。根据SMPTE ST2022-6/ST2110标准，验证数据包格式是否符合标准规定，用数据包对应位置数值赋值结构体内各个字段及数组，并完成视频的宽高、帧率、色度采样、隔行/逐行参数的传递，参数所在的字段如图5图6所示。按照视频数据的分辨率和色度取样，新建一个大小为1920*1080*2字节的图像缓存区。接着继续从文件中读取第二个数据包头及数据包，根据数据包内层的SDI载荷数据格式，获取时钟参考信号(TRS)来搜寻一帧图像的起始点数据包。根据TRS 判断第二个包是否为图像起始行，如若不是，则继续读取文件，直至匹配上为止。当图像起始行所在数据包确定以后，依次读取属于同一帧图像数量的数据包，通过相邻字节拼接恢复出10bit的原始取样像素值元组，再结合 SDL显示图像的特性对像素值数据进行处理，以方便图像显示。最后将图像对应像素的Y、Cb、Cr亮度色度进行赋值，直到图像缓存区完全被填满，我们便得到了一帧完整图像。重复这个过程，不断更新图像缓存区内的图像。

线程3调用SDL多媒体开发库，按照次序先后创建SDL窗口、渲染器、纹理，之后从线程2处获取图像缓存区内存储的完整帧数据作为纹理参数调用，图像缓存区以帧为单位更新的同时纹理也会得到更新，通过渲染器的渲染，原始视频的显示效果就得此实现。视频显示画面播放流畅，没有卡顿，如图4所示。

2.实验效果对比

本部分我们将从丢帧率、帧内丢包率、端到端时延这3个指标来测量监测IP视频流解析系统的性能。通过初始方案、队列无限存储方案、队列有限存储方案(在此队列长度以设置为能够存储5帧视频数据包长度 (4497*5＝22485个数据包)为例)三个方案的对比，来体现我们自主研发改进方案的优越性。

1.丢帧率

图5为由ST 2022-6协议封装的RTP有效载荷标头中的字段内容，其中 FRcount表示视频帧计数器的值，计数器数值应在视频帧尾数据包M标志位为1后的下一个数据包增加1，并在256帧后翻转重新计数。通过捕获和解析前后视频帧尾数据包FRcount的数据差值来计算丢帧数、总帧数，从而得到丢帧率。

图8为3个方案的效果对比，初始方案与队列有限存储方案效果接近，丢帧率平均在6％左右；而队列无限存储方案在20次实验测试中丢帧率均为0，对比初始方案效果提升明显。

2.帧内丢包率

RTP标头中的字段sequence number表示低16位的RTP序列计数器，当发送节点每次以相同功率发送一个RTP数据包后，序列号应加1，以此表示总共发送的RTP数据包数。通过一帧捕获和解析前后数据包sequence number的数据差值来计算丢包数、总包数，从而得到丢包率。

图9为3个方案的效果对比，初始方案与队列有限存储方案效果接近，帧均丢包率约5.5％；而队列无限存储方案在20次实验测试中帧均丢包率均为0，对比初始方案效果有明显提升。

3.端到端时延

首先通过PTP达到网络的同步，然后通过视频数据源端与视频播放端二者之间的实时时间差，得到端到端时延。

图10为3个方案的效果对比，初始方案的端到端时延均值为12525ms；队列无限存储方案端到端时延均值为11500ms，对比初始方案效果略有提升；而队列有限存储方案端到端时延均值为463ms，对比初始方案效果大幅提升。

从各个指标的对比中发现，队列无限存储方案在丢帧率、帧均丢包率、首包处理时延指标方面远远优于初始方案，但在端到端时延指标和初始方案差不多但明显劣于队列有限存储方案。因此，对于丢包敏感而实时性不敏感时可以采用队列无限存储方案。

实验中队列有限存储方案在丢帧率与帧均丢包率指标上与初始方案表现基本一致，而端到端时延效果要显著优于初始方案和队列无限存储方案。本实验的队列有限存储方案是以设置为能够存储5帧视频数据包长度为例。当我们采用队列长度优化算法调整队列长度可以降低丢帧率与帧均丢包率，略微延长端到端时延，最终得到低丢包率和低时延，体现我们自主研发改进方案的优越性。