- 博客(17)
- 收藏
- 关注
RSS订阅原创 深入浅出SRS—RTMP实现
本文分析了 SRS RTMP 直播的实现，覆盖了单机、Edge 集群、Origin 集群、Forward 等多种场景，详细讲解了单机场景下全流程处理，重点分析了 RTMP 直播实现所需的媒体处理。
2024-09-06 20:29:19
1741
1
原创 KCP实现原理探析
KCP 是一个轻量级的、高效的、面向 UDP 的传输协议库，专为需要低延迟和高可靠性的实时应用设计。本文针对 KCP 的主要机制和实现与原理进行分析。
2024-09-06 20:08:10
1568
原创 UDT实现原理探析
和 TCP 一样，UDT 也有慢启动阶段。发送端基于设置的发包间隔不停的发包，接收端会不停的反馈 ACK，当出现以下条件之一，慢启动阶段结束：1）拥塞窗口大小增长到上限值。（这个上限值为接收端的流控窗口大小）2）发生丢包。3）EXP 定时超时。
2024-09-06 10:49:05
2320
原创 深入浅出mediasoup—拥塞控制
本文分析了 mediasoup 拥塞控制实现，重点阐述了 TransportCongestionControlClient 如何对 GCC 进行封装和适配，并对 PacedSender 实现进行了深入分析。当然还有很多细节没有涉及，比如带宽分配逻辑，后面有时间再补充。大家在自己的项目中可以借鉴 mediasoup 集成 GCC 的方案。
2024-07-30 22:02:32
1139
1
原创 深入浅出mediasoup—媒体处理
本文分析了 mediasoup 报文转发框架，以及报文流转过程中的相关处理逻辑。其中，simulcast 和 SVC 的分层切换逻辑稍微复杂一些，切换条件涉及到伸缩编码的背景知识。最复杂的是 simulcast 时间戳转换，除了计算基于 NTP 时间戳的基础偏移，还需要计算额外偏移，然后再进行调整，本文没有展开分析。
2024-07-29 16:33:00
1421
原创 深入浅出mediasoup—关键帧请求
当丢包或者解码错误导致无法正确解码视频流，或者当一个新的接收者加入到视频通话时，需要一个关键帧来恢复和开始正常解码。关键帧请求机制是确保视频流在不可靠网络环境下能够恢复和维持高质量播放的关键技术之一，mediasoup 支持关键帧请求。
2024-07-27 21:09:24
2312
原创 深入浅出mediasoup—NACK
本文分析了 mediasoup NACK 实现原理。可以看到，mediasoup NACK 实现与 WebRTC NACK 实现非常相似，但有一定程度的简化， 有理由认为借鉴了 WebRTC 实现。从代码角度看，mediasoup 的实现更加简洁，是一份优秀的 NACK 实现范本。
2024-07-27 18:01:14
1261
原创 深入浅出mediasoup—WebRtcTransport
本文重点分析了 WebRtcTransport 的静态结构及重要数据流，对于理解 mediasoup 媒体转发框架非常重要。建立 WebRtcTransport 需要经历 ICE 协商和 DTLS 协商两个阶段，本文只对其中几个比较重要的逻辑进行了分析，不涉及 ICE 协商和 DTLS 协商的协议细节，如有需要请参考其他文档。
2024-07-24 18:01:02
1270
原创 深入浅出WebRTC—Pacer
报文优先级定义如下，数字越小优先级越高（参考函数GetPriorityForType）。0 - Audio本文详细分析了 WebRTC 平滑发送模块的整体框架和实现原理，并对重要的数据结构和逻辑进行了深入剖析。平滑发送模块设计的非常灵活，采用动态发包周期和漏桶控制机制，能够满足媒体报文发送、带宽探测、高优先级报文优先发送等多种发送要求。不过，相比于固定发包周期，这种设计实现起来更加复杂性，大家在借鉴的时候，要充分评估、小心谨慎。
2024-07-23 10:17:20
1492
原创 深入浅出WebRTC—LossBasedBweV2
与带宽一样，固有丢包率（inherent loss）也是网路链路的一个属性，而且是动态变化的。当观察到丢包的时候，我们如何判断这是由于链路固有丢包率导致的丢包还是由于网络拥塞导致的丢包？除非我们知道链路的固有丢包率和带宽，但显然这是无法办到的。WebRTC 为解决这个问题打开了一扇窗，其思路是建立网络丢包的二项式分布模型，通过搜集足够多的观测值，构造目标函数，使用牛顿方法去搜索链路带宽和固有丢包率的最佳组合。然后对这个最佳组合进行必要的校正与调整。
2024-07-23 03:37:28
1352
原创 深入浅出mediasoup—协议交互
如果只是完成基本的媒体通信，相比基于 SDP 的 WebRTC 协商，使用 mediasoup的 WebRTC 协商看起来更加复杂，这种感觉是正常的。这是因为 mediasoup 使用 ORTC 接口规范，ORTC 旨在简化 WebRTC 的 API，提供更加模块化和面向对象的接口，它把 WebRTC 的一整坨 API 进行了面向对象的细粒度模块划分，能够实现更灵活的控制。
2024-07-22 12:41:55
1897
原创 深入浅出WebRTC—ULPFEC
ULPFEC 实现的核心是 FEC 保护比率的计算和掩码表的生成，FEC 保护比率决定了能使用多少 FEC 报文来保护原始报文，掩码表决定了 FEC 报文如何保护原始报文。围绕这两个核心概念，涉及如何生成 FEC 报文，如何打包和解包、如何发送和接收以及如何恢复原始报文等相关处理逻辑。
2024-07-22 02:54:18
1760
原创 深入浅出mediasoup—通信框架
本文详细描述了 mediasoup 对 libuv 的封装，覆盖了 pipe、socket、signal 等几种通信方式，重点分析了 Socket 通信的静态结构和数据流，并着重分析了 UDP 报文的异步发送机制。熟悉 mediasoup 的底层通信机制，是深入阅读 mediasoup 源码的基础。另外，mediasoup 对 libuv 的封装方案简洁清晰，值得大家借鉴。
2024-07-20 21:08:47
1841
原创 深入浅出WebRTC—NACK
WebRTC NACK 的实现简单明了，发送端缓存报文，接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求，实现相对简单一些，重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求，实现会相对复杂一些，由于存在报文乱序，什么时候发起 NACK 请求是一个值得斟酌的事情。除此之外，WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等，这些都凸显了 WebRTC 对细节的掌控和重视。
2024-07-20 00:01:42
2643
原创 深入浅出WebRTC—ALR
识别 ALR 状态对 WebRTC 的拥塞控制来说非常重要，很多人可能没有意识到这一点。为什么这么说，是因为，WebRTC 的拥塞控制算法本质上是一种“刀尖上跳舞”的算法，只有当你要求的最大带宽超过链路容量时，才需要做拥塞控制，此时 WebRTC 会在链路容量的上限疯狂试探。如果带宽随便你使用，怎么用都用不完，怎么用都不会造成拥塞，那也就没必要做拥塞控制了。ALR 状态本质上是用来标识当前带宽是否够用，进入 ALR 状态和退出 ALR 状态，所需要的控制策略是不一样的，相关算法都需要做调整。
2024-07-19 22:01:24
1636
原创 深入浅出WebRTC—DelayBasedBwe
基于延迟的带宽估计，以处于非 ALR 状态的 ACK 码率为基础，基于延迟梯度估计链路真实带宽，实现对链路带宽的动态跟踪，算法的核心逻辑可以表述为：1）网络过载，说明网络产生拥塞，当前发送码率过高，需要降低发送码率。2）网络欠载，说明网络正在排空，不要急着提升发送码率，先保持当前发送码率一段时间。3）网络正常，可以试着增加发送码率，探测下带宽的上限。同时，在网络非过载状态下，使用探测带宽对估计值进行校正，使估计更加精准。算法在计算延迟梯度、判断网络使用状况都做了精心的设计，会尽量排除随机噪声的干扰。
2024-07-19 20:46:24
2511
原创 深入浅出WebRTC—GCC
简单总结下 WebRTC 拥塞控制思路。拥塞控制的核心是获取链路的带宽，对于实时音视频通信来说，还要考虑延时指标。因为只有获得了链路的真实带宽，才能确保发送的码率不会超过链路容量，从而避免产生拥塞。那有没有一种办法，在不发送码流的情况下，提前知道链路的真实带宽呢？答案是没有。这个问题貌似变成了一个先有鸡还是先有蛋的问题。理论上是这样的，但实践中，可以采用一个带有负反馈回路的控制算法来打破这个循环魔咒，这就是 WebRTC 拥塞控制的核心思想。
2024-07-19 18:45:03
1897
8
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人