一种网络流媒体的帧数据获取方法与流程

本发明属于网络流媒体技术领域，尤其涉及一种网络流媒体的帧数据获取方法。

背景技术：

目前市售网络摄像头输出的音视频信号常采用H.264/AVC格式进行压缩，压缩后的信号内容常采用RTP协议将转换为适合于通过网络进行实时传输的流媒体数据包。这种流媒体传输方式被称为H264Over RTP或AVC/RTP。

在进行AVC/RTP传输时，常采用的传输协议有TCP和UDP两种。TCP协议有利于保持数据的完整性，UDP协议则可支持组播和多播，二者各有其更适合的应用场合。

通过TCP协议传输的数据和通过UDP协议传输的数据在操作系统(安卓)转发给应用程序时具有不同的数据形式。通过UDP协议传输的数据应用程序在接收到时仍具有很好的IP包独立性，通过不同IP包发送的数据应用程序在接收到时也保存在不同的数据包中。通过TCP协议传输的数据在操作系统层被解读为流数据，应用程序在接收到时已经无法辨认IP包边界，接收到的只有数据块。这给应用程序进行后续数据解析增加了困难。

技术实现要素：

本发明要解决的技术问题是，提供一种对网络流媒体数据进行获取方法，能支持多种通讯协议和数据内容的数据存储结构，以及在其基础上获取流媒体帧数据，并进行结构化存储。

为解决上述问题，本发明采用如下的技术方案：

一种网络流媒体的帧数据获取方法，其包括以下步骤：

步骤S1、获取TCP协议传输的图像数据流

具体获取过程如下：

获取TCP数据块；

寻找数据包起始标记；

读取跟随起始标记2字节，获得数据包长度；

判断字节数组剩余长度是否大于该单元长度，若剩余数据量不够，则继续等待下一字节数据到达；

数据量充足后，跳至数据单元结尾，检查其后跟随的数据是否是另一数据单元起始标志或其他可表征数据截止的标记；

若是则寻找数据单元边界成功，若为否则从原位置向后继续寻找下一起始标识；

获取数据单元边界后，按照RFC3550文档规定的数据格式解析出帧类型、时间签、单元序号数据，其中，具有相同帧类型和时间签的图像单元从属于同一图像帧，其单元序号标识了它们在帧内的排序关系；

步骤S2、获取UDP协议传输的图像数据流

除无需寻找单元起始标记0x24 0x00和验证单元结尾外，后续方法与步骤S1中获取TCP协议传输的图像数据流处理过程相同。

作为优选，所述图像数据流的数据格式中设置FrameMarker属性，用于记录其保存于存储体时的存储位置，以支持图像数据在记忆体和存储体之间的转移。

本发明针对采用TCP协议或UDP协议传输的视频/音频/控制数据设计统一的数据存储格式；针对TCP协议或UDP协议传输的流媒体信息设计获取算法，以将其存储于上述格式内；利用该数据结构在记忆体(Memory，如内存等)和存储体(Storage，如硬盘、机身存储等)之间转移数据。采用本发明的技术方案，实现图像数据对TCP协议和UDP协议的兼容，以及在存储体和记忆体间的数据转移。

本发明可以同时兼顾TCP纯视频、TCP纯音频、UDP纯视频以及UDP纯音频传输情景，针对上述四种不同的数据输入给出统一的输出结构，以便利与后续功能模块进行对接。同时，在后续处理中还需要对输入的流媒体内容进行灵活的缓存操作，包括在存储体和记忆体间对流媒体数据进行反复转移。

附图说明

图1为本发明对网络流媒体数据进行解析的流程示意图；

图2为本发明对网络流媒体数据进行获取的流程示意图；

图3a为本发明缓存网络流媒体数据至存储体的流程示意图；

图3b为本发明读取网络流媒体数据至记忆体的流程示意图。

具体实施方式

下面结合实施例及附图对本发明的技术方案作进一步阐述。

AVC视频流的基本单位是图像帧，为适合网络传输，一帧图像被分割为若干图像单元。图像数据流在从操作系统传递给应用程序时，采用的数据格式类型都是字节数组。采用TCP和UDP协议传输的区别在于，UDP协议获得的字节数组能够很好的保持图像单元边界，操作系统能够将属于同一个图像单元的IP包进行拼合，传递给应用程序的每一个字节数组代表一个图像单元，但UDP协议存在丢包的风险。TCP协议是一种可靠的传输协议，但采用TCP协议进行传输时，在应用程序接收到的字节数组中，图像单元的边界已全部丢失，需要应用程序对数据进行解析和重构。

AVC/RTP传输协议的具体编码规则参见RFC3550、RFC3984等标准文件，视频流数据解析过程需参考这些标准进行。此外，在重构流媒体帧结构的过程中，应当尽量规避大量的数据拷贝运算。因此上述数据结构在图像单元(NalUnit)下增加了数据包(Package)层，用于记录图像数据在字节数组中的存储信息，同时操作系统提供的字节数组得以整体保留，不对其中的数据进行大量的转移操作。

一个图像单元内的信息可能来自于多个字节数组，一个字节数组内也可能携带属于不同图像单元的数据。因此在一个NalUnit内可包含多个Package，每个Package保存有相关字节数组的内存地址指针(packet)、有效数据的起始位置(offset)以及数据长度(length)。对于包含来自不同数据单元数据的字节数组，其地址指针也将在不同的NalUnit中重复出现。由于字节数组在Package中被引用，因此在程序中无需为其分配全局变量，其数据也不会被操作系统的内存回收机制所破坏。

图像采集设备在送出图像单元(NalUnit)时为其添加了时间签(timestamp)、帧类型(type)和序列号(seq)。具有相同时间签(timestamp)和帧类型(type)的图像单元(NalUnit)来自于同一帧图像(VclFrame)，序列号(seq)则标识了其排序关系。

上述数据结构能够兼容使用TCP和UDP两种传输协议接收到的流媒体数据，且在数据重构过程中避免了大量的拷贝运算。但大量的视频图像数据不能都保存在记忆体(如内存等)中，还需要设计相应的数据结构支持记忆体和存储体(如硬盘等)间的数据转移。因此本数据结构为图像帧设置了FrameMarker属性，用于记录其保存于存储体时的存储位置，以支持图像数据在记忆体和存储体之间的转移。

基于以上分析，如图1、2所示，本发明实施例提供一种网络流媒体的帧数据获取方法，实现图像数据对TCP协议和UDP协议的兼容，以及在存储体和记忆体间的数据转移，其包括以下步骤：

步骤S1、获取TCP协议传输的图像数据流

以TCP协议传输的图像数据流，其图像单元边界被破坏，应用程序需对数据流进行解析重构。RFC3550文档规定了AVC/RTP传输协议的数据头结构，每一数据单元的数据头以0x24 0x00作为开头，其后跟随数据包长度、时间签、单元序号、帧类型等数据。

应用程序在读取TCP监听端口获取的字节数组时，首先需检索数据单元起始标志0x24 0x00，找到此2字节后，假定其为某单元头，并解析出该单元长度。此时判断字节数组剩余长度是否大于该单元长度，若剩余数据量不够，则继续等待下一字节数组到达。数据量充足后，跳至数据单元结尾，检查其后跟随的数据是否是另一数据单元起始标志或其他可表征数据截止的标记，若是则寻找数据单元边界成功，若为否则从原位置向后继续寻找下一起始标识。获取数据单元边界后，需要继续按照RFC3550文档规定的数据格式解析出帧类型、时间签、单元序号等数据。具有相同帧类型和时间签的图像单元从属于同一图像帧，其单元序号标识了它们在帧内的排序关系。在重建图像帧时，还需删除网络传输时添加的数据头，并添加解码用的帧起始标记0x00 0x00 0x00 0x01。

步骤S2、获取UDP协议传输的图像数据流

以UDP协议传输的图像数据其数据单元结构未被破坏，解析重建时较TCP为简单，除无需寻找单元起始标记0x24 0x00和验证单元结尾外，后续方法与TCP相同。

存储体上的数据存储以文件为基本形式，本算法利用一系列缓存文件作为图像数据在存储体上的保存介质。记忆体和存储体间以一帧图像为单次最小数据交换量，在VclFrame中具有FrameMarker结构用于记录该帧图像在存储体中的保存位置。block记录所在缓存文件序号，offset为数据起始位置，length为数据长度。存入缓存文件后，通过赋值VclFrame.dataList为null切断VclFrame与其内部数据单元间的引用关系，其图像数据所占用记忆体空间被操作系统自动回收。

如图3a所示，将图像数据存入缓存文件过程如下：当一个缓存文件内存储的图像数据大小超过程序设定的上限值时，程序将新建一个新的缓存文件。当缓存文件数量达到程序设定的上限值时，程序将覆盖第一个缓存文件，文件内的原有数据永久性丢失。

如图3b所示，读取数据至记忆体的过程如下：在需要将图像数据导回记忆体时，程序读取第block个缓存文件内从第offset字节开始的length字节长度数据，将这些数据读入一个字节数组，利用该字节数组新建一个Package对象，进而新建NalUnit对象插入VclFrame.dataList。

如此，程序内可始终保有最新的相当于最大缓存容量大小的视频图像数据，并可对这些数据进行帧层面的操作。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。