简介：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 以及 SRT，WebRTC 还标记为实验特性。这意味着同一个live/test流，RTSP 客户端能拉、浏览器里的 flv.js 能拉、手机上的 VLC 也能用 RTSP 拉，不需要为每种协议单独部署一套服务。
这个“接入层”定位在 Windows 上的价值很直接。很多安防摄像头只支持 RTSP 或 GB/T 28181 协议输出，而你的业务系统可能只愿意消费 HTTP-FLV 或 HLS。常见做法是让 ZLMediaKit 跑在中间，摄像头推给 ZLM，ZLM 再把流转成业务方需要的格式。做 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 是 554，RTMP 是 1935，HTTP 是 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?start=0或者直接用 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] port=554，改成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.265（HEVC），而 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] secret=your-own-secret-value [rtsp] port=10554 [general] logLevel=2这三个字段的解释：logLevel=2表示只记录警告级别以上的日志，避免高频推流时控制台被刷屏。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?secret=your-own-secret-value" curl -s "http://127.0.0.1/index/api/close_streams?secret=your-own-secret-value&vhost=__defaultVhost__&app=live&stream=test"第一条命令返回所有正在推流的媒体流信息，包含 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 stream=codec_name,width,height,r_frame_rate -of default=noprint_wrappers=1 rtsp://127.0.0.1:10554/live/test这条命令只显示视频流的关键字段。看到codec_name=h264就放心，如果出现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 本身。希望帮到你。
本文还有配套的精品资源，点击获取
