RTCP扩展反馈报文的接收与WebRTC中的NACK重传

最新推荐文章于 2024-07-20 00:01:42 发布
最新推荐文章于 2024-07-20 00:01:42 发布
阅读量150 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： webrtc 网络 WebRTC
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/WaJulia/article/details/133095285
WebRTC 专栏收录该内容
128 篇文章 ¥59.90 ¥99.00
订阅专栏
本文介绍了RTCP扩展反馈报文在WebRTC中的作用，特别是NACK重传功能，用于通知发送端数据包丢失并请求重传。通过监听和解析RTCP包，接收端可以实现NACK处理，提高实时通信的稳定性和可靠性。

WebRTC是一项用于在浏览器之间实现实时通信的技术，它为实时音视频通话提供了强大的支持。RTCP（Real-Time Control Protocol）是WebRTC中用于传输控制信息的协议之一，而扩展反馈报文则是RTCP中的一种重要功能。

RTCP扩展反馈报文（RTCP Extended Feedback Message）是一种用于通知发送端有关接收端解码和播放情况的消息。其中，NACK（Negative Acknowledgement）重传是RTCP扩展反馈报文中的一项重要功能，用于告知发送端某些数据包未能正确接收，并请求发送端进行重传。

本文将介绍RTCP扩展反馈报文的接收过程，并提供相应的源代码示例，以便读者能够更好地理解和运用该功能。

首先，我们需要在WebRTC的基础上添加对RTCP扩展反馈报文的支持。具体而言，在接收端的代码中，我们需要监听RTCP包并解析其中的扩展反馈报文。以下是一个简化的示例代码：

// 监听RTCP包
pc.oniceconnectionstatechange = function(
了解本专栏 订阅专栏 解锁全文
【粗读webrtc】RTCP扩展反馈报文 接收 触发 nack重传
突围
06-27 875
RTCP扩展反馈报文 webrtc的rtp重传代码分析 rtp也有nack机制，webrtc基于rtp实现了重传在一定程度上保证可靠性。 rfc4585，看到了这么一段 : RTCP扩展反馈报文，有一种nack报文 当FMT=1并且PT=205时，代表此报文是个NACK报文 Name Value Brief Description RTPFB 205 Transport layer FB message PSFB 206 Pyload-specific FB message .
【粗读webrtc】NACK 重传 :RtpPacketHistory NackList
突围
06-26 599
webrtc支持RTPFB和PLI FB两种重传方式 建立连接时，写入SDP O:\WEBRWTCSTORE\webrtc-checkout\src\media\engine\webrtc_video_engine.cc void AddDefaultFeedbackParams(VideoCodec* codec) { // Don't add any feedback params for RED and ULPFEC. if (codec->name == kRedCodecNam.
WebRTC RTCP RTP Feedback
clark的专栏
04-09 1217
作为WebRTC RTCP消息中的一种，RTP Feedback包含的内容很多，所以这里单独介绍。 在RTCP Header中，这类消息的负载类型Payload Type=205，反馈消息类型FMT如下： FMT Name Long Name Description Reference 1 NACK Generic negative acknowledgement 丢包重传请求 RFC4585 3 TMMBR Temporary Maxi
借助rtcp实现NACK丢包重传
好记性不如写博客！
10-10 5410
Qos.NACK 一、RTP/RTCP RTP/RTCP协议是流媒体通信最基本协议。RTP协议定义流媒体数据在互联网上传输的数据包格式，而RTCP协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。在很多项目中，如WebRTC中，RTP/RTCP模块作为传输模块的一部分，负责对发送端采集到的媒体数据进行进行封包，然后交给上层网络模块发送；在接收端RTP/RTCP模块收到上层模...
RTP 控制协议 (RTCP) 反馈用于拥塞控制
03-16 1887
有效的 RTP 拥塞控制算法，需要比标准 RTP 控制协议(RTCP)发送方报告(SR)和接收方报告(RR)数据包提供的关于数据包丢失、定时和显式拥塞通知 (ECN) 标记的更细粒度的反馈。本文档描述了 RTCP 反馈消息，旨在使用 RTP 对交互式实时流量启用拥塞控制。反馈消息设计用于基于发送方的拥塞控制算法，其中 RTP 流的接收方向发送方发送回 RTCP 反馈数据包，其中包含发送方执行拥塞控制所需的信息。
RTCP 协议的 NACK 报文
qq_28581781的博客
09-13 3409
接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传。 相对ARQ带来的改进：减少的反馈包的频率和带宽占用，同时也能比较及时地通知发送方进行丢包重传。 NACK 报文的定义在[rfc4585]文档中定义。 RTCP 的反馈报文包头定义如下，FMT 和 PT 决定了该报文的类型，FCI 则是该类型报文的具体负载： 转存失败重新上传取消转存失败重新上传取消 version (V): 2 bits 该字段标识RTP版本。当前版本是2 padding (P): 1 bit 如果...
WEBRTC 的RTP/RTCP的 NACK, PLI，SLI,FIR
thehunters的专栏
08-23 1605
在网络环境不是太好的情况下，比如网络拥塞比较严重，丢包率可能比较高，简单实用NACK重传的机制，这样就会有大量的RTCP NACK报文，发送端收到相应的报文，又会发送大量指定的RTP报文，反而会增加网络的拥塞程度，可能导致更高的丢包率，导致接收端解码失败，导致花屏等马赛克现象。
Webrtc nack
fdsafwagdagadg6576的专栏
04-11 656
Nack 协议头 Nack: webrtc 10ms发送一次？ Nack重传分成两种类型的包，不仅仅是重传rtp 报文 PID（Packet identifier），即为丢失的 RTP 数据包的序列号 BLP（Bitmao of Lost Packets），通过掩码的方式指出了接下来 16 个数据包的丢失情况 Packet identifier(PID)即为丢失RTP数据包的序列号，Bitmap of Lost Packets(BLP)指示从PID开始接下来16个RTP数据包的丢失情况..
简述WebRTC中的丢包重传Nack的实现
chenquangobeijing的专栏
03-04 1038
RTCP FB Nack包如上图所示：pt=205，fmt=1，PID是丢包的起始序列号-2字节，BLP表示起始序列号后面16位丢包情况，1是丢包，0是没丢包。这是WebRTC中的SDP，原视频流PT是96，重传RTX PT是97， ssrc-group是原视频流ssrc和RTX ssrc。sender ssrc是发送RTCP NACK包这端发送视频rtp包的ssrc，media ssrc是随机生成的。接收端发现序列号不连续，发送RTCP FB Nack包，发送端从历史队列中查找该包，再发送RTP包，
RTCP丢包重传策略之NACK
qq_41681715的博客
01-07 1384
NACK全称Negative acknowledgements，相关具体描述可以查看rfc4585(NACK)文档。如果音视频收发双发都支持RTCP-NACK，当接收端认为发送端过来的RTP数据有丢包，这时接收端会向RTCP(NACK)的报文，请求发送端发送网络传输过程中丢掉的RTP数据包，同一个RTCP-NACK反馈包，可以请求发送端重传多个RTP包，下面主要讲下NACK格式的RTCP报文的主要组成部分： typedef struct rtcp_header { #if __BYTE_ORDER ==
rtcp nack 重传抓包
07-10
rtcp nack 重传抓包
RTCP 报文格式
12-06
RTCP 报文格式 英文版
深入浅出WebRTC—NACK
最新发布
程序员老六的专栏
07-20 3211
WebRTC NACK 的实现简单明了，发送端缓存报文，接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求，实现相对简单一些，重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求，实现会相对复杂一些，由于存在报文乱序，什么时候发起 NACK 请求是一个值得斟酌的事情。除此之外，WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等，这些都凸显了 WebRTC 对细节的掌控和重视。
WebRTC RTCP
clark的专栏
04-06 1001
RTCP作为RTP控制协议，对于弱网下音视频质量和会话控制具有重要的作用。 RTCP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
RTCP介绍及发送间隔控制
热门推荐
风清扬的博客
09-22 1万+
1、简述 RTP实时传输协议，广泛应用于流媒体传输应用场景，根据rfc3550介绍，RTP协议应用场景有如下几种： Ø  简单多播音频会议（Simple Multicast Audio Conference） Ø  音频和视频会议（Audioand Video Conference） Ø  混频器和转换器（MixersandTranslators） Ø  分层编码（LayeredEnco
流媒体基础-RTCP
键盘敲的劈啪响
01-10 1744
RTCP对于流传输QoS起着至关重要的作用
音视频传输(RTP/RTCP)丢包重传(NACK)，以及I帧申请(PLI，FIR)
qq_41681715的博客
11-19 8252
学过TCP通信原理的同学都知道，TCP没法送一个TCP报文，TCP协议栈都要等对端的ACK确认，才能确定是否进行报文重传或者发送下一包数据；然而RTCP的NACK重传机制与TCP的确认机制整好相反，当RTP接收端发现某一包数据或者N包数据确实没有收到，即在经过中间网络设备时丢掉了，接收端才会向发送端发送RTCP的NACK报文，向发送端要求重传相应的RTP包，NACK报文如下： 特别注意，使用NACK重传机制的收发双发，RTP都有一个发送缓冲区和接收缓冲区，缓冲区有缓冲区大小，发送太迟的NACK申请报文
WebRTC-RTP/RTCP协议分析
简单生活
12-10 2606
RTP：RFC3550 SRTP（安全）：RFC3711 主要字段说明 P（padding）：1 比特，若填充比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充字节。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。 由于Opus的包大小差不太多，但又不完全一样，所以会出现很多大小差不多却又不一样的小包，这对于服务器GSO发送这些包会带来很大的困难，所以通过增加几个字节的padding，可以
音视频传输协议(RTSP/RTP/RTCP)(十三)
irainsa的博客
03-07 1189
RFC3550,对应的中文版RFC3550中文版RTP被定义为在一对一或者一对多的传输情况下工作，其目的是为了提供时间信息和实现流同步。RTP的典型应用是建立在UDP上的，也可以建立在TCP等其它协议之上进行工作，一般将其看作传输层的一部分，位于UDP层之上，应用层之下，它不保证数据传输的可靠性RTCP为RTP提供服务质量保证，其主要功能为：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识。RTCP协议是基于每隔一段时间给会话的所有参与者发送一些控制包的机制。
RTP音视频FEC与NACK丢包重传技术演示项目
该项目支持 NACK 表明其具备完整的 RTCP（RTP Control Protocol）反馈通道处理能力，能够解析 SR/RR、SDES 及 NACK 类型的 RTCP 报文，并实现相应的重传逻辑。 项目结构以“客户端”和“服务端”划分，说明其采用了...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值