简介ZLMediaKit是一款轻量级流媒体服务器支持RTSP、RTMP、HLS、HTTP-FLV等协议适合直播推流、实时互动、监控转播等低延迟场景。这份2024年5月30日编译的Windows 64位版本面向需要在Windows环境快速部署MediaServer的开发者与运维人员免去源码编译和依赖配置的麻烦。压缩包共61个文件、约30.67MB包含核心可执行程序、动态链接库、JS前端组件、HTML页面、配置与日志等目录区分运行程序、Web资源和辅助库结构清晰便于直接使用。已有909人学习下载。借助现成的二进制文件和示例配置用户可以立即启动流媒体服务进行HTTP-FLV、RTSP、HLS等协议验证也可基于自带API做二次开发快速搭建面向在线教育、游戏直播、安防监控的推拉流系统。1. 2024-05-30 这份 Windows 预编译包解决了流媒体接入的哪个卡点如果你手上有一台 Windows 机器想把摄像头 RTSP 流拉进来、统一对外输出成 RTMP 或 HTTP-FLV或者想在本地快速验证 ZLMediaKit 能不能满足项目需求那这个标题指向的这份预编译好的 ZLMediaKit-windows64 版本就是为你准备的。它省掉了在 Windows 上配置 Visual Studio、CMake、OpenSSL 等一堆依赖的编译过程解压后直接面对MediaServer.exe。你不需要读懂 C 源码也能把一套完整的流媒体服务跑起来。这篇笔记讲清楚它是什么、怎么启动、参数怎么改、哪里最容易翻车。2. ZLMediaKit 的内核拆解为什么一台 Windows 机器能同时当 RTSP、RTMP、HTTP-FLV 网关2.1 从 RTSP 到 WebRTC它内置了哪些协议标准为什么适合做接入层ZLMediaKit 不是一个“播放器”而是一个流媒体服务器更准确地说是一个流媒体网关。它接收上游推过来的流把流归一到内部管道里再按请求方的协议格式分发出去。以 2024-05-30 这个时间节点的版本来看它稳定支持 RTSP推流和拉流、RTMP推流和拉流、HTTP-FLV、HLS 以及 SRTWebRTC 还标记为实验特性。这意味着同一个live/test流RTSP 客户端能拉、浏览器里的 flv.js 能拉、手机上的 VLC 也能用 RTSP 拉不需要为每种协议单独部署一套服务。这个“接入层”定位在 Windows 上的价值很直接。很多安防摄像头只支持 RTSP 或 GB/T 28181 协议输出而你的业务系统可能只愿意消费 HTTP-FLV 或 HLS。常见做法是让 ZLMediaKit 跑在中间摄像头推给 ZLMZLM 再把流转成业务方需要的格式。做 AI 分析的同行更是经常把 ZLM 放在检测链路的前级先统一接入摄像头流再统一输出给 yolov 这类推理服务读取帧。它的优势是协议转换全部在服务端完成客户端不需要装任何私有 SDK。2.2 为什么选择预编译版本MSVC 工具链与运行时依赖的隐形门槛Windows 上编译 ZLMediaKit 的痛点不是代码本身而是工具链。官方推荐用 Visual Studio 配合 CMake 构建但实际编译时需要处理 OpenSSL、zlib、libsrtp 等第三方库版本对不上就会在 CMake 配置阶段报错。尤其是当你尝试用 MSVC 编译 FFmpeg 之后再来编 ZLM你会发现两个项目的运行库依赖经常打架——一个要静态链接一个要动态加载。这种问题在 Linux 上用 apt 装依赖很容易解决在 Windows 上却要花掉大半天。预编译版本的价值就在这里它已经把 MSVC 工具链下的编译产物、运行时 DLL、默认配置和 Web 管理页面打包好了。你不需要知道编译时用了哪个版本的 OpenSSL也不需要手动拷贝第三方库。但有一个前提要记住MSVC 编译出来的程序依赖 Visual C Redistributable 运行库。如果目标机器是干净的 Windows Server首次运行之前最好装上 VC 2015-2022 x64 运行库否则程序会闪退而且没有任何界面提示。这不是 ZLM 的问题是所有 MSVC 编译程序都有的隐性要求。3. 把预编译包变成可推流可拉流的服务解压、启动与首条测试流3.1 解压与首次启动识别目录结构让 MediaServer.exe 跑起来拿到压缩包后先别急着双击。把内容完整解压到一个不含中文和空格的路径下例如D:\zlm。解压后你会看到几个关键目录bin里是MediaServer.exe主程序conf里是config.ini配置文件www目录存放 Web 静态资源和一个默认的 H5 播放器页面。注意MediaServer.exe启动时会读取相对路径下的配置所以先确认你当前的工作目录正确。cd /d D:\zlm\bin MediaServer.exe -c ..\conf\config.ini-c参数的作用是指定配置文件的绝对或相对路径。如果你不加这个参数程序也会去默认位置找配置但一旦工作目录不对它会生成一份全新默认配置端口和 secret 都会重置。第一次启动时控制台会打印监听端口信息默认 RTSP 是 554RTMP 是 1935HTTP 是 80。看到API server started之类的日志说明服务已经起来。启动这一步有两个容易被忽略的点。第一如果你在 PowerShell 里运行路径中的..要确认解析正确建议直接写绝对路径。第二554 端口在 Windows 上默认被系统 http.sys 占用如果日志提示端口绑定失败先换成管理员权限再启动或者改配置端口。这两个坑我在下一章详细说。3.2 用 FFmpeg 推一条测试流RTSP 推流的完整命令与最小参数服务起来了接下来要往里灌数据。最简单的方式是用 FFmpeg 把本地视频文件以 RTSP 协议推给 ZLMediaKit。没有摄像头的场景下这个命令能模拟一路持续的直播流足够验证整个链路。ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:554/live/test这里几个参数值得解释。-re让 FFmpeg 按视频的原始帧率读取文件而不是全速推完这是推流测试的基本要求。-stream_loop -1表示无限循环适合长时间挂机验证稳定性。-c copy直接复用文件里的编码数据不做转码CPU 占用会很低但前提是你的测试文件编码格式能被 ZLM 接受。-rtsp_transport tcp强制走 TCP 传输在 Windows 防火墙环境下比 UDP 更稳定。推流成功后ZLMediaKit 的控制台会打印收到流的相关日志你可以同时打开浏览器访问http://127.0.0.1/在首页的播放器里输入rtsp://127.0.0.1:554/live/test直接预览。这一步如果能出画面说明从推流到存储再到拉流的内部链路已经完全打通。如果没画面先检查日志里有没有auth failed之类的鉴权提示默认配置下推流鉴权是关闭的但如果 config.ini 被重新生成过行为可能不同。3.3 VLC 与 FFplay 拉流验证确认流已经进入媒体管道推流成功只是上半场还要验证拉流侧能不能正常消费。我一般同时用两种方式验证一个是 FFplay另一个是 VLC因为这两个播放器在 Windows 上最常见也能暴露不同的解码问题。ffplay -rtsp_transport tcp rtsp://127.0.0.1:554/live/test ffplay http://127.0.0.1/live/test.flv第一条走 RTSP 拉流第二条走 HTTP-FLV 拉流。注意第二条的 URL 结构http://127.0.0.1/live/test.flv其中live是 app 名test是流名.flv表示以 FLV 封装格式输出。这是 ZLM 比较有代表性的能力——同一路流协议的消费方式完全由 URL 后缀决定。视频流地址是test.flv如果要把音频也拉出来可以写test.flv?start0或者直接用 VLC 打开原始 RTSP 地址。VLC 里的操作路径是“媒体 → 打开网络串流 → 输入rtsp://127.0.0.1:554/live/test”。这里要留个心眼如果你的测试视频编码是 H.265而 VLC 版本较旧或者浏览器不支持画面会黑屏甚至直接退出。这不是 ZLM 的问题是播放器解码能力不足。建议第一次测试时优先用 H.264 编码的视频文件减少变量。拉流验证通过之后你才有底气去改端口、加鉴权、接业务回调。4. Windows 下使用 ZLMediaKit 的避坑记录闪退、端口占用与黑屏排查4.1 双击 MediaServer.exe 闪退运行库缺失能直接让程序“闭嘴”现象程序刚启动就消失控制台窗口一闪而过有时候连日志都看不到。原因最常见的不是配置错误而是目标机器缺少 Visual C 运行库。MSVC 编译的程序会在启动时动态加载VCRUNTIME140.dll等文件缺失时进程直接终止。解决办法先去 Windows 事件查看器里看应用程序日志如果出现0xc000007b或0xc0000135错误码基本可以断定是运行库问题。装一遍 VC 2015-2022 x64 Redistributable重启服务问题就消失了。我见过不少同事在这上面耗费时间原因是他们相信“绿色免安装”的说法忽略了 MSVC 运行库这个隐性依赖。4.2 554 端口被系统保留RTSP 默认端口为什么需要管理员权限现象启动日志里提示端口绑定失败但 netstat 查不到 554 端口被其他进程占用。原因Windows 的 http.sys 内核驱动默认会绑定 554 端口用于 RTSP 服务这导致普通权限下 ZLM 无法监听同一端口。解决办法有两个方向。一是以管理员身份启动MediaServer.exe让它有权绕过限制二是修改配置里的[rtsp] port554改成10554客户端拉流地址同步换成rtsp://127.0.0.1:10554/live/test。如果你是在开发机上测试第一种更方便如果要部署到客户的 Windows Server 上建议直接换端口避免每次都要求管理员权限。4.3 防火墙拦截导致拉流超时客户端能看到“连接被拒绝”吗现象本地推流正常但局域网内另一台机器用ffplay rtsp://192.168.x.x:554/live/test拉流时一直转圈或提示超时。原因Windows 防火墙默认阻止了 ZLM 监听的 TCP 端口尤其是 554、1935、80 这些非常规入站端口。解决办法第一次启动 ZLM 时Windows 会弹出防火墙授权对话框很多人直接点了取消此时去“控制面板→Windows Defender 防火墙→允许应用通过防火墙”里把MediaServer.exe加入例外。如果没弹窗就手动添加注意同时勾选“专用”和“公用”网络。还有一点如果你改了端口新的端口也需要加入放行规则。4.4 拉流黑屏但有声音H.265 流与播放器解码能力不匹配现象FFplay 能收到流音频正常但视频区域全黑或者 VLC 直接不出画面。原因视频编码是 H.265HEVC而 Windows 上很多播放器默认没有 HEVC 解码器尤其是 VLC 3.0 以下的版本对 H.265 的支持不太稳定。解决办法有两条路。最简单的换用 H.264 编码的测试视频更符合生产场景的在推流端用 FFmpeg 做转码命令大致是ffmpeg -re -i input.mp4 -vcodec libx264 -acodec aac -f rtsp rtsp://127.0.0.1:554/live/test。另外要注意 Windows 商店里的“HEVC 视频扩展”是收费的别指望所有客户端都会装。做交付时如果客户播放器不可控服务端直接限制只接收 H.264 更省心。4.5 浏览器拉 WebRTC 流失败它还是“实验特性”别当稳定 API 依赖现象配置里能看到 WebRTC 相关选项但浏览器端播放一直没有画面控制台报 ICE 或证书相关错误。原因zlmediakit 的 WebRTC 在 2024 年这个时期仍然标记为实验性它依赖 ICE 端口分配和 HTTPS 证书Windows 预编译版本默认不会把整套 WebRTC 环境配置好。解决办法生产环境不要依赖 WebRTC 输出优先用 HTTP-FLV 配合 flv.js 做浏览器播放兼容性最好。如果你确实要评估 WebRTC 性能建议去官方文档查最新的编译和配置要求而不是在预编译包上反复尝试——这个特性对部署环境的要求远超出“解压即用”的范畴。5. 让服务进入可用状态Config.ini 关键参数、REST API 与鉴权回调5.1 Config.ini 里必须改的三个字段端口、secret、日志级别预编译包默认能跑但要往生产方向靠配置文件必须动。打开conf/config.ini重点看[api]、[rtsp]、[general]三个节区。第一个要改的是api.secret这是一个访问 REST API 的共享密钥默认值是一串 UUID不同版本可能不一样。不修改的风险是局域网内知道地址的人可以直接调用管理接口拉走你的流列表甚至关闭流。第二个要改的是监听端口[rtsp] port和[http] port生产环境建议避开默认端口减少扫描攻击面。第三个是日志级别[general] logLevel默认可能是 0跟踪级别日志刷得飞快日积月累会占用不少磁盘。[api] secretyour-own-secret-value [rtsp] port10554 [general] logLevel2这三个字段的解释logLevel2表示只记录警告级别以上的日志避免高频推流时控制台被刷屏。secret改成你自己的随机字符串后所有 REST API 请求都要带上?secret参数否则返回 401。端口修改后VLC 和 FFplay 的拉流地址也要同步改否则会被连接拒绝。配置文件修改后必须重启MediaServer.exe才能生效这是最容易漏掉的一步——改完文件不重启程序仍然跑在旧参数上。5.2 用 REST API 查流和踢流不登录服务器也能做运维ZLM 自带了一套 HTTP REST API日常运维完全不需要登录服务器看控制台。查询当前所有在线流用getMediaList关闭某一路流用close_streams这两个接口是我平时用频率最高的。它们在 Windows 命令行下用 curl 就能调用。curl -s http://127.0.0.1/index/api/getMediaList?secretyour-own-secret-value curl -s http://127.0.0.1/index/api/close_streams?secretyour-own-secret-valuevhost__defaultVhost__applivestreamtest第一条命令返回所有正在推流的媒体流信息包含 app、stream、协议类型、客户端数量等字段。第二条命令关闭live/test这路流注意vhost参数默认是__defaultVhost__如果你没改过 virtual host 配置这个值保持不变。这里有个 Windows 特有的坑PowerShell 里curl是Invoke-WebRequest的别名参数语法完全不一样会直接报错。解决方法是调用真实的 curl 可执行文件写成curl.exe或者干脆用Invoke-RestMethod写 PowerShell 原生命令。我建议直接用curl.exe减少跨 shell 的兼容问题。5.3 二次开发的方向Hook 回调、推流鉴权和拉流鉴权ZLM 的 REST API 适合人工操作但它真正适合被业务系统集成的点在于“事件回调”。它可以在推流开始、拉流开始、流关闭等时机向你的业务服务器发送 HTTP POST 请求让你决定是否放行。这是做流媒体平台最常用的鉴权方式。常见做法是在config.ini里配置[hook]节区的回调地址业务服务收到回调后返回 JSON 控制指令。{ app: live, stream: test, ip: 192.168.1.10, port: 554, schema: rtsp }这是推流鉴权回调里携带的基础字段你的业务服务需要根据stream或携带的 token 判断这个客户端有没有推流权限。返回{code: 0}表示放行返回非 0 则拒绝。判断拉流权限用的是另一组回调事件逻辑类似。这一段的重点是ZLM 把“权限判断”这个动作完全交给了业务系统它只负责转发事件和执行结果。如果你只是本地测试可以暂时不管 hook 配置但如果你要做一个允许外部用户推流的平台这个机制就是你安全体系的基石不经过它会很难控制谁在往你的服务器灌流。6. 进阶验证用 ffprobe 与协议转换确认你的流“没白推”6.1 用 ffprobe 验证流内容不打开播放器也能判断编码拉流有画面只能说明通路是通的但你还需要确认流内容本身符合预期尤其是编码格式、分辨率、帧率这些元数据。手动打开 VLC 看信息太慢ffprobe 一条命令就能完成。ffprobe -v error -show_entries streamcodec_name,width,height,r_frame_rate -of defaultnoprint_wrappers1 rtsp://127.0.0.1:10554/live/test这条命令只显示视频流的关键字段。看到codec_nameh264就放心如果出现hevc记得确认你的客户端播放器是否支持。r_frame_rate显示的是平均帧率如果推流端使用了 B 帧这个值可能和预期有偏差但不一定代表故障。这个验证习惯在排查“客户端黑屏”问题时特别有效——你可以很快分清是 ZLM 分发问题还是播放器解码问题。6.2 用一进多出验证网关能力RTSP 输入HTTP-FLV 输出最后一个技巧回到 ZLM 的本质。你可以同时用 ffplay 拉 RTSP用浏览器打开 HTTP-FLV 预览页再用 ffmpeg 从本机再推一路流。这三条链路互不干扰因为它们走的是同一个流媒体管道而不是三份独立缓存。我在 Windows 上做过一次压力很小的测试一路 RTSP 摄像头推入同时让 VLC 拉 RTSP、浏览器拉 HTTP-FLV、手机拉 HLS全部正常出画面。这验证的不只是 ZLM 的工作正常更是你在生产架构中选择它作为统一流媒体接入层的合理性——它能把不同协议端的兼容性问题收敛到一个节点上解决。我自己的习惯是每次拿到新的 ZLM 预编译版本第一件事不是部署到服务器而是在本机跑通“ffmpeg 推流 → ffprobe 验证 → 浏览器预览”这条链路确认这个版本的 HTTP-FLV 输出没有回归问题然后再动配置、改鉴权。如果你第一次在 Windows 上接触 ZLMediaKit建议也从这个最小闭环开始确认日志里出现收到流的提示之后再去改端口和 secret。把这条路走通你遇到的大部分问题都会在网络层面和播放器层面找到答案而不是在 ZLM 本身。希望帮到你。本文还有配套的精品资源点击获取