【twcc】学习1：cc-feedback包构造及其接收处理

原创 已于 2023-06-19 11:22:02 修改 · 636 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#ffmpeg #网络

于 2023-06-19 11:21:04 首次发布
本文介绍了WebRTC中cc-feedback的实现原理，包括它如何接收和处理RTCP发送的TransportPacketsFeedback，以及cc-feedback如何利用transport-sequence-number进行包状态跟踪。重点讨论了RtpTransportControllerSend如何解析cc-feedback并进行码率预估。

  • 我的代码是m79，大神的代码看起来比我的新。核心的 ProcessTransportFeedbackInner 竟然没有找到。

  • webrtc源码分析(8)-拥塞控制(上)-码率预估 再次膜拜一下大神的分析。

  • 本文大量引用大神的论述。

  • cc-controller下最重要的几个函数来介绍码率控制的核心过程，其分别是OnProcessInterval()和OnTransportPacketsFeedback()，前者根据时间流逝定时更新码率, 后者需要借助于cc-feedback的到来才能更新码率,

接受测基于rtcp发来的report：TransportPacketsFeedback

在这里插入图片描述

cc-feedback 是一个rtp扩展:从中能得到包的接收状态和时间。

了解本专栏 订阅专栏 解锁全文
学习2：使用cc-feedback包提供的cc预估码率优化WebRTC
KnBackend的博客
09-20 237
本文将介绍如何利用cc-feedback包来实现码率的动态预估和优化，并提供相应的源代码。cc-feedback是一个基于WebRTC的码率控制反馈包，它通过网络信息的反馈来预测当前的网络状况和带宽情况，从而合理地调整传输的码率。通过使用cc-feedback包，我们可以根据实时的网络信息进行动态的码率预估和调整，从而提升用户体验。因此，控制传输的码率并进行动态调整是非常必要的。通过cc-feedback包提供的API，我们可以根据实时的网络信息进行动态的码率预估和优化，从而提高音视频传输的质量和稳定性。
【twcc】学习2：cc-feedback包送去cc预估码率
突围
06-19 584
twcc
webrtc（2）——拥塞控制算法TWCC
爱学习的CC
07-24 1500
webrtc（2）——拥塞控制算法TWCC
WEBRTC浅析（八）GCC:: Transport-wide Congestion Control的协议简析
muwesky的专栏
07-12 1318
WEBRTC浅析（八）GCC:: Transport-wide Congestion Control的协议简析 Transport-wide Congestion Control 参考文档：https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01 一：SDP协商 a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-
WebRTC媒体通信核心技术解析
gitblog_00578的博客
06-25 486
WebRTC作为实时通信领域的革命性技术，其媒体通信能力具有以下显著特点： 1. **多流支持**：支持同时传输多条独立的音视频流，并可在通话过程中动态增减 2. **编解码器无关**：协议层不限制编解码器类型，支持现有及未来可能出现的各种格式 3. **网络自适应**：能够智能应对网络条件变化，在带宽波动时自动调整传输策略 ## 基础协议架构 WebRTC媒体通信建立在两大核心协议之上： ...
【音视频】remb && twcc原理
dualvencsdn的博客
12-22 2242
TWCC全称是Transport wide Congestion Control，是webrtc的最新的拥塞控制算法。其原理是在接收端保存数据包状态，然后构造RTCP包反馈给发送端，反馈信息包括包到达时间、丢包状态等；在发送端进行带宽估计，进行拥塞控制。发送方带宽估计有什么好处？谷歌解释的理论是，通过这种方式，所有的决策逻辑都在一个地方（发送方），因此可以轻松测试新算法，因为你不依赖两个端点。老实说，考虑到浏览器自动更新，我不认为这一点有什么大的优势，但它肯定更干净，即使它在带宽使用方面更昂贵。
学习：构建和处理 WebRTC 的 cc-feedback 包
KnBackend的博客
09-24 193
在上述代码中，build_cc_feedback_packet函数接收延迟、丢包率和抖动作为输入，并将它们打包为一个字节序列。通过使用cc-feedback包，发送方可以获得接收方对媒体质量的反馈信息，从而进行实时的优化和调整。在上述代码中，handle_cc_feedback_packet函数接收一个cc-feedback包的字节序列作为输入，并逐个解析出其中的延迟、丢包率和抖动值。通过定期发送cc-feedback包，发送方可以了解到媒体传输的延迟、丢包率、抖动等信息，从而进行动态的调整和优化。
webrtc twcc接收端处理在Nginx RTC SFU 服务端的实现
xiaofeilong89的专栏
03-13 7175
twcc简介 TWCC全称是Transport wide Congestion Control，是webrtc的最新的拥塞控制算法。其原理是在接收端保存数据包状态，然后构造RTCP包反馈给发送端，反馈信息包括包到达时间、丢包状态等；在发送端进行带宽估计，进行拥塞控制。 发送方带宽估计有什么好处？谷歌解释的理论是，通过这种方式，所有的决策逻辑都在一个地方（发送方），因此可以轻松测试新算法，因为你不依赖两个端点。老实说，考虑到浏览器自动更新，我不认为这一点有什么大的优势，但它肯定更干净，即使它在带宽使用方面
【Fargo】25：基于mediasoup发rtp包及内存清理
突围
11-22 353
// Cloned ref-counted packet that RtpStreamSend will store for as long as // needed avoiding multiple allocations unless absolutely necessary. // Clone only happens if needed. std::shared_ptr sharedPacket;
大话ion系列（五）
LiveVideoStack
11-19 627
点击上方“LiveVideoStack”关注我们作者 | 王朋闯本文为王朋闯老师创作的系列ion文章，LiveVideoStack已获得授权发布，未来将持续更新。大话ion系列（一）大话i...
webrtc拥塞控制
sun007700的专栏
02-19 664
mediasoup 源码分析 （五） Congestion Control 拥塞控制 https://blog.youkuaiyun.com/lcalqf/article/details/107913613
WebRTC的transport wide cc feedback 带宽预估
linux_vae的专栏
06-19 4958
@toc 背景介绍 BWE 带宽预估，参考 https://blog.youkuaiyun.com/CrystalShaw/article/details/82981183 的文章 – 丢包预测：丢包率反应带宽情况 – 延时预测： 组包延时，多个包的到达时间delta的趋势来判断带宽情况 – 从之前GCC拥塞的接收端计算带宽并发送remb 到接收端反馈Transport cc， 由发送端sender...
webrtc twcc接收端代码分析（webrtc-m76）
qq_16135205的博客
09-01 3519
接收端twcc主要功能就是通过fb通知发送端每一个rtp的接收时间。 基本逻辑：当接收端接收到每一个rtp包的时候，记录当前的接受时间和包序号，然后按一定策略定时的发送到发送端，然后发送端可以根据的发送，接收时间统计延迟，为后续估算提供数据点。 代码分析 remote_estimator_proxy.cc文件 webrtc::RemoteEstimatorProxy类主要作用，保存窗口期的rtp包...
WebRTC RTCP RTP Feedback
clark的专栏
04-09 1238
作为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
webrtc-sdp详解
码农修仙的博客
06-17 4267
1、SDP协议简介 SDP(Session Description Protocol) 是一种会话描述协议，基于文本，其本身并不属于传输协议，需要依赖其它的传输协议（比如 SIP 和 HTTP）来交换必要的媒体信息，用于两个会话实体之间的媒体协商，详细的标注规范可参考RFC2327和RFC4566。WebRTC 中使用 Offer-Answer 模型交换 SDP，本文详细介绍SDP各属性在WebRTC中的应用。 2、SDP组成 SDP是由多行文本组成的一个纯文本协议，如果将SDP从语义上分解成不同组件来描述
webrtc(m76) video sender总结
qq_16135205的博客
09-21 3055
一. class VideoSendStream Video模块 (video_send_stream.h,video_send_stream.cc) 1.创建VideoStreamEncoderInterface. 用于对source进行编码。 2.创建VideoSendStreamImpl. 用于接收VideoStreamEncoderInterface编码后的视频数据。 ...
WebRTC[24]-WebRTC M75 Release Notes
liuzhen007的专栏
06-19 1370
WebRTC M75同样提供了Android和iOS的版本库，它包含3个新功能和50多个错误修复，增强功能以及稳定性/性能的改进措施。
流媒体学习之路(mediasoup)——GCC的Feedback信令回复（8）
qw225967的博客
07-20 1087
本文讲了mediasoup的拥塞控制接收端类，讲得稍微细一些。其实主要就两个功能产生发送端带宽估计的feedback报文、产生接收端估计的remb报文（已废弃）。remb和transport-cc两个在mediasoup中无法同时使用，所以这俩只有一个会在工作时运行，之后的文章我们会跟着分析一下webrtc的gcc算法和发送控制类——TransportCongestionControlClient。httpshttpshttps。...
【mediasoup TRANSPORT_CC 1】发送侧 RTP 头部扩展 和 接收侧 RTCP包 FeedbackRtpTransportPacket
突围
04-12 609
上一篇提到了传输拥塞控制客户端类 mediasoup 支持 ： Sender and receiver bandwidth estimation with spatial/temporal layers distribution algorithm. 使用了两种拥塞控制，TRANSPORT_CC 和REMB 参考大神文章 Recv-side Delay-based BWE：REMB-based GCC（简称REMB） Send-side Delay-based BWE：TransportFB-bas..
PS D:\cuban\work\estimate_bitrate\data> & "C:/Program Files/Python312/python.exe" d:/cuban/work/estimate_bitrate/data/get_suggestion_bitrate.py 开始解析文件: est_all.txt (共 5783 行) 调试行 290: [2025-10-16 20:05:16] [ERROR] sender_bandwidth_estimation_handler():523 - [WEBRTC]handle RR start: c... 调试行 291: [2025-10-16 20:05:16] [ERROR] sender_bandwidth_estimation_handler():500 - [WEBRTC]handle twcc start:... 调试行 292: [2025-10-16 20:05:16] [ERROR] overuse_detect():103 - [WEBRTC]current_time[753466851]: Tq[-320996.196... 成功解析292行: Tq=-320996.196148, gamma=6.0 调试行 293: [2025-10-16 20:05:16] [ERROR] sender_estimation_update():301 - [WEBRTC]loss bitrate update success, ... 调试行 294: [2025-10-16 20:05:16] [ERROR] on_bitrate_changed():443 - [WEBRTC]current_time[216595968]: [RAZOR] Su... 调试行 295: ... 解析汇总: 总行数 5783, 解析成功 2689 行, 错误 0 处 数据统计: 码率/RTT=996, 丢包率=1160, overuse=533 码率/RTT数据保存至: est_all_bitrate_rtt.csv 丢包率数据保存至: est_all_loss_rate.csv Overuse数据保存至: est_all_overuse_data.csv Overuse数据示例: timestamp_ms Tq gamma 0 753456316 0.0 12.5 1 753457149 0.0 6.0 2 753457607 0.0 6.0 处理错误: name 'generate_plots' is not defined Traceback (most recent call last): File "d:\cuban\work\estimate_bitrate\data\get_suggestion_bitrate.py", line 101, in parse_and_plot generate_plots(file_prefix, bitrate_rtt_data, loss_data, overuse_data) ^^^^^^^^^^^^^^ NameError: name 'generate_plots' is not defined
最新发布
10-18
另外，我们还可以在代码中添加更多的错误处理，比如检查generate_plots函数是否存在（但通过调整位置已经解决）。 修改后的代码： ```python import re import os import matplotlib.pyplot as plt import ...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

等风来不如迎风去

你的鼓励是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值