摘要：音视频传输协定泛滥， 不同业务应该如何抉择？ 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、 全互联实时音视频直播，随着在线教育和在线办公的遍及，越来越多客户对具备大规模散发能力的低时延互动视频服务有着强烈的诉求，以后的架构要么反对大规模散发，要么反对低时延、互动，无奈同时具备三者的能力。咱们认为将来的支流架构须要同时满足这三样能力，华为的实时音视频服务曾经实现这套架构的实现，致力于在流媒体畛域继续深耕，让咱们共建流媒体的将来。
点击关注，第一工夫理解华为云陈腐技术~
发表回复