android H264(3): 流媒体播放器设计方案

如果说一个人的力量有限，那么网络的力量就是无穷的。研究H264的目的就是自己定制一个流媒体播放器，实时播放视频。

好在网上牛人颇多，站在巨人的肩上，压力会小很多。

播放器整体设计方案

一般播放器整体设计包括方案包括三个处理阶段：
1）获取媒体数据 
2）解码音视频流媒体 
3）将解码后的媒体数据显示给用户 

基于层次的播放器结构设计从上到下的层次： 

1. 数据提取层 
   该层功能包括本地文件、流媒体文件的获取 
2. 数据预处理层 
   对本地文件按照媒体格式解封装，获取文件的音视频或文字字幕等信息，并将其按帧放入相应的上层待解码缓冲区；对流媒体文件将去除RTP的包头信息，并将RTP中音视频信息组帧，将完整的数据帧传给上层待解码缓冲区 
3. 音视频解码层 
   有解码选择组件，各种主流音视频解码器和多路媒体流之间同步的功能 
4. 用户界面 
   主要提供用户和播放器之间的交互接口 
FFmpeg:它提供了录制、转换以及流化音视频的完整解决方案。 

本篇来自：http://freewxy.iteye.com/blog/738790

基于Android平台的流媒体播放器的设计

1 引 言 
　　随着移动通信技术和多媒体技术的迅速发展，融合手机、网络、多媒体技术为一体的视频监控技 术也有了长足的进步，通过移动通信网络提供流媒体服务已经成为可能。全球移动用户数非常庞大，因此移动流媒体服务具有巨大的市场潜力，也正成为移动业务的 研究热点之一。在这一背景下，针对移动网络和移动终端的特点，提出移动流媒体客户端的解决方案很有现实意义。
　　本论文结合FFmpeg开源代码中解码流程，提出了移动终端流媒体播放器基于分层体系架构的设计方案。该设计的特点是在底层屏蔽不同类型文件解码时对媒体流处理的差异，并且提供了对外部摄像头设备的控制功能，最终在Android平台[1]上实现该播放器。
2 播放器整体设计方案 
　　播放器无论播放本地文件或是网络流媒体文件，都需要有获取媒体数据，解码音视频媒体流，将解码后媒体数据显示给用户三个处理阶段，根据0文件播放的流程中这三个明显的处理阶段，本文提出基于层次的播放器结构设计。
　 　由于本地文件和网络流媒体文件的数据获取方式是不相同的，若要保持上层解码的一致性，需要对两类文件进行预处理，形成相同格式的数据提供给上层解码。根 据以上特性，结合文件解码流程本文中面向实时监控的播放器设计采用分层结构，每层独立完成任务，使系统的耦合度降低，利于各层独立扩展而不影响上下层的应 用。从下至上依次是数据提取层、数据预处理层、音视频解码层和用户界面。该流媒体播放器分层结构如图1所示。
　　用户界面层主要提供用户和播放器之间的交互接口，如播放本地文件时可以实现暂停、快进、快退等功能，在观看流媒体文件时可以通过数字键、导航键或者播放器上方向按钮控制摄像头的焦距、方向等信息。
　 　音视频解码层主要有解码选择组件、各种主流音视频格式的解码器和多路媒体流之间同步的功能。解码选择组件从本地文件或者流媒体文件头中获取到媒体的解码 格式信息，根据该格式信息选择相应的解码器对压缩后媒体流进行解码。该部分是由FFmpeg修剪优化后作为播放器的解码模块的。多路媒体之间同步包括视频 流和音频流的同步，在播放本地文件时可能还需要字幕的同步。
　　数据预处理层对本地文件按照其媒体格式解封装，获取文件的音视频或字幕等信息并将 其按帧放入相应上层待解码缓冲区。对流媒体文件将去除RTP的包头信息，并将RTP中音视频信息组帧，将完整的数据帧传给上层待解码缓冲区。而封装控制信 息组件按照PELCO-D/P协议规定的文本格式封装用户的控制输入，并将控制信息传递给下层。
　　数据获取层的功能包括本地文件、流媒体文件的 获取和摄像头控制信息的发送，前者只需读取本地文件即可，流媒体文件的获取需要从流媒体服务器获取媒体数据信息。流媒体文件获取部分包括前期会话协商部 分、数据发送部分和数据缓冲部分。其中媒体信息协商部分需要使用 RTSP协议[2]协商媒体流常规信息，如媒体类型（视频和音频）、传输协议（RTP/UDP/IP…）和媒体格式（H263、mpeg…）和媒体传输端 口等信息。
3 FFmpeg到Android平台的移植 
　　FFmpeg是一个集录制、转换、音/视频编码解 码功能为一体的完整的开源解决方案。但本文中播放器只需要FFmpeg中对文件解封装及音视频解码部分的功能，若将 FFmpeg整个解决方案全部移植到目标平台上会造成大量的代码冗余。并且FFmpeg代码的开发时基于Linux操作系统的，并没有考虑到手机平台的处 理能力小，能源不足等限制，因此针对手机上特定功能需求将FFmpeg代码进行修剪及优化是十分重要的。
　　3.1 FFmpeg修剪及优化
　 　从FFmpeg如此庞大并且代码结构复杂的源代码中找出本文需要的代码确实是一项非常艰难的工作。在Linux下编译运行FFmpeg代码时需要经过 configure、make、make install三步才能将FFmpeg正确的编译到Linux系统当中。其中configure阶段会生成一个configure.h和make文件，从 这两个文件中可以查找出该次编译都编译了那些文件。
　　经研究发现在configure源代码的时候可以加入很多配置参数，其中参数分为基本选项 参数、高级选项参数还有专门提供的优化参数。优化参数主要负责配置在编译时需编译的内容。对FFmpeg的修剪也恰是将本系统中不需要的文件去除，因此本 文利用选择适当的优化参数的方法找出播放器所需文件。对这些参数仔细研究后，得出编译时设置的参数如下：

./configure --enable-version3 --disable-encoders --enable-encoder=h263 --enable-encoder= amr_nb --disable-parsers --disable-bsfs --enable-muxer=tgp --disable-protocols --enable-protocol =file。

　　以上面所示的参数配置编译源文件时，系统只将h263、amr_nb的编码方法和3gp的文件封装格式及其所有的解码格式、解封装文件的源代码部分编译到了链接库。
　    此时被编译到链接库的源代码集合即为本文所需的源代码有效集，通过查找configure.h和make文件中的后缀名为.o文件，后缀名为.o的文件 是编译.c代码时生成的目标文件，每一个被编译的.c文件都会生成.o文件，所以通过查看所有的后缀名为.o的文件名，便可得知在该配置参数下被编译源文 件有哪些，因此可以得出本文所需编译的源文件最小集合。
　　FFmpeg开源代码虽然能够跨平台编译运行，但其代码的设计都是针对于PC机而言的，PC机和手机从CPU处理能力、能源、内存等各方面的资源都具有很多大差异，本文中针对手机的特点主要从以下几个方面优化代码：
　　1. 去除冗余代码、规范程序结构、减少if-else 的判断、调整局部和全局变量、使用寄存器变量代替局部变量，减少不必要的代码冗余，去除FFmpeg 调试过程中的打印语句；
　　2. 用逻辑移位运算代替乘除操作，因为乘除运算指令的执行时间远远大于逻辑移位指令，尤其是除法指令，使用逻辑移位运算可以减少指令的运行时间；
　　3. 注意循环函数的调用，尽量减少多重循环的使用，编写代码时尽量减弱上次循环与下次循环的相关性，减少不必要的代码计算量；
　　4. 设置合理的缓存。针对FFmpeg 移植的目标平台Android平台，设置适合此本台的缓存大小；。
　　这里对具体代码的修改就不一一重复了。
　　3.2 FFmpeg移植
　 　Google发布的NDK的makefile文件即Android.mk文件语法和普通的makefile文件有很多不同之处，在跨平台编译 FFmpeg源代码时并不能使用原有的makefile文件。所以移植的先决条件就是将FFmpeg里的makefile文件全部替换为NDK中的 Android.mk文件。
　　通过分析FFmpeg的模块结构得知avutil是基础模块，avcodec模块的编译基于已经编译好的 avutil模块，avformat基于前两者，按照这种模块结构本文编译移植的顺序为avutil、avcoedec、avformat，编译的步骤详 细说明如下：
　　1. 关于config.h和config.mak
　　首先说明一下FFmpeg自带的 makefile的框架，FFmpeg在经过configure命令之后会产生一个config.h文件和一个config.mak文件，这两个文件加起 来共有 600-700个宏定义，用来描述编译后代码的各个方面参数设置，其中有关于体系架构、编译器、链接库、头文件、版本、编解码器等等相关的宏定义。在这一 部分必须要修改关于平台差异方面的定义，比如必须把体系架构改成Android平台的ARMv5TE，这时文件编译的时候指令集就会选择ARM的指令集而 不是X86的指令集。这两个文件很重要，以后很多文件都要include config.h这个文件，编译器会根据这个文件而选择性对代码进行编译。
　　2. 编译libavutil.a
　 　在libavutil建立一个Android.mk的文件，libavutil里的makefile文件需要调用subdir.mak，这个其实就是真 正的编译，但是书写在Android.mk下，这个make文件可以不要，但需要直接把对应的源文件引入，标准的makefile是指定.o目标文件，但 在Android.mk中需要直接指定.c源文件，Android.mk文件如下所示：

LOCAL_PATH := $(call my-dir)
　　include $(CLEAR_VARS)
　　 LOCAL_MODULE := avutil
　　LOCAL_SRC_FILES:=adler32.c \
　　…… \
　　 include $(BUILD_STATIC_LIBRARY)

　　编译时可能会出现很多错误，但这些问题归结起来大部分都是因为有些头文件没有引入而产生的问题，只要引入相应的头文件后就可以了。比如不识别某些文件的size_t关键字，在该文件include stdio.h后就不报错了，其他类似错误就不一一例举了。
　　其它模块按照相同的方法书写Android.mk文件，移植到Android平台最为本文中播放器的解码模块。
4 各层模块详解 
　　4.1数据获取层
　　该层完成主要功能为与流媒体服务器协商媒体信息细节，并根据协商结果从服务器端获取流媒体数据，将流媒体数据存入缓冲区，按照本文中缓冲策略将数据包发送给数据预处理层，其结构图如图2所示：
　　本文中该层一共启动五个线程，其中一个线程中启动TCP连接，用于RTSP会话协商，并且在RTP数据传输期间，该TCP连接必须一直保留。两个线程分别为接收音频和视频RTP数据的线程，另外两个线程分别为接收以及发送音频和视频的RTCP数据包。
　　4.2 数据预处理层
　　本层对本地文件的预处理完全依赖于FFmpeg提供的功能文件解封装功能，而流媒体文件的预处理需将一个或多个RTP 数据包整合在一起，这部分技术已经相对成熟，本文将不再复述。
　　本文中流媒体播放器区别于其他普通流媒体播放器的最大特点即为能对外部带有云台的摄像头进行控制，例如焦距、上、下、左、右等方面的设置。所以本文中使用PELCO-D协议作为云台控制协议。
　 　中第一字节为同步字也称起始符号，通常都是0xFF。该符号字节用来检测所采用的收发方式正确与否。第二字节填写为目标设备的地址，在命令字1字节中为 对摄像头光圈及焦距的控制。在命令字2字节为焦距及变倍控制，其中Bit4, Bit3, Bit2, Bitl为上下左右控制位，最后一个Bit0位总是0。数据1字节中，水平方向速度（00-3F）。数据2字节，垂直方向速度，其数值同数据字节1。校验 码字节为前六个字节之和。
　　本文设计的PELCO-D协议文本，最初默认情况下位命令字1、命令字2全部为0，数据字1和数据字2值为20H。通过上层发送的按键消息修改相应命令字1、命令字2的相应位。
　 　目前本文中流媒体播放器只提供以上六种控制功能，该模块根据上层出发的按键信息设置相应位为1，计算字节的值，形成七个字节文本发送至外部设备，当接收 到上层按键停止的消息后，统一发送 {0xff,0x01,0x00,0x00,0x00,0x00,0x01,}停止命令。
　　4.3 解码及显示层
　　解码层主要应用 FFmpeg移植到Android平台的代码作为播放器的解码模块，该部分代码支持包括avi、3gp、MPEG-4等90多种解码格式及文件格式，并且经过修剪优化后的FFmpeg代码效率和效能都得到了很大的提高。
　 　显示层本文主要应用开源的SDL函数库实现，SDL(Simple DirectMedia Layer)是一个跨平台的，免费的开源软件。该软件应用C语言开发，对外提供多种平台上图像、声音和其它输入设备的简单接口。经常用于游戏和其他多媒体 应用的开发，该开源软件可以运行于多种操作系统上，其中包括Linux、PSP、Windows、Mac OS X等。同时SDL还具有视频，音频，线程，定时器，事件等功能。

5 总结
　　本文介绍了基于Android平台的流媒体播放器的分层设计结构及其各层的详细设计，该播放器的解码库源自经过剪切优化的FFmpeg源代码，并且本文中的播放器提供了对外部摄像头的控制功能，是其应用范围更为广泛。
　　本文虽然完成了带有控制功能的流媒体播放器的原型功能实现，但还有很多例如 QoS、代码优化的问题需要进一步的研究。

本篇来自：http://yangguangfu.iteye.com/blog/712227

基于rtsp的手机视频点播实现和研究

前言： 随着3G的到来，带宽大了流量费便宜了，手机电视等多媒体应用必将有很大发展， 本人总结以往经验，跟大家讨论一下如何建立一个手机视频点播的方案，最后给出了一个初步的客户端实现效果。欢迎大家讨论。
先说架构，出于便于管理和扩展，带宽限制和多用户并发的考虑，商用方案都会采用流媒体服务器+WEB服务器+中转服务器+手机客户端的方案，其中流媒体服务器(streaming server)负责采集视频源并压缩编码并随时等待来自客户端的rtsp连接请求； 
WEB服务器(web server)便于发布和管理视频信息；
中转服务器(transmission server）是可选的，用于把来自client的RTSP请求转发给server,并把服务器端的实时流转给client，这样的好处是在相同带宽下支持更多的用户同时观看；
手机客户端(client)可以用手机内置的播放器（如nokia上的realplayer)或者自己开发的独立播放器，前者的好处是降低用户使用门槛，便于大规模应用；后者方便扩展和定制，满足更多的功能。
streaming server是整个方案的核心，目前主流的流媒体服务器解决方案如下：
helix  server :借助Real公司的强大实力，这是目前最流行的方案，  可以支持所有音视频格式，性能稳定，是唯一可以横跨 Windows Mac 及 Linux， Solaris ，HP/UX 使用者流媒体服务的平台，支持在手机自带播放器播放。helix server免费的版本只支持1M流量，企业版很贵。当然你要破解就是另外一回事了:)
darwin server: 这是apple公司推出的开源的流媒体解决方案，支持格式没helix那么多，但由于是开源的免费的，对于开发者有很大的开发空间。
live555 media server:性能稳定,但支持格式比较少(只有mp3,amr,aac,mpeg4 es等几种流)，很少独立使用而一般作为系统的一部分。
Windows Media Server：仅限微软平台，就不考虑了。
手机端框架流程如下：
 

手机客户端与服务器端的传输协议目前有HTTP,RTSP两种，早期的手机电视多用的HTTP，HTTP的优点有不用特殊的服务器软件，有IIS即可，不 用考虑防火墙NAT，但HTTP不支持实时流，也会浪费带宽； RTSP则是当前流媒体传输的主流标准，连微软都抛弃了MMS而转而支持RTSP， RTSP可以支持客户端暂停回放停止等操作，基本不用考虑音视频同步问题（因为音频视频分别从不同RTP PORT读入缓冲）。值得说明的是，RTSP成功后，就开始RTP传输，分为RTP OVER TCP和RTP OVER UDP，前者保证每个数据包都能收到，如果没收到就重传，而且不用考虑防火墙NAT；后者只保证尽最大努力的传输，不会重传丢帧，实时性好，要解决防火墙 NAT问题。如果对帧率要求比较高的手机电视，推荐采用UDP传输，因为延迟较大的重传数据对用户是没有意义的，宁可丢弃。
我在网络部分采用强大的开源库live555实现RTSP/RTP协议，其性能稳定而且支持大多数音视频格式的传输。(当然ffmpeg也实现了网络传输 部分,经过改动后也能用）对live555经过裁剪后移植到symbian和windows mobile，这部分工作在symbian真机调试比较费时。
视频解码部分当然还是采用ffmpeg,移植了mpeg4 sp/h.264解码器，在没有任何优化的情况下可支持32K,CIF,5-10fps的效果，对于一般的流媒体应用足够了。以后还要经过算法和汇编优 化。解码后还需要经过yuv2rgb和scale，需要注意的是ffmpeg的解码有消隐区的说法，即qcif的图像其linesize不是176而是 192，如果你发现解码后图像呈绿色，需用img_convert()转一下(目的格式也是PIX_FMT_YUV420P)。symbian上用DSA 直接写屏就行。windows mobile上可以用sdl.
 音频解码主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge带宽支持的音频（aac效果比amrnb 好),AMRWB是3G后的音频格式。在ffmpeg 0.5 release中已经支持amrnb/wb的fixed point解码，很强大。
在symbian和windows mobile真机均测试通过，6122c真机和Windows mobile5.0模拟器上效果如下：
 

演示视频地址为rtsp://v.starv.tv/later.3gp，视频为mpeg4 sp,音频为amrwb。目前只能看到图像，音频还没加。
注意做流媒体应用接入点一般是cmnet，cmwap只用来浏览网页之类的低数据量应用。

本篇来自：http://yueguc.iteye.com/blog/832953

推荐一个：http://www.pandastream.com/，The powerful video encoding web service！