我之前有篇文章介绍过如果实现一个C/S模式的Flv点播系统,Flv格式简单,处理起来也比较轻松,不过,实际工作中,需要点播的影片,岂会只有Flv这一种格式。我们常见的几种视频格式,随便哪一个都要比Flv复杂的多,尤其是本身设计的时候就没有考虑到要通过网络观看的格式,要实现点播,自然要比Flv难的多。当然,你可以把所有影片都转成Flv格式来处理,可是,当你拥有成千上万部影片的时候,不但得一个个转换,还要一个个检查是否转换成功、转换质量如何等,那工作量可不是一点半点。从这点考虑出发,做一个支持多种视频格式的点播系统,就显得很有必要了。
可是,视频格式有很多,千差万别,有的格式里面,描述视频信息的字段一大堆,而有的格式里却几乎没什么描述的字段,这么个情况下,怎么能把它们揉合到一个系统中去呢?本人不才,做了这个尝试,目前已经支持AVI、TS、FLV、F4V格式在同一个点播系统中的播放和拖动,而且不存在拖动后花屏的现象。下面我介绍一下这个点播系统的设计方案和架构。
点播系统,最重要的考虑因素就是“拖动”的处理,关键点就是要在客户端播放器“拖动”进度条的时候,服务器给客户端返回以关键帧起始的视频流,否则,播放器很有可能会出现花屏,甚至无法播放的情况。用户不是神仙,看影片的人才不会去关注一个片子里哪些时间点是关键帧的位置,用户拖动进度条的位置,是非常随意的,而视频并非每一秒都是关键帧,所以,播放器必须要把拖动后进度条的位置,重新定位到离它关键帧之处(想想看,大家平时看片,都是这种体验吧)。
在点播系统中,播放器想要实现上面所说的定位关键帧的技术,就要知道影片的关键帧列表,可是“点播”嘛,视频在服务器上,是边下边看的,没法自己解析,只能让服务器告诉它。具体的获知方式,我觉得,可以设计成以下3种方案,这3中方案,针对AVI, TS, FLV等很多格式,都可以适用:
1. 每次拖动之后时,先发起一个请求,将拖动位置告诉服务器,由服务器返回最近关键帧对应的位置,然后播放器再以这个位置发起请求,服务器返回数据,播放。
2. 将方案1的两个请求合并为1个,服务器返回关键帧位置+数据,播放器播放。
3. 在开始点播一个视频之前,先发起一个请求,服务器返回所有关键帧的位置,拖动时,播放器先定位到关键帧位置,然后直接请求数据,播放。
这个系统中,我选择了方案三,原因就是处理简单~~
这里,以f4v文件为例。(其中,XVideoKFrame是视频格式解析程序,作用是读取AVI TS等视频,并生成关键帧列表。)
1. Client端
相对比较简单,当然,原因是我采用了libvlc作为播放器内核,vlc对于播放网络流的支持,恐怕是最好的,这省去了你自己写播放器的工作。libvlc的接口比较简单,我就直接上代码,大家一看就明白了。
私有成员变量:
操作libvlc进行播放的方法:
2. Server端
点播Server端,就是一个比较特殊的HttpServer,“特殊”主要是指在处理拖动的请求上。
XVideoKFrame,负责读取并分析输入的视频格式,然后Video.kframe文件,这里面包含了关键帧列表和其他媒体信息,是一个非常重要的程序/模块,点播系统的工作基础。在上面的处理逻辑图里面,我把视频解析这部分放在了单独的程序当中,主要是方便平时调试和增加格式解析的代码。当然也可以放到Server中,在视频文件第一次被访问时,生成.kframe文件。
目前,该解析器已经支持AVI格式解析、TS格式解析、FLV格式解析和F4V格式解析,正在写ASF格式解析,往后也还会增加。视频格式解析,是点播系统中工作量最大的部分之一,除了要读取数不清的字段,还要针对不同的编码,做不同的处理。例如TS格式,是不是H264编码,对于关键帧的查找方法是完全不一样的。我就不把所有格式的解析方法写出来了,将来有机会再写文章介绍这些格式。
最后,让大家看一下效果图,这个是点播ts文件的效果
haibindev.cnblogs.com,合作请联系QQ。(转载请注明作者和出处)