PDF《常见问题》

常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第1 共23页 直播 常见问题 产品文档 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第2 共23页 【版权声明】 ?2013-2018 腾讯云版权所有 本文档著作权归腾讯云单独所有,未经腾讯云事先书面许可,任何主体不得以任何形式复制、修改、抄袭、传 播全部或部分本文档内 容.

【商标声明】 及其它腾讯云服务相关的商标均为腾讯云计算(北京)有限责任公司及其关联公司所有.本文档涉及的第三方 主体的商标,依法由权利 人所有. 【服务声明】 本文档意在向客户介绍腾讯云全部或部分产品、服务的当时的整体概况,部分产品、服务的内容可能有所调整 .您所购买的腾讯云产 品、服务的种类、服务标准等应由您与腾讯云之间的商业合同约定,除非双方另有约定 ,否则,腾讯云对本文档内容不做任何明示或模 式的承诺或保证. 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第3 共23页 文档目录 常见问题 直播基础知识 视频卡顿怎么办 如何实现秒开 如何降低延迟 为何推流不成功 为何直播看不了 如何实现好的画质 如何适配苹果 ATS 如何实现连麦功能 频道模式和直播码模式ID删除问题 禁播断流的区别 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第4 共23页1. 推流、直播 和 点播分别是什么? 推流:主播将本地视频源和音频源推送到腾讯视频云服务器,在有些场景中也被称为 RTMP 发布 . 直播:直播的视频源是实时生成的,有人推流直播才有意义,一旦主播停播,直播 URL 也就失效了,而且由于是实时直播,所以播 放器在播直播视频的时候是没有进度条的. 点播:点播的视频源是云端的一个文件,文件只要没有被提供方删除就随时可以播放(类似优酷土豆、爱奇艺和腾讯视频), 而且 由于整个视频都在服务器上,所以播放的时候是有进度条的. 2. 常见的直播协议有哪些? 目前常见的直播协议有三种:RTMP、 FLV 和HLS. RTMP:RTMP 协议比较全能,既可以用来推送又可以用来直播,其核心理念是将大块的视频帧和音频帧 剁碎 ,然后以小数据包的 形式在互联网上进行传输,而且支持加密,因此隐私性相对比较理想,但拆包组包的过程比较复杂,所以在海量并发时也容易出现一 些不可预期的稳定性问题. FLV:FLV 协议由 Adobe 公司主推,格式极其简单,只是在大块的视频帧和音视频头部加入一些标记头信息,由于这种极致的简 洁,在延迟表现和大规模并发方面都很成熟,唯一的不足就是在手机浏览器上的支持非常有限,但是用作手机端 App 直播协议却异 常合适. HLS:苹果推出的解决方案,将视频分成 5-10 秒的视频小分片,然后用 m3u8 索引表进行管理,由于客户端下载到的视频都是 5-

10 秒的完整数据,故视频的流畅性很好,但也同样引入了很大的延迟(HLS 的一般延迟在 10-30s 左右).相比于 FLV, HLS 在iPhone 和大部分 Android 手机浏览器上的支持非常给力,所以常用于 QQ 和微信朋友圈的 URL 分享. 3. 常见的点播协议有哪些? 目前常见的点播格式有三种:MP

4、HLS 和FLV. MP4:非常经典的文件格式,在移动终端和 PC 浏览器上的支持度都很好(在iOS 和大部分 Android 设备上,都可以使用系统浏览 器进行播放,在PC 上可以使用 Flash 控件进行播放),但是 MP4 的视频文件格式比较复杂,所以处理成本高,而且由于索引表复 杂度高,导致时长稍大(比如半小时)的MP4 文件在线播放时加载速度会很慢. HLS:苹果公司力推的标准,在移动终端的浏览器上的支持度较好,但IE 的支持情况依赖 Flash 的二次开发工作(建议使用腾讯视 频云的 Flash 播放器控件),其精简的 m3u8 的索引结构可以规避 MP4 的索引慢问题,如果是用于点播,是非常不错的选择. FLV:Adobe 公司所推的标准,目前直播平台最常用的封装格式,在PC 端有 Flash 的强力支持,但在移动终端只有 App 实现播放 器才有可能支持(或者使用本播放器),大部分手机端浏览器均不支持,目前腾讯视频云的直播录制,采用的就是 FLV 视频格式. 4. 常见的推流协议有哪些? 虽然 RTMP 在直播领域不是特别流行,但是在推流服务,也就是【主播】>

【服务器】这个方向上 RTMP 居于主导地位,目前国内的 视频云服务都是以 RTMP 为主要推流协议,由于腾讯视频云 SDK 第一个功能模块就是主播推流,所以也被称为是 RTMP SDK. 常见问题 直播基础知识 最近更新时间:2018-07-11 16:05:19 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第5 共23页5. 腾讯 RTMP SDK 支持哪些功能和协议? 腾讯视频云 RTMP SDK 支持推流、直播和点播三个功能: 推流:支持 RTMP 发布协议,并包含硬件加速、美颜滤镜、带宽适应、清晰度调整等强大功能. 直播:支持 FLV 协议和 RTMP 协议,推荐使用 FLV,具有秒开优化,延迟自动控制技术以及适应性良好的硬件解码能力. 点播:支持 MP4HLSFLV 文件在线点播服务,注意老版本 SDK 是只支持 FLV 点播的. 6. 直播需要网络视听许可证吗? 通过互联网向用户提供直播等音视频服务的应用程序,需要取得相关部门颁发的《信息网络传播视听节目许可证》. 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第6 共23页1. 为什么会卡顿 卡顿的原因无外乎三种情况: 原因 1:帧率太低 如果主播端手机性能较差,或者有很占 CPU 的后台程序在运行,可能导致视频的帧率太低.正常情况下每秒 15FPS 以上的视频流才 能保证观看的流畅度,如果 FPS 低于

10 帧,可以判定为帧率太低,这会导致全部观众的观看体验都很卡顿. 原因 2:上传阻塞 主播的手机在推流时会源源不断地产生音视频数据,但如果手机的上传网速太小,那么产生的音视频数据都会被堆积在主播的手机里 传不出去,上传阻塞会导致全部观众的观看体验都很卡顿. 国内运营商 提供的宽带上网套餐中,下载网速虽然已经达到了 10Mbps, 20Mbps 甚至是 100Mbps,但上传网速却还一直限制的 比较小,很多小城市的上行网速最快是 512Kbps(也就是每秒最多上传 64KB 的数据). Wi-Fi 上网 遵循 IEEE 802.11 规定的载波多路侦听和冲突避免标准,简言之就是一个 Wi-Fi 热点同时只能跟一个手机通讯,其它手 机在跟热点通讯前都要先探测或询问自己是否能够通讯,所以一个 Wi-Fi 热点使用的人越多就越慢.同时 Wi-Fi 信号受建筑墙体的 屏蔽干扰很严重,而一般的中国普通家庭很少在装修时考虑好 Wi-Fi 路由器和各个房间的信号衰减问题,可能主播本人也不清楚自己 做直播的房间离家里的路由器究竟穿了几堵墙. 原因 3:下行不佳 就是观众的下载带宽跟不上或者网络很波动,比如直播流的码率是 1Mbps 的,也就是每秒钟有 1M 比特的数据流要下载下来,但如 果观众端的带宽不够,就会导致观众端体验非常卡顿. 下行不佳只会影响当前网络环境下的观众. 2. 发现问题的 眼睛 推流 SDK 提供了一种状态反馈机制,每隔 1-2 秒就会将内部各种状态参数反馈出来,我们可以通过注册TXLivePushListener 监听器 来获取这些状态. 推流状态 含义说明 NET_STATUS_CPU_USAGE 当前进程的 CPU 使用率和本机总体的 CPU 使用率 NET_STATUS_VIDEO_FPS 当前视频帧率,也就是视频编码器每条生产了多少帧画面 NET_STATUS_NET_SPEED 当前的发送速度(单位:kbps) NET_STATUS_VIDEO_BITRATE 当前视频编码器输出的比特率,也就是编码器每秒生产了多少视频数据,单位: kbps NET_STATUS_AUDIO_BITRATE 当前音频编码器输出的比特率,也就是编码器每秒生产了多少音频数据,单位: kbps NET_STATUS_CACHE_SIZE 音视频数据堆积情况,这个数字超过个位数,即说明当前上行带宽不足以消费掉已经生产 的音视频数据 视频卡顿怎么办 最近更新时间:2018-06-11 14:58:08 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第7 共23页 推流状态 含义说明 NET_STATUS_CODEC_DROP_CNT 全局丢包次数,为了避免延迟持续恶性堆积,SDK 在数据积压超过警戒线以后会主动丢 包,丢包次数越多,说明网络问题越严重. NET_STATUS_SERVER_IP 连接的推流服务器的 IP,一般应该是离客户端跳数比较少的就近服务器 3. 帧率太低 3.1 帧率太低的评判 通过 TXLivePushListener 的VIDEO_FPS 的状态数据,我们可以获得当前推流的视频帧率.正常来说每秒 15FPS 以上的视频流才能保 证观看的流畅度,如果 FPS 在10 帧以下,观众就会明显的感到画面卡顿. 3.2 针对性优化方案 3.2.1 观察 CPU_USAGE 的大小 通过 TXLivePushListener 的CPU_USAGE 的状态数据,我们可以获得当前推流 SDK 的CPU 占用情况 和 当前系统的 CPU 占用情 况.如果当前系统的整体 CPU 使用率超过 80%,那么视频的采集和编码都会受到影响,无法正常发挥作用;

如果 CPU 使用率达到 100%,那么主播端本身就已经很卡,观众端要有流畅的观看体验显然是不可能的. 3.2.2 确认谁在消耗 CPU 一款直播 App 中使用 CPU 的不可能只有 RTMP SDK,弹幕、飘星、文本消息互动等都有可能会消耗一定的 CPU,这些都是不可避 免的.如果单纯要测试推流 SDK 的CPU 占用情况,可以使用我们的 简单版 DEMO 来观察和评估. 3.2.3 不盲目追高分辨率 过高的视频分辨率并不一定能带来清晰的画质:首先,较高的分辨率要配合较高的码率才能发挥效果,低码率高分辨的清晰度很多时 候比不上高码率低分辨率.其次,像1280 x

720 这样的分辨率在平均

5 寸左右的手机屏幕上并不能看出优势,要像跟

960 x

540 的 分辨率拉开差距,只有在 PC 上全屏观看才能有明显的感官差异.但较高的分辨率会显著提升 SDK 的CPU 使用率,因此常规情况下 推荐使用 TXLivePush 的setVideoQuality 设置 高清 档即可,盲目追高分辨率有可能达不到预期的目标. 3.3.4 适当使用硬件加速 现在的智能手机都支持硬件编码来降低视频编码对 CPU 的依赖,如果您发现您的 App 的CPU 使用率过高,可以开启硬件编码来降 低CPU 使用率.TXLivePush 的setVideoQuality 的高清档默认使用的是软件编码(硬件编码在部分 Android 手机上的编码效果不 佳,马赛克感很强是个硬伤),如果要使用硬件编码,可以使用 TXLivePushConfig 的enableHWAcceleration 选项开启. 4. 上传阻塞 据统计,视频云客户群 80% 以上的直播间卡顿问题,均是由于主播端上传阻塞所致. 4.1 上传阻塞的评判 4.1.1:BITRATE 与NET_SPEED 的关系 BITRATE( = VIDEO_BITRATE + AUDIO_BITRATE ) 指的是编码器每秒产生了多少音视频数据要推出去,NET_SPEED 指的是每秒钟 实际推出了多少数据,所以如果 BITRATE == NET_SPEED 的情况是常态,则推流质量会非常良好;

而如果 BITRATE >

= NET_SPEED 这种情况的持续时间比较长,推流质量就很难有什么保障. 4.1.2:CACHE_SIZE 和DROP_CNT 的数值 BITRATE >

= NET_SPEED 的情况一旦出现,编码器产生的音视频数据就会在主播的手机上积压起来,积压的严重程度以 CACHE_SIZE 这个状态值展示出来,如果 CACHE_SIZE 超过警戒线,SDK 会主动丢弃一些音视频数据,从而触发 DROP_CNT 的增 常见问题 产品文档 版权所有:腾讯云计算(北京)有限责任公司 第8 共23页长.下图所示就是一个典型的上行阻塞,途中 CACHE_SIZE 始终在红色警戒线以上,说明上行网络不足以满足数据的传输需求,也 就是上行阻塞严重: 注意: 您可以在【直播控制台】>

【质量监控】里看到类似上图的

图表. 4.2 针对性优化方案 4.2.1 主动提示主播 对于注重清晰度的场景下,通过合适的 UI 交互提示主播 当前网络质量很糟糕,建议您拉近离路由器的距离,避免 Wi-Fi 穿墙 是 最好的选择. RTMP SDK 的推流功能文档中有涉及 事件处理 的介绍,您可以利用它来做到这一点,推荐的做法是:如果 App 在短时间内连续收 到RTMP SDK 的多个 PUSH_WARNING_NET_BUSY 事件,则提示主播网络关注一下当前网络质量,因为对于上行阻塞这种情况 而言,主播本人是没办法通过视频的表现感知到的,只能通过观众的提醒或者 App 的提醒来了解. 4.2.2 合理的编码设置 如下是我们推荐的编码设置(适合美女秀场,更多信息请参考 如何实现更好的画质?),可以通过 TXLivePush 里的 setVideoQuality 接口进行相应档位的设置: 档位 分辨率 FPS 码率 使用场景 标清 360*640

15 400kbps - 800k................