一、背景因客户招投标合规需要需建设一个流媒体平台辅助日常办公接入摄像头设备路数大约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路 1080p4Mbps, 30fps的负载估算,所有计算都留有一定余量。1CPU主要负载分析流媒体服务 接收、转发、封装流。纯转发对CPU消耗不高。视频转码 这是最消耗CPU的操作。如果需要实时转码例如75路全部转码CPU负载会急剧上升。系统与应用 操作系统、数据库、Web服务等。估算依据如果不做大规模转码仅进行流转发和封装一个现代CPU核心可以轻松处理20-30路流。如果需要进行软件转码使用CPU根据FFmpeg的基准测试转码1080p4Mbps到同规格单核大约能处理2-4路。75路全部转码将需要20-30个物理核心。最佳实践使用GPU进行硬件转码将CPU从繁重的编解码任务中解放出来。推荐配置方案一无GPU软件转码 2颗 Intel Xeon Silver 431416核/颗或同等规格的AMD EPYC CPU总计32核心。不推荐此方案。方案二主流GPU转码 1颗 Intel Xeon Silver 431012核/颗或 AMD EPYC 731316核。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 A400016GB GDDR6 或 RTX 409024GB GDDR6X。A4000是专业卡稳定性更好4090是消费卡性价比极高但需考虑数据中心部署的兼容性和保修。方案二企业级稳定扩展 1-2张 NVIDIA L424GB GDDR6 或 Tesla T416GB 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或SSDHDD混合存储热点数据放SSD。计算公式本地存储容量(GB) 总码率(MB/s) * 86400 * 保留天数 * 1.2 (冗余系数) / 1024 37.5 * 86400 * 7 * 1.2 / 1024 ≈ 26,600 GB ≈ 26 TB5长期归档存储资源用途 长期保存超过本地保留周期的录像满足法规要求。估算依据假设法规要求保存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、ZLMediaKitZLMediaKit是国人开发的一个非常高效、功能全面的C流媒体服务器。在国内应用极其广泛社区活跃。 性能强劲延迟低支持RTSP、RTMP、HLS、HTTP-FLV等几乎所有主流协议对国产CPU如鲲鹏、飞腾支持好。内置简单的录制功能。推荐度 ★★★★★本项目首选3.2、MediaSoupMediaSoup是一个高效的WebRTC SFU选择性转发单元框架基于Node.js和C。它是 为WebRTC而生非常适合需要超低延迟双向通信的场景。如果评标过程中有双向语音对讲需求这是最佳选择。缺点 对于单纯的RTSP摄像头拉流和转发布配置比ZLMediaKit复杂。3.3、MonibucaMonibuca也是一个国产的、模块化的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/room013.5、wvp-GB28181-proWEB VIDEO PLATFORMWVP是一个基于GB28181-2016标准实现的网络视频平台使用宽松的MIT开源协议可商用但部分代码引用外部有商业风险需替换它支持NAT穿透支持海康、大华、宇视等品牌的IPC、NVR、DVR接入。 支持国标设备(摄像机、平台、NVR等)设备接入 支持非国标(onvif, rtsp, rtmp直播设备等等)设备接入以充分利旧。支持国标级联支持rtsp/rtmp等视频流转发到国标平台支持rtsp/rtmp等推流转发到国标平台支持多平台级联支持跨网网闸平台互联可跨网视频预览。其中前端页面基于 MediaServerUI基于 vue-admin-template 构建流媒体服务基于ZLMediaKit播放器使用 jessibuca浏览器可无插件播放摄像头视频。该平台未完全开源以下部分收费ONVIF设备的接入支持点播云台控制国标级联点播自动点播。支持部标1078808协议支持点播云台控制录像回放位置上报自动点播。支持国标28181-2022协议支持巡航轨迹查询PTZ精准控制存储卡格式化设备软件升级OSD配置h265aac支持辅码流录像倒放等。3.7、EasyDarwin流媒体服务EasyDarwin是一款开源的高性能RTSP流媒体服务器支持视频点播、RTMP推流直播RTSP、FLV、WebRTC、串流拉流直播、服务端录像与回放、视频抽帧快照适用于安防监控、在线教育、企业通信等场景更多参见EasyDarwin仓库和官网。3.8、其他辅助工具1liveweb它是一款超低延时、秒启动、无插件的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协议的实现RTSPReal-Time Streaming Protocol实时流协议作为ZLMediaKit支持的重要协议之一主要用于控制音视频的传输地址格式rtsp://ip:port/。在ZLMediaKit中RTSP协议的实现不仅关注于数据的高效传输同时也致力于提供一个稳定可靠的流媒体服务。通过使用C11标准库中的智能指针技术ZLMediaKit有效地管理了RTSP会话中的资源分配与回收减少了内存泄漏的风险。此外针对RTSP协议的特点ZLMediaKit还特别优化了网络延迟问题确保了即使在网络条件不佳的情况下也能为用户提供流畅的播放体验。例如在处理RTSP请求时ZLMediaKit采用了异步非阻塞的方式这大大提升了服务器处理并发请求的能力使得即使是面对大量用户的直播场景也能保持良好的性能表现。2RTMP协议推流RTMPReal-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 等。3HLS和HTTP协议的适配HLSHTTP Live StreamingHTTP实时流化是一种基于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_hls1enable_rtsp1enable_rtmp1enable_ts1enable_fmp41[rtmp]port1935[rtsp]port554[http]port80rootPath./www[rtc]port8000externIP10.24.139.210更多待后续补充……4.4、防火墙规则1、仅允许网关主动下行网关主动向摄像头 / NVR 发 INVITE、REGISTER、MESSAGE、ACK、BYE2、严格禁止设备主动上行发起任何 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--stringINVITE sip:--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--stringINVITE sip:--algobm-jDROP# 2. 禁止设备 反向主动注册 REGISTER 防非法注册、弱密码爆破、伪造设备上线iptables-AINPUT-pudp--dport5060-mstring--stringREGISTER sip:--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--stringREGISTER sip:--algobm-jDROP# 3. 禁止设备 反向主动 MESSAGE 防恶意短信、报警风暴、垃圾信令、攻击报文iptables-AINPUT-pudp--dport5060-mstring--stringMESSAGE sip:--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--stringMESSAGE sip:--algobm-jDROP# 4. 禁止设备 反向主动 OPTIONS 防全网扫描、存活探测、端口扫描iptables-AINPUT-pudp--dport5060-mstring--stringOPTIONS sip:--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--stringOPTIONS sip:--algobm-jDROP# 5. 禁止设备 反向主动 SUBSCRIBE 订阅类信令iptables-AINPUT-pudp--dport5060-mstring--stringSUBSCRIBE sip:--algobm-jDROP iptables-AINPUT-ptcp--dport5060-mstring--stringSUBSCRIBE 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 行号# 保存规则CentOSserviceiptables 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、推流与拉流的核心区别对比推流‌拉流‌数据源内容从采集端如摄像头、手机主动传输至服务器是内容生产环节‌客户端从服务器请求已有内容是内容消费环节‌这时流媒体平台变为消费者。技术要求一般需高带宽和稳定网络抗抖动‌动态调整码率/帧率依赖编码压缩技术如H.264和传输协议如RTMP‌更注重解码能力和网络适应性预加载分片减少卡顿支持多种协议如HLS、HTTP-FLV‌注重协议兼容和解码效率‌协议和场景通过RTMP协议将视频流进行封装推送到流媒体服务器延迟约1-3秒适合实时直播多数情况下采用推流的方式通过多种协议实现如RTMP、RTSP、FLV、HLS以及WebRTC等拉流中HLS延迟较高10秒以上适合点播‌比如视频监控系统通常会通过视频接入网关将摄像头采集的视频数据传输到网关。当需要查看特定摄像头的实时视频时我们可以在网关上针对该摄像头启动拉流流程从而在指定的摄像头获取视频数据另外一些不支持GB的设备可通过拉流代理的方式接入GB平台‌实时性要求‌高如体育赛事直播‌低如课程回放‌技术实现核心流程采集→编码→封装→传输其中使用H.264/H.265等编码标准压缩数据降低带宽占用将编码后的数据封装为RTMP、RTSP等协议支持的格式如FLV、TS通过RTMP低延迟1-3秒或WebRTC毫秒级延迟推流至服务器RTMP稳定→ WebRTC超低延迟依赖‌请求→解封装→解码→渲染‌其中可采用HTTP-FLV‌低延迟3-5秒适合实时直播。HLS‌高兼容性但延迟较高10秒以上通过M3U8索引分片TS文件实现最后浏览器端使用hls.js或flv.js解析流数据移动端通过原生SDK拉流并渲染HTTP-FLV平衡→ HLS兼容性5.3、UDP传输方式下SIP协议传输巨型帧偶现丢包问题因为UDP 是不可靠的数据传输模式在传输SIP协议巨型帧即最大传输单元MTUMaximum Transmission Unit大于1500时存在偶现丢包的风险影响业务稳定性。可修改云主机关联的安全组在对应UDP协议规则处修改为勾选全部端口按钮即放开该项UDP规则全部端口可以提升UDP传输可靠性可以有效规避该问题。