新知第一期 01 卡顿问题优化原创

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

哎，可以给大家介绍一下，每一个是SDS调实状态信息，你看在左边的这个里面其实有一个。很关键的信息，比如说我一开始预设的推流马力是。三兆的也就3000K，那然呢，它就会提示，如果网络不行了啊，会提示我的这个in这个upstream不流就适点。

然后呢，后面的话，他可能就会有一段时间持续的在2.5~2.9之间这样来回的波动，那这个呢，虽然退休端会自信降低码率，但是实际上面在服务端可能在它识别到码网络不足的情况下面，已经产生了一定程度的一个卡顿了，结合服端可以看到这里收到的帧率和码已经有一个降低了。这是一个推流SDK的一个推荐的使用情况啊，还有一些用户啊，最近因为大家用腾讯会议开会比较多，那有些场景呢，腾讯会议进行开会的时候，大家觉得不想让更多的观众进来，然后可能会呃，保持这个会议的一个稳定啊，但是同时呢，又想让大家很多人能够看到这个会议的直播，所以有的同学他可能就会议。耗费CPU，其实我们推荐采用腾讯会议自带的一个推流到直播的一个能力。

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

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

开通就可以满足你的足够的使用的一个情况，假如我不想用这个IPDNS的话，可能我就用。嗯，也有些方式，比如说我可以在搜索上搜一些DNS的工具，然后呢，他就可以获取到各个运营商的一个IP，比如说我拿这个地址把域名填进去，解析到一些近的一些电信联通移动啊，或者是腾讯的一些IP啊，进行分别进行验证一下。推流时I推流呢？这I动能随I。啊，那对于这种我可以设置推流UR的时候呢，我直接拿到这个IP，把IP放在我们这个imp的推流协议里面，这开始的这个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令就可以了。

这时候呢，就可以很容易实现我们的这种PK，或者是连的一个效果。这是今天主要介绍的主要内容，今天主要就介绍这么多。谢谢大家。