xiaofeilong89的专栏

draft-ietf-rmcat-gcc-02简介实时媒体的拥塞控制具有挑战性，原因如下：1、媒体的编码格式不能快速的适应不同的带宽，带宽需求经常被改变。2、参与者可能对如何响应有特定的期望，发现拥塞的流可能不会减少所需的带宽。3、编码通常对数据包丢失很敏感，而实时性和通过重传修复数据包丢失相排斥。本文描述了两种拥塞控制算法，它们共同能够提供良好的性能，并与使用相同拥塞控制的其他视频流以及共享相同链路的TCP流合理共享带宽。系统模型系统中包含以下元素：1、RTP pack

twcc简介TWCC全称是Transport wide Congestion Control，是webrtc的最新的拥塞控制算法。其原理是在接收端保存数据包状态，然后构造RTCP包反馈给发送端，反馈信息包括包到达时间、丢包状态等；在发送端进行带宽估计，进行拥塞控制。发送方带宽估计有什么好处？谷歌解释的理论是，通过这种方式，所有的决策逻辑都在一个地方（发送方），因此可以轻松测试新算法，因为你不依赖两个端点。老实说，考虑到浏览器自动更新，我不认为这一点有什么大的优势，但它肯定更干净，即使它在带宽使用方面

前言级联解决的主要问题是媒体分发。横向扩展：在大主播场景下，一个主播对应成千上万的观众，服务器的性能和带宽限制了观众人数的上限，为了能够支持更多的观众，需求从单个服务器扩展到集群服务器。分发质量：同样对于大规模观众来说，不同的观众分布在不同的地域，可能出现跨国或跨省传输，还有就是不同的观众对应的电信网络运营商不同，也会影响媒体分发传输质量，所以需要观众可以就近接入高质量的服务器节点。这些不同的服务器节点组成了服务器集群，服务器间的媒体分发采用级联的形式。由于网上介绍为什么需要级联SFU的文章已经很

简介PACER网络报文平滑策略是webrtc Qos策略之一，是针对数据发送端的。如果是单纯的音频数据通信，由于一帧音频数据的长度固定并且音频码率较平稳，不会出现忽高忽低的现象，可以不考虑使用pacer。但是对于视频数据来说，一帧视频的数据量可能很大，已经大于网络的MTU，尤其是I帧（关键帧）数据量更是通常远大于MTU，所以需要封装到多个RTP报文中，如果这些视频RTP报文同时一起发生到网络上可能会引起网络衰减和通信恶化。WebRTC引入Pacer，pacer会根据estimator中计算出来的码率调整发

SRS作为接收方，对端作为发送方生成Nack RTCP包的流程SrsRtcConnection::SrsRtcConnection(SrsRtcServer* s, const SrsContextId& cid){ req = NULL; cid_ = cid; hijacker_ = NULL; sendonly_skt = NULL; server_ = s; transport_ = new SrsSecurityTransport(

问题描述：SRS Version=4.0.126. 配置文件配置：listen 1935;max_connections 100;daemon off;srs_log_tank console;http_server { enabled on; listen 8080; dir ./objs/nginx/html;}http_api

RTMP转RTC；或者RTC转RTMP，是通过Bridger实现的。RTMP转RTCclass SrsRtcFromRtmpBridger : public ISrsLiveSourceBridgerRTMP推流#mermaid-svg-5GDqSCrD6tqxIolT .label{font-family:'trebuchet ms', verdana, arial;font-family:var(--mermaid-font-family);fill:#333;color:#333}#merma

在上一节中，我们知道在SrsRtcServer::listen_api()中启动了HTTP接口/rtc/v1/play/用于接收RTC播放的请求。RTC play接口分析在文件trunk/src/app/srs_app_rtc_api.cpp中。以http://127.0.0.1:8080/players/rtc_player.html中的RTC播放demo为例。http://127.0.0.1:1985/rtc/v1/play/请求参数为：api: "http://127.0.0.1:1985/r