直播

直播卡顿原因详解及优化

随着视频直播的发展,很多直播团队可能会遇到视频直播卡顿,频繁出现缓冲标志或者直播画面一卡一卡等情况。究竟是哪些原因造成了视频直播观看的卡顿情况呢?

又拍直播云结合实践经验,从设备、视频流、网络这三方面进行解剖分析造成直播卡顿的问题及其解决方法。

视频直播卡顿原因

造成直播视频卡顿的原因主要有设备、视频流、网络这三方面的问题。

问题排查及解决方法

设备

高清视频往往会给硬件带来解码压力,由于解码造成的卡顿尤为明显。同时如果PC端Flash Player或移动端播放软件版本过低,可能也会造成解码问题导致播放卡顿情况。

如果是这个原因,解决方法有以下几点:

  • 升级硬件、软件设备,提高兼容性和容错率;
  • 使用硬编硬解方案,充分利用GPU 加速;
  • 降低视频码率,选择流畅或者标清画质进行视频播放;
  • 增大播放器缓冲区,缓解因网络或解码不稳定引起的卡顿。

视频流

音视频时间戳不同步

在直播中,当音视频时间戳不同时,会影响画面渲染,导致画面解析时出现问题,造成一卡一卡的现象,如下图所示,音视频时间戳非单调递增会导致播放器在解析画面时出现错乱的情况,前后画面衔接会出现不连续甚至花屏的现象。

△ 音画不同步

针对此类问题,我们需要对推流器的源码进行研究,把读取到的每一针音频、视频的时间戳进行查阅、分析,然后通过程序干涉推流器或者流媒体服务器,矫正逻辑值,从而使音画同步。

视频流参数配置问题

如果视频的帧率设置过低(帧率即每秒的画面张数),根据人眼的视觉暂留原理,每秒的画面张数必须达到一定的数值,人眼观看才是连续有效的。导致视频流的编码方式与传输服务器有不兼容的情况,部分音视频数据出现了解析错误甚至无法解析的情况,也会出现视频流播放卡顿的问题。

如果是这个原因,解决方法有:

  • 设置合理的码率,帧率,分辨率,关键帧间隔,音视频编码格式等参数;
  • 尽量遵循标准的视频编码方案,流媒体传输协议,对视频流进行采集,编码,解码,播放等操作。

网络

直播网络目前存在三种情况:无线、有线、4G。

无线网络:WIFI 连接的直播受距离、环境等使用因素的影响,需要让设备尽量靠近 WIFI 信号源,避免穿墙或金属物遮挡,保持信号强度,带宽6M以上,同时避免其他设备接入 WIFI 信号源抢占信号;

有线网络:直播场地有专门的网口使用,最好是专线网络,上下行带宽不少于4M;

4G网络:手机网络受到周围的环境影响大,需要在手机信号良好的地方,并且防止网络波动,在直播时最好选择4G卡。

上传网络

当主播端网络较差时,会导致推流端上行不稳定,这个时候可以通过 speedtest 

CBR 与 VBR(固定码率与可变码率):哪个最适合您的在线直播视频平台

启动流媒体服务看起来很复杂,尤其是当您不熟悉为您的视频平台选择正确的编码器设置时。如果您是编码和流媒体领域的新手,那么广泛的选项会让您感到困惑,特别是 CBR 和 VBR 等术语。那么,什么是 CBR 和 VBR 编码?哪个更好——CBR 与 VBR?放松!喝杯咖啡,在接下来的几分钟内,您将得到所有问题的答案。

    

通过流混合改善音频/视频实时流体验

流混合是一种将多个音频或视频流组合到云上的一个流技术,广泛应用于直播、在线教育、音频室直播等场景。开发人员可以通过播放混合流来查看屏幕并听到聊天室中所有成员的声音,无需管理聊天室中的每个流。

 

流混合是一种将多个音频或视频流组合到云上的一个流技术,广泛应用于直播、在线教育、音频室直播等场景。开发人员可以通过播放混合流来查看屏幕并听到聊天室中所有成员的声音,无需管理聊天室中的每个流。

流混合的优势

流混合之所以广泛应用于音频和视频领域,是因为它可以给开发人员带来以下好处。

1. 低成本

在大型直播或在线教育场景中,如果多方在一个房间内共同主持,房间内的所有用户需要播放多条流。使用流混合技术,只需要播放一个流。即在双方托管的情况下,费用可减半。在多方托管的情况下,成本可以降低(n - 1)/n。如果使用审查机制(比如淫秽内容审核),成本也可以降低(n - 1) /n,因为只需要查看一个流的图像。

2. 简单的代码逻辑

当多个主机共同托管并使用流混合时,观众只需播放混合流并进行渲染,而不是播放和渲染多个流。

3.在不同平台之间轻松转发

如果没有流混合,我们无法在多方共同托管方案中将直播转发到 Facebook​、YouTube 和其他直播流平台。因为这些平台只有一个 RTMP 地址,我们无法将多个流转发到一个地址。

4. 移动客户端上的 Web 浏览器支持的多方共同托管

对于 iPhone 用户,Safari 浏览器不支持同时播放多个音频文件。当播放多个流时,就只能播放一个流,流混合可以解决这个问题。由于手机性能和浏览器性能的限制,手机上的大多数Web浏览器一般可以播放最多四个流。借助流混合技术,可以播放的最大流数会有很大的增加,并且无需额外的带宽和性能消耗。

什么是流混合

如下图所示,当一个聊天室中的多个用户发布流时,服务器会根据布局配置将两个流合并为一个流,这样观众就可以播放混合流查看用户 A 和用户 B 的屏幕。

流混合的实现

1. 流体混合工艺

a) …

    

前端使用tensorflow.js模型实现浏览器摄像头视频流人像识别,背景虚化&背景替换

背景

实习期间有个需求,需要前端调用算法模型,封装成npm包,供视频会议组去用,从而在视频会议中实现背景虚化,背景替换功能。后续可能会进一步加入一些好玩的功能,如面部特效(胡子,一字眉),头发颜色替换等。

实现效果应类似于下面这样

腾讯会议界面:

image-20210603181106629

为了给需求方演示,先采用google的TensorFlow.js的 BodyPix 模型做了一个小demo,先实现背景虚化和背景替换功能,模型的效果较为满意,显示画面流畅。

TensorFlow.js 是一个 JavaScript 库。 我们可以借助于它,来直接用 JavaScript 去创建新的机器学习模型和部署现有模型。对于前端人员入门机器学习十分友好。

TensorFlow.js 提供了很多开箱即用的预训练模型(见下图):
这里选用了图像处理类别里面的BodyPix模型

image-20210604145627620

这是BodyPix的官方演示demo https://storage.googleapis.co...

demo里的功能对我们的需求来说有些过于复杂,也没有背景替换功能。因此,我自己写了一个针对于背景虚化,背景替换场景的demo。

介绍

  • 思路: 在浏览器中打开摄像头,获取视频流图片,调用tensorflow.js的 body-pix 模型的方法,来绘制结果。 其中背景虚化比较容易实现,可直接用模型提供的drawBokehEffect方法;模型没有现成的背景替换的接口,用canvas的绘制方法对模型的toMask方法返回的遮罩对象
    

WebTransport 与 WebCodecs 初探

什么是WebTransport?

WebTransport 是WebRTC体系下的一套浏览器API,提供低延迟,client和server之间双向通信的能力。 核心的能力点包括:

  • WebTransport 提供基于QUIC 和 HTTP3实现的API, 自动获得QUIC和HTTP3本身的特性,比如应用层的拥塞,避免队头阻塞。
  • 双向通信的能力,多个传输通道复用一个连接的能力,能够很好的替代WebSocket。
  • 提供发送/接受不可靠UDP的能力,这个是浏览器一直欠缺的能力,

相关的规范如下:

  • WebTransport overview 这个规范介绍了WebTransport整体的情况,
  • WebTransport over QUIC 这个规范介绍WebTransport over QUIC的实现规范, 目前版本(M89)的WebTransport实现是基于QUIC的。
  • WebTransport over HTTP/3 这个规范介绍WebTransport over HTTP/3的实现规范,目前版本(M89)还没有实现这这部分。 按照官方的说法是,WebTransport 最终会完全基于HTTP/3 实现,并移除基于QUIC的实现,这个还需要进一步关注。

在浏览器中可以通过URL 来实例化一个WebTransport 实例,比如:

const url = quic-
            

使用OBS-Studio软件推流直播教程,支持RTMP及RTSP两种协议

一、基于RTMP协议的推流直播

首先需要手动搭建RTMP流服务器,搭建过程可以借鉴我的另外一篇文章 传送门 的第章节。
打开OBS软件,新建 场景->新建 来源

image.png

控件位置有个设置,选择服务,填写服务器串流密钥,点击确定

image.png

控件位置,点击开始推流,就OK了
接下来使用VLC软件进行测试下效果
输入网络URL,这块跟上图设置的一致

image.png

看看效果

image.png

搞定!!!

二、基于RTSP协议的推流直播

这个要稍微复杂一点,需要借助OBS的插件去实现该功能。软件地址附上:https://github.com/iamscottxu/obs-rtspserver/releases
另外,OBS还有很多插件,有兴趣的可以去深入学习,具体可以参考

            

34 | 如何使用Nginx搭建最简单的直播服务器?

在前面三篇文章中,我们介绍了传统直播系统架构、HLS 协议、RTMP 协议相关的知识,那今天我们就来具体实操一下,根据前面所学到的知识搭建出一套最简单的音视频直播系统。
今天我们要搭建的这套直播系统相较于《31 | 一对多直播系统 RTMP/HLS,你该选哪个?》一文中介绍的直播系统要简单得多。该系统不包括客户端、没有 CDN 分发,只包括最基本的推流、转发及拉流功能。虽然它简单了一点,但麻雀虽小五脏俱全,通过这样一个实战操作,我们就可以将前面讲解的理论与实际结合到一起了。
当然,作为一个直播系统来说,客户端是必不可少的。但由于时间和篇幅的原因,我们只能借助一些现成的或者开源的客户端对我们的直播系统进行测试了,所以客户端的界面可能会简陋一些。也正因为如此,我才没有将它们算作咱们这个直播实验平台之中。
实际上,我们完全可以以这个直播系统实验平台为原型,逐步地将一些功能添加进去,这样很快就可以构建出一套商业可用的传统直播系统了。

直播系统架构

在正式开始实战之前,我们先来简要介绍一下这个直播系统的架构,如下图所示:
最简单的直播系统
这个直播架构非常简单,由两部分组成,即媒体服务器客户端
媒体服务器有两个功能:
推流功能,可以让客户端通过 RTMP 协议将音视频流推送到媒体服务器上;
拉流功能,可以让客户端从媒体服务器上拉取 RTMP/HLS 流。
实际上,这个架构与我们前面介绍的传统直播架构相比是有变化的,减少了信令服务器,同时将 CDN 网络变成了一台流媒体服务器。但理解了整个直播架构的原理后,我们就可以快速地将这个简单的直播架构恢复成一个正式的、可商用的直播系统。
那对于我们这个简化的直播系统来说,如何实现架构中的媒体服务器呢?
这里我们使用了目前最流行的 Nginx 来实现它。之所以选用 Nginx 主要出于以下两方面的原因:
Nginx 的性能是很优越。在众多的
                

33 | FLV:适合录制的多媒体格式

虽然苹果拒绝使用 RTMP 协议并推出了自己的 HLS 技术,但大多数用户仍然还是使用 RTMP 协议作为传统直播系统的传输协议。在 Adobe 宣布不再对 RTMP 技术进行支持的情况下,仍然还有这么多用户在使用它,说明 RTMP 协议具有其他协议不可比拟的优势。
这里我们做个对比,你就知道 RTMP 协议的优势在哪里了。
首先,与 HLS 技术相比,RTMP 协议在传输时延上要比 HLS 小得多。主要原因在于 HLS 是基于切片(几秒钟视频的小文件)、然后缓存的技术,这种技术从原理上就比直接进行数据传输慢很多,事实也证明了这一点。
其次,相对于 RTP 协议,RTMP 底层是基于 TCP 协议的,所以它不用考虑数据丢包、乱序、网络抖动等问题,极大地减少了开发人员的工作量;而使用 RTP 协议,网络质量的保障都需要自己来完成。
最后,与现在越来越火的 WebRTC 技术相比,RTMP 也有它自己的优势。虽然在实时传输方面 WebRTC 甩 RTMP 技术几条街,但对于实时性要求并没有那么高的传统直播来说,RTMP
                

32 | HLS:实现一对多直播系统的必备协议

上一篇文章中 ,我们对 RTMP 协议和 HLS 协议的优势与劣势进行了比较。从比较的结果我们可以看出,RTMP 作为传统的直播传输技术在实时性方面要比 HLS 好很多,所以它还是有一定优势的。
不过,随着 Chrome 浏览器宣布不再对 Flash 插件提供支持、Adobe 公司停止对 RTMP 协议更新以及苹果公司声称 iOS 上不允许使用 RTMP 协议等一系列事件的发生,我们可以断定 RTMP 协议已失去了未来。
而 HLS 协议则恰恰相反,它在未来会有更广阔的应用前景。我们可以通过以下几点来得到这个结论:
HLS 是苹果开发的协议,苹果产品原生支持此协议;
HLS 是基于 HTTP 的,可以不受防火墙限制,所以它的连通性会更好;
HLS 还能根据客户的网络带宽情况进行自适应码率的调整,这对于很多用户来说是非常有吸引力的。
基于以上原因,我们有必要从 HLS 直播架构、FFmpeg 生成
                

31 | 一对多直播系统RTMP/HLS,你该选哪个?

近年来,随着智能手机的普及以及移动互联网的飞速发展,音视频技术在各个行业得到了广泛的应用。尤其是娱乐直播在前几年着实火了一把,像映客、斗鱼这类以展示才艺为主的直播产品非常受大家的欢迎。
从技术角度来讲,映客、斗鱼这类娱乐直播与在线教育、音视频会议直播有着非常大的区别。在线教育、音视频会议这类直播属于实时互动直播,主要考虑传输的实时性,因此一般使用 UDP 作为底层传输协议;而娱乐直播对实时性要求不高,更多关注的是画面的质量、音视频是否卡顿等问题,所以一般采用 TCP 作为传输协议。我们称前者为实时互动直播,后者为传统直播。
本专栏的前两个模块都是介绍实时互动直播的,而从今天开始我们会讲解传统直播技术。
传统直播技术使用的传输协议是 RTMP 和 HLS。其中,RTMP 是由 Adobe 公司开发的,虽然不是国际标准,但也算是工业标准,在 PC 占有很大的市场;而 HLS 是由苹果公司开发的,主要用在它的 iOS 平台,不过 Android 3 以后的平台也是默认支持 HLS 协议的。
接下来,我们先看一下传统音视频直播系统的基本架构,让你对传统直播架构的“内幕”有一个初步的了解。

传统直播基本架构

商业级直播系统的规模、结构是非常复杂的,除了最核心的音视频直播外,还包括用户管理、认证系统、直播间管理、打赏、红包、私信等很多功能,不过这些更多的是一些业务逻辑,在本文中我们不会对它们进行讲解,而是聚焦在最核心的音视频直播技术上。
我们先来看一下传统直播的基本架构图,如下图所示:
传统直播基本架构图
从图中可以看出,传统直播架构由直播客户端、信令服务器和 CDN