前言: 随着3G的到来,带宽大了流量费便宜了,手机电视等多媒体应用必将有很大发展, 本人总结以往经验,跟大家讨论一下如何建立一个手机视频点播的方案,最后给出了一个初步的客户端实现效果。欢迎大家讨论。 先说架构,出于便于管理和扩展,带宽限制和多用户并发的考虑,商用方案都会采用流媒体服务器+WEB服务器+中转服务器+手机客户端的方案,其中
流媒体服务器(streaming server)负责采集视频源并压缩编码并随时等待来自客户端的rtsp连接请求;
helix server :借助Real公司的强大实力,这是目前最流行的方案, 可以支持所有音视频格式,性能稳定,是唯一可以横跨 Windows Mac 及 Linux, Solaris ,HP/UX 使用者流媒体服务的平台,支持在手机自带播放器播放。helix server免费的版本只支持1M流量,企业版很贵。当然你要破解就是另外一回事了:)
手机客户端与服务器端的传输协议目前有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真机调试比较费时。
音频解码主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge带宽支持的音频(aac效果比amrnb好),AMRWB是3G后的音频格式。在ffmpeg 0.5 release中已经支持amrnb/wb的fixed point解码,很强大。
2010.05.15: 程序还在进一步完善, 目前在S60 3rd/5th上已支持手机浏览器+播放器,支持h264/mpeg4, aac/amrnb。 目前支持WM, SYMBIAN, MTK。
最新支持android平台, IOS平台。 详见http://linux.it.net.cn/e/server/ios/2014/1004/6169.html
|