简介ZLMediaKit在Windows平台上的免编译发布包面向需要快速部署流媒体服务的开发者与运维人员。该版本已将主程序与运行库打包为可直接运行形态省去源码编译步骤双击exe即可启动适合本地联调、功能验证和小型生产环境试用。压缩包共86个文件包含MediaServer.exe等6个exe主程序、mk_api.dll动态库与配套lib/exp导入库、12个pdb调试符号、9个lib静态库以及config.ini、default.pem、前端控制台html/js/css等运行所需文件整体约133.23MB。已有525人学习下载。借助这套包可快速搭建支持RTMP、HLS、HTTP-FLV等协议的媒体服务通过bom.exe、api_tester_httpclient.exe、test_bench_proxy.exe等自带工具可验证推拉流、转推和代理性能。Debug目录保留了pdb/ilk/map等调试文件便于定位异常和进行二次开发。config.ini可调整端口与日志参数便于灵活适配不同环境。对希望避开编译障碍、专注业务验证的Windows开发者而言这份资源能明显缩短上手路径。 ZLMediaKit 这个项目做流媒体的人基本都绕不开。但说实话很多人在 Windows 上第一次接触它时最大的障碍不是功能不会用而是编译环境搞不定——CMake 版本不对、依赖库缺失、编译器报错一通折腾下来可能一晚上就过去了还没看到那个传说中的 MediaServer.exe 长什么样。我之前也踩过这个坑所以当我发现官方仓库的 Release 页面直接提供了 Windows 预编译版本、解压后双击 exe 就能把流媒体服务跑起来时确实有种“终于等到你”的感觉。这篇就围绕 ZLMediaKit-Windows-Release 这个免编译版本把从下载、配置、启动到推拉流测试的完整过程拆开讲一遍包括你大概率会遇到的几个坑。希望能给准备在 Windows 上快速搭建流媒体服务的朋友省点时间。1. 为什么推荐直接用免编译版本1.1 ZLMediaKit 到底解决了什么问题先简单交代一下背景。ZLMediaKit 是一个基于 C11 开发的高性能流媒体服务框架核心能力是帮你把各种流媒体协议统一起来。它内置了 RTSP、RTMP、HLS、HTTP-FLV、GB28181、WebRTC 等协议的接入和转封装能力这意味着你只需要部署这一个服务就能同时接收不同来源的流再按需输出成不同协议给客户端播放。举个例子你的现场设备推上来的是 RTSP 流但浏览器播放需要 HTTP-FLV手机 App 可能需要 HLS传统方案可能要分别部署转换服务而在 ZLMediaKit 里这些都是默认自带的能力。它内部通过统一的流媒体管道处理数据减少了协议转换的中间环节延迟和资源消耗都控制得比较好。这也是为什么很多安防监控、在线教育、直播平台的项目里都能看到它的身影。1.2 自己编译 vs 直接使用 Release在 Linux 上编译 ZLMediaKit 还算顺利因为官方提供了比较成熟的脚本。但到了 Windows 上情况就复杂了你需要安装 Visual Studio、CMake还需要处理 openssl、libsrtp、ffmpeg 等一系列可选依赖的编译问题。不是说编译不过去而是这个过程对新人不友好容易消磨耐心。而 Windows Release 免编译版本把这个问题直接绕开了。官方已经把 Windows 平台下编译好的二进制文件、运行时依赖库、以及默认配置文件打包到一起你只需要做三件事下载、解压、双击 exe。对于只想验证功能、做二次开发调试、或者快速搭一个测试环境的场景来说这是效率最高的方式。提示免编译版本不等于“绿色免安装”它依然依赖系统里有对应的运行库环境比如较新的 Windows 10/11 系统自带的 Universal C Runtime。绝大多数情况下双击就能跑但偶尔遇到缺 DLL 的问题也不用慌后面我会在常见问题里专门说。2. 下载与启动前的准备工作2.1 获取 Release 包与目录结构解析从项目仓库的 Release 页面找到 Windows 版本压缩包下载即可文件名一般类似ZLMediaKit-Windows-Release-xxx.zip。下载完成后解压到自定义目录比如D:\zlmediakit不建议放带空格的路径里虽然现代版本已经处理了很多路径兼容问题但保持路径干净能省去很多隐形麻烦。解压后你会看到这样的目录结构D:\zlmediakit │ MediaServer.exe # 主程序 │ config.ini # 配置文件 │ README.txt └── www # 静态文件目录HLS切片、网页播放器 └── ...这里面最关键的就是MediaServer.exe和同级的config.ini。程序启动时会读取同目录下的配置文件如果你把 exe 单独拷出去运行会看到它自动生成了一个默认配置但这样会导致很多自定义项失效。所以我的建议是保持整个目录完整不要单独移动 exe所有通过 Release 包解压出来的文件都尽量维持原样。2.2 环境要求与运行前检查免编译版本对系统要求不算高。操作系统建议 Windows 10 1809 以上或 Windows Server 2019 以上64 位系统内存至少 2GB流媒体服务属于 IO 密集型磁盘最好使用 SSD。运行前先确认以下几件事检查.NET相关运行库虽然 ZLMediaKit 本身不依赖 .NET但如果你用它的配套 Web 管理界面或后续要跑一些辅助脚本最好提前装好。没有也不需要专门处理先启动主服务为主。确认端口没有被占用ZLMediaKit 默认会占用 1935RTMP、554RTSP、8080HTTP等端口。你可以在命令行执行netstat -ano | findstr 1935 554 8080快速检查如果有 ESTABLISHED 或 LISTENING 状态就需要看下是不是自己的其他程序占用了这些端口。关闭或放行系统防火墙Windows 防火墙默认会拦截未识别的程序监听端口第一次启动时系统会弹出“是否允许访问”的提示一定要勾选“专用网络”和“公用网络”后点击允许否则本机测试没问题但局域网内其他设备访问会被挡住。3. 核心配置详解与首次启动3.1 config.ini 关键参数说明打开 config.ini你会看到大量配置项。初次使用不需要逐行研究但以下几个参数是必须搞明白的因为它们直接决定你后面的推拉流能否成功。首先是协议端口配置段[rtmp] port1935 [rtsp] port554 [http] port8080默认端口如果你不想用可以改成高位端口比如 HTTP 改成 18080这样可以避免和本机其他服务冲突。改完端口后后续所有访问地址里的端口号都要对应修改。再看两个容易被忽略但很重要的开关[http] rootPath./www [general] enableVhost1rootPath指定了 HLS 切片和静态网页的存放目录默认指向同级的 www 目录。如果你自己写播放页面可以把 HTML 文件丢到这个目录里通过http://服务器IP:8080/你的页面.html直接访问省得再单独部署一个 Nginx。enableVhost表示是否启用虚拟主机。流媒体服务里的 vhost 可以理解为 URL 中的一级路径用于区分不同业务域。比如同一个服务同时服务多个项目每个项目可以用不同的 vhost 做隔离。默认开启新手保持默认即可。3.2 启动 exe 与验证服务配置修改保存后双击MediaServer.exe。如果一切正常你会看到控制台窗口打印出类似这样的日志[2024-xx-xx 10:00:00.123][MediaServer][notice][main.cpp:...] http server listen on 0.0.0.0:8080 rtsp server listen on 0.0.0.0:554 rtmp server listen on 0.0.0.0:1935看到三条 listen 日志说明服务已经正常启动。这时候在浏览器里访问http://127.0.0.1:8080如果配置没问题你应该能看到一个简单的页面里面包含了一些测试入口。新版 Release 还带了一个简易的 Web 播放器页面可以直接用来测试拉流播放这对快速验证环境非常有帮助。注意双击 exe 启动后控制台窗口不要关闭关闭窗口等于停止服务。如果你希望服务在后台运行、不占用桌面窗口可以使用start /b MediaServer.exe命令或者借助 NSSM 这类工具把主程序注册成 Windows 服务。生产环境建议用服务方式运行测试环境无所谓。4. 实操演示搭建一个完整的推拉流链路4.1 用 FFmpeg 向 ZLMediaKit 推流服务跑起来后第一件事当然是把流推进去验证。这里我用 FFmpeg 作为推流工具你可以从 FFmpeg 官网下载 Windows 构建版解压后把bin目录加到系统 PATH 环境变量里。推流命令的基本格式如下ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f flv rtmp://127.0.0.1:1935/live/test这条命令的意思是循环读取本地的test.mp4视频文件以原编码格式直接封装成 FLV 格式推送到本机 ZLMediaKit 的 RTMP 端口应用名是live流 ID 是test。稍微解释下几个参数-re按原视频帧率读取文件模拟实时推流。如果不加这个参数FFmpeg 会以最快速度把文件推完实际效果就是播放器看到的是“快进”后的瞬间结束。-stream_loop -1无限循环读取输入文件这样推流不会因为文件播完而中断。-c copy不重新编码视频音频直接复制编码数据。因为是本机文件编码格式通常兼容性没问题拷贝模式更省 CPU也更能反映服务的转发能力。推送成功后ZLMediaKit 控制台会打印一条新流接入的日志。这时候流已经进入服务内部等待各种协议被拉取。如果你手头有摄像头或采集卡也可以用 FFmpeg 推摄像头实况流命令大概是这样ffmpeg -f dshow -i videoUSB Camera -vcodec libx264 -acodec aac -f flv rtmp://127.0.0.1:1935/live/cameraWindows 下dshow是常用的设备采集方式前提是你的 FFmpeg 编译版本带了 dshow 支持通常官方构建版都自带。4.2 多协议拉流播放测试推流只是第一步ZLMediaKit 的核心价值在于你能用各种协议把同一条流拉出来。这里我把刚才推上去的rtmp://127.0.0.1:1935/live/test分别用不同协议拉流测试。RTSP 拉流使用 VLC 播放器打开rtsp://127.0.0.1:554/live/test正常能出画面。HTTP-FLV 拉流在浏览器或播放器里打开http://127.0.0.1:8080/live/test.flv这是目前直播场景下比较流行的低延迟播放方式。HLS 拉流打开http://127.0.0.1:8080/live/test/hls.m3u8这里稍微注意一下HLS 的访问路径和上面两种不太一样多了一层/hls.m3u8后缀。WebRTC 拉流ZLMediaKit 新版本支持 WebRTC一般通过http://127.0.0.1:8080/index/webrtc.html?urlrtsp://127.0.0.1:554/live/test这样的页面来测试延迟和连通性。同一路流对应四种不同协议你什么都不用做ZLMediaKit 会自动帮你完成转协议分发的动作。这也是它相比那些单一协议的服务最大的优势——一次接入多渠道输出。如果你只想验证服务是否通不想装播放器也可以直接用 FFmpeg 拉流ffmpeg -i http://127.0.0.1:8080/live/test.flv -t 10 -f null -这条命令从 HTTP-FLV 地址拉取 10 秒流数据然后丢弃到空输出如果命令正常执行到结束且没有报错说明拉流链路是通的。4.3 本地回环与局域网访问的区别测试的时候要分清本机回环地址127.0.0.1和局域网地址。127.0.0.1只能用于本机自测如果想让同一局域网里的其他设备访问你的流媒体服务推流和拉流地址都要改成你电脑的局域网 IP。查看局域网 IP 的方法命令行执行ipconfig找到“IPv4 地址”那一项比如192.168.1.100。然后局域网内的播放器就可以用rtsp://192.168.1.100:554/live/test来拉流。这一步如果失败十有八九是防火墙拦截回到前面说的确认启动时弹窗里允许了访问或者在防火墙放行规则里手动加入MediaServer.exe。5. 常见问题与排查技巧实录5.1 双击 exe 闪退或者提示缺 DLL这是免编译版本最常遇到的问题。闪退先别慌右键点击MediaServer.exe选择“以管理员身份运行”有些依赖库初始化需要较高的权限普通权限可能直接退出。如果还是闪退打开命令行在服务目录下直接输入MediaServer.exe运行这样即使崩溃错误信息也停留在命令行窗口里方便判断。如果提示缺少某个 DLL比如libssl-3-x64.dll或libcrypto-3-x64.dll先检查确认这些 DLL 是否在 exe 同目录下。Release 包一般会把运行时依赖都放在一起可能是杀毒软件误删了。用 Windows Defender 的“威胁历史记录”查一下有没有被隔离的文件恢复出来就好。5.2 本机能访问局域网设备访问不了优先排查两件事第一确认监听地址是0.0.0.0而不是127.0.0.1日志里可以看到如果是后者需要检查 config.ini 里是否有配置强制绑定了回环地址第二Windows 防火墙入站规则找到 MediaServer.exe 或对应端口确认是否允许。我自己的排查习惯是先在命令行用telnet 192.168.1.100 1935测试端口连通性如果提示连接失败基本就是防火墙问题直接放行端口再试。如果端口通但拉流失败再往上查应用层配置。5.3 推流成功但播放黑屏或卡顿这种情况大多是编码格式不匹配。ZLMediaKit 对 H.264 AAC 的支持最成熟如果你推的流里视频编码是 H.265部分播放器尤其浏览器内置播放器本身就不支持硬解黑屏就正常了。可以先换成 H.264 试试。另外HLS 播放默认有切片延迟首次播放会有几秒等待这是协议机制决定的不是服务问题。追求低延迟可以优先选择 HTTP-FLV 或 WebRTC 拉流。5.4 常用排查命令速查把几个排查过程中高频使用的命令整理一下遇到问题先跑一遍能解决大部分情况# 查看端口监听状态 netstat -ano | findstr 1935 554 8080 # 查看进程是否在运行 tasklist | findstr MediaServer # 测试本机到服务端的端口连通性 telnet 127.0.0.1 1935 # 测试局域网端口连通性 telnet 192.168.1.100 19356. 个人实操小结把 ZLMediaKit-Windows-Release 跑通的整个过程看下来你会发现免编译版本真正的价值在于缩短了“从想法到验证”的路径。以前在 Windows 上搞定这套环境可能要花大半天现在从下载到看到第一路流画面熟练的话十几分钟就够这对做方案选型、接口调试和快速交付 demo 来说都很实用。我在实际使用中有几个小体会。第一Release 版本虽然免编译但配置文件的注释非常完整建议通读一遍 config.ini你对流媒体服务的很多疑问都能在里面找到答案这是干巴巴看文档学不到的东西。第二尽量保持 exe 和配置文件在同一目录不要为了“整洁”把 exe 单独复制出去否则默认配置会脱离掌控。第三一旦测试通过如果这个服务要长期跑建议用 NSSM 把MediaServer.exe注册成 Windows 服务配合开机自启比每次都手动双击靠谱得多。最后再分享一个小技巧ZLMediaKit 提供了完善的 RESTful API启动服务后你可以通过 HTTP 接口去查询在线流列表、主动关断某路流甚至控制录像。用浏览器访问一下文档里提到的http://127.0.0.1:8080/index/api/getMediaList这类地址就能直观看到 API 返回的数据结构。很多人以为它只是一个简单的转发服务把这套 API 用好之后你会发现它完全可以作为自己业务系统里的流媒体中间件来使用。本文还有配套的精品资源点击获取