一种移动设备间视频传输方法、系统、设备及计算机介质与流程

本申请涉及移动设备间视频传输技术领域，更具体地说，涉及一种移动设备间视频传输方法、系统、设备及计算机介质。

背景技术：

随着通信技术的发展，移动设备已实现短信加密、图片加密、实时语音加密，然而，由于视频实时性强、数据量大的特点，移动设备无法有效的对视频进行加密；此外，为了保证视频的时效性，移动设备还需要有较高的视频传输效率。

综上所述，如何实现移动设备间视频传输的安全性和时效性是目前本领域技术人员亟待解决的问题。

技术实现要素：

本申请的目的是提供一种移动设备间视频传输方法，其能在一定程度上解决如何实现移动设备间视频传输的安全性和时效性的技术问题。本申请还提供了一种移动设备间视频传输系统、设备及计算机可读存储介质。

为了实现上述目的，本申请提供如下技术方案：

一种移动设备间视频传输方法，包括：

获取待传输视频；

对所述待传输视频进行h.264硬件编码，得到编码视频；

对所述编码视频进行加密，得到加密视频；

对所述加密视频进行rtp封包，得到封包视频，并传输所述封包视频。

优选的，所述对所述编码视频进行加密，得到加密视频，包括：

对所述编码视频进行混沌加密，得到所述加密视频。

优选的，所述对所述编码视频进行混沌加密，得到所述加密视频，包括：

采用混沌加密公式对所述编码视频进行运算，得到所述加密视频；

所述混沌加密公式包括：

其中，k表示迭代次数；m(k)表示所述编码视频；c(k)表示所述加密视频；σ＝2.5×10⁷，ε＝3.3×10⁸；表示向下取整；

优选的，所述传输所述封包视频，包括：

采用rtp协议和udp协议传输所述封包视频。

优选的，所述对所述待传输视频进行h.264硬件编码，得到编码视频，包括：

从h.264编解码器中获取输入缓冲区队列；

在所述输入缓冲区队列中申请一个空缓冲区；

将所述待传输视频拷贝至所述空缓存区，得到实缓存区，将所述实缓冲区存放至所述输入缓冲区队列；

获取所述h.264编解码器的输出缓冲区队列，所述输出缓冲区队列中缓存有所述编码视频，所述编码视频包括所述h.264编解码器对所述实缓存区中的所述待传输视频进行编码后得到的视频；

在所述输出缓冲区队列中申请一个输出缓冲区，并获取所述输出缓冲区中缓存的所述编码视频。

优选的，所述对所述加密视频进行rtp封包，包括：

采用单一封包模式、组合封包模式、分片封包模式中的任意一种或几种模式对所述加密视频进行rtp封包。

优选的，还包括：

接收待显示视频；

对所述待显示视频进行rtp解包，得到解包视频；

对所述解包视频进行解密，得到解密视频；

对所述解密视频进行h.264硬件解码，得到与所述待显示视频对应的原始视频。

一种移动设备间视频传输系统，包括：

第一获取模块，用于获取待传输视频；

第一编码模块，用于对所述待传输视频进行h.264硬件编码，得到编码视频；

第一加密模块，用于对所述编码视频进行加密，得到加密视频；

第一封包模块，用于对所述加密视频进行rtp封包，得到封包视频，并传输所述封包视频。

一种移动设备间视频传输设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上任一所述移动设备间视频传输方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现如上任一所述移动设备间视频传输方法的步骤。

本申请提供的一种移动设备间视频传输方法，获取待传输视频；对待传输视频进行h.264硬件编码，得到编码视频；对编码视频进行加密，得到加密视频；对加密视频进行rtp封包，得到封包视频，并传输封包视频。本申请提供的一种移动设备间视频传输方法，在获取待传输视频后、对待传输视频进行h.264硬件编码、加密及rtp封包，得到封包视频，并且对封包视频进行传输，保证了待传输视频的时效性，并且在得到封包视频的过程中进行了加密处理，保证了待传输视频的安全性，解决了如何实现移动设备间视频传输的安全性和时效性的技术问题。本申请提供的一种移动设备间视频传输系统、设备及计算机可读存储介质也解决了相应技术问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种移动设备间视频传输方法的第一流程图；

图2为h.264编解码器的数据处理流程图；

图3为h.264编解码器的状态转移图；

图4为本申请实施例提供的一种移动设备间视频传输方法的第二流程图；

图5为rtp协议封装格式图；

图6为本申请提供的rtp封包的流程图；

图7为本申请提供的rtp解包的流程图；

图8为混沌加解密方法的流程图；

图9为本申请实施例提供的一种移动设备间视频传输系统的结构示意图；

图10为本申请实施例提供的一种移动设备间视频传输设备的结构示意图；

图11为本申请实施例提供的一种移动设备间视频传输设备的另一结构示意图；

图12为发送视频的移动设备的程序架构流程图；

图13为接收视频的移动设备的程序架构流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参阅图1，图1为本申请实施例提供的一种移动设备间视频传输方法的第一流程图。

本申请实施例提供的一种移动设备间视频传输方法，可以包括以下步骤：

步骤s101：获取待传输视频。

实际应用中，移动设备可以先获取待传输视频，可以是移动设备自身采集待传输视频，也可以是移动设备直接接收传输过来的视频等；待传输视频的类型可以根据实际需要确定，移动设备包括手机、平板电脑等。具体应用场景中，移动设备自身采集待传输视频的过程可以为：移动设备通过自身的摄像头采集nv21格式的原始视频数据，同时将原始视频数据格式转换为nv12格式，得到待传输视频；此外，移动设备还可以将原始视频数据显示在surface上作为预览。

步骤s102：对待传输视频进行h.264硬件编码，得到编码视频。

实际应用中，移动设备在获取待传输视频后，便可以对待传输视频进行h.264硬件编码，得到编码视频。本申请所涉及的h.264是一种视频压缩编码标准，具有高压缩比、高质量编码效果和较好的网络适应性，h.264将编码系统划分为视频编码层vlc以及网络抽象层nal，视频编码层描述了视频数据载荷，网络抽象层负责将vlc中的数据载荷适配到具体网络环境中以提高网络适应性。

实际应用中，为了提高对待传输视频进行h.264硬件编码的编码效率，可以采用缓冲区来加快编码效率。请参阅图2和图3，图2为h.264编解码器的数据处理流程图，图3为h.264编解码器的状态转移图，图2中的客户端可以根据实际情况确定。则对待传输视频进行h.264硬件编码，得到编码视频的过程可以具体为：从h.264编解码器中获取输入缓冲区队列；在输入缓冲区队列中申请一个空缓冲区；将待传输视频拷贝至空缓存区，得到实缓存区，将实缓冲区存放至输入缓冲区队列，此时，h.264编解码器从输入缓冲区队列中取出一个实缓存区，并对其包含的数据进行编码处理，编码结束后，再将实缓冲区清空，得到空缓冲区，将空缓冲区存放至输入缓冲区队列，并将编码视频存放到输出缓冲区队列；获取h.264编解码器的输出缓冲区队列，输出缓冲区队列中缓存有编码视频，编码视频包括h.264编解码器对实缓存区中的待传输视频进行编码后得到的视频；在输出缓冲区队列中申请一个输出缓冲区，并获取输出缓冲区中缓存的编码视频，并将输出缓冲区存放到输出缓冲区队列。

在图3中，h.264编解码器的生命周期内具有停止态、执行态和释放态3种状态。其中停止态包含了3种子状态，分别为未初始化状态、已配置状态、错误状态。执行态经历了3种子状态，分别为刷新状态、运行状态和流结束状态。当使用任意一种方法创建一个编解码器后，编解码器处于未初始化的状态。因此，首先需要调用configure()对编解码器进行配置，使编解码器转换为已配置状态，其次通过调用start()使其转换为执行状态，再次调用start()使得编解码器进入刷新子状态，此时编解码器会拥有所有缓存。一旦第一个输入缓存被移出队列，编解码器就会转入运行子状态，编解码器的大部分生命周期都会在此状态下度过。当带有eos(end-of-stream)标记的输入缓存进入队列时，编解码器将转换到流结束的子状态，编解码器不再接收新的输入缓存，而当eos标记到达输出端时停止输出缓存。在执行状态下通过调用flush()从而使编解码器重新返回到刷新子状态。调用stop()使编解码器返回到未初始化状态，然后可以重新配置。当使用完编解码器之后，必须调用release()释放其资源。在极少数情况下，编解码器会进入到错误状态，通过调用reset()将其恢复到未初始化状态。否则，调用release()进入到最终的释放状态。具体应用场景中，可以通过调取与配置android底层多媒体支持库mediacodec类来访问h.264编解码器。

步骤s103：对编码视频进行加密，得到加密视频。

实际应用中，在获得编码视频后，便可以对编码视频进行加密，得到加密视频。加密方法可以根据实际需要确定。比如可以对编码视频进行混沌加密，得到加密视频。混沌加密过程可以如下：首先甄别h.264码流中的头部数据与视频压缩数据，仅对原始的视频压缩数据进行加密和加密后的视频压缩数据进行解密，具体的甄别方法如下：一个原始的h.264网络抽象层单元nalu(networkabstractlayerunit)由[startcode]+[naluheader]+[nalupayload]三部分组成，在[startcode]中，用"00000001"或"000001"来标示着一个nalu单元的开始，在[naluheader]中，包括1个比特的禁止位、2个比特的参考级别、5个比特的载荷类型，[startcode]+[naluheader]组成头部数据，[nalupayload]为视频压缩数据，然后再对甄别出后的原始的视频压缩数据进行加密。

实际应用中，对编码视频进行混沌加密，得到加密视频的过程可以具体为：采用混沌加密公式对编码视频进行运算，得到加密视频；

混沌加密公式包括：

其中，k表示迭代次数；m(k)表示编码视频；c(k)表示加密视频；σ＝2.5×10⁷，ε＝3.3×10⁸；表示向下取整；aij(i,j＝1,2,3,4)为与密钥相关的参数；

步骤s104：对加密视频进行rtp(real-timetransportprotocol，实时传输协议)封包，得到封包视频，并传输封包视频。

实际应用中，在得到加密视频后，便可以对加密视频进行rtp封包，得到封包视频，并传输封包视频给用来接收视频的移动设备。

具体应用场景中，传输封包视频的过程可以具体为：采用rtp协议和udp(userdatagramprotocol，用户数据报协议)协议传输封包视频。rtp协议提供时间戳、序列号、负载格式，其中时间戳用于数据的同步，序列号用于丢包和重排序检测，负载格式用于说明数据的编码格式，采用rtp协议传输的过程为：从加密视频，也即加密后的h.264码流中分离出每个网络抽象层单元nalu，并加上相应的rtp包头，然后将包含rtp包头和nalu的数据包发送出去。具体应用场景中，可以采用单一封包模式、组合封包模式、分片封包模式中的任意一种或几种模式对加密视频进行rtp封包。

本申请提供的一种移动设备间视频传输方法，获取待传输视频；对待传输视频进行h.264硬件编码，得到编码视频；对编码视频进行加密，得到加密视频；对加密视频进行rtp封包，得到封包视频，并传输封包视频。本申请提供的一种移动设备间视频传输方法，在获取待传输视频后、对待传输视频进行h.264硬件编码、加密及rtp封包，得到封包视频，并且对封包视频进行传输，保证了待传输视频的时效性，并且在得到封包视频的过程中进行了加密处理，保证了待传输视频的安全性，解决了如何实现移动设备间视频传输的安全性和时效性的技术问题。

请参阅图4，图4为本申请实施例提供的一种移动设备间视频传输方法的第二流程图。

实际应用中，本申请实施例提供的一种移动设备间视频传输方法可以包括以下步骤：

步骤s201：获取待传输视频。

步骤s202：对待传输视频进行h.264硬件编码，得到编码视频。

步骤s203：对编码视频进行加密，得到加密视频。

步骤s204：对加密视频进行rtp封包，得到封包视频，并传输封包视频。

步骤s205：接收待显示视频。

实际应用中，可以通过rtp协议和udp协议来发送和接收待显示视频。

步骤s206：对待显示视频进行rtp解包，得到解包视频。

实际应用中，当采用单一封包模式、组合封包模式、分片封包模式中的任意一种或几种模式对加密视频进行rtp封包时，相应的，采用单一封包模式、组合封包模式、分片封包模式中的任意一种或几种模式对待显示视频进行rtp解包。

无论是rto封包还是rtp解包中，rtp数据包均由固定包头和载荷两部分组成，其中包头前12个字节的含义是固定的，载荷为音频或视频数据。rtp固定包头的格式如图5所示，具体含义如下：

v为2位的版本号，目前rtp使用的版本号为2(即二进制的10)；

p为1位的填充号，如果p＝1，则在该报文尾部填充一个或多个额外的8位组。在本发明中，选取p＝0，不在报文尾部进行填充；

x为1位的扩展位，如果x＝1，则在rtp报头后跟有一个扩展报头，在本申请中，选取x＝0，不使用扩展报头；

cc为4位的csrc计数，它位于rtp固定包头的后面，提供源标识符csrc的数目，在本申请中，选取cc＝0000，即rtp固定包头后不加入csrc；

m为1位的标记位，如果为nalu最后的接入单元或者为nalu最后的分片时，则m＝1，否则m＝0；

pt为7位的载荷类型，根据封包内容的不同而改变，如31代表rtp载荷类型为h.261数据、34代表rtp载荷类型为h.263数据，在本申请中，选取pt为96(代表h.264数据)；

sq为16位的序列号，序列号的起始值为随机值，在本申请中，选取sq为0，每发送一个rtp数据包，序列号加1；

ts为32位的时间戳，时间戳的起始值为随机值，在本申请中选取ts为0；

ssrc为32位的同步源标识符，ssrc为随机生成值，从而使得在同一个rtp会话期中，没有任何两个同步源具有相同的ssrc识别符；

csrc提供0～15项的源标识符，其中每一项的长度为32比特，项数的大小为0～15，由cc字段确定。

请参阅图6和图7，图6为本申请提供的rtp封包的流程图，图7为本申请提供的rtp解包的流程图。

图6与图7分别为发送端rtp封包算法流程图与rtp解包算法流程图。对于每一个nalu，数据量的大小也有差异。在ip(internetprotocol)网络中，当需要传输的ip报文大小超过最大传输单元mtu(maximumtransmissionunit)时，就会产生ip分片情况。在以太网的环境中，可传输的最大ip报文(mtu)的大小为1500字节，其中ip头为20字节，udp头为8字节，rtp头为12字节，rtp的最大有效负载为1460字节。如果发送的ip数据包大于mtu，则需要拆包传送，这样会产生很多的数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，如果rtp包大于mtu，并且由硬件协议任意拆包，就会导致接收端的播放器延时播放甚至无法正常播放。故对于大于mtu的nalu单元，必须进行拆包处理。为了进一步解决这个问题，在本申请中，给出了以下3种rtp的封包方案：

单一封包模式：在一个rtp包中只封装一个nalu，封包时直接使用rtp头替换nalu开始码。在本申请中，对于小于1400字节的nalu采用了这种打包方案；

组合封包模式：在一个rtp包中封装多个nalu，对于较小的nalu可以采用这种打包方案，从而提高传输效率。有stap-a、stap-b、mtap16、mtap24四种组合封包模式，在本申请中，采用了stap-a封包模式。封包格式如下：[rtp头]+[78(stap-a头，占用1个字节)]+[第一个nalu长度(占用两个字节)]+[第一个nalu内容]+[第二个nalu长度(占用两个字节)]+[第二个nalu内容]；

分片封包模式：一个nalu封装在多个rtp包中，对于大于1400字节的nalu采用这种方案进行拆包处理，并分为fu-a和fu-b两种类型，本发明文采用fu-a。封包格式如下:[rtp头]+[fuindicator]+[fuheader]+[除去了nalu头的nalu]，其中[fuindicator]包括了1个比特的禁止位、2个比特的nri和5个比特的分片类型，[fuheader]包括1个比特的开始位、1个比特的结位、1个比特的禁止位和5个比特的载荷类型，[fuheader]中的开始位和结束位不能同时为1。

一个原始的h.264nalu由[startcode]+[naluheader]+[nalupayload]三部分组成，其中startcode标示一个nalu单元的开始，必须是"00000001"或"000001"，nalu头仅为一个字节，其余的为nalu单元内容。封包时除开始码"000001"或"00000001"外，将其他数据封包成rtp包即可。

根据图6，在发送视频的移动设备端，h.264码流在不同情况下可采用不同的rtp封包方案，对于序列参数集(sps)和图像参数集(pps)，采用组合封包模式。对于长度小于1400字节的nalu，采用单一封包模式，而大于1400字节则采用分片封包模式。封包过程如下：判断是否以00000001为起始码，若否，则丢弃，若是，则识别nalu格式；判断nalu格式是否为sps和pps，若是sps和pps，则使用组合封包模式设置rtp包头，若不是sps和pps，则计算nalu(i帧或p帧)长度len；判断len是否小于1400，若小于1400，则使用单一nalu模式设置rtp包头，若大于等于1400，则使用分片封包模式设置rtp包头，并设置分片nalu头；判断是否为该nalu最后一个分片rtp包，若是，则返回判断判断是否以00000001为起始码的步骤，若否，则返回使用分片封包模式设置rtp包头的步骤。

根据图7，在接收视频的移动设备端，当收到rtp包后，通过rtp包头的pt字段识别nalu的封包模式，并根据不同的封包模式还原h.264的nalu头部信息，拼接成完整的一帧加密后的h.264码流。解包过程如下：判断是否以0x80为起始码，若否，则丢弃，若是，则识别nalu封包模式；若是单一封包模式，则去掉rtp头，还原h264nalu头部(0x0000000161或0x0000000165)；若是组合封包模式(stap-a)，则获取stap-a载荷1的长度与内容，去掉rtp头，还原sps头部(0x0000000167)，获取stap-a载荷2的长度与内容，去掉rtp头，还原pps头部(0x0000000168)，拼接sps与pps；若是分片封包模式(fu-a)，获取分片fu-header，判断fu-header第一位是否为1(起始位置)，若第一位不是1，则直接附上载荷内容至buf，若第一位为1，则清空buf，附上h264头部信息，并附上载荷内容至buf，判断fu-header第一位是否为1(结束标志)，若否，则获取下一个fu-a分片，返回执行获取分片fu-header的步骤。

步骤s207：对解包视频进行解密，得到解密视频。

实际应用中，当采用混沌加密方法进行加密时，相应的，采用混沌解密方法进行解密；请参阅图8，图8为混沌加解密方法的流程图。解密过程如下：采用混沌解密公式对解包视频进行运算，得到解密视频；

混沌解密公式包括：

其中，k表示迭代次数；p(k)表示解包视频；表示解密视频；表示向下取整；aij(i,j＝1,2,3,4)为与密钥相关的参数。

当密钥参数匹配时，成立，得可知接收视频的移动设备端能正确解密出原始视频；当密钥参数失配时，可知接收视频的移动设备端不能解密出原始视频。

步骤s208：对解密视频进行h.264硬件解码，得到与待显示视频对应的原始视频。

实际应用中，可以原始视频还原成yuv格式的视频数据，并且将openglrender绑定到显示平面上，编写在图形处理器(gpu)中运行的并行程序段shader，将yuv格式转化为rgb格式，通过opengles进行视频显示。

本申请还提供了一种移动设备间视频传输系统，其具有本申请实施例提供的一种移动设备间视频传输方法具有的对应效果。请参阅图9，图9为本申请实施例提供的一种移动设备间视频传输系统的结构示意图。

本申请实施例提供的一种移动设备间视频传输系统，可以包括：

第一获取模块101，用于获取待传输视频；

第一编码模块102，用于对待传输视频进行h.264硬件编码，得到编码视频；

第一加密模块103，用于对编码视频进行加密，得到加密视频；

第一封包模块104，用于对加密视频进行rtp封包，得到封包视频，并传输封包视频。

本申请实施例提供的一种移动设备间视频传输系统，第一加密模块可以包括：

第一加密单元，用于对编码视频进行混沌加密，得到加密视频。

本申请实施例提供的一种移动设备间视频传输系统，第一加密单元可以包括：

第一加密子单元，用于采用混沌加密公式对编码视频进行运算，得到加密视频；

混沌加密公式包括：

其中，k表示迭代次数；m(k)表示编码视频；c(k)表示加密视频；σ＝2.5×10⁷，ε＝3.3×10⁸；表示向下取整；

本申请实施例提供的一种移动设备间视频传输系统，第一封包模块可以包括：

第一传输单元，用于采用rtp协议和udp协议传输封包视频。

本申请实施例提供的一种移动设备间视频传输系统，第一编码模块可以包括：

第一获取单元，用于从h.264编解码器中获取输入缓冲区队列；

第一申请单元，用于在输入缓冲区队列中申请一个空缓冲区；

第一拷贝单元，用于将待传输视频拷贝至空缓存区，得到实缓存区，将实缓冲区存放至输入缓冲区队列；

第二获取单元，用于获取h.264编解码器的输出缓冲区队列，输出缓冲区队列中缓存有编码视频，编码视频包括h.264编解码器对实缓存区中的待传输视频进行编码后得到的视频；

第二申请单元，用于在输出缓冲区队列中申请一个输出缓冲区，并获取输出缓冲区中缓存的编码视频。

本申请实施例提供的一种移动设备间视频传输系统，第一封包模块可以包括：

第一封包单元，用于采用单一封包模式、组合封包模式、分片封包模式中的任意一种或几种模式对加密视频进行rtp封包。

本申请实施例提供的一种移动设备间视频传输系统，还可以包括：

第一接收模块，用于接收待显示视频；

第一解包模块，用于对待显示视频进行rtp解包，得到解包视频；

第一解密模块，用于对解包视频进行解密，得到解密视频；

第一解码模块，用于对解密视频进行h.264硬件解码，得到与待显示视频对应的原始视频。

实际应用中，为了提高视频传输效率，可以采用缓存队列来对视频传输过程中的数据进行处理，使得移动设备可以并行工作，比如可以设置发送视频数据缓存队列和接收视频数据缓存队列，则第一获取模块可以将获取的待传输视频发送至发送视频数据缓存队列中；第一编码模块可以将编码视频传送到发送视频数据缓存队列；第一加密模块可以将加密视频传送到发送视频数据缓存；第一解包模块可以将解包视频传送到接收视频数据缓存队列；第一解密模块可以将解密视频传送到接收视频数据缓存队列。

本申请还提供了一种移动设备间视频传输设备及计算机可读存储介质，其均具有本申请实施例提供的一种移动设备间视频传输方法具有的对应效果。请参阅图10，图10为本申请实施例提供的一种移动设备间视频传输设备的结构示意图。

本申请实施例提供的一种移动设备间视频传输设备，可以包括：

存储器201，用于存储计算机程序；

处理器202，用于执行计算机程序时实现如上任一实施例所描述的移动设备间视频传输方法的步骤。

请参阅图11，本申请实施例提供的另一种移动设备间视频传输设备中还可以包括：与处理器202连接的输入端口203，用于传输外界输入的命令至处理器202；与处理器202连接的显示单元204，用于显示处理器202的处理结果至外界；与处理器202连接的通信模块205，用于实现移动设备间视频传输设备与外界的通信。显示单元204可以为显示面板、激光扫描使显示器等；通信模块205所采用的通信方式包括但不局限于移动高清链接技术(hml)、通用串行总线(usb)、高清多媒体接口(hdmi)、无线连接：无线保真技术(wifi)、蓝牙通信技术、低功耗蓝牙通信技术、基于ieee802.11s的通信技术。

本申请实施例提供的一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现如上任一实施例所描述的移动设备间视频传输方法的步骤。

本申请所涉及的计算机可读存储介质包括随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质。

请参阅图12和图13，图12为发送视频的移动设备的程序架构流程图，图13为接收视频的移动设备的程序架构流程图。

发送端(发送视频的移动设备端)和接收端(接收视频的移动设备端)的具体程序架构流程图分别如图12和图13所示。根据图12，整个发送端程序架构主要分为main类、camera类、encoder类、encrypter类、sender类以及bufferqueue类。main类主要实现线程初始化以及控制每一个线程的开始与结束，具体实现方法如下：

(a)执行int_camera_sufaceview()实现摄像头的初始化。

(b)执行setvideoframelistener()实现摄像头采集视频数据的监听。

(c)执行startcamera()实现摄像头视频采集的开始。

(d)执行createncoder()创建编码器线程，并通过newencoderbufferqueue()创建一个新的队列，用来缓存编码器的数据。

(e)执行createncrypter()创建混沌加密线程，并通过newencrypterbufferqueue()创建一个新的队列，用来缓存混沌加密模块的数据。

(f)执行creatsender()创建网络发送线程，并通过newsenderbufferqueue()创建一个新的队列，用来缓存网络发送模块的数据。

(g)调用stop()结束各个线程。

camera类实现视频采集与视频预览，具体实现方法如下：

(a)执行setpreviveparams()实现摄像头的配置。

(b)执行setprevivecallback(captureyuvstr)实现视频信号的循环采集，并且通过oncapturerawframecallback(byte[]buffer)将数据回调到main类，通过push_encoder_frame_queue()方法将数据送进bufferqueue中。

(c)执行startpreview()开启视频预览。

encoder类实现视频数据的h.264编码，具体实现方法如下：

(a)执行newencoder(encoderbufferqueue)创建一个编码器对象，并且通过configencoder()对编码器进行参数配置。

(b)执行setencoderframelistener()实现编码数据的监听。

(c)执行stratencoderthread()开启编码线程，调用poll_queue_frame()获取队列里的视频帧，并且通过mediacodecencoding()对所有从队列里读取到的视频帧进行编码，执行callbackencryptframedata()回调数据，最后执行push_encrypter_queue()将h.264码流传送到缓存队列。

encrypter类实现h.264码流的混沌加密，具体实现方法如下：

(a)执行newencrypter(encrypterbufferqueue)创建一个加密的对象。

(b)执行stratencrypterthread()开启混沌加密线程，执行startencrypt()开始加密，通过pollqueueframe()获取队列里的h.264码流，加密所有从队列里读取到的h.264码流，最后执行callbacksendframedata()回调数据，执行push_encrypter_queue()将加密后的h.264码流传送到缓存队列。

sender类实现加密后的h.264码流的网络发送，具体实现方法如下：

(a)执行newsender(senderbufferqueue)创建一个网络发送的对象。

(b)执行startsenderthread()开启网络发送线程，执行startrtppacketizer()实现对加密后的h.264码流的rtp封包，并且通过udpsend()进行网络发送。

bufferqueue类实现缓冲区队列，对每一个线程的数据进行缓存

根据图13，整个接收端程序架构主要分为main类、receiver类、decrypter类、decoder类以及bufferqueue类。main类主要实现线程初始化以及控制每一个线程的开始与结束，具体实现方法如下：

(a)执行creatreceiver()创建网络接收线程。

(b)执行creatdecrypter()创建混沌解密线程，并执行newdecrypterbufferqueue()创建一个新的队列，用来缓存混沌解密模块的数据。

(c)执行creatdecoder()创建解码器线程，并执行newdecoderbufferqueue()创建一个新的队列，用来缓存解码器的数据。

(d)调用stop()结束各个线程。

receiver类实现加密后的h.264码流的网络接收，具体实现方法如下：

(a)执行newreceiver(receiverbufferqueue)创建一个网络接收对象。

(b)执行startreceiverthread()开启网络接收线程，执行startudpreceiver()实现对网络接收到的加密后的h.264码流rtp解包，执行startframeconstruct()将解包后的h.264码流拼成完整的一帧h.264帧。最后执行callbackframedata()回调数据，执行push_decrypter_queue()将网络接收到的加密后的h.264码流传送到缓存队列。

decrypter类实现h.264码流的混沌解密，具体实现方法如下：

(a)执行newdecrypter(decrypterbufferqueue)创建一个加密的对象。

(b)执行stratdecrypterthread()开启混沌解密线程，调用startdecrypt()开始解密，执行poll_queue_frame()获取队列里的加密后的h.264码流，解密所有从队列里读取到加密后的h.264码流，最后执行callbackdecryptframedata()回调数据，执行push_decrypter_queue()将解密后的h.264码流传送到缓存队列。

decoder类实现对解密后的h.264码流的解码，具体实现方法如下：

(a)执行newdecoder(decoderbufferqueue)创建一个解码器对象。

(b)执行setdecoderframelistener()实现解码数据的监听。

(c)执行stratdecoder()开始解码，在解码过程中，执行startrenderthread()实现opengl的视频循环显示，执行startdecoderthread()开启解码线程，执行poll_queue_frame()获取队列里的h.264码流，执行findavcnalspsandpps()，当识别到序列参数集(ssp)和图像参数集(pps)时，执行configdecoder()将其传送到硬件解码器并初始化解码器，执行mediacodec_decoding()解码所有从队列里读取到的h.264码流，循环解码每一帧视频数据。

bufferqueue类实现缓冲区队列，对每一个线程的数据进行缓存。

本申请实施例提供的一种移动设备间视频传输系统、设备及计算机可读存储介质中相关部分的说明请参见本申请实施例提供的一种移动设备间视频传输方法中对应部分的详细说明，在此不再赘述。另外，本申请实施例提供的上述技术方案中与现有技术中对应技术方案实现原理一致的部分并未详细说明，以免过多赘述。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。