文章目录
项目概述
RtspServer 是由 PHZ76 开发的高效、可定制的实时流媒体服务器解决方案。它基于作者编写的网络基础库 xop ，允许开发者轻松处理和分发实时音视频流。项目提供了一个名为 DesktopSharing 的示例应用，可以捕获桌面和麦克风声音，并在编码后通过 RTSP 协议进行转发和推流。该项目支持 Windows 和 Linux 平台，代码量少，相比于 live555 等经典的流媒体库，RtspServer 更加轻量级，易于集成和二次开发，已在公司的项目中应用。
技术分析
支持的编码格式
RtspServer 支持多种音视频编码格式，涵盖了广泛的应用场景：
- 视频编码：H.264、H.265
- 音频编码：G.711A、AAC
传输方式
-
单播 (Unicast)：
- RTP_OVER_UDP：通过 UDP 协议传输 RTP 数据，延迟低，但在网络不稳定时可能会丢包。
- RTP_OVER_RTSP (TCP)：通过 RTSP 协议在 TCP 连接上传输 RTP 数据，可靠性高，适用于防火墙或 NAT 环境。
-
组播 (Multicast)：
- 适用于需要将同一流媒体数据发送给多个客户端的场景，节省网络带宽。
心跳检测机制
针对单播传输，RtspServer 内置了心跳检测机制，可以及时发现和处理连接异常，确保数据传输的稳定性。
RTSP 推流
RtspServer 支持 RTSP 推流功能，使用 TCP 协议进行数据传输，保证了数据的可靠传输，适用于对传输可靠性要求较高的应用场景。
安全性
RtspServer 内置了摘要认证（Digest Authentication），为服务提供了安全保障，防止未经授权的访问。
架构分析
RtspServer 整体架构
RtspServer 的架构主要包括以下组件：
- RTSP Server：处理客户端的 RTSP 请求，包括 SETUP、PLAY、PAUSE、TEARDOWN 等指令，管理会话和媒体流。
- Media Session：表示一个媒体会话，包含媒体流的相关信息，如流名称、媒体类型、编码格式等。
- Media Source：媒体源，负责提供音视频帧数据，可以来自文件、摄像头、麦克风或其他实时数据源。
- RTP Connection：负责通过 RTP 协议发送音视频数据，支持单播和组播传输。
流程分析
1. 客户端连接和会话建立
- 客户端通过 RTSP 协议发送连接请求到服务器。
- RTSP Server 接收到请求后，解析并创建一个新的 Media Session。
- 为每个媒体流（音频或视频）创建对应的 Media Source。
2. 媒体数据传输
- Media Source 获取音视频数据帧（可能来自编码器或实时采集设备）。
- RTP Connection 负责将媒体数据打包成 RTP 包，通过网络传输给客户端。
- 支持的传输方式包括 RTP_OVER_UDP、RTP_OVER_RTSP 和组播。
3. 心跳检测和连接维护
- 为了保持连接的稳定性，服务器会定期发送心跳检测，确认客户端的在线状态。
- 如果检测到连接异常，服务器会及时释放资源，防止资源泄漏。
xop 基础库
项目介绍
xop 是 RtspServer 的基础网络库，参考了 muduo 和 live555 的设计，封装了一个简单高效的网络框架，提供了构建高性能网络应用的基础组件。
功能特性
- 跨平台支持 ：兼容 Windows 和 Linux 操作系统。
- Windows 下 ：使用
select实现事件循环。 - Linux 下 ：使用
epoll实现高效的事件通知机制。
- Windows 下 ：使用
- 事件驱动模型：基于 Reactor 模式，实现非阻塞 IO 和事件驱动。
- 定时器：提供高精度的定时任务调度。
- 内存管理：实现了环形缓冲区和内存池，提升内存分配和释放的效率。
- 日志系统：内置简洁的日志功能，方便调试和运行监控。
xop 整体架构
- EventLoop：事件循环，核心组件，负责监听和分发 IO 事件、定时器事件等。
- Channel：通道，封装了文件描述符及其感兴趣的事件类型，如可读、可写等。
- TimerQueue：定时器队列，管理所有的定时任务。
- Buffer：缓冲区，提供高效的数据读写接口。
- Acceptor：监听器，负责接受新的客户端连接。
应用场景
- 在线教育平台：提供高清、流畅的远程教学体验，实现教师与学生的实时互动。
- 视频监控系统：实时传输监控摄像头的视频流，实现远程监控和安全管理。
- 远程会议系统：确保音频和视频的同步传输，提高远程会议的质量和效率。
- 桌面共享与远程协助 ：通过 DesktopSharing 示例应用，实现桌面实时共享和远程协助功能。
社区问题收集与解答
问题一：刚开始播放时有些花屏
问题描述：
在播放开始时，视频出现花屏现象。怀疑是与 GOP（Group of Pictures）有关，没有收到完整的一组 GOP，所以会花屏。是否应该等待下一个 I 帧？
解答：
是的，花屏问题通常是由于解码器没有接收到完整的关键帧（I 帧）导致的。解码器需要从 I 帧开始才能正确解码后续的 P 帧和 B 帧。
解决方案：
- 确保首帧为关键帧：在客户端连接后，服务器应确保发送的第一帧是关键帧。可以在编码器中设置，让其在新的会话开始时立即生成一个 I 帧。
- 检查帧类型 ：在编码过程中，可以通过
AVFrame或其他编码库的接口，获取帧类型，根据编码后的类型（I 帧、P 帧、B 帧）进行处理。 - 缓冲策略：在客户端实现一定的缓冲策略，等待接收到第一个 I 帧后再开始解码和播放。
问题二：推送 H.265 流时播放器无法播放
问题描述：
在使用 H.265 推流时，播放器无法正常播放视频。怀疑是在 H265Source 的 handleFrame 函数中处理有误。
解答：
问题可能出在对 NALU（Network Abstraction Layer Unit）的处理上。在 H.265 码流中，每个 NALU 前通常有一个起始码（如 0x00 00 00 01）。在计算 NALU 类型时，需要正确跳过起始码。
解决方案：
-
去除起始码：在处理帧数据时，需要跳过起始码，以正确解析 NALU 类型。
cppuint8_t *frameBuf = frame.buffer.get(); uint32_t frameSize = frame.size; frameBuf += 4; // 跳过起始码 frameSize -= 4; // 调整帧大小 -
统一处理方式 ：建议在构建
VideoFrame时就去掉起始码，这样后续的处理会更加统一。 -
区别转发和推流 ：对于转发和推流的处理，可以有所区别。直接获取 H.265 帧数据后调用
pushFrame，确保计算时是带有起始码的头部信息。
注意：
-
NALU 解析：正确解析 NALU 类型对于视频解码非常重要。确保在处理时准确跳过起始码，才能正确识别帧类型。
-
播放器兼容性：不同的播放器对码流格式的要求可能不同，确保码流符合标准，有助于提高兼容性。
Bug 修复与代码分析
问题描述
在使用 RtspServer 时，发现使用 VLC 和 ffplay 播放时出现错误：
Invalid NAL unit 0, skipping导致播放器无法正常播放视频流。需要对代码进行修复，解决该问题。
分析与解决方案
经过分析，问题出在 RTP 包的组装和 NALU 的处理上。以下是具体的修复步骤和代码修改。
1. 修改 RTP 包的最大负载大小
文件 ：rtp.h
问题分析：
- 原始定义的
MAX_RTP_PAYLOAD_SIZE为 1420，可能导致 RTP 包过小，增加了网络负载。 - RTP 头部的大小为 12 字节，实际可用的负载大小应该更大。
修改内容：
cpp
// 原始定义
#define MAX_RTP_PAYLOAD_SIZE 1420
// 修改为
#define MAX_RTP_PAYLOAD_SIZE 1440解释：
- 将
MAX_RTP_PAYLOAD_SIZE增加到 1440，可以减少 RTP 包的数量，提高传输效率。 - 参考了 Live555 中的
MultiFramedRTPSink.cpp，调整了最大负载大小。
2. 调整 RTP TCP 头部大小
文件 ：rtp.h
问题分析：
- 原代码中
RTP_TCP_HEAD_SIZE定义为 4，当传输模式为RTP_OVER_UDP时，这个值应该为 0。 - 在 UDP 传输中，不需要额外的 TCP 头部。
修改内容：
cpp
// 原始定义
//#define RTP_TCP_HEAD_SIZE 4 // when transport_mode_ = RTP_OVER_TCP
// 修改为
#define RTP_TCP_HEAD_SIZE 0 // when transport_mode_ = RTP_OVER_UDP解释：
- 将
RTP_TCP_HEAD_SIZE设置为 0，确保在 UDP 传输时，不会错误地加入额外的头部。
3. 修正 H.264 视频源的帧处理
文件 ：H264Source.cpp
问题分析：
- 在处理 H.264 帧时，需要正确跳过起始码（
0x00 00 00 01），否则会导致 NALU 解析错误。 - 当帧大小小于等于最大 RTP 负载时，直接发送整个帧；否则，需要进行分片（FU-A）。
修改内容：
cpp
if (frame_size <= MAX_RTP_PAYLOAD_SIZE)
{
frame_buf += 4; // 跳过起始码
frame_size -= 4;
// 构建 RTP 包
RtpPacket rtp_pkt;
rtp_pkt.type = frame.type;
rtp_pkt.timestamp = frame.timestamp;
rtp_pkt.size = frame_size + RTP_TCP_HEAD_SIZE + RTP_HEADER_SIZE;
rtp_pkt.last = 1;
...
}
else
{
frame_buf += 4; // 跳过起始码
frame_size -= 4;
char FU_A[2] = {0};
FU_A[0] = (frame_buf[0] & 0xE0) | 28; // NALU 头部
FU_A[1] = 0x80 | (frame_buf[0] & 0x1F); // FU-A 起始标志
// 进行分片处理
}解释：
- 对于小于等于最大负载的帧，直接跳过起始码，发送整个 NALU。
- 对于大于最大负载的帧，跳过起始码，进行 FU-A 分片，需要正确构建 FU-A 头部。
4. 修正 H.265 视频源的帧处理
文件 ：H265Source.cpp
问题分析：
- H.265 的 NALU 解析与 H.264 类似，但头部格式不同，需要相应调整。
- 同样需要正确处理起始码和分片。
修改内容：
cpp
if (frame_size <= MAX_RTP_PAYLOAD_SIZE)
{
frame_buf += 4; // 跳过起始码
frame_size -= 4;
// 构建 RTP 包
RtpPacket rtp_pkt;
rtp_pkt.type = frame.type;
rtp_pkt.timestamp = frame.timestamp;
rtp_pkt.size = frame_size + RTP_TCP_HEAD_SIZE + RTP_HEADER_SIZE;
rtp_pkt.last = 1;
...
}
else
{
frame_buf += 4; // 跳过起始码
frame_size -= 4;
uint8_t PL_FU[3] = {0};
uint8_t nalUnitType = (frame_buf[0] & 0x7E) >> 1;
PL_FU[0] = (frame_buf[0] & 0x81) | (49 << 1); // NALU 头部
PL_FU[1] = frame_buf[1]; // NALU 头部
PL_FU[2] = 0x80 | nalUnitType; // FU 起始标志
// 进行分片处理
}解释：
- 同样跳过起始码，正确调整
frame_buf和frame_size。 - 构建 H.265 的分片头部，确保 NALU 类型和标志位正确。
总结
通过上述修改，修复了播放器无法正常播放的问题。主要原因在于：
- 起始码处理：需要正确跳过起始码，才能正确解析 NALU。
- RTP 包组装：调整最大负载大小，确保网络传输的效率和稳定性。
- 分片处理：在帧过大时，正确地进行 RTP 分片，构建正确的 FU-A（H.264）或 FU（H.265）包。
这些修改使得 RtspServer 在与常见播放器（如 VLC、ffplay）兼容性方面得到了改善。
进一步的技术分析
深入理解 RTP 分片与 NALU 处理
在 RTP 传输中，当单个 NALU 的大小超过了最大 RTP 负载大小时，需要对其进行分片。分片时，需要构建特殊的 RTP 包，称为 Fragmentation Unit（FU）。
H.264 中的 FU-A 分片
-
FU-A 头部格式：
+---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |S|E|R| Type | +---------------+ -
S（Start）：分片的开始标志位，1 表示这是第一个分片。
-
E（End）：分片的结束标志位，1 表示这是最后一个分片。
-
Type：原始 NALU 的类型。
H.265 中的 FU 分片
-
FU 头部格式：
+---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |S|E| Type | +---------------+ -
S（Start）：分片的开始标志位。
-
E（End）：分片的结束标志位。
-
Type：原始 NALU 的类型。
起始码的处理
- 起始码（Start Code） ：在原始的 H.264/H.265 码流中，起始码用于分隔 NALU，一般为
0x00 00 00 01。 - RTP 传输中不需要起始码：在 RTP 传输中，起始码不应包含在传输的数据中，需要在发送前去除。
- 解析 NALU 类型：跳过起始码后，才能正确解析 NALU 的头部，获取 NALU 类型。
播放器兼容性
-
VLC 和 ffplay 等播放器在解析 RTP 流时，严格遵循标准。如果发送的数据不符合 RTP 和 H.264/H.265 的封装规范，就会出现错误。
-
错误信息：
Invalid NAL unit 0, skipping表示接收到的 NALU 类型为 0，这是无效的，可能是因为没有正确跳过起始码导致的。