CN112565247B - 基于IPv6的移动终端实时多媒体数据流传输系统及方法 - Google Patents

Abstract

本发明提供一种基于IPv6的移动终端实时多媒体数据流传输系统及方法，涉及数据传输技术领域。本系统包括用户管理模块、视频推流模块、服务器端模块、视频拉流播放模块以及D2D(Device‑to‑Device Communication)通信模块；使用Wi‑Fi Direct建立了移动设备间的通信网络，实现了吞吐量较大、时延较低的D2D通信来传输实时多媒体数据流，有效地卸载了核心网络的流量。然后针对本系统的应用场景，设计了基于TCP的轮询传输机制，较好地解决了视频数据在D2D传输过程中缺少解码信息无法解码的问题。

Description

基于IPv6的移动终端实时多媒体数据流传输系统及方法

技术领域

本发明涉及数据传输技术领域，尤其涉及一种基于IPv6的移动终端实时多媒体数据流传输系统及方法。

背景技术

目前主流的实时多媒体数据流传输服务主要是基于IPv4(Internet ProtocolVersion4互联网协议第4版)，终端向核心服务器进行推流，核心服务器使用内容分发网络CDN(Content Delivery Network)对多媒体数据流进行缓存以及分发，以基站作为移动设备接入互联网的渠道。这种架构在当前存在许多优点，如不需对原有的适用于PC的传输架构做较大的改变，已经成熟的内容分发网络依旧适用于移动端的场景等等。然而随着近些年移动端设备数量的快速增长，对实时多媒体数据流传输的服务需求与日俱增，导致了网络的数据压力急剧增大，并且由于IPv4协议未能对数据包的优先级做出较为精细的划分，在网络数据压力急剧增大的情况下，实时多媒体的传输会出现越来越严重的时延与抖动，极大地破坏了用户体验。与此同时，实时多媒体数据流相比其他类型的内容有更高的比特率，单纯地依靠蜂窝网络进行传输会产生较多的资费，在本次新冠肺炎疫情中能够看到部分学生因为流量资费的问题而无法正常上网课学习。这些问题的存在让我们思考新的方式来完成实时多媒体数据流的传输。

发明内容

针对现有技术的不足，本发明提供一种基于IPv6的移动终端实时多媒体数据流传输系统及方法；

本发明所采取的技术方案是：

一方面，本发明提供一种基于IPv6的移动终端实时多媒体数据流传输系统，包括用户管理模块、视频推流模块、服务器端模块、视频拉流播放模块以及D2D(Device-to-Device Communication)通信模块；

所述用户管理模块包括用户注册、用户登陆、用户退出、修改频道列表、刷新推流密钥、显示推流地址的二维码；所述用户注册时填写用户ID、密码、频道名，其中用户ID、密码均不能为空格且必须由字母与数字组成，同时为了安全性密码不能低于8位；所述频道列表包括频道名和频道标题，频道名要求不能为空，频道名与频道标题一起显示在正在直播的频道列表便于用户选择自己感兴趣的频道，在登陆时填写ID以及密码，用户分为发送端用户以及接收端用户，发送端用户在采集好数据以后，使用RTMP协议向服务器进行推流操作，数据传输到服务器上；

所述视频推流模块实现视频流的采集、压缩编码、向服务器端推流的功能；该模块使用了前端React社区中的组件库；

所述服务器端模块用于对实时消息传输协议RTMP(Real Time MessagingProtocol)的支持、对超文本传输协议HTTP(HyperText Transfer Protocol)请求的响应来支撑起整个系统的正常运行；

所述视频拉流播放模块完成与视频流源建立连接。在客户端从服务器端请求频道列表数据的同时，也会同时从服务器端获取每个频道注册为组主的设备的P2P(Peer-to-Peer)网卡的MAC地址，同时通过Wi-Fi Direct发现待连接设备，通过比对MAC地址得到获取目标视频流的组主列表，选择频道进行播放时，选择从服务器端直接拉流播放，若存在正在播放该频道的组主，则可以通过加入Wi-Fi Direct组来获取视频流。

所述D2D通信模块是属于接收端用户，使用Wi-Fi Direct建立设备之间的D2D连接达到卸载网络中的实时视频流量的目的。

另一方面，一种基于IPv6的移动终端实时多媒体数据流传输方法，基于前述一种基于IPv6的移动终端实时多媒体数据流传输系统实现，包括以下步骤：

步骤1：发送端采集数据，并进行编码；

发送端实时使用系统的接口API(Application Program Interface)来调用移动端的摄像头获取到原始的视频数据；

步骤2：发送端将采集到的数据传输到系统端；在发送端采集好数据以后，与服务器端建立连接；

步骤3：接收端进行数据接收，首先接收数据可以分为两种方式，一种是直接从系统端进行数据接收。另一种方式是通过D2D的方式进行数据接收；

所述从系统端直接接收数据采用D2D技术进行核心流量卸载，使用Wi-Fi Direct创建组，组主直接采用RTMP协议与服务器端建立连接，将RTMP消息中的视频数据拆分出来后，经过解码操作来获取原始数据，最后播放视频。组主将音视频数据解码后进行存储；

所述通过D2D连接获取数据流通过Wi-Fi Direct组内的成员直接从组主接收音视频数据，组主待组员连接后首先分发所需的解码关键数据，然后再将收到的数据可靠地传输给组员。

采用上述技术方案所产生的有益效果在于：

本发明提出一种基于IPv6的移动终端实时多媒体数据流传输系统及方法，在IPv6网络下设计并实现了实时多媒体数据流传输系统。在吞吐量和延时方面的性能进行验证。服务器端到客户端的之间的传输的吞吐量主要取决于带宽，不在本系统的主要工作范围内，测试主要是针对在网络流量卸载过程中设备通过Wi-Fi Direct组成通信网络的吞吐量。系统的吞吐量远大于将视频正常传输的需求，并在时延方面有较好表现。

附图说明

图1为本发明具体实施方式的基于IPv6网络的实时多媒体数据传输系统结构图；

图2为本发明具体实施方式的拉流播放流程图；

图3为本发明具体实施方式的拉流模块流程图；

图4为本发明具体实施方式的TCP轮询机制流程图；

图5为本发明具体实施方式的用户模块逻辑流程图；

图6为本发明具体实施方式的后端处理流程图；

图7为本发明具体实施方式的系统框架图

图8为本发明具体实施方式的吞吐量示意图。

具体实施方式

下面结合附图对本发明具体实施方式加以详细的说明。

一方面，本发明提供一种基于IPv6的移动终端实时多媒体数据流传输系统，如图1所示，包括用户管理模块、视频推流模块、服务器端模块、视频拉流播放模块以及D2D(Device-to-Device Communication)通信模块；

所述用户管理模块如图5所示，包括用户注册、用户登陆、用户退出、修改频道列表、刷新推流密钥、显示推流地址的二维码；所述用户注册时填写用户ID、密码、频道名，其中用户ID、密码均不能为空格且必须由字母与数字组成，同时为了安全性密码不能低于8位；所述频道列表包括频道名和频道标题，频道名要求不能为空，频道名与频道标题一起显示在正在直播的频道列表便于用户选择自己感兴趣的频道，在登陆时填写ID以及密码，用户分为发送端用户以及接收端用户，发送端用户在采集好数据以后，使用RTMP协议向服务器进行推流操作，数据以这种方式被传输到服务器上。

在注册、登陆以及修改频道标题的时候，首先客户端会直接验证各个字段是否格式满足要求，如果不满足要求则直接提示用户需要修改相应字段，这样做的好处是提前校验能够减少不必要的HTTP请求，缩短用户等待时间的同时能够减小服务器端的访问压力。在刷新推流密钥后，服务器端存储新的密钥，如果推流认证的密钥与数据库中存储的新的密钥不同，则验证失败拒绝推流。每次刷新密钥后，客户端能够生成新的推流地址二维码便于用户扫码进行推流。

所述视频推流模块实现视频流的采集、压缩编码、向服务器端推流的功能；该模块使用了前端React社区中的组件react-native-nodemediaclient库，使用NEON指令集优化H.264软件编码器，支持H.264/AAC组合的RTMP协议音视频流发布；

所述服务器端模块用于对实时消息传输协议RTMP(Real Time MessagingProtocol)的支持、对超文本传输协议HTTP(HyperText Transfer Protocol)请求的响应来支撑起整个系统的正常运行，如图6所示；本模块分为三部分：处理HTTP的nodejs进程、处理RTMP的nginx进程以及用于持久化数据的mysql进程。使用了nodejs社区中生态良好的express框架来实现HTTP服务器处理业务逻辑。对视频流的处理比较影响性能，为了尽可能地提高服务器端的性能，本文使用了基于异步IO的高性能服务器Nginx以及nginx-rtmp-module来实现RTMP服务器端。当客户端发起推流时，会直接与Nginx中的nginx-rtmp-moudle建立通信，nginx-rtmp-module对处理HTTP请求的nodejs进程发起请求，nodejs从mysql中读取数据，对nginx-rtmp-module传来的密钥以及用户ID进行校验，通过则对nginx-rtmp-module返回HTTP状态码200，否则返回HTTP状态码403。nginx-rtmp-module根据返回的状态码决定是否允许客户端进行交流；

所述视频拉流播放模块完成与视频流源建立连接。在客户端从服务器端请求频道列表数据的同时，也会同时从服务器端获取每个频道注册为组主的设备的P2P(Peer-to-Peer)网卡的MAC地址，同时通过Wi-Fi Direct发现附近的设备，通过比对MAC地址得到附近可获取目标视频流的组主列表。选择某个频道进行播放时，可以选择从服务器端直接拉流播放，若附近存在正在播放该频道的组主，则可以通过加入Wi-Fi Direct组来获取视频流。

所述D2D通信模块是属于接收端用户，使用Wi-Fi Direct建立设备之间的D2D连接达到卸载网络中的实时视频流量的目的。Wi-Fi Direct创建组后，组主直接采用RTMP协议与服务器端建立连接，将RTMP消息中的视频数据拆分出来后，由于获取到的视频流数据是经过压缩编码后的，需要经过解码操作来获取原始数据，最后播放视频。组主还需要将音视频数据解码后进行存储。Wi-Fi Direct组内的成员可以直接从组主接收音视频数据，组主待组员连接后首先分发所需的解码关键数据，然后再将收到的数据可靠地传输给组员；

另一方面，一种基于IPv6的移动终端实时多媒体数据流传输方法，基于前述一种基于IPv6的移动终端实时多媒体数据流传输系统实现，包括以下步骤：

步骤1：发送端采集数据，并进行编码；

本系统首先要解决的问题为实时多媒体数据流的获取即采集的工作，发送端需要实时地使用系统的API来调用移动端的摄像头获取到原始的视频数据。

由于原始的视频数据比特率较大，不利于视频的存储，同时在传输的过程中会增加冗余的网络流量，这无法达成本系统尽可能卸载网络流量的目的，因此在进行传输前需要将原始的视频数据进行压缩编码处理，这里本实施例中采用被广泛使用的H.264编码，它在很多软件以及系统中都有良好的支持，并且具有较高的压缩比，能够有效地减少视频带宽。为了让实时多媒体数据流并不局限在小范围内传输，本系统使用RTMP协议向服务器进行推流操作，使其他客户端能够方便地通过与服务器端建立连接拉取到视频流数据；

步骤2：发送端将采集到的数据传输到系统端；

在发送端采集好数据以后，与服务器端建立连接，为了让实时多媒体数据流并不局限在小范围内传输，本系统使用RTMP协议向服务器进行推流操作，使其他客户端能够方便地通过与服务器端建立连接拉取到视频流数据；

步骤3：接收端进行数据接收，首先接收数据可以分为两种方式，一种是直接从系统端进行数据接收。另一种方式是通过D2D的方式进行数据接收；

步骤3.1：从系统端直接接收数据；

本系统采用D2D技术进行核心流量卸载，使用Wi-Fi Direct创建组，组主直接采用RTMP协议与服务器端建立连接，将RTMP消息中的视频数据拆分出来后，由于获取到的视频流数据是经过压缩编码后的，需要经过解码操作来获取原始数据，最后播放视频。组主还需要将音视频数据解码后进行存储；拉流播放流程图如图2所示：选择从服务器端播放则会首先向服务器发送HTTP请求发送自己的p2p网卡的MAC地址来在服务器端注册成为组主。然后与服务器建立TCP连接，客户端向服务器端发送C0、C1，待收到服务器端发送的S0、S1、S2后发送C2完成RTMP握手，然后再向服务器发送建立RTMP连接的指令以及播放的指令，此时能够从服务器端收到RTMP Chunk Stream流。将RTMP Chunk根据唯一的Message Stream ID字段重新组装成为RTMP Message，从RTMP Message中根据Type ID分别提取出音视频数据；

步骤3.2：建立D2D连接来获取数据流；

Wi-Fi Direct组内的成员直接从组主接收音视频数据，组主待组员连接后首先分发所需的解码关键数据，然后再将收到的数据可靠地传输给组员；

步骤3.2.1：组主列表形成：如图3所示在客户端从服务器端请求频道列表数据的同时，也会同时从服务器端获取每个频道注册为组主的设备的p2p网卡的MAC地址，同时通过Wi-Fi Direct发现附近的设备，通过比对MAC地址得到附近可获取目标视频流的组主列表。选择某个频道进行播放时，可以选择从服务器端直接拉流播放，若附近存在正在播放该频道的组主，则可以通过加入Wi-Fi Direct组来获取视频流。

步骤3.2.2：选择加入Wi-Fi Direct组：如图2接收端会向组主请求连接，当组主同意连接后向组主发送数据让组主能够感知到有新的成员加入并建立TCP连接。然后从组主直接获得经提取后的音视频数据。

与视频流源建立连接后，使用安卓的Mediacodec API分别对音视频数据进行解码，得到原始的视频数据后输出到Surface播放，得到原始的音频数据后使用AudioTrackAPI进行播放。

步骤3.2.3：本发明的D2D连接部分采用图4所示的TCP轮询机制进行组主与组员的连接：Wi-Fi Direct组内的成员可以直接从组主接收音视频数据，组主待组员连接后首先分发所需的解码关键数据，然后再将收到的数据可靠地传输给组员；为了保证较好的压缩比以及良好的兼容性，本发明使用了H.264、AAC分别作为视频数据以及音频数据的编码格式。而H.264的视频流数据在解码的过程中，需要获取第一个视频帧的SPS、PPS信息，假如组主通过UDP广播或者多播的方式进行分发数据流的话，无法保证用于解码的SPS、PPS信息能够按照预期的顺序传输给组员，同时由于组员并不是同一个时间加入的Wi-Fi Direct组，每次在组员加入时都广播或多播一次SPS、PPS信息的话，在该组员之前加入组的客户端会收到无用的数据，干扰到正常的解码过程；如果组主通过UDP单播在组员加入时都单独发送SPS、PPS信息给该组员，由于UDP不保证可靠性传输，无法确保数据一定能够传输到客户端，如果通过设计上层协议来保证数据能够可靠地传输，这样做的成本较高，因此本发明设计了一种TCP轮询传输的机制。本发明设计的一种TCP轮询传输的机制分为两个部分：发现组员与轮询传输。每次与Wi-Fi Direct在建立通信网络的时候，组主并不知道组员在D2D网络中的IP地址，无法主动地与组员建立TCP连接，因此需要有一个发现组员的过程。在通过Wi-Fi Direct组件的通信网络中组主的IP地址是固定的，即192.168.49.1，组员成功加入组之后，组员主动与组主建立TCP连接，组主在与组员建立连接后，首先给组员发送视频的SPS、PPS信息，然后将该连接存储到列表中，组员通过接收到的SPS、PPS完成解码操作的初始化，此时第一部分发现组员完成。轮询传输则是在组主每次解析到音视频数据后，遍历存储着与组员建立的TCP连接的列表，如果发现该TCP连接已经终止则将该TCP连接从队列中删除，否则通过该连接向组员传输音视频数据。

本实施例中使用三种不同系统设备进行测试，测试环境如表1所示：

表1:系统测试环境

实现架构如图7所示，系统实现从终端可以分为两部分：客户端用户交互以及后端服务器。

客户端用户交互主要由React Native框架来完成，React Native可以直接通过HTTP访问服务器端，使用JavaScript编写基础的UI以及对整个客户端程序做出控制，在需要性能优化的部分，使用Java编写原生的React Native Component组件来供JavaScript调用，需要调用安卓的API时则使用Java编写原生的React Native Module。本系统通过Java代码实现了RTMP协议拉流过程，将其集成到播放器组件，与nginx-rtmp-module进行通信。

后端服务器部分主要通过Nodejs搭建的HTTP服务器完成调度、响应、认证等工作。Nginx中的nginx-rtmp-module使服务器端支持了RTMP协议，视频的推流的过程中与nginx-rtmp-module建立连接，由Nodejs来控制是否允许推流的进行。Nodejs同时与MySQL Server建立连接，完成数据的持久化操作。

吞吐量测试如下：

服务器端到客户端的之间的传输的吞吐量主要取决于带宽，不在本系统的主要工作范围内，本次测试主要是针对在网络流量卸载过程中设备通过Wi-Fi Direct组成通信网络的吞吐量。本次测试使用到了两台设备：小米Note3(Android 9)、坚果Pro(Android 7)。首先使用坚果Pro作为组主，使用小米Note3作为组员，测试组主TCP向组员发送数据时的吞吐量。

吞吐量结果如图8所示，五次测试的平均值为50.68Mbps，在本系统中客户端推送的视频码率为2.56Mbps，该吞吐量远远大于将该视频正常传输的需求。由于本系统设计使用TCP轮询机制，理论上每个组员的带宽都相同，从原理上说能够满足19个组员加入到组同时播放视频。

时延测试如下：

通过比较组主与组员收到相同视频帧时的时间戳来得出从组主发送到组员的视频帧的延迟，本次测试使用坚果Pro作为组主，小米Note3和坚果U2 Pro均作为组员，测试结果如表2所示。

从测试结果我们可以看出组员越多的情况下，时延则会越大，由于设计的TCP轮询机制采用从前向后遍历，越早加入组的组员时延越小，延迟大概在1s左右。从时延来看，本系统在传输实时数据流的过程中时延较小，具有良好的可用性。

表2：时延测试结果

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

Claims (1)

1.一种基于IPv6的移动终端实时多媒体数据流传输系统，其特征在于，包括用户管理模块、视频推流模块、服务器端模块、视频拉流播放模块以及D2D(Device-to-DeviceCommunication)通信模块；

所述用户管理模块包括用户注册、用户登陆、用户退出、修改频道列表、刷新推流密钥、显示推流地址的二维码；所述用户注册时填写用户ID、密码、频道名，其中用户ID、密码均不能为空格且必须由字母与数字组成，同时为了安全性密码不能低于8位；所述频道列表包括频道名和频道标题，频道名要求不能为空，频道名与频道标题一起显示在正在直播的频道列表便于用户选择自己感兴趣的频道，在登陆时填写ID以及密码，用户分为发送端用户以及接收端用户，发送端用户在采集好数据以后，使用RTMP协议向服务器进行推流操作，数据传输到服务器上；

所述视频推流模块实现视频流的采集、压缩编码、向服务器端推流的功能；

所述服务器端模块用于对实时消息传输协议RTMP(Real Time Messaging Protocol)的支持、对超文本传输协议HTTP(HyperText Transfer Protocol)请求的响应来支撑起整个系统的正常运行；

所述视频拉流播放模块完成与视频流源建立连接；在客户端从服务器端请求频道列表数据的同时，也会同时从服务器端获取每个频道注册为组主的设备的P2P(Peer-to-Peer)网卡的MAC地址，同时通过Wi-Fi Direct发现待连接设备，通过比对MAC地址得到获取目标视频流的组主列表，选择频道进行播放时，选择从服务器端直接拉流播放，若存在正在播放该频道的组主，则可以通过加入Wi-Fi Direct组来获取视频流；

所述D2D通信模块是属于接收端用户，使用Wi-Fi Direct建立设备之间的D2D连接达到卸载网络中的实时视频流量的目的；

所述视频推流模块使用了前端React社区中的组件库；

通过前述基于IPv6的移动终端实时多媒体数据流传输系统实现的传输方法具体流程如下：

步骤1：发送端采集数据，并进行编码；

发送端实时使用系统的接口API(Application Program Interface)来调用移动端的摄像头获取到原始的视频数据；

步骤2：发送端将采集到的数据传输到系统端；在发送端采集好数据以后，与服务器端建立连接；

步骤3：接收端进行数据接收，首先接收数据可以分为两种方式，一种是直接从系统端直接接收数据，另一种方式是通过D2D连接获取数据流；

所述从系统端直接接收数据采用D2D技术进行核心流量卸载，使用Wi-Fi Direct创建组，组主直接采用RTMP协议与服务器端建立连接，将RTMP消息中的视频数据拆分出来后，经过解码操作来获取原始数据，最后播放视频，组主将音视频数据解码后进行存储；

所述通过D2D连接获取数据流通过Wi-Fi Direct组内的成员直接从组主接收音视频数据，组主待组员连接后首先分发所需的解码关键数据，然后再将收到的数据可靠地传输给组员。

Images