直播流程以及常见问题
腾讯RTMP SDK支持哪些功能和协议?
腾讯视频云 RTMP SDK 支持推流、直播和点播三个功能：
- 推流支持RTMP发布协议，并包含硬件加速，美颜滤镜，带宽适应，清晰度调整等强大功能。
- 直播支持FLV协议和RTMP协议，推荐使用FLV，具有秒开优化，延迟自动控制技术以及适应性良好的硬件解码能力。
- 点播支持MP4\HLS\FLV文件在线点播服务，注意老版本SDK是只支持FLV点播的。
如何进行推流？
↙↓↘
主播开启直播的时候会通过RTMP协议向服务器发起推流请求，（推流的目的就是让其房间在首页的直播列表中显示出来）当请求成功后服务器同步的以RTMP的协议进行下发用户的播放器，异步的进行录制发送到点播后台，至用这样用户就可以进行观看直播了。当直播结束后，用户也可以通过请求点播后台进行观看直播回放。
如何进行拉流？
用户观看直播通过RTMP协议向服务器发起拉流请求，
当请求成功的时候服务器将观看的数据返回给用户播放器进行展示。
点播：
点播就是用户访问点播后台，点播后台将直播异步录制的视频文件反馈给用户。
点播是有进度条的，观看直播（拉流）是实时播放观看的。
RTMP协议：
实时消息传输协议，基于TCP，用来进行实时数据通信的网络协议，主要用来在播放器和服务器之间进行音视频的数据通信。
RTMP的三次变种：
RTMP工作在TCP之上的明文协议，使用端口1935；
RTMPT封装在Http请求之中，可穿越防火墙；
RTMPS类似于RTMPT，使用Https连接。
RTMP是目前主流的流媒体传输协议，广泛用于直播领域，现在市场上大多数采用的都是这个协议。
RTMP像是用来装数据包的这么一个容器，这里可以使AMF 格式的数据也可以是FLV中的音视频数据一个单一的连接可以是通过不同的通道传输多路网络流。这些通道包是按照固定大小包传输的。
直播连麦：
- 登录：LIveRoom单靠一个终端的组件无法独立运行，他依赖于一个后台服务为其实现房间的一个管理和状态协调这个后台我们称之为一个房间服务RoomService,想要这个房间服务就必须先登录。
获取房间列表
- 通过调用liveRoom的getRoomlist()可获取当前房间列表
- 主播开播：先调用LiveRoomde staretLocalpreView
接口开启本地的摄像头，该函数要传入一个View对象，用于显示摄像头的视频影像这期间LiveRoom会申请摄像头权限,同时主播可调整美颜和滤镜。之后调用CreateRooom接口，LiveRoom会在后台房间新建一个直播间，同时进入推流的一个模式。
观看直播：观众通过LiveRoom接口可以进入观看直播，enterRoom要传入一个View对象，用于显示音视频流，今日房间后，调用LiveRoom的getAudienList接口可获得 观众列表，这个列表不是全数据，最多显示30个观众
连麦：
第一步（观众）：通过RequestJoinPusher发起联盟，发起连麦请求
第二步（主播）：会收到onRevJoinPushRequest回调通知，之后UI提示主播连麦还是不连麦。
第三步（主播）可以选择acceptJoinPusher接受连麦
第四步（观众）获得ResquestJoinPusherCallback来了解主播是否接受你的连麦。
第五步（观众）如果连麦请求被接受，将会调用startLocalPreview开启本地摄像头，startLocalPreview需要一个view对象显示摄像头摄像此时SDK会申请本地摄像头和麦克风权限
第六步（观众）：调用JoinPusher函数来进入连麦（观众端始推流）
第七步（主播）：一旦观众进入连麦状态，主播就会收到通知。将连麦者的个人信息封装在PusherInfo的对象里通知出来。然后主播通过AddRemotview函数把连麦者远程影像显示出来。
第八步（观众）：如果该房间已经有一个连麦者，那么观众端会收到通知，也可通过addRemotview霸体其影响显示出来。
常见问题
如何实现秒开？
使用腾讯云音视频SDk+FLV协议即可实现秒开！！！
Http+FLV协议是目前最普遍的播放协议，他的数据格式非常简单，可以做到一点接到服务器就能获取音视频内容数据。相比之下，RTMP连接初期不可避免的几次“握手协商过程”，导致首帧方面更逊与FLV协议。
腾讯云音视频SDK
秒开的云端实现也非常简单，服务器始终缓存一组GOP画面（至少包括一个可以解码的关键帧）这样的一个特性，播放器一单链接服务器就可以获取到缓存的关键帧。进行解码和播放。
什么是CDN加速？
CDN即内容分发网络，其目的是通过现有的Internet中增加一层新的网络架构，将服务器的内容分发到更接近用户的节点使用户就近就能获取所需要的内容，从而提升用户的访问速度。
CDN加速原理：
CDN将服务器获取的内容缓存到网络边缘，然后当用户访问站点内容的时候通过DNS重定向到离用户最近的节点这种方式缩短了用户与内容之间的距离，从而达到加速的效果。
视频卡顿怎么办？
原因有三点：
1.帧率太低（如果主播端手机性能较差，或者有很占 CPU 的后台程序在运行，可能导致视频的帧率太低。正常情况下每秒 15FPS 以上的视频流才能保证观看的流畅度，如果 FPS 低于 10 帧，可以判定为帧率太低，这会导致全部观众的观看体验都很卡顿。）
2.上传阻塞：主播的手机在推流时会源源不断地产生音视频数据，但如果手机的上传网速太小，那么产生的音视频数据都会被堆积在主播的手机里传不出去，上传阻塞会导致全部观众的观看体验都很卡顿。
3.下行不佳
就是观众的下载带宽跟不上或者网络很波动，比如直播流的码率是 1Mbps 的，也就是每秒钟有 1M 比特的数据流要下载下来，但如果观众端的带宽不够，就会导致观众端体验非常卡顿。 下行不佳只会影响当前网络环境下的观众。
发现问题的“眼睛”
推流 SDK 提供了一种状态反馈机制，每隔 1-2 秒就会将内部各种状态参数反馈出来，我们可以通过注册TXLivePushListener监听器来获取这些状态。
帧率太低的 针对性优化方案
- 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 不盲目追高分辨率
过高的视频分辨率并不一定能带来清晰的画质：首先，较高的分辨率要配合较高的码率才能发挥效果，低码率高分辨的清晰度很多时候比不上高码率低分辨率。其次，像 1280720 这样的分辨率在平均 5 寸左右的手机屏幕上并不能看出优势，要像跟 960540 的分辨率拉开差距，只有在 PC 上全屏观看才能有明显的感官差异。但较高的分辨率会显著提升 SDK 的 CPU 使用率，因此常规情况下推荐使用 TXLivePush 的 setVideoQuality 设置 高清 档即可，盲目追高分辨率有可能达不到预期的目标。
- 3.3.4 适当使用硬件加速
现在的智能手机都支持硬件编码来降低视频编码对 CPU 的依赖，如果您发现您的 App 的 CPU 使用率过高，可以开启硬件编码来降低 CPU 使用率。TXLivePush 的 setVideoQuality 的高清档默认使用的是软件编码（硬件编码在部分 Android 手机上的编码效果不佳，马赛克感很强是个硬伤），如果要使用硬件编码，可以使用 TXLivePushConfig 的 enableHWAcceleration 选项开启。
上传阻塞的针对性优化方案：
- 4.2.1 主动提示主播
对于注重清晰度的场景下，通过合适的 UI 交互提示主播 “当前网络质量很糟糕，建议您拉近离路由器的距离，避免 WiFi 穿墙” 是最好的选择。
RTMP SDK 的推流功能文档中有涉及 事件处理 的介绍，您可以利用它来做到这一点，推荐的做法是：如果 App 在短时间内连续收到 RTMP SDK 的多个 PUSH_WARNING_NET_BUSY 事件，则提示主播网络关注一下当前网络质量，因为对于上行阻塞这种情况而言，主播本人是没办法通过视频的表现感知到的，只能通过观众的提醒或者 App 的提醒来了解。
- 4.2.2 合理的编码设置
档位 | 分辨率 | FPS | 码率 | 使用场景 |
标清 | 360*640 | 15 | 400kbps - 800kbps | 如果您比较关注带宽成本，推荐选择该档位，画质会偏模糊，但带宽费用较高清档要低 60%。 |
高清 （推荐） | 540*960 | 15 | 1200kbps | 如果您比较关注画质，推荐选择该档位，能确保绝大多数主流手机都能推出很清晰的画面。 |
超清 | 720*1280 | 15 | 1800kbps | 慎用：如果您的场景多是小屏观看不推荐使用，如果是大屏幕观看且主播网络质量很好可以考虑。 |
