〝 古人学问遗无力,少壮功夫老始成 〞
随着5G技术的发展,音视频直播领域发生了翻天覆地的变化,尤其是 2011 年 Google 推出 WebRTC 技术后,大大降低了音视频技术的门槛,你再也不必自己去实现回音消除算法了,也不用自己去实现各种音视频的编解码器了,更不必去考虑跨平台的问题了。如果这篇文章能给你带来一点帮助,希望给飞兔小哥哥一键三连,表示支持,谢谢各位小伙伴们。
目录
一、UDP/TCP
二、RTP 协议
三、RTP案例
四、RTCP 协议
如果让你自己开发一套实时互动直播系统,在选择网络传输协议时,你会选择使用UDP协议还是TCP协议
假如使用 TCP 会怎样呢?在极端网络情况下,TCP 为了传输的可靠性,将会进行反复重发信息的操作
在 TCP 协议中,为了避免重传次数过多,定时器的超时时间会按 2 的指数增长,也就是说,假设第一次设置的超时时间是 1 秒,那么第二次就是 2 秒,第三次是 4 秒……第七次是 64 秒。如果第七次之后仍然超时,则断开 TCP 连接,而对于这么长时间的延迟,实时互动的直播系统是根本无法接受的
所以做在线直播系统时候一定要选择 UDP 协议
在实时互动直播系统传输音视频数据流时,我们并不直接将音视频数据流交给UDP 传输,而是先给音视频数据加个 RTP 头,然后再交给 UDP 进行传输
因为视频数据在传输时,数据量太大,所以传输1帧可能需要几十个包,而数据传到接受端的时候,要将这几十个包进行组装,才能还原成完整的图像
而RTP 协议就是为了然对接端组装数据之后,顺序不会乱而存在的,你想想,如果组装的时候,顺序乱了,组装出来的图像还是传输过来的图像吗
RTP 协议非常简单,这里对RTP进行简单的介绍
sequence number:序号,用于记录包的顺序
timestamp:时间戳,同一个帧的不同分片的时间戳是相同的。不同帧的时间戳是不同的
PT:Payload Type,数据的负载类型。音频流的 PT 值与视频的 PT 值是不同的,通过它就可以知道这个包存放的是什么类型的数据
SSRC:共享媒体流的源,它是全局唯一的,不同的SSRC标识不同的共享源
CC:CSRC的个数
CSRC:共享源,一般用在混音或混屏上
X:RTP扩展头标记,如果该位置是1,说明此RTP包还有扩展头
M:表示MARK位,用来界定视频帧边界
P:填充位
如果你在网络上接收了一组下面的音视频数据
假设 PT=80 是视频数据,PT=100 是音频数据
按照上面的规则,是不是就很容易组装数据了
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:14,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:14,ts:123456789,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:15,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:15,ts:123456789,ssrc=2345},
{V=2,P=0,X=0,CC=0,M=0,PT:100,seq:16,ts:123456789,ssrc=888},
{V=2,P=0,X=0,CC=0,M=0,PT:80,seq:16,ts:123456789,ssrc=2345}
在使用 RTP 包传输数据时,难免会发生丢包、乱序、抖动等问题
比如:网络线路质量问题引起丢包率高、传输的数据超过了带宽的负载引起的丢包问题等等
而在处理这些问题之前,WebRTC首先要让各端都知道它们自己的网络质量到底是怎样的,这就是 RTCP 的作用
RTCP 有两个最重要的报文:RR(Reciever Report)
和 SR(Sender Report)
通过这两个报文的交换,各端就知道自己的网络质量了
该报文协议如下图,其中字段的含义:
V=2:指报文的版本。
P:表示填充位,如果该位置 1,则在 RTCP 报文的最后会有填充字节
RC:全称 Report Count,指 RTCP 报文中接收报告的报文块个数
PT=200:Payload Type,也就是说 SR 的值为 200
Header:部分用于标识该报文的类型,比如是 SR 还是 RR
Sender info:部分用于指明作为发送方,到底发了多少包
Report block:部分指明发送方作为接收方时,它从各个 SSRC 接收包的情况