RtspServer:轻量级RTSP服务器和推流器

文章目录

项目概述

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 的基础网络库,参考了 muduolive555 的设计,封装了一个简单高效的网络框架,提供了构建高性能网络应用的基础组件。

功能特性

  • 跨平台支持 :兼容 Windows 和 Linux 操作系统。
    • Windows 下 :使用 select 实现事件循环。
    • Linux 下 :使用 epoll 实现高效的事件通知机制。
  • 事件驱动模型:基于 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 推流时,播放器无法正常播放视频。怀疑是在 H265SourcehandleFrame 函数中处理有误。

解答

问题可能出在对 NALU(Network Abstraction Layer Unit)的处理上。在 H.265 码流中,每个 NALU 前通常有一个起始码(如 0x00 00 00 01)。在计算 NALU 类型时,需要正确跳过起始码。

解决方案

  • 去除起始码:在处理帧数据时,需要跳过起始码,以正确解析 NALU 类型。

    cpp 复制代码
    uint8_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_bufframe_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,这是无效的,可能是因为没有正确跳过起始码导致的。

相关推荐
小李飞刀李寻欢4 天前
ffmpeg 提取mp4文件中的音频文件并保存
ffmpeg·音视频·音频·视频·audio
Mac@分享吧7 天前
Topaz Video AI for Mac 视频无损放大软件安装教程【保姆级,操作简单轻松上手】
macos·音视频·视频·topaz video ai·视频无损放大·topaz video·视频放大
欣慰的三叶草(● ̄(エ) ̄●)7 天前
Topaz Video AI for Mac 视频无损放大软件安装教程【保姆级,操作简单轻松上手】
macos·音视频·视频·topaz video ai·视频无损放大·topaz video·视频放大
程序员阳哥shen1616119 天前
短视频矩阵系统源码开发优势,短视频矩阵系统oem部署
矩阵·视频·源代码管理
程序员阳哥shen16161110 天前
抖音短视频矩阵源码开发/抖音矩阵系统OEM搭建/短视频源码开发
大数据·人工智能·矩阵·视频·源代码管理
hi9410 天前
基于KV260的基础视频链路通路(MIPI+Demosaic+VDMA)
fpga开发·视频·1024程序员节·mipi·vdma
侯增涛12 天前
一致角色的视频且唇形同步中文配音和免费音效添加
视频·人物一致·morph studio·免费音效网站
Linux音视频开发16 天前
C#实现信创国产Linux麦克风摄像头推流(源码,银河麒麟、统信UOS)
信创·推流·rtmp·国产化·摄像头推流
2401_8566545116 天前
这TOP3免费录屏软件,助你轻松跃升视频制作小能手
编辑器·音视频·视频编解码·视频·备忘录模式
freeabc16 天前
利用 OBS 推送 WEBRTC 流到 smart rtmpd
服务器·webrtc·rtmp·rtsp·sfu·whip/whep