WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档

基于WebRTC的直播CDN

2020-09-17 15:46:49

 

    • 1 背景
    • 2 功能
    • 3 架构
    • 4 主要业务
      • 4.1 推流
        • 4.1.1 推WebRTC
        • 4.1.2 推RTMP
        • 4.1.3 推WebRTC转RTMP
        • 4.1.4 推RTMP转WebRTC
      • 4.2 拉流
        • 4.1.1 拉WebRTC
        • 4.2.2 拉FLV/HLS/FMP4
    • 5 最短回源路径
    • 6 业务系统
    • 7 一些特性/问题
      • 7.1 WebRTC与其他格式的兼容性
      • 7.2 Janus的优化以及丢包
      • 7.3 延迟
      • 7.4 秒开
      • 7.5 安全性

 

1 背景

本文介绍一下我们这两年做的直播系统架构,系统中媒体相关服务直接叠加在搜狐视频的点播CDN之上,业务相关服务依托于大搜狐云。

2 功能

主要特性:

  • 支持WebRTC、RTMP推流;
  • 支持WebRTC、FLV、HLS、FMP4拉流;
  • 最优用户接入;
  • 最短回源路径;
  • 全平台SDK,包括H5、iOS、Android、PC。

3 架构

在这里插入图片描述

在这里插入图片描述

整体上这个系统是一个典型的CDN结构,主要包含调度系统、CDN源节点和CDN边缘节点。

节点服务列表:

服务 功能
Transfmtd 转格式服务,主要负责WebRTC的RTP流与RTMP流的互转。
Janus WebRTC流转发服务,主要负责WebRTC流的推、拉。
Merge 合流服务,主要负责多个流的合流,用于使用MCU的场景。
Segmentd 切片服务,用于推RTMP流时的转封装、切片,可以切成FLV、HLS、FMP4等格式。
Controld 控制服务,主要用于管理节点内的所有服务,流的管理,并负责与Masterd服务的交互。
Edged 边缘服务,主要用于拉FLV、HLS、FMP4流。

所有节点内部的服务都由Nginx代理。

调度系统服务列表:

服务 功能
Named 流名服务,流名的生成、校验。
Masterd 主控服务,用于管理所有的节点,并自动生成最短回源路径。
Schedule 调度服务,用于管理用户地域与节点的关系,管理流与节点的关系。

4 主要业务

4.1 推流

不同的推流模式由推流地址中携带的参数决定。

4.1.1 推WebRTC

在这里插入图片描述

  1. 推流端请求Named,请求、校验流名,并获得schedule地址;
  2. 推流端请求schedule,获得地域、运营商匹配的推流Janus;
  3. 推流端请求Janus,开始推流;
  4. Janus请求Controld,创建一路流,并开始传输RTP;
  5. Controld请求Masterd,通知流信息;
  6. Masterd请求Schedule,通知流与节点信息;

4.1.2 推RTMP

使用Nginx RTMP模块接收RTMP流:
在这里插入图片描述

  1. 推流端请求Named,请求、校验流名,并获得schedule地址;
  2. 推流端请求schedule,获得地域、运营商匹配的推流地址;
  3. 推流端开始推流到推流地址,Nginx RTMP模块收到RTMP流;
  4. Nginx 上的一个自定义模块会请求Segmentd服务,Segmentd服务使用ffmpeg拉RTMP流并根据推流的参数进行切片;
  5. Segmentd请求Controld,创建一路流,并开始传输切片数据(FLV/HLS/FMP4);
  6. Controld请求Masterd,通知流信息;
  7. Masterd请求Schedule,通知流与节点信息。

4.1.3 推WebRTC转RTMP

在这里插入图片描述

  1. 推流端请求Named,请求、校验流名,并获得schedule地址;
  2. 推流端请求schedule,获得地域、运营商匹配的推流Janus;
  3. 推流端请求Janus,开始推流;
  4. Janus检查推流参数判断需要转成RTMP,则请求Transfmtd服务,传递sdp,开始进行转换;
  5. Transfmtd使用ffmpeg,根据sdp以及转换参数将RTP转成RTMP,并推流给Segmentd切片服务;
  6. Segmentd请求Controld,创建一路流,并开始传输切片数据(FLV/HLS/FMP4);
  7. Controld请求Masterd,通知流信息;Controld请求Masterd,通知流信息;
  8. Masterd请求Schedule,通知流与节点信息;

4.1.4 推RTMP转WebRTC

在这里插入图片描述

  1. 推流端请求Named,请求、校验流名,并获得schedule地址;
  2. 推流端请求schedule,获得地域、运营商匹配的推流地址;
  3. 推流端开始推流到推流地址,Nginx RTMP模块收到RTMP流;
  4. Nginx 上的一个自定义模块会请求Transfmtd服务,Transfmtd服务使用ffmpeg拉RTMP流并根据推流的参数转换成RTP;
  5. Transfmtd请求Controld,创建一路流,并开始传输RTP;
  6. Controld请求Masterd,通知流信息;
  7. Masterd请求Schedule,通知流与节点信息。

4.2 拉流

4.1.1 拉WebRTC

在这里插入图片描述

  1. 拉流端请求Masterd,获得流相关信息,并获得schedule地址;
  2. 拉流端请求schedule,获得地域、运营商匹配的拉流Janus;
  3. 拉流端请求Janus,开始拉流;
  4. Janus请求本地Control,请求流数据,如果Controld上已经缓存该流,则直接返回数据,否则到5;
  5. Controld请求Masterd,请求回源路径,Masterd将根据当前的整体网络路由状态返回一个最短路径;
  6. 每个Controld向路径上的下一跳请求数据,直到请求到达某个命中的Controld并返回数据,回源路径上的所有Controld都将缓存该流。

4.2.2 拉FLV/HLS/FMP4

在这里插入图片描述

  1. 拉流端请求Masterd,获得流相关信息,并获得schedule地址;
  2. 拉流端请求schedule,获得地域、运营商匹配的拉流地址;
  3. 拉流端请求拉流地址,也就是Edged,如果Edged已经缓存该流,则直接返回数据,否则到4;
  4. Edged请求本地Control,请求流数据,如果Controld上已经缓存该流,则直接返回数据,否则到5;
  5. Controld请求Masterd,请求回源路径,Masterd将根据当前的整体网络路由状态返回一个最短路径;
  6. 每个Controld向路径上的下一跳请求数据,直到请求到达某个命中的Controld并返回数据,回源路径上的所有Controld都将缓存该流。

5 最短回源路径

  • Masterd服务管理所有Controld的连接;
  • Masterd周期性地向Controld服务发起网络探测请求,获得链路参数(丢包、延迟);
  • Controld服务在实际媒体数据传输过程中,获得链路参数(丢包、延迟);
  • Mastered构建Controld有向全通图,顶点为Controld,边为链路参数;
  • 在拉流需要回源时,使用dijkstra算法计算最短回源路径。

6 业务系统

上面未涉及业务系统,业务系统主要包含:

  • 流的管理;
  • 用户管理;
  • 应用授权管理等。

我们开始的目标是做成平台,同时针对业务系统的可定制的需求,我们将APP SDK设计成了可以热加载定制业务的模式,后面会在另外一篇文章中介绍。

7 一些特性/问题

7.1 WebRTC与其他格式的兼容性

WebRTC默认的流控策略会修改分辨率,在RTP转换成其他格式时,分辨率的变化会导致播放出问题,可选的做法是在Janus上强制转码成固定分辨率。另外一种办法是固定推流分辨率,但是目前在浏览器上,如果不是抓屏业务,WebRTC接口无法设置为固定分辨率,而在APP上可以做到,具体参考我这篇文章。

7.2 Janus的优化以及丢包

我们修改了Janus的默认带宽检测、NACK模块,跟WebRTC保持兼容,并在SDK上做了优化,有效降低了卡顿率,参考我这篇文章,目前在30%的丢包下可以流畅进行视频通话。

7.3 延迟

延迟主要依赖于CDN的部署情况、用户侧的网络条件,据不完全测试,目前的端到端延迟可以达到250ms。

7.4 秒开

参考我这篇文章,在我们默认的业务环境下,所有平台端可以达到600ms的首开时间。

7.5 安全性

传输层面有以下加密措施。

  • 对WebRTC流,从信令到媒体都是加密的;
  • RTMP推流,本身是不加密的,但是可以添加扩展支持RTMPS;
  • FLV、HLS、FMP4拉流,可以通过HTTPS。

在应用层面,可以集成我们的DRM模块,这样即使盗播者拿到最终播放地址也无法播放,只有我们的私有播放器才能播放。当然这个特性只是针对APP,对浏览器来说不存在DRM,因为谷歌的widevine服务无法使用。

 

By:rasp | WebRTC项目与应用 |

  • 分类目录

    • WebRTC概念与基础 (225)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (12)
    • WebRTC服务端开发 (23)
    • WebRTC网络与通信 (26)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
  • 最新文章

    • 音视频相关的书籍,多媒体技术
    • SFU级联解决方案——Jitsi
    • SFU级联解决方案——Licode
    • Janus源码分析(6)——Streaming分析
    • janus Streaming插件推流指南
    • 流媒体服务器 
    • WebRTC+libwebsockets+Janus的秒开实践
    • 基于WebRTC的直播CDN
    • 不需要SFU实现WebRTC联播实践  
    • webrtc 开启Simulcast功能
    • Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
    • WebRTC源码分析rfc4588 RTP重传有效载荷格式
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • 自研WebRTC网关服务器架构的实践之路
    • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  
    • janus的videoroom插件
    • WebRTC+libwebsockets+Janus的秒开实践
    • Janus源码分析(7)——videoroom分析
    • Janus源码分析(5)——echotest分析
    • Janus源码分析(4)——信令交互过程
    • WebRTC+libwebsockets+Janus的秒开实践
    • 前向纠错码(FEC)的RTP荷载格式
    • WebRTC 开发实践:从一对一通话到多人会议
    • Distord如何使用WebRTC处理250万用户同时进行的音频交流
    • 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
    • 基于WebRTC技术的多人音视频解决方案
    • 谁是最好的WebRTC SFU?
    • WebRTC媒体服务器
    • 使用Janus作为对讲服务器的后台框架和业务流程
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.