返回
快速导航关闭
当前搜索
网站分类
栏目推荐
实用工具
热门标签
子分类:
直播培训网 >人货场 » 正文

一个新手怎么做直播,电脑直播画面卡顿是什么原因,以为 flv.js 直播超简单,结果被延迟和卡顿整傻了

人货场 更新时间: 发布时间: 人货场归档 最新发布 网站地图

之前在csdn上面看到一篇文章,叫《用一个 flv.js 播放监控的例子,带你深撅直播流技术》。这片文章的热度还不错,主要内容就是科普直播是什么,以及如何在浏览器中播放直播。

实现方法很简单,使用一个流行的第三方包 flv.js,即可快速播放直播。

在我们的项目中也使用这种方式,比如播放海康监控器的直播、教学直播等都可以正常播放。然而在产品成熟后,我们发现直播中有两个致命问题:

  1. 直播延迟,播越久延迟越高。

  2. 直播卡顿,无法判断什么时候卡顿。

解决上述两个问题是直播稳定性和可用性的关键,下面就来详解一下。

抗延迟关键 —— “追帧”

使用 flv.js 直播,需要一个 <video> 标签承载直播画面。默认情况下 video 标签用于播放点播(录制好的)视频,因此它会一边播放一边下载。

点播不要求实时性,暂停之后再继续播放,视频会接着暂停的画面继续播放;而如果是直播,暂停后继续播放时必须切换到最新的画面帧,这就是 “追帧” 的概念。

一图胜千言,不追帧的效果是这样的:


追帧的效果是这样的:


可以看到,设置追帧后的暂停重播,会立即切换到最新的画面。

在实际场景中,直播没有暂停按钮,但是常常会因为网络问题卡顿。如果卡顿恢复后视频没有追帧,就会导致直播延迟越来越高。

使用 mpegts.js 替代 flv.js

据传说,flv.js 的作者是一个高中毕业在 B 站上班的小伙子,月薪仅仅不到 5k。后来小伙离职去了日本,无法更新 flv.js,于是有了 mpegts.js。

目前 flv.js 已停止维护,mpegts.js 是其升级版,开发者是同一个人。涉及到追帧的高级功能,mpegts.js 支持的更好。在 flv.js 主页也可以看到推荐:


mpegts.js 的用法与 flv.js 基本一致,如下:


import mpegts from 'mpegts.js';let config = {};let player = mpegts.createPlayer(
  {    type: 'flv',
    isLive: true,
    url: 'http://xxxx.flv',
  },
  config,
);

mpegts.js 提供了自动追帧的配置项 liveBufferLatencyChasing,开启自动追帧方法如下:

let config = {  liveBufferLatencyChasing: true,};

置自动追帧后,虽然延迟问题解决了,但画面可能会更加卡顿。这里涉及到 IO 缓存的问题。

配置 IO 缓存,优化追帧卡顿

首先思考一个问题:直播的延迟越低越好吗?

从需求上讲,当然是越低越好;可从技术上讲,并不是越低越好。

直播是实时流,从远端拉流并实时解码播放,但这个过程极容易受到网络影响。不管是推流端或拉流端遇到了网路抖动,数据传输受阻,直播必然会卡顿,这个是正常现象。

怎么办呢?这个时候就要用到 IO 缓存,牺牲一点实时性,用延迟换取流畅。

假设播放器缓存了 1 秒的数据流,并将直播延迟 1 秒播放。当遇到网络抖动时,播放器会读取缓存数据继续播放,网络恢复后再向缓冲区追加数据,这样用户在看直播时,完全感受不到卡顿。

但如果网络异常时间超过 1 秒,缓冲区中的数据读取完毕,直播还是会卡住;如果加大缓存量,缓存了 3 秒的数据,这又会导致直播延迟过高。

所以,设置缓存可以有效解决追帧卡顿问题;若要在保证流畅的前提下,尽可能地降低延迟,则需要一个合理的缓存值。

mpegts.js 提供了
liveBufferLatencyMaxLatency 和
liveBufferLatencyMinRemain 两个配置项来控制缓存时间,分别表示最大缓存时间和最小缓存时间,单位为秒。

以下方配置为例,缓存时间设置越长、流畅性越好、延迟越高:

let config = {  liveBufferLatencyChasing: true, // 开启追帧  liveBufferLatencyMaxLatency: 0.9, // 最大缓存时间  liveBufferLatencyMinRemain: 0.2, // 最小缓存时间};

实际的缓存时间会根据网络情况动态变化,值的范围在上述两个配置项之间。

处理卡顿关键 —— “断流检测”

直播是实时流播放,任何一个环节出现异常,都会导致直播卡顿、出现黑屏等现象。这是因为实时拉取的流数据断开了,我们称之为“断流”。

多数情况下的断流都是网络原因导致,此时可能需要提醒用户“当前网络拥堵”、或者显示“直播加载中”的字样,告诉用户发生了什么。

而实现这些功能的前提,必须要知道流什么时候断开,我们就需要做“断流检测”。

mpegts.js 提供了几个内置事件来监听直播的状态,常用如下:

  • mpegts.Events.ERROR:出现异常事件。

  • mpegts.Events.LOADING_COMPLETE:流结束事件。

  • mpegts.Events.STATISTICS_INFO:流状态变化事件。

前两个事件分别会在出现异常和直播结束的时候触发,监听方法如下:

let player = mpegts.createPlayer({...})

player.on(mpegts.Events.ERROR, e=> {  console.log('发生异常')
});
player.on(mpegts.Events.LOADING_COMPLETE, (e) => {  console.log("直播已结束");
});

当未发生异常、且直播未结束的情况下,我们就需要监听直播卡顿。通过监听 STATISTICS_INFO 事件来实现。

首先科普一下:播放器在播放直播时需要实时解码,每一帧画面过来,就需要解码一次。当直播卡顿时,没有画面过来,解码也会暂停,因此可以通过已解码的帧数来判断是否卡顿。

STATISTICS_INFO 事件的回调函数参数中,有一个 decodedFrames 属性,正是表示当前已解码的帧数,我们来看一下:


player.on(mpegts.Events.STATISTICS_INFO, (e) => {  console.log("解码帧:"e.decodedFrames); // 已经解码的帧数
});

在直播过程中,上述回调函数会一直执行,打印结果如下:


可以看到,解码帧一直在递增,表示直播正常。当直播卡顿时,打印结果是这样的:


解码帧连续 9 次卡在了 904 这个值不变,这是因为直播卡顿了,没有画面需要解码。

所以,判断卡顿的方法是将上一次的解码帧与当前解码帧做对比,如果值一致则出现了卡顿。

当然轻微的卡顿不需要处理。我们可以将连续 N 次出现相同的解码帧视为一次卡顿,然后执行自己的业务逻辑。

当解码帧的值长时间没有变化时,我们可以视为推流已结束,此时可以主动结束直播。

结尾

如果有小伙伴在本文中遇到了疑问,欢迎加我微信 ruidoc 拉你进读者群交流咨询,或者关注我的公众号 江湖人称CV工程师 查看更多文章。



转载请注明:文章转载自 http://panaseima.com/
本文地址:http://panaseima.com/renhuochang/13304.html
考高分网交流群

扫一扫加入QQ交流群

和更多志同道合朋友一起交流,分享干货资料!
直播培训网客服

扫一扫加客服微信

有疑问请咨询直播培训网微信号,在线为您解答!
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 Copyright Your WebSite.Some Rights Reserved. Powered · 创奇学院

ICP备案号:浙ICP备2023008056号