从零构建智能监控系统ZLMediaKit与SpringBoot的RTSP流处理实战监控系统这块我这两年折腾了不少方案从最开始的FFmpeg命令行硬转到后来用JavaCV自己做转发再到最终落到ZLMediaKit SpringBoot这套组合上可以说把市面上主流的几条路都趟了一遍。今天想聊的这套“从零构建智能监控系统”方案核心就是用SpringBoot做业务控制和信令处理用ZLMediaKit做流媒体网关统一接管海康、大华等摄像头的RTSP拉流、转封装和Web端播放。这套东西能解决的问题很具体摄像头厂商SDK碎片化、RTSP协议在浏览器里没法直接播、多路视频并发时带宽和性能扛不住以及“能不能用一套代码同时支持PC端和手机端观看”这种最实际的需求。适合正在做安防平台、智慧工地、连锁门店远程巡店或者想把手头那个“只能自己看”的监控项目改造成“能给别人看”的产品的Java后端开发。先说清楚一个底层事实RTSPReal Time Streaming Protocol本身是一个非常成熟的流媒体控制协议负责协商会话、控制播放暂停但它不管媒体数据怎么传输。实际传输音视频数据走的是RTPReal-time Transport Protocol。而浏览器端的WebRTC和HTTP-FLV之所以无法直接消费RTSP流是因为协议栈、容器格式、信令交互方式全都对不上。所以中间必须要有一层“翻译官”把RTSP拉过来解复用成裸的H.264/H.265和AAC数据再重新封装成浏览器能认的FLV或者WebRTC能吃的SRTP包。这就是流媒体服务器存在的意义也是我为什么最终选定ZLMediaKit作为核心转发引擎的原因。1. 整体方案设计与选型拆解1.1 为什么是ZLMediaKit而不是FFmpeg或SRS在做技术选型的时候我先把市面上常见的几条路线列了个对比表把各自的痛点都摊开来看。第一象限是直接用FFmpeg命令行做转推比如摄像头RTSP拉到服务器再用FFmpeg转成HLS推到Nginx。这条路最粗糙优点是上手快缺点是并发一上去就崩而且HLS的延迟通常在5秒以上根本没法做云台控制那种需要实时反馈的操作。更麻烦的是FFmpeg进程级的管理粒度非常差我想统计每路流的在线时长、码率、丢包率都得靠解析日志体验一言难尽。第二象限是JavaCV自己写转发层。JavaCV封装了FFmpeg的Java接口能做拉流、转码、推流但实际做下来会遇到几个扎心问题JavaCV的FFmpegFrameGrabber在断流重连时很不稳定偶发内存泄漏底层native库版本跟系统环境强绑定换台服务器就要重新踩一遍编译的坑而且转发节点一旦多起来GC停顿直接导致画面卡顿排查问题非常痛苦。第三象限是SRSSimple Realtime Server。SRS确实很强大尤其在高并发直播场景下表现优秀但它的定位是直播分发对ONVIF、GB28181这类安防协议的支持不如ZLMediaKit原生。而且SRS的配置体系对刚接触流媒体的人有一些门槛很多参数需要从文档里翻半天才知道含义。第四象限就是我最后选定的ZLMediaKit。它有几个点很打动我一是底层的ZLToolKit是C11写的事件循环库性能很能打单机处理几百路RTSP完全不在话下二是原生支持RTSP、RTMP、HLS、HTTP-FLV、WebRTC等多种协议拉流、推流、转封装一体搞定不用再拼装多个组件三是提供了完善的RESTful API和WebHook事件回调SpringBoot可以直接通过HTTP请求动态添加、删除拉流代理甚至不用改C代码就能完成业务联动。这一点对Java后端来说真是太友好了我可以把ZLMediaKit当成一个“黑盒流媒体交换机”来用业务逻辑全在SpringBoot里。1.2 SpringBoot在架构里承担什么角色SpringBoot在这一整套系统里扮演的绝对不只是“提供一个接口让别人调”那么简单。我的分层设计是这样的最上层是应用服务层。这一层负责所有业务逻辑设备管理摄像头的增删改查、通道管理、用户权限谁能看哪路流、录像计划什么时候录、录多久、告警联动移动侦测触发后自动推流或截图。这些都是SpringBoot的Controller和Service在处理整个系统的“大脑”在这里。中间是信令与控制层。这一层通过HTTP调用ZLMediaKit的RESTful API完成“添加拉流代理”、“关闭流”、“查询在线流”等操作。比如用户在前端点了一个摄像头图标SpringBoot收到请求后先查数据库拿到这个摄像头的RTSP地址然后调ZLMediaKit的/index/api/addStreamProxy接口告诉流媒体服务器去主动拉取那一路RTSP流。拉流成功后ZLMediaKit会把流ID、播放地址等信息返回SpringBoot再把这些信息拼成HTTP-FLV的播放URL返回给前端。最底层是数据与事件层。ZLMediaKit会把关键事件通过WebHook推送给SpringBoot比如“流注册了”、“流注销了”、“服务器启动完成了”。SpringBoot收到这些回调后会更新数据库中对应设备的状态字段——比如设备离线时把状态置为“离线”同时触发一些告警逻辑。这样整个系统就不是“前端轮询问状态”而是“事件主动上报”实时性高很多也省服务器资源。1.3 这套架构的核心优势在哪里整套方案最核心的优势我觉得是解耦。摄像头只管推RTSP流媒体服务器只管拉流转协议SpringBoot只管业务编排前端播放器只管消费HTTP-FLV或WebRTC流。每一层的边界非常清晰任何一层出问题都能独立排查和替换。另外还有一个很重要的点是多协议输出。同一路摄像头流ZLMediaKit可以同时输出HTTP-FLV给PC浏览器延迟1秒左右、HLS给iOS Safari延迟3-5秒但兼容性最好、WebRTC给需要极低延迟的场景延迟300毫秒以内。这意味着我在对接不同场景时不用为每一种终端单独开发一路流处理逻辑只要在SpringBoot里根据播放端类型选择不同的播放地址返回就行。有一点我必须坦白ZLMediaKit默认不转码也就是只做转封装不改变视频编码格式。如果摄像头输出的是H.265/HEVC而浏览器端不支持H.265解码那HTTP-FLV播放会黑屏。这种情况有两条路可以走一条是让摄像头把编码改成H.264另一条是加上FFmpeg转码模块。我自己的做法是优先在摄像头侧改成H.264除非硬件条件不允许才考虑服务端转码因为转码对CPU的消耗实在太大一路1080P的实时转码差不多要吃满一个中高配CPU的单核路数一多成本直接起飞。2. 环境搭建与ZLMediaKit部署2.1 服务器与环境要求先聊聊硬件和系统选型。不要上来就搞Windows服务器生产环境老老实实上Linux。我自己用的Ubuntu 20.04 LTS64位系统4核8G内存起步硬盘看录像保存周期而定单纯做实时流转发的话系统盘50G就够了。如果摄像头路数超过50路建议上SSD做缓存盘因为ZLMediaKit会频繁读写临时文件来支持HLS切片和录像回看功能。编译工具链方面ZLMediaKit是C项目依赖gcc、g、cmake、make这些基础工具。还需要安装OpenSSL开发库因为RTSP的认证和一些加密操作要用到它。另外如果你想让ZLMediaKit支持FFmpeg转码还需要在编译前安装FFmpeg的开发库。不过这里我不建议直接把FFmpeg编进ZLMediaKit因为会让整个二进制膨胀很多而且转码性能瓶颈明显需要时再单独部署转码模块更灵活。2.2 编译安装与目录规划我把ZLMediaKit安装在/opt/zlm目录下编译过程分三步走对应着三个命令。先拉代码我建议直接clone master分支稳定版不要用release包因为很多bug修复只在master上。# 1. 安装依赖不同系统包名可能略有差异 apt install build-essential cmake libssl-dev git -y # 2. 克隆源码并初始化子模块 cd /opt git clone https://github.com/ZLMediaKit/ZLMediaKit.git cd ZLMediaKit git submodule update --init --recursive # 3. 编译安装 mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX/opt/zlm -DCMAKE_BUILD_TYPERelease make -j4 make install编译完成后可执行文件在/opt/zlm/bin/MediaServer配置文件是/opt/zlm/bin/config.ini。我要重点提醒一下ZLMediaKit需要两个关键目录的权限一个是logs目录一个是www目录。logs目录用来写运行日志www目录是内置的HTTP静态文件服务根目录HLS切片、截图等文件默认都会写到www目录下如果你用非root用户跑MediaServer务必给这两个目录授权否则启动时会报各种权限错误。2.3 核心配置项详解ZLMediaKit的config.ini里的配置项很多但不是每个都要动。我按重要性排序把必须改和必须知道的几项列出来。配置块[general]里的mediaServerId是这台流媒体服务器的唯一标识SpringBoot调用API时会用到。[http]里的port是HTTP API和HTTP-FLV服务的监听端口我习惯用8088而[rtsp]里的port是RTSP服务的默认端口标准就是554内网没冲突就不用改。最关键的一项配置是[hook]块下的enable和on_flow_report、on_stream_changed、on_server_started这几个回调地址。WebHook默认关闭必须打开。我把回调地址指向SpringBoot的接口比如http://127.0.0.1:8080/api/zlm/hook。这里有个坑ZLMediaKit的WebHook回调是异步的而且如果回调接口响应超时ZLMediaKit会重试所以SpringBoot的接口务必做到轻量快速不要在里面做耗时的数据库写操作。我自己的做法是先把回调消息打到一个内存队列里然后由后台线程异步处理接口本身秒回。启动ZLMediaKit直接用./MediaServer -d以后台守护模式运行然后查看日志确认启动成功。cd /opt/zlm/bin ./MediaServer -d tail -f /opt/zlm/bin/logs/MediaServer.log日志里出现start server successfully就说明起来了之后用浏览器访问http://服务器IP:8088/index/api/getServerConfig能正常返回JSON配置数据说明HTTP API也通了。2.4 使用Docker部署的替代方案如果你是临时测试环境不想折腾编译用Docker跑ZLMediaKit是捷径。官方镜像在Docker Hub上可以直接拉但我实测下来有个问题官方镜像里没有包含FFmpeg转码组件如果后续要扩转码能力得用自定义Dockerfile重新构建。所以我的建议是测试用Docker生产尽量用二进制部署这样对系统资源的控制更精细也方便用systemd做进程管理。docker run -d --name zlm \ -p 1935:1935 -p 8088:8088 -p 554:554 \ -p 10000:10000 -p 10000:10000/udp \ -v /opt/zlm/config.ini:/opt/media/conf/config.ini \ -v /opt/zlm/logs:/opt/media/bin/logs \ -v /opt/zlm/www:/opt/media/bin/www \ zlmediakit/zlmediakit:master端口映射这块要特别留意我上面把1935RTMP、554RTSP、8088HTTP、10000RTP收流全都映射出来了实际上根据你的需求可以裁剪。另外RTP收流端口是一个范围区间不是单端口在config.ini里配置的是rtp_proxy端口池以我用的4.0版本为例是10000-10100这一段。Docker映射的时候要么写成上面这种单端口映射实际只有10000生效要么用-p 10000-10100:10000-10100把整个区间都暴露出来。我第一次用Docker部署就是因为漏了这一段导致摄像头拉流后画面迟迟不出来排查了半天。3. SpringBoot集成与RTSP拉流实战3.1 项目初始化与依赖引入SpringBoot这边的工程结构我按照标准的Maven多模块来规划。父工程只做依赖管理子模块分成monitor-common公共工具类、实体类、monitor-core核心业务逻辑、monitor-boot启动类、Controller层、monitor-clientZKMediaKit的API客户端封装。这样做的好处是以后如果要把流媒体管理拆成独立微服务可以直接把monitor-client和monitor-core抽出去变成一个独立的工程。依赖方面除了SpringBoot Web和Validation之外我用Hutool来做HTTP调用。Hutool的HttpUtil工具类封装了超时、重试、异常捕获的逻辑比手写HttpURLConnection省太多事了。另外用Fastjson2做JSON序列化解析ZLMediaKit返回的嵌套JSON特别方便。因为我这里面没有复杂的对象关系映射数据库操作直接用Spring Data JPA就够了。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.25/version /dependency dependency groupIdcom.alibaba.fastjson2/groupId artifactIdfastjson2/artifactId version2.0.46/version /dependency /dependencies3.2 封装ZLMediaKit的RESTful客户端ZLMediaKit的API调用方式很统一都是/index/api/开头的HTTP接口参数里带一个secret这个secret在config.ini里配置相当于API调用的密钥。我把这块封装成一个ZlmClient组件把常用的添加拉流代理、关闭流、查询流信息、获取服务器配置这些操作全包进去。需要说明的是加拉流代理这个方法很关键。addStreamProxy的参数有vhost虚拟主机、app应用名、stream流ID、url源地址也就是摄像头的RTSP地址这几个核心字段。stream这个参数是我们自己命名的逻辑流ID要保证全局唯一我一般用设备的编码或者数据库自增ID来生成比如device_001。这样后续不管查询流状态还是关闭流都用这个流ID来定位。Component public class ZlmClient { Value(${zlm.host}) private String zlmHost; Value(${zlm.port}) private Integer zlmPort; Value(${zlm.secret}) private String zlmSecret; private String getBaseUrl() { return http:// zlmHost : zlmPort /index/api/; } /** * 添加拉流代理 */ public JSONObject addStreamProxy(String streamId, String rtspUrl) { MapString, Object params new HashMap(); params.put(secret, zlmSecret); params.put(vhost, __defaultVhost__); params.put(app, live); params.put(stream, streamId); params.put(url, rtspUrl); params.put(auto_close, true); // 无人观看时自动关闭流 String body HttpUtil.post(getBaseUrl() addStreamProxy, params); return JSON.parseObject(body); } /** * 关闭流 */ public JSONObject closeStream(String streamId) { MapString, Object params new HashMap(); params.put(secret, zlmSecret); params.put(stream, streamId); params.put(app, live); String body HttpUtil.post(getBaseUrl() close_stream, params); return JSON.parseObject(body); } /** * 查询流信息 */ public JSONObject getMediaList(String streamId) { MapString, Object params new HashMap(); params.put(secret, zlmSecret); params.put(stream, streamId); String body HttpUtil.post(getBaseUrl() getMediaList, params); return JSON.parseObject(body); } /** * 获取HTTP-FLV播放地址 */ public String buildFlvUrl(String streamId) { return http:// zlmHost : zlmPort /live/ streamId .flv; } }3.3 设备接入与拉流流程完整实现设备接入的完整业务逻辑是这样的前端提交一个摄像头设备信息设备名称、RTSP地址、所属分组SpringBoot先把设备信息保存到数据库然后调addStreamProxy让它立即拉流验证这条RTSP地址能否正常取流。如果返回的code是0并且有播放路径说明拉流成功把设备状态置为“在线”同时给前端返回播放URL。如果拉流失败就把设备状态置为“离线”并记录失败原因。写入Controller和Service时需要特别注意一点HikariCP连接池的配置要调大一点。因为拉流操作涉及HTTP调用如果做同步流程在摄像头网络延迟大的情况下一次拉流的HTTP调用最快也要1-2秒这个过程中数据库连接是持有状态并发一起来连接池很快就打满了。所以我建议把spring.datasource.hikari.maximum-pool-size从默认的10调到50左右同时Service层的方法加Async注解改成异步执行主接口立刻返回“正在连接中”的状态前端再通过轮询或者WebSocket接收状态更新。Service public class DeviceService { Autowired private DeviceRepository deviceRepository; Autowired private ZlmClient zlmClient; /** * 接入新设备 */ public DeviceInfo addDevice(DeviceAddRequest request) { DeviceInfo device new DeviceInfo(); device.setDeviceName(request.getDeviceName()); device.setRtspUrl(request.getRtspUrl()); device.setGroupId(request.getGroupId()); device.setStatus(0); // 0-离线 1-在线 2-拉流中 device.setCreateTime(LocalDateTime.now()); deviceRepository.save(device); // 异步发起拉流 pullStreamAsync(device.getId(), request.getRtspUrl()); return device; } Async public void pullStreamAsync(Long deviceId, String rtspUrl) { String streamId device_ deviceId; // 先关闭可能残留的旧流避免流ID冲突 zlmClient.closeStream(streamId); JSONObject result zlmClient.addStreamProxy(streamId, rtspUrl); if (result.getIntValue(code) 0) { deviceRepository.updateStatus(deviceId, 1); log.info(设备{}拉流成功, streamId{}, deviceId, streamId); } else { deviceRepository.updateStatus(deviceId, 0); log.error(设备{}拉流失败: {}, deviceId, result.getString(msg)); } } }3.4 播放地址生成与前端对接拉流成功之后就可以给前端返回播放地址了。前端播放我推荐用Jessibuca这个播放器。它是纯H5的不用装插件支持HTTP-FLV和WebSocket-FLV解码走WASM兼容性比flv.js好很多特别是一堆老旧的Windows机器上的Chrome也能正常跑。对接方式很简单前端拿到播放URL后设置给播放器实例就行。播放URL的格式取决于你拉流代理里配置的app名。如果app是live流ID是device_1那么HTTP-FLV地址就是http://服务器IP:8088/live/device_1.flv。WebSocket-FLV地址则是ws://服务器IP:8088/live/device_1.live.flv。前端根据自身环境选一个合适的来播。需要注意跨域问题。如果你的前端页面部署在另一个域名或端口上播放器请求ZLMediaKit的8088端口时会被浏览器的跨域策略拦截。解决办法是在ZLMediaKit的config.ini里找到[http]配置块下的allow_cross_domains设为1即可开启CORS跨域。如果你有自定义域名或需要HTTPS访问还要配置ssl_cert和ssl_key这两个SSL证书文件路径并且把HTTP服务端口改成443。这些在实测中都是踩过的坑提前说清楚能少走弯路。4. 摄像头RTSP地址配置与兼容性处理4.1 海康、大华等主流摄像头RTSP地址格式项目里对接的设备种类多了之后我发现RTSP地址的写法每家都有自己的性格搞错了就拉不出流。我直接把常见设备的地址规则整理成了一张表方便大家直接套用。海康威视的新版固件地址格式是rtsp://用户名:密码IP地址:554/Streaming/Channels/101最后的101代表通道1的主码流102是通道1的子码流。子码流分辨率低、码率小适合网格预览画面主码流清晰度高适合单路放大查看。如果遇到海康的老设备地址格式可能变成rtsp://用户名:密码IP地址:554/h264/ch1/main/av_stream。大华的地址格式是rtsp://用户名:密码IP地址:554/cam/realmonitor?channel1subtype0channel是通道号从1开始subtype为0是主码流为1是子码流。还有一部分大华NVR的地址是rtsp://用户名:密码IP地址:554/Streaming/Channels/101和海康类似具体要看固件版本。宇视的地址是rtsp://用户名:密码IP地址:554/MediaInput/1/1后面两个1分别代表通道和码流类型。其他杂牌摄像头很多基于RTSP标准实现地址格式五花八门无法一一列出。我的建议是拿到设备先用VLC或者PotPlayer本地验证RTSP地址是否能出画面确认没问题再接进系统。这里我要特别提醒很多摄像头的RTSP用户不是后台登录的管理员账号而是需要在“安全”-“用户管理”里单独添加一个RTSP协议用户如果你用管理员账号去拉流有时候会因为权限策略问题被拒。4.2 不同编码格式的处理策略摄像头视频编码格式主要分H.264和H.265两种。H.264兼容性好基本所有播放端都支持H.265压缩率更高同等画质下码率大约是H.264的一半但浏览器端的支持情况很不理想。ZLMediaKit拉流成功后会返回流的编码信息在代理添加接口的返回JSON里有个codec字段可以看到是H264还是H265。我在SpringBoot里做了这样一个逻辑如果设备编码是H.265先尝试用HTTP-FLV播放部分新版Chrome解码能力提升了能软解H.265但卡顿风险大同时提供HLS备用播放地址给iOS SafariSafari对H.265的支持还行。如果两种方式都不行就需要在摄像头后台把编码改成H.264。在项目文档里我直接给用户写了一条硬性要求接进来的摄像头主码流编码优先用H.264不要用H.265这一条能省掉90%的播放兼容性问题。4.3 断流重连与流状态监测监控系统的稳定性很大程度由断流重连机制决定。摄像头离线、网络抖动、设备断电重启都会导致RTSP流中断如果不做处理播放器画面会一直卡在最后一帧非常影响体验。我做的第一层保障是WebHook的状态上报。ZLMediaKit的on_stream_changed事件会在流注册和注销时回调注销了就说明这条流断了。SpringBoot收到回调后把设备状态置为离线并启动一个延迟任务比如30秒后尝试重新拉流。第二层保障是内部的流状态巡检。我写了一个定时任务每30秒调用一次getMediaList查询所有应该在线的流如果发现有设备状态是“在线”但流已经消失了就触发重连逻辑。这个巡检机制看似简单但非常重要因为WebHook回调偶尔会因为网络问题丢失巡检兜底能确保系统最终收敛到正确的状态。Component public class StreamMonitorTask { Autowired private DeviceRepository deviceRepository; Autowired private ZlmClient zlmClient; Scheduled(fixedDelay 30000) public void checkStreamStatus() { ListDeviceInfo onlineDevices deviceRepository.findByStatus(1); for (DeviceInfo device : onlineDevices) { String streamId device_ device.getId(); JSONObject mediaList zlmClient.getMediaList(streamId); JSONArray data mediaList.getJSONArray(data); boolean streamAlive data ! null !data.isEmpty(); if (!streamAlive) { log.warn(设备{}流已断开尝试重连, device.getId()); deviceRepository.updateStatus(device.getId(), 2); zlmClient.addStreamProxy(streamId, device.getRtspUrl()); } } } }这里有一个值得优化的细节重连不能过于频繁。我踩过的坑是摄像头断电重启需要1-2分钟如果每30秒重连一次ZLMediaKit会在摄像头还没起来时持续报错既刷日志又浪费资源。我的方案是分级退避重连第1次重连在断流后30秒第2次在60秒之后每隔5分钟重试连续重试失败10次后不再自动重试只发告警通知人工介入。等摄像头恢复后用户主动点一次“重连”按钮或者WebHook收到流注册事件时自动把状态恢复为在线。5. 录像回放与告警联动扩展5.1 通过MP4自动录像实现回放实时预览只是监控系统的基础能力真正能打动用户的是录像回放。ZLMediaKit内置了MP4录制功能可以在拉流代理里把enable_mp4参数设为1这样流建立后会自动录制MP4文件到服务器。但这样做有几个不便一是所有流都录制磁盘空间扛不住二是没有录像计划的概念不能按星期几、时间段来灵活指定录制策略。我在SpringBoot里实现了自己的录像计划模块。数据库里建了一张record_plan表字段包括设备ID、录像类型持续录像/定时录像/事件联动录像、开始时间、结束时间、存储保留天数。定时任务每分钟扫描一次计划表到了指定的录像时段就调用ZLMediaKit的addStreamProxy接口把enable_mp4设为1并指定mp4_save_path为按设备分目录的路径录像结束后自动关闭代理并停止录制。这样既实现按需录像又能按设备归档文件。录像文件的检索和播放也比较直接。录制生成的MP4文件路径可以在ZLMediaKit的录像文件查询API里拿到我的实现是在SpringBoot里维护一个录像文件索引表定时任务扫描每个设备的录像目录把新生成的文件信息开始时间、结束时间、文件大小、存储路径写入数据库。前端打开回放页面的时候设备ID和时间区间作为查询条件就能列出对应的录像列表播放时直接把MP4文件地址交给video标签播放。如果服务器走的是Nginx静态文件服务记得在Nginx配置里加location /record/的别名映射。5.2 基于WebHook的移动侦测告警联动智能监控不搞点告警联动总觉得少了灵魂。我们后端只做业务调度真正的算法可以是你自己训练的模型也可以是调ONVIF协议的移动侦测接口。我项目里的做法是摄像头开启移动侦测后事件推送到ZLMediaKit有些摄像头可以直接配RTSP的event订阅有些要轮询ONVIF事件ZLMediaKit回调WebHookSpringBoot收到后把告警事件入库同时调播放器接口把实时画面弹到值班大屏上再做一步截图保存。截图这个功能是ZLMediaKit自带的非常实用。调用/index/api/getSnap接口传入流ID和播放URL它就能返回一张当前画面的JPG截图。告警时我每次都截一张图存起来作为告警的证据辅助。实际效果是当摄像头检测到画面变化时最快5-8秒内运维人员就能在告警列表里看到一条带截图的告警记录点开就能看当时的现场画面和前后各30秒的录像回放。这个体验用户反馈很不错。5.3 多级级联与集中管理架构如果你的项目不是单台服务器而是分公司、多地域部署每台服务器各跑一套系统那管理成本就上来了。ZLMediaKit支持集群级联的一种简单方式是“拉流级联”A站点的设备由A站点服务器拉流B站点的服务器通过“源拉流”模式把A站点服务器的流再拉过来。这样B站点只需保存转发地址不直接连接摄像头既减轻了摄像头压力又方便了集中管理。SpringBoot这边我建了一张server_node表来管理边缘节点核心服务从每个节点查询在线流列表统一汇总到总控台展示。节点之间通过WebSocket或HTTP回调实时同步状态。这种级联模式最典型的好处是总部领导在办公室就能直接看全国连锁门店的实时画面只要总部的带宽允许多路并发播放非常流畅完全不需要每家门店单独开账号登录去看。6. 常见问题与排查技巧实录6.1 “拉了代理但播放黑屏”的排查路径这个是我被问得最多的问题没有之一。黑屏的原因有一长串但大部分时候都是下面几类。第一编码是H.265但播放器不支持。这个最好判断打开浏览器的开发者工具看控制台如果是解码报错日志里通常会有编码格式相关的关键字。解决办法就是改成H.264或者用支持H.265的播放器方案。第二拉流成功但画面是静帧或者不出流。这种情况先看ZLMediaKit日志最常在日志里看到的是get key frame failure或者track is empty。这两个错误说明摄像头输出的数据里缺少关键帧GOP开头处的I帧。ZLMediaKit只有在收到关键帧之后才能开始向播放端输出数据。出现这个问题的原因大多是摄像头的参考帧间隔配置得太长或者用了B帧但配置不合理。我一般建议把摄像头的“I帧间隔”也叫GOP长度设置为帧率的两倍例如25fps的帧率就设为50这样每2秒至少有一个关键帧既能保证画面快速起播又不会太占带宽。第三网络问题导致RTP包丢失。RTSP拉流走的是UDP时在跨路由、有防火墙的场景下很容易出现丢包。ZLMediaKit的RTP收流支持TCP模式在拉流代理的参数里可以加rtsp_rtp_tcp1强制使用TCP传输RTP包。这个参数能解决80%的跨网段拉流不稳定问题。TCP模式虽然会略微增加网络开销和延迟但稳定性大幅提升。为了验证这个猜想我在一台内网摄像头上做了组播和跨VLAN测试发现在跨VLAN时UDP模式丢包率高达5%-10%画面马赛克严重切到TCP模式后马赛克几乎消失所以生产环境我毫不犹豫地全线开启TCP传输。6.2 服务器端口不通导致拉流失败很多新手在调试的时候明明在服务器本机测试RTSP地址能出流但SpringBoot调ZLMediaKit就是拉不过来最后发现是服务器安全组或者防火墙没有放行RTSP端口。这里有个容易产生误导的细节防火墙不只影响摄像头到ZLMediaKit的554端口还影响RTP动态端口的接收。ZLMediaKit收到RTSP信令后会开启一个RTP端口用来接收媒体的实际数据流这些端口范围是在config.ini的[rtp_proxy]里配置的。如果你的服务器只放行了554端口RTP数据是进不来的表现为信令正常但画面出不来。排查命令用ss -tunlp | grep MediaServer查看端口监听情况再配合在摄像头上用telnet 服务器IP 端口测试连通性一步步缩小范围。我在项目初期因为RTP端口段没放行整整卡了一个下午后来把整个10000-10100端口段全部放行才解决问题。6.3 高并发下的性能瓶颈与优化多路并发时ZLMediaKit最常暴露的性能瓶颈是线程模型和磁盘IO。ZLMediaKit基于事件循环核心线程数默认是CPU核心数我用threads配置项设置了合理的并发度。一个比较诡异的优化点是udp_sock_buf_size这个参数它控制UDP缓存区大小。在视频码率高、网络抖动大的时候加大这个值能有效减少因为缓冲区溢出导致的RTP丢包。我通常设置在4MB左右。参考经验数据在4核8G的普通服务器上ZLMediaKit做纯转封装不转码拉50路1080P主码流之外再拉50路子码流做预览CPU占用在40%左右内存占用3GB上下。但是如果你用FFmpeg转码50路直接能把CPU吃到100%而且相机源稍微卡顿还会引发级联效应拖垮整个进程。所以除非你的业务非常依赖转码否则尽量用硬件编码好的H.264来跑整个链路。6.4 请求返回超时与日志排查技巧addStreamProxy接口偶尔会出现返回超时或者一直返回code-1的情况。这时需要去看ZLMediaKit的日志但日志文件默认是轮转的位置在logs/目录下。我习惯在测试阶段直接把日志级别调到traceconfig.ini里[log]配置块的log_level默认为debug测试期可以临时调成trace以查看更多上报细节。生产环境务必调回debug或info不然日志量会大到吓人。另一个排查流媒体问题的利器是Wireshark。直接用Wireshark抓摄 SpringBoot+ZLMediaKit构建智能监控系统：RTSP拉流转发实战
从零构建智能监控系统ZLMediaKit与SpringBoot的RTSP流处理实战监控系统这块我这两年折腾了不少方案从最开始的FFmpeg命令行硬转到后来用JavaCV自己做转发再到最终落到ZLMediaKit SpringBoot这套组合上可以说把市面上主流的几条路都趟了一遍。今天想聊的这套“从零构建智能监控系统”方案核心就是用SpringBoot做业务控制和信令处理用ZLMediaKit做流媒体网关统一接管海康、大华等摄像头的RTSP拉流、转封装和Web端播放。这套东西能解决的问题很具体摄像头厂商SDK碎片化、RTSP协议在浏览器里没法直接播、多路视频并发时带宽和性能扛不住以及“能不能用一套代码同时支持PC端和手机端观看”这种最实际的需求。适合正在做安防平台、智慧工地、连锁门店远程巡店或者想把手头那个“只能自己看”的监控项目改造成“能给别人看”的产品的Java后端开发。先说清楚一个底层事实RTSPReal Time Streaming Protocol本身是一个非常成熟的流媒体控制协议负责协商会话、控制播放暂停但它不管媒体数据怎么传输。实际传输音视频数据走的是RTPReal-time Transport Protocol。而浏览器端的WebRTC和HTTP-FLV之所以无法直接消费RTSP流是因为协议栈、容器格式、信令交互方式全都对不上。所以中间必须要有一层“翻译官”把RTSP拉过来解复用成裸的H.264/H.265和AAC数据再重新封装成浏览器能认的FLV或者WebRTC能吃的SRTP包。这就是流媒体服务器存在的意义也是我为什么最终选定ZLMediaKit作为核心转发引擎的原因。1. 整体方案设计与选型拆解1.1 为什么是ZLMediaKit而不是FFmpeg或SRS在做技术选型的时候我先把市面上常见的几条路线列了个对比表把各自的痛点都摊开来看。第一象限是直接用FFmpeg命令行做转推比如摄像头RTSP拉到服务器再用FFmpeg转成HLS推到Nginx。这条路最粗糙优点是上手快缺点是并发一上去就崩而且HLS的延迟通常在5秒以上根本没法做云台控制那种需要实时反馈的操作。更麻烦的是FFmpeg进程级的管理粒度非常差我想统计每路流的在线时长、码率、丢包率都得靠解析日志体验一言难尽。第二象限是JavaCV自己写转发层。JavaCV封装了FFmpeg的Java接口能做拉流、转码、推流但实际做下来会遇到几个扎心问题JavaCV的FFmpegFrameGrabber在断流重连时很不稳定偶发内存泄漏底层native库版本跟系统环境强绑定换台服务器就要重新踩一遍编译的坑而且转发节点一旦多起来GC停顿直接导致画面卡顿排查问题非常痛苦。第三象限是SRSSimple Realtime Server。SRS确实很强大尤其在高并发直播场景下表现优秀但它的定位是直播分发对ONVIF、GB28181这类安防协议的支持不如ZLMediaKit原生。而且SRS的配置体系对刚接触流媒体的人有一些门槛很多参数需要从文档里翻半天才知道含义。第四象限就是我最后选定的ZLMediaKit。它有几个点很打动我一是底层的ZLToolKit是C11写的事件循环库性能很能打单机处理几百路RTSP完全不在话下二是原生支持RTSP、RTMP、HLS、HTTP-FLV、WebRTC等多种协议拉流、推流、转封装一体搞定不用再拼装多个组件三是提供了完善的RESTful API和WebHook事件回调SpringBoot可以直接通过HTTP请求动态添加、删除拉流代理甚至不用改C代码就能完成业务联动。这一点对Java后端来说真是太友好了我可以把ZLMediaKit当成一个“黑盒流媒体交换机”来用业务逻辑全在SpringBoot里。1.2 SpringBoot在架构里承担什么角色SpringBoot在这一整套系统里扮演的绝对不只是“提供一个接口让别人调”那么简单。我的分层设计是这样的最上层是应用服务层。这一层负责所有业务逻辑设备管理摄像头的增删改查、通道管理、用户权限谁能看哪路流、录像计划什么时候录、录多久、告警联动移动侦测触发后自动推流或截图。这些都是SpringBoot的Controller和Service在处理整个系统的“大脑”在这里。中间是信令与控制层。这一层通过HTTP调用ZLMediaKit的RESTful API完成“添加拉流代理”、“关闭流”、“查询在线流”等操作。比如用户在前端点了一个摄像头图标SpringBoot收到请求后先查数据库拿到这个摄像头的RTSP地址然后调ZLMediaKit的/index/api/addStreamProxy接口告诉流媒体服务器去主动拉取那一路RTSP流。拉流成功后ZLMediaKit会把流ID、播放地址等信息返回SpringBoot再把这些信息拼成HTTP-FLV的播放URL返回给前端。最底层是数据与事件层。ZLMediaKit会把关键事件通过WebHook推送给SpringBoot比如“流注册了”、“流注销了”、“服务器启动完成了”。SpringBoot收到这些回调后会更新数据库中对应设备的状态字段——比如设备离线时把状态置为“离线”同时触发一些告警逻辑。这样整个系统就不是“前端轮询问状态”而是“事件主动上报”实时性高很多也省服务器资源。1.3 这套架构的核心优势在哪里整套方案最核心的优势我觉得是解耦。摄像头只管推RTSP流媒体服务器只管拉流转协议SpringBoot只管业务编排前端播放器只管消费HTTP-FLV或WebRTC流。每一层的边界非常清晰任何一层出问题都能独立排查和替换。另外还有一个很重要的点是多协议输出。同一路摄像头流ZLMediaKit可以同时输出HTTP-FLV给PC浏览器延迟1秒左右、HLS给iOS Safari延迟3-5秒但兼容性最好、WebRTC给需要极低延迟的场景延迟300毫秒以内。这意味着我在对接不同场景时不用为每一种终端单独开发一路流处理逻辑只要在SpringBoot里根据播放端类型选择不同的播放地址返回就行。有一点我必须坦白ZLMediaKit默认不转码也就是只做转封装不改变视频编码格式。如果摄像头输出的是H.265/HEVC而浏览器端不支持H.265解码那HTTP-FLV播放会黑屏。这种情况有两条路可以走一条是让摄像头把编码改成H.264另一条是加上FFmpeg转码模块。我自己的做法是优先在摄像头侧改成H.264除非硬件条件不允许才考虑服务端转码因为转码对CPU的消耗实在太大一路1080P的实时转码差不多要吃满一个中高配CPU的单核路数一多成本直接起飞。2. 环境搭建与ZLMediaKit部署2.1 服务器与环境要求先聊聊硬件和系统选型。不要上来就搞Windows服务器生产环境老老实实上Linux。我自己用的Ubuntu 20.04 LTS64位系统4核8G内存起步硬盘看录像保存周期而定单纯做实时流转发的话系统盘50G就够了。如果摄像头路数超过50路建议上SSD做缓存盘因为ZLMediaKit会频繁读写临时文件来支持HLS切片和录像回看功能。编译工具链方面ZLMediaKit是C项目依赖gcc、g、cmake、make这些基础工具。还需要安装OpenSSL开发库因为RTSP的认证和一些加密操作要用到它。另外如果你想让ZLMediaKit支持FFmpeg转码还需要在编译前安装FFmpeg的开发库。不过这里我不建议直接把FFmpeg编进ZLMediaKit因为会让整个二进制膨胀很多而且转码性能瓶颈明显需要时再单独部署转码模块更灵活。2.2 编译安装与目录规划我把ZLMediaKit安装在/opt/zlm目录下编译过程分三步走对应着三个命令。先拉代码我建议直接clone master分支稳定版不要用release包因为很多bug修复只在master上。# 1. 安装依赖不同系统包名可能略有差异 apt install build-essential cmake libssl-dev git -y # 2. 克隆源码并初始化子模块 cd /opt git clone https://github.com/ZLMediaKit/ZLMediaKit.git cd ZLMediaKit git submodule update --init --recursive # 3. 编译安装 mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX/opt/zlm -DCMAKE_BUILD_TYPERelease make -j4 make install编译完成后可执行文件在/opt/zlm/bin/MediaServer配置文件是/opt/zlm/bin/config.ini。我要重点提醒一下ZLMediaKit需要两个关键目录的权限一个是logs目录一个是www目录。logs目录用来写运行日志www目录是内置的HTTP静态文件服务根目录HLS切片、截图等文件默认都会写到www目录下如果你用非root用户跑MediaServer务必给这两个目录授权否则启动时会报各种权限错误。2.3 核心配置项详解ZLMediaKit的config.ini里的配置项很多但不是每个都要动。我按重要性排序把必须改和必须知道的几项列出来。配置块[general]里的mediaServerId是这台流媒体服务器的唯一标识SpringBoot调用API时会用到。[http]里的port是HTTP API和HTTP-FLV服务的监听端口我习惯用8088而[rtsp]里的port是RTSP服务的默认端口标准就是554内网没冲突就不用改。最关键的一项配置是[hook]块下的enable和on_flow_report、on_stream_changed、on_server_started这几个回调地址。WebHook默认关闭必须打开。我把回调地址指向SpringBoot的接口比如http://127.0.0.1:8080/api/zlm/hook。这里有个坑ZLMediaKit的WebHook回调是异步的而且如果回调接口响应超时ZLMediaKit会重试所以SpringBoot的接口务必做到轻量快速不要在里面做耗时的数据库写操作。我自己的做法是先把回调消息打到一个内存队列里然后由后台线程异步处理接口本身秒回。启动ZLMediaKit直接用./MediaServer -d以后台守护模式运行然后查看日志确认启动成功。cd /opt/zlm/bin ./MediaServer -d tail -f /opt/zlm/bin/logs/MediaServer.log日志里出现start server successfully就说明起来了之后用浏览器访问http://服务器IP:8088/index/api/getServerConfig能正常返回JSON配置数据说明HTTP API也通了。2.4 使用Docker部署的替代方案如果你是临时测试环境不想折腾编译用Docker跑ZLMediaKit是捷径。官方镜像在Docker Hub上可以直接拉但我实测下来有个问题官方镜像里没有包含FFmpeg转码组件如果后续要扩转码能力得用自定义Dockerfile重新构建。所以我的建议是测试用Docker生产尽量用二进制部署这样对系统资源的控制更精细也方便用systemd做进程管理。docker run -d --name zlm \ -p 1935:1935 -p 8088:8088 -p 554:554 \ -p 10000:10000 -p 10000:10000/udp \ -v /opt/zlm/config.ini:/opt/media/conf/config.ini \ -v /opt/zlm/logs:/opt/media/bin/logs \ -v /opt/zlm/www:/opt/media/bin/www \ zlmediakit/zlmediakit:master端口映射这块要特别留意我上面把1935RTMP、554RTSP、8088HTTP、10000RTP收流全都映射出来了实际上根据你的需求可以裁剪。另外RTP收流端口是一个范围区间不是单端口在config.ini里配置的是rtp_proxy端口池以我用的4.0版本为例是10000-10100这一段。Docker映射的时候要么写成上面这种单端口映射实际只有10000生效要么用-p 10000-10100:10000-10100把整个区间都暴露出来。我第一次用Docker部署就是因为漏了这一段导致摄像头拉流后画面迟迟不出来排查了半天。3. SpringBoot集成与RTSP拉流实战3.1 项目初始化与依赖引入SpringBoot这边的工程结构我按照标准的Maven多模块来规划。父工程只做依赖管理子模块分成monitor-common公共工具类、实体类、monitor-core核心业务逻辑、monitor-boot启动类、Controller层、monitor-clientZKMediaKit的API客户端封装。这样做的好处是以后如果要把流媒体管理拆成独立微服务可以直接把monitor-client和monitor-core抽出去变成一个独立的工程。依赖方面除了SpringBoot Web和Validation之外我用Hutool来做HTTP调用。Hutool的HttpUtil工具类封装了超时、重试、异常捕获的逻辑比手写HttpURLConnection省太多事了。另外用Fastjson2做JSON序列化解析ZLMediaKit返回的嵌套JSON特别方便。因为我这里面没有复杂的对象关系映射数据库操作直接用Spring Data JPA就够了。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.25/version /dependency dependency groupIdcom.alibaba.fastjson2/groupId artifactIdfastjson2/artifactId version2.0.46/version /dependency /dependencies3.2 封装ZLMediaKit的RESTful客户端ZLMediaKit的API调用方式很统一都是/index/api/开头的HTTP接口参数里带一个secret这个secret在config.ini里配置相当于API调用的密钥。我把这块封装成一个ZlmClient组件把常用的添加拉流代理、关闭流、查询流信息、获取服务器配置这些操作全包进去。需要说明的是加拉流代理这个方法很关键。addStreamProxy的参数有vhost虚拟主机、app应用名、stream流ID、url源地址也就是摄像头的RTSP地址这几个核心字段。stream这个参数是我们自己命名的逻辑流ID要保证全局唯一我一般用设备的编码或者数据库自增ID来生成比如device_001。这样后续不管查询流状态还是关闭流都用这个流ID来定位。Component public class ZlmClient { Value(${zlm.host}) private String zlmHost; Value(${zlm.port}) private Integer zlmPort; Value(${zlm.secret}) private String zlmSecret; private String getBaseUrl() { return http:// zlmHost : zlmPort /index/api/; } /** * 添加拉流代理 */ public JSONObject addStreamProxy(String streamId, String rtspUrl) { MapString, Object params new HashMap(); params.put(secret, zlmSecret); params.put(vhost, __defaultVhost__); params.put(app, live); params.put(stream, streamId); params.put(url, rtspUrl); params.put(auto_close, true); // 无人观看时自动关闭流 String body HttpUtil.post(getBaseUrl() addStreamProxy, params); return JSON.parseObject(body); } /** * 关闭流 */ public JSONObject closeStream(String streamId) { MapString, Object params new HashMap(); params.put(secret, zlmSecret); params.put(stream, streamId); params.put(app, live); String body HttpUtil.post(getBaseUrl() close_stream, params); return JSON.parseObject(body); } /** * 查询流信息 */ public JSONObject getMediaList(String streamId) { MapString, Object params new HashMap(); params.put(secret, zlmSecret); params.put(stream, streamId); String body HttpUtil.post(getBaseUrl() getMediaList, params); return JSON.parseObject(body); } /** * 获取HTTP-FLV播放地址 */ public String buildFlvUrl(String streamId) { return http:// zlmHost : zlmPort /live/ streamId .flv; } }3.3 设备接入与拉流流程完整实现设备接入的完整业务逻辑是这样的前端提交一个摄像头设备信息设备名称、RTSP地址、所属分组SpringBoot先把设备信息保存到数据库然后调addStreamProxy让它立即拉流验证这条RTSP地址能否正常取流。如果返回的code是0并且有播放路径说明拉流成功把设备状态置为“在线”同时给前端返回播放URL。如果拉流失败就把设备状态置为“离线”并记录失败原因。写入Controller和Service时需要特别注意一点HikariCP连接池的配置要调大一点。因为拉流操作涉及HTTP调用如果做同步流程在摄像头网络延迟大的情况下一次拉流的HTTP调用最快也要1-2秒这个过程中数据库连接是持有状态并发一起来连接池很快就打满了。所以我建议把spring.datasource.hikari.maximum-pool-size从默认的10调到50左右同时Service层的方法加Async注解改成异步执行主接口立刻返回“正在连接中”的状态前端再通过轮询或者WebSocket接收状态更新。Service public class DeviceService { Autowired private DeviceRepository deviceRepository; Autowired private ZlmClient zlmClient; /** * 接入新设备 */ public DeviceInfo addDevice(DeviceAddRequest request) { DeviceInfo device new DeviceInfo(); device.setDeviceName(request.getDeviceName()); device.setRtspUrl(request.getRtspUrl()); device.setGroupId(request.getGroupId()); device.setStatus(0); // 0-离线 1-在线 2-拉流中 device.setCreateTime(LocalDateTime.now()); deviceRepository.save(device); // 异步发起拉流 pullStreamAsync(device.getId(), request.getRtspUrl()); return device; } Async public void pullStreamAsync(Long deviceId, String rtspUrl) { String streamId device_ deviceId; // 先关闭可能残留的旧流避免流ID冲突 zlmClient.closeStream(streamId); JSONObject result zlmClient.addStreamProxy(streamId, rtspUrl); if (result.getIntValue(code) 0) { deviceRepository.updateStatus(deviceId, 1); log.info(设备{}拉流成功, streamId{}, deviceId, streamId); } else { deviceRepository.updateStatus(deviceId, 0); log.error(设备{}拉流失败: {}, deviceId, result.getString(msg)); } } }3.4 播放地址生成与前端对接拉流成功之后就可以给前端返回播放地址了。前端播放我推荐用Jessibuca这个播放器。它是纯H5的不用装插件支持HTTP-FLV和WebSocket-FLV解码走WASM兼容性比flv.js好很多特别是一堆老旧的Windows机器上的Chrome也能正常跑。对接方式很简单前端拿到播放URL后设置给播放器实例就行。播放URL的格式取决于你拉流代理里配置的app名。如果app是live流ID是device_1那么HTTP-FLV地址就是http://服务器IP:8088/live/device_1.flv。WebSocket-FLV地址则是ws://服务器IP:8088/live/device_1.live.flv。前端根据自身环境选一个合适的来播。需要注意跨域问题。如果你的前端页面部署在另一个域名或端口上播放器请求ZLMediaKit的8088端口时会被浏览器的跨域策略拦截。解决办法是在ZLMediaKit的config.ini里找到[http]配置块下的allow_cross_domains设为1即可开启CORS跨域。如果你有自定义域名或需要HTTPS访问还要配置ssl_cert和ssl_key这两个SSL证书文件路径并且把HTTP服务端口改成443。这些在实测中都是踩过的坑提前说清楚能少走弯路。4. 摄像头RTSP地址配置与兼容性处理4.1 海康、大华等主流摄像头RTSP地址格式项目里对接的设备种类多了之后我发现RTSP地址的写法每家都有自己的性格搞错了就拉不出流。我直接把常见设备的地址规则整理成了一张表方便大家直接套用。海康威视的新版固件地址格式是rtsp://用户名:密码IP地址:554/Streaming/Channels/101最后的101代表通道1的主码流102是通道1的子码流。子码流分辨率低、码率小适合网格预览画面主码流清晰度高适合单路放大查看。如果遇到海康的老设备地址格式可能变成rtsp://用户名:密码IP地址:554/h264/ch1/main/av_stream。大华的地址格式是rtsp://用户名:密码IP地址:554/cam/realmonitor?channel1subtype0channel是通道号从1开始subtype为0是主码流为1是子码流。还有一部分大华NVR的地址是rtsp://用户名:密码IP地址:554/Streaming/Channels/101和海康类似具体要看固件版本。宇视的地址是rtsp://用户名:密码IP地址:554/MediaInput/1/1后面两个1分别代表通道和码流类型。其他杂牌摄像头很多基于RTSP标准实现地址格式五花八门无法一一列出。我的建议是拿到设备先用VLC或者PotPlayer本地验证RTSP地址是否能出画面确认没问题再接进系统。这里我要特别提醒很多摄像头的RTSP用户不是后台登录的管理员账号而是需要在“安全”-“用户管理”里单独添加一个RTSP协议用户如果你用管理员账号去拉流有时候会因为权限策略问题被拒。4.2 不同编码格式的处理策略摄像头视频编码格式主要分H.264和H.265两种。H.264兼容性好基本所有播放端都支持H.265压缩率更高同等画质下码率大约是H.264的一半但浏览器端的支持情况很不理想。ZLMediaKit拉流成功后会返回流的编码信息在代理添加接口的返回JSON里有个codec字段可以看到是H264还是H265。我在SpringBoot里做了这样一个逻辑如果设备编码是H.265先尝试用HTTP-FLV播放部分新版Chrome解码能力提升了能软解H.265但卡顿风险大同时提供HLS备用播放地址给iOS SafariSafari对H.265的支持还行。如果两种方式都不行就需要在摄像头后台把编码改成H.264。在项目文档里我直接给用户写了一条硬性要求接进来的摄像头主码流编码优先用H.264不要用H.265这一条能省掉90%的播放兼容性问题。4.3 断流重连与流状态监测监控系统的稳定性很大程度由断流重连机制决定。摄像头离线、网络抖动、设备断电重启都会导致RTSP流中断如果不做处理播放器画面会一直卡在最后一帧非常影响体验。我做的第一层保障是WebHook的状态上报。ZLMediaKit的on_stream_changed事件会在流注册和注销时回调注销了就说明这条流断了。SpringBoot收到回调后把设备状态置为离线并启动一个延迟任务比如30秒后尝试重新拉流。第二层保障是内部的流状态巡检。我写了一个定时任务每30秒调用一次getMediaList查询所有应该在线的流如果发现有设备状态是“在线”但流已经消失了就触发重连逻辑。这个巡检机制看似简单但非常重要因为WebHook回调偶尔会因为网络问题丢失巡检兜底能确保系统最终收敛到正确的状态。Component public class StreamMonitorTask { Autowired private DeviceRepository deviceRepository; Autowired private ZlmClient zlmClient; Scheduled(fixedDelay 30000) public void checkStreamStatus() { ListDeviceInfo onlineDevices deviceRepository.findByStatus(1); for (DeviceInfo device : onlineDevices) { String streamId device_ device.getId(); JSONObject mediaList zlmClient.getMediaList(streamId); JSONArray data mediaList.getJSONArray(data); boolean streamAlive data ! null !data.isEmpty(); if (!streamAlive) { log.warn(设备{}流已断开尝试重连, device.getId()); deviceRepository.updateStatus(device.getId(), 2); zlmClient.addStreamProxy(streamId, device.getRtspUrl()); } } } }这里有一个值得优化的细节重连不能过于频繁。我踩过的坑是摄像头断电重启需要1-2分钟如果每30秒重连一次ZLMediaKit会在摄像头还没起来时持续报错既刷日志又浪费资源。我的方案是分级退避重连第1次重连在断流后30秒第2次在60秒之后每隔5分钟重试连续重试失败10次后不再自动重试只发告警通知人工介入。等摄像头恢复后用户主动点一次“重连”按钮或者WebHook收到流注册事件时自动把状态恢复为在线。5. 录像回放与告警联动扩展5.1 通过MP4自动录像实现回放实时预览只是监控系统的基础能力真正能打动用户的是录像回放。ZLMediaKit内置了MP4录制功能可以在拉流代理里把enable_mp4参数设为1这样流建立后会自动录制MP4文件到服务器。但这样做有几个不便一是所有流都录制磁盘空间扛不住二是没有录像计划的概念不能按星期几、时间段来灵活指定录制策略。我在SpringBoot里实现了自己的录像计划模块。数据库里建了一张record_plan表字段包括设备ID、录像类型持续录像/定时录像/事件联动录像、开始时间、结束时间、存储保留天数。定时任务每分钟扫描一次计划表到了指定的录像时段就调用ZLMediaKit的addStreamProxy接口把enable_mp4设为1并指定mp4_save_path为按设备分目录的路径录像结束后自动关闭代理并停止录制。这样既实现按需录像又能按设备归档文件。录像文件的检索和播放也比较直接。录制生成的MP4文件路径可以在ZLMediaKit的录像文件查询API里拿到我的实现是在SpringBoot里维护一个录像文件索引表定时任务扫描每个设备的录像目录把新生成的文件信息开始时间、结束时间、文件大小、存储路径写入数据库。前端打开回放页面的时候设备ID和时间区间作为查询条件就能列出对应的录像列表播放时直接把MP4文件地址交给video标签播放。如果服务器走的是Nginx静态文件服务记得在Nginx配置里加location /record/的别名映射。5.2 基于WebHook的移动侦测告警联动智能监控不搞点告警联动总觉得少了灵魂。我们后端只做业务调度真正的算法可以是你自己训练的模型也可以是调ONVIF协议的移动侦测接口。我项目里的做法是摄像头开启移动侦测后事件推送到ZLMediaKit有些摄像头可以直接配RTSP的event订阅有些要轮询ONVIF事件ZLMediaKit回调WebHookSpringBoot收到后把告警事件入库同时调播放器接口把实时画面弹到值班大屏上再做一步截图保存。截图这个功能是ZLMediaKit自带的非常实用。调用/index/api/getSnap接口传入流ID和播放URL它就能返回一张当前画面的JPG截图。告警时我每次都截一张图存起来作为告警的证据辅助。实际效果是当摄像头检测到画面变化时最快5-8秒内运维人员就能在告警列表里看到一条带截图的告警记录点开就能看当时的现场画面和前后各30秒的录像回放。这个体验用户反馈很不错。5.3 多级级联与集中管理架构如果你的项目不是单台服务器而是分公司、多地域部署每台服务器各跑一套系统那管理成本就上来了。ZLMediaKit支持集群级联的一种简单方式是“拉流级联”A站点的设备由A站点服务器拉流B站点的服务器通过“源拉流”模式把A站点服务器的流再拉过来。这样B站点只需保存转发地址不直接连接摄像头既减轻了摄像头压力又方便了集中管理。SpringBoot这边我建了一张server_node表来管理边缘节点核心服务从每个节点查询在线流列表统一汇总到总控台展示。节点之间通过WebSocket或HTTP回调实时同步状态。这种级联模式最典型的好处是总部领导在办公室就能直接看全国连锁门店的实时画面只要总部的带宽允许多路并发播放非常流畅完全不需要每家门店单独开账号登录去看。6. 常见问题与排查技巧实录6.1 “拉了代理但播放黑屏”的排查路径这个是我被问得最多的问题没有之一。黑屏的原因有一长串但大部分时候都是下面几类。第一编码是H.265但播放器不支持。这个最好判断打开浏览器的开发者工具看控制台如果是解码报错日志里通常会有编码格式相关的关键字。解决办法就是改成H.264或者用支持H.265的播放器方案。第二拉流成功但画面是静帧或者不出流。这种情况先看ZLMediaKit日志最常在日志里看到的是get key frame failure或者track is empty。这两个错误说明摄像头输出的数据里缺少关键帧GOP开头处的I帧。ZLMediaKit只有在收到关键帧之后才能开始向播放端输出数据。出现这个问题的原因大多是摄像头的参考帧间隔配置得太长或者用了B帧但配置不合理。我一般建议把摄像头的“I帧间隔”也叫GOP长度设置为帧率的两倍例如25fps的帧率就设为50这样每2秒至少有一个关键帧既能保证画面快速起播又不会太占带宽。第三网络问题导致RTP包丢失。RTSP拉流走的是UDP时在跨路由、有防火墙的场景下很容易出现丢包。ZLMediaKit的RTP收流支持TCP模式在拉流代理的参数里可以加rtsp_rtp_tcp1强制使用TCP传输RTP包。这个参数能解决80%的跨网段拉流不稳定问题。TCP模式虽然会略微增加网络开销和延迟但稳定性大幅提升。为了验证这个猜想我在一台内网摄像头上做了组播和跨VLAN测试发现在跨VLAN时UDP模式丢包率高达5%-10%画面马赛克严重切到TCP模式后马赛克几乎消失所以生产环境我毫不犹豫地全线开启TCP传输。6.2 服务器端口不通导致拉流失败很多新手在调试的时候明明在服务器本机测试RTSP地址能出流但SpringBoot调ZLMediaKit就是拉不过来最后发现是服务器安全组或者防火墙没有放行RTSP端口。这里有个容易产生误导的细节防火墙不只影响摄像头到ZLMediaKit的554端口还影响RTP动态端口的接收。ZLMediaKit收到RTSP信令后会开启一个RTP端口用来接收媒体的实际数据流这些端口范围是在config.ini的[rtp_proxy]里配置的。如果你的服务器只放行了554端口RTP数据是进不来的表现为信令正常但画面出不来。排查命令用ss -tunlp | grep MediaServer查看端口监听情况再配合在摄像头上用telnet 服务器IP 端口测试连通性一步步缩小范围。我在项目初期因为RTP端口段没放行整整卡了一个下午后来把整个10000-10100端口段全部放行才解决问题。6.3 高并发下的性能瓶颈与优化多路并发时ZLMediaKit最常暴露的性能瓶颈是线程模型和磁盘IO。ZLMediaKit基于事件循环核心线程数默认是CPU核心数我用threads配置项设置了合理的并发度。一个比较诡异的优化点是udp_sock_buf_size这个参数它控制UDP缓存区大小。在视频码率高、网络抖动大的时候加大这个值能有效减少因为缓冲区溢出导致的RTP丢包。我通常设置在4MB左右。参考经验数据在4核8G的普通服务器上ZLMediaKit做纯转封装不转码拉50路1080P主码流之外再拉50路子码流做预览CPU占用在40%左右内存占用3GB上下。但是如果你用FFmpeg转码50路直接能把CPU吃到100%而且相机源稍微卡顿还会引发级联效应拖垮整个进程。所以除非你的业务非常依赖转码否则尽量用硬件编码好的H.264来跑整个链路。6.4 请求返回超时与日志排查技巧addStreamProxy接口偶尔会出现返回超时或者一直返回code-1的情况。这时需要去看ZLMediaKit的日志但日志文件默认是轮转的位置在logs/目录下。我习惯在测试阶段直接把日志级别调到traceconfig.ini里[log]配置块的log_level默认为debug测试期可以临时调成trace以查看更多上报细节。生产环境务必调回debug或info不然日志量会大到吓人。另一个排查流媒体问题的利器是Wireshark。直接用Wireshark抓摄