网站上线后想修改,制作网站的软件有哪些,安全协议书 网站开发公司,小程序定制开发多少钱一年Android IOS WebRTC 音视频开发总结#xff08;八十七#xff09;-- WebRTC中丢包重传NACK实现分析 本文主要介绍WebRTC中丢包重传NACK的实现#xff0c;作者#xff1a;weizhenwei #xff0c;文章最早发表在编风网#xff0c;微信ID#xff1a;befoio 支持原创#x… Android IOS WebRTC 音视频开发总结八十七-- WebRTC中丢包重传NACK实现分析 本文主要介绍WebRTC中丢包重传NACK的实现作者weizhenwei 文章最早发表在编风网微信IDbefoio 支持原创转载必须注明出处欢迎关注我的微信公众号blacker微信IDblackerteam 或 webrtcorgcn。 在WebRTC中前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码纠错码连同数据包一起发送到接收端接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后发送NACK报文到发送端发送端根据NACK报文中的序列号在发送缓冲区找到对应的数据包重新发送到接收端。NACK需要发送端发送缓冲区的支持RFC5104[2]定义NACK数据包的格式。 本文在研究WebRTC源代码的基础上以Video数据包的发送和接收为例深入分析ANCK丢包重传机制的实现。主要内容包括SDP协商NACK接收端丢包判定NACK报文构造、发送、接收和解析RTP数据包重传。下面分别详细论述之。 一、SDP协商NACK NACK作为RTP层反馈参数和Video Codec联系在一起。WebRTC在初始化阶段创建PeerConnectionFactory对象在该对象中创建MediaEngine其中的VideoEngine为WebRtcVideoEngine2。该对象在构造时会收集本端支持的所有Video CodecNACK作为Codec的属性被一起收集。在接下来的SDP协商过程中NACK属性被协商到Offer/Answer中如图1所示。 图1 SDP协商NACK及作用于Video JitterBuffer PeerConnection在CreateOffer时收集本端的会话控制信息、音视频Codec信息和网络信息等内容。视频Codec信息从WebRtcVideoEngine2中获取。最后本端Offer形成SDP报文经过PeerConnection对象发送到网络。 接收端在收到Offer之后首先调用SetRemoteDescription根据本地配置信息向下创建VideoReceiveStream对象本地NACK配置信息会最终到达VCMJitterBuffer。接着PeerConnection调用CreateAnswer生成Answer根据Offer中的Codec信息和本端支持的Codec信息最终选定双方都支持的Codec集合。最后用生成的Answer作为参数调用SetLocalDescription根据Answer中的Video Codec信息向下重新创建VideoReceiveStream对象。NACK信息向下传递最终到达VCMJitterBuffer在这里设置NACK相关参数。这些参数在接收RTP数据包过程中发挥作用比如判断丢包、是否发送NACK报文等。Answer发回发送端时发送端调用SetRemoteDescription执行同样的设置流程。 二、接收端丢包判定 Video接收端丢包判定在Worker线程中进行。RTP数据包到达接收端后经过RTP模块到达VCM模块的JitterBuffer对象最终调用VCMJitterBuffer的InsertPacket函数对数据包进行缓存和重排。 VCMJitterBuffer把丢失RTP数据包的序列号存储在集合missing_seq_nums中。对于本次从RTP模块到来的数据包标记其序列号为seq1而上次到达数据包的序列号为seq2。如果seq1 seq2则表示seq1顺序到达标记(seqnum2, seqnum1)区间内的数据包为丢失状态将其存储到missing_seq_nums集合中。注意这里的丢失状态是暂时的如果下个数据包到达时有seq1 seq2则表示数据包乱序到达则把missing_seq_nums中小于seq1的序列号都删除掉。 在更新missing_seq_nums集合时如果集合中存储的序列号超过预设的容量则通过调用RecycleFramesUntilKeyFrame()不断丢包来减少集合中的序列号直到集合中的序列号总数低于预设容量值。 三、NACK报文发送和接收 接收端的NACK报文构造和发送工作在ModuleProcessThread线程中周期性完成。过程如图2所示。 图2 NACK报文构造和发送 ModuleProcessThread线程周期性调用VideoReceiver::process函数该函数通过VCMReceiver调用VCMJitterBuffer::GetNackList从missing_seq_nums集合中得到过去一段时间内丢失RTP数据包的序列号。然后调用RtpStreamReceiver::ResendPackets函数。调用流程最终会到达RTCPSender::SendRTCP发送类型为NACK的RTCP报文。 NACK报文是类型为205的RTCP 扩展反馈报文如图3所示 图3 NACK报文格式 其中PT 205FMT 1Packet identifier(PID)即为丢失RTP数据包的序列号Bitmao of Lost Packets(BLP)指示从PID开始接下来16个RTP数据包的丢失情况。一个NACK报文可以携带多个RTP序列号NACK接收端对这些序列号逐个处理。 NACK报文构造完成以后发送到网络层。NACK报文是RTCP报文的一种因此其发送、接收和分析遵循RTCP报文处理的一般流程。这部分内容可参考文档[3]。 四、RTP数据包重传 接收端在接收和解析NACK报文后通过回调机制处理各种类型的RTCP报文对于NACK报文会调用RTPSender重新发送RTP数据包如图4所示 图4 发送端数据包重传 RTCPReceiver在解析RTCP之后得到RTCP报文的描述结构然后通过回调进行报文语义处理。NACK报文会被发送到RTPSender进行处理。RTPSender根据NACK报文中包含的序列号到RTPPacketHistory缓存中查找对应的RTP数据包。如果找到则把数据包发送到网络。 至此一个完整的NACK报文回路完成丢失的RTP数据包会重新发送到接收端。 五、总结 本文深入分析了WebRTC内部关于丢包重传(NACK)的实现细节对NACK的SDP协商、丢包判定和重传进行深入研究为继续学习掌握WebRTC的QoS机制奠定基础。 参考文献 [1] RFC5109 - RTP Payload Format for Generic Forward Error Correction. [2] RFC5104 - RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) . [3] WebRTC中RTP/RTCP协议实现分-http://www.jianshu.com/p/c84be6f3ddf3. posted on 2016-12-09 11:02 RTC.Blacker 阅读(...) 评论(...) 编辑 收藏 转载于:https://www.cnblogs.com/lingyunhu/p/rtc87.html
