流媒体建设及部署指导

一、背景

因客户招投标合规需要，需建设一个流媒体平台辅助日常办公，接入摄像头设备路数大约15路，服务器要支持国产化，满足后期扩容需求；对于该流媒体平台可购置商用或采用开源版本。

相关资料：开源视频平台、wvp-GB28181文档、ZLM仓库、vue-admin-template文档、OBS官网、SRS

二、资源估算

2.1、估算参考

首先，我们需要明确数据流，这将直接影响资源估算：

• 采集端： 5间评标室 × 15路摄像头 = 75路 1080p视频流。
  每路码率： 4Mbps (按上限计算，留有余量)
  总输入带宽： 75路 * 4Mbps = 300Mbps (此为流媒体服务器入口带宽)

• 流媒体服务层：
  直播与回看： 接收75路RTSP/Onvif流，转封装成RTMP/HTTP-FLV/HLS等格式，供Web端实时观看和回看。
  录制与转码： 将75路流进行录制，生成MP4/FLV文件，并可能需要对部分流进行转码（例如为不同网络条件的用户提供多码率，或转换为AI分析更高效的格式）。
  AI分析层： 从流媒体服务器“拉取”或通过回调“接收”视频流，送入AI模型进行分析。考虑到是75路实时流，对GPU算力要求很高。

• 存储层：
  本地磁盘（热存储）： 用于系统、应用、数据库、近期录制文件和高频访问的录像文件。
  归档存储（冷存储）： 用于长期存储录像文件，符合评标监控的法规要求（通常要求保存N年）。

2.2、资源估算

以下基于75路 1080p@4Mbps, 30fps的负载估算,所有计算都留有一定余量。

1）CPU

• 主要负载分析：
  流媒体服务： 接收、转发、封装流。纯转发对CPU消耗不高。
  视频转码： 这是最消耗CPU的操作。如果需要实时转码（例如75路全部转码），CPU负载会急剧上升。
  系统与应用： 操作系统、数据库、Web服务等。

• 估算依据：
  如果不做大规模转码，仅进行流转发和封装，一个现代CPU核心可以轻松处理20-30路流。
  如果需要进行软件转码（使用CPU），根据FFmpeg的基准测试，转码1080p@4Mbps到同规格，单核大约能处理2-4路。75路全部转码将需要20-30个物理核心。

• 最佳实践：使用GPU进行硬件转码，将CPU从繁重的编解码任务中解放出来。

• 推荐配置：
  方案一（无GPU，软件转码）： 2颗 Intel Xeon Silver 4314（16核/颗）或同等规格的AMD EPYC CPU，总计32核心。不推荐此方案。
  
  方案二（主流，GPU转码）： 1颗 Intel Xeon Silver 4310（12核/颗）或 AMD EPYC 7313（16核）。CPU主要用于流媒体服务、AI调度和系统任务，编解码由GPU负责。

• 计算公式：CPU核心数 ≈ (流转发路数 / 25) + (软件转码路数 / 3) + (系统预留 4-8核)

现场：本例（无软件转码）：75 / 25 + 0 + 6 = 9核。考虑到冗余和未来发展，推荐12-16核。

2）内存估算

• 主要负载：
  操作系统缓存。
  流媒体服务缓存： 特别是HLS切片和内存缓冲。
  AI应用： 运行AI模型（如YOLO）需要大量内存来加载模型和缓存视频帧。
  数据库与应用。

• 估算依据：
  流媒体服务：每路流预留10-20MB内存，75路约需1.5GB。
  AI服务：一个中等规模的视觉模型（如YOLOv5s）加载后可能占用1-2GB显存/内存。如果在CPU上运行，内存占用会更高。
  系统与其他：预留8-16GB。

• 推荐配置：64 GB DDR4 ECC内存。
  这是一个平衡的配置，能为流媒体、AI分析和操作系统提供充足的缓冲。

• 计算公式：
  总内存 ≈ 流媒体服务(75 * 15MB) + AI服务(4GB * AI进程数) + 系统与数据库(16GB)
  ≈ 1.125GB + 8GB + 16GB ≈ 25GB。推荐64GB以提供充足余量。

3）显卡

• 主要负载：
  视频硬件转码： 这是GPU在此场景下的核心价值。NVIDIA GPU的NVENC/NVDEC编码器效率极高。
  AI推理： 运行视频内容分析模型。

• 估算依据：
  转码能力： 一张NVIDIA Tesla T4 GPU的NVENC编码器可同时处理18+路 1080p H.264编码。一张消费级的RTX 3060也能轻松处理10路以上。
  AI推理能力： 分析75路实时视频流是更大的挑战。以YOLOv5s模型在1080p图像上推理为例，一张T4在TensorRT优化下可以达到100+ FPS。但这是针对单路视频。对于75路，平均到每路要求30FPS，那么总需求是 75 * 30 = 2250 FPS 的推理速度。一张T4大约能提供 100 * (30/1)？ 这个计算不准确，因为模型推理速度和分辨率、batch size强相关。一个更实际的估算：一张T4大概能同时处理15-25路1080p的实时AI分析。

• 推荐配置：
  方案一（一体机，性价比高）： 2张 NVIDIA RTX A4000（16GB GDDR6） 或 RTX 4090（24GB GDDR6X）。A4000是专业卡，稳定性更好；4090是消费卡，性价比极高，但需考虑数据中心部署的兼容性和保修。
  
  方案二（企业级，稳定扩展）： 1-2张 NVIDIA L4（24GB GDDR6） 或 Tesla T4（16GB GDDR6）。L4是T4的换代产品，性能和能效比更高。

结论：为了同时满足75路转码和75路AI分析，建议部署2-3张上述规格的GPU卡。可以规划1张专门用于转码，1-2张专门用于AI推理。计算公式如下：

转码所需GPU数 ≈ 总流路数 / 单卡NVENC并发路数(15)
AI推理所需GPU数 ≈ 总流路数 / 单卡AI并发路数(20)
总GPU数 ≈ (75 / 15) + (75 / 20) = 5 + 3.75 ≈ 9。这个理论值很高，但通过模型优化（如使用更小模型、降低分析频率、动态调度）和硬件性能，2-3张卡是可行的实践方案。

4）本地磁盘

• 资源用途：
  操作系统、应用程序、数据库。
  流媒体服务器的缓存、HLS临时切片。
  近期录像文件存储（例如7-30天）。

• 估算依据：
  总码率： 300Mbps = 37.5 MB/s。
  每天数据量： 37.5 MB/s * 86400秒 ≈ 3240 GB ≈ 3.24 TB/天。
  假设本地保留7天的录像： 3.24 TB/天 * 7天 ≈ 22.68 TB。

• 推荐配置：
  系统盘： 2块 960GB NVMe SSD，做RAID 1。用于操作系统和应用程序。
  数据盘： 一组RAID磁盘阵列，可用容量30TB以上。

• 最终方案： 8-10块 7.68TB SATA/SAS SSD 或 高性能HDD（如希捷银河Exos），配置为RAID 50或RAID 6，兼顾性能和数据安全。另外现场因需要75路视频同时写入，对IOPS和带宽要求高，如果用全HDD在RAID下可能成为瓶颈，而且现场生产HDD的场景越来越少，因此建议采用全SSD或SSD+HDD混合存储（热点数据放SSD）。

• 计算公式：
  本地存储容量(GB) = 总码率(MB/s) * 86400 * 保留天数 * 1.2 (冗余系数) / 1024
  = 37.5 * 86400 * 7 * 1.2 / 1024 ≈ 26,600 GB ≈ 26 TB

5）长期归档存储

• 资源用途： 长期保存超过本地保留周期的录像，满足法规要求。

• 估算依据：假设法规要求保存2年。
  总数据量： 3.24 TB/天 * 365天 * 2年 ≈ 2365 TB ≈ 2.3 PB。
  实际存储时，对象存储有压缩和去重技术，但视频压缩比已很高，此处按原始估算。

• 推荐配置：
  类型： 对象存储 是比NFS更优的选择。
  理由： 成本更低（通常使用纠删码技术），扩展性无限，具备版本控制和生命周期管理功能，非常适合海量非结构化数据的归档。

• 长期存储方案：
  公有云： 阿里云OSS标准/归档存储、腾讯云COS。
  私有化部署： 使用开源方案如 MinIO 或 Ceph 搭建对象存储集群。

• 计算公式：归档存储容量 ≈ 日均数据量 * 365 * 保存年限

6）最后就是带宽资源

• 内部带宽：
  服务器网卡： 至少需要2个 10Gbps SFP+ 光口。一个用于接入摄像头网络，一个用于连接核心交换机和外部访问网络。

• 外部带宽（供用户观看）：假设最大有50个用户同时观看不同的1080p直播流。
  50用户 * 4Mbps = 200Mbps的下行带宽。

• 平台出口带宽： 500Mbps - 1Gbps，以应对突发流量和回看下载。

三、优秀的开源流媒体平台推荐

3.1、ZLMediaKit

ZLMediaKit是国人开发的一个非常高效、功能全面的C++流媒体服务器。在国内应用极其广泛，社区活跃。 性能强劲，延迟低，支持RTSP、RTMP、HLS、HTTP-FLV等几乎所有主流协议，对国产CPU（如鲲鹏、飞腾）支持好。内置简单的录制功能。推荐度： ★★★★★（本项目首选）

3.2、MediaSoup

MediaSoup是一个高效的WebRTC SFU（选择性转发单元）框架，基于Node.js和C++。它是 为WebRTC而生，非常适合需要超低延迟双向通信的场景。如果评标过程中有双向语音对讲需求，这是最佳选择。缺点： 对于单纯的RTSP摄像头拉流和转发布，配置比ZLMediaKit复杂。

3.3、Monibuca

Monibuca也是一个国产的、模块化的Go语言流媒体服务器。它云原生友好，可扩展性强，插件化架构。适合作为流媒体中台的核心。社区和生态在快速发展中。

3.4、Nginx with nginx-rtmp-module

借助Nginx实现的轻量的经典的RTMP流媒体服务器。优点： 简单、稳定、资料多。缺点： 功能相对单一，延迟较高，现代浏览器不支持RTMP，需要转换为HLS/HTTP-FLV，通常需要配合FFmpeg使用。更多参见：nginx-rtmp-module

#监听频道，拉流ffplay rtmp://localhost/mytv/room01#mytv是起的流应用名称;room01是自定义频道#保存：ffmpeg-irtmp://localhost/mytv/room01-ccopy out2.flv#进行推流ffmpeg-re-i./out.flv-ccopy-fflv rtmp://localhost/mytv/room01

3.5、wvp-GB28181-pro

WEB VIDEO PLATFORM（WVP）是一个基于GB28181-2016标准实现的网络视频平台，使用宽松的MIT开源协议，可商用（但部分代码引用外部有商业风险需替换）；它支持NAT穿透，支持海康、大华、宇视等品牌的IPC、NVR、DVR接入。 支持国标设备(摄像机、平台、NVR等)设备接入 支持非国标(onvif, rtsp, rtmp，直播设备等等)设备接入，以充分利旧。支持国标级联，支持rtsp/rtmp等视频流转发到国标平台，支持rtsp/rtmp等推流转发到国标平台；支持多平台级联，支持跨网网闸平台互联，可跨网视频预览。其中，前端页面基于 MediaServerUI，基于 vue-admin-template 构建；流媒体服务基于ZLMediaKit，播放器使用 jessibuca；浏览器可无插件播放摄像头视频。

该平台未完全开源，以下部分收费：

• ONVIF设备的接入，支持点播，云台控制，国标级联点播，自动点播。
• 支持部标1078+808协议，支持点播，云台控制，录像回放，位置上报，自动点播。
• 支持国标28181-2022协议，支持巡航轨迹查询，PTZ精准控制，存储卡格式化，设备软件升级，OSD配置，h265+aac，支持辅码流，录像倒放等。

3.7、EasyDarwin流媒体服务

EasyDarwin是一款开源的高性能RTSP流媒体服务器，支持视频点播、RTMP推流直播（RTSP、FLV、WebRTC）、串流拉流直播、服务端录像与回放、视频抽帧快照，适用于安防监控、在线教育、企业通信等场景；更多参见：EasyDarwin仓库和官网。

3.8、其他辅助工具

1）liveweb

它是一款超低延时、秒启动、无插件的web实时视频播放器，支持多种常见浏览器和音视频格式。它支持RTSP、RTMP、HLS、HTTP-FLV、WebSocket-FLV、GB28181等多种协议，可以方便地接入到流媒体平台中，实现视频的播放和展示。

四、平台选用及部署配置

4.1、平台选用

经综合考虑： 本项目选用ZLMediaKit，因其性能卓越：单机支持10W+播放器，100Gb/s级别IO带宽；项目定位于成为移动嵌入式跨平台流媒体解决方案、商用级流媒体服务器，并支持网络编程二次开发SDK。协议支持完善：支持的RTMP协议确保了直播内容的快速传输，同时还具备动态调整码率的功能，可以根据网络状况自动调节视频质量，从而在保证流畅播放的同时，也兼顾了画质的清晰度；Linux/macOS/Windows/iOS/Android全平台兼容，部署相对简单，并且在国内有大量成功案例，ZLMediaKit都能够提供高效稳定的视频传输服务，特别是在处理大规模并发连接时，ZLMediaKit的优势尤为明显；据官方数据显示，在理想条件下，单台服务器能够同时支持超过十万条并发连接，这对于需要实时监控多个地点的大规模项目来说尤其友好。ZML采用模块化设计，核心代码位于src/目录，包含流媒体协议处理RTP/RTMP/WebRTC、媒体编解码、网络IO等模块。更多参见仓库：ZLMediaKit。另外可结合wvp-GB28181-pro，将其与ZLMediaKit进行集成，wvp-GB28181-pro可以充当接口服务器和信令服务器，主要用于响应客户端的请求和流媒体服务器和视频设备之间的交互，提供API接口供客户端调用，实现与客户端的交互。负责信令的传递和控制指令的下发。而ZLMediaKit则充当流媒体服务器，处理媒体流的接收、转换、分发。

1） RTSP协议的实现

RTSP（Real-Time Streaming Protocol，实时流协议）作为ZLMediaKit支持的重要协议之一，主要用于控制音视频的传输，地址格式：rtsp://ip:port/。在ZLMediaKit中，RTSP协议的实现不仅关注于数据的高效传输，同时也致力于提供一个稳定可靠的流媒体服务。通过使用C++11标准库中的智能指针技术，ZLMediaKit有效地管理了RTSP会话中的资源分配与回收，减少了内存泄漏的风险。此外，针对RTSP协议的特点，ZLMediaKit还特别优化了网络延迟问题，确保了即使在网络条件不佳的情况下，也能为用户提供流畅的播放体验。例如，在处理RTSP请求时，ZLMediaKit采用了异步非阻塞的方式，这大大提升了服务器处理并发请求的能力，使得即使是面对大量用户的直播场景，也能保持良好的性能表现。

2）RTMP协议：推流

RTMP（Real-Time Messaging Protocol，实时消息传输协议）是另一种被广泛应用于直播领域的协议。ZLMediaKit支持RTMP协议，用于推流，推流地址一般格式:rtsp://{流IP}:{RTSP PORT}/{app}/{stream}，对于使用GB28181的，流由视频设备主动推送到服务器。通过内置的RTMP服务器模块，ZLMediaKit能够轻松地与现有的直播平台进行对接，另ZLMediaKit针对RTMP协议进行了深度优化，特别是在数据加密传输方面，确保了流媒体内容的安全性。ZLMediaKit还支持动态调整码率的功能，可以根据网络状况自动调节视频质量，从而在保证流畅播放的同时，也兼顾了画质的清晰度。我们可使用 OBS Studio进行RTMP推流调试验证，比如将本地画面（如游戏、摄像头、PPT 等）推送到 RTMP 流媒体服务器（如 NGINX-RTMP、SRS、Red5 等）。

3）HLS和HTTP协议的适配

HLS（HTTP Live Streaming，HTTP实时流化）是一种基于HTTP的流媒体传输协议，由苹果公司提出。与传统的RTSP或RTMP相比，HLS具有更好的跨平台兼容性，尤其适合移动设备上的应用。ZLMediaKit在实现HLS协议时，充分考虑到了这一点，通过生成分段的M3U8文件列表，使得客户端可以按需下载对应的数据片段，从而实现了低延迟的直播效果。同时，ZLMediaKit还支持HTTP协议，这意味着除了直播之外，还可以方便地提供点播服务。无论是哪种协议，ZLMediaKit都致力于提供最佳的用户体验，通过灵活的配置选项，用户可以根据具体需求选择最合适的传输方式，确保每个场景下都能获得最优的播放效果。

4.2、部署

#克隆项目gitclone https://gitcode.com/GitHub_Trending/zl/ZLMediaKitcdZLMediaKit#初始化子模块gitsubmodule update--init#创建编译目录mkdirbuildcdbuild#编译安装cmake..

4.3、配置

# conf/config.ini 基础配置[protocol]enable_hls=1enable_rtsp=1enable_rtmp=1enable_ts=1enable_fmp4=1[rtmp]port=1935[rtsp]port=554[http]port=80rootPath=./www[rtc]port=8000externIP=10.24.139.210

更多待后续补充……

4.4、防火墙规则

1、仅允许网关主动下行：网关主动向摄像头 / NVR 发 INVITE、REGISTER、MESSAGE、ACK、BYE
2、严格禁止设备主动上行发起任何 SIP 请求：摄像头 / NVR 禁止主动反向发 INVITE/REGISTER/MESSAGE 攻击、扫描、恶意外呼、穿透，字符串仅匹配标准 SIP 请求行：XXX sip: 精准拦截，不误杀；IP 响应报文格式：SIP/2.0 200 OK 无 xxx sip: 请求行，不会被上面规则匹配；国标视频流随机端口 / 固定端口，不依赖 5060，以上规则不影响视频预览、回放、对讲、PTZ。
3、只拦截入站主动请求，不影响网关出站呼叫、心跳、流媒体、语音对讲
4、精准匹配 请求行，杜绝误杀响应包、会话关联包，统一使用 bm 高性能匹配算法，高并发低 CPU

#默认国标 SIP 端口：UDP/TCP 5060# 1. 禁止设备 反向主动发起 INVITE （重点：防设备主动呼叫、回拨、穿透）iptables-AINPUT-pudp--dport5060-mstring--string"INVITE sip:"--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--string"INVITE sip:"--algobm-jDROP# 2. 禁止设备 反向主动注册 REGISTER （防非法注册、弱密码爆破、伪造设备上线）iptables-AINPUT-pudp--dport5060-mstring--string"REGISTER sip:"--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--string"REGISTER sip:"--algobm-jDROP# 3. 禁止设备 反向主动 MESSAGE （防恶意短信、报警风暴、垃圾信令、攻击报文）iptables-AINPUT-pudp--dport5060-mstring--string"MESSAGE sip:"--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--string"MESSAGE sip:"--algobm-jDROP# 4. 禁止设备 反向主动 OPTIONS （防全网扫描、存活探测、端口扫描）iptables-AINPUT-pudp--dport5060-mstring--string"OPTIONS sip:"--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--string"OPTIONS sip:"--algobm-jDROP# 5. 禁止设备 反向主动 SUBSCRIBE 订阅类信令iptables-AINPUT-pudp--dport5060-mstring--string"SUBSCRIBE sip:"--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--string"SUBSCRIBE sip:"--algobm-jDROP#放行 192.168.10.0/24 内网所有5060iptables-IINPUT-s192.168.10.0/24-pudp--dport5060-jACCEPT iptables-IINPUT-s192.168.10.0/24-ptcp--dport5060-jACCEPT iptables-LINPUT-n--line-numbers# 按需删除某一条规则（替换行号）iptables-DINPUT 行号# 保存规则（CentOS）serviceiptables save

五、附录

5.1、SSRC校验

SSRC校验是用于流媒体传输中的同步机制，主要用于验证媒体流的同步源标识符（SSRC）的一致性，确保不同设备或节点间的音视频数据同步。 ‌SSRC校验通过验证媒体流中每个包的SSRC值是否连续或符合预期，来检测串流攻击或设备故障导致的数据错乱。例如，在RTP协议中，SSRC校验可确保接收端按顺序重组音视频帧，避免因网络延迟或重复传输导致的播放卡顿。 ‌‌但即便如此，不同厂商设备可能存在SSRC生成规则不一致（如部分设备在级联平台中有的直接默认为0，无法使用ssrc校验码流，导致串流问题频发），会出现校验失败情况。 ‌其次，动态端口‌也会导致串流，若使用动态端口范围（如40000-50000端口），虽降低串流概率，但经验表明百万级设备场景下仍可能半年发生一次串流，比如媒体服务器开放10000个端口，可以同时支持5000路推流(rtp、rtcp各占一个端口的情况)时，当端口耗尽下次端口就会被其他通道占用导致串流；另外GB28181开放端口范围过大，容易收到异常码流攻击和端口扫描攻击。 ‌另外GB28181协议本身缺陷（未明确规定底层网络必须支持TCP连接，导致部分设备仅支持UDP传输），进一步增加校验复杂度。 ‌另外经验验证，rtp码流无法避免串流和异常码流攻击，即使采用ssrc校验也不能完全避免。出SSRC默认0的情况，媒体服务可能接收不同上线服务下发的推流请求，导致ssrc可能一样，ssrc存在设备上报和实际码流ssrc不一致的情况，即使开启ssrc校验，ip校验也无法防止串流发生；

解决方案：

• 协议适配‌：统一设备SSRC生成规则，或通过SIP协议扩展增强SSRC验证机制。 ‌
• 端口管理‌：采用端口随机分配模式，减少异常端口暴露风险。 ‌
• 组合校验‌：结合CRC校验码（如循环冗余校验）提升数据完整性验证能力

5.2、推流与拉流的核心区别

5.3、UDP传输方式下SIP协议传输巨型帧偶现丢包问题

因为UDP 是不可靠的数据传输模式，在传输SIP协议巨型帧，即最大传输单元（MTU，Maximum Transmission Unit）大于1500时存在偶现丢包的风险，影响业务稳定性。可修改云主机关联的安全组，在对应UDP协议规则处修改为勾选全部端口按钮，即放开该项UDP规则全部端口，可以提升UDP传输可靠性，可以有效规避该问题。