WebRTC → 传统直播(非实时)系统浅析

690 阅读13分钟

传统直播架构

直播系统可以简单的分为实时互动直播传统直播实时互动直播注重于传输的实时性(因此采用UDP作为底层协议),如在线教育、音视频会议等,传统直播则注重的是画面质量、音视频是否卡顿的问题(因此采用TCP作为底层传输协议),如娱乐直播等

商业级别的直播系统结构是非常复杂的,除了核心的音视频直播外,还包括用户管理、认证系统、直播间管理、私信等业务逻辑

image.png

直播客户端

直播客户端主要包括音视频数据的采集、编码、推流、拉流、解码和播放等功能

  • 客户端主要用途分类
    • 主播使用的客户端
      • 包括音视频采集、编码和推流的功能
      • 可以从直播设备上采集对应数据,然后对采集的音视频数据进行编码,最后将编码后的音视频数据按RTMP协议推送给CDN源节点(RTMP接入服务器)
    • 观众使用的客户端
      • 包括拉流、解码与渲染(播放)的功能
      • 观众端主要实现了一个播放器的功能,开源的有两个成熟的项目集成后就可以基本实现对应的功能(ljkplayer和VLC)
信令服务器

主要用于接收信令,并根据信令处理一些和业务相关的逻辑,如创建房间、加入房间、离开房间、送礼物、文字聊天等

  • 注意点
    • 一定要关注和防止消息的洪范
CDN网络

主要用于媒体数据的分发

主播推流浅析

  • 向信令服务器发送「创建房间」的信令,并收到信令服务器返回的推流地址信息(CDN网络源站地址) - 步骤①
  • 主播客户端将采集到的音视频数据进行编码,生成RTMP消息,最终将媒体流推送给CDN网络 - 步骤②
  • 步骤③和④与①和②一样,只是设备不同
  • 观众向信令服务器发送「加入房间」的消息,信令服务器根据用户地区,分配一个最近的CDN边缘节点 - 步骤⑤
  • 观众收到CDN地址后进行拉流和渲染 - 步骤⑥
  • 在传统直播中,一般推流端使用RTMP协议,拉流端可以使用RTMP协议或者HLS协议

RTMP协议与HLS协议

RTMP协议

RTMP(Real Time Messaging Protocol:实时消息协议,默认端口1935,可能会被防火墙屏蔽),一般情况下最少会有几秒到几十秒的延迟,底层是基于TCP协议的,其传输格式是RTMP Chunk Format,媒体流数据的传输和RTMP控制消息的传输都是基于此格式的,在使用RTMP协议传输数据之前,RTMP也像TCP协议一样,先进行三次握手才可以建立连接;

  • 优势
    • 底层依赖于TCP协议,不会出现丢包,乱序等问题,因此音视频业务质量有很好的保障;
    • 使用简单,技术成熟,有现成的RTMP协议库实现,如FFmpeg项目中的librtmp库等
    • 市场占有率高,相较于HLS协议,实时性要高很多
  • 劣势
    • iOS不支持该协议,理由是有较大的安全缺陷,现在该协议已经停止更新了
    • 不支持h.265
HLS协议

HLS全称是HTTP Live Streaming,是苹果公司实现的基于HTTP的流媒体传输协议,支持流媒体的直播和点播,主要用于iOS系统和HTML5网页播放器中;

基本原理

是将多媒体文件或直接流进行切片,形成一堆的ts文件和m3u8索引文件并保存到磁盘中;
HLS协议的本质就是通过HTTP下载文件,然后将下载的切片缓存起来,切片比较小,基本可以实现边下载边播的效果

  • 优势
    • 连通性好:RTMP协议没有使用标准的HTTP接口传输数据,会在一些有访问限制的网络环境下出现失败的情况(企业内部一般允许80/443端口进行访问),而HLS协议使用的是HTTP协议传输数据,并不会存在上述问题
    • HLS本身实现了码率自适应,不同宽带的设备可以自动切换到最适合码率的视频进行播放
    • 浏览器天然支持HLS协议,而RTMP协议需要安装Flash插件才可以播放RTMP流
  • 不足
    • 实时性较差,由于HLS采用10s的切片,因此也有最小10s的延迟,一般是20~30s的延迟
    • HLS使用的是HTTP短连接,且HTTP是基于TCP的,因此就意味着HLS需要不断的与服务器建立连接,也就说每次的建立连接和断开连接都会有三次握手和四次挥手耗时

HLS协议深入

HLS规范
  • 视频的封装格式是TS
  • 音视频采用H264编码和AAC编码
  • 除了TS视频文件本身,还定义了用来控制播放的m3u8索引文件
HLS直播结构分析

image.png

  • 步骤图解
    • 源节点服务器收到音视频流后先缓存下来,在保证到达帧的所有切片都收到后,再进行切片成TS流(生成HLS切片文件即.ts文件和与之对应的m3u8文件,即HLS播放列表文件.m3u8文件)
    • 客户端在拉取HLS媒体流时,先通过HLS协议将m3u8索引文件下载下来,然后按照索引文件中的顺序,将.ts文件一片一片下载下来,最后一边播放一边缓冲

HLS协议是由PAT+PMT+TS数据流组成,TS数据中的视频数据采用的是H264编码,而音频数据采用AAC/MP3编码,TS数据流总长度是188字节

image.png image.png

  • PES(Packet Elementary Stream),是将ES流增加PES Header后形成的数据包
  • ES(Elementary Stream),基流,是编码后的音视频数据

在播放HLS流时有很多的开源库可用,移动端可以使用ljkplayer,浏览器端可以使用video.js,pc端可以使用VLC;服务器端的HLS切片由CDN网络完成,只需要向CDN网络推流就可以了,CDN网络会直接将上传的流进行HLS切片

  • 劣势
    • 与HLS技术相比,RTMP协议在传输延时上要比HLS小的多;
      • 主要原因在于:HLS是基于切片的,然后再有缓存技术就直接导致了延时问题
    • RTMP底层是基于TCP协议的,属于应用层,因此不用考虑数据丢包,乱序、网络抖动等问题,而RTP协议网络质量保证需要自己单独实现,RTSP(Real Time Streaming Protocol:实时流传输协议,是TCP/IP协议体系中的一个应用层协议,)是基于UDP传输;
    • RTSP在体系结构上位于RTP和RTCP之上,基于文本的多媒体传输协议,属于应用层,它使用TCP或UDP完成数据传输。HTTP与RTSP相比,HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可以发出请求,即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议,并允许同时多个串流需求控制,传输时所用的网络通讯协定并不在其定义的范围内,服务器端可以自行选择使用TCP或UDP来传送串流内容,它的语法和运作跟HTTP 1.1类似,但并不特别强调时间同步所以比较能容忍网络延迟。
    • RTSP作为一个应用层协议,它主要用来控制具有实时特性的数据的发送,但其本身并不用于传送流媒体数据,而必须依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送。RTSP负责定义具体的控制信息、操作方法、状态码,以及描述与RTP之间的交互操作。 image.png
    • RTSP传输的一般是TS、MP4格式的流,其传输一般需要2~3个通道,命令和数据通道分离。使用RTSP协议传输流媒体数据需要有专门的媒体播放器和媒体服务器,也就是需要支持RTSP协议的客户端和服务器。 image.png

FLV(FLASH VIDEO)浅析

FLV格式的文件就是由:FLV Header + RTMP数据构成的,FLV与RTMP互相转换也很容易,且有相对较成熟的库进行处理,如librtmp等,同时处理FLV格式的文件可以使用FLVParser、FLV分析工具FlvAnalyzer库等,播放FLV格式的播放器有bilibili的flv.js、potplayer等

FLV文件是一个流式的文件格式,该文件中的数据部分时由多个「PreviousTagSize + Tag」组成的,这样的文件格式可以将音视频数据随时添加到FLV文件的尾部,而不会破坏文件的整体结构(在进行FLV格式的文件合并时,需要将后续的文件头的几个字节都删除掉),像其他的媒体格式则没有这种特性,因为其他格式的是结构化的即音频数据和视频数据是分开存储的;其次,FLV较其他媒体格式文件,其文件头是固定的,音视频数据可以随着时间推移追加的文件末尾,而其他格式的文件头是随着数据的增长而变大的;

FLV格式的文件也使用于音视频录制中,可以实现中间的随意暂停,等录制结束后再进行时间依据的追加即可,另外FLV进行视频回放也特别方便,将生成好的FLV格式文件上传到CDN,然后在CDN云服务上进行文件转换为HLS切片,这样用户就可以根据自己的终端选择对应格式的回放音视频数据了

FLV格式详解

总结

流媒体协议分类(应用场景不同)
  • 推流协议:摄像机等推流到服务器
  • 拉流播放协议:手机等从服务器拉流

RTMP可以用在双端,即是推流又是拉流,HLS用在拉流端,HTTP-FLV用在拉流端 image.png image.png image.png

拓展

在线教育直播架构浅析

  • 核心组件
    • 音视频引擎
      • OPUS、VP8、VP9、H264、H265等
    • 传输层协议
      • 底层传输UDP
    • 媒体协议
      • SRTP、SRTCP
    • 数据协议
      • DTLS/SCTPP2P
    • P2P内网穿透
      • STUN、TURN、ICE、Trickle ICE
    • 信令与SDP协商
      • HTTP、WebSocket、SIP Offer Answer 模型
  • 产品功能架构
    • 直播前筹备
      • 直播间个性化装修
      • PPT课件内容上传
      • 直播暖场视频或图片
    • 课程推广引流
      • 公众号、小程序、朋友圈、官网
      • 邀请海报、预约登记观看
      • 直播多平台转推
    • 直播工具
      • 连麦互动、桌面共享、文档、画笔、白板、伪直播
      • 图文直播、签到、公告、答题卡、多媒体
    • 营销工具
      • 问卷、公聊、私聊提问、邀请海报、邀请榜、商品库
      • 优惠券、红包、抽奖、打赏、红包雨、兑换码、会员

无延迟直播技术浅析

  • 音视频发展趋势
    • 移动通讯
    • CDN直播
      • 基于传统的HTTP协议、可比较好的兼容主流的端设备
      • 直播延迟较严重,网络丢包也较严重,没有太多的交互要求,只是简单的直播需求
    • RTC互动
    • 与AI、AR、VR等的结合
核心技术分析
  • 直播技术协议演进
    • 阶段一:专有协议
      • 主要代表是RTMP和RTSP,这些协议需要有专门的服务器进行支持,且对播放器也有一定的要求
    • 阶段二:基于HTTP的分片协议进行直播
      • 主要代表有苹果推出的HLS和安卓推出的DASH,这些协议底层都是基于HTTP协议,因此适用性更好,设备触达率更高,对CDN的支持也很好
      • 由于采取了分片转码技术,可以较好的适配用户的不同网络状况,可有效的降低播放器卡顿率和提升画面质量
      • 但分片转码技术带来的就是延迟,播放器需要缓存多个分片,导致延迟一般在5~30秒
    • 阶段三:以WebRTC为代表的基于UDP的实时音视频技术
      • 利用了UDP无连接、快速的优势
      • UDP不需要像HTTP一样在发送数据前都需要进行三次握手建立连接,只是充当了数据报文的搬运工,不会对数据报文进行任何的拆分和拼接操作,在数据发送效率上高于普通的TCP协议
      • WebRTC核心组件包括音视频引擎、传输协议UDP、媒体协议、数据协议、P2P内网穿透、信令与SDP协商等
  • 无延迟互动关键技术
    • NACK和ARQ(弱网对抗)
      • 传统基于TCP协议的网络
        • 接收方会对收到的所有数据进行ACK确认(Acknowledge),当发送方收不到ACK、超过一定的时间后,发送方会认为接收方数据丢包,会触发数据的停等和重传
        • 常规的网络抖动会影响传输效率,尤其在超时判断、等待确认等方面都带来了很大的延时
      • 基于UDP的现代RTC技术不要求接收方对所有消息进行ACK确认,只要求接收方对没有收到(或乱序)的数据发送NACK(丢包重传),以触发数据重传。该机制会有效的提高通信效率,对抗网络抖动
    • FEC(Forward Error Correction)
      • 在如RTT(Round-Trip time:往返时间)的网络情况下,WebRTC会利用FEC(Forward Error Correction)算法策略来对抗网络丢包
      • RTT是指网络请求从“起点”到“目的地”再返回到“起点”所花费的时长,是确定本地网络或较大Internet上链接运行状况的重要指标
      • FEC会在每个数据包上附带一些冗余的编码,这些冗余的编码数据可以进行后续的校验、恢复和响应的纠错 image.png
    • JitterBuffer(抖动缓冲区)
      • 抖动延迟由网络抖动延迟、解码延迟和渲染延迟构成,其中解码延迟和渲染延迟是比较稳定的,网络抖动延迟是动态变化的
      • JitterBuffer机制可以处理丢包、乱序、延时到达等情况平滑的向解码模块输出数据包/帧
      • 其核心思想是用时间换空间,以增大端到端的延迟来换取视频通话的流畅性
      • 当网络不稳时,增加Buffer长度,多缓存一些数据,以应对将来可能发生的抖动
      • 当网络稳定时,减小Buffer长度,少缓存一些数据,降低端到端的数据缓存,提高实时性
      • JitterBuffer的运行过程就是根据抖动来动态调整Buffer长度的过程,可以在延时和卡顿率之间取得较好的平衡

推荐文献

HLS/RTSP/RTMP 三个流媒体协议的区别
RTMP协议 和 HLS 协议