七牛客户端负责人 卢俊 - 移动直播的关键技术优化

2020-02-27 117浏览

  • 1.移动直播的关键技术优化 卢 俊 @ 七⽜牛客户端负责⼈人 lujun@qiniu.com
  • 2.背景介绍 直播云 推流 SDK 连⻨麦 SDK 播放 SDK
  • 3.演讲⼤大纲 1. 直播的痛点介绍 2. 技术层⾯面的关键优化 - 秒开优化 - 卡顿优化 - 延时优化 - 清晰度优化 - 功耗优化 - 排障的优化 3. 直播部分⾼高级功能技术剖析 - 连⻨麦⽅方案 - 合流原理理 4. 总结
  • 4.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 5.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 6.直播 - ⾸首开慢 ⾸首开速度和⽤用户感受
  • 7.直播 - ⾸首开慢 - 优化 主播 流服务器器 观众 I PPP I PPP I PPP I… 服务器器 GOP 缓存 I PPP I PPP I PPP I… I PPP
  • 8.直播 - ⾸首开慢 - 优化rtmp://domain/xxxx.flv 播放器器 流服务器器 Step1 播放域名 -> 服务器器 IP 地址 提前完成解析，直接传⼊入 IP Step2 连接服务器器，发送播放请求 Step3 服务器器 -> 码流的媒体信息 Step4 播放器器接收媒体信息 -> parser ->init demuxer & decoder Step5 服务器器 -> ⾳音视频数据 Step6 播放器器接收数据 -> demux -> decode -> display 优化速度 ⾸首帧⽴立即解码渲染，不不缓冲
  • 9.直播 - ⾸首开慢 - 优化 # 提前完成域名 -> IP 解析 URL：rtmp://live.hkstv.hk.lxdns.com/live/hksrtmp://221.230.141.131/live/hks# 坑在哪 ？ CDN 服务商需要知道是 “谁” 在申请这个流 -> 计费，判断⽅方式：domain # 怎么解决 ？ RTMP 协议中，有⼀一个参数：tcUrl，记录的是完整的播放地址 修改播放器器底层 RTMP 代码模块，把含有 domain 的 URL 填写到 tcUrl 字段即可
  • 10.直播 - ⾸首开慢 - 优化 # 优化媒体信息解析速度 1. 基于 ffmpeg 的播放内核 - probesize - analyzeduration 减⼩小这两个值，可以明显加快⾸首开，但是 probesize 过⼩小，可能导致媒体信息解析错误 2. ⾃自研播放内核 - 应⽤用场景固定，只⽀支持和解析特定的协议和格式，缩⼩小解析范围
  • 11.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 12.直播 - 卡顿 Q：为什什么会卡顿 ？ 由于⼈人的视觉保持现象，要使观看者看到平滑的运动，帧率⾄至少要达到约 8 帧/秒， 要想让观察者完全感觉不不到闪烁，则⾄至少在 24帧/秒 以上。 A：播放的 “帧率太低” 或者 “帧率不不稳定” 带宽不不够 带宽不不稳 带宽不不够 带宽不不稳 ⼿手机 性能不不⾜足 客户端 服务器器 过载 服务器器
  • 13.客户端带宽不不⾜足 直播 - 卡顿 - 优化 主播 上⾏行行带宽 < 推流的码率 全局卡顿 动态码率 流服务器器 观众 下⾏行行带宽 < 推流的码率 个体卡顿 多码流切换
  • 14.客户端带宽不不⾜足 直播 - 卡顿 - 优化 动态码率 多码流切换
  • 15.客户端带宽不不稳 直播 - 卡顿 - 优化 主播 上⾏行行带宽不不稳 全局卡顿 发送缓冲区 流服务器器 观众 下⾏行行带宽不不稳 个体卡顿 播放缓冲区
  • 16.客户端性能不不⾜足 直播 - 卡顿 - 优化 主播 ⼿手机性能不不⾜足 流服务器器 全局卡顿 使⽤用硬编 & 减⼩小分辨率 & 降低帧率 观众 ⼿手机性能不不⾜足 个体卡顿 使⽤用硬解 & 多码率切换 & 主动丢帧
  • 17.服务端原因 直播 - 卡顿 - 优化 主播 流服务器器 观众 带宽不不⾜足/不不稳/服务过载 全局卡顿 质量量监控 & 线路路调整
  • 18.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 19.直播 - 延时 Q：延时来⾃自哪⾥里里 ？ A1：来⾃自从 “主播—观众” 的⽹网络物理理传输耗时吗 ？ 结论 1：物理理传输延时是 ms 级别，不不是直播延时的主要来源 ！
  • 20.直播 - 延时 Q：延时来⾃自哪⾥里里 ？ A2：来⾃自视频采集 -> 美颜特效 -> 编码的耗时吗？ 假设推流帧率：20～30 fps 每⼀一帧的处理理延时：33ms~50ms 结论 2：视频处理理延时是 ms 级别，也不不是直播延时的主要来源 ！
  • 21.Q：延时来⾃自哪⾥里里 ？ 直播 - 延时 假设推流帧率：20～30 fps 每缓冲 20~30 帧，延时增加：1s 直播的 GOP 通常设置的是 2～3s，因此服务端 GOP 缓存直接导致延时⾄至少 2～3s ！ 结论：延时主要来⾃自各业务代码中的缓冲区 ！
  • 22.直播 - 延时 - 优化 缓冲区 GOP 缓存 缓冲区 编码前，主动丢帧，减少延时 减⼩小 GOP ⼤大⼩小 解码后，主动丢帧，减少延时
  • 23.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 24.直播 - ⻢马赛克 - 优化 如何提⾼高画质 ？ 原则：减少送⼊入编码器器的数据量量，降低压缩⽐比，画⾯面 会更更清晰 类别 码率 帧率 GOP 画质级别 码控⽅方式 优 化 策 略略 提⾼高码率 降低帧率 增⼤大 GOP High > Main > Base Profile VBR > CBR 负 ⾯面 影 响 带宽压⼒力力变⼤大 流畅度下降 延时增⼤大 功耗/延时增⼤大 码控不不稳
  • 25.直播 - ⻢马赛克 - 优化 还有哪些优化⼿手段 ？ 1. 避免画⾯面从⼩小分辨率拉伸到⼤大分辨率的情况出现 2. 保障良好的光照条件
  • 26.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 27.直播 - 功耗⼤大 如何降低功耗 ？ 优化点 硬编 帧率 视频分辨率 画⾯面剪裁 格式转换 OpenGL ⾼高级特性 描述 尽可能地使⽤用系统硬编，功耗可以明显降低 降低帧率，可以减轻 “美颜”、“编码”、“传输” 的计算量量 拍摄分辨率不不⽤用太⾼高，合适就⾏行行，⽐比如 480P 1. 尽可能保持 Camera 预览的分辨率与推流尺⼨寸⼀一致 2. 尽可能使⽤用 GPU 对画⾯面进⾏行行缩放和剪裁 从 GPU 输出数据的时候，顺便便完成格式转换，⽽而不不⽤用 再由 CPU 进⾏行行转换 尽可能地使⽤用 OpenGL 的⾼高级特性提⾼高效率，⽐比如： VBO, VAO, FBO, PBO
  • 28.直播 - 痛点 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 29.直播 - 疑难杂症 ⿊黑屏 闪屏 花屏 ⻢马赛克 发烫 杂⾳音 噪声 回声 线上崩溃 播放失败 ⾳音画不不同步 拖动不不准
  • 30.直播 - 排障 - 优化 1. RTMP 的 Metadata 每⼀一个流都可以直接通过播放器器拿到主播推流的环境信息，包括： - 系统信息：设备型号、系统版本、App 版本号等 - 编码信息：软编硬编、帧率配置、GOP 参数配置等 - ⽹网络信息：⼿手机 ip 地址，服务器器 ip 地址、WiFi 强度、运营商等
  • 31.直播 - 排障 - 优化 2. 秒级服务端流数据统计 从服务端的帧率、码率变化曲线，可以准确判断卡顿问题，是否是主播⽹网络不不好导致的 - 码率 稳定，帧率 降低 -> 带宽充⾜足，帧率低可能是⼿手机发热或者内存不不⾜足导致丢帧 - 码率 降低，帧率 稳定 -> 带宽不不⾜足，动态码率⽣生效了了 - 码率 降低，帧率 降低 -> ⽹网络抖动厉害，卡顿是由于⽹网络原因导致的
  • 32.直播 - 排障 - 优化 3. 线上 Crash 收集上报 + ⽇日志落存储 如果只有 Crash 堆栈，却没有上下⽂文⽇日志，线上问题排查和修复起来是⽐比较困难的
  • 33.直播 - 痛点 - 优化 ⾸首开慢 卡顿率⾼高 延时⼤大 ⻢马赛克 功耗⼤大 排障不不易易
  • 34.直播 - ⾼高级功能 - 连⻨麦
  • 35.直播 - ⾼高级功能 - 连⻨麦 ⽅方案 合流
  • 36.直播 - ⾼高级功能 - 连⻨麦 ⽅方案 合流
  • 37.直播 - ⾼高级功能 - 连⻨麦 主播 UDP RTMP TCP 互动服务器器 UDP 延时：500ms 连⻨麦观众 延时：2～4s 流媒体服务器器 存储 RTMP/HLS CDN RTMP/HLS CDN RTMP/HLS CDN 观众 观众 观众 核⼼心：基于 UDP 协议的低延时⽅方案
  • 38.直播 - ⾼高级功能 - 连⻨麦 ⽅方案 合流
  • 39.连⻨麦 - ⽆无合流⽅方案 主播 1路路上⾏行行＋2路路下⾏行行 3路路下⾏行行 互动服务器器 RTC Server 3路路下⾏行行 1路路上⾏行行＋2路路下⾏行行 1路路上⾏行行＋2路路下⾏行行 3路路下⾏行行 连⻨麦观众 连⻨麦观众 观众 观众 观众 特点：
 
 1. 所有的⼈人都是视频会议的⼀一部分 2. 抛弃传统的 RTMP 协议，只使⽤用互动协议 缺点：
 
 1. 抛弃了了成熟的内容分发⽹网络(CDN) 2. ⽆无合流，连⻨麦画⾯面⽆无法存储回放 3. ⽆无合流，普通观众端带宽压⼒力力⼤大，需要 同时拉取所有跟主播连⻨麦的其它观众的画⾯面
  • 40.连⻨麦 - 服务端合流⽅方案 主播 1路路上⾏行行＋2路路下⾏行行 特点：
 
 1. 服务器器端合流，再转推 RTMP 2. 普通观众依然从 CDN 拉流观看 互动服务器器 RTC Server 合流 B A C RTMP 流媒体服务器器 RTMP Streaming Server 1路路上⾏行行＋2路路下⾏行行 连⻨麦观众 1路路上⾏行行＋2路路下⾏行行 RTMP/HLS CDN RTMP/HLS CDN RTMP/HLS CDN 连⻨麦观众 缺点：
 观众 观众 观众 
 1. 服务器器转码，延时⽐比较⼤大，6～10s 左右 2. 服务器器压⼒力力⼤大，性能要求极⾼高，扩展成本也⾼高
  • 41.连⻨麦 - 客户端合流⽅方案 主播 1路路上⾏行行＋2路路下⾏行行 B A C RTMP 流媒体服务器器 RTMP Streaming Server RTMP/HLS CDN RTMP/HLS CDN RTMP/HLS CDN 存储 视频互动服务器器 RTC Server 观众 观众 观众 1路路上⾏行行＋2路路下⾏行行 互动观众 1路路上⾏行行＋2路路下⾏行行 互动观众 对⽐比服务器器合流⽅方案：
 
 1. ⽆无转码，延时⼩小 2. ⽆无缝合流，服务端⽆无感知 缺点：
 
 1. 主播端带宽和功耗压⼒力力⾮非常⼤大
  • 42.连⻨麦 - 合流原理理 - 视频 Q：如何实现画⾯面混合 ？ 1. 配置合流参数 2. 对图像进⾏行行：剪裁、拉伸、旋转 3. 根据合流参数，对图像数据进⾏行行叠加 480 x 848 连⻨麦者 剪裁 Camera
 预览
 720 x 1280 剪裁 主播 + 连⻨麦者 480 x 848 240 x 320 连⻨麦者 主播 480 x 848
  • 43.连⻨麦 - 合流原理理 - ⾳音频 Q：如何实现混⾳音功能 ？ 4.8KHz, 8bit, stereo 44.1KHz, 16bit, mono decode transcode remote PCM PCM H.264 capture Microphone PCM 44.1KHz, 16bit, mono encode 混合 AAC 混合 muxer FLV 44.1KHz, 16bit, mono
  • 44.连⻨麦 - 合流原理理 - ⾳音频 1. 重采样（resample） 2. 对位叠加 3. 溢出处理理
  • 45.演讲⼤大纲 1. 直播的痛点介绍 2. 技术层⾯面的关键优化 - 秒开优化 - 卡顿优化 - 延时优化 - 清晰度优化 - 功耗优化 - 排障的优化 3. 直播部分⾼高级功能技术剖析 - 连⻨麦⽅方案 - 合流原理理 4. 总结
  • 46.移动直播的关键技术优化 “哪有什什么岁⽉月静好 只不不过是有⼈人替你负重前⾏行行。”
  • 47.联系⽅方式 主⻚页：http://www.jhuster.com邮箱：lujun.hust@gmail.com 微信：weixin_lujun 公众号：@Jhuster