直播问题排查方法

发表于 | 分类于
字数统计: 1,987字 | 阅读时长 ≈ 7分钟

[TOC]

好邻好课直播问题排查方法总结

前言

希望这个文档可以作为一个”种子”,随着之后在工作中遇到问题的不断增多，进一步完善，做到定位问题的”快准稳”。

非技术排错

  • 连麦没声音
  1. 手机硬件（尝试微信语音是否可以发消息） x
  2. 权限 (判断麦克风权限是否已打开) x
  3. 网络 （尝试4g和wifi下的运行效果是否一致）x
  4. 程序bug

​ 4.1 (引导用户退出房间再重新进入) x

  • 突来的卡顿

    通过影响范围判断：

    1. 主播端网络不好，直接影响到的是所有观众，因此，如果发现所有的观众都出现频繁卡顿，那么多半就是主播端的问题了
    2. 某个用户网络不好.

技术排错

存在角色

主播

  1. 主播设置的音视频参数
  2. 上行带宽
  3. wifi出现问题的情况下，建议尝试使用有线推流。

观众

  1. 选择的播放协议

主播/观众设备

  1. 硬件性能和编解码能力
  2. 双方网络的运营商，是否跨运营商连接或者二级运营商。

推流分辨率和带宽关系

如果设置的码率（带宽）过低，则无法保证传输的视频质量；
如果设置的码率（带宽）过高，则对网络带宽质量要求较高。
建议的对应关系如下：

分辨率和帧率 码率(带宽)
1280720@20fps 1280720@15fps 1280*720@10fps 1500 kbps 1300 kbps 1000 kbps
960540@20fps 960540@15fps 960*540@10fps 1100 kbps 900 kbps 700 kbps
640480@20fps 640480@15fps 640*480@10fps 800 kbps 700 kbps 500 kbps
640360@20fps 640360@15fps 640*360@10fps 700 kbps 600 kbps 400 kbps

人数限制

主播加入互动直播房间时需要使用推流地址进行直播，连麦者不需要使用推流和拉流地址，观众需要使用主播同一个频道下与其推流地址对应的拉流地址进行观看

  • 目前互动直播房间支持1个主播和最多4个连麦者（1+4）进行音视频连麦，聊天室支持的观众数没有限制
  • 目前互动直播房间支持最多13人(1主播+12连麦者)进行纯音频连麦互动
  • 对纯音频连麦者进行静音与非静音的操作，他们都仍然算在12个连麦者名额当中
  • 如果人数超出限制，需要当前连麦的用户先退出房间,然后再让择其进入

播放延时

影响因素

  1. 无法避免的网络延时计算。主播与观众的物理距离,用 200,000km/s(光在光纤中的传播速度) 计算往返延时。
  2. 网络抖动 。比如发送100个数据包,19号数据包不是紧跟着18号到达的,而是延迟到88后面才到达。
  3. 网络丢包。

影响原理

业务代码中的缓冲区

业务代码中的缓冲区，主要是推流端的缓冲区和播放端的缓冲区，一个 30 fps 的视频流，缓冲区每滞留 30 帧，延时就会增大 1s，那么，它们是怎么产生缓冲数据的呢 ？

  1. 推流端的数据「积累」
1
采集 -> 编码 -> 数据发送 -> [服务器] 当网络产生抖动的时候，「数据发送」会因此减慢，产生一定的阻塞，从而导致这些数据会被 「积累」在了推流端的发送缓冲区中。
  1. 播放端的数据「积累」
1
[服务器]-> 数据接收 -> 解码 -> 渲染 当网络产生抖动的时候，服务器的数据无法「及时」地传输到播放端，而由于 TCP 协议的可靠性，所有的数据都会被服务端积累起来，在网络恢复良好的时候，会快速传输到播放端，这些数据会被动地 「积累」在接收缓冲区中。
  1. 消除业务缓冲区的累计延时
1
2
3
推流端的发送缓冲区，可以在网络恢复良好的时候，快送发送出去，从而消除掉这个累计延时。

播放端的接收缓冲区，可以通过丢帧或者加速播放的方式快速消费掉缓冲区中的数据，从而消除累计延时。

连麦方式

  • 云信互动直播的连麦方式

    app_struct

    • 互动直播 = 互动 + 直播。

      互动部分 是使用的音视频功能，是UDP私有协议。

      音视频服务器将数据发送给互动直播服务器，进行画面合并，转为RTMP协议发送给直播服务器。

    • 普通观众：通过直播服务器以普通的标准的直播协议来拉流

    • 主播和连麦者之间的音视频交互 都是音视频服务器处理的

      [ps:期间遇到过学生先加 老师后加入然后普通观众无法拉流的情况,就是因为服务器分配了不带互动直播能力的资源]

    ​

  • 其他现有的连麦方式

  1. RTMP 多路合流到CDN变成一路下发【cdn合成】
  2. 主播端与连麦者P2P,然后主播把合流推送到CDN上面再发送给观众。【主播端合成】
  • RTMP多路推到CDN,CDN再把这几路流都推给观众端【观众端合成】

直播功耗高

导致手机功耗高，发热严重的根本因素，无外乎就是一点：CPU/GPU 占用率高，那么有哪些因素会导致 CPU/GPU 占用率高

  1. 大量的格式转换
  2. 数据量太大视频的尺寸（例如：1280 x 720 的图像，明显要比 320 x 240 的图像处理起来费劲）视频的帧率（例如：每秒 30 帧，明显要比每秒 15 帧，处理起来费劲
  3. 对图像进行放大操作,图像的缩小或者剪裁，同样也会消耗一定的 CPU，只不过相比于图片放大要好点
  4. 软编/软解靠的是 CPU，非常耗性能，而硬编/硬解是使用专门的硬件编解码器模块，会显著降低 CPU 的负担，相对而言，会省电很多

其他

  1. 云信提供了一个辅助的网络情况测试工具 AVChatNetDetectType，它可以探测音视频通话网络的连通性、丢包率和延迟等信息,可以将这些信息上报给服务器。

  1. pc主播的网络检测。在浏览器中输入speedTest进行简单网络环境检测 。

  2. 观众使用的网络情况可以通过AVChatNetDetectType监测。

  3. 声音大小回调提示 ,可以通过AVChatStateObserver中的onReportSpeaker方法获得。

  4. 观众端可以通过ping播放域名的方式,查看当前网络丢包率是多少。

  5. 设备性能 带宽越高对解码要求越高，特别对720p和1080p。

    • 尽可能选择使用硬解，充分利用 GPU 加速
    • 如果有多种码流，尽可能在低端机上选择非高清码流
    • 增大缓冲区，有助于缓解解码不稳定带来的卡顿

  6. 云信提供了直播实时转码功能，支持不同分辨率、码率的拉流地址供客户自行选择

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
        //云信提供回调方法
        @Override
        public void onNetworkQuality(String s, int i, AVChatNetworkStats avChatNetworkStats) {
            if (i == 0 || i == 1) {
    //网络状态好的时候选择清晰度优先。 在此模式下会优先保证视频的清晰度, 网络不稳定时会优先降低帧率来保证视频的清晰度
                AVChatManager.getInstance().setVideoQualityStrategy(AVChatVideoQualityStrategy.PreferImageQuality);
            } else {
              //网络状态不好的时候选择流畅优先。 在此模式下会优先保证视频的流畅度, 网络不稳定是会优先降低视频分辨率来保证视频的流程度
                AVChatManager.getInstance().setVideoQualityStrategy(AVChatVideoQualityStrategy.PreferFrameRate);
            }
        }