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

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介: 设计并实现同时支持多种视频格式的流媒体点播系统

  我之前有篇文章介绍过如果实现一个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文件的效果

   

目录
相关文章
|
5月前
|
编解码 移动开发 流计算
【开源视频联动物联网平台】流媒体传输协议HLS,FLV的功能和特点
【开源视频联动物联网平台】流媒体传输协议HLS,FLV的功能和特点
93 2
|
5月前
|
编解码 缓存 安全
视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题
视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题视频点播这边在执行 HLS标准加密 转码后的视频,在解密播放上有些技术问题
191 1
|
11月前
|
数据安全/隐私保护 流计算
如何成功地下载和播放DRM受限的M3U8流媒体
在今天的数字娱乐领域中,许多平台提供了高品质的流媒体服务,其中包括使用M3U8格式的视频内容。然而,某些流媒体平台使用DRM技术保护其内容,限制了用户在其他设备上进行下载和播放的能力。在本文中,我们将向您介绍一种成功下载和播放DRM受限的M3U8流媒体的方法。
|
开发工具 Android开发 开发者
Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)编码前数据接入类型总结
很多开发者在做Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)时,总感觉接口不够用,以大牛直播SDK为例 (Github) 我们来总结下,我们常规需要支持的编码前音视频数据有哪些类型:
145 0
|
编解码 Android开发 开发者
Android平台GB28181设备接入模块如何实现实时视频和本地录像双码流编码
我们在做Android平台GB28181设备接入模块的时候,遇到这样的场景,比如执法记录仪或智慧工地等场景下,由于GB28181设备接入模块,注册到国标平台后,平时只是心跳保持,或还有实时位置订阅,查看视频的时候,是按需看,而且有时候,网络环境并不是太好,所以,催生了这样一个诉求:部分开发者希望能本地录像的时候,录制高分辨率(比如1920*1080),国标平台侧发起实时视频查看请求的时候,上传低分辨率(如1280*720)数据,有点类似于IPC的主码流和子码流。
|
编解码 网络协议 开发工具
跨平台低延迟的RTMP/RTSP直播播放器设计实现
2015年,当我们试图在市面上找一款专供直播播放使用的低延迟播放器,来配合测试我们的RTMP推送模块使用时,居然发现没有一款好用的,市面上的,如VLC或Vitamio,说白了都是基于FFMPEG,在点播这块支持格式很多,也非常优异,但是直播这块,特别是RTMP,延迟要几秒钟,对如纯音频、纯视频播放,快速启播、网络异常状态处理、集成复杂度等各方面,支持非常差,而且因为功能强大,bug很多,除了行业内资深的开发者能驾驭,好多开发者甚至连编译整体环境,都要耗费很大的精力。
325 0
|
缓存 监控 算法
开发个好的RTMP播放器到底难在哪里?RTMP播放器对标和考察指标
好多开发者提到,RTMP播放器,不知道有哪些对标和考察指标,以下大概聊聊我们的一点经验,感兴趣的,可以关注 github: 1. 低延迟:大多数RTMP的播放都面向直播场景,如果延迟过大,严重影响体验,所以,低延迟是衡量一个好的RTMP播放器非常重要的指标,目前大牛直播SDK的RTMP直播播放延迟比开源播放器更优异(大牛直播SDK延迟在1秒左右,开源播放器如VLC,延迟在5-7秒),而且长时间运行下,大牛直播SDK播放端不会造成延迟累积,开源或第三方播放器,长时间运行,容易产生延迟累积;
168 0
|
编解码 缓存 Linux
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
对话音视频牛哥:如何设计功能齐全的跨平台低延迟RTMP播放器
147 0
|
存储 网络协议 流计算
|
Web App开发 编解码 监控
网页播放海康威视大华华为摄像头RTSP流,不需转码转流,延迟毫秒级,支持多路播放、H.264/H.265及1080P/2K/4K,支持抓图录像字幕
在遍地都是摄像头的今天,往往需要在各种信息化、数字化、可视化B/S系统中集成实时视频流播放等功能,海康、大华、华为等厂家摄像头或录像机等设备一般也都遵循监控行业标准,支持国际标准的主流传输协议RTSP输出,而Chrome、Firefox、Edge等新一代浏览器从2015年开始取消了NPAPI插件技术支持导致不再支持RTSP的原生播放
700 0