从2016年10月(Chrome 54)开始,Chrome不再内置flash,而是改为用户第一次访问flash资源时提示安装。从Chrome62开始,不再提供“click to play的选项”,改为点击视频box后,左上方弹出
这意味着,flash作为过时的标准将被新技术所取代。
前言
从我们可以在网站上播放视频开始,到h5播放器们如火如荼地发展之前,使用flash一直都是web播放视频的不二之选。甚至于说得更加广泛一些,在html5成为主流之前,网站的多媒体能力,包括动画、游戏和视频一直都是adobe生态在掌控。那么随着html5标准的推出,这一切都成为了过去式。
flv与播方案
flv的全程是 Flash Video,顾名思义,就是专门给flash播放器提供的播放格式,这种格式具有结构简单、清晰的优点,最早出现是为了解决flash导出的swf文件体积过大,不适合在web中播放的问题。随着flash的逐渐淘汰,新的video标签自然是不支持flv格式的,人们开始把web视频的重点放在mp4或者hls上,但是随着直播这种视频形式的火热兴起,flv迎来了新一轮的生机。
我们来横向对比一下可用的直播方案:
flv播放实现·跳转·清晰度切换
可以看到,flv由于其编码格式的特点,只需要一个MetaData 以及音视频Track各自的Header就可以在任意的时间点播放,极大地符合实时直播的需求,在GOP足够小的情况下甚至可以达到0延迟,可以说在现有的技术方案里,http-flv是最理想的一个,正是因此,flv依然是web播放器不可或缺的一个格式支持。
首先我们通过一张图了解一下前端播放flv的过程
从上图可以看到,flv播放的过程其实是从flvt中提取元信息、音视频header以及数据,然后转码成fmp4盒子结构的过程,再通过MSE交给video的过程。因为flv的结构本身就是流式的,也就是说,它的数据被拆分到了很多个小的tag中,所以我们可以很方便地做数据的封装,也就是说将一段flv tag数据封装成一个独立的moof_mdat盒子对,然后就可以直接交给MSE处理,非常的方便。这里我们讨论flv是如何处理加载、跳转播放、重放及清晰度切换问题的
数据加载 数据加载直播和点播两种模式,首先来聊一下点播:针对点播的数据获取,我们采用Range这个参数作为分段加载的控制参数
如上图,Range这个参数向服务器描述了希望加载一个flv文件的 到 个字节 这段数据,相应的,服务器也需要能够根据Range参数正确返回这段数据。这里展示一个极简的服务端代码:
从上述代码可以看到,服务端是先是解析range,根据range切出文件分段,然后返回一个readableStream交给前端。
再看一下直播:直播跟点播是非常不一样的数据流动结构,我们看一下简单的直播流程
可以看到,直播的流程是一个 推流->服务端格式编码-> 终端播放 的一个流程。那么这里就带来了一个问题,我们不可以像点播时那样去加载数据了。因为服务端实际上保存的是一个文件流,不断有数据推到服务端,播放器也不存在缓存一段数据这样的情况,而是不断向服务器请求,只要有新的流到达服务端,播放器就要拿到这一段进行解码播放,达到推流和拉流同步进行的一个直播效果。为了实现这种效果,在播放器内,我们使用 fetch+ streamReader,简单的实现如下:
从上述代码我们可以看到,我们通过一个reader递归地从流里面读取数据,再将数据交给解码器进行处理。关于直播的数据加载还有更加先进的websocket方式,这里不再深入探讨,有兴趣的同学可以自行查阅相关资料。
播放时跳转 播放时点击进度条跳转(下称seek)是一个非常高频的操作,尤其是在长视频中。用户遇到不想看的部分,或者想重看的片段,都会点击进度条触发seek。举个例子,一段视频,可能用户实际观看的部分只占不到50%, 如果我们将整段视频加载,那剩下加载的50%就浪费掉了。所以我们要做的事情就是精确地加载用户希望播放的部分,节约流量。解决方法如下:
获取用户将要跳转到的时间点,下称seekTime根据seekTime计算出离该时间点最近的一帧的位置,称为 startPos以预加载时间为30s 为例, 计算出seekTime + 30s 这个时间点最近的帧位置 称为 endPos我们以 Range: startPos-endPos 为请求参数,向服务端请求这一段数据解码播放
这里说起来简单,但是涉及到了一个跟flv格式紧密相关的问题,那就是flv的onMetaData信息里是否具有keyframes这个属性。我们上述所提到的,基于时间点计算某一帧位置的算法,是完全依赖keyframes这个属性的,它记录了flv中所有关键帧的时间点和文件偏移量,keyframes大概长这个样子:
times中每一个时间点都对应着同位置的fileposition的偏移量,正是基于这一点,我们可以计算需要加载的数据Range。值得注意的一点是,并不是所有flv文件都携带了keyframes头,flv文件缺失部分onMetaData属性是很常见的事情。缺失了keyframes信息,我们就没办法做跳转了,因此我们需要借助额外的工具帮我们补全flv的onMetaData。这里推荐使用yamdi,一个轻量级的工具,有兴趣的同学可以看一下它的使用。
清晰度切换 清晰度切换是一个非常重要的功能,为什么重要呢,因为用户会根据网速的快慢,去选择更清晰或者更流畅的视频。假设没有这个选项,用户看视频卡顿了没法切换清晰度,就只能愤愤地关掉窗口了。那么多个清晰度的视频源我们如何做到无缝的切换呢?我们分情况来讨论一下:
点播中的清晰度切换方案 点播的切换清晰度是比较容易实现的,流程如下
如图,简而言之,就是尝试加载视频B,通过从视频B的onMetaData中提取关键帧信息,推算出当前应该加载哪一个关键帧,然后加载这个位置之后的数据,直到数据加载到之后,将视频B的数据交给MSE,同时,清除掉之前视频A在buffer中的缓存。
直播中的清晰度切换方案 直播清晰度切换目前还没有发现无缝的方案,因此建议在切换时,直接重建解码器以及MSE,关于这方面的问题我们还在探究。更多内容请关注我们的开源播放器
欢迎来我们github提issue (下方扩展链接)
标签: 我们
②文章观点仅代表原作者本人不代表本站立场,并不完全代表本站赞同其观点和对其真实性负责。
③文章版权归原作者所有,部分转载文章仅为传播更多信息、受益服务用户之目的,如信息标记有误,请联系站长修正。
④本站一律禁止以任何方式发布或转载任何违法违规的相关信息,如发现本站上有涉嫌侵权/违规及任何不妥的内容,请第一时间反馈。发送邮件到 88667178@qq.com,经核实立即修正或删除。