简介ZLMediaKit是一款轻量级流媒体服务器支持RTSP、RTMP、HLS、HTTP-FLV等常用协议适用于直播推流、在线教育、远程会议和监控视频分发等场景。本压缩包提供2024年5月30日编译的Windows 64位可运行版本共61个文件整体30.67MB。包内以MediaServer.exe主程序及配套dll、lib库文件为核心同时包含前端Web页面js、html、css、配置文件ini、json、日志及证书等其中js与html用于控制台和Web管理界面dll与lib保障协议解析与编解码功能pem证书用于安全连接。用户无需自行编译解压后按官方说明修改config.ini即可启动服务适合希望快速搭建流媒体服务或进行二次开发的开发者。当前已有909人学习下载该版本在Windows 64位环境下的兼容性与稳定性已得到验证可作为直播推流或流媒体分发项目的直接基础。1. 为什么你要关心一个“编译好的 Windows64 版”如果你做流媒体接入或者要把某个安防平台的摄像头统一转成 Web 播放地址ZLMediaKit 这个名字大概率绕不过去。它把 RTSP、RTMP、HTTP-FLV、HLS 这些常见协议收在一个进程里同一个端口对外提供省掉同时维护多个服务进程的麻烦。但真正到了 Windows 这台机器上编译它和 Linux 上是两回事依赖库版本挑来挑去、CMake 生成一次一个样、缺符号缺头文件会让你怀疑工具链坏了。于是当一份 2024-05-30 编译完成的 Windows64 预编译包出现时它解决的第一个问题就是“别折腾工具链先把服务跑起来”。这篇文章就围绕这个包讲清楚目录长什么样、怎么启动、如何用 FFmpeg 推流验证、Windows 上会撞到哪些坑以及最后如何判断这份二进制能不能长期信任。2. 从解压到跑起来目录、启动命令与一条自检链路2.1 解压后先认清目录可执行文件、配置与依赖库拿到包以后我建议不要直接双击可执行文件先冷静地看一眼目录结构。一个常见的发布包会这样组织bin 目录下放 MediaServer.exe旁边跟着一堆运行期动态库比如 openssl、crypto、x264 相关的 DLLconfig.ini 要么和 exe 同级要么在上一级 conf 目录里。这个 config.ini 是整个服务的中枢启动时没有被正确读取后面所有自定义端口和鉴权可能都不生效。我第一次用这类预编译包时犯过懒直接点开 exe看它窗口里刷了几行日志就以为跑起来了。结果发现监听端口完全是默认值Web 管理页面也打不开最后才意识到当前工作目录不对服务器根本没有读到我要的那份配置。所以要养成一个习惯把整个包解压到一个纯英文、不带空格的路径例如E:\zlm-media\bin在配置齐全的情况下再启动。还有一点需要提前说动态库不要乱删。有些发布包会把 DLL 集中放一个lib子目录有些则完全平铺在 bin 里。如果为了“目录清爽”把 DLL 挪走启动时会直接报“找不到动态库”。这个编译包如果能在原环境跑那么它的依赖基本都已经打全但对应版本依赖的是哪几个具体 DLL你不能只看文件名猜要看 exe 的导入表。Windows 下可以用命令工具查也可以直接看启动报错提示它会告诉你第一个缺失的库是谁。2.2 第一次启动命令、日志级别与默认端口启动命令其实很简单打开一个 cmd 窗口先切换到 bin 目录再运行MediaServer.exe。这样日志会直接打到当前窗口如果启动过程报错你能第一时间看到。建议不要用双击方式启动因为双击启动后日志窗口一闪而过错误信息根本来不及看。cd /d E:\zlm-media\bin start zlm-server MediaServer.exe timeout /t 3 netstat -ano | findstr 554 1935 80命令说明start会让 MediaServer 在独立窗口运行这样你关掉当前 cmd 也不影响它timeout /t 3意思是等待 3 秒给服务留出初始化时间后面的netstat用于检查 RTSP 默认端口 554、RTMP 默认端口 1935、HTTP 默认端口 80 是否已经监听。如果这三个端口都被占用说明服务已经起在默认配置上。日志级别这个问题常见做法是在 config.ini 的[log]或类似段落里设置输出级别。调试阶段建议开到比较低的级别能看到详细链路日志正式环境再调高避免日志刷盘拖累性能。如果你拿到这个包之后日志文件不产生不要慌看控制台窗口输出Windows 下默认日志输出往往和窗口绑定不一定所有包都会自动写文件。2.3 自检服务用 HTTP 接口确认状态和版本进程起来后最有效的验证不是看任务管理器而是访问它的 HTTP 管理端口。在浏览器里打开http://127.0.0.1/如果包没有改过端口默认 80 端口会看到一个控制台页面。有的包因为安全考虑会在首次访问时要求你设置一个 secret也就是管理密钥设置一次后后续 API 请求都需要带上它。如果浏览器不方便直接用一个请求也可以curl http://127.0.0.1/index/api/getServerInfo解释一下这个接口在常见版本里会返回服务器版本号、编译时间、启动时间、使用协议等基本信息。如果返回的是 JSON说明服务正常如果返回401或者一个要求授权的小页面说明包里开启了鉴权需要先把 secret 拼到 URL 后面再试比如?secretmysecret。这个接口也是我判断一个二进制是不是可靠的第一个抓手编译时间是否和包的日期一致版本号和发布信息是否匹配这些信息都能在 getServerInfo 里看到。3. 推拉一路流FFmpeg 推流、三种拉流协议与地址规则3.1 推流前先调三个参数端口、secret、超时时间服务能跑起来只是第一步重要的是确认它能真正承载流。我一般会先在配置里固定三件事HTTP 端口、RTSP/RTMP 端口以及一个足够合理的流空闲超时时间。默认端口在 80、554、1935 上看起来好看但办公网里这三个端口经常被别的服务占用。与其后续排查不如在第一份 config.ini 里就放开。一个最小可用配置片段如下[api] secretyour_secret [http] port8080 [rtsp] port10554 [rtmp] port1935 [rtp_proxy] timeoutSec15说明secret用于保护管理接口建议改成一串只有内部知道的字符串http段里的端口控制 HTTP-FLV、HLS 播放地址rtsp改到 10554 是为了避开 554 端口被占用的问题timeoutSec控制 RTP 代理在没有数据时多久判定超时。这里 15 秒适合测试环境生产环境如果推流端频繁断线重连可以调大到 30 秒。需要注意修改配置以后不是所有段落都热加载的。很多版本里配置只在启动时读取一次所以改完端口要重启 MediaServer 进程否则你以为改了服务还在用旧参数。这一点我后面会在避坑章节再展开因为太多人在这里翻车。3.2 用 FFmpeg 推 RTSP 与 RTMP命令和参数拆解验证服务最直接的方式是推一路本地视频上去。这里我推荐用 FFmpeg它能把一个 mp4 文件转成 RTMP 流或 RTSP 流推给 MediaServer。推 RTMP 流ffmpeg -re -i test.mp4 -vcodec libx264 -preset ultrafast -tune zerolatency -acodec aac -f flv rtmp://127.0.0.1:1935/live/test命令里-re表示按文件的真实时间戳速度读取不加速推送这是推给流媒体服务器的常见要求-preset ultrafast和-tune zerolatency是为了减少转码延迟-f flv指定输出封装格式最后一个地址指向127.0.0.1:1935/live/test其中live/app是常见的应用名test是这个流的流名。如果你要推到远端把 IP 换成目标服务器 IP 即可。推 RTSP 流稍微简单一点ffmpeg -re -i test.mp4 -c copy -f rtsp rtsp://127.0.0.1:10554/live/test这里使用-c copy表示不重新编码直接把源文件的视频音频流复制到 RTSP 封装里。源文件如果是 H.264 AAC这条命令通常没问题如果源文件是 H.265某些版本的老二进制不一定原生支持就要先转成 H.264 再推。为什么要保留-re因为没有它FFmpeg 会把文件以最快速度推出去推流端瞬间结束服务端根本来不及做播放分发甚至你会看到流已经断掉。3.3 用播放器验证RTMP、HTTP-FLV、HLS 三条地址推流成功后验证是否真的能拉出来。常见的三种拉流协议地址格式如下协议地址示例说明RTMPrtmp://127.0.0.1:1935/live/test适合内部工具播放浏览器不直接支持HTTP-FLVhttp://127.0.0.1:8080/live/test.flv适合网页播放器延迟低HLShttp://127.0.0.1:8080/live/test/hls.m3u8适合跨平台播放延迟一般会高几秒用 FFplay 拉流验证是一条命令ffplay -rtsp_transport tcp rtsp://127.0.0.1:10554/live/test ffplay http://127.0.0.1:8080/live/test.flv-rtsp_transport tcp的意思是强制走 TCP 传输 RTSP避免默认 UDP 在某些局域网环境下丢包导致画面花屏。如果这两条命令都能出画面说明推流链路、服务端分发链路都通了。你可能会问为什么明明只推了一条流三种协议都能拉这正是这个服务器的作用它会把推上来的流转换成多个协议出口上层播放器按自己合适的协议请求即可。这一点也是选题“编包版本”时最容易忽略的价值点。3.4 观察在流状态确认服务不是“假活”画面能出来还不够我建议再从管理接口确认一下流的在线状态。调用媒体列表接口curl http://127.0.0.1:8080/index/api/getMediaList?secretyour_secret返回的 JSON 里会列出当前所有的流包括 app、stream、协议类型、在线播放器数量、每一路流的码率等。其中在线播放器数量是一个关键数字如果你拉流成功后数字是 0说明播放器并没有实际连接上只是 FFplay 还在重试如果数字是 1 或更多说明分发是真的在工作。这一步看下来再回到 config.ini 调整也不迟。比如发现流经常断优先看超时时间发现推流很卡优先看是不是转码预设太耗 CPU。整个验证思路是从推流端到服务端再到播放端一段一段排查而不是上来就怀疑二进制坏了。4. Windows 部署避坑启动失败、端口占用、中文路径和配置不生效4.1 进程起来了端口没监听端口占用与配置漂移现象你看到 MediaServer 窗口已经开了日志也不报错但netstat -ano | findstr 554什么也没有控制台页面也打不开。原因有两种常见情况第一种是启动的工作目录不对config.ini 里的端口被另一个配置文件覆盖第二种是 554 或 1935 端口已经被别的进程占用服务器尝试绑定失败后又继续跑。解决方法是分两步走。先查端口占用netstat -ano | findstr 554 tasklist | findstr PIDfindstr PID里的 PID 换成 netstat 结果里最后一列的数字。如果确实被占用可以关掉占用进程或者直接把配置里的端口改掉。再检查当前目录下有没有多个 config.ini确保你改的就是 exe 启动时读取的那一份。我有一个笨办法临时把 config.ini 改名为 config_test.ini然后再启动如果服务启动后日志里明确报告找不到配置文件说明之前的搜索路径是有效且唯一的。4.2 防火墙拦截外部拉流不通但本机正常现象在本机用127.0.0.1推拉流一切正常换到局域网另一台机器访问播放器一直转圈。这种问题在 Windows 上非常典型因为系统防火墙默认会拦截新程序的入站连接。MediaServer 第一次运行时可能弹过防火墙授权框你没点允许或者点错了网络类型后续流量就被挡死。解决的办法不是关防火墙而是给端口单独开放入站规则。管理员权限打开 cmd执行netsh advfirewall firewall add rule namezlm-rtsp dirin actionallow protocolTCP localport10554 netsh advfirewall firewall add rule namezlm-http dirin actionallow protocolTCP localport8080 netsh advfirewall firewall add rule namezlm-rtmp dirin actionallow protocolTCP localport1935这里的每条规则名字都可以自定义dirin指入站方向actionallow允许连接localport是协议对应的端口。如果你改了端口把 localport 一并改掉再执行。执行完以后从另一台机器用telnet ip 8080测一下端口通不通通了再测流播放。4.3 解压目录带中文或空格动态库加载失败现象解压到D:\下载资料\新目录\媒体服务器\bin之后启动窗口一闪而过或者提示“无法加载程序”“应用程序无法正常启动 0xc000007b”。原因不是文件坏了而是部分依赖库在 Windows 下对路径里的中文和空格支持不好exe 在启动阶段加载动态库时失败。解决很简单把整个目录挪到一个纯 ASCII 路径下比如C:\zlm\bin或E:\media\zlm64\bin。要注意工作目录本身也要是 ASCII 路径因为 config.ini 里的日志路径、录制路径如果是相对路径最终拼出来的绝对路径可能仍包含中文。我遇到过一次日志文件里中文路径乱码导致录制任务失败的案例最后全部改成英文路径就好了。这个坑最让人无语的是它在某些 Windows 10 版本上不出现在 Windows Server 版本上就必现。不要以为在你自己机器上测过就万事大吉分发到同事机器时尽量统一英文路径能少很多解释成本。4.4 缺运行库双击后报“找不到 VCRUNTIME140.dll”现象双击 exe 后直接弹窗说缺少VCRUNTIME140.dll或提示“代码 0xc000007b 无法启动”。原因很简单编译这个包用的编译器要求目标机器安装 VC 运行库而你的 Windows 系统是精简版或者没装过对应版本的开发运行库。解决方法是安装 VC 2015-2022 x64 运行库这是 Windows 下的常见系统组件网上很多系统装机工具包也有。装完重启进程再试。另外一个坑是区分 32 位和 64 位如果你的包是 x64 版就一定要装 x64 运行库某些系统默认装了 x86 运行库exe 启动时依然报错所以要核对版本。在这里也给没有经验的人一个建议不要因为缺运行库就怀疑二进制坏了。先装标准运行库再考虑是不是动态库版本冲突很多所谓“打包不完整”的翻车现场最后都发现是目标机器缺通用的 VC 运行库。4.5 改了配置没生效BOM、路径和进程残留现象config.ini 里把 HTTP 端口改成了 8080重启 MediaServer 后访问 80 端口依然能打开页面8080 却连接失败。原因不只是“没重启进程”还有三个隐蔽细节进程没退干净、配置被存成了 UTF-8 BOM、exe 当前目录下根本不是你以为的那份 config。先说第一个Windows 下用start启动的进程关闭窗口不代表进程结束。你要先在任务管理器确认MediaServer.exe没有残留再重新启动。第二个很常见用记事本另存为 UTF-8 可能会带 BOM服务端解析时把第一个配置项读坏导致整段配置被忽略。解决方法是让编辑器保存为“UTF-8 无 BOM”或者用更朴素的文本编辑器。第三个则需要你检查启动脚本或快捷方式的工作目录。我的习惯是写一个启动脚本每次先杀进程再清理旧日志然后启动避免残留问题taskkill /f /im MediaServer.exe nul 21 cd /d E:\zlm-media\bin start MediaServer.exetaskkill /f强制结束旧进程nul 21把找不到进程的报错吞掉避免影响后续命令执行。这个脚本不复杂但能解决我在这个项目上踩过的最多的一类错误。5. 更进一步把编译包变成业务网关API 状态查询与回调鉴权5.1 保护管理端设置 API secret 与只监听内网当服务跑顺了就要考虑安全问题。二进制默认把 HTTP 和流媒体端口全都暴露出来如果机器有公网 IP等于把整个管理端和拉流入口暴露在公网。我第一次用这类预编译包时没改默认 secret结果日志里出现了很多来源不明的请求赶紧改了配置才消停。设置 secret 的方法很简单打开管理页面或者在 config.ini 的[api]段里写入一个非空字符串。重启后所有管理接口都需要带secret参数。除此之外如果服务只给内网用不要监听 0.0.0.0可以把监听 IP 改成内网网卡 IP。端口规划上宁愿把 HTTP 端口换成一个五位数的高位端口也不要盯着 80、443、554 这些容易撞车的默认端口。下面是一个配置参考[api] secret9f8a7b6c5d4e [general] listenIP192.168.1.10secret这里用一串看起来像随机字符串的值实际使用中建议让运维生成一个足够长的随机串listenIP表示只在这个内网地址上提供服务。这样就算有人把 IP 扫到也无法从其他网口访问管理端。要注意 listenIP 改了之后所有客户端都要用这个 IP 访问流服务所以不要随手写一个和网卡不一致的地址。5.2 拿 API 做集成媒体列表、关闭流、服务器信息业务方往往不希望人工看控制台而是希望调用 API 来查流和干预流。预编译包里服务端 API 基本齐全我常用下面几个接口作用常见参数/index/api/getServerInfo获取服务器信息secret/index/api/getMediaList获取所有流的列表secret, app, stream/index/api/close_stream强制关闭指定流secret, vhost, app, stream/index/api/getStatistic获取连接和设备统计secret以关闭流为例你的回调或运营后台拿到一个异常流名以后可以这样请求curl http://127.0.0.1:8080/index/api/close_stream?secret9f8a7b6c5d4evhost__defaultVhost__applivestreamtestforce1为什么要加force1因为默认行为是等播放器全部退出才真正关闭加上 force 会立刻中断这条流。在云上做直播管控时force 参数几乎是必须的。别等到业务被卡的没法处理才发现需要用这个参数。调用 API 的过程中最容易搞错的是返回码。不同版本接口的返回结构不完全一样有的用code有的用result。我建议先手工 curl 一次把返回 JSON 打出来看清字段再写脚本解析。这也正好印证了一句话预编译包不等于黑匣子它暴露的管理维度比许多人想象的多。5.3 推流鉴权回调本地调试 Hook 的最小 Python 实现如果只允许特定推流账号推流光设一个管理 secret 不够。常见做法是启用回调 hook让 MediaServer 在收到推流请求时主动请求你的业务服务由业务服务决定允许还是拒绝。config.ini 里找到[hook]段设置on_publish地址[hook] on_publishhttp://127.0.0.1:8000/hook/on_publish这里用回环测试先让你的 hook 监听本地 8000 端口等业务验证通过再把地址改成内网真实地址。回调调试时我习惯把请求体直接打出来确认字段名然后再加逻辑。这里是一个不依赖第三方框架的最小 Python 实现from http.server import HTTPServer, BaseHTTPRequestHandler import json class HookHandler(BaseHTTPRequestHandler): def do_POST(self): length int(self.headers.get(Content-Length, 0)) data json.loads(self.rfile.read(length)) secret data.get(secret, ) allowed (secret expected-secret) result {code: 0 if allowed else -1, msg: ok if allowed else deny} body json.dumps(result).encode() self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(body) def log_message(self, *args): pass HTTPServer((0.0.0.0, 8000), HookHandler).serve_forever()代码逻辑不复杂服务收到 POST 请求后读取 JSON从字段里取 secret 字段和预期值比较相同则返回 code 0不同则返回 code -1。这里的expected-secret要替换成你真正用于推流鉴权的密码。如果返回 code 0MediaServer 允许流建立如果返回 -1推流端会看到拒绝。需要注意不同版本回调字段可能叫params或直接暴露在顶层调试时先打印data原始值再适配。如果你发现 hook 收到了请求但推流仍然失败大概率是返回值格式不对。检查 code 到底用 0 还是 200 表示成功不同版本习惯不一样。这个项目里我见过太多人把 HTTP 200 当成业务成功最后还是放在 code 字段里拒绝了。6. 一个收尾技巧先看版本和编译时间再决定要不要信任这个包拿到任何预编译包都别立刻上生产先用接口确认它的身份。第一步打开管理接口 getServerInfo看里面的版本号、编译时间和编译选项。如果你标题里看到 2024-05-30但接口返回另一个编译时间那说明这个包可能是被改造过的未必是发布者预期的原始包。第二步用一个合成源视频推流重复执行推拉流操作观察进程内存和 CPU 是否稳定。如果推流 10 分钟以后内存增长到几百兆且不回落到初始值说明这个包可能存在内存泄漏尽量找新版本。这里给一个直接的建议表状态处理方式版本较老只是本地测试直接用预编译包不需要自己折腾工具链版本较老但要用新协议或新 API自己编译一次或寻找更新的发布物包内编译时间和版本无法对应当成未知二进制处理先隔离环境验证需要对接内部鉴权系统优先用 hook 回调做不改二进制我个人的使用习惯是把这个预编译包放在测试服务器上作为参照物同时保留一份自己本地编译的版本。因为预编译包的构建时间固定它适合用来复现某类问题的基线而自己编的版本适合验证新需求。曾经我因为图省事直接拿一份很老的预编译包给前端调试 WebRTC结果协议能力对不上前端排查两三天才发现是服务端问题。那次的教训是预编译包节省的是编译时间不是验证时间。每次拿到新包都先跑一遍版本和时间核对再针对性地做一次推拉验证养成这个习惯后很多离谱的故障都会被挡在部署之前。希望帮到你。本文还有配套的精品资源点击获取
