基于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解码，很强大。