音视频流媒体开发【四十六】RTMP流媒体2-直播推流1

音视频流媒体开发-目录
iOS知识点-目录
Android-目录
Flutter-目录
数据结构与算法-目录
uni-pp-目录

RTMP流媒体Demo

  1. 直播框架分析
  2. 直播具体技术细节分析
  3. 直播推流源码实战

第一章 直播框架分析

直播应用场景

常用直播功能项

直播框架示例1:常用直播功能项

直播框架示例2:某直播学院框架

直播架构-基本逻辑

直播架构-基本流程

直播常用工具

流媒体服务器

SRS :一款国人开发的优秀开源流媒体服务器系统

BMS :也是一款流媒体服务器系统,但不开源,是SRS的商业版,比SRS功能更多

nginx :免费开源web服务器,也常用来配置流媒体服务器。
集成Rtmp_module即可。

Red5:是java写的一款稳定的开源的rtmp服务器。

直播框架之CDN

基础知识补充 流媒体开发

  1. 名词术语:YUV 、PCM、AAC、H264、FLV、RTMP、音视频同步:《1-快速掌握音视频开发基础知识.pdf》
  2. FFmpeg命令行测试环境:《2-Windows FFmpeg命令行环境搭建.docx》
  3. QT-FFmpeg开发环境:《3-QT+FFmpeg4.0 Windows开发环境搭建.docx》
  4. SRS服务器搭建:《4-RTMP流媒体服务器搭建.pdf》
  5. AAC ADTS格式分析:《5-AAC ADTS格式分析.pdf》
  6. H264 NALU分析:《6-H264 NALU分析.pdf》
  7. FLV格式分析:《 7-FLV格式分析.pdf》
  8. RTMP协议详解:《8-RTMP协议详解.pdf》

RTMP文档: rtmp_specification.pdf

采集端逻辑

播放端逻辑

第二章 技术细节

推流拉流技术点

缓冲控制

  • 延时:实时采集画面与播放展示画面的时间差
    一般主要是节点网络抖动,数据堆积导致GOP缓存过多
    X264编码:无延时编码zerolatency,控制码率波动
  • 首屏:从点击播放到出图的时间
    节点级数越多耗时越长
    首屏打开考验的是直播CDN的组网方式、网络覆盖率和传输协议的优化程度
  • 卡顿:播放过程中出现卡顿次数或时长
    主播推流卡顿、CDN内部网络卡顿,客户终端网络
  • 策略方面
    预热:提前拉取热门直播
    集群:就近共享数据

延时

全网延时控制
◼ 延时控制:在网络拥塞严重时采用丢帧策略,保障实时播放
◼ 参数更新:meta/video codec/audio codec
◼ 时间戳:递增

质量监控

质量指标

CDN监控
◼ 建连时间
◼ 首帧时间
◼ 缓存
◼ 帧率
◼ 码率
◼ 丢帧

端监控
◼ DNS解析时间
◼ 建连时间
◼ 首帧时间
◼ 缓存
◼ 帧率
◼ 码率
◼ 丢帧
◼ 码率
◼ 卡顿率
◼ 失败率

卡顿

故障排查-黑屏

◼ metadata是否正常
◼ 是否有视频sequence header
◼ 是否有视频帧数据
◼ 音视频时间戳是否单增
◼ 是否视频数据大小一致(本身就是黑屏数据)

故障排查-卡顿

◼ 看卡顿分布:
• 全网卡顿,还是局部卡顿;
• 全网卡查上行,局部卡查下行
◼ 另外,全网卡顿也可能是流异常,比如码率过大
• 主要受观众带宽限制
• 一般2M以上就会出现卡顿上升,3M就要开始吐槽了

故障排查-推流卡顿

◼ 查看推流路径监控
• 是否频繁断开
• 主播推流是否欠速(速率明显偏低)
• 内部上行是否欠速
◼ 常见原因
• 主播网络问题。ping推流点,speedtest测速
• 连接的推流点不合理。可能是调度问题,也可能是dns配置不对或localdns不对
• 内部链路问题。查丢包
• 节点高负载(cpu、内存、io、带宽、机房带宽)

故障排查-下行拉流卡顿

◼ 部分区域卡顿高
◼ 常见原因:
• 丢包
• 高负载(cpu、内存、io、带宽、机房带宽)
• 节点覆盖

故障排查-播放异常

◼ 时间戳问题
• 时间戳跳变
• 音视频差距大
• 可以调节选项拉原流验证
◼ 声音异常
• 网络抖动导致没有声音进行播放

第三章 直播推流源码实战

➢ 推流实战-见源码演示
➢ 拉流实战-见源码演示

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容