1 多平台播放解决方案模型
系统由移动设备客户端、服务器端、视频播放客户端三部分组成。本文中实验的移动客户端为支持安卓系统的手机，通过调用手机设备上的摄像头和麦克风，进行音视频采集。由于在3G网络下服务器访问手机移动IP地址需要“打洞”，故采用手机主动推送的方式进行视频传输。服务器端采用支持RTSP协议的Darwin Stream Server开源服务器，负责RTSP流的转发，因不支持视频存储功能，所以结合开源库mp4v2实现服务器端视频流的录制，存储手机客户端采集的视频到服务器上。播放客户端包括C/S架构的PC播放客户端和B/S架构的浏览器客户端，实现在播放列表中直播或点播文件。系统整体架构如图1所示。
2 手机端设计
2.1 手机端方案
利用手机本身硬件的编码功能，视频采用H264编码，音频采用AAC编码，将编码后的音视频数据封装到RTP包中发送到服务器端。手机客户端主要由音视频采集及编码模块、RTP/RTCP数据压缩及控制模块、RTSP传输控制模块三部分组成，流程框图如图2所示。
2.2 模块设计
(1)音视频采集及编码模块
采用MediaRecorder类，首先调用该类的setAudioSource和setVideoSource设置音视频采集源，再通过该类的setAudioEncoder()和setVideoEncoder()设置音视频的编码方式。以h.264视频编码为例，调用该类中的SetoutputFile函数绑定LocalSocket实现。在编码过程中可以使用硬编码的方式，硬编码是在预览过程提前确定视频的sps、pps、head（一般为0x00000001）。
(2)RTP/RTCP数据压缩及控制模块
RTP包传送可以基于UDP或者TCP，采用TCP作为传输层协议注重可靠性而不是及时性，在RTP传输过程中应用很少，大部分RTP包发送都是采用UDP方式。在RTP会话过程前，发送方需要确定接收方的目标IP及接收端口。
(3)RTSP传输控制模块
RTSP协议作为应用层协议，RTSP命令的传输是基于TCP协议，RTSP本身不作为数据传输的协议，而是作为一种流媒体传输过程的控制协议。
通过RTSP与服务器进行音视频流媒体传输有两种方式：拉模式和推模式。拉模式是主从模式，拉方(例如视频播放客户端)需要维护各个被拉方(例如摄像头)的状态，如url信息、端口信息等，只有拉方主动请求被拉方告知相应信息才能启动。推模式主动权在推方(本文即为安卓移动设备端)，从接方(本文即为Darwin服务器)来看，只要做好标准接口即可，无需关注有多少推方会推送数据。由于移动设备在3G网络下，如果选择拉模式，同一个网段下还需穿透NAT，即“打洞”，不方便做远程音视频传输，所以选择推模式下的视频传输。
3 Darwin服务器端设计
本系统中服务器端负责转发和存储音视频数据，主要由RTSP连接建立模块、视频转发模块及视频录制模块三部分构成。视频播放客户端发送RTSP请求，Darwin流媒体服务器通过Modules发送数据包来回复客户，处理相应的RTSP请求。Darwin服务器作为流媒体客户端的中继代理，移动设备在RTSP协议中的ANNOUNCE命令携带.sdp文件到Darwin服务器接收sdp的目录文件中。此后视频播放客户端就可以通过rtsp://<DSS IP>/***.sdp请求.sdp文件获取到手机客户端对应地址和端口的流。由于Darwin服务器本身不支持视频录制，故加入开源库mp4v2实现视频录制，具体各模块如下：
3.1 RTSP连接建立模块
Darwin Streaming Server定义了RTSPListenerSocket Class，它继承自TCPListenerSocket Class,用于对RTSP连接请求进行处理，进入RTSP状态机。通过RTSPSession对象完成对请求类型的匹配，如果匹配成功，则注册QTSS_RTSPPreProcessor_Role角色的模式。在这个角色模式下，进入QTSSReflectorModule类处理了每种RTSP消息，比如本次RTSP请求的Describe、Setup、Play指令。该类中针对各种请求指令都有对应的单独函数处理，分别对应着DoAnnounce、DoDescribe、DoSetup和DoPlay函数。除此之外，RTSP状态机的终结点所在位置也是在QTSSReflectorModule类中，通过Shutdown()函数实现RTSP会话的结束。
3.2 视频转发建立模块
当收到一路RTSP连接请求时，在DSS中为RTSPSession类对象，首先需要解析请求头部是否为转发请求，进而解析其请求的后续部分。进行查询字符串的解析，得到需要转发的具体url，建立一路面向url源的会话，通过Describe命令获取到sdp信息进行保存，再转发到请求Describe的客户端，而且Setup、Play分别将对应的响应码返回给客户端，在转发具体的数据时，建立一路ReflectorSession，将获取到的rtp数据转发到添加进ReflectorSession转发列表的客户端中。
3.3 视频录制模块
要实现视频录制，首先需要找到音视频RTP数据包，然后将编码过后的H264视频和AAC音频数据从RTP包中按续提取出来，并以MP4文件格式封装，最后存成文件。在Darwin服务器中的ProcessRTPData()函数内部处理处理接收到的RTP包，提取char* packetData数据传递到MP4文件生成函数中。具体通过创建MP4文件句柄、设置时间标度、添加h264视频轨道及aac音频轨道、添加序列参数集和图像参数集，最后再写入文件的方式生成MP4文件。具体视频存储步骤如下：
(1)通过MP4Create创建MP4文件句柄。
(2)通过MP4SetTimeScale设置时间标度，即每秒的时钟ticks数。
(3)通过MP4AddH264VideoTrack添加h264视频track，MP4AddAudioTrack添加aac音频track。
(4)通过MP4AddH264SequenceParameterSet和MP4AddH264PictureParameterSet添加序列参数集和图像参数集。
(5)通过MP4WriteSample写一帧视频数据或写一段音频数据。
其中duration这个参数是用来实现音视频同步用的，如果设置错了会造成音视频不同步，甚至会出现crash现象。对于视频流MP4WriteSample函数，每次调用是录制前一帧数据，用当前帧的时间戳和前一帧的时间戳计算duration值，然后把当前帧保存下来在下次调用MP4WriteSample时用，写音频数据一样。
(6)通过MP4Close关闭打开的MP4文件。
4 B/S架构及C/S架构客户端设计
4.1 C/S架构客户端原理
C/S架构的播放客户端通过支持RTSP的开源live555构建与手机移动客户端的RTSP通信，通过开源编解码框架ffmpeg的解码功能进行解码。
通过live555构建RTSP的过程为：首先创建BasicTaskScheduler和BasicUsageEnvironment对象，用于调度不同事件。创建RTSPClient对象，由RTSPClient对象向服务器发送RTSP中的OPTION消息命令并等待接受回应，返回SDPDescription字符串即sdp文件内容。在任务调度while循环中配置所有子会话对象，为每个子会话创建RTPSource和RTCPInstance对象，并创建两个GroupSock对象。将每个GroupSock对象中创建的socket描述符置入 BasicTaskScheduler::fReadSet中，RTPSource对象的创建的依据是SDPDescription。由RTSPClient对象向服务器发送SETUP消息并接受回应，while循环中为每个子会话创建接收器FileSink对象，由RTSPClient对象向服务器发送PLAY消息并接受回应，FileSink的缓冲区和包含写入文件操作的一个函数指针配置给RTPSource对象，这个缓冲区将会在networkReadHandler中接收来自网络的视音频数据。
获取到音视频数据后，通过ffmpeg的解码功能进行解码处理，流程如图3所示。
avformat_open_input函数对输入的文件名进行解析，并发起与Darwin服务器的RTSP交互。在数据读取线程中，使用rtsp_read_packet函数用于每个RTP包的读取和第一次排序解析。首先调用rtp_read函数从缓冲区获取数据，然后通过包队列交给RTP解析函数rtp_parse_packet进行第一次解析。第一次解析的目的是对包进行重新排序，解决因为网络抖动导致接收到的包序列号不连续的问题。具体是根据RTP协议解析RTP包头信息，对RTP包头的包序列号按递增顺序重新排序。然后调用av_parser_parse2函数对RTP包进行第二次重组帧解析，目的是将包中的数据重新按帧进行组合，组成一帧数据的avpacket。
4.2 B/S架构的实现
B/S架构的服务器端采用Apache服务器，Web客户端采用HTML5的技术直接播放缓存在Darwin服务器下的MP4视频。Web客户端通过访问Darwin服务器下录制视频存放的文件夹，获取mp4后缀的文件名，输出到Web客户端播放列表中。Web客户端实现图片保存及视频大小控制等功能。注册VLC的ActiveX嵌入到网页中，实现直播功能。B/S架构播放客户端如图4所示。
5 测试及分析
根据上述设计，客户端采用B/S架构的Web客户端及C/S架构的PC客户端均可正常观看直播视频，通过mp4v2可实现视频存储功能。本系统服务器使用中国电信100M光纤网络，用60个B/S架构及C/S架构客户端分3组同时请求3路手机推送视频。3路手机视频端码率均设为为500 kb/s，视频采集分辨率分别为320×240、640×480、720×1 280，并在720p分辨率的条件下分3次在中国联通3G网络、中国电信3G网络及无线WiFi网络下分别统计手机移动客户端的视频播放延迟时间。其中服务器所用的硬件环境为：中央处理器：Inter Core I5-2 450 M 2.5 GHz双核四线程；内存：4 GB DDR3 1 333 MHz；硬盘：5 400 rad/min；操作系统：32位 Windows7 操作系统。
播放客户端通过RTSP请求观看直播，请求如：rtsp:// 202.193.53.103/teststream.sdp，由sdp文件名区分不同推送视频源。表1统计了在中国联通3G网络、中国电信3G网络及无线WiFi网络下分别统计手机移动客户端的视频播放延迟时间。
通过60个客户端同时请求服务器连接，表明服务器在带宽为100M光纤网络的条件下，可以同时满足60个用户同时请求连接。客户端同时请求的数量由服务器网络带宽决定。通过分别在中国联通3G网络、中国电信3G网络及无线WiFi网络下推送视频的播放延迟区别表明，系统整体满足不同网络条件下的需求，具有较好的实时性。
6 结束语
本文通过移动设备客户端、服务器端、视频播放客户端组成的系统架构阐述了一个新的视频直播、录制及多平台播放的解决方案。详细讨论了移动设备客户端音视频采集及传输方案、服务器端的转发及存储方案，以及视频播放客户端的两种架构，分析了基于live555的RTSP通信过程及基于mp4v2的视频存储过程，开发出了整套直播、点播系统。同时，设计了相应的测试实验，为实现高可靠、高实时性的视频直播系统提供了一种较为可行的方法。
◆ ◆ ◆ ◆ ◆◆ ◆ ◆ ◆ ◆◆ ◆ ◆ ◆ ◆◆ ◆ ◆ ◆ ◆
联系客服
