重庆市建设工程安全网站,上海制造网站公司,建筑类专业做教育的网站,自己制作动画的软件文章目录TCP为何不适用于实时音视频UDP-RTPRTP协议结构JittbufferRTP扩展头RTP填充数据参考TCP为何不适用于实时音视频
可靠性是以牺牲实时性为代价的。按照TCP原理#xff0c;当出现极端网络情况时#xff0c;理论上每个包的时延可达到秒级以上#xff0c;而且这种时延…
文章目录TCP为何不适用于实时音视频UDP-RTPRTP协议结构JittbufferRTP扩展头RTP填充数据参考TCP为何不适用于实时音视频
可靠性是以牺牲实时性为代价的。按照TCP原理当出现极端网络情况时理论上每个包的时延可达到秒级以上而且这种时延是不断叠加的。这对于音视频实时通信来说是不可接受的。 TCP为了实现数据传输的可靠性采用的是“发送→确认→丢包→重传”这样一套机制。而且为了增加网络的吞吐量还采用了延迟确认和Nagle算法(将多个小包组成一个大包发送组合包的大小不超过网络最大传输单元)
为了增加网络的吞吐量接收端不必每收到一个包就确认一次而是对一段时间内收到的所有数据集体确认一次即可。为了实现该功能TCP通常会在接收端启动一个定时器。定时器的时间间隔一般设置为200ms即每隔200ms确认一次接收到的数据。这就是延迟确认机制。‘ 除此之外TCP在发送端也启动了一个定时器不过该定时器的功能不是发送确认消息而是用来判别是否有丢包的情况。发送端定时器的时长为一个RTO(RTORetransmission Timeout重传超时时长。其值约等于RTT的平均值每次超时后以指数级增长。RTT表示一个数据包从发送端到接收端然后再回到发送端所用的时长)如果在定时器超时后仍然没有收到包的确认消息则认为包丢失了需要发送端重发丢失的包。这就是TCP的丢包重传机制。
假如接收端发送的确认消息丢失了按TCP的协议规则通信双方会怎么做呢首先发送端只有等到定时器超时后才能发现该包丢失了。确认丢包后发送端会将前面所有未确认的包重发一遍。如果在收到数据后接收端发送的确认消息又丢失了那么发送端还要等到定时器超时后才能知道包丢失了。因此在遇到这种极端网络的情况下TCP传输的时延要累加很多这种时延是不可控的。
UDP-RTP
UDP没有这套逻辑所以实时性最高。WebRTC通过NACK、FEC、Jitter Bufer以及NetEQ技术既可以解决丢包和抖动问题又不会产生影响服务质量的时延。 UDP传输一些有前后逻辑关系的数据时有缺陷所以在UDP之上的应用层上使用RTP传输音视频数据
RTP协议结构
保持有序:Sequence Number 我们希望在使用RTP传输音视频数据时一旦有数据丢失可以快速定位是哪个数据包丢失了。 如果给每个发送的数据包都打上一个编号并且编号是连续的那么接收端就可以很容易地判断出哪些包丢失了。在RTP头中有一个专门记录该编号的字段称作Sequence Number。在发送端每产生一个RTP包其Sequence Number字段中的值就被自动加1以保证每个包的编号唯一且连续。当接收端收到RTP包时会对Sequence Number字段进行检查如果发现Sequence Number不连续了就说明有包丢失或乱序了。 区分不同类型数据:PayloadType 我们在做网络应用开发时通常会使用同一个端口传输不同类型的数据如音视频数据。但接收端是如何区分出不同类型的数据的RTP在其协议头中设置了PTPayloadType字段.比如VP8的PT一般为96而Opus的PT一般为111 区分不同源数据包:SSRC 同一个端口不仅可以同时传输不同类型的数据包还可以传输同一类型但不同源的数据包。 流媒体服务就可以将多个不同源参与人的视频通过同一个端口发送给客户端。那么客户端接收端又是如何将不同源的数据区分出来的呢这就要说到RTP中另一个字段SSRC了。 RTP要求所有不同的源的数据流之间可以通过SSRC字段进行区分且每个源的SSRC必须唯一。 每个SSRC所代表的数据流的Sequence Number都是单独计数的如下图
完整的协议格式如下
VVersion字段占2位表示RTP的版本号现在使用的都是第2个版本所以该域固定为2。 PPadding字段占1位表示RTP包是否有填充值。为1时表示有填充填充以字节为单位。一般数据加密时需要固定大小的数据块此时需要将该位置1。 XeXtension字段占1位表示是否有扩展头。如果有扩展头扩展头会放在CSRC之后。扩展头主要用于携带一些附加信息。 CCCSRCCount字段占4位记录了CSRS标识符的个数。每个CSRC占4字节如果CC2则表示有两个CSRC共占8字节。 MMarker字段其含义是由配置文件决定的一般情况下用于标识边界。比如一帧H264被分成多个包发送那么最后一个包的M位就会被置位表示这一帧数据结束了。 timestamp字段占4字节用于记录该包产生的时间主要用于组包和音视频同步。 CSRC字段指该RTP包中的数据是由哪些源贡献的。比如混音数据是由三个音频混成的那么这三个音频源都会被记录在CSRS列表中。
Jittbuffer
介绍一下使用RTP消除包抖动的一个简要过程 对于WebRTC而言其在接收RTP包时会为之创建一个接收队列来消除包抖动。一开始队列中只收到了100、101、102和104号包。由于103号包还没到所以无法将100∼104号包组成一帧数据。103号包没有到有两种可能的原因一种原因是103号包丢失了另一种原因是网络抖动导致包乱序了。判断缓冲队列有没有满。如果缓冲队列满了就说明包真的丢失了。对于103号包来说由于现在缓冲队列还不满因此该包处于待定状态。同理当107号包到达时105号包和106号包也处于待定状态。
很快103号包来了通过对其RTP头中Sequence Number字段的计算它会被插到队列中对应的空缺位置此时100∼104号包连成了一串。又由于104号包上有M标记因此可以将这几个RTP包组成一个完整的帧。接下来100∼104号包将从缓冲队列中弹出交由组帧模块处理空出的位置可以继续接收新包。WebRTC也是通过类似的方法从网络上将一个个RTP包接收下来。 WebRTC中解决RTP包抖动的缓冲队列就是我们通常所说的JitterBufer。
RTP扩展头
当X被置位1说明有扩展头
RTP扩展头由三部分组成分别为profile、length以及headerex tension。 在RFC5285中定义了两种profile分别是**{0xBE0xDE}和{0x100x0X}**分别代表存放在headerextension中的两种不同的数据格式即one-byte-header和two-byte-header
接收端解析RTP扩展头时通过profile来区分header extension中的内容该如何解析。 length字段表示扩展头所携带的header extension的个数。如果length为4表示有4个headerextension header extension字段是扩展头信息以4字节为单位其具体含义由profile决定。
one-byte-header格式 存放在扩展头header extension字段中的数据由一个字节的Header和N字节的Body组成而Header又由4位的ID和4位的len组成。注意length的值为跟在Header后面的数据以字节为单位长度减1。
第一个one-byte-header的length值为0其数据长度为011字节第二个one-byte-header的length值为1其数据占112字节第三个one-byte-header的length值为3其数据占314字节。此外由于扩展头要保持4字节对齐所以最后两个字节是填充字节设置为0。
two-byte-header格式 Header部分由两个字节组成第一个字节表示ID第二个字节表示长度two-byte-header中length存放的是实际长度。
通过上面的介绍我们知道RTP扩展头有三个要点。一是RTP标准头中的X位该位置1时RTP中才会有扩展头。二是扩展头中的profile字段指明了扩展头中数据的格式。如果profile为0xBEDE则说明使用的扩展头格式为one-byte-header如果profile为0x100XX表示任意值则说明使用的扩展头格式为two-byte-header。三是one-byte-header与two-byte-header的区别。如果ID和len放在一个字节中说明它是one-byte-header格式如果ID和len放在两个字节中说明它是two-byte-header格式。
RTP填充数据
RTP头中的P位用于标识RTP包中是否有填充数据。如果P位为1说明RTP包中含有填充数据。 当RTP包中包含有填充数据时其数据包的最后一个字节记录着包中填充字节的个数即图中的Padding Size部分。
如果Padding Size为5说明RTP包中共有5个填充字节其中包括它自己。在解析RTP Payload部分之前应将填充部分去掉。去掉填充字节的算法也非常简单首先读取RTP包的最后一个字节取出填充字节数然后从最后一个字节算起将其前面的Padding Size个字节丢掉即可。
参考
李超《WebRTC音视频实时互动技术:原理、实战与源码分析》 https://weread.qq.com/web/reader/377320f07260a55337761c1kc81322c012c81e728d9d180
