简介：这份资源围绕 live555 与 MP4 点播展开，面向具备 C++ 基础、希望理解 RTSP 流媒体服务实现的中高级开发者，可用于搭建本地 MP4 点播环境、研究 live555 Media Server 的会话管理与 RTP 封装机制。压缩包共 1487 个文件，约 31.69MB，以 cpp、hh、h 等 C++ 源码与头文件为主体，辅以 obj、tlog、pdb 等编译中间产物，以及 vcxproj、mak、genmakefiles 等工程与构建脚本，并包含 sdp 示例、mp4 与 avi 测试媒体及多平台 config 配置，覆盖 Windows、Linux、macOS 等编译环境。已有 675 人学习。资源保留了较完整的源码目录与示例程序，便于读者对照 ffmpeg 解析 MP4 元数据、设置 RTSP 播放路径、处理 Range 请求与音视频同步等环节，理解点播服务的缓冲与错误恢复思路，适合作为流媒体协议学习与二次开发的参考工程。
1. 点播一个 MP4 文件，为什么比想象中难
很多人第一次接触 live555 的 MP4 点播，都会有一个直觉：MP4 不就是个文件吗，读出来按字节发出去不就完了？真动手才发现，客户端要么卡在握手阶段，要么画面花屏，要么播到一半直接断流。问题不在网络，而在 MP4 这个容器本身——它的索引（moov）可能藏在文件尾部，它的采样（sample）大小参差不齐，它的时间戳需要从容器时间基换算到 RTP 时间基。live555 的 MP4 点播模块，本质上就是一套把「文件里的静态字节」翻译成「网络上连续 RTP 包」的调度器。搞懂它，你就搞懂了流媒体服务端最核心的那层抽象：源（Source）、子会话（Subsession）、以及按时间片驱动的任务调度。这也是为什么值得把它的底层机制拆开看——玄学般的卡顿和花屏，答案往往就藏在这几个类的协作顺序里。
2. 从文件到 RTP：live555 的 Source 抽象到底在做什么
2.1 为什么要有 ByteStreamFileSource 和 MPEG4VideoStreamFramer 两层
live555 处理 MP4 点播时，并不是一个类从头干到尾，而是把「读字节」和「切帧」拆成了两层。底层是ByteStreamFileSource，它只负责按固定块大小从文件里读数据，完全不关心这些字节是视频还是音频；上层是MPEG4VideoStreamFramer这类 framer，它拿到字节流后，按照 MP4 的采样表把连续的字节切成一个个访问单元（access unit），再打上时间戳。
这种拆分的动机很直接：文件读取是 I/O 密集的，切帧是 CPU 密集的，两者节奏不同。如果混在一起，读文件的阻塞会直接拖慢帧解析，反过来帧解析的复杂度也会污染 I/O 逻辑。拆开之后，ByteStreamFileSource可以用统一的doGetNextFrame()接口被调度器驱动，framer 则在doGetNextFrame()里向源要数据、解析、再回调给下游。常见的实现思路是让每一层都实现同一个FramedSource接口，这样调度器不需要知道数据来自文件、网络还是摄像头。
// ByteStreamFileSource 的核心读取逻辑（简化示意） void ByteStreamFileSource::doGetNextFrame() { if (fFid == NULL || feof(fFid) || ferror(fFid)) { handleClosure(); // 文件读完或出错，通知下游关闭 return; } // 按 fMaxSize 读取，fMaxSize 由下游 framer 决定 fFrameSize = fread(fTo, 1, fMaxSize, fFid); if (fFrameSize == 0) { handleClosure(); return; } fPresentationTime = fPlayTime; // 由上层设置的时间基准 // 读取完成后回调下游，驱动下一轮调度 FramedSource::afterGetting(this); }这段代码里最关键的是fMaxSize和afterGetting。fMaxSize不是随便定的，它由下游 framer 在调用getNextFrame时传入，决定了每次从文件里搬多少字节；afterGetting则是 live555 调度模型的枢纽——它不直接递归调用下游，而是把「数据已就绪」这件事交回给任务调度器，避免深递归把栈打爆。参数fPresentationTime在这里只是占位，真正的时间戳要等 framer 解析出采样时间后才能确定。
2.2 MP4 的 moov 索引：为什么不能顺序读
MP4 和 MPEG-TS 最大的区别在于，它的采样信息集中在moovbox 里，而moov可能在文件头，也可能在文件尾。如果moov在尾部，服务端必须先 seek 到文件末尾读索引，再跳回mdat读数据。live555 的MP4File类在打开文件时会先解析 box 结构，把每个 track 的采样表（stsz、stco、stsc、stts）读进内存，之后每次取帧都是一次「查表 + seek + read」。
这个设计带来的直接后果是：点播的启动延迟和文件大小无关，但和moov的大小正相关。一个采样表巨大的长视频，打开时会有明显的索引解析开销。我一般会这么理解：这相当于把「随机访问」的代价前置到了打开阶段，换来的是播放过程中每次取帧都是 O(1) 的查表操作。如果你的 MP4 是流式生成的（moov 在尾部且未完成），live555 会直接打不开——这不是 bug，是容器格式的硬约束。
2.3 时间戳换算：从容器时间基到 90kHz RTP 时钟
MP4 里每个 track 有自己的 timescale，比如视频可能是 90000，音频可能是 44100。而 RTP 传输要求时间戳统一到 90kHz 时钟（视频）或采样率时钟（音频）。live555 在MPEG4VideoStreamFramer里做了一次换算：把采样表的 decode time 和 composition time 差值算出来，再按比例映射到 90kHz。
// 时间戳换算的核心思路（示意） u_int64_t presentationTime_us = sampleTime * 1000000 / fTimescale; // 转成 live555 内部使用的 struct timeval fPresentationTime.tv_sec = presentationTime_us / 1000000; fPresentationTime.tv_usec = presentationTime_us % 1000000;这里容易翻车的地方是 B 帧。如果 MP4 里有 B 帧，decode time 和 composition time 不一致，framer 必须用 composition time 作为呈现时间戳，否则客户端解码顺序对了、显示顺序却乱了，表现就是画面跳帧。live555 通过cttsbox 拿到 composition offset，在切帧时把它加到 decode time 上。参数fTimescale来自mdhdbox，每个 track 独立，不能混用。
3. 子会话与 RTP 打包：一个 MP4 track 怎么变成一路流
3.1 ServerMediaSubsession 的职责边界
在 live555 的模型里，一个 MP4 文件如果有 1 路视频 + 1 路音频，就会生成两个ServerMediaSubsession，每个子会话负责一个 track 的 RTP 打包和 RTCP 反馈。MPEG4VideoFileServerMediaSubsession在createNewStreamSource里创建 framer，在createNewRTPSink里创建MPEG4ESVideoRTPSink。这个分工的意义在于：SDP 描述、RTP 序列号、SSRC 都是按子会话隔离的，客户端可以只订阅视频不订阅音频，服务端不需要为未订阅的 track 做任何打包工作。
常见的实现思路是让子会话持有一个StreamState，记录当前播放位置、RTP 序列号、时间戳偏移。当客户端发起 PLAY 时，startStream被调用，调度器开始以fDurationInMicroseconds为间隔驱动doGetNextFrame。这个间隔不是固定的，它由 framer 根据当前帧的时长动态计算——视频帧间隔可能是 33ms，音频可能是 23ms，调度器按最早到期的任务优先执行。
3.2 RTP 打包：为什么一帧要切成多个包
MPEG-4 视频的一帧可能远大于 MTU（通常 1400 字节左右），MPEG4ESVideoRTPSink必须把一帧切成多个 RTP 包，每个包带相同的 timestamp，但 marker 位只在最后一个包置 1。客户端靠 marker 位判断一帧结束，靠 sequence number 判断丢包。
// RTP 分包的核心逻辑（示意） void MPEG4ESVideoRTPSink::doSpecialFrameHandling( unsigned fragmentationOffset, u_int8_t* frameStart, unsigned numRemainingBytes, struct timeval presentationTime) { if (fragmentationOffset == 0) { // 一帧的第一个包，设置 RTP 头里的 marker 为 0 setMarkerBit(0); } if (numRemainingBytes == 0) { // 一帧的最后一个包，marker 置 1 setMarkerBit(1); } // 每个包都带同一个 presentationTime setTimestamp(presentationTime); }参数fragmentationOffset表示当前包在整帧中的字节偏移，numRemainingBytes表示这帧还剩多少字节没发。这两个参数由MultiFramedRTPSink基类在分包时计算并传入。容易踩的坑是：如果一帧刚好等于 MTU，numRemainingBytes为 0 且fragmentationOffset也为 0，marker 位会同时被置 0 再置 1，最终结果是 1，这是正确的；但如果分包逻辑写错，把 marker 判断放在 offset 判断之前，就会出现整帧只有一个包却 marker 为 0 的情况，客户端会一直等下一帧，表现为卡住。
3.3 RTCP 与播放控制：PAUSE 之后发生了什么
点播场景下，客户端按 PAUSE 时，live555 并不会销毁子会话，而是调用pauseStream，把StreamState里的播放标记置为暂停，调度器不再为该流排新的doGetNextFrame任务。但已经发出去的 RTP 包不会撤回，客户端需要靠 RTCP 的 SR（Sender Report）来对齐时间。恢复播放时，startStream会重新计算时间戳偏移，保证续播的时间戳连续。
这里有个血泪经验：如果 PAUSE 期间客户端没有发 RTCP RR，服务端的StreamState不会感知到客户端状态，续播时可能因为序列号回绕导致客户端丢弃一批包。排查时看服务端日志里 RTP 序列号是否在 PAUSE 前后连续，就能定位是服务端调度问题还是客户端缓冲问题。
4. 调度器与事件循环：live555 为什么不用多线程
4.1 单线程事件循环的设计动机
live555 默认是单线程的，所有网络 I/O、文件读取、RTP 打包都在一个TaskScheduler里跑。这个选择在点播场景下非常合理：点播的并发压力主要来自多个客户端，而不是单个客户端的计算量。单线程避免了锁竞争，也让时间戳和序列号的状态管理变得简单——不需要考虑多线程下的可见性问题。
代价是任何一个阻塞操作都会拖垮所有客户端。ByteStreamFileSource的fread如果遇到慢磁盘，整个事件循环都会卡住。所以 live555 在文件读取上做了限制：每次只读一个块，读完立刻交回调度器，让其他任务有机会执行。这种「协作式调度」要求每个doGetNextFrame都必须快速返回，不能在里面做耗时计算。
4.2 延迟任务与延迟队列
调度器内部维护一个延迟任务队列，按到期时间排序。scheduleDelayedTask把任务插入队列，SingleStep每次取出最早到期的任务执行。对于点播，framer 在每次doGetNextFrame结束后会调用scheduleDelayedTask安排下一次取帧，延迟时间等于当前帧的显示时长。
// 调度下一次取帧（示意） void StreamState::scheduleNext() { // fDurationInMicroseconds 由 framer 根据帧时长设置 fNextTask = scheduler->scheduleDelayedTask( fDurationInMicroseconds, taskHandler, this); }参数fDurationInMicroseconds如果设得太小，会导致 CPU 空转；设得太大，会导致帧间隔不均匀，客户端缓冲抖动。常见的做法是让 framer 根据采样表的 delta 精确计算，而不是用固定值。排查卡顿时，先看这个值是否和实际帧率匹配，往往能快速定位问题。
4.3 多客户端下的资源隔离
单线程下，多个客户端共享同一个调度器，但每个客户端有独立的StreamState和 framer 实例。文件句柄是每个ByteStreamFileSource独立打开的，所以同一个 MP4 被多个客户端点播时，会有多份文件读取。这在并发不高时没问题，但并发上去后磁盘 seek 会成为瓶颈。优化思路是共享MP4File的索引解析结果，只让数据读取按客户端隔离——不过这需要改 live555 的默认实现，属于进阶改造。
5. 避坑与排查：MP4 点播最常见的几个翻车点
5.1 现象：客户端能连上但一直黑屏
原因通常是moov解析失败或采样表为空。检查MP4File打开时是否报 box 解析错误，尤其是stsz的 sample size 为 0 且stsc的 chunk 映射不完整时，framer 拿不到有效帧。解决方法是先用工具确认 MP4 的 box 结构完整，moov里的stbl四个表齐全。
5.2 现象：播放几秒后花屏
多半是 RTP 分包时 marker 位或时间戳处理错误。检查doSpecialFrameHandling里 marker 的设置顺序，以及同一帧的多个包是否用了同一个 timestamp。另一个常见原因是fMaxSize设得比 MTU 大，导致单个 RTP 包超过网络 MTU 被分片，客户端重组失败。
5.3 现象：PAUSE 后恢复播放时间戳跳变
StreamState在暂停时没有保存时间戳偏移，恢复时从当前文件位置重新计算，导致时间戳不连续。解决方法是暂停时记录fPresentationTime的基准，恢复时把新时间戳减去基准再加回原偏移。
5.4 现象：多客户端并发时部分客户端卡顿
单线程调度器被某个慢客户端拖住。检查是否有客户端的doGetNextFrame里做了阻塞操作，或者文件读取的块大小设得过大。把fMaxSize调小、确保每次读取快速返回，通常能缓解。
5.5 现象：音频视频不同步
两个子会话的时间戳基准不一致。检查视频和音频的fTimescale是否分别正确读取，以及 RTCP SR 里的 NTP 时间是否对齐。常见错误是把音频的 44100 时钟直接当 90kHz 用，导致音频时间戳整体偏移。
6. 设计取舍：为什么 live555 的 MP4 点播看起来「笨」却够用
live555 的 MP4 点播实现，放在今天看确实不算优雅：索引全量加载、单线程调度、每个客户端独立读文件。但这些「笨」的选择背后有清晰的取舍。全量加载索引换来了播放时 O(1) 的取帧，单线程换来了无锁的状态管理，独立读文件换来了客户端之间的故障隔离。对于中小规模的点播场景，这套设计的复杂度远低于引入线程池和共享缓存，出问题时也更容易定位——所有状态都在一个线程里，日志顺序就是执行顺序，没有黑匣子。
真正需要警惕的是把它用在超出设计边界的场景：超高并发、超大文件、或者需要精确 seek 的交互式点播。这时候要么在 live555 外面加一层缓存代理，要么换用支持范围请求和分片索引的方案。我自己的习惯是，每次部署前先用一个长视频跑一遍完整播放，观察调度器的任务队列深度和文件 seek 次数，如果 seek 次数随并发线性增长到磁盘扛不住，就说明该加缓存层了。希望这些底层拆解能帮你在下次遇到点播卡顿时，少走一点弯路。
本文还有配套的精品资源，点击获取
