设计并实现同时支持多种视频格式的流媒体点播系统

简介: 设计并实现同时支持多种视频格式的流媒体点播系统  我之前有篇文章介绍过如果实现一个C/S模式的Flv点播系统,Flv格式简单,处理起来也比较轻松,不过,实际工作中,需要点播的影片,岂会只有Flv这一种格式。

设计并实现同时支持多种视频格式的流媒体点播系统

  我之前有篇文章介绍过如果实现一个C/S模式的Flv点播系统,Flv格式简单,处理起来也比较轻松,不过,实际工作中,需要点播的影片,岂会只有Flv这一种格式。我们常见的几种视频格式,随便哪一个都要比Flv复杂的多,尤其是本身设计的时候就没有考虑到要通过网络观看的格式,要实现点播,自然要比Flv难的多。当然,你可以把所有影片都转成Flv格式来处理,可是,当你拥有成千上万部影片的时候,不但得一个个转换,还要一个个检查是否转换成功、转换质量如何等,那工作量可不是一点半点。从这点考虑出发,做一个支持多种视频格式的点播系统,就显得很有必要了。

  可是,视频格式有很多,千差万别,有的格式里面,描述视频信息的字段一大堆,而有的格式里却几乎没什么描述的字段,这么个情况下,怎么能把它们揉合到一个系统中去呢?本人不才,做了这个尝试,目前已经支持AVITSFLVF4V格式在同一个点播系统中的播放和拖动,而且不存在拖动后花屏的现象。下面我介绍一下这个点播系统的设计方案和架构。

 

一、设计方案

  点播系统,最重要的考虑因素就是“拖动”的处理,关键点就是要在客户端播放器“拖动”进度条的时候,服务器给客户端返回以关键帧起始的视频流,否则,播放器很有可能会出现花屏,甚至无法播放的情况。用户不是神仙,看影片的人才不会去关注一个片子里哪些时间点是关键帧的位置,用户拖动进度条的位置,是非常随意的,而视频并非每一秒都是关键帧,所以,播放器必须要把拖动后进度条的位置,重新定位到离它关键帧之处(想想看,大家平时看片,都是这种体验吧)。

  在点播系统中,播放器想要实现上面所说的定位关键帧的技术,就要知道影片的关键帧列表,可是“点播”嘛,视频在服务器上,是边下边看的,没法自己解析,只能让服务器告诉它。具体的获知方式,我觉得,可以设计成以下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文件的效果

    

 

相关文章
|
1月前
|
编解码 移动开发 流计算
【开源视频联动物联网平台】流媒体传输协议HLS,FLV的功能和特点
【开源视频联动物联网平台】流媒体传输协议HLS,FLV的功能和特点
34 2
|
7月前
|
Web App开发 数据采集 物联网
Android平台基于RTMP或RTSP的一对一音视频互动技术方案探讨
随着智能门禁等物联网产品的普及,越来越多的开发者对音视频互动体验提出了更高的要求。目前市面上大多一对一互动都是基于WebRTC,优点不再赘述,我们这里先说说可能需要面临的问题:WebRTC的服务器部署非常复杂,可以私有部署,但是非常复杂。传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量,难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景,行话说的好:从demo到实用,中间还差1万个WebRTC。
|
2月前
|
存储 缓存 编解码
C++ 音视频流媒体浅谈
C++ 音视频流媒体浅谈
C++ 音视频流媒体浅谈
|
9月前
设计并实现同时支持多种视频格式的流媒体点播系统
设计并实现同时支持多种视频格式的流媒体点播系统
118 0
|
4月前
|
编解码 缓存 安全
视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题
视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题
140 1
|
5月前
|
数据安全/隐私保护 流计算
如何成功地下载和播放DRM受限的M3U8流媒体
在今天的数字娱乐领域中,许多平台提供了高品质的流媒体服务,其中包括使用M3U8格式的视频内容。然而,某些流媒体平台使用DRM技术保护其内容,限制了用户在其他设备上进行下载和播放的能力。在本文中,我们将向您介绍一种成功下载和播放DRM受限的M3U8流媒体的方法。
|
7月前
|
开发工具 Android开发 开发者
Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)编码前数据接入类型总结
很多开发者在做Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)时,总感觉接口不够用,以大牛直播SDK为例 (Github) 我们来总结下,我们常规需要支持的编码前音视频数据有哪些类型:
|
7月前
|
编解码 网络协议 开发工具
跨平台低延迟的RTMP/RTSP直播播放器设计实现
2015年,当我们试图在市面上找一款专供直播播放使用的低延迟播放器,来配合测试我们的RTMP推送模块使用时,居然发现没有一款好用的,市面上的,如VLC或Vitamio,说白了都是基于FFMPEG,在点播这块支持格式很多,也非常优异,但是直播这块,特别是RTMP,延迟要几秒钟,对如纯音频、纯视频播放,快速启播、网络异常状态处理、集成复杂度等各方面,支持非常差,而且因为功能强大,bug很多,除了行业内资深的开发者能驾驭,好多开发者甚至连编译整体环境,都要耗费很大的精力。
254 0
|
7月前
|
缓存 监控 算法
开发个好的RTMP播放器到底难在哪里?RTMP播放器对标和考察指标
好多开发者提到,RTMP播放器,不知道有哪些对标和考察指标,以下大概聊聊我们的一点经验,感兴趣的,可以关注 github: 1. 低延迟:大多数RTMP的播放都面向直播场景,如果延迟过大,严重影响体验,所以,低延迟是衡量一个好的RTMP播放器非常重要的指标,目前大牛直播SDK的RTMP直播播放延迟比开源播放器更优异(大牛直播SDK延迟在1秒左右,开源播放器如VLC,延迟在5-7秒),而且长时间运行下,大牛直播SDK播放端不会造成延迟累积,开源或第三方播放器,长时间运行,容易产生延迟累积;
|
8月前
|
编解码 缓存 Linux
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
125 0

热门文章

最新文章