基于TD‑LTE应急通信的无线视频传输系统的制作方法

本发明属于实时视频传输技术领域，具体涉及一种基于TD-LTE应急通信的无线视频传输系统。

背景技术：

随着科技的不断发展，人们对于火灾、地震、袭击等突发应急事件的救援过程日益重视。一般的救援通信系统中都包括一个监控中心、若干现场视频采集点以及若干接受语音命令的呼叫终端。传统的视频采集点都是固定摄像头，将采集到的视频数据通过以太网传送到监控指挥中心，这种传输方式已经过于死板，一是其监控力度的局限性，只能监督固定的范围，无法动态的移动；二是这种方式的基础设施很容易遭到破坏，一旦主线路或者某个重要的转发节点坏掉，则整个视频传输系统都将瘫痪，而采用TD-LTE无线网络作为传输信道则可以避免这些弊端。一般在多线程处理过程中，子线程创建之后都要通过循环维持线程的生存，而为了防止子线程一直占用系统资源，在子线程中会加入休眠机制，但是，在视频传输系统的接收过程中，如果加入休眠函数会导致数据包的丢失，严重时会导致画面失真。

技术实现要素：

有鉴于此，本发明的目的是提供一种基于TD-LTE应急通信的无线视频传输系统。

本发明的目的是通过以下技术方案来实现的，基于TD-LTE应急通信的无线视频传输系统，包括至少一个移动通信终端、基站和监控中心；

移动通信终端：用于采集视频数据，并将所采集的视频数据进行压缩编码，通过TD-LTE无线通信网络将压缩编码后的视频数据传输给基站；

基站：用于接收移动通信终端传输过来的压缩编码后的视频数据，通过TD-LTE无线通信网络将压缩编码后的视频数据传输给监控中心的服务器作解码处理并予以显示。

进一步，移动通信终端将采集的视频数据进行压缩编码后以UDP方式将视频数据传输到基站，再由基站转发至监控中心。

进一步，移动通信终端将一帧数据分为若干个UDP分包存入缓存区，然后将UDP分包按顺序从视频发送端口发送至基站，再由基站转发至监控中心。

进一步，监控中心的服务器按照预先设置的IP号开辟端口并接收UDP分包，接收到的数据存入缓存区。

进一步，每个移动通信终端具有与该移动通信终端相对应的接收线程、接收缓存以及解码播放线程。

进一步，所述移动通信终端具有北斗GPS双模定位功能。

进一步，监控中心的服务器接收到的视频数据被从缓存区提取出来，然后经过Ffmpeg视频处理程序将数据包解码并转换为流的形式，最后经过OpenCV的视觉库作视频显示。

由于采用了上述技术方案，本发明具有如下的优点：

视频传输的数据量十分庞大，因此，在传输数据之前必须进行压缩编码，然后在接收端进行解码播放，本发明所使用的H264标准相比于目前在网络中所使用的H263以及H261压缩标准具有更高的编码效率。

在视频接收模块，本发明采用消息响应机制的用户界面线程进行接收，可以有效地解决传统线程使用循环配合休眠函数所引起的丢包情况，在接收端检测数据包的帧信息与包序列，以确定每一个视频包进入循环链表的存储位置，防止UDP传输协议引发的乱序情况。另外，本发明在在解码模块与播放模块中间加入一个双缓存结构的乒乓buffer，数据经过解码之后以帧为单位存入缓存中，可以有效地提高处理器的运算能力，并防止数据因为线程间处理速度的不同而被覆盖丢失。

附图说明

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步的详细描述，其中：

图1为基于TD-LTE应急通信的数据传输系统结构示意图；

图2为基于TD-LTE应急通信的数据传输系统原理框图；

图3为发送端视频采集过程的流程图；

图4为发送端视频编码过程；

图5为接收端通过消息响应机制建立的数据接收线程；

图6为接收端通过死循环建立的视频解码播放线程；

图7为整个视频接收端所有线程的工作过程；

图8为解码之后的帧缓存部分的工作原理。

具体实施方式

以下将结合附图，对本发明的优选实施例进行详细的描述；应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围。

如图1、2所示，基于TD-LTE应急通信的无线视频传输系统，包括至少一个移动通信终端、基站和监控中心。每一个移动通信终端都会事先知道监控中心的网络信息并都将在监控中心的数据库上注册，移动通信终端以一定的时间周期向监控中心发送自己的网络信息，监控中心也以一定的时间不断的检测在线用户列表，如果时间超出一定范围，监控中心一直没有收到某一个移动通信终端的网络信息，说明该用户不在线，监控中心将重新更新用户列表。

移动通信终端主要包括视频采集模块、显示控制模块、通信传输模块以及电源模块。监控中心主要是具有多线程处理功能的服务器或者PC机。在移动通信终端和监控中心上都使用能够处理多线程业务的面向对象语言控制视频数据的接收、编解码和播放过程。

移动通信终端：用于采集视频数据，并将所采集的视频数据进行压缩编码，通过TD-LTE无线通信网络将压缩编码后的视频数据传输给基站；

基站：用于接收移动通信终端传输过来的压缩编码后的视频数据，通过TD-LTE无线通信网络将压缩编码后的视频数据传输给监控中心的服务器作解码处理并予以显示。监控中心的服务器接收到的视频数据被从缓存区提取出来，然后经过Ffmpeg视频处理程序将数据包解码并转换为流的形式，最后经过OpenCV的视觉库作视频显示。

作为对本发明的改进，移动通信终端将一帧数据分为若干个UDP分包存入缓存区，然后将UDP分包按顺序从视频发送端口发送至基站，再由基站转发至监控中心。监控中心的服务器按照预先设置的IP号开辟端口并接收UDP分包，接收到的数据存入缓存区。

由于本发明在视频接收时使用UDP传输协议，具有低时延性；为了克服UDP传输协议可靠性差的缺点，本发明采用并行的多线程接收和单独存储的接收机制，即为每一路移动通信终端开辟一个单独的接收线程和接收缓存，使服务器在下一个数据包来临之前可以完整的接收并存储当前数据包，在同等网络条件下，该方法相比于串行接收可以极大的降低丢包率；在数据接收过程中采用消息响应的方法而不是采用死循环的方法，在保证丢包率在一定范围内的前提下，该方法具有降低CPU消耗的优点。

在无线视频传输的过程中，使用帧间预测编码对视频数据进行编码可以提升视频的编码效率。在帧间预测编码中，以规定的间隔生成通过其自身对输入图像进行编码的帧内编码帧(I图像)，在I图像彼此之间生成对输入图像与预测图像的差分进行编码的多个帧间编码帧(P图像或B图像)，因此能够大幅度地压缩视频数据。被采集到的视频数据先是进入缓存区域，移动通信终端的回放线程和压缩编码线程独立的在缓存区域中读取数据，如果回放的视频模糊或者不连续，说明采集到的视频数据失真，移动通信终端使用者应该重新采集。压缩编码线程从缓存区域读取的数据经过H.264标准压缩编码之后被送到套接字发送。

作为对发明的改进，在移动通信终端的发送终端加入了北斗GPS双模定位功能，通过储存的预制程序算法，获得准确可靠的地理位置信息。双模定位的工作方式相比于单模定位可以更好的保证定位精确性和可靠性，若其中一种定位系统的卫星信号丢失，还可以依靠另一个定位系统进行定位导航。移动通信终端在采集到一帧视频数据后，系统将通过双模定位获取该视频采集点的具体地理位置一并发送给监控中心，在监控中心通过数据挖掘的方式分离视频数据和地理信息。通过精确定位，可以让用户实时了解自己的位置情况，也可以让监控中心更清楚的了解救援现场的周边环境。

在本发明中，设置了至少一个移动通信终端中，每一路移动通信终端都会统一通过TD-LTE网络实时的向监控中心发送视频数据，但是由于监控中心屏幕大小的局限性，为了保证视频信息的准确性和图像质量，监控中心只能选择性的接收和播放各个移动终端采集的视频。所以，在救援过程中，营救人员会根据现场的事态情况设定当前紧急程度，监控中心将根据事故的缓急程度为每一路视频设定优先级，并根据优先级选择性的接收和播放各路终端的视频数据，如果出现突发的紧急事件，营救人员可以直接通过语音呼叫请求指挥人员与自己进行视频通信。指挥人员可以通过当前在线列表更换自己需要观看的视频，也可以进入其中的某一路观看此路视频的详细画面和详细信息。

在传统的监控中心设计过程中，为了减少计算开销，只用开辟一个端口串行接收所有终端或者多个终端的数据量，将数据统一存入一个缓存里，然后在解码播放的时候提取数据通过特征信息分离识别，将数据送到对应的播放窗口，这种做法对于接收不需要达到高清晰度的监控系统是比较合理的，但是却不利于高清视频的完整传输，当单位时间内监控端的接收数据量比所有视频终端发送的数据量小时，很容易造成较大的丢包率，最终必然导致画面失真，且该方法容易出现串扰造成画面的混乱。在本发明中，考虑到视频的质量问题，视频采集频率设置到8000Hz以上，采样率越高图像越清晰，而数据量也就越庞大，因此，当某一路视频被监控指挥人员设定为接收状态时，本发明中的视频接收采用并行接收模式，为该路视频设定单独的接收线程、接收缓存以及解码播放线程，可以在保证视频的高质量性的同时降低接收时延和丢包率。

本发明移动通信终端是在基于达芬奇数字图像处理技术的嵌入式开发平台上加以实现。目前，较为流行的DM37x/AM37x系列是高性能、增强型数字媒体处理器，这种架构提供了丰富的外设接口，充分满足用户对网口、S-VIDEO接口、音频输入输出接口、USB等各种接口的需求，此架构主要被用于ARM和图形演示，具有低功耗的优点。典型代表是DM3730/AM3715处理器，该处理器集成了高主频的ARM内核以及具有高级数字信号处理能力的DSP核。

在进行视频采集时，首先打开视频操作获取设备状态并检测设备的状态是否可以被激活。然后再以读写、非阻塞模式打开设备，查询设备是否支持V412编程，枚举此设备支持的视频格式和视频大小，最后设置系统需要的视频格式及大小，将视频格式设置为YUV格式，图像高度为240，图像宽度为320。

DM37x/AM37x系列平台所提供的摄像头接口ISP兼容了CCD工业摄像头和CMOS数字摄像头，同时支持BT.601、BT.656制式。2D/3D图形加速的底层加快了2D和3D的图形应用速度，其SGX底层是基于新一代可编程的POWERVR图形核，这种架构具有可伸展性。

在设备中申请一个空的视频缓存区域队列并保存队列的相关信息，同时将获取到的实际队列长度里的值提取出来，该长度一般不能超过五个视频缓存区，然后为每个视频缓存区所在的内核空间申请内存，申请完的内核空间需要映射到用户空间。最后，申请相同个数的RGB图像缓冲区，用于在终端上的显示。

在移动通信终端中用于显示的主要在LCD或者TV接口下提供存储帧缓存的逻辑视频图像，底层模块包括：显示控制模组、远程帧缓冲接口模组、显示串行接口的I/O模块和DSI协议引擎、DSI PLL控制器驱动以及NTSC/PAL视频编码。NTSC与PAL是两种不同的电视标准，其中，适用于中国与欧洲的是PAL标准，考虑到与国内其他设备保持一致性，在移动通信终端采用的是PAL标准。

通过事件驱动机制将采集到的图像数据将保存到一个开辟了10帧大小的YUV图像缓冲队列中，其中开辟的每帧图像的最大缓冲区大小为153600B。YUV图像缓冲区中的每帧图像将在视频编码线程中被调用。

视频编码采用的是基于达芬奇平台的H264视频编码方案，该标准是建立在MPEG-4技术的基础之上，编解码流程大致可以分为五步：帧间和帧内预测、变换和反变换、量化和反量化、环路滤波、熵编码。与其它现有的视频编码标准相比，H.264标准在同等带宽条件下对图象的质量具有更好的保障，且该标准在保证相同的图象质量前提下，其压缩效率要比以前的标准高出2倍左右。

移动通信终端使用的是DM9000的10/100M自适应网络接口，DM9000是低功耗、高度集成了快速以太网控制器与通用处理器的芯片，网络接口包括一路10/100M PHY和4K DWORD SRAM,该芯片支持3.3V和5V的IO接口。其中，DM9000内置的10/100M Ethernet模块，它兼容了IEEE 802.3标准协议，网线接口为标准RJ45，可以通过直通网线连接到网络hub上。

由于在视频编码过程中，每一帧数据分包后的每个子包放入到UDP发送队列的时间间隔为5ms，为了实现将数据放入UDP队列和从UDP队列取出数据的同步，视频的发送间隔也设为5ms。

视频数据最终通过LTE双极化智能天线进入LTE网络中。双极化智能天线使用一组双极化辐射单元代替原有单极化辐射单元，并且阵列数量减少为原来的一半，以达到在保持端口总数不变的前提下，减小天线宽度的目的。双极化智能天线在工程上通常采用+45与-45度辐射单元的排列方式，通过这种方式组成的双极化N*2天线线阵，其中N为同极化辐射单元数目，根据目前理论研究、仿真和测试表明，优先选择N＝4。

移动通信终端的电源管理模块包括电源管理控制器、USB高速传输控制、LED驱动控制、模数转换(ADC)、实时时钟(RTC)和嵌入式时钟管理(EPC)等。

本实施例的无线视频传输是基于跨平台设计的，发送端是在基于Linux操作系统的嵌入式开发板上实现，而无线视频传输系统的接收端是在基于Windows操作系统上的PC机或大型计算机上实现。通过MySQL结合MFC建立监控中心的数据库模块，每一个在线终端一旦开机会自动在监控中心注册，监控中心实时检测在线列表。通过MFC中封装的API以及相关的类实现数据的接收和线程的创建与控制，结合ffmpeg以及OpenCV实现视频的解码与播放。

图4为移动通信终端发送视频的基本步骤，移动通信终端采集到一帧数据之后，将其进行编码压缩并以KByte为单位(K>0)分成若干个UDP包。在本发明的动态图像编码过程中，将采集到的若干幅数据图像分成P帧与I帧，I帧为数据画面，是图像的关键帧，P帧为参考帧，是由在它前面的P帧或者I帧预测而来，它与它前面的P帧或者I帧之间的相同信息或数据进行比较，也即考虑运动的特性进行帧间压缩。采取P帧和I帧联合压缩的方法可达到更高的压缩且无明显的压缩痕迹。

图5表示监控中心接收线程基本工作流程，该线程采用消息响应机制达到无休眠、低时延的接收效果。一般情况下，工作子线程创建之后，必须使用循环机制维持其生存，但是无限的循环工作会一直占用运算器，最终将导致系统崩溃，为了避免这类事件发生，在循环工作机制中需要加入休眠机制，缓解处理器的压力，而对于实时传输系统，加入休眠机制将会导致非常大的丢包率，最终表现为视频画面十分不连贯。本发明提供了一种实时传输子线程的创建方法，且该方法不需要休眠，当有数据来临时，线程开始工作，没有数据来临时则不工作。

由微软公司封装的类库MFC提供了丰富的类以及API，为监控中心服务器软件模块的实现奠定了环境基础。为了满足更好的用户体验，当现场情况不是很紧急或者涉及到个人隐私时，营救人员可以自行关闭视频，一来可以节约终端的能量，二来可以为其他的移动终端腾出接入点。这也就决定了移动通信终端的视频数据并不是时刻都有的。本发明通过创建继承于Thread基类的派生类实现监控中心的接收线程，相比于普通线程的实现方法，其优势在于：无需循环工作维持自身的生存，可以在线程中嵌入消息响应机制，当有视频数据来临时，接收线程会实时接收数据，当没有数据来临时，线程处于监听状态，等待数据到来，这样也就省去了休眠机制，减少这种特性迎合了实时通信中低时延和低丢包率的需求。

如图7所示，在主线程中通过AfxBeginThread创建一个独立的线程，该线程中声明并定义一个创建套接字端口的执行函数。创建一个由MFC的Socket类衍生的派生类，声明并定义其接收响应函数，在该函数中写入和发送终端保持一致性的接收函数。然后在接收线程中声明一个Socket派生类的指针变量，在开启监听的地方new一个Socket派生类的对象，用此对象在前面创建的接收线程函数中创建端口号，再绑定一个SOCKADDR_IN的对象，指定发送端地址是任意地址，只要发送端往主机所创建的接收端口上发送数据，就会触发该派生类的接收响应函数接收数据。

在本发明的视频传输中，存在两种不同的缓存区域，第一是接收缓存区域BUFFER，第二是解码缓存区域buffer。接收缓存是一个容量足够大的环形BUFFER，接收数据包一律存放在同一个环形BUFFER中，由于在存放数据的节点上均有对应窗口号的标识，解码线程在访问该BUFFER时只需按照标识将数据解码到对应的播放缓存中去。由于视频数据的接收、解码与播放线程均是不同步的，为了防止解码之后的数据发生丢失，本发明在每一路视频解码之后的分配一个较小的乒乓buffer，其结构如图8所示，解码线程将解好的帧数据存放在一个缓冲单元里，当该缓冲单元存满之后，解码线程开始将数据存入另一个缓冲单元，而播放线程开始从前面的缓冲单元中读取数据，两个线程交替访问两个缓冲单元，使每一帧视频数据完整的显示在对应的窗口中。由于视频数据包遵循先进先出的读写顺序，所以环形BUFFER实际上是一个FIFO，其最小深度为：

Delph＝B_Length-(B_Length/w_clk)*(Num_clk/W_length)*(r_clk/w_clk)其中，B_Length表示突发写入的数据长度；w_clk表示写周期时钟；r_clk表示读周期时钟；Num_clk表示写周期时钟个数；W_length表示Num_clk个写时钟周期内写入的数据长度；

由于人眼的识别能力是在25ms以外,因此在解码与播放过程中延迟1毫秒,对于人的观察而言是没有任何影响的，如图5所示，为了减小解码线程与播放的复杂度,减小处理器的计算开销，直接使用Windows自带的API创建解码线程和播放线程，并使用while(1)维持线程的生存，使用sleep(1)分割线程周期，避免系统CPU被一直占用。

按照前面的两步骤依次创建接收线程、接收缓存、解码线程和播放线程。为预先设定为接收状态的每一个终端开辟接收端口，监控中心根据应急程度选择性的接收并播放该视频。

最后说明的是，以上优选实施例仅用以说明本发明的技术方案而非限制，尽管通过上述优选实施例已经对本发明进行了详细的描述，但本领域技术人员应当理解，可以在形式上和细节上对其作出各种各样的改变，而不偏离本发明权利要求书所限定的范围。