- 博客(36)
- 收藏
- 关注
RSS订阅原创 janux源码走读（五）Janus事件处理模块（events/）
本文介绍了Janus事件处理模块的架构设计与实现方式。该模块采用分层架构，核心组件包括事件处理器、事件分发器和事件传输通道。支持三种事件处理方式：MQTT事件处理基于paho.mqtt.c库实现跨服务异步通知，RabbitMQ事件处理通过AMQP协议实现高可靠批量传输，简单事件处理则采用本地队列实现同步处理。每种方式都通过事件类型位掩码实现精细化订阅，并通过janus_events_init初始化注册到核心模块。架构图清晰展示了各组件关系，代码示例和流程图则具体说明了不同事件处理方式的工作原理与实现细节。
2025-12-23 21:45:00
790
原创 janux源码走读（四）Janus传输模块（Transports/）
摘要 Janus传输模块采用标准接口架构，核心通过janus_transport_interface统一管理多种传输协议。REST协议基于libmicrohttpd实现HTTP服务，通过路由分发处理JSON请求；MQTT协议利用paho.mqtt.c库实现异步消息订阅/发布；Nanomsg协议提供IPC通信能力。各协议独立实现，仅负责传输层功能，与业务逻辑解耦。架构支持REST、MQTT、Nanomsg、Unix套接字、RabbitMQ和WebSocket等多种协议，通过统一接口与核心交互，实现灵活可扩展的
2025-12-23 21:15:00
612
原创 janux源码走读（三）Janus插件模块（plugins/）
摘要 本文分析了Janus视频会议系统的核心架构与功能实现。系统采用模块化设计，WebRTC客户端通过Janus Core与各功能插件交互，包括视频会议(SFU)、音频桥接、流媒体等。重点剖析了视频会议插件的房间管理与用户状态机制： 房间管理：通过哈希表维护房间状态，支持创建/销毁房间，配置带宽等参数，核心数据结构包括参与者列表和发布者列表。 用户管理：实现用户加入/离开流程，处理主持人权限自动转移，采用事件驱动方式通知状态变更。发布者加入时自动启动SFU媒体转发。 源码实现：展示了房间创建、销毁以及用户加
2025-12-22 20:45:00
642
原创 janux源码走读（二）核心模块（src/）
Janus采用SFU架构，专注于WebRTC协议栈处理和媒体流转发，不参与媒体编解码等处理。其核心模块包括： DTLS模块：实现安全传输层，为SRTP提供密钥交换，通过SSL/TLS握手确保媒体传输安全。 ICE模块：处理NAT穿透，通过收集候选地址建立最优网络路径，支持STUN/TURN协议。 RTP模块：负责实时媒体数据传输，包含包头处理、序列号管理和数据包转发功能。 RTCP模块：提供RTP控制协议支持，实现丢包反馈、带宽自适应等QoS机制。 各模块协同工作，Janus作为中间层高效转发媒体流，客户端
2025-12-22 20:30:00
832
原创 janux源码走读（一）源码结构
Janus的智慧在于：它不试图成为一切，而是专注于自己能做得最好的部分——让WebRTC的潜力真正释放出来。请求认证、配置文件解析、日志、事件处理通知、录音录像、抓包…实用工具 Tools and utilities。事件处理 Event Handlers。WebSocket信令（创建房间）传输 Transports。，不涉及编解码或NetEQ。SIP信令（INVITE）返回SDP offer。通过SIP网关转发媒体。插件 Plugins。发送RTP（视频流）创建WebRTC会话。
2025-12-21 23:18:25
787
原创 mediasoup源码走读（十三）——Transport
摘要： Mediasoup的Transport模块作为核心网络传输通道，实现了WebRTC/PlainRTP/Pipe等协议的抽象统一，提供ICE/DTLS协商、带宽自适应等能力。其工作流程包含创建、连接、媒体传输三个阶段，通过Worker进程管理Transport实例，与Router协同实现媒体路由。关键交互包括：Transport与Worker的IPC通信、Transport在Router的注册管理、Producer/Consumer的RTP包收发处理。代码层面通过C++类实现生命周期管理（创建→活跃→
2025-12-17 20:45:00
1742
原创 mediasoup源码走读（十二）——router
Mediasoup Router是媒体流处理的核心枢纽，负责协调Producer、Consumer和Transport之间的交互。作为多方会议的逻辑容器，Router管理RTP包的路由转发，支持Simulcast/SVC编码层切换等动态策略。其生命周期包括创建时注册到Worker进程，管理Producer的媒体流发布和Consumer的订阅，以及通过Transport建立网络通道。关键交互包括：Worker创建Router实例，Router管理Producer/Consumer的注册与关闭，Transpor
2025-12-16 22:00:00
881
原创 mediasoup源码走读（十一）——consumer
Consumer 是 Mediasoup 中负责接收和处理媒体流的核心模块，主要功能包括订阅 Producer 的媒体流、处理 RTP/RTCP 数据包、自适应接收策略以及支持多层编码流。其生命周期由 Router 管理，通过 Transport 接收数据并与 Producer 交互。关键流程包括创建 Consumer 实例、注册回调、接收和处理 RTP 包、转换为可播放格式并传递给应用层，最后完成资源清理。代码实现涵盖了与 Router、Transport 和 Producer 的交互逻辑，以及媒体流处理
2025-12-16 21:30:00
694
原创 mediasoup源码走读（十）——producer
本文深入剖析了Mediasoup中Producer的核心定位与模块交互机制。Producer作为媒体流源，通过与Router、Transport、RtpObserver和Consumer的协同工作，构建完整的实时媒体流管理系统。文章详细阐述了端到端工作流程，包括Producer创建、媒体传输、质量监控和资源清理等关键环节。通过核心代码分析，展示了Producer与各模块的交互细节：Router负责生命周期管理，Transport处理RTP包传输，RtpObserver进行质量监控并触发自适应策略调整，Con
2025-12-15 21:15:00
1015
原创 mediasoup源码走读（九）——RtpObserver
摘要：RtpObserver是Mediasoup的实时媒体质量监控模块，通过毫秒级采集RTP/RTCP数据包计算丢包率、延迟、Jitter等关键指标。其核心优势在于低延迟（内置事件驱动）、低CPU开销，相比传统RTCP解析或抓包方案更适合实时场景。工作流程包括创建注册、RTP包处理（更新统计/阈值检测）和事件触发三部分，支持通过JavaScript API配置监控间隔（默认1s）和各项质量阈值（如10%丢包率）。内部采用指数加权算法计算Jitter等指标，并通过定时器周期性检查阈值，触发自适应策略。
2025-12-15 21:00:00
1278
原创 mediasoup源码走读（八）——级联
本文介绍了Mediasoup级联架构及其负载均衡实现原理。级联通过将不同媒体流分配到不同Worker实现负载分担，而非简单的流量转发。文章详细说明了级联工作流程：当WorkerA上的客户端订阅WorkerB的Producer时，通过PipeTransport请求并转发媒体流。配置示例展示了如何规划Worker部署范围（如WorkerA处理0-499流，WorkerB处理500-999流）及具体实现方法，包括创建PipeTransport和根据Producer ID路由到对应Worker。级联能有效分散大规模
2025-12-14 11:24:03
640
1
原创 mediasoup源码走读（七）——SVC
本文介绍了SVC（可伸缩视频编码）在Mediasoup中的实现架构和核心机制。SVC采用端到端带宽感知的自适应编码架构，通过分层编码解决传统方案的三大问题：码率动态调整（响应时间50ms）、网络波动适应（基础层独立解码）和码率分配效率（按需生成增强层）。核心模块包括发送端的VideoEncoder、Svc和RtpStreamSend，以及接收端的RtpStreamRecv、Svc和VideoDecoder，通过BitrateAdjuster进行带宽调度。关键实现包括：发送端根据带宽动态生成多层视频流（基础层
2025-12-14 11:21:39
559
原创 mediasoup源码走读（六）——NetEQ
文章摘要： 本文详细解析了WebRTC中的NetEQ模块架构与核心机制。发送端通过RtpCache管理数据包缓存（音频50包/视频200包），采用LRU淘汰策略并防止NACK洪水攻击。NACK处理模块在重传率>10%时主动降码率20%-30%，FEC生成模块为音频/视频分别设置3:1和2:1冗余比。接收端通过JitterBuffer实现抖动缓冲，结合NACK和PLI机制保障传输可靠性。带宽估计模块针对音频（平滑系数0.95）和视频（0.8）采用差异化算法，动态调整传输码率。所有机制均通过原始指针操作和
2025-12-13 15:38:10
815
1
原创 mediasoup源码走读（五）——RTP流处理
fill:#333;color:#333;color:#333;fill:none;important;important;important;important;发送RTP包存储RTP包遍历Consumer处理RTP包发送RTP包检测丢包转发请求RTX发送RTX包转发推流客户端RouterProducerConsumer观看客户端NACK请求完整生命周期推流客户端发送RTP包 → WebRtcTransportRouter接收RTP包，存储到Producer。
2025-12-13 15:36:09
899
原创 mediasoup源码走读（四）woker
摘要： Mediasoup的核心架构分为业务层、传输层、媒体处理层和基础设施层。Worker作为总控中心，管理Router（房间）和WebRtcTransport（传输通道）。Router协调Producer（媒体生产者）和Consumer（媒体消费者），通过WebRtcTransport实现数据传输。传输层依赖IceHandler处理网络连接、DtlsHandler实现加密通信，RtpReceiver处理RTP数据包。Producer发送RTP数据，Consumer接收并解码媒体流。整体采用分层设计，模块
2025-12-07 21:56:34
931
原创 mediasoup源码走读（三）Node.js 控制面
本文分析了WebRTC媒体服务器的架构设计，重点阐述了Node.js控制面与C++数据面的双层架构实现。系统通过Channel和PayloadChannel实现跨进程通信，Router作为媒体流容器管理Producer/Consumer的生命周期。详细展示了信令交互、路由器创建、生产者/消费者管理等核心模块的时序流程与类关系，并提供了关键源码实现说明。架构支持WebRTC、RTP/RTCP等多种协议接入，通过事件驱动机制实现高效的媒体流转发控制。
2025-12-07 21:53:51
671
1
原创 mediasoup源码走读（二）环境搭建与 Demo 运行
Mediasoup环境搭建主要分为四个步骤：依赖安装、编译核心、配置Demo和启动运行。核心依赖包括Node.js（推荐v16/v18 LTS）、Python 3.6+和C++编译工具链。不同系统安装方法各异：Windows需安装Visual Studio Build Tools，macOS需Xcode命令行工具，Linux需gcc等基础工具。获取官方Demo后，需分别安装前后端依赖，其中后端安装会触发C++核心编译。配置文件server/config.js可调整服务器监听IP、端口等参数。最后通过npm
2025-11-30 13:46:40
771
原创 mediasoup源码走读（一）概述
Mediasoup源码结构分为C++核心层(worker/)和Node.js控制层(src/)，核心功能包括WebRTC传输、生产者/消费者模型及RTP流处理。实时通信场景中，客户端通过ICE候选交换、DTLS连接建立媒体传输，由Router处理RTP包并进行带宽自适应调整。关键文件包括WebRtcTransport.cpp、Producer/Consumer.cpp等核心模块，以及Node层的Worker/Router管理类。
2025-11-30 13:44:49
673
原创 webrtc代码走读（十七）-音频QOS-NetEQ
WebRTC音频QoS技术通过NetEQ模块解决网络抖动和丢包问题。发送端采用3A算法预处理音频，接收端NetEQ通过抖动缓冲、丢包补偿和压缩解码三大功能确保流畅播放。NACK协议实现丢包重传，FEC冗余协议和交织编码则分别通过嵌入冗余数据和分散传输降低丢包影响。源码分析显示，NetEQ动态调整缓冲区大小并生成伪音频帧，而NACK和FEC通过智能重传和冗余编码协同保障音频质量。该技术形成了发送预处理、网络稳传和接收后处理的闭环系统，有效提升实时音频体验。
2025-11-24 18:55:47
827
原创 webrtc代码走读（十六）-QOS-音频QOS-3A算法
WebRTC音频前处理3A算法摘要：AEC（回声消除）、AGC（自动增益控制）和ANS（噪声抑制）共同保障音频质量。AEC通过分析参考信号消除回声；AGC动态调整音量保持舒适听感；ANS识别并抑制环境噪声。源码实现上，AEC3模块处理回声路径估计与双讲检测，AGC通过数字增益平滑调整音量，ANS则在频域过滤噪声。这些算法通过AudioProcessing类统一调度，按帧实时处理音频数据，最终输出清晰稳定的语音信号。
2025-11-16 21:07:24
1139
原创 webrtc代码走读（十五）-QOS-Pacer
文章摘要 PACER模块旨在解决视频数据传输中的网络拥塞问题。由于视频帧大小差异显著，直接发送可能导致网络波动，尤其在WiFi环境下影响通话质量。PACER通过优先级队列管理音频、视频、重传等报文，确保高优先级数据（如音频、重传）优先发送，同时动态调整发送节奏。核心通过NextSendTime和ProcessPackets函数控制发送周期（如固定5ms间隔），实现数据平稳发送，减少延迟和卡顿。优先级规则基于报文类型、重传标志及时间戳，优化弱网环境下的传输效率。
2025-11-02 19:09:33
963
原创 webrtc代码走读（十四）-QOS-Jitter
本文深入剖析了WebRTC中处理网络抖动的核心机制，重点分析了视频Jitter Buffer的实现原理。主要内容包括：1）Jitter的本质是网络数据包到达时间波动，WebRTC通过动态缓冲区和延时计算来平衡卡顿与延迟；2）详细拆解了视频RTP数据包从接收到组帧的完整流程，涉及15个关键函数调用；3）重点解读了PacketBuffer插入机制、首帧验证及帧参考关系管理等核心代码实现，展示了WebRTC如何通过精细的缓存策略和时间戳处理来应对网络抖动问题。文章通过源码级分析，揭示了实时音视频通信中保障流畅播放
2025-11-01 22:38:17
1192
原创 webrtc代码走读（十三）-QOS-帧率调控机制
WebRTC帧率调控通过全链路动态调整保障视频流畅性与画质平衡。核心机制包括：1）采集端根据摄像头性能与环境光调整帧率；2）编码端通过直接丢帧或漏桶算法应对编码性能不足与网络带宽限制；3）传输与解码端丢弃不完整帧确保稳定性。发送端作为调控重点，采用直接丢帧（应对编码瓶颈）与漏桶算法（平滑码率控制）两种策略，其中漏桶算法通过Fill-Leak-Drop流程实现帧率动态优化。该设计有效解决摄像头过载、编码瓶颈和网络波动等QOS问题，但渲染端堆积问题仍需优化。
2025-10-31 23:42:31
797
原创 webrtc代码走读（十二）_QOS_Transport-cc协议与RTP扩展头
Transport-cc协议是WebRTC中基于RTCP反馈报文的拥塞控制机制，通过动态调整码率保障实时音视频传输质量。其核心结构包括：1）报头标识字段；2）SSRC源标识；3）控制参数（序列号、包状态计数等）；4）packet chunk状态编码（行程编码Run length或状态向量Status vector）；5）到达时间差recv delta（1/2字节存储）。该协议通过压缩反馈信息实现高效拥塞评估，其中packet chunk采用两种编码方式优化存储效率，recv delta则根据时间间隔大小智能
2025-10-30 22:06:41
723
原创 webrtc代码走读（十一）-QOS-拥塞算法、Probe探测与码率配置
Probe探测算法摘要 Probe探测算法是解决GCC算法"快降慢升"问题的带宽快速探测机制，包含启动阶段和网络变化阶段两个应用场景。该算法通过发送端发送探测数据包并记录发送时间/序列号，接收端反馈接收码率，最终取发送码率与接收码率的最小值作为实际发送码率。核心由ProbeController等5个模块协同实现，采用指数级探测策略（3倍→6倍起始码率）。算法通过比较发送/接收时间间隔和数据量计算带宽，当接收码率低于发送码率的90%时会自动调整目标码率以避免拥塞。这种主动探测机制能快速适应
2025-10-29 22:20:13
955
原创 webrtc代码走读（十）-QOS-Sender Side BWE原理
WebRTC 带宽估计（BWE）是决定视频通话质量的关键模块，其算法经历了从基于丢包的被动响应到基于延迟的主动预测的演进。Sender Side BWE 作为最新方案，将计算逻辑迁移至发送端，通过三大核心机制实现动态码率调整：1）兼容旧版本的 REMB 反馈；2）基于丢包率的直接调整（2%-10%丢包率阈值）；3）基于延迟的趋势预测（通过 Trendline 滤波器分析包组延迟）。最终采用三者最小值作为发送码率，在避免网络拥塞的同时最大化视频质量。该方案相比传统接收端计算的 GCC 算法，显著减少了反馈延迟
2025-10-28 22:44:12
939
原创 webrtc代码走读（九）-QOS-SVC（可分级视频编码）
SVC（可适性视频编码）是H.264/AVC的扩展技术，通过时间、空间和质量的灵活分层实现视频流的自适应传输。其核心优势在于"一次编码，多端适配"，有效降低编码开销。时间分层通过帧间预测实现帧率调整，空间分层支持分辨率动态变化，质量分层则允许码率弹性控制。典型应用包括监控视频的多分辨率存储、视频会议的多终端适配以及抗网络丢包场景。OpenH264等开源库已实现SVC编码功能，通过分层参数配置满足不同场景需求，显著提升视频传输效率与兼容性。
2025-10-27 22:59:57
1446
原创 webrtc代码走读（八）-QOS-FEC-flexfec rfc8627
WebRTC通过三种FEC方案实现媒体传输冗余保护。UlpFEC（RFC5109）仅支持VP8/VP9编码，FlexFEC（RFC8627）兼容性更广，InbandFEC专为Opus音频设计。FEC核心原理是将M个媒体包异或生成N个冗余包，允许丢失不超过N个包时仍能恢复数据。FlexFEC相比UlpFEC优势明显：支持独立SSRC/Sequence、无编码格式限制、避免NACK误触发等。目前FlexFEC主要实现1D列异或模式（针对突发丢包），2D模式虽理论更强但未实现。WebRTC源码显示，UlpFEC因
2025-10-26 19:24:21
1147
原创 webrtc代码走读（七）-QOS-FEC-ulpfec rfc5109
文章摘要： ULPFEC（非均匀级别保护前向纠错）是WebRTC中提升实时通信质量的关键技术，其核心原理是通过预先发送冗余数据包（FEC包）来应对网络丢包。FEC包采用分层结构：RTP头标识基础信息，FEC头定义保护范围（如掩码标记被保护的媒体包），ULP Level头实现分级保护（Level 0保护少量包，Level 1增强保护）。通过XOR算法生成恢复字段，接收方可在丢包时逆向还原数据。例如，发送4个媒体包（A-D）时附加2个FEC包，分别保护A/B和C/D组合，确保任意丢包均可修复。该技术显著提升了弱
2025-10-26 18:40:33
837
原创 webrtc代码走读（六）-QOS-FEC冗余度配置
WebRTC中FEC冗余度配置的核心逻辑是动态调整冗余包数量以应对网络丢包。其工作流程为：接收端计算当前丢包率并通过RTCP反馈给发送端；发送端根据历史趋势预判未来丢包率（采用指数平滑等算法），通过查表确定关键帧/普通帧的冗余比例；最终按该比例生成FEC包与媒体包一起发送。整个过程通过定时触发和事件驱动的双链路实现：丢包率计算链路周期性处理网络反馈并调整冗余参数，封装链路则按最新参数为编码后的视频帧添加冗余包。系统提供三种预判策略——直接采用当前值适用于稳定网络，指数平滑适合波动网络，窗口期最大值为突发丢包
2025-10-25 19:12:05
851
原创 webrtc代码走读（五）-QOS-FEC原理
WebRTC中前向纠错(FEC)技术通过主动生成冗余数据提升抗丢包能力。文章详细解析了三种FEC方案：Red(简单冗余拼接)、Ulpfec(主流异或冗余)和Flexfec(实验性交织异或)，对比了其原理、优缺点及适用场景。其中Ulpfec作为默认方案支持动态调整冗余度，Flexfec则针对复杂丢包提供更灵活保护。文章还分析了不同编解码器的FEC适配策略，并解读了WebRTC源码中FEC的使能与封装逻辑。该技术通过牺牲部分带宽换取传输可靠性，成为WebRTC音视频传输的关键保障。
2025-10-25 18:51:59
1258
原创 webrtc代码走读（四）-QOS-NACK实现-发送端
发送端NACK实现的核心流程包括RTP报文缓存、RTCP NACK处理和RTP报文重发。发送端通过Pacer发送RTP报文时，会将允许重传的媒体报文存入packet_history_缓存队列，为后续重传提供数据源。当接收端检测到丢包并发送NACK请求时，发送端通过RTPSender::OnReceivedNack处理请求，并调用ReSendPacket重传丢失的RTP报文。关键函数包括RtpSenderEgress::SendPacket负责报文发送与缓存，RtpPacketHistory::PutRtpP
2025-10-24 21:14:23
911
原创 webrtc代码走读（三）-QOS-NACK实现-接收端
WebRTC接收端NACK机制通过实时丢包检测和定时队列检查两种方式触发。当检测到RTP报文序列号不连续时，立即触发NACK请求；同时通过周期性检查NACK队列判断是否需要重传。该机制涉及网络线程、解码线程和渲染线程的协同工作，核心函数包括NackModule::OnReceivedPacket（实时检测）和NackModule::Process（定时检查）。实现上通过检查报文序列号连续性、关键帧标记等条件，结合多线程调度完成丢包检测与重传请求的生成与处理。
2025-10-24 21:10:45
1008
1
原创 webrtc源码走读（二）-QOS-RTT
WebRTC中的RTT（环路延时）及其作用 RTT（Round-Trip Time）是数据从发送端到接收端再返回确认的时间，单位为毫秒（ms）。WebRTC通过解析RTCP协议的RR报告计算RTT，核心流程涉及多模块协作，最终由RTCPReceiver提取字段并计算。RTT直接影响抗丢包策略：低RTT（<100ms）优先使用NACK重传；中RTT（100-300ms）混合NACK和FEC；高RTT（>300ms）依赖FEC冗余。RTT还会动态调整FEC的冗余量，优化网络适应性。
2025-10-23 21:04:32
1035
原创 webrtc源码走读（一）-QOS-NACK-概述
NACK是ACK的逆向机制，用于通知数据未达。在TCP中，ACK确保可靠传输，而NACK则在丢包时触发重传请求。NACK分为包级重传（RTPFB）和帧级重传（PSFB），后者包括PLI（整帧丢失）、SLI（部分丢失）和RPSI（参考帧丢失）。WebRTC根据丢包程度自动选择策略：优先包级重传，严重时升级为帧级重传。RTCP反馈消息通过包头字段（如FMT、PT）区分类型，RTPFB（PT=205）处理包丢失，PSFB（PT=206）处理视频数据问题。FMT进一步细分反馈类型，如RTPFB的FMT=1表示通用N
2025-10-23 20:46:19
744
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人