直播+趋势下，如何打造低延时、安全流畅的直播技术方案原创

大家好，我是来自腾讯云的侯文珍，目前呢，主要是从事嗯腾讯云直播平台的一些开发工作，那今天呢，会结合我们工作中实际遇到的一些案例，跟大家介绍一下直播卡顿问题的一些实际的原因，以及它的优化解决方案。主要从这么几个方面给大家介绍，一是直播链监控，第二是卡顿质量指标，第三是卡顿原因分析，第四是推荐优化方案。啊，先从直播链路监控这里开始，我们先来简单介绍一下我们整个直播平台的一个链路。一般呢，我们的主播就会从那个推流端开始推流，通过手机直播或者是PC，或者是专业的一些视频设备，然后推出RTMP的流，然后推到我们的服务端，也就是云端，然后云端呢会进行一些智能处理啊，以及录制啊，转码等操作，然后通过CDN分发到全国或者是全球各地给观众进行观看啊，通过各种的一些手机或者是浏览器，电视等等进行。

观看，那么总结下来呢，简单来讲就是有推流端和云端以及观看端这么三块，那我们后面整个的一个介绍呢，可能都会围绕着这个三端来进行进行介绍。我们这是一个直播的一个过程，那我们再介绍一下，在我们直播的里面，怎么来监控一个直播的质量的一个好坏呢？一般情况下面业界常用的有QE和QS2种指标，QE呢是一种用户体验相关的，常常包括有观看时长啊，在线人数啊，以及完播率，评论卡顿数，还有GMV打赏等等一些指标，那这个呢，用户的主观感受比较多。还有一种呢，是有QS，就是一些客观一些的服务质量的，那这里呢，就有几个常用的指标，有卡顿，秒开，端到端延时，还有开播成功率，开播跳帧等等啊在这里面呢，卡顿可能是呃用户最为敏感的，因为这个一旦有卡了，可能对他的体验就会受损比较大。

那我们。今天呢，就重点介绍一下卡顿的一个质量的一个指标及优化情况，我们看看这个卡顿的一个质量的指标啊。啊，首先看一下卡顿那个现象，我们经常在观看直播或者是短视频长视频的过程中啊，就会出现有一些情况就是说卡了，那卡了它表现就是说可能视频正在加载中，或者是显示一个loading，再不就是画面卡住不动，那我们。怎么去描述这种现象呢？我们给他一个简单的定义，就是说在直播的播放过程中啊，因网络不稳，设备性能不足，直播流内容异常等等而导致的应视频播放不连续的现象，嗯。简单来讲就是我的音视频播放不连续了，那我们一般可能直观上认为音视频播放不连续，那就是我的可能我自己的网络不好，那下载视频啊，啊，下载不下来啊，所以就会出现卡顿了，那这个直观的感受，那我们看底层实际具体是。

具体从底层的基础上来看，是为什么出现卡顿呢？假设现在我有个。那随着我的本地流逝，时间的均匀的流逝，比上面的这个坐标轴就是从零到600毫秒均匀的这样流逝，那我现在呢，如果我在观看一个帧率是20FPS的一个呃视频，那这时候呢，按。正常的情况，我应该50毫秒就会收到一帧视频帧，那我这里用这个蓝色的柱子表示这是一个视频，然后绿色的呢，表示一个是音频，那如果是网络比较稳定，一切都很好，然后我的这个音视频的那个就会均匀的，呃，均匀的接收里面的时间戳也在均匀的往前进，但是假如说由于各种原因，网络或者是视频本身的原因，导致他数据里面的时间戳的那个速度小于我音视频的一个渲染速度，那可能这时候啊就会出现卡顿了。

也就是说播放器我没有数据可以继续的渲染播放，这时候呢，用户的画面就会出现暂停啊，或者是跳动这种情况。那在技术上我们如何进行统一呢？统计，要统计我们得先有一个卡顿的定义，我们把那个顺时卡顿的定义啊，一般常规的是这么说，就是播放器的缓冲区从有数据到无数据，我们把它记为一次卡顿，那连续无数据的时间呢，就会记作卡顿的时长，但是呢，在有一些临界的情况下面呢，我们会比如说我的人。的一个感官嘛，视觉残留啊等等，他可能对呃，几秒几毫秒甚至几十毫秒的一个卡顿不是那么的敏感，还有我本身我的音视频到达也有一个间隔，所以为了规避这种一个临界的情况下，我们一般会加一个buff，嗯，比如说连续卡顿时长超过一定的阈值，比如50毫秒的时候，这种卡顿它具有有效卡顿，然后呢，我们通过有效卡顿来衡量卡顿的一个严重情况。

有了卡顿的定义呢，我们看看具体有什么指标来统计这个卡顿的严重情况呢？啊，业界常用的指标的话，最主要是客户端的一个指标，客户端呢，大部分呢是基于音频来统计的，那基于音频呢，就是有一个百秒卡顿时长和百秒卡顿次数，那百秒卡顿时长呢，就是我把我所有的整个参与评价的所有的直播的一个观看行为呢，把它的所有的音频的一个卡顿时长加合起来，然后再除以它整个的一个观看时长的一个。乘以一个百分100，这样子呢，就把它规划成零到100的这个范围内了，把这个叫做百秒可能市场百秒可能次数也是类似的一个定义，那除了这些音频的呢，还有一些APP它做的比较好呢，可能它会有一些基于视频的一个卡顿。

比如说视频渲染版面卡顿，那他统计的卡顿就是关于视频帧的一个卡顿。是只看视频帧的一个呃缺失或者是渲染缺失的一个情况，那这时候它求和的一个视频渲染的一个卡顿时长，然后呢，处以一个呃整体的观看时长的一个价格，再乘以100啊。还有一个视频渲染白秒卡顿次数也是类似的一个定义啊，这是客户端的，那我们在服务端或者是云端呢，因为它没有客户端一个直观的一个卡顿的一个一一个指标，还有不能够精确的判断，所以呢，我们服务端会有一个慢速的一个指标，比如说接收慢速就是指五秒钟呢，接收到的音视频一个DS4秒。也就是说我五秒钟只接收了四秒的数据，那缺了一秒，那我们就认为很可能会产生卡顿，我把这个定义成一个慢速，那发送慢速也是类似的啊，发送慢速就是五秒钟内我发送缓冲器堆积的音视频大于一秒，有一秒没有发下去，那可能我认为客户端很可能会发生卡顿。

那这个一个慢速啊，我们。可能理解或者是观看的不是特别的直观，所以我们定义了一个流畅的一个指标，它就是五秒钟内接收到或者发送的音视频的DS值，然后我们把这个画出来。就可以看到它非常的直观，比如这是一个接收流畅度的一个曲线，蓝色这一条呢，就是我的本地流失时间，就是五秒均匀的一个流逝，那它然后呢，呃，绿色的这条曲线呢，就是一个我的视频的一个流入时间，也就是说我每五秒钟接收到的视频呢，呃，帧的第一帧跟最后一帧它的一个时间戳的一个差值，哎，如果我的一个视频还有网络都很好的话，那这个值应该基本上也是接近五秒。那如果要是出现比如说网络原因呢，出现我接收到的数据不及时，所以就会出现一个明显的一个一个下跌，哎，然后过一会儿网络恢复又把它传过来了，这个接收到的时间多就会上涨，所以就会有这种波动的一个曲线，这种呢就会非常的直观，通过这个抖动的情况，就可以很容易看到你的这个视频的一个稳定性，直播流到底。

嗯，质量怎么样。那这个五秒的这个间隔呢，我们可以根据实际的情况来进行调整。这个呢是我们的一些卡顿的一个监控的指标，那下面呢，我们就结合卡顿的指标来具体分析一下，我们这个卡顿它产生的原因有哪些，就是说卡顿产生在哪里，我把前面的那个架构图呢，就简单的画在这里，也就是推有推流端、云端以及播放端三个部分，那每一端的话都有自己的一些流程，比如说推流端有采集、编码、上传，那云端呢，可能有接收，还要进行音视频的处理，以及视频分发，播放端呢可能还要拉流啊，解码、渲染等等，实际上在每一个环节出现了异常，都有可能会导致这条直播流最终在观看的时候出现卡顿，那这么多问题，我们把它梳理一下。

用这个导图画出来的话，可能有这么几种常见的大类，首先还是推流端、云端和播放端这三大类，那在推流端来看呢，推流端一般就有设备本身的问题，还有网络问题，以及源流本身的问题，比如说设备问题，常常是由于我的推流设备性能不足，比如我设备比较老旧啊，CPU跟不上，所以说它就会比较卡。还有就是比如说我的网络问题，哎，常常有我常常遇到的，我的出口带宽限制，那我的带宽达不到我的这个推流码的一个要求，所以他可能会就会卡了，那还有就是比如说我推流端的接入网络异常，这个呢，常常是一些呃中小运营商或者是DNS异常的时候会出现跨运营商等等。那就会引起网络网络受限啊，还有一些源流本身的问题，比如说我的推流帧率过低，那如果你的帧率低于时帧以下，基本上观可能就会受到有卡顿，还有比如说我的这个的时间不是递增，或者有等等，在观看端的播放器的行为可能就会有有有等待，有回退，或者是甚至往前跳等等，就会有一个卡卡顿的一个现象。

那在云端这里也有各种，比如说编码异常，还有服务器的一个能，比如说C发中间链路抖动等等，这些呢，也有可能会产生卡顿，在播放端也是一样，有设备啊，有网络啊，有原理本身的问题等等这些问题，那这么多的问题。那可能大家就会想，我，我拿到一个卡顿的一个case，一个反馈，那到底这么多原因，我到底怎么找呢？我怎么定位这个卡顿呢？就我们大致推荐的一个卡顿的定位思，就是我呢，拿到问题我先来上来先判断一下到底是大面积的卡顿还是各地的卡顿，那我们有几个。方式来辅助我们进行判断，比如说我要看一下控制台，查看一下推流是否稳定。

右边那个截图呢，是腾讯云官网的一个控制台，可以查到每一条流的一个推流数据，比如这是这条流的一个推流的一个帧率，还有码率的情况啊，这里可以看到马力有些抖动，但这个没有关系，因为马力它会随着画面的一个变化，或者是你的那个码控的方式是C或者是A等等，它会有一些抖动，但是呢，我的一般情况下，如果没有问题，这个帧率都是应该是比较平稳的，所以我们可以根据帧率主要靠这个来进行判断。再一个呢，就是说我可以试一下在播放端带宽冲突的情况下是否流程，比如说我我知道我自己的网络是没问题的啊，我网络带宽很好，那我自己来一下这种看卡还是不卡，如果要是我的不卡，那可能就是说啊，至少证明他应该是推流端，或者是说CDN那里大。还有呢，如果有卡顿比较多，我们可以看一下是否有一些地区运营商设备一些版本的聚集，这些都可以辅助我们进行定位。

好，假设我们现在看到定位出来，或者是分析出来，认为它是有大面积的卡顿，那这个时候呢，我们再来看一下那推流端是否稳，就是结合右边的这个图来可以呃来辅助我们看到它推流端是不是稳定，那假如说我的推流比较稳，那就是大面积卡顿，那全长呢，可能是我们推荐你就降低一些码率来减少卡顿，比如说常规的直播呢，一般就采用一兆。一兆的码率加上15帧的一个帧率，或者是两兆码率加上30帧的帧率，这样子就差不多了，除非你有一些特殊的一些活动啊，或者是比较关键的一些需要高清的那种，可以码一些。但是的话。好。那假如说我的这个发现我的推流不稳，那我可能就要继续来进行分析，我的推流端以及流内容是不是正常了，那推流不稳呢，那可能原因啊就会比较多，那我们结合我们平时遇到的一些case，给大家一下常用的一些常见的一些场景，这是首先推流端的性能分析，这里看一下。

这个case呢，就是说我们接到一个反馈，说我的这个推流的不稳，然后导致观看的卡顿，那我们看到服务端接收到的这个帧确实抖动比较大，不是很稳，那我们经过跟客户进行沟通呢，他比如说反馈，嗯，用户是通过OBS的一个多推流的插件来进行推流，同时推了流出来。然后它刚好呢，每流它的这个带宽码率呢是三兆，所以说总共就需要12兆的一个出带宽，但是呢，用户实际测试下来，最终。它的网速的一个上传呢，只有11兆左右，所以刚好就达不到这个输出码力的一个要求，那这个问题就是网络受限了，那最终解决呢，可能也很简单，我如果要是把这关了其中一路整个的这个输出马力变成九兆，然后你看到它的帧率马力马上就变成恢复正常了。

啊，这是客户端推流的一个，呃，带宽受限的一个场景，那有的时候呢，我们甚至还会遇到通过服务端来进行推流，也会出现超过带宽上限的一个情况，这种话可能就会更难进行分析。比如说这是一个case呢，是我们也是从服务端看接收到的确实是帧率很不稳定，这个呢，也是经过各种的沟通呢，用户反馈他是推了三流，然后每流的码率呢都会比较大。那最终呢，我们经过呃，反复的沟通和定位，还是发现这个呢，它的这个通过云服务器，它的公网IP的一个出比较小，所以超过了它的这个网IP的这个出的上限，就是这个已经跑到分了至还有很多的丢弃的一些处理，那这个呢，肯定也会造成一个卡顿。

那这里呢，其实。这种在服务端定位是已经是比较困难的了，因为这个刚好它的这个服务器，云服务器是在腾讯云上面，所以我们才联合了那个云服务器，以及呃，公网网络那边的同事一起来进行定位，才发现了这个问题，因为这个如果从客户端看比较方便，但是从服务端如果他不是在腾讯云这边云服务啊，其实是很难进行定位出来的。那这里呢？想公网就是带宽上线，以及我公网IP的一个带宽上线，比如用户反馈他购买的时候，他可能显示的两核四上100兆的一个出口。但是呢，由于我们都知道我要出口他我需要绑定一公网IP，那在用户在反复的进行绑定这个公网IP调整的时候呢，它这个公网IP的出买云服务器的这个还有绑定IP上。

啊，这是一个推流端的一个公网IP的一个带宽上线的一个问题啊，除了这个带宽的限制呢，我们还会常常遇到的一些，更多的是有一些接入网络的一些异常，这时候呢，一般呢，我们会出现在一些中小运营商，或者是一些localo DNS设置有异常的一个问题，因为中转运营商呢，它是租借的三大运营商的一个出口，他有的时候为了自己的成本考虑，会在各个出口之间进行调度，那这个时候。就有可能会出现跨运营商的情况，比如我们这边反馈的一个case啊，这个用户他也是进行推流，然后推流，发现推流比较卡顿，后来我们发现还有跨运营商的接入，然后呢，用户看到认为自己的一个出口是北京移动的，但是我们看到呢，是北京电信的，这样子的话就会出现了一个跨运营商的情况，然后最终定位下来，发现用户是使用了一个X，一个推流软件，不是使用OS，那X这种可能在里面设置了，修改了ODNS，或者是有一些VPN等等的，就导致他跨运营的。

还有一些case呢，就是产出的中小运营商的，比如说这个用户他就很他就很有意思，就是说他每次推流的时候，过一段时间推流，他推流的时候，这个出口的IP都会不停的变化，然后那肯定到服务端接收的运营，运营商也会不断的进行变化，有的时候呢，在变化在他呃首次变化，他中间出口发生不一致的情况，那肯定就跨运营商就会导致这个。呃，卡顿的一个情况，那这里可能大家就有个疑问，就是说我怎么我出口的客I是什呢？

这里我们有一种推荐的方法，比如说你可以在腾讯云的这个云直播的控制台上面呢，就可以看到它的这个每一条流的一个推流的一个记录，那直播记录里面他介绍了这条流什么时候开始推，以及他的一个推流的客户端IP，这个客户端IP呢，实际上就是服务端从那个TP连接上面拿到的对端IP，所以这个它肯定是一个准确的一个这次推流的一个客户端IP。D这个系统呢，嗯，可以从浏览器直接打开，那手机和PT都可以，然后输入域名呢，就可以进行检测，检测到它常常能检测到几个关键的信息，就是自己的一个出口IP，还有一些DNS的一些信息，还有服务域名的一些探测的一个情况。

等这几个也是可以辅助我们进行那个本地网络的一个一个定位。啊，这是接入网络，接入网络的一些问题，除了这个呢，我们还常常会遇到一些源流本身的一些问题，这个源流本身的一些问题，主要是时间出发等等的一些，呃，不连续或者是帧率太低也会导致卡。比如这里有几个case，我们看一下，这个case就是说是我的采集帧率是15帧，但是发送帧率只有三到四帧。嗯，那这样子的话，他肯定会，呃，播放出来就会卡顿，因为它的帧率太低了。我们可以看到它这有一个客户端的一个日志里面就可以看到，前面呢，有一段时间客户端看到的他那个RTT就非常的大，然后呢，客户端为了R帧。还有一种就是说是我的这个推的帧率码率就会持续的进行波动，它很不稳定，这种呢，而且它的帧率很低，低于十帧，这种肯定也会造成卡顿，像这种case呢，一般我们就必须要结合客户端的日志来进行查看客户端当时推流的一个情况，以及CPU啊等等的一个占用率的一个情况。

啊，还有一些是留内容，它的一个时间戳不连续，就比如可能我看到我的这个帧率啊，挺稳的，码率也挺稳的，但是它的时间戳，哎，你仔细看下来就发现，嗯，它的时间戳就会反复的并行不连续进行跳变，比如这个我们的服务端用iPhone pro来进行查看的话，你看它从400哎，时间戳一直往下跳两百四啊，然后过一会儿呢，又忽然又跳大，然后又跳小，就是反复的这样的抖动，那这个时间戳的一个不连续，最终在播放端呢，播放器它也会很懵，他比如说我我播着播着又回退了，那可能我回退的就会把它给扔掉。那画面呢，就会就会停住了，那过会又会跳，那甚至可能会等，等一会，如果等不到，然后再往前跳，这时候呢，也会有各种的卡顿的一个现象。

啊，前面介绍了播推流端的几种一个情况的啊，推流端一般问题出现问题，它就会引起大面积的卡顿，那如果我按播放端呢，播放端我们要看的话，基本上都是一些个例的问题了，因为推，因为大面积问题，我们就往前面的那个推流端以及云端去查啊，那播放端的一些个例的卡顿呢，我们推荐的一些定位思哈，比如说我们先确认一下我设备的一个终端，一个性能如何，那这个呢，我们可以结合客户端的一个日志来看一下当时我的CPU啊等等的一些占用率情况。啊，还有呢，呃，我可以通过前面介绍的那个拼点滑图的那个功率，也可以播放端来进行查看是否进行跨网，Logo DNS是否正常等等啊还有就是我们可以测速，测一下己地的一个络速度情况，我们常会使用这工具来来测试，它可以很方便的看到我们的这个上传以及下载的速度如何。主要是下载的这个速度吧，然后还有就是客户I。

这是端的一个设备以及网络的问题，那播放端它可能也会有同样的有一些是流本身的问题，那对于一些有能力的一些用户呢，其实可以通过W是保。辅助我们进行定位，比如说有了这个文件以后，我们可以用f pro或者是一些F工具来查看它的一些文件的信息，比如说这个用f pro来查看这个文件的一个信息，你可以其实大家都可以看到它的一些啊，一些编码格式啊，或者它的分辨率啊，以及它的码率啊，帧率等等情况啊，最主要的是还可以看到它每一帧的一个DTS以及pts一个情况，可以看到它的DTS差值。等等啊，比如说你看他的视频啊，差值都是66，是不是均匀，有没有回啊等等，还有它的音频啊，大概都在23左右，如果这个就是视频，就是一个比较好的一个视频，那除了这个在Windows端的话也有一个。

等一些工具也可以辅助大家进行看，它也可以很方便看到那个每个视频帧频帧，甚至它的视频是不是关键帧等等，还有每帧的一个时间戳啊，这个都可以，呃，辅助大家去查看这个流本身是否有问题。说前面介绍了推流端，不放端，还有云端的有一些异常，但云端的有一些异常，简单介绍一下，比如说这有一个编界码的异常，比如说你新的一些编码格式还不支持，或者是有一些硬件编码，或者是等等一些，呃，编码出来的那个格式音视频不是特别的规范，可能云端就兼容不了，还有啊，或者是我的服务器性能出现瓶颈，比如我开始推了一个流比较真，呃，码都很低，忽然提高了一下这个马率，然后呢，呃，我的服务器有没有会及时的把这个任务给调度到一个资源充足的机器上面去啊等等这些问题，还有比如说我CD的分发的过程中。

可以往全国甚至全球走，外网进行分发的过程中，它如果外网的抖动也有可能会出现这个。呃，短暂的这个卡顿的一个情况，不过这些呢，嗯，大家呢，可能就不用太关注啊，一般情况下，如果用户他在排除了推流端和播放端的问题以后，如果是云端的问题呢，可以工进行核实来行解决。啊，前面我们其实介绍了很多的各种的一些呃，Case导致的一些卡顿的一个情况，那可能大家就会有一个想法，就是说这么多的问题呢，我在使用的时候如何规避呢？如何避免产生这么多的这这些问题，然后有没有什么好的一些使用的姿势呢？啊下面就给大家介绍一下我们常用的一些工具里面的一些，还有一些场景，他们的一些推荐的一个使用的一个方案吧。

个推流之前呢，我们可以进行它的一个输出的设置嘛，输出模式呢，就推荐就选高级了，然后关于这个编码器推荐大家就选叉六四的，就这个呢，其实就是我们的那个软件编码，因为软件编码它用性更好一些，如果你选硬件编码，它可能不同的硬件设备编出来的一个编啊，因的格式或者是内容有可能会有一些差异啊，还有就是我的这个码率控制一般没什么特殊要求，你选C就可以了，这样子他推出感觉是比较平稳的那个，那看着比较舒服。对于比，也就是我们的率率这里的话。没有特殊的要求的话，一兆到两兆应该就够了，如果你有特殊的比较非常高清的4K，或者是特殊的一些高清场景，可以来选一点。关于关键间隔，就是我们说的那个的那个大小啊，一般的一到四秒就好，尽量不要超过四秒，超过四秒可能会延迟啊等一些问题啊，兼容性啊，可能可能会有一些小啊，会觉得延迟比较大，那一般没有特殊要求个二就OK。

还有就是最重要的，我们的设的一个输出的一个分辨率，就输出分辨率，这里呢，一般的要求呢，选择720P或者1080P来来进行输出就可以了，还有就是我们的这个帧率FPS啊，一般不用超过30就可以来，如果是一些静态的，像PPT等等这种15帧都是够的，如果是呃特殊的一般其实不需要超过30秒30帧。还有就是如果我们选好了以后，在推理的过程中，大家其实可以实时的关注一下下面的这一个，呃。

嗯，状态条吧，状态栏它里面会显示一些很关键的一些信息，比如说丢帧有没有啊，比如说我的当前的CPU占用率怎么样，还有我的推出的一个帧率码率情况怎么样，当年是不是稳稳定的，如果OK，可能是一个绿绿色的一个，呃，状态栏，然后还有就是如果有条件的用户呢，其实可以打开本地录制，本地录制，录到本地，在后面遇到问题或者是说。复盘反馈的时候都可以进行对比啊，这个是辅助大家进行定位。DEMO可以装在手机上就可以直接进行推流了，然后呢，呃，当然也可以作为SDK嵌入到自己的APP里面，也是非常方便的。那这里我简单演示一下，比如说用摄像头推流，这个就直接把这个输入的一个推流地址，呃，输入进去以后，然后点击开始推流，其实就可以了，但是呢，对有条件的用户呢，就非常的建议大家，尤其是在定位问题的时候啊，把右下角的这个配置打开，然后开启调试日志，开启调试日志以后再进行推理，就可以看到非常详细的一个日志的一个信息啊，比如说它可以显示当前的一个CPU的一个情况，有的CPU啊，还有设备自。

哎，可以给大家绍一个S态信息，你看在左边的这个里面其实有一个。很关键的信息，比如说我一开始预设的推流马力是。三兆的也就3000K，那忽然呢，它就会提示，如果网络不行了啊，然会提示我的这个iner的这个upstam不推，然后呢，后面的话，他可能就会有一段时间持续的在2.5~2.9之间这样来回的波动，那这个呢，虽然推流端会自信降低码率，但是实际上面在服务端可能在它识别到码网络不足的情况下面，已经产生了一定程度的一个卡顿了，就结合服务端日志可以看到这里收到的帧率和码已经有一个降低了。

这是一个推流SDK的一个推荐的使用情况啊，还有一些用户啊，最近因为大家用腾讯会议开会比较多，有些场景呢，腾讯会议进行开会的时候，大家觉得不想让更多的观众进来，然后可能会呃，保持这个会议的一个稳定啊，但是同时呢，又想让大家很多人能够看到这个会议的直播，所以有的同学他可能就会议。耗费CPU，其实我们推荐采用腾讯会议自带的一个推流到直播的一个能力。

就可以直接推到呃云端来，比如说嗯，这里在会议的过程中，点开这个设置里面直接有一个直播的一个按钮，直播的时候呢，我们可以设置自己的一些主题或者是水印啊等等，然后就可以呃还可以设置自己的这个推流的目的，如果我采用官方的直播地址，那可能直接开始推流，然后用上面的这个官方直播地址就可以进行观看了。当然呢，我们也可以推到视频号或者是其他第三方的一个平台，假如推到第三方的平台呢，我们就可在自己在这里设置一个推流地址和推流密钥填上去，然后开始推流。

然后呢，我们通过这个如果是官方的推流的话，我们就可以从官方的这个地址就可以看到一个会议的一个实施的情况，这样的话是一个比较好的一个使用的方式吧。还有一些用户呢，他可能会在推流的时候，我们经常会说我的一个很重要的一个活动千万不能出问题，那我要验证一下我的推流端网络是不是OK的啊，我保证我的活动不能出问题，这时候呢，我怎么去避免因为local DNS产生的一些域名解或者跨网访问的这些问题呢？所以我们呢，可以推荐采用一个HTBDNS来获取地址，BNS呢，它有一个免费版，不过这个呢可呃，现在实际上已经不再推荐使用了，还商业的行。

开通就可以满足你的足够的使用的一个情况，假如我不想用这个ICPDNS的话，可能我就用。嗯，也有一些方式，比如说我可以在所有上搜一些DNS的工具，然后呢，他就可以获取到各个运营商的一个IP，比如说我拿这个地址把域名填进去，呃，解析到一些就近的一些电信联通移动啊，或者是腾讯的一些IP啊，进行分别进行验证一下。推I，这I能。啊，那对于这种我可以设置推流UR的时候呢，我直接拿到这个IP，把IP放在我们这个IP的推流协议里面，这开始的这个IP的地址就可以了，然后把域名呢放在参数里面，单上来就可以支持进行推流，那对于一些不能设置推流urr的一些情况呢，我们就可以尝试去修改我们的那个host文件来进行推流，Windows还有linus下面的一些设置文件的一个地址这里。

嗯，啊，这是一个关于网络的一个问题的一个规避，那除了这里呢，我们现在还有遇到非常多的用户呢，他有其实有向多个平台推流的一个需求，因为现在的直播平台非常多，嗯，那大家可能同时往多个平台进行推流，那同时往多个平台推流，那我们肯定最推荐的就是说是采用服务器推流，或者是采用多个设备推流，避免单设备的一个性能出现瓶颈。嗯，除了这个呢，我们还有一个就是非常嗯好用的，其实最最推荐大家使用的就是一个云端的一个转推的一个能力，比如说。嗯，这是一个腾讯的一个拉流转的个控制台的一个界面，其实呢，可以非常。方面呢，向多个平台进行转推，比如我要添加一个转推的一个任务，就可以点击，哎，创建任务就可以了，创建任务的话只需要填三个信息，那一个是时间，我这个任务的起始时间，一个是我的一个源流的一个地址，还有源流地址就是我推的先推一路流出来，推到一个平台，然后拿它的播放地址作为这个原流地址啊，第三个就是我目标地址，就是我要转到哪个地方去哪个平台去，把这三个地址一填，就可以非常方便的创建一个任务，而且呢，它还规避到你自己进行服务器转推啊，或者设备推流的各种不稳定的问题。

因为它是很方便的进行那个自动的进行等一个任务自动。这个源流的这里再多介绍一下，其实它其实很方便的，能支持直播的一个源流，也能支持它的那个是呃点播的一个源流，点播的源流的话，其实呃还能甚至支持多个点播文件进行同时进行推流，比如说我有三个点播文件，我要要求呃第一个播完以后自动播第二个，然后自动再播第三个，其实这个呢，用这个拉流转就可以非常平滑的实现嗯轮轮流播放的一个能力。

甚至在你的还可以设置主备员，就是我的主员，不管是直播和点播，当我的主员出现问题的时候呢，我还可以设置一个备员，那备员的话就自动的就是在主源异常的时候切到备源来进行使用，所以它的稳定性啊，或者是就会非常的高。使用A端的推流的一个能力。啊，这是一个向多个平台推流，我们还有一些情况就是越来越多的APP啊，都有PK和连麦的一个场景啊，这里呢，对于PK和连麦的使用场景呢，当然我们可以在APP端进行实现，比如APP端，嗯，可以自己进行把两个画面混合以后再推出推出来，但是这个呢，就是对APP端的一个性耗就较大，甚至还需同时推流流采集编码以及发送的这个性能消耗。

所以我们呢，有推荐采用云端连麦的一种方案，也可以非常方便的实现这种连麦或者P的情况，比如说这个左边的这个图啊，上面这个是正常的一个推流的一个情况，主播A进行推流，那观众B和C啊在进行正常的观看，那这个时候假如说有观众B要发起连麦，那可能观众B他就哎。把自己的流推到这个云端来，这个时候呢，主播就也同时会呃拉一路呃用户B的流拉到自己的画面，这样的A和B呢，两个人都可以看到自己的这个大小画面了，嗯，这时候呢，主播只需要再发送一个混流心应就可以了，也就是往云端发一个IDB请求，告诉云呢，我要把哪路两路流混起来，哎，这样子云呢马上就可以把这两路流混起来，向其他的观众C就可以，这一个以这个的话就可常方的这个需耗客户的，然后呢，我这里呢，有一个腾讯云的云直播的控制台上面也有一个很方便的连麦管理的一个快速上手的一个指引，可以按照这个指引12345就可以非常方便的实现一个，呃，在SDK集成一下就可以实现这个云端连的能力，通过发送这个API就可了。

这时候呢，就可以很容易实现我们的这种P，或者是连的一个效果。这是今天主要介绍的主要内容，今天主要就介绍这么多。谢谢大家。大家好。呃，我是来自腾讯云音视频的流媒体工程师付秋平。

今天我为大家带来的分享是流媒体源流常见问题与延迟分析处理。呃，今天的内容主要分为如下几个部分啊，一部分是我们简要介绍一下播放器的播放流程。第二部分是呃，我们介绍一下直播源流常见问题，结合一些常见的案例啊，我们进行一些啊分享。啊，第三部分是直播延迟的产生和处理。由这由这个延迟的产生与处理，我们再简要介绍一下第四部分外部RTC快直播。第一部分播放器播放流程。播放器的播放流程啊。基本上是推流的一个逆向的过程啊，我们的推流呢，基于同一个时钟源进行一个音频啊和视频的采集，得到一个音频的PCM。

啊，音频帧，然后视频的是视频帧，然后由于这个存在相应的。时空信息冗余啊，我们要需要进行一个编码，然后得到一个封装。啊，为了这个适应这一个网络传输，我们要按照流媒体的相关的标准协议，然后进行一个啊再次处理啊，得到一个输出流。那么这个播放呢，就是这个推流的一个反过来的一个过程，它由这个输入流经过一个解这个流媒体的一个协议，然后呢，经过一个解封装啊。得到一个音频，比如说我们常见的AC啊，得到一个视频，比如说我们常见的264265，然后再经过一个解码得到啊音频帧的这个PCM和视频帧的OV啊，最后呢，要经过一个音视频的一个时钟的一个同步。然后最后送到这个，呃，音视频设备，比如说外放。

耳机啊，视频帧进行一个相应的显示。其中解码音视频同步呢，是主要影响播放的重要环节啊，相应出问题也是比较多在这两个环节啊。在音视频同步这个策略方面呢，啊，主要有三种策略，一个是音频时间优先啊，视频时间优先，还有一个是外部时钟优先。啊，其中由于这个啊，我们的耳朵对这个音频呢，它更为敏感，所以通常音视频同步啊，默认都是音频时间优先的一个策略。随着这个啊浏览器的发展啊，现在H5外国的播放了，也逐渐占有一个相当大的组成部分。啊，H的呢。主要是有video标签，以及这个Ms SE API的一个相关支持啊，我们将这个多媒体的内容通过这个source buffer啊，放进去之后，浏览器经过这个。

视频以及音频的解码啊，最后送到这个音频设备和视频设备。H265的播放呢，目前浏览器还不是原生支持的，它需要这个WSM啊，也就是比如说将这个iPhone tag经过这个WS的一个编译，然后呢进行一个外置的支持。浏览器上的主要播放过程呢，与客户端的这个传统播放器基本上是一个类似的过程，只不过它增加了从v tag。比如说这个fo GS，它就是增加了一个f fo t到F mp4的一个转风扇过程啊，与此类似的，比如说啊Hs.gS它增加了一个TS到。FP4的一个封装过程。其中比较特殊的一点是，它的音频播放并不是完全依靠这个时间戳，而是这个内容的连续处理啊，当出现这个音频的pts跳变。

啊，或者是因为传输的原因导致了这个音频的丢帧的时候啊，需要进行一个额外的同步处理，否则呢，随着这个时间的推移，有可能导致因视频的不同步。第二部分是直播源流常见的一些问题啊，下面我们就一些直播源流常见的案例进行一些分享。播放单常见的一些问题啊，主要是集中在如下的几类啊，比如说啊。为什么我的流播放不了？为什么他播放声音？啊，为什么这个音画不同步或者画面不动啊，为什么这个延迟很高等等。啊，常见的原因啊有啊第一类，比如说与我们这个时间戳相关啊，时间戳与这个流畅度不理想。啊，比如说啊第一个例子。我们的客户反馈啊，这一个流它播起来之后啊，有有这个明显的硬化不同步。

我们使用这个f play去播放这个地址。或者将这个源流呢，经过w get或者是C另存为一个本地文件之后呢，使用这个f pro来分析它的一个啊音视频时间戳，可以看到这个因食品的这个时间戳的差距是非常大的。啊，总结一下就是这个啊，当这个音视频时间戳差距过大的时候呢，啊。播放器会有可能放弃这个音视频同步啊到它的，呃，直接原因就是原流的这个时间串，它的DTSPTS等这个复制是不理想的。啊，第二个案例是啊，直播的时候播放呢频繁卡顿，但是录制文件录制下来之后呢，播放的时候呢，还是比较流畅的，没有那个频繁卡顿的现象，只是他最后得到的这个时长是不够的。我们通过分析这一个源流的上行呢，它一个流畅度的一个曲线啊，发现它在上行呢啊。

单位时间，比如说五秒内啊正常啊。过来这个音视频的数据呢，实际上只有3.5秒的音视频数据。它这个媒体内容一直不足，会导致这个播放器啊，没有足够的数据缓冲。啊，引起直播会频繁卡顿啊，最后录制文件的这个时长是不足的。其原因呢，通常与网络带宽在受限的情况下呢，数据会产生积压啊，客户端的网络受限，然后没有合适的这个纠正策略的时候。容易导致。啊，常见原因的第二个呢，就是这个关键帧的它的一个间隔设置设置不太合理。啊，比如说啊，这里有一个现象是部分观众啊，他反馈这个牛的播放延迟很高，达到了这个八到九秒。我们去拉链播放这一个客户的留地址的时候呢，发现它初始下发的音视频的内容是比较多的，分析客户的源流呢，发现go关键帧的间隔有十秒左右的现象。

在过的时候呢。有可能引发这个CDN下的缓存过长。播放器的缓存过多的时候呢，容易延迟过大。第四个案例是啊，客户的原始流地址，它的播放是失败的，但是转码流可以正常播放。我们去分析这个。客户的播放文件，发现它是没有关键帧的。这个原因就是啊，部分编码器的设置的时候啊，Go不太合理。出现了全程只有一个关键帧的现象啊，造成直播无法正常观看。因为播放要从关键帧开始，但是转码流呢，经过了重新编码之后呢，它的关键帧。就可以了。所以这是啊，两个关键帧设置。有关的一个案例。

第三个原因就是音视频解码的关键信息啊，缺失或者是不匹配。啊，当视频解码关键信息缺失或者不匹配的时候，现象是比较明显的，主要表现为不能播放或者是花屏。当音频这个解码器信息缺失或者不匹配的时候呢，它的现象是比较隐蔽的。啊，比如现在啊，这里有一个案例五，就是播放的播放器没有声音，但是iPhone play播放正常是有声音的。客户反馈录制这个H文件失败。啊，我们使用这个Apple play播放客放客户的源流的时候，发现它没有显示出这个音频的profile啊，正常，如果。这个流播放正常的时候会显示出比如说LC啊。或者是原料中含有这个SBR和的时候，会显示出H1或者是h he VR的字样。啊，分析这个客户的原流日志的时候呢，发现缺少音频的解码信息啊。

这个原因就是客户推送的时候，他没有推送这个音频的解码头啊那啊。会导致这个播放器啊，有的人正常播放啊，有的是不行的。啊，第六个例子呢，就是啊。与客户的这个解码关键信息不匹配相关的。它的主要现象就是f play是播放正常的啊，VRC刚开始正常了，但是后面的这个延迟是越来越高了。客户的原有的音频内容实际是时间间隔是按照44.1K赫制啊进行了一个编码。但是它的解码信息传递给啊服务端的时候呢，只是为啊48K赫兹。当客户的推流的这个音视频解码信息不匹配的时候啊，也容易导致这个播放产生啊各种异常。

第四个常见的问题就是音视频的内容啊。比较特殊啊，存在一定的设备兼容性问题。啊，比如说有一个现象是其他的平台，比如说PC web安卓。啊，各个平台播放都是很正常，但是只有在iOS的上了，这个HS流播放不了。我们使用这个f play播放客户的源流时候，发现这个提示客户的源流使用的长编码。啊场编码主要用于传统的电视直播场景。消费类电子设备啊，如苹果手机iOS等系统啊。一般是不支持这个场编码播放，它会造成这个HR无法正常观看。其他在L上不能兼容的。还有比如说自定义的SEI啊，不符合这个标准的。苹果系统本身。对这个。留的内容的要求是比较严格的。啊，第四个案例与音频的内容有关啊。比如说现在这个现象是Apple play呢，VC啊等播放都非常正常，但是呢，部分的移动端是没有声音的啊，我们去分析客户的原有的时间戳啊帧率。

啊，各种解码信息都是正常的。啊，但是把这个音频的内容啊，通过WBCC这个工具去分析的时候发现的内容啊，相为是相反的。当采集编码的设备它的相位调试异常的时候，会造成音频的内容相位相反。当部分设备合并这个声道内容输出后，有可能会造成声音很弱。或者没有声音而升到独立输出的设备，比如说耳机啊。他就会表现正常。这主要是与项目相关有关的一个。啊，总结来说就是啊，原料常见的一些问题呢，要尽量避免以下的一些问题。一是尽量保持原流的时间戳啊，流程度正常啊。

第二是设置合理的源流构。啊，既不能过大也不能过小啊，和你的客户在一到四秒之间啊，第三是确保音视频的解码信息啊。发送到。服务端。第四呢，尽量避免使用一些啊特殊的。啊，编码啊，长编码，比如说非标准的SCI啊等等。啊，当然也可以寻求这个云上专家的帮助。我们常用的一些分析工具呢，主要有如下几类，第一部分呢是iPhone pack iPhone。Pro的一个套装，主要用来分析解码啊。时间等相关的一些内容。呃，第二部分呢，就是也可以使用这个any card。它可以辅助分析这个264牛里面的内容，比如说这一个。相关内容等等。啊，第三部分呢，啊，也可以使用刀啊。进行分析这个音频的内容啊，判断它是否有相位，相反，或者是这个音频没有能量啊，基本上处于静音状态等等。

下面是第三部分啊。这里简要分析一下直播延迟的一个产生与处理啊，也是上面常见问题中的其中一类很典型的问题。直播延迟产生的一个背景呢啊，主要是与从推流到云端到观众的整个环境有关。我们的推流端经过一个采集，然后啊预处理，比如说这个瘦脸啊，大眼大眼美颜等等，然后再经过一个编码，然后。啊，推到云端进行一个接入，然后云端经过一个媒体的处理，比如说水印转码啊，最后经过一个CDN的分发与传输。最后在关注经过一个解码后处理，比如说挂件的特效。等等最后呢，播放出来。延迟主要是由数据堆积产生。

推流传输下行播放了啊。都有可能会产生这个数据堆积。也就都有可能产生延迟。实践中影响这个延迟的主要因素有如下几个方面啊，一部分是上行编码参数的这个选择。第二次视频。是啊，时间传输是否选择了交织，第三是链路传输线路相关的一个延迟，以及这个TCP可靠协议啊带来的延迟。呃，第四个是这个构的大小。第五个是下行播放的一个，对啊。抗抖动缓冲的一个处理能力。常见的协议延迟延迟了，比如说RTP。HTPV基本上可以做到。两到三秒钟之内。然后HS的延迟呢，大概在六到20秒左右，它主要依赖于这个构谱的大小啊，切片的大小以及这个切片的数目有关。

直播延迟的常见测量方式啊，第一种是端到端的一个播放对比。比如说在推流端啊。汇聚一个网页的一个时间，然后在播放端啊，这里是一个web IDC的播放啊，可以看到这个延迟大概在500毫秒以内啊，这端到端的一个啊。播放对比它需要有一个良好的低延迟播放器啊，如果现在手头没有的话。Play-FX no buffer也是一个勉强可用的选择。啊，第二个呢，就是在推流端中呢，插入自定义的S的内容啊，通过携带这个本地时间戳。经过进行一个粗略的估算啊，比如说发送端啊。将本地时间戳以一个阶层的形式放进这个SCI里面啊。播放端解析到这个Sai之后啊。或者获取本地的一个时间。然后与这个。中的这个时间进行一个比较啊，得到一个短短的电路延迟啊。

这个要求呢？两端之间的这个本地机器时钟呢，不能差异太大。影响延迟的主要因素之一呢啊，下面详细的分别介绍一下啊。第一就是推流端啊，如果是采用的软编的时候，X264的这样一个参数会影响到它的延迟，比如说我们常见的RC look ahead与这一个征集编码的线程数目，还有是否使用逼帧，以及逼帧的这个数目。啊，比如说啊，随着这个pro的增加，Look ahead的这个默认值。啊，也从fast fast。Fast和medium啊分别啊由十变到20 30以及40，如果以啊常见的这个推流编码帧数，比如说15FBS为例，那么呢，会导致的延迟额外增加从600毫秒。

卡到1000啊，1300毫秒啊，最终会增加到比如说2.3秒之多。这个是由于啊，提高这个图像的质量以及编码速度呢，会导致一个额外的延迟。啊，第二个影响延迟的因素呢，就是说。啊，如果使用iPhone PA，它这个音视频的交织同步等待的时候也会导致额外的延迟，比如说视频的时间错误。T1T2T3与这个音频的识别出来。今年T1T2啊，它并不是完全一致的时候啊。存在一个缓冲区的一个重排啊。在这个缓冲区的等待过程中呢，也会产生一个额外的延迟。啊，影响延迟的其他因素有，第一是网络传输的本身呢，它存在一个实验的RDT啊。比如说拼这个lo的一个结果啊，我们可以看到它的。平均实验啊，大概在30~40之间啊。短的是几毫秒啊，但是在海外的时候呢，比如说它也可以啊，到这个100~200毫秒之间，那么这个延迟也是不容忽视的。

啊，第三个呢，就是啊，现在传统的推流直播主要基于这个TCP的可靠传输协议。啊，当它在这个艾可入网丢失的时候呢，容易造成这个岩石的扩大。啊，比如说客户端发送了一段数据之后。啊，等待这个服务器和一个。那么这个超时，比如说200毫秒还没收到，那么下一轮客户端会进行一个重试啊，但是这个。啊，如果下一次的艾克再次丢失，那么这次的超时时间有可能会扩大到400，那么整体这个累计的延时啊，会变得比较大啊，不可控。啊，影响延迟的第三个因素，也就是前面提到的啊，它的个股设置大小会影响这一个延迟。播放器在接入CDN的时候，CDN通常会从啊，最近或者年轻的去下发这个数据。

个的设置呢，会影响播放器接入初始发送的一个数据量。比如播放端连接到CDN节点的时候。比如说CDN的缓存目前有八秒。那么CN把这八秒发送给播放之后。就会产生这个初始，比如八秒的一个因子。啊，还有一个就是网络抖动呢，会导致这个缓冲的累积。当网络抖动呢，容易出现这个数据的波峰，波谷。播放器会出现这个数据累积越来越差。比如说在前单位时间五秒内啊。因为这个网络卡顿的原因啊，只来了两秒的内容，那么啊播放器有可能播完这两秒之后就会卡顿，卡住这里啊等后面的八秒内容来了之后呢，他又按照正常的节奏去，或者啊五秒的内容，那么就会产生这个额外的三秒延迟。啊，如果这个。延迟得不到有效的处理的话，那么随着这个时间的累积啊，抖动次数的变多啊，那它的这个延迟也会越来越长。

啊，降低延迟的一些可选方法啊。下面比如说呃，在我我们常用的这个OBS的推流软件里面呢，可以考虑设置这个。Latency啊，此时它的RC had啊，基本上为零，也没有征集编码的线程。走的是slash的线程，也没有使用逼帧啊，它的延迟是比较低的。第二个是呢，将这个构图设置在合理范围，比如说两秒CDN节点呢，下发的缓冲比较少啊。第三个呢，就是播放器啊，主动增加对帧的能力啊，主动去丢帧，或者是采用一些啊上touch这些库。去快速播放来降低一些延迟。啊，如果是H5的web播放器呢？呃，适当考虑控制这个play的属性，也可以有类似的效果。啊，当然是推荐使用一些成熟的播放器啊。

这里也可以考虑使用立方的SDK。第三个呢，就是第四个就是推流的播放接入呢，如果有条件呢，可以采用HPDNS去获取这个最佳的调度节点。避免local DNS的干扰。造成这一个选取的节点并不是最优，然后导致延时过长，网络不佳。啊，第四个呢，是可以考虑采用其他的商品协议啊，非TCP的，比如说SRT啊。跟这个推流。下面是OBS呢，常见的一些设置啊，以及比如说十立方的一些啊设置，可以通过设置不同的啊技术模式啊，流程模式来控制这个缓冲区域，以及这个最深的速度啊。啊，当然也可以配置CDN下的这个缓冲的大小啊，来优化这个延迟的选择。第四部分呢，我们简要介绍一下这个外部RTC的快直播。

啊，传统的直播延迟呢，它呃。经过一定的优化能够做到啊，比如说两秒到三秒啊。这种。算是不错了，如果想进一步的这个优化，延迟要做到这个毫秒的级别以内啊。完全放弃这个缓冲区，或者把这个缓冲区控制的特别小啊。那么很有可能会导致这个卡顿的上升。啊，但是快直播呢啊，是专门针对这个基于外部RTC的一个低延迟的技术，还是满足这样一些对延迟性能要求更高的一些特定场景需求。啊，比如说啊，适合于在线教育啊，体育赛事直播在线答题的。啊，它兼容了标准直播，包括推牛、转码、录制、截图、鉴黄、播放等全功能。支持客户呢，从现有的标准直播业务平滑迁移。客户可选的推流方式呢，既可以选用这个外部IDC接入，也可以使用传统的。

方式啊，基本上不修改用的习。然后在播放端呢，使用这个外部RDC来获得一个良好的低延迟以及卡顿的一个效果。那么。这个。快直播。到底是。做做了哪些内容，或者是具有什么样的优势啊，使得它在这个延迟降低的时候，卡顿率又上升了啊。主要是啊，普通直播呢，它是基于TCP的一个可靠的数据传输存在啊。艾可延迟确认入网数据积压等等。另外就是它的播放传输网络啊，这三部分是一个割裂的行为，对于缓存的这个调整呢，基本上没有联动。所以会造成它过于降低这个缓存的话，会造成卡顿上升。啊，但是web r TC的这个筷子波呢啊。

它第一是基于这个udp协议啊或加啊，实现在一个快速重传。第二是当这个比如说RTT啊，比较长的时候啊，我们可以考虑适当加了这个f fec的这个恢复机制啊。使得这个。数据包不需要经过重传啊，直接通过冗余的数据包啊，就可以进行恢复。啊，第三个呢，就是他。一个良好的带宽预测算法来动态调整这个g buffer，使得这个buffer更适应当前网络的一个状态。还有就是呢。啊，比如说在发送这个I帧的时候啊，会产生一个大的网络抖动，因为I帧相对比较大的啊，它通过一些配色机制，对这个I帧进行一些分片啊。传输啊，降低了这个网络带宽的一个压力啊，使得这个网络发送的更为平滑。第五个呢，就是对这个传输的媒体的优先级啊，进行一个区别处理。

比如说音频有些啊视频帧。逼真逼真啊。在这个网络带宽啊，有限的时候，可以考虑优先，比如说丢弃。没有参考的一些逼真。通过来降低这个。数据量，避免这个网络的压力。那么我们可以看一下这个快直播对比标准直播的一些结果。同样在推流端参数180P180乘720P的情况下，15FPS啊，1.8兆的。状态下。主播无网络。客户端设置不同的这个落网的一个对比结果啊，比如说在啊。丢包30%的时候，FV基本上帧率只有十帧，但是筷子包还有14帧，那丢包50%的时候呢，FV基本上只有两帧的。快速包还能保持一个13帧这样一个水平。整体整体对比来看呢，啊快直播在网络抗性以及延迟等方面都具有相当的优势。

所以呢啊，也推荐大家啊。有兴趣的可以考虑啊。去尝试一下会直播。啊，我今天的分享就到这里结束了。谢谢大家。今天我分享的内容主要包括四个部分，第一个部分是直播的安全体系，简单介绍一下直播场景中的安全风险和。保障。呃，直播的主要流程是主播通过一个推流的URL推流到腾讯云直播等云端平台上，云端根据客户需要对直播流进行转码处理，终端公观众通过拉有的URL进行播放。

的接。倒推就有可能会导致我们正常的主播在直播的时候被下线，或者是产生大量因为推流而产生的。的封禁台。在端，如果观的URL也是一定的拼，或者是通过者调试方。那就存在着被的果这链接被二次发或者一台引流产大量期的费用，从而导致我们平台的经济损失。

因此我们可以看到，如果没有任何的安全策略，对整个平台的正常运营带来很大的风险。播自己接地址带来的规则泄问题，从一定的角来讲，这也是一种安全的策。直播的内容和运营的策略也都很不一样，用一种方案来所有的场景需要实际的需要来。

呃，为了保证客户的直播安全，腾讯云直播从推流、内容、播放三个维度提供了丰富的安全机制，可以满足不同场景下的安全需求。一般情况下，在整个直播流程中播放，因为涉及到的链路、使用的设备。最为复杂，因此是整个直播安全方案中的重点。接下来，我将根据不同的业务场景，简单介绍如何使用腾讯的安全策略。保证播放安全。如果我们的直播不需要很高的安全性，只是想要简单的提高倒播的门槛，那推荐使用refer校验的方式。refer是HTTP协议中个字用R。使用这个功能很简单，只需要在腾讯直播控制，简单就可以成。

不过因为容易伪造。如果直播是面向固定的观众和设备，并且这些呃设备的IP已知的话，那么。比如说是作为原的情况，或者是明确的知道哪些IP不被允许播放的场景，那推荐使用IP黑白名单的方式来提高安全性。这个功能的配置也非常简单，只需要在腾讯云控制台打开开关。将允者允，I可以使用I。也可以实现不错的安全效果。但是一般情况下，播放端的公网IP是很难获取到的，并且经常变化，这种方式就会比较容易，比较难实施，因此只适合观众少，设备IP固定的场景。

在日常直播中，呃，更多的场景呢，是直播平台，希望直播内容可以被更多的观众观看，比如说游戏类啊，娱乐类的直播，那使用前两种方式就都不适合了，在这种场景下，我们推荐使用防盗链的方式来防止直播。呃，防盗链的原理是，呃，我们的业务端和云端约定一个统一的健全规则，业务端按照这个健全规则生成防盗链播放链接发给客户端，客户端通过这个播放链接播放时，云端会使用相同的规则对播放链接中的健全参数进行校验计算。只有校验成功才允许播放。在整个过程中，客户端是接触不到规则的，而且因为健全参数一般都是使用M的呃摘要算法计算出来，很难通过反推的方式计算出原始的呃健全T等关键信息。因此，终端用户自行破解生成播放链接的难度就会很大，从而提升了播放的安全性。

要生腾讯云的链播放链接，首先需要在控制台上打开功能。然后根据。面就可以，相比较于前两种方式，防盗链策略也非常容易配置使用，并且它的安全性相对来说比较高，可以满足多种直播场景，是我们直播中最广泛使用的安全策略之一。一般情况下，防盗链已经可以满足很多场景的需要，但是如果防盗链播放地址被泄露了，并且呢，这个播放地址还是在这个有效时间之内的，那这个地址还是可以播放的。啊，还是会有被盗播的风险，如果我们的直播场景需要保证呃播放链接即使被泄露也也能防止盗播，或者是呃希望可以添加一些自定义的健全规则，实现类似于筛选观众这样的功能，那么推荐使用呃防盗链加特窥验证的方式来实现啊，这种方式在播放时，云端除了呃防盗链健全之外呢，还会向客户配置的特根验证服务发起校验，只有校验通过了之后才允许播放。

比如说我们要啊配置这个，呃，一个播放链接一个用户只能播放一次，那么我们我们可以在自定义的特困信息里面带上这个用户的ID，然后在校验的时候呢，增加校验啊，一个用户在一个播放链接只能播放一次，这样就可以实现我们的目的，呃用使使用这样的方法呢，就可以呃达到即使播放链接不泄露，也能防止倒播的目的。但是，呃。以上的这几种方法呢，我们都是通过控制这个链接能不能被访问，能不能土数据来保证我们的直播安全，但是呃，这我们在整个链路的数据传输还都是明文的，明文在官网上传输，就仍然存在着被非法拷贝和传播的风险。

呃。如果是我们的直播场景是内部会议这种。内容比较机密的场景，那我们就需要更加安全的方案，在这种场景下，呃，我们推荐使用防盗链加特验证加HSAES12A128加密的方案。这个方案在主播推流成功之后呢，云端会自动会向业务的呃密钥管理系统KMS获取加密密钥，并使用加密密钥对音视频数据进行加密。当播放的时候，播放端从云端的CDN获取到的是加密的音视频，由是没有办法直接播放的。因此。需要终端向呃密钥管理系统申请解密密钥才可以播放。在这种情况下，即使有人可以成功的拉到流，但是因为它没有办法获取到解密密钥，依然是无法播放直播的内容的。呃，这就进一步的降低了我们直播内容被截取的风险。

不过这种方式呢，只支持hrs协议，呃，国内应用比较多的这个FLV协议是无法使用的。如果我们的直播场景里面需要使用的FV协议播，那么推荐使用呃，防盗链加资源第二的方案，这个方案打通了腾讯云直播和腾讯云的KMS，在推流成功之后呢，会自动到KMS获取到加密的密钥。并通过这个密钥对FLV数据进行加密。在播放端我们也提供了腾讯云直播的SDK，这个SDK呢会自动获取解密密钥。来进行解密播放。嗯，整个的方案呢，是由腾讯直播提供全的技术，跟H密方案相比，通过。既通过加密的方式保证了安全性啊，又使用了FLV协议来兼顾了延时。

通过防盗链的方式和在防盗链基础上的一些扩展方案。我们保证了直播流不会被轻易的到播盗链播放，又通过对数据进行加密，保证了数据在传输的过程中不会被轻易的获取到原始数据，但是这样真的已经啊完全安全了吗？啊，其实没有。为在的场景不进。到用户的电脑上来进行解密啊。正常情况下音视频的解密播放的流程啊，如这个图所示。呃，视频数据在解封装之后，需要使用到解密器进行解密，然后呢，对这些解密后的数据进行解码，变成视频的原始数据，在经过音视频同步后，最后来进行渲染播放。的。

那就仍然存在着通过调试工具、注入、立项等方式啊获取到原始加密密钥和音视频数据的风险。因此严格来说，呃，它是有一定的安全隐患的。因此应用范围有比较大的限制。而方案。的，呃，就没有类似的限制，通过可以做到卓iOS和端的覆是目前使用比较体里面来完成，而是引入了一个新的模块CM，通过这个CM模块来完成生成解解数据理过程。

CDM模块将所有涉及解密的操作都从应用。播放器中剥离，保证了解密数据都处在可控的环境中。C。解密是否需要？呃，硬件可执行环境，也就是T来分别的安全级别可以分为三个级别。分别是LL2和L3 L别解渲染。呃，芯片的TE中。LL2级别呢？它只是需要解密在T中完成，L1 L22个级别它都需要硬件的参与，因此都需要使用到方案认可的。

芯片啊。他的，呃。它的终端的要求会比较高，呃，L3级别呢？呃，相对于L1和L级别来说，它的安全性相对比较。呃，他的解密动作全部都在CDM软件模块中完成。但是这个方式呢，它不需要硬件的，非常适用在浏览器的浏览器等场景下面。啊，通过对L1 L2 L3的介绍，我们也可以发现，安全性越高，对终端设备的要求也就越高，啊性来说相对也会越差。如果需要放有版权的内容，或者是版权方有明确的DM的，那我们就推荐使用盗链加M方。目前腾。在这个方案中，腾讯云直播会与D提供商使用CPS协议交互来。

呃，传播啊，传递加密密钥。并且在此基础上对整个的直播数据进行加密，播放器播放时，从腾讯云拉到的数据是加密的音视频数据。播放器通过CDM向DM提供商请求播放许可。DM提供商可以根据呃配置。给不同的终端分发，包括包括不同的播放时间、许可证有效期等要求的播放许可。行业第二的方案，相对于其他的方案呢，实现了硬件系统的安全播放，拥有出色的安全性，但是也存在着实施复杂，全流程黑较多、金容性不佳等问题，因此一般只有在明确有版权要求的时候然才建议使用。对比以上的几种方案的安全性、实施复杂度，我们可以发现，随着安全性的提升，呃，实施的复杂度、成本都在增加，所以呢，一味的高呃，追求最高的安全性可能并不是最适合的方案。如果直播的场景需要有较高的安全性，又不想做太多复杂的配置。

那么最推荐使用的是呃，播放链加的方案，如果是应用在会议等场景下，需要数据安全传输啊，那推荐使用HS加密的方案。与播放相比呢？推流链更涉及到的主播的数量跟观众相比也要少得多，因此相对来说会更安全一些。啊腾讯云直播为推流也提供了呃不同的方案来保证安全性。首先啊腾讯直播提供了推流健全的方式来提高呃倒推的门槛，它的原理跟播放全是一致的，也是只需要在控制台上简单的配置就可使用。如果需要跟播放一样自定义这个健全规则啊，推流也同样提供了推流健全加特验证的方式来支持这种场景。

推流一般都是使用，因为视频绕来推流全，如果非常敏感的直播。需要全链路的加密传输，那也可以使用RTMPS协议来进行推流，目前腾讯云已经默认支持，如果只需要使用啊默认的推流域名，那么不需要更换端口，也不需要配置证书，只需要将呃。推流。地址的协议由RTP更换成RTPS就可以使用，如果需要使用到自定义的域名，那么只需要提供对应的域名和证书，通过工单的方式提供到腾讯云。在呃，实施完成了之后呢，可以使用。最后再简单介绍一下内容的安全。对于直播平台来说，呃，除了保证推流和播放的安全外，保证内容的合规也是呃直播平台能否稳定和持续运营的一个关键。

呃，随着业务的发展，主播越来越多，通过人工扫描去判断直播间是否合规，呃，肯定是无法满足呃直播呃直播平台发展的呃效率和成本需求的。在这种场景下，呃推荐使用腾讯直播的。截图功能，截图鉴黄功能。来进行呃，安全加固呃，通过在配控制台上配置好截图功能和相关的回调地址之后呢，如果直播间存在违规的风险，就会触发回调，嗯，业务方在收到回调之后呢，可以通过人工二次确认等方式。辨别这个直播间是否真的违规，在确认违规后呢，可以通过直播的进推功能来及时的封禁直播间，从而保证直播的安全。

而且虽然在现实的这个互联网中啊，没有100%安全的方案，也没有100%适合的方案。100%。呃，适用于所有场景的方案，但是呢，我们可以根据业务的实际需求啊，选择合适的安全方案。从而来保障我们直播业务的呃安全、稳定、可靠的运行。