一种保证初始数据完整性的实时视频流分发插件①

张凯

(苏州科达科技股份有限公司 上海研发中心,上海 201103)

一种保证初始数据完整性的实时视频流分发插件①

张凯

(苏州科达科技股份有限公司 上海研发中心,上海 201103)

在视频监控联网系统中进行实时监控时,如果监控客户端收到的初始视频数据不完整会出现初始播放画面花屏的问题.基于开源多媒体框架GStreamer,针对H.264编码标准,设计并实现了一种实时视频流分发插件.该插件使用随机创建的请求型source衬垫用于视频数据的分发,并通过缓存当前IDR帧组的方法确保发送初始视频数据的完整性.该插件可应用于流媒体服务器当中,解决实时监控时初始画面花屏的问题.实验结果表明,应用该插件的流媒体服务器能够高效分发实时视频数据并保证初始播放画面完整,对提升实时监控效果有着明显的作用.

视频监控;流媒体服务器;GStreamer框架;H.264标准;IDR帧;RTP协议

视频监控联网系统中使用IPC(IP Camera网络摄像机)作为监控前端采集实时视频流,通过流媒体服务器分发到多个监控客户端(以下简称客户端)进行实时视频监控.流媒体服务器的这种工作模式呈现“一进多出”的拓扑形态.

高清视频编码标准(如H.264[1])使用帧间图像数据压缩技术.由于实时视频流访问的随机性,客户端获取到的初始视频帧(第一个视频帧)可能需要参考之前的帧进行解码,这会导致客户端由于接收的初始视频数据不完整出现初始播放画面花屏现象,影响了实时监控效果.

为解决这一问题,需要在视频流分发侧保证发送到客户端的每一路视频流的初始视频数据是完整的.

在视频流分发侧使用缓存数据保证所发送数据完整性是目前业内常用方式.内容分发网络 CDN (Content Delivery Network)是使用数据缓存方式的代表[2].在CDN中,使用缓存代理服务器缓存流媒体服务器的内容,客户端从缓存代理服务器上获取流媒体内容.

CDN在提升流媒体服务响应速度,媒体流分发容量的同时,也对网络传输服务质量提出了很高的要求.在CDN中传输实时视频流时,缓存代理服务器和流媒体服务器之间需要实时同步缓存数据.若缓存代理服务器和流媒体服务器之间的网络质量不佳,实时监控效果会受到较大影响.

本文提出了在流媒体服务器上通过实时视频流分发插件缓存当前视频数据以保证初始视频数据完整性的方法,针对H.264编码标准,基于GStreamer框架[3,4]设计并实现了一个应用于流媒体服务器中的实时视频流分发插件.相比较CDN而言,本文描述的流媒体服务器不需要缓存代理服务器就能通过分发插件保证所分发初始视频数据的完整性,不再产生流媒体服务器与缓存代理服务器之间的通讯开销.

本文描述了分发插件的设计与实现方法并给出相关实验结果.

1 相关定义

1.1 GStreamer中相关定义

GStreamer框架基于插件(plugins).GStreamer中的插件是一段可以加载的代码,常常以动态链接库的形式存在.一个GStreamer插件中可包含一个或多个元件(Element)[5].

元件是GStreamer中最重要的概念,见定义1.

定义1.元件:GStreamer中,元件是构建一个媒体管道的基本块,GStreamer中的元件都继承自GstElement对象.

多媒体应用程序可以创建若干个元件(elements)连接在一起,从而构成一个管道(pipeline)来完成一个媒体处理任务.GStreamer中的管道见定义2.

定义2.管道:管道是一种容器元件,可以向管道中添加元件从而将一组存在链接的元件组合成一个大的逻辑元件.管道可以操作包含在其自身内部的所有元件.

管道中的元件需要建立链接关系,衬垫(Pads)在GStreamer中被用于元件之间的链接,从而让数据流能在管道中流动.衬垫的定义见定义3.

定义3.衬垫:衬垫是元件之间的接口,元件之间的数据交互依靠衬垫来完成.衬垫能够限制数据流的通过,只有两个元件链接在一起的衬垫允许通过的数据类型一致时,这两个元件才可交换数据.

一个衬垫很像一个物理设备上的接口,如电视机上的HDMI输入接口和机顶盒上的HDMI输出接口.正因为电视机和机顶盒都有相同类型的接口,才可以使用数据线连接起来完成媒体流的播放.

根据数据流向,衬垫被分为两种类型:source衬垫与sink衬垫.数据向元件之外流出可以通过一个或多个source衬垫,元件接受数据通过一个或多个sink衬垫来完成.在一个管道中,数据流从一个元件的source衬垫流到另一个元件的sink衬垫.

根据生命周期,衬垫分为永久型(always)、随机型(sometimes)、请求型(request)三种类型.永久型衬垫在元件创建时就存在,并一直存在直到所属元件销毁.随机型衬垫在某种特定条件触发后才创建并存在.请求型衬垫只在应用程序明确发出请求时才创建并存在.

使用元件,管道和衬垫这些GStreamer基本元素可以构建丰富的多媒体应用程序.

1.2 IDR帧组

视频编码中,每一个图像帧代表一幅静止的图像.实际压缩时,会采取各种算法减少数据的容量[6].

I帧表示关键帧,可理解为这一帧画面的完整保留,解码时只需要本帧数据就可以完成.P帧表示的是这一帧跟之前一个关键帧(或P帧)的差别,解码时需要用之前缓存的关键帧(或P帧)叠加上本帧定义的差别,生成最终画面.B帧是双向差别帧,B帧记录本帧与前后帧的差别.要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面与本帧数据的叠加获得最终画面.

在H.264编码中,I帧不用参考任何帧,但是之后的P帧和B帧有可能参考这个I帧之前的帧.为区分首个I帧和其他I帧,把首个I帧称为IDR(Instantaneous Decoding Refresh即时解码刷新)帧[1].由IDR帧开始,重新开始编解码一个新的帧序列.IDR帧之后的所有帧都不会引用该IDR帧之前帧的内容.由此可知,IDR帧阻断了误差的积累,提供了随机访问性,播放器可以从视频流中任意一个IDR帧播放而不会导致花屏.

考察帧序列(下标表示帧的显示顺序):I1P4B2B3P7B5B6I8P11B9B10P14B11B12.这里I1和I8就是IDR帧,因为其之后的帧不需要跨过该帧去参考之前的帧.

定义4定义了IDR帧组的概念.

定义4 IDR帧组 视频流中一个IDR帧和其之后,下一个IDR帧之前的帧组成的集合称为IDR帧组.

参考帧序列:I1P4B2B3P7B5B6I8P11B9B10P14B11B12.{I1,P4,B2,B3},{I1,P4,B2,B3,P7,B5,B6},{I8, P11,B9,B10}都可被称为IDR帧组.

2 基于GStreamer的流媒体服务器架构

流媒体服务器是视频监控联网系统的核心部分.流媒体服务器获取所请求IPC的实时视频流,并将这一路视频流分发到各个请求的客户端[2].

基于GStreamer框架,仅用于实时视频浏览的流媒体服务器架构如图1所示.本文约定IPC生成的视频流格式为H.264编码格式,客户端与流媒体服务器之间,流媒体服务器与IPC之间都使用RTSP[7]作为控制协议,使用RTP[8]作为视频数据传输协议.为方便描述,本文约定一个IPC只提供一路实时视频流,并使用ES流(Elementary Stream,基本流)传输.

图1 基于GStreamer框架的流媒体服务器架构

图1 的流媒体服务器中,clientproxy元件接收来自客户端的实时浏览请求建立RTSP会话,并对RTSP会话中所请求的IPC建立对应的数据分发管道.该数据分发管道为定义2所定义的GStreamer管道,包含一个ipcsrc元件,一个 streamdispatcher元件和若干个clientsink元件.Clientsink元件是随机产生的,每建立一个对该IPC请求的RTSP会话,clientproxy元件就在该数据分发管道中创建一个clientsink元件与其对应.

数据分发管道中的ipcsrc元件使用RTSP协议向所请求IPC获取实时视频流,获取的实时视频流使用RTP协议由IPC发送到ipcsrc元件.Ipcsrc元件收到承载实时视频流的RTP包后,传递到streamdispatcher元件进行分发.Streamdispatcher元件将收到的RTP包分别传递给管道中每个clientsink元件.

管道中每个clientsink元件包含了其对应RTSP会话的会话参数(传输协议,地址端口等信息),clientsink元件将streamdispatcher元件分发的RTP包根据会话参数发送到客户端.

以图1为例,clientproxy元件收到客户端1对IPC1的实时视频流会话请求后建立RTSP会话1,并建立名为管道1的数据分发管道.管道1中包含一个ipcsrc元件ipcsrc1,一个streamdispatcher元件streamdispatcher1和一个clientsink元件clientsink1(包含RTSP会话1的会话参数).ipcsrc1使用RTSP协议向IPC1请求实时视频流后,承载视频流的 RTP包经“ipcsrc1→streamdispatcher1→clientsink1”的路径传递后发送到客户端1.此后若clientproxy元件又建立客户端2对IPC1请求的RTSP会话2,则在管道1中再创建clientsink元件clientsink2(包含RTSP会话2的会话参数),承载视频流的 RTP包经“ipcsrc1→streamdispatcher1→clientsink2”的路径传递后发送到客户端2.

图1中管道的生命周期依赖于请求其对应IPC的客户端RTSP会话数目:当会话数目大于0时,管道被创建clientproxy元件;当会话数目等于0时,管道被clientproxy元件销毁.

streamdispatcher元件是数据分发管道中的分发控制中枢,不仅将数据分发给clientsink元件,还保证发送 给 clientsink 元 件 的 初 始 帧 为 IDR 帧 . streamdispatcher元件的设计与实现是本文的重点,下一节将详细介绍streamdispatcher元件的设计与实现.

3 实时视频流分发插件设计与实现

3.1 设计思想

将IPC发送的实时视频流视为一个帧序列.为确保发送到客户端的初始帧为IDR帧,streamdispatcher元件需缓存当前帧参考的IDR帧组(当前帧参考的IDR帧及当前帧与IDR帧之间的其它帧).Streamdispatcher元件在分发数据时总是先发送缓存的当前IDR帧组,再发送当前帧.这种工作方式可由图2示意.

图2中t1时刻,请求IPC实时视频流的RTSP会话1建立,与之对应的 clientsink元件也随之创建. streamdispatcher元件此时收到IPC发送的当前帧为SLICE1m(非IDR帧,且IDR1与SLICE1m之间无IDR帧).因为在t1时刻之前,streamdispatcher元件中已经缓存了IDR1及IDR1至SLICE1m之间所有帧的IDR帧组,所以在t1时刻streamdispatcher元件首先发送缓存的IDR帧组,再发送SLICE1m帧给对应RTSP会话1的clientsink元件.对应RTSP会话1的clientsink元件收到初始帧为IDR1.同理在t2时刻,streamdispatcher元件中缓存的是IDR2及IDR2至SLICE2n之间(IDR2与SLICE2n之间无IDR帧)所有帧的IDR帧组,对应RTSP会话2的clientsink元件收到的初始帧为IDR2.

图2 streamdispatcher元件工作原理

Clientproxy元件建立RTSP会话时会创建对应的clientsink元件,然后向streamdispatcher元件申请创建一个请求型source衬垫,并将此衬垫与clientsink元件的sink衬垫进行链接.当streamdispatcher元件在接收视频流数据后,通过已创建的请求型source衬垫将数据推送到 clientsink元件.Ipcsrc、clientproxy和clientsink之间的衬垫链接关系如图3所示.

图3 管道中元件的衬垫链接关系

3.2 IDR帧识别方法

ES流中,IPC将H.264视频编码后的NALU (Network Abstract Layer Unit)封装在RTP包中.NALU的首字节定义如图4所示.

图4 NALU的首字节定义

其中F为1个比特,在规范中规定为0.NRI为2个比特,用于表示NALU的优先级.Type为5个比特,表示NALU的类型.若NALU类型为5,则表示该NALU为IDR图像,其对应的帧为IDR帧.

RTP在对NALU封包时,会使用单一NAL单元模式,组合封包模式,分片封包模式这三种模式中的一种.在实际运行中,应根据视频流的封包模式判断RTP载荷的NALU类型是否为IDR帧类型.

以分片封包模式为例,若RTP包载荷的首字节中Type为28,表示为FU-A类型的分片单元.此时应判断该RTP包是否为第一个分片单元,若为第一个分片单元,再对FU头字节(载荷的第二个字节)的后5个比特判断NALU类型.只有包含第一个分片单元且FU头字节中类型为5的RTP包才被判断为IDR帧类型.

3.3 视频流分发算法

如图3所示,管道中每一个clientsink元件创建时, streamdispatcher元件也会创建一个请求型source衬垫与该clientsink元件链接,承载实时视频流的RTP包经该source衬垫传递到与其连接的clientsink元件.创建请求型source衬垫的过程如算法1所示.

当承载实时视频流的RTP包从streamdispatcher元件的sink衬垫流入时,streamdispatcher元件将流入的RTP包分发到使用算法1创建的source衬垫中,同时缓存当前帧的IDR帧组数据.这个过程使用算法2描述.算法2在streamdispatcher元件每接收到一个RTP数据包时都会被调用一次.

算法1中padContext为srcPad的上下文对象,包含两个成员变量:sessionid和initialized.sessionid为整型,用于存放所创建衬垫对应的 RTSP会话 ID. initialized为布尔型,表示该衬垫是否已经接收到了初始IDR帧,初始值为FALSE.算法1的第6行表示srcPad设置上下文对象.

streamdispatcher元件使用列表变量srcPadList存放所有被请求创建的source衬垫,并用index变量记录索引.算法1的第7行表示新创建的srcPad被加入到srcPadList列表中.

算法2中,idrGroupList是streamdispatcher元件用于缓存当前IDR帧组的列表变量,在streamdispatcher元件初始化时创建且设初始值为空.rtpPkg是来自sink衬垫由IPC发送的RTP数据包,被parseFrameType函数用来判断载荷中NALU类型是否为IDR帧类型 (判断方法参考3.2节,本文中只考虑单一NAL单元模式和分片封包模式).

算法2的第1至14行描述了向每个已创建source衬垫(包含在srcPadList中)推送数据的过程.算法2先根据每个source衬垫的上下文信息了解该衬垫是否已经接收过初始IDR帧:如果该衬垫还未接收过初始帧:在缓存当前IDR帧组的idrGroupList不为空且当前NALU类型不为 IDR帧类型的条件下,先推送idrGroupList,再推送rtpPkg到该衬垫,并将上下文中的初始帧接收标示置为TRUE;如果该衬垫已经接收过初始IDR帧:只需要将当前rtpPkg数据推送至该衬垫即可.

向source衬垫推送数据后,需要判断当前rtpPkg是否需要加入到idrGroupList中,算法2的第15至25行描述了这一个过程.如果当前rtpPkg的NALU类型为IDR帧类型则表示idrGroupList已缓存的IDR帧组不再成为当前IDR帧组,这时算法2清空idrGroupList后添加当前rtpPkg到idrGroupList中.

算法2利用缓存的当前IDR帧组保证了发送到各source衬垫的初始帧为IDR帧.

4 实验结果

应用第2节介绍的架构,基于GStreamer 1.6版本开发了一个简单的流媒体服务器,仅实现实时浏览IPC的功能.其中clientproxy元件和streamdispatcher元件都实现为独立插件,ipcsrc元件和clientsink元件实现在一个插件当中.基于GStreamer 1.6版本自带的rtspsrc,decodebin,autovideosink等插件开发了流媒体服务器的实时浏览客户端,可用于实时浏览IPC监控的视频流.

服务器与IPC之间,客户端与服务器之间都通过RTSP协议建立媒体会话并且使用RTP协议进行视频流传输.实验使用一个IPC作为视频监控前端,客户端建立多个RTSP会话来测试streamdispatcher插件的分发效率.IPC视频流为ES流,使用H.264编码,分辨率为704×400,帧率为25fps,平均每3秒发送一个IDR帧.

实验所使用服务器为PC机,操作系统为windows 7,CPU为英特尔酷睿双核处理器(2.5GHZ),内存为4GB.实验中针对不同的RTSP会话数目重点考察了streamdispatcher插件分发一个RTP包(执行一次算法2)的时间,并和不使用streamdispatcher插件直接分发RTP包的时间做了比较.实验结果如图5所示.

图5 RTP包分发消耗时间及比较

图5 中的消耗时间是分发一个RTP包到所有clientsink插件所消耗的时间(采集头1000个RTP包的分发时间作为样本,计算出平均时间).每个clientsink插件对应一个RTSP会话,随着会话数目的增加,分发时间也随之增加.分发时间随会话连接数目线性增加,这与算法2的逻辑拟合.

图5对使用streamdispatcher插件分发和不使用streamdispatcher插件直接分发所消耗的时间进行了比较.可以看到两者在消耗时间上基本无差别,这是因为streamdispatcher插件只在直接分发流程上增加了一些条件判别,所增加的开销极小.

我们的实验目标设置为300路实时视频流并发输出能力.在会话连接数目达到300时,一个RTP包发送到所有clientsink插件的消耗时间为542206纳秒.使用抓包工具得知IPC平均一秒内大约发送60个RTP包,因而streamdispatcher插件的转发能力完全能够满足实验目标.

Streamdispatcher插件保证了发送到客户端的初始帧为IDR帧,这也使得视频监控的效果得到了提升,图 6展示了使用 streamdispatcher插件和未使用streamdispatcher插件的视频监控效果.

图6 streamdispatcher插件使用与否的效果比对

图6 中,未使用streamdispatcher插件的流媒体服务器发送到客户端的初始画面出现花屏现象,而使用streamdispatcher插件的流媒体服务器保证了客户端初始画面的完整性,提升了视频监控效果.

5 结语

本文基于GStreamer框架,针对H.264编码规范,设计并实现了一种实时视频流分发插件:使用随机创建的请求型source衬垫完成数据的分发,并通过缓存当前IDR帧组的方法保证了发送的初始帧为IDR帧,解决了视频监控初始画面花屏的问题.本文所描述的插件可应用于流媒体服务器当中,实验证明这种保证了初始数据完整性的实时视频流分发插件在高效转发的同时,也大大提升了实时视频监控效果.

虽然本文讨论的插件针对H.264编码规范,但这种在视频分发端缓存当前IDR帧组以保证初始视频数据完整性的思路仍可扩展到兼容多种编码格式的流媒体服务器设计当中.

1 Wiegand T,Sullivan G J,Bjontegaard G,Luthra A.Overview of the H.264/AVC video coding standard.IEEE Trans.on Circuits&SystemsforVideoTechnology,2003,13(7):560–576.

2杨戈,廖建新,朱晓民,樊秀梅.流媒体分发系统关键技术综述.电子学报,2009,37(1):137–145.

3 Taymans W,Baker S,Wingo A,Bultje RS,Kost S.GStreamer Application Development Manual(1.6.0).2013.https://gstreamer. freedesktop.org/documentation/.

4刘兴民,赵连军.基于GStreamer的远程视频监控系统的关键技术研究.计算机应用与软件,2011,28(5):243–246.

5 Boulton RJ,Walthinsen E,Baker S,Johnson L,Bultje RS, Kost S,Müller TP,Taymans W.GStreamer Plugin Writer’s Guide(1.6.0). 2013. https://gstreamer.freedesktop.org/ documentation/.

6计文平,郭宝龙,丁贵广.新一代视频编码国际标准的研究.计算机应用与软件,2004,21(2):60–62.

7 Schulzrinne H,Rao A,Lanphier R.Real Time Streaming Protocol(RTSP).RFC 2326,Internet Engineering Task Force, 1998,4.

8 Schulzrinne H,Casner S,Frederick R,Jacobson V.RTP:A Transport Protocol for Real-Time Applications.RFC 3550, Internet Engineering Task Force,2003,7.

Real Time Video Stream Dispatch Plugin for Ensuring the Integrity of Initial Data

ZHANG Kai

(Suzhou Keda Technology Co.Ltd.,Shanghai R&D Center,Shanghai 201103,China)

In the real time video surveillance network system,if the initial video data

by the monitoring client is not complete,the screen will show blurred screen.For H.264 coding standard,this paper designs and implements real time video stream dispatch plugin based on the open source multimedia GStreamer framework.The plugin uses a randomly requested source pad to dispatch video data.It also caches current IDR frames group to ensure the integrity of initial IDR frame to be sent.The plugin can be used in streaming media server to solve the problem of the blurred screen of initial screen effect in video surveillance.Experiment shows that the streaming media server with this plugin can effectively distribute the real time video data and ensure the integrity of the initial playback screen,which has a significant effect on improving the real-time monitoring effect.

video surveillance;streaming media server;GStreamer framework;H.264 standard;IDR frame;RTPprotocol

2016-08-28;收到修改稿时间:2016-09-27

10.15888/j.cnki.csa.005747