基于C++与Live555构建高性能RTSP流媒体服务器实战指南

1. 项目概述为什么选择C和Live555来构建RTSP服务器如果你正在处理音视频流媒体相关的项目比如安防监控、在线教育、视频会议或者只是想自己搭建一个能推送视频流的服务端那么“RTSP服务器”这个概念你肯定绕不开。RTSP实时流传输协议是控制音视频流“播放”、“暂停”、“定位”的核心协议它本身不传输数据而是像导演一样指挥RTP/RTCP去完成实际的音视频包传输。市面上有很多现成的方案比如用FFmpeg推流到Nginx-rtmp-module或者用更现代的MediaMTX前身是rtsp-simple-server。但当你需要深度定制、追求极致性能或者想在嵌入式设备比如海思、RK3588这类平台上跑起来时用C结合Live555库从零搭建一个RTSP服务器就成了一个非常“硬核”且实用的选择。我选择C和Live555核心原因有三点。第一是控制力。C能让你对内存、线程、网络IO有最底层的把控这对于高并发、低延迟的流媒体服务至关重要。你可以精细优化每一个环节避免高级语言运行时带来的不可控开销。第二是Live555的成熟度。Live555虽然代码风格古老文档也少得可怜但它是一个经过近二十年工业级考验的库RTSP/RTP/SDP协议栈的实现非常完整和稳定很多商业产品都在用它。直接基于它开发相当于站在了巨人的肩膀上避免了重复造轮子。第三是学习价值。这个过程能让你彻底吃透RTSP协议的工作流程、SDP协商、RTP打包等流媒体核心知识这是使用现成黑盒工具无法比拟的。这个项目适合有一定C/C基础对网络编程和音视频技术感兴趣的开发者。你可能正在为毕业设计发愁也可能在工作中遇到了定制化流媒体的需求。接下来我会带你从环境准备、Live555源码编译开始一步步拆解如何构建一个能推送H.264视频的RTSP服务器并分享我踩过的坑和调试技巧。2. 环境准备与Live555源码编译工欲善其事必先利其器。在开始写代码之前我们需要一个可靠的开发环境和编译好的Live555库。这里我以Linux环境Ubuntu 20.04/22.04为主进行说明Windows和macOS的交叉编译思路类似但细节会有所不同。2.1 基础开发环境搭建首先确保你的系统有基本的编译工具链和C开发环境。打开终端执行以下命令安装必备软件包sudo apt update sudo apt install build-essential g make cmake pkg-config sudo apt install libssl-dev # 可选用于支持RTSP over TLSRTSPS对于代码编辑我强烈推荐使用VSCode配合远程开发或WSL2。如果你在Windows上可以通过WSL2获得一个近乎原生的Linux开发体验。在VSCode中安装“C/C”、“CMake Tools”等插件能极大提升开发效率。很多人搜索“vscode配置c/c环境”和“vscode连接ssh远程服务器”核心就是为了获得一个舒适的编码和调试环境。我的经验是直接在Linux服务器或WSL2子系统上开发避免跨平台编译的复杂性。2.2 获取与编译Live555源码Live555的官方源码托管在 Live Networks官网 我们直接下载最新的稳定版本。这里以live.2024.07.05.tar.gz为例。# 1. 下载源码包 wget http://www.live555.com/liveMedia/public/live.2024.07.05.tar.gz # 2. 解压 tar -xzf live.2024.07.05.tar.gz cd live # 3. 生成Makefile ./genMakefiles linux这里./genMakefiles linux是关键一步它根据你的目标平台生成对应的编译配置。如果你的平台是64位通常直接用linux即可。对于其他平台比如嵌入式ARM架构如RK3588你需要使用交叉编译工具链。例如假设你的交叉编译工具链前缀是aarch64-linux-gnu-你需要先修改config.linux文件将COMPILE_OPTS中的-DBSD1等选项调整好并将C_COMPILER和C_PLUS_PLUS_COMPILER指向你的交叉编译器然后再执行./genMakefiles linux。注意Live555的编译系统比较“老派”它依赖一个config.$平台文件。编译失败十有八九是因为这个文件没配置对。对于ARM平台一个常见的坑是忘记添加-fPIC位置无关代码选项导致后续链接动态库失败。# 4. 编译 make -j4编译成功后在live目录下会生成几个重要的目录liveMedia、groupsock、BasicUsageEnvironment、UsageEnvironment 这是Live555的四个核心库的源码和编译出的.a静态库文件。testProgs 包含了许多示例程序如testOnDemandRTSPServer就是一个现成的点播RTSP服务器是我们学习的最佳范例。mediaServer 一个更完整的媒体服务器目录里面也有可执行文件。实操心得第一次编译时建议先不要用-j多线程以便看清错误信息。编译成功后可以将live目录下的include子目录包含所有头文件和四个核心库的.a文件备份到一个统一的地方方便后续项目引用。你也可以执行sudo make install将库安装到系统目录如/usr/local但我不太推荐因为可能会污染系统环境不如在项目中指定相对路径清晰。3. RTSP服务器核心架构与Live555类库解析在动手写代码之前我们必须理解Live555是如何组织代码的以及一个RTSP服务器的基本工作流程。Live555的代码结构清晰但庞大我们聚焦于最核心的几个类和它们的关系。3.1 Live555的四大核心库Live555由四个相互依赖的基础库组成层次从上到下UsageEnvironment 提供了任务调度、事件循环和日志输出的基础框架。核心类是UsageEnvironment和TaskScheduler。我们的服务器主循环就在这里驱动。BasicUsageEnvironment 是UsageEnvironment的一个简单实现通常我们直接使用这个。groupsock 封装了网络组播Multicast和单播的套接字操作是RTP/RTCP传输的基础。liveMedia最核心的库包含了所有媒体相关的类如ServerMediaSession、ServerMediaSubsession、RTSPClient、RTSPServer等。我们的RTSP服务器主要工作就是和liveMedia库中的类打交道。3.2 服务器工作流程与核心类一个最简单的点播RTSP服务器其工作流程和对应的Live555类如下创建并运行RTSPServerRTSPServer::createNew()是我们的起点。它内部会创建一个GenericMediaServer监听指定的RTSP端口默认554。创建媒体会话ServerMediaSession 一个ServerMediaSession代表一个可被请求的媒体流比如一个电影文件或一个摄像头通道。它有一个唯一的streamName如“h264VideoTest”。创建媒体子会话ServerMediaSubsession 一个ServerMediaSession可以包含多个ServerMediaSubsession例如视频轨和音频轨。对于H.264视频文件我们使用H264VideoFileServerMediaSubsession。这个类负责从源如文件读取H.264数据并按要求创建StreamState和RTPSink。将子会话添加到会话将会话添加到服务器 通过addSubsession和RTSPServer::addServerMediaSession完成注册。启动事件循环 调用env-taskScheduler().doEventLoop()。这个循环会一直运行处理新的RTSP连接请求、客户端命令DESCRIBE, SETUP, PLAY, TEARDOWN以及定时发送RTP数据包。// 伪代码流程示意 TaskScheduler* scheduler BasicTaskScheduler::createNew(); UsageEnvironment* env BasicUsageEnvironment::createNew(*scheduler); RTSPServer* rtspServer RTSPServer::createNew(*env, 8554, NULL); if (rtspServer NULL) { /* 处理错误 */ } ServerMediaSession* sms ServerMediaSession::createNew(*env, “testStream”, “”, “”, True); H264VideoFileServerMediaSubsession* h264Subsession H264VideoFileServerMediaSubsession::createNew(*env, “test.h264”, True); sms-addSubsession(h264Subsession); rtspServer-addServerMediaSession(sms); // 打印访问URL char* url rtspServer-rtspURL(sms); env “Play this stream using the URL \”” url “\”\n”; env-taskScheduler().doEventLoop(); // 主循环永不返回除非出错核心类关系解析RTSPServer 监听端口管理多个ServerMediaSession。ServerMediaSession 媒体流的逻辑集合对应一个RTSP URL。ServerMediaSubsession 具体的媒体轨道视频或音频。当客户端发起SETUP请求时它会创建一个StreamState。StreamState 管理一个特定客户端会话的流状态内部包含关键的RTPSink和FramedSource。RTPSink 负责将媒体数据如H.264 NALU按照RTP协议打包并发送出去。FramedSource 媒体数据源比如从文件读取H264VideoStreamFramer-ByteStreamFileSource。为什么这么设计Live555采用了“工厂模式”和“组合模式”。ServerMediaSubsession像一个工厂为每个连接的客户端生产独立的StreamState。这样确保了客户端之间的流状态是隔离的互不影响。这种设计非常契合流媒体服务器一对多、且每个客户端进度可能不同的场景。4. 实战构建一个H.264文件点播RTSP服务器现在我们进入实战环节基于Live555的示例代码构建一个能推送本地H.264裸流文件的RTSP服务器。我将详细解释每一步并标注关键参数和易错点。4.1 项目结构与代码实现我们创建一个简单的项目目录假设结构如下my_rtsp_server/ ├── include/ # 存放Live555的头文件从live目录拷贝过来 ├── lib/ # 存放Live555的四个静态库文件.a ├── media/ # 存放测试用的H.264文件如test.h264 ├── src/ │ └── main.cpp # 我们的服务器主程序 └── Makefile第一步准备Live555库文件将之前编译好的live目录下的所有.hh和.h头文件拷贝到include/下保持原有子目录结构。将liveMedia/libliveMedia.a、groupsock/libgroupsock.a、BasicUsageEnvironment/libBasicUsageEnvironment.a、UsageEnvironment/libUsageEnvironment.a这四个静态库文件拷贝到lib/目录下。第二步编写主程序src/main.cpp#include BasicUsageEnvironment.hh #include liveMedia.hh #include GroupsockHelper.hh // 定义ourIPAddress等 int main(int argc, char** argv) { // 1. 初始化任务调度器和环境 TaskScheduler* scheduler BasicTaskScheduler::createNew(); UsageEnvironment* env BasicUsageEnvironment::createNew(*scheduler); // 获取本机IP用于构造RTSP URL。注意生产环境可能需要指定IP。 char const* ipAddress “127.0.0.1”; // 默认本地环回 struct in_addr ipAddr; ipAddr.s_addr ourIPAddress(*env); // 这个函数会尝试获取本机第一个非环回IP ipAddress inet_ntoa(ipAddr); // 2. 创建RTSP服务器监听8554端口554需要root权限 Port rtspPort(8554); RTSPServer* rtspServer RTSPServer::createNew(*env, rtspPort, NULL); if (rtspServer NULL) { *env “Failed to create RTSP server: ” env-getResultMsg() “\n”; exit(1); } // 3. 创建媒体会话ServerMediaSession // 参数: env, 流名称 流信息 流描述 是否单播 char const* streamName “h264Stream”; ServerMediaSession* sms ServerMediaSession::createNew(*env, streamName, streamName, “A H264 video stream”, True); if (sms NULL) { *env “Failed to create ServerMediaSession\n”; exit(1); } // 4. 指定H.264文件路径。这里假设文件在当前目录的media文件夹下。 char const* inputFileName “./media/test.h264”; Boolean reuseFirstSource True; // 重要允许多个客户端共享同一个数据源对于文件点播是安全的 // 5. 创建H.264视频文件子会话并添加到媒体会话 ServerMediaSubsession* h264Subsession H264VideoFileServerMediaSubsession::createNew(*env, inputFileName, reuseFirstSource); if (h264Subsession NULL) { *env “Failed to create H264VideoFileServerMediaSubsession: possibly unsupported file format?\n”; exit(1); } sms-addSubsession(h264Subsession); // 6. 将媒体会话添加到RTSP服务器 rtspServer-addServerMediaSession(sms); // 7. 打印出访问地址方便客户端连接 char* url rtspServer-rtspURL(sms); *env “\nRTSP Server is ready!\n”; *env “Play this stream using the URL:\n\t” url “\n\n”; delete[] url; // 8. 进入主事件循环等待客户端连接和处理命令 env-taskScheduler().doEventLoop(); // 这个调用通常不会返回 return 0; // 实际上永远不会执行到这里 }第三步编写MakefileCXX g CXXFLAGS -g -Wall -I./include -stdc11 LDFLAGS -L./lib LIBS -lliveMedia -lgroupsock -lBasicUsageEnvironment -lUsageEnvironment -lpthread # 添加链接器搜索路径确保找到静态库 LDFLAGS -Wl,-rpath,./lib TARGET rtsp_server SRCS src/main.cpp all: $(TARGET) $(TARGET): $(SRCS) $(CXX) $(CXXFLAGS) $(SRCS) -o $ $(LDFLAGS) $(LIBS) clean: rm -f $(TARGET) .PHONY: all clean4.2 关键参数与配置详解端口选择 使用Port rtspPort(8554)。标准RTSP端口是554但在Linux上绑定1024以下端口需要root权限。为了开发安全我们使用8554。客户端连接时就需要指定这个端口如rtsp://192.168.1.100:8554/h264Stream。reuseFirstSource参数 这是H264VideoFileServerMediaSubsession::createNew的第三个参数设置为True。它的含义是当多个客户端连接同一个流时是否复用第一个客户端创建的数据源FramedSource。对于文件点播数据是静态的复用是安全且高效的所有客户端读取的是同一份文件数据。但对于直播源如摄像头每个客户端应该有自己的数据源实例这个参数通常要设为False。H.264文件格式test.h264需要是H.264 Annex B格式的裸流文件。这种格式的特征是每个NALU网络抽象层单元以0x000001或0x00000001起始码分隔。你可以用FFmpeg生成一个ffmpeg -i input.mp4 -c:v copy -an -bsf:v h264_mp4toannexb output.h264如果文件格式不对H264VideoFileServerMediaSubsession会创建失败。IP地址获取ourIPAddress(*env)函数会返回一个unsigned int格式的本机IP。代码中将其转换为点分十进制字符串。在有多网卡的服务器上这个函数可能返回的不是你期望的IP。生产环境中最好显式指定服务器对外的IP地址比如char const* ipAddress “192.168.1.100”;。4.3 编译与运行# 在项目根目录 my_rtsp_server/ 下执行 make # 确保 media/test.h264 文件存在 ./rtsp_server如果一切顺利终端会打印出类似这样的信息RTSP Server is ready! Play this stream using the URL: rtsp://192.168.1.100:8554/h264Stream现在你就可以用任何支持RTSP的播放器如VLC、FFplay、EasyPlayer来测试了。在VLC中点击“媒体” - “打开网络串流”输入上面的URL就能看到视频了。实操心得第一次运行最常见的错误是“Failed to create RTSPServer: Address already in use”。这意味着8554端口被占用了。可以用sudo lsof -i:8554查看是什么进程然后杀掉它或者换个端口。另一个常见错误是找不到H.264文件或者文件格式错误程序会直接退出。务必用ffprobe或十六进制查看器确认文件格式。5. 从文件点播到实时流接入摄像头或编码器文件点播是入门但实际项目中更多需要的是实时流比如接入USB摄像头、网络摄像头IPCamera或者编码器如海思芯片编码后的码流。这需要我们自定义FramedSource。5.1 理解FramedSource数据源的抽象FramedSource是Live555中所有媒体数据源的基类。它的核心是一个事件驱动的模型。当下游如RTPSink需要数据时它会调用FramedSource::getNextFrame()。我们的任务就是继承FramedSource实现doGetNextFrame()这个虚函数在这个函数里填充数据缓冲区并通知下游数据已就绪。一个自定义FramedSource的基本骨架class MyH264FramedSource : public FramedSource { public: static MyH264FramedSource* createNew(UsageEnvironment env, /* 你的参数 */); protected: MyH264FramedSource(UsageEnvironment env, /* 你的参数 */); virtual ~MyH264FramedSource(); // 最重要的函数当下游需要数据时被调用 virtual void doGetNextFrame(); private: // 你的数据获取逻辑例如从摄像头驱动读取一帧 static void deliverFrame0(void* clientData); void deliverFrame(); private: // 成员变量如摄像头句柄、缓冲区等 int mFd; // 假设是V4L2摄像头描述符 EventTriggerId mEventTriggerId; unsigned char* mBuffer; // ... };5.2 实现一个简单的内存模拟实时源为了便于理解我们先实现一个最简单的“模拟实时源”它从一个全局的、不断被填充的环形缓冲区中读取H.264数据。这模拟了编码器不断产出数据的情景。// 示例模拟实时H.264源 (SimulatedLiveH264FramedSource) #include FramedSource.hh #define FRAME_BUFFER_SIZE 1024*1024 // 1MB环形缓冲区 class SimulatedLiveH264FramedSource : public FramedSource { public: static SimulatedLiveH264FramedSource* createNew(UsageEnvironment env) { return new SimulatedLiveH264FramedSource(env); } protected: SimulatedLiveH264FramedSource(UsageEnvironment env) : FramedSource(env), mIsWaitingForData(False) { // 初始化例如启动一个线程填充mFrameBuffer // 这里简化处理假设数据已经存在 } virtual ~SimulatedLiveH264FramedSource() {} virtual void doGetNextFrame() { // 当下游RTPSink需要数据时调用 if (!mIsWaitingForData) { // 立即尝试传送一帧数据 deliverFrame(); } // 如果没有数据可传需要设置一个延迟任务等有数据时再调用deliverFrame0 } void deliverFrame() { if (!isCurrentlyAwaitingData()) return; // 安全检查 // 1. 从你的环形缓冲区mFrameBuffer中找出一帧完整的H.264 NALU // 这里需要你自己实现解析起始码(0x000001)的逻辑找到一帧的起始和结束。 // 假设我们找到了数据指针是frameData长度是frameSize。 unsigned char* frameData ...; unsigned frameSize ...; // 2. 检查我们提供的缓冲区是否足够大 if (frameSize fMaxSize) { fFrameSize 0; fNumTruncatedBytes frameSize - fMaxSize; handleClosure(); return; } // 3. 复制数据到下游缓冲区 (fTo) memcpy(fTo, frameData, frameSize); fFrameSize frameSize; fNumTruncatedBytes 0; // 4. 设置时间戳非常重要 // 对于实时流应该使用当前系统时间。Live555提供了gettimeofday的封装。 gettimeofday(fPresentationTime, NULL); // 5. 通知下游数据已就绪 FramedSource::afterGetting(this); } private: Boolean mIsWaitingForData; // 你的环形缓冲区及相关索引 // unsigned char mFrameBuffer[FRAME_BUFFER_SIZE]; // ... };5.3 集成自定义Source到服务器创建了自定义的FramedSource后我们需要创建一个对应的ServerMediaSubsession来生产它。这需要继承OnDemandServerMediaSubsession并重写几个虚函数。class SimulatedLiveH264ServerMediaSubsession : public OnDemandServerMediaSubsession { public: static SimulatedLiveH264ServerMediaSubsession* createNew(UsageEnvironment env); protected: SimulatedLiveH264ServerMediaSubsession(UsageEnvironment env) : OnDemandServerMediaSubsession(env, True /* 实时流不重用第一个源 */) {} virtual ~SimulatedLiveH264ServerMediaSubsession() {} // 最重要的重写当客户端SETUP时创建数据源 virtual FramedSource* createNewStreamSource(unsigned clientSessionId, unsigned estBitrate) { estBitrate 2000; // 估计码率 2000 kbps return SimulatedLiveH264FramedSource::createNew(envir()); } // 创建对应的RTP Sink打包器 virtual RTPSink* createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { // 对于H.264使用H264VideoRTPSink return H264VideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } };然后在主程序中用这个自定义的SimulatedLiveH264ServerMediaSubsession替换之前的H264VideoFileServerMediaSubsession即可。注意事项实时流与文件点播的关键区别在于ServerMediaSubsession的reuseFirstSource参数。在OnDemandServerMediaSubsession的构造函数中我们传入了True但这是指“是否复用第一个客户端会话的源”对于实时流每个客户端连接的createNewStreamSource都会被调用创建独立的源实例这是正确的。而在文件点播中我们使用的是H264VideoFileServerMediaSubsession它内部通过reuseFirstSource参数控制所有客户端是否共享同一个文件读取源。6. 高级话题优化、调试与常见问题排查当你成功运行起基础服务器后接下来就会遇到性能、稳定性和各种奇怪的问题。这部分是我在实际项目中积累的“血泪经验”。6.1 性能优化要点缓冲区管理 自定义FramedSource时避免在doGetNextFrame中进行阻塞IO或繁重的内存拷贝。理想情况是数据由另一个线程或中断服务例程填充到环形缓冲区doGetNextFrame只负责从缓冲区快速取出并传送。缓冲区大小要足够容纳关键帧I帧避免丢帧。时间戳处理 实时流的时间戳必须单调递增且最好与系统时钟或编码器时钟对齐。在deliverFrame中使用gettimeofday(fPresentationTime, NULL)获取当前时间作为时间戳。如果使用编码器的时间戳需要将其转换为RTP的90kHz时钟单位。不准确或跳跃的时间戳会导致客户端播放卡顿或加速。线程安全 Live555的主循环是单线程的doEventLoop。如果你的数据采集在另一个线程如摄像头采集线程那么在向Live555的缓冲区写入数据时必须加锁。一个常见的做法是使用Live555的TaskScheduler调度一个延迟任务envir().taskScheduler().scheduleDelayedTask来触发数据传送从而将数据从采集线程“安全地”切换到Live555的主线程上下文。RTP打包大小MTU 默认的RTP包大小可能超过网络MTU通常是1500字节导致分片影响效率。可以在创建RTPSink后调用sink-setPacketSizes(1000, 8000);来设置首选和最大包大小。对于H.264通常设置为小于1400字节。6.2 调试技巧与日志分析Live555自带了一套简单的日志系统通过UsageEnvironment的操作符输出。你可以通过设置环境变量DEBUG来增加日志级别。export DEBUG1 ./rtsp_server但这通常不够。更有效的调试方法是抓包分析 使用Wireshark或tcpdump抓取RTSP/RTP流量这是最权威的调试手段。sudo tcpdump -i any port 8554 -w rtsp.pcap用Wireshark打开rtsp.pcap过滤rtsp或rtp。你可以清晰地看到OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN的交互过程以及RTP包的序列号、时间戳。如果客户端黑屏首先检查PLAY之后是否有RTP包发出以及RTP包的SSRC、序列号是否连续。客户端日志 VLC播放器可以在“工具” - “消息”中设置详细日志级别如2查看连接和解码的详细过程。关键点添加日志 在自定义FramedSource的doGetNextFrame和deliverFrame中加入日志打印帧大小、时间戳确认数据是否正常产生和发送。6.3 常见问题排查速查表问题现象可能原因排查步骤与解决方案服务器启动失败提示Address already in use端口被占用sudo lsof -i :8554查看占用进程终止或更换端口。客户端连接成功但DESCRIBE后无响应或断开SDP生成失败检查ServerMediaSubsession创建的FramedSource和RTPSink是否成功。在createNewStreamSource和createNewRTPSink函数开始处加日志。确保媒体格式被支持。PLAY命令后客户端黑屏/无画面无RTP数据发送1.抓包确认PLAY的200 OK响应后是否有RTP/UDP包发出。2.检查SourcedoGetNextFrame是否被调用deliverFrame是否执行了afterGetting3.检查网络防火墙是否阻止了UDP端口RTP默认是偶数端口如34566。画面卡顿、花屏或马赛克严重数据不连续或时间戳问题1.抓包看RTP序列号是否连续大量丢包会导致花屏。2.检查时间戳在deliverFrame中打印fPresentationTime.tv_sec和tv_usec看是否连续递增。跳跃的时间戳会导致播放器解码异常。3.检查NALU类型确保发送的数据包含SPS/PPS0x67,0x68并且I帧0x65完整。丢失SPS/PPS会导致解码器无法初始化。多客户端连接时服务器CPU占用高或崩溃资源未隔离或锁竞争1. 确认reuseFirstSource策略是否正确。实时流应为每个客户端创建独立Source。2. 检查自定义Source的缓冲区访问是否有锁保护避免多线程竞争。3. 使用性能分析工具如perf、valgrind检查内存泄漏和热点函数。嵌入式平台如RK3588编译或运行出错交叉编译配置错误或资源不足1.编译确认config.文件中的编译器、-fPIC选项正确。2.运行嵌入式设备内存和CPU有限减少缓冲区大小优化代码。注意字节序大端/小端问题。3.依赖库确保设备上有必要的系统库如libssl。6.4 进阶功能扩展思路当你掌握了基础服务器搭建后可以考虑以下扩展方向这会让你的服务器更实用认证与安全 Live555的RTSPServer支持UserAuthenticationDatabase可以实现简单的用户名密码认证。你可以在创建服务器时传入一个自定义的认证数据库对象。支持更多编码格式 Live555内置了H.264、H.265(HEVC)、MPEG-4、JPEG等视频格式以及AAC、MP3、PCM等音频格式的ServerMediaSubsession。参考H264VideoFileServerMediaSubsession的实现可以仿写支持其他格式。实现按需直播On-Demand Streaming与录制 结合自定义FramedSource和文件写入可以实现将实时流同时转发给客户端并录制到本地文件。集群与负载均衡 单个服务器能力有限。可以考虑设计一个信令服务器管理多个RTSP服务器节点实现流的发布、发现和负载均衡。构建一个稳定、高效的RTSP服务器是一个系统工程涉及网络、音视频、操作系统等多方面知识。从Live555这个经典库入手虽然会面对一些晦涩的代码和设计模式但一旦啃下来你对流媒体技术的理解会深刻得多。记住多动手、多抓包、多读Live555自带的testProgs示例代码是快速进步的不二法门。遇到问题时回溯到协议本身RFC 2326 for RTSP, RFC 3550 for RTP/RTCP去思考往往能豁然开朗。