共计 3399 个字符，预计需要花费 9 分钟才能阅读完成。
摘要：音视频传输协定泛滥，不同业务应该如何抉择？RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此咱们就从业务倒退的视角来了解各种流媒体协定，帮忙大家有更加清晰的了解，抉择时做出更感性的判断。
音视频传输协定泛滥，不同业务应该如何抉择？RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此咱们就从业务倒退的视角来了解各种流媒体协定，帮忙大家有更加清晰的了解，抉择时做出更感性的判断。
IPTV
IPTV 是由运营商主导建设的一套零碎，他的次要对标对象是传统广电的数字电视。所以这套零碎首要解决的是大规模直播的问题，在此基础上还须要反对点播、时移、回看等新业务。运营商的劣势就是能够自建一套可治理的网络，所以直播就基于组播技术进行大规模散发。次要技术栈是 RTP+TS over multicast，这个技术大大降低了直播峰值对流媒体服务器的压力。而点播、时移、回看业务因为必须应用单播传输，所以过后抉择的技术栈是应用 RTSP 进行流媒体管制，应用 RTP+TS over UDP（大量基于 TCP）进行数据传输。
当初这套零碎服务了全国靠近 1.7 亿多用户。这套技术栈面临的挑战和对应的解决方案次要包含几点：
解决单播基于 UDP 传输丢包的问题，丢包会导致用户观看花屏或爆音，咱们基于 RTSP 协定扩大制订了一套标准，基于 RTSP 的 GET_PARAMETER 扩大了重传数据报文的信令，次要是基于 NACK 原理进行设计，告诉流媒体服务器哪个报文没有接管到，流媒体服务器依据申请中携带的 RTP 序号进行重发。
解决组播传输丢包问题，组播报文丢包会导致直播花屏或爆音，咱们采纳了 2 个伎俩解决这个问题：
- FEC
- ARQ
通过 FEC 技术减少等步长的冗余报文，能够解决随机丢包问题，然而无奈解决突发间断丢包问题，这个时候就须要 ARQ 技术，咱们在零碎中减少一个 RETServer，RET Server 也会退出组播组接管和机顶盒收到的雷同的组播报文，机顶盒在检测到丢包后，会向这台服务器发动 NACK 报文，RET Server 收到申请后依据申请的 RTP 须要将对应的报文发送给机顶盒。
解决组播传输下频道疾速启动问题，终端退出组播组的工夫是随机的，无奈保障每次退出组播组后接管到的报文就能够了解用于解码并显示，所以咱们通过在零碎中减少一个 FCC Server，解决该问题，终端在起播观看一个频道的时候，优先向 FCC Server 申请一条单播流，FCC Server 会以 1.X 倍的速率将 I 帧和解码所需的报文发给终端，配合终端快显技术能够实现 300ms 以内的频道切换速度。
IPTV 多屏
随着挪动终端的倒退，运营商心愿在 IPTV 业务根底上，倒退手机等多屏业务，开始反对 HLS（支流）、MPEG DASH（局部海内运营商，反对 MultiDRM）流媒体协定。这套零碎在流媒体协定层面临的问题是不同屏幕，不同 DRM 格局，多种格局带来了存储空间成倍的回升，特地是 NPVR 集体录制业务，对存储的需要十分大。次要解决思路就是 JITP（Just In Time Package），即只有存储一份内容，依据用户观看的内容格局进行实时格局转换。
OTT 点播
随同着以 Youtube，Netflix，爱奇艺，优酷，腾讯视频为代表的 OTT 视频点播平台的崛起，以及苹果手机的遍及和 HLS 协定的呈现，流媒体协定从 HTTP 渐进式下载倒退到 ABR Streaming，HLS 是其中最为支流的一种 ABR 协定，HLS 也成为了各个 OTT 视频平台的首选视频传输协定。这套零碎在流媒体协定层面临的问题和解决方案如下：
1、解决基于互联网的大规模散发问题。CDN 技术能够很好的解决这个问题，这也是 OTT 流媒体协定基本上在设计之初就思考对 CDN 敌对的起因。
2、Netflix 因为业务量的规模倒退到肯定规模，从最开始抉择第三方 CDN，走向了自建 CDN（Open Connect）的路线，然而他的技术栈仍旧是 HLS 和 DASH 这类对 CDN 敌对的流媒体协定。
OTT 直播
细分为事件类（新闻 / 赛事 / 演唱会）直播、集体（游戏 / 网红 / 秀场）直播。满足这类直播业务的流媒体协定层面临的问题和解决方案如下：
1、首先他们和 OTT 点播一样，须要解决基于互联网的视频大规模散发问题。
2、其次直播相较于点播须要额定思考的一点就是直播时延，第一类：电视台 / 事件（新闻 / 赛事 / 演唱会）直播根本没有和观众互动的要求。所以它们仍然抉择对 CDN 敌对的 HLS 和 DASH 协定，然而时延会高达 10-30s，随着 CMAF 格局的呈现，依据咱们在实验室的测试数据示意时延能够小于 5s。第二类：集体（游戏 / 网红 / 秀场）直播，以国内直播平台为例，商业模式次要靠打赏分层，所以要求直播的 E2E 时延必须低于 5s，否则观众与主播的互动成果十分差，间接影响直播平台的支出。这类厂家抉择的技术栈为提早更低的 RTMP 和 HTTP FLV。
3、随着手机和 4G 网络的遍及，局部主播也开始尝试在户外进行开播，因为户外直播的网络条件不可控，而 RTMP 是基于 TCP 传输的，导致在户外 4G 网络条件不稳固的环境下，直播成果很差，所以针对弱网环境下的直播上行成果差成为直播平台须要解决问题。为了解决这个问题，大家把眼光转向 UDP，基于 UDP 的直播传输技术逐渐进入人们的视线。常见的有 ZIXI、SRT 和 RIST。ZIXI 属于纯商业化公司，显然不适合大量集体直播上传这类商业模式的直播平台。SRT 有绝对成熟的开源社区反对，所以在国内利用较为广泛。RIST 是由 Video Services Forum (VSF) 于 2017 年初开始制订的牢靠的互联网流传输协定（Reliable Internet Stream Transport，RIST），相较于 SRT，基于 UDT 非实时流媒体的技术栈构建，RIST 一开始便应用较为成熟的 RTP+RTCP 技术，而且他只定义了标准化的语法，容许实厂家在此基础上进行翻新，而又不影响相互操作。通过近几年的倒退 RIST 反对的场景越来越多，也越来越成熟。
4、直播业务倒退越来越凋敝后，又呈现了多主播 PK，主播与观众连麦等场景，这些对时延的要求间接从 5s 变成 1s 以内，甚至小于 400ms，为了满足业务的倒退，直播平台抉择了实时通信的技术栈 RTP+RTCP over UDP。一旦引入 UDP，就须要解决丢包带来的视频体验问题，这里常见的技术有 FEC、ARQ 等。
实时音视频 RTC
随着 5G 网络的遍及，以及疫情带来的影响，人们对实时音视频技术的利用场景会越来越多，次要包含：会议、连麦、音视通话、视频通话、在线教育、近程医疗等。因为这些利用场景对时延的要求 <400ms，所以从技术栈抉择来看，基本上都是抉择 RTP/RTCP over UDP 的形式进行音视频数据的输入。
如果把流媒体协定做三个维度划分：品质（画质 / 帧率）、平滑、提早。实时音视频通信和 OTT 直播上传场景相比，对低质量的容忍度更高，即容许升高肯定的品质，降落（降帧率等）来换取更加平滑的体验和更低的提早。这个抉择上的差别，导致在技术设计上须要买通网络传输零碎和音视频编解码零碎，实现依据网络传输品质实时动静调整音视频编码参数，在品质、时延、平滑三个维度上进行衡量得出最优解。
流媒体新的倒退方向
1、新的媒体表现形式包含 VR、自在视角、点云；他们与传统视频的最大区别在于，传统视频次要反对工夫维度的定位，而新的媒体，除了反对工夫维度的定位，还反对空间维度的定位。以后次要在 MPEG 规范组织中进行探讨，基于 MPEG DASH 标准进行演进。以 VR 为例，个别人类的 FOV 视场角 <140°，新的流媒体协定利用这个个性，能够实现依据观众观看的视频范畴，进行局部传输，从而升高的对带宽的诉求，这也很好的解决了传输的数据量越来越大对带宽要求刻薄的问题。华为云视频的 Cloud VR 产品曾经反对 8K VR、自在视角的直播和点播服务。
2、全互联实时音视频直播，随着在线教育和在线办公的遍及，越来越多客户对具备大规模散发能力的低时延互动视频服务有着强烈的诉求，以后的架构要么反对大规模散发，要么反对低时延、互动，无奈同时具备三者的能力。咱们认为将来的支流架构须要同时满足这三样能力，华为的实时音视频服务曾经实现这套架构的实现，致力于在流媒体畛域继续深耕，让咱们共建流媒体的将来。
点击关注，第一工夫理解华为云陈腐技术~
