找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

熊猫TV直播H5播放器架构探索(3)

2018-6-28 08:00

接上文


注册、调用、销毁的流程会经常在工程化中被用到。那么在我们的Mccree Core中模块是如何被接入的?



首先初始化模块,接下来进行模块调用;这一步比较简单的是调用标准接口也就是Loader加载数据;最后在我不用的时候进行销毁。需要注意的是这里的Unload也是一个标准接口, Unload是promise,如果有人想比着这个东西去改FLVJS,可以把改掉,因为这个是个promise,泛指是个promise,其他的也都必须做成一个promise才能兼容这样的一个接口。



这是我们一个具体的数据传输方式。首先是向缓存中填充数据,再通过消息通道通知下一个模块获取数据;之后会给出获取数据的长度,否则下一块模块无法确定获取数据量;接下来收到这些消息后下一模块从缓存中提取数据。大家都知道FLV的视频Header等于13位,就是以上的一段代码,大家可以在开源库上看到这段代码,我就不再赘述了。


3.4 工程管理



这个较为复杂的流程本身会有一些工程管理上的麻烦:


1) 工程体积大,模块多

解决方案:多包管理系统

我们现在使用Lerna package管理系统,我想做前端的同学应该了解这是Babel的多包管理工具。


2) 参与开发复性工作多

解决方案:完整的开发套件

当你第一次布局这套环境时会发现需要一个个装所有的库,还要做Lerna Bootstrap的工作,参与开发复性工作多,如何改进?我们可以做一套完整的开发套件,将包括自动检测在内的全部工作做好。


3) 模块质量保证

解决方案:完整的测试用例、文档支持。

我们要求需要有一个完整的测试用例与文档支持,即使是上一个模块我们也会做A/B  Test和软切换。保证其模块的质量。


4. 技术创新与展望



关于这一点我想与大家分享一个简单的例子:P2P技术想必大家并不陌生。



上图是我们实际中接入一位合作方P2P的代码。如果需要我在外层去控制使用P2P该如何解决?



我们在P2PLoader层先写了一些如刚才提到的Loade还有URLsource这样的标准接口,再写了这一套代码;之后把P2P完整接入到我们的HTML5播放器。



我们花了半天工时写了一个模块与几行控制代码就可以将这样一个P2P技术完整接入到播放器中。 


4.1 WebVR



WebVR想必大家都了解一些。但现在距离产品化还有一段探索的路,故而一直没有推向市场。只需封装一个WebVR接口,也就是去做一个插件就可很快取代我们现有的纯MSE,很快就可以上线。


4.2 服务端应用接入



这应该是前端的同学比较熟悉的NodeJS。由于现在的框架包括大部分的模块和浏览器是不相关的,而唯一和浏览器相关的是部分Loader与基于浏览器的MSE。我们可以使用Node服务端运行提供音视频服务,将来需要去自建CDN时可以很轻易地将我们现在所做的包括解决音画不同步在内的一切优化都转接到一个边缘节点上。


Q&A


Q1.1:播放器刚启动时默认使用大码率还是小码率?


A:大码率


Q1.2:如果用户的网络环境比较差怎么办?


A:关于这一点我们有一个降级的解决方案。熊猫直播可切换三个清晰度,但默认是超清;用户上传多少码率,我就可以拉多少码率。比如说有P2P推一个8000kbps的码率,其用户可在超清链路上拉到8000,如果出现卡顿可切换到高清或更低的码流。


Q1.3:播放器是否会推荐给用户合适的码流?


A:这是一个业务层面需要解决的问题。我们在Loader里集成了一个实时监控的插件监控实时传输速率。基于保证沉浸且连续的用户体验与业务方的需求,我们不会默认在直播中向用户弹出推荐合适码流的提示框。


Q1.4:一般码流切换时播放器会缓存多长时间?


A:这个问题与我们的首屏优化有一定关系的,我预测今天会有很多人讲首屏优化。因为直播视频里是没有B帧的,不存在向后预测的帧,只存在向前预测的帧。我们进行首屏优化时,如果是在GOP比较长的情况下会在到下一个I帧前开始播放。我们只会给I帧缓存并且直接开始播放以实现秒开的效果,此时用户会看到直播画面闪一下。


当然在这个过程中需要切换码率, MOOV的Header需要改变,所以必须要清空之前MSE上所有的数据。


Q2:这些视频插件在Chrome、Safari、IE等平台上如何实现适配?


A:其实大部分国内的浏览器厂商使用的都是谷歌的Chromium内核解决方案,除此之外还有火狐、苹果的Safari、微软的Edge。Chrome与火狐已经支持了这些插件,而为什么我最后说Safari与Edge?因为这个问题的解决很大程度上取决于浏览器的市场覆盖率。但是这两个浏览器在Fetch Loader上存在问题,我们只能去加载HLS流。如果我的Remuxer不变,MSE控制插件也不变的情况下降级兼容HLS,只需要换一个Loader一个Master就可以解决。


Q3:关于解决音视频不同步问题的修正码插件,是集成在原生播放器中吗?


A:在Remaster中,暂时还没有提取出来。 FLV流拉过来时会给出一个PTS差值。当被检测到时我们就改动时间或重新输出数据包。

HTML5原生播放器支持MP4、WebM,不支持FLV,PC端也不支持HLS。我们会将数据进行拆包和分包再传输给浏览器以实现格式支持。


Q4:客户端会缓存多少?追赶策略是什么?


A:首先说一下几个不同拉流方式的差异:Fetch方式拉流时,因为是长链接所以是挨着拉。如果出现网络抖动,保持在比较卡的状态下拉流会和服务器端产生很大差距;但如果是网络抖动,后面的数据密度大,可与服务器保持一个相似的状态。这两种不同追帧方式,如果只是抖动,最后拉流多少就是多少。我们会监测实际播放时长和理论播放时长的差值,根据差值找最新的GOP里的I帧。如果有就不用重新拉流,如果没有则需要重新拉流。



来自: LiveVideoStack
文章点评
相关文章