1.SRS(simple-rtmp-server)流媒体服务器源码分析--RTMP消息play
2.2024年 C++音视频开发学习路线（ffmpeg/rtsp/srs/webrtc/hls）
3.音视频流媒体服务器搭建（直播架构、码分搭建、码分SRS流媒体及其集群部署）
4.常见流媒体服务器方案对比分析
5.SRS(simple-rtmp-server)流媒体服务器源码分析--启动
6.SRS4.0源代码分析之WebRTC服务总体介绍

SRS(simple-rtmp-server)流媒体服务器源码分析--RTMP消息play

       本章内容梳理了SRS在接收到RTMP信息后如何进行转发的码分过程。在此过程中，码分首先进行代码梳理，码分作者也在源码熟悉阶段，码分网课 APP 源码可能尚未完全梳理完接受到RTMP后信息如何处理、码分缓存以及转发给直播用户等内容。码分

       SRS源码中的码分Play流程如下：

       1. 进入play流程：本章内容直接从SrsRtmpConn::stream_service_cycle()方法开始梳理。

       2. 在接受流程中，码分客户类型为SrsRtmpConnFMLEPublish “fmle publish”，码分而在转发流程中，码分客户类型为SrsRtmpConnPlay。码分

       3. 在http_hooks_on_play()方法中，码分回调on_play()方法通知vhost，码分xxx用户已经开始play。

       4. 在http_hooks_on_stop()方法中，回调on_stop()方法通知vhost，xxx用户已经停止play。

       5. 最重要的是进入该函数。

       在函数中：

       1.1 根据客户端创建消费者对象：create_consumer(this, consumer)

       1.2 为该消费者开启一个独立协程：trd.start() //此处一直不太明白，在play流程中创建一个协程用来做什么?

       1.3 进入play主流程：do_playing(source, consumer, &trd);

       2. 进入主play循环：do_playing()函数内容众多且非常重要，因此将函数内容全部列出。

       2.1 通知消费者准备play

       2.2 从消费者列表中取出Rtmp信息（SrsMessageQueue）

       2.3 进入play入口

       3. 进入SRS发送接口（play）：在int SrsProtocol::send_and_free_messages(SrsSharedPtrMessage** msgs, int nb_msgs, int stream_id)函数中，进入int SrsProtocol::do_send_messages(SrsSharedPtrMessage** msgs, int nb_msgs)，该函数有一个#ifdef SRS_PERF_COMPLEX_SEND宏定义，一般rtmp协议都是要混合音视频数据，在做转发。在往后面看，

       最后进入

       在该函数中，最重要的一点是send message总出口writen()函数。它负责将转发给直播用户的流转发出去。

       4. 最后：play总结

       （1）通知client开始play

       （2）从消费者列表中取出Rtmp数据

       （3）从总出口writev（）函数中转发出去

年 C++音视频开发学习路线（ffmpeg/rtsp/srs/webrtc/hls）

       音视频工作领域繁复多样，自学时易陷入迷茫。本文整理出九个前景不错的.net 个人博客源码方向：直播、传输、算法、视频播放器、流媒体后端、短视频、音频播放、视频编辑、图像处理。以下为详细学习路线：

       音视频基础

音频基础知识

视频基础知识

解复用基础知识

FFmpeg开发环境搭建

音视频开发常用工具

       FFmpeg实战教程

FFmpeg命令

SDL跨平台

FFmpeg基石精讲

FFmpeg过滤器

FFmpeg音视频解复用+解码

ffplay播放器

FFmpeg音视频编码+复用合成视频

ffmpeg多媒体

FFmpeg+ QT播放器

       流媒体客户端

RTMP推拉流项目实战

RTSP流媒体实战

HLS拉流分析

       流媒体服务器

SRS源码剖析协程

ZLMediaKit源码剖析

       WebRTC项目实战

WebRTC中级开发实践指南

WebRTC高级开发-SRS 4.0/5.0源码分析

WebRTC高级开发-MESH模型多人通话

WebRTC高级开发-Janus SFU模型多人通话

       Android NDK

Android NDK开发基础

Android FFmpeg编译和应用

Android RTMP推拉流

Android Ijkplayer源码分析

       iOS音视频开发

iOS FFmpeg 6.0编译和应用

iOS FFmpeg RTMP推拉流

VideoToolbox硬件编解码

iOS jkplayer编译和应用

iOS ijkplayer编译和应用

       音视频项目实战

       相关开源网站与地址

       本文涵盖音视频全栈开发技术，适合各类技术人员。

音视频流媒体服务器搭建（直播架构、搭建、SRS流媒体及其集群部署）

       直播产品的种类

       泛娱乐化直播：适用于大规模直播，主要为观看，使用 rtmp、hls、http/flv。实时互动直播：运用 RTP 协议，与学习协议不同，常用 webrtc。

       泛娱乐化直播架构

       结构包括左内用户互动、右大规模用户直播。

       实时互动直播架构

       分为左内部用户互动、右大规模用户直播。

       直播客户架构

       有多种搭建方式，Nginx、flv、rtmp。

       Nginx搭建流媒体服务

       下载 Nginx 源码，编译安装并配置 Nginx。下载 Nginx RTMP 模块。

       Nginx RTMP 服务搭建步骤

       配置 Nginx RTMP 模块，编译安装 Nginx，修改配置文件，快速实现汉诺源码启动服务。

       推/拉流测试

       进行拉流操作，获取视频流地址。

       SRS 流媒体服务介绍

       SRS 是单进程实现的运营级互联网直播服务器，支持 RTMP、HLS、HTTP-FLV，提供丰富接入方案。

       SRS 单机部署

       下载源码，配置、编译、安装，设置自动启动脚本。

       SRS 集群部署

       部署图源节点、边缘节点，开启集群，进行推流/拉流测试。

       CDN 了解

       CDN 网络提供内容分发加速服务，减少延迟，提高用户体验。

       阿里云 CDN 架构

       分析和解决抖音直播延迟问题，涉及缓存、网络抖动、推流、服务器转发、拉流技术。

       腾讯云超低延时直播白皮书

       音视频流媒体开发学习资料、教学视频和路线图，加入学习交流群获取。

常见流媒体服务器方案对比分析

       SRS

       功能和稳定性大幅提升，易于上手，提供丰富功能和集群支持。配置步骤：获取源码、编译、电子书源码 asp运行。

       主要功能：集群、协议网关、CDN功能等。支持概念完整性和简单实现。提供接入方案、流变换、集群特性、丰富接口、广泛应用。

       EasyDarwin

       由国内开源团队维护，Golang开发，支持快速构建流媒体服务平台。配置步骤：获取源码、运行。

       主要功能：基于Golang、多系统平台部署、RTSP推流/拉流、服务端录像、关键帧缓存、Web后台管理、分布式负载均衡。

       ZLMediaKit

       高性能流媒体服务框架，支持多种协议，三大PC平台及iOS、Android两大移动端。配置步骤：获取源码、编译、运行。

       主要功能：C++开发，多路复用/多线程/异步IO，海量客户端连接，全平台支持，秒开画面、仿穷游源码php极低延时，完善标准C API。

       Monibuca

       Go语言实现的流媒体服务器框架，采取引擎+插件方式，支持定制化功能。配置步骤：获取源码、安装monica、运行。

       主要功能：优化Golang特性，利用goroutine合理分配资源，减少内存操作，功能强大仪表盘，直观服务器状态，纯Go编写，部署方便。

       对比图表

SRS(simple-rtmp-server)流媒体服务器源码分析--启动

       小卒最近探索了SRS源码，并撰写博客以整理思路，方便日后查阅。SRS源码具备以下优势：

       1、轻量化设计，代码结构清晰，SRS3.0版本代码量约为8万行，功能却足以支撑直播业务。

       2、采用State Threads架构，实现高性能、高并发。

       3、支持rtmp和hls，满足PC和移动直播的需求。

       4、支持集群部署，适应不同规模的部署需求。

       代码分析分为两个阶段：一、梳理代码框架，理解流程；二、深入细节，熟悉SRS工作原理。

       SRS源码框架包括系统启动、RTMP消息处理、RTMP信息发布、HLS切片等功能模块。系统启动时，初始化类，监听端口，对每个访问请求创建线程，专门处理连接操作。

       系统监听包含不同类型的请求，如RTMP连接、HTTP API等，通过创建线程处理。

       RTMP连接处理中，SRS采用协程而非线程，实现高效并发。创建协程后，进入协程循环处理。

       HTTP API连接监听机制与RTMP类似，仅参数不同。

       HTTP API回调接口在run_master函数中注册，允许访问服务器参数。

       SRS对拉流处理独特，通过ffmpeg工具实现，SRS代码负责简单的系统调用。

       系统启动代码结构清晰，从初始化、监听到线程处理，再到回调注册、拉流处理、自服务，各环节紧密衔接。

       总结SRS源码分析，不仅展现了代码的高效性和扩展性，还提供了灵活的部署方案，适用于多种直播场景。

SRS4.0源代码分析之WebRTC服务总体介绍

       SRS4.0的WebRTC服务提供了一种强大的实时音视频通信解决方案，它基于Web标准，支持浏览器之间的双向通信。SRS4.0引入WebRTC的主要目的是为了增强服务器的SFU（服务器转发单元）功能，以优化客户端接入和降低音视频处理对服务器CPU的负担。通过部署SFU，客户端可以将本地音视频数据推送到服务器，同时服务器根据需要拉取数据，实现低延迟的直播连麦场景。

       WebRTC涉及的知识点广泛，包括SDP报文处理、ICE连接建立、DTLS加密等，但SRS4.0的重点在于简化用户对WebRTC的理解。SRS4.0 WebRTC服务的核心模块在`srs_app_rtc_server.cpp`中初始化，主要负责自签名证书生成、UDP端口监听（如）和推拉流API接口注册。RTMP与WebRTC的不同在于，WebRTC通过P2P/ICE技术建立UDP连接，而RTMP则通过socket复用控制命令和数据流。

       SRS4.0通过HTTP(S)接口提供对外API，如/rtc/v1/publish/和/rtc/v1/play/，用于接收和发送音视频数据。当客户端发起推流或拉流请求时，SRS会创建相应的对象（如SrsRtcPublishStream和SrsRtcPlayStream），并处理SDP交换和ICE连接建立。推流和拉流过程涉及SDP报文协商，ICE用于客户端和服务端建立数据传输通道，确保安全性和稳定性。

       最后，总结SRS4.0 WebRTC的处理流程：首先，监听端口并提供API接口；其次，根据API请求创建相应的数据流对象；接着，通过SDP和ICE建立连接；最后，音视频数据在服务器和客户端之间按此流程传递：客户端→服务器→SRS对象→客户端。理解这些核心流程有助于深入研究SRS4.0的WebRTC功能和实现机制。

FFplay源码分析-nobuffer

       在使用 FFplay 播放 RTMP 流时，不开启 nobuffer 选项会导致画面延迟高达7秒左右，而开启此选项后，局域网延迟可降低到毫秒左右。因此，本文将深入探讨nobuffer的实现细节，以及播放端缓存7秒数据的作用。

       fflags 的定义在 libavformat/options_table.h 文件中，这是一个通用选项，所有解复用器均包含此选项。在调用 avformat_open_input() 函数时，会将该命令行参数传入，其位置与所有格式参数相同，如在之前的文章《FFplay源码分析》中所述。记得在调试参数中添加-fflags nobuffer。

       在 avformat_open_input() 函数内部，fflags 这个 AVOption 会被传递给 AVClass，该类存储了多个 AVOption，而fflags 的索引为5。在 av_opt_set_dict() 函数中，fflags 的值会被应用并清除其他选项。在 avformat_open_input() 执行完毕后，AVFormatContext::flags 的第7位应被置为1，即二进制的 。通过下图可以清晰地看到这个过程。

       在 avformat_find_stream_info() 函数内部，如果没有设置nobuffer标记，探测的数据包将被丢入队列。avformat_find_stream_info() 首先读取一段数据包以分析输入流的编码器等信息，为了重用这些数据包，它们会被放入队列中。然而，整个探测过程长达5秒，这意味着 FFplay 大概会读取5秒的数据来分析输入流。若开启nobuffer，则不会重复使用这些探测数据，FFplay 探测完输入流后，会读取新的数据包进行播放。无需缓存，从而降低了延迟。

       通过在 ffpaly.c 文件中的 avformat_find_stream_info() 函数前后输出时间，可以发现两者相差5秒，直观展示了nobuffer对于降低延迟的作用。在实时场景下，缓存功能变得多余，它原本是为了分析本地文件，避免重复读取，但在实时场景中反而影响了性能。因此，在实时场景中，关闭缓存更为合适。

       补充说明：若在本地虚拟机环境下，不启用缓存也能实现流畅播放。然而，如果 SRS 部署在局域网的另一台机器上，不开启缓存可能导致视频卡顿，原因可能是解码前未能及时读取视频帧，FFplay 不断丢弃视频帧，尤其是当视频比音频慢时，这种情况下缓存功能反而成为瓶颈。

分析流媒体服务器源码：Rtmp发布流程的SRS解析

       Rtmp发布流程在SRS服务器中主要通过单线程多协程模型来实现，以简化线程管理和数据同步。以下是关键步骤的解析：

       SRS基于state-threads协程库工作，每个协程在单线程内独立执行，无需考虑线程安全问题。程序启动后，通过SrsStreamListener监听并处理TCP连接，创建SrsTcpListener和SrsReusableThread进行并发处理。

       当接收到客户端连接时，会根据连接类型创建不同的SrsConnection，如RtmpConn。SrsRtmpConnFMLEPublish负责处理推流至服务器，会进入publishing函数，其中创建SrsPublishRecvThread协程，接收和处理客户端的消息。

       消息处理中，视频数据会经过缓存H序列头、HLS分发和消费者分发等步骤。每个消费者有自己的SrsMessageQueue，队列大小由配置文件中的"queue_length"设置，队列满时旧消息会被丢弃，但关键的序列头不会被删除，避免影响客户端解码。

       总结来说，SRS的Rtmp发布流程通过高效的单线程协程设计，保证了数据的缓存和分发，同时通过策略性丢包避免了可能导致花屏的问题。