一种移动设备音视频流实时传输方法与流程

本发明涉及移动设备通信技术，特别涉及一种移动设备音视频流实时传输方法。

背景技术：

自2011年起，移动设备(主要包括手机，平板等)全球出货量就已经超越pc，随后，移动设备一直保持着快速发展，从2007年到2015年，移动设备的出货量增长1000％以上，同时，移动设备的智能化程度越来越高，其运算能力已不弱于普通pc，这使得人们对于移动设备的功能需求越来越丰富和多样化。

音视频通信是近年来非常热门的移动设备通信方式，有别于传统的电话/短信通信，音视频通信包含了更丰富的信息维度，特别是视频数据的加入，大大增强了通信数据的表现力。但是由于音视频通信的数据量大，数据使用复杂等原因，音视频通信的稳定性、实时性一直是一项颇具挑战性的工作。

当下流行的音视频传输技术包括hpd(httpprogressivedownload)、hls(httplivingstreaming)、rtsp(realtimestreamingprotocol)三种方式。hpd在开始播放之前仅需等待一段较短的时间用于下载和缓冲该媒体文件最前面的一部分数据，之后便可以一边下载一边播放。在正式开始播放之前的这一小段缓冲应使得后续即使在网络较为拥塞的情况下媒体数据也能够得以不间断地连续播放。hls是苹果公司(appleinc.)实现的基于http的流媒体传输协议，可实现流媒体的直播和点播，主要应用在ios系统。hls协议在服务器端将音视频数据流存储为连续的、很短时长的媒体文件，而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。rtsp实际上是由一组在ietf中标准化的协议所组成，包括rtsp(实时流媒体会话协议)，sdp(会话描述协议)，rtp(实时传输协议)，以及针对不同编解码标准的rtp净载格式等，共同协作来构成一个流媒体协议栈，支持实时的音视频通信。

经过实际应用证明，hpd、hls、rtsp都有相应的缺陷：hpd不支持实时音视频通信，缺少会话控制和流量控制；hls的实时性欠佳，在ios以外的设备支持度较低；而rtsp实现较为复杂，其开发和维护成本都较高。

技术实现要素：

本发明所要解决的技术问题是：提出一种移动设备音视频流实时传输方法，解决传统技术中移动设备音视频传输方案存在的稳定性、实时性不好的问题。

本发明解决其技术问题所采用的技术方案是：

一种移动设备音视频流实时传输方法，包括以下步骤：

a.作为音视频数据发送端的移动设备a和作为音视频数据接收端的移动设备b启动，然后开始参数配置工作；

b.移动设备a开启音视频数据采集的线程进行音视频数据采集，并采用编码器分别对音频和视频进行编码，并记录对应的配置信息；

c.移动设备a将每一帧音视频数据和对应的配置信息封装成对象并存入缓存池中；

d.移动设备a读取缓存池中的音视频数据，将对应配置信息封装至协议头中，已编码的数据紧跟协议头之后；

e.移动设备a将经过步骤d封装的音视频数据发送给移动设备b；

f.移动设备b接收到音视频数据后首先读取协议头，根据读取的信息查找对应的解码器进行解码，然后将解码的数据放入其缓存池中待用。

作为进一步优化，步骤a中，所述开始参数配置工作包括：

a1、移动设备a开启两个tcpsocket与移动设备b建立连接，其中一个连接用于传输视频数据，另外一个连接用于传输音频数据；

a2、移动设备a初始化三个线程at0、at1、at2，其中，at0用于音视频数据采集，at1用于音频数据的发送，at2用于视频数据的发送；移动设备b初始化两个线程bt1、bt2，其中，bt1用于音频数据的接收和解码，bt2用于视频数据的接收和解码；

a3、移动设备a初始化两个缓存池apool1、apool2，其中，apool1用于存放已编码的音频数据及其对应的配置信息，apool2用于存放已编码的视频数据及其对应的配置信息；移动设备b初始化两个缓存池bpool1、bpool2，其中，bpool1用于存放已解码的音频数据及其对应的配置信息，bpool2用于存放已解码的视频数据及其对应的配置信息；

a4、移动设备a初始化音视频编码器。

作为进一步优化，步骤b、c中，所述对应的配置信息包括：编码格式、数据长度和时间戳信息。

作为进一步优化，步骤d中，所述移动设备a读取缓存池中的音视频数据，具体包括：

移动设备a初始化的线程at1和at2检测到缓存池有音视频数据时，从缓存池中读取数据。

作为进一步优化，步骤d中，在配置信息和数据封装时需要遵循以下规则：

d1、协议头每行以“\r\n”结尾；

d2、协议头第一行为“<chunkstart>”,标志一个完整数据的开始

d3、协议头第二行为“command:”，紧随其后是该数据的编码格式，以及其它自定义命令以“/”分隔，内容格式为“[数据类型]/[编码方式]/[命令]”；

d4、协议头第三行为“content-length:”，紧随其后是该数据的长度，单位是字节；

d5、协议头第四行为“timestamp:”，紧随其后是采集数据时记录的时间戳；

d6、协议头第五行为空白，仅包含“\r\n”结尾符。

作为进一步优化，步骤e中，所述移动设备a通过与移动设备b之间建立的两个tcp连接分别将音频数据和视频数据发送给移动设备b。

作为进一步优化，步骤f中，移动设备b接收到音视频数据后首先读取协议头，根据读取的信息查找对应的解码器进行解码，具体包括：

根据协议头数据长度读取对应大小的流数据，根据编码格式和时间戳来查找对应的解码器进行解码。

作为进一步优化，步骤f中，移动设备b通过初始化的线程bt1和bt2监听对应的tcpsocket端口，当有数据来时，解析协议头。

作为进一步优化，步骤f具体包括：

f1、移动设备b以”\r\n\r\n”为协议头结束标志位，从tcpsocket缓存池中读取协议头数据；

f2、以“\r\n”为协议头每行结束标志位，将读取的协议头分割为对应的四行内容，检查第一行是否为“<chunkstart>”，验证协议头正确性，检验其余行内容关键字，若包含“command”，则从该行内容中读取数据类型和编码方式的信息以及协商的命令；若包含“content-length”，则从该行内容中读取数据长度信息；若包含“timestamp”，则从该行内容中读取数据时间戳信息；

f3、根据f2步骤中读取的数据长度信息，读取对应长度的数据，根据f2步骤中读取的编码方式，选取对应的解码器进行数据解码；

f4、将解码的数据和读取的时间戳信息封装成对象，存入对应的缓存池以备使用。

本发明的有益效果是：

本发明利用局域网低延时的优势，采用基于tcp的传输协议，在保证实时、稳定的传输性能的同时，通过有效的协议头控制，极大的增强了通信双方的灵活性，对现有的音视频通信技术是一种非常有效的补充。

附图说明

图1为实施例中的音视频传输和接收流程图；

图2为协议头结构示意图。

具体实施方式

本发明旨在提出一种移动设备音视频流实时传输方法，解决传统技术中移动设备音视频传输方案存在的稳定性、实时性不好的问题。其核心思想是：使用两个tcp连接分别传输音频数据和视频帧，所有的数据与特定的协议头绑定，协议头包含了数据的长度，数据类型，时间戳，操作指令等内容，接收端收到数据后，首先读取协议头，根据协议头数据长度读取对应大小的流数据，根据数据类型和时间戳来查找对应的解码器进行解码，协议头的操作指令可以包含各种自定义的操作，比如切换分辨率，停止传输，重连接等等。

下面结合附图及实施例对本发明的方案做进一步的描述：

实施例：

本实施例中的作为发送端的移动设备a与作为接收端的移动设备b之间的音视频传输和接收流程如图1所示，其包含以下实施步骤：

1、移动设备a、b启动程序，随后，移动设备a、b开始参数配置工作。

参数配置包括如下子步骤：

a1、发动端移动设备a开启两个tcpsocket与接收端移动设备b建立连接，其中一个连接用于传输视频数据，另外一个连接用于传输音频数据，启动独立的线程备用；

a2、发送端移动设备a初始化三个线程at0、at1、at2，其中，at0用于音视频数据采集，at1用于音频数据的发送，at2用于视频数据的发送；接收端移动设备b初始化两个线程bt1、bt2，其中，bt1用于音频数据的接收和解码，bt2用于视频数据的接收和解码；

a3、发送端移动设备a初始化两个缓存池apool1、apool2，其中，apool1用于存放已编码的音频数据及其对应的配置信息，apool2用于存放已编码的视频数据及其对应的配置信息；接收端移动设备b初始化两个缓存池bpool1、bpool2，其中，bpool1用于存放已解码的音频数据及其对应的配置信息，bpool2用于存放已解码的视频数据及其对应的配置信息；

a4、发送端移动设备a初始化音视频编码器，注意，此处接收端移动设备b并没有初始化解码器，而是根据接收到的数据，动态初始化对应的解码器进行解码；

2、发送端移动设备a使用线程at0开始采集音视频数据，通过编码器分别将音频和视频数据编码为对应的数据格式，并记录各自的编码格式、数据长度、时间戳信息等配置信息；

3、发送端移动设备a使用线程at0将步骤2中采集的每一帧音视频数据和对应记录的编码方式、数据长度和时间戳封装成对象存入缓存池中，并将at0的任务跳转至步骤2；

4、发送端移动设备a在步骤1中所初始化的线程at1和at2检测到缓存池有音视频数据时，从缓存池中读取数据，并将数据的配置信息封装到协议头里面，已编码的音视频数据紧随在协议头之后，通过对应的音视频socket发送至移动设备接收端b。

将配置信息和数据封装需要遵循特定的规则，规则具体如下：

b1、协议头每行以“\r\n”结尾；

b2、协议头第一行为“<chunkstart>”,标志一个完整数据的开始

b3、协议头第二行为“command:”，紧随其后是该数据的编码格式，以及其它自定义命令以提供控制的灵活性，以“/”分隔，内容格式为“[数据类型]/[编码方式]/[命令]”，例如”audio/aac”。“video/h.264/exit”等；

b4、协议头第三行为“content-length:”，紧随其后是该数据的长度，单位是字节(byte)；

b5、协议头第四行为“timestamp:”，紧随其后是采集数据时记录的时间戳；

b6、协议头第五行为空白，仅包含“\r\n”结尾符。

协议头的结构如图2所示。

5、接收端移动设备b在步骤1中初始化的线程bt1,bt2监听对应的tcpsocket端口，当有数据来时，解析协议头，并将数据解码放入到缓存池等待使用。

所述读取数据、解析协议头、存放缓存池包括如下几个步骤：

c1、以”\r\n\r\n”为协议头结束标志位，从tcpsocket缓存池中读取协议头数据；

c2、以“\r\n”为协议头每行结束标志位，将读取的协议头分割为对应的四行内容，检查第一行是否为“<chunkstart>”，验证协议头正确性，检验其余行内容关键字，若包含“command”，则从该行内容中读取数据类型和编码方式的信息以及协商的命令；若包含“content-length”，则从该行内容中读取数据长度信息；若包含“timestamp”，则从该行内容中读取数据时间戳信息；

c3、根据c2步骤中读取的数据长度信息，读取对应长度的数据，根据c2步骤中读取的编码方式，选取对应的解码器将数据解码；

c4、将c3步骤解码的数据和c2步骤读取的时间戳信息封装成对象，存入对应的缓存池以备使用。

基于以上方案，本发明中的移动设备音视频流实时传输方法在保证实时、稳定的传输性能的同时，通过有效的协议头控制，极大的增强了通信双方的灵活性。