这次因为要调试几款播放器需要在本地搭一套能同时出 RTSP、RTMP、HLS 测试流地址的服务。一开始朋友推荐我用开源方案但对比了一圈发现 WOWZA 这类商业流媒体服务器反而更适合“快速出地址”的场景——装上就能用三种协议开箱即出省去一堆相互转换的麻烦。这篇文章就把我整个搭建过程、踩过的坑、以及最后反复确认过的三种协议测试地址整理出来给同样需要在测试环境拉流验证的朋友做个参考。无论你是做播放器开发、客户端测试还是偶尔需要给前端提供一个能播的直播流这套流程都适用。我目标很简单用 WOWZA 搭起服务然后拿着一个真实视频源分别滚出rtsp://、rtmp://、http://...m3u8三种地址让不同端都能直接拉出来看。1. 为什么选 WOWZA三种协议的定位与方案取舍1.1 RTSP、RTMP、HLS 到底有什么不同先把协议底层的适用场景理清楚因为很多人测试时最容易犯的错就是“拿 HLS 的地址去让 RTSP 播放器播”然后一脸懵。RTSP 全称是 Real Time Streaming Protocol基于 TCP/UDP 的实时流控制协议典型应用场景是 IPC 摄像头、安防平台这类低延迟局域网拉流VLC、ffplay、海康/大华 SDK 都能直接消费它RTMP 是当年 Flash 时代的推流霸主现在虽然浏览器不再原生支持了但直播推流侧仍然是事实标准OBS、FFmpeg、各大云直播平台的上行通道基本都是 RTMPHLS 走的是 HTTP 协议服务端把流切成一堆 ts 分片外加 m3u8 索引文件浏览器、iOS 原生播放器不需要装任何插件就能播缺点是延迟天然偏高。延迟从低到高大概是这样RTSP RTMP HLS。所以要给这三个协议各出一路测试流地址并不是同一路流做三次“转码”而是在拉流侧分别走不同的封装和传输通道需要的编码源最好还是统一的。比如用 H.264 AAC 这种普及度最高的组合做原始流RTMP 可以直接复用HLS 也能直接切片分发RTSP 同样不需要二次转码兼容性最好。搞明白这一点后面在 WOWZA 里配置思路就顺了。1.2 WOWZA vs 开源方案适合你的才是最好的在真正定方案之前我在 SRS、ZLMediaKit、GStreamer RTSP Server 这些开源框架之间也转了一圈。SRS 确实很优秀尤其是国内直播场景适配得很好RTMP 推流、HLS 分发一条龙ZLMediaKit 也强一套服务把 RTSP/RTMP/HLS/WebRTC 全包了部署也不复杂GStreamer 则更偏底层适合自己定制链路的人玩。那为什么最后还是选了 WOWZA原因是这次测试场景里我时间紧需要一个“装完就有管理界面、能可视化看到流状态、三个协议地址在一个应用里直接生成”的方案。WOWZA 的管理控制台里能直观看到当前流是否在线、连接了多少人、带宽占用多少这种可观测性对排查测试问题非常友好。另外它的性能兜底能力强虽然是商业软件但一次装好后内部甚至不用怎么调优能扛住的基本都扛住了省下来的时间比它本身授权费用更有价值。当然如果你的生产环境对成本敏感开源方案完全值得优先考虑尤其是 SRS、ZLMediaKit 这类已在工业场景大量验证过的但测试环境追求的是“最短路径拿到可用地址”这正是 WOWZA 的强项。1.3 测试流地址要测什么很多朋友以为测试流地址就是打开 VLC 能播放就完事其实远不止这样。从客户端开发角度来看至少这几类场景是必须覆盖的第一协议兼容性测试同一个地址在不同播放器里能不能播比如同一路 RTSP 地址在 VLC、ffplay、Android 的 MediaPlayer、iOS 的 VLCKit 里行为各不相同如果只在一款播放器里测过就上线肯定出问题第二弱网和延迟表现HLS 的 TS 分片时长设置、RTSP 的 TCP/UDP 模式切换都会直接影响观感第三拉流并发能力一个地址同时被 5 个、20 个客户端拉的时候服务端会不会抖。所以搭建测试流地址时我建议你顺手准备一张表记录这个地址所在的服务器 IP、端口、流名、编码格式、关键延迟参数甚至可以备注下具体这一路流是通过哪种方式推上去的。后面的排查往往就要靠这些记录快速定位问题不然光靠记忆很容易搞混。2. 环境准备与安装配置2.1 服务器配置和端口规划WOWZA 对硬件要求并不激进2 核 4G 内存的小机器跑纯测试完全足够如果后面要压测并发至少准备 4 核 8G带宽上云服务器要留意入网带宽因为推流上行和拉流下行都会挤占它。我这台用的是一台 CentOS 7.9 的云主机4 核 8G、带宽 5Mbps做单路源流外加七八个客户端同时拉流完全够用。端口规划这一步千万别偷懒。先确定几个位置1935 是 RTMP 和 RTSP 共用的默认端口8080 是 WOWZA 管理控制台和 HTTP 播放HLS默认端口554 是 RTSP 的标准端口但 WOWZA 默认并不启用需要在配置里手动绑定。如果你有多个服务器尤其要注意 1935 别被其他程序占用。我习惯单独创建一个放流媒体服务的用户而不是直接用 root 跑这样后面开防火墙规则也更安全。还需要注意云服务器除了要开操作系统里的防火墙策略还要检查控制台安全组入网规则很多新手在这栽过——内部防火墙全放通了但安全组没放行 1935VLC 一直连不上。我通常给安全组开 1935、8080、554 三个端口源地址按需限制测试环境图省事也会暂时改成/0。2.2 WOWZA 安装与许可证激活WOWZA 的安装在老手看来没什么但初次接触的人会被它的许可证机制绕一下。它采用的不是传统串码注册而是基于机器指纹和许可文件的方式。从官网下载对应 Linux 版本的安装包后解压到目录执行安装脚本即可。安装完成后访问http://服务器IP:8080会进入管理初始化页面在这里设置管理员密码然后会要求你导入由 WOWZA 官方下发的 License 文件。没有 License 的话服务基本处于不可用状态。你可以去官网注册一个试用的 License 放入系统这样整台服务器就能正常跑起来了。需要注意的是 License 文件是绑定服务器硬件信息的不同机器之间不能直接混用。我第一次就踩了这个坑把测试机的 License 复制到另一台新机器上结果服务起来后一直报 license 无效重新申请一份才解决。安装过程中还会让你选择安装目录我用的默认路径/usr/local/WowzaStreamingEngine。这是后续所有配置文件、应用目录、日志文件的根位置建议记在心里。整个安装过程大概两三分钟中间如果有 OpenSSL 相关警告不用太慌只要最终提示安装成功就行。2.3 管理后台初始配置进后台第一件事我建议检查“Server Status”里的各项指标确认端口监听正常。然后在 Server → Ports 里把 RTSP 的端口配置确认一下如果你希望别人用标准的rtsp://ip:554/...访问就在这加开一个 554 端口监听。不配也没关系默认的 1935 同样能拉起 RTSP 流只是地址里要带上端口号。后台里还有一个容易忽略的地方是“Media Cache”和“HTTP Streaming”相关参数。HLS 切片的 chunk duration 默认可能偏大这会导致生成的 m3u8 索引更新慢、播放器起播延迟明显。测试环境可以把 chunk duration 调短比如 2 秒到 4 秒之间对起播速度和调试体验都有改善。这里要特别说明这些参数调整以后需要重启流引擎才会生效别在控制台里改了参数然后说“怎么没变化”。初始配置阶段我还会顺手改一处把管理控制台的端口从默认 8080 改成一个不常用的高位端口避免它和后续 HLS 的 HTTP 承载端口冲突也减少被扫描的暴露面。改完以后访问后台的地址就变成http://ip:新端口/一路测试下来这个操作能少很多麻烦事。3. 创建直播源并获得三种协议地址3.1 创建 Live 应用与推流入口WOWZA 里的核心概念是 Application你可以把它理解成一个直播“频道组”。安装完成后默认会有live这个应用但我建议大家自己新建一个应用比如testlive这样可以避免动默认配置。在控制台 Applications → Add Application 里选择 Live Streaming 类型创建一个名为testlive的应用创建成功后它会自动生成几个为直播服务的 stream files。在这个应用下推流入口就是rtmp://你的IP:1935/testlive你只需要在斜杠后面接一个流名就能产生一路流。比如使用 FFmpeg 推流ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f flv rtmp://你的IP:1935/testlive/stream001这里stream001就是流名。一旦这路流推上来WOWZA 管理控制台的 Incoming Streams 列表里立刻就能看到它的状态这一点对排查“流到底有没有推上来”非常实用。新创建的应用默认参数可能不太适合 HLS所以最好去应用配置的 HTTPStreamer 里确认一下httplive这个 packetizer 是否启用。常见的坑是只开了 RTMP但忘记启用 HLS 相关配置导致 m3u8 根本访问不到。确认启用后同一路 RTMP 流在 WOWZA 内部会自动被封装成 HLS不再需要你再做任何转推操作。3.2 生成测试视频并推送 RTMP 流没有现成视频文件的话用 FFmpeg 直接生成一个测试视频是很省事的。我经常用下面这条命令生成一个带彩条和正弦音的视频时长 30 秒循环推送时不会因为文件结束而断流ffmpeg -f lavfi -i testsrcsize1280x720:rate30 -f lavfi -i sinefrequency440:sample_rate44100 -t 30 -c:v libx264 -preset veryfast -c:a aac test.mp4生成好之后推流命令再像上面那样写。注意-stream_loop -1要放在-i之前这样 FFmpeg 会循环读取文件实现无限循环直播的效果。如果不加这个参数视频放完 30 秒后推流就断了WOWZA 后台的流状态会变成 disconnectedVLC 拉到一半也会黑屏。如果是摄像头这类实际设备推流命令又会不一样比如 Linux 下用 v4l2 采集摄像头画面推 RTMP。但测试流地址这件事重点不在源头的花哨程度而在于“稳定”所以我反而建议用文件循环推送作为测试源这样不会因为设备断连导致测试中断。3.3 三种协议地址生成规则这一步是整个文章的核心。假设我已经把名为stream001的流推到了testlive应用下那么 WOWZA 会自动把它发布在几个协议端口上地址规则如下协议地址格式端口典型用途RTSPrtsp://IP:1935/testlive/stream0011935 或 554VLC、ffplay、SDK 拉流RTMPrtmp://IP:1935/testlive/stream0011935FFmpeg、OBS 推流后拉流HLShttp://IP:8080/testlive/stream001/playlist.m3u88080浏览器、iOS/Android 播放器这三个地址表面上看只是前缀和路径不同本质上对应了 WOWZA 对同一路输入流并存的三种输出封装。RTMP 和 RTSP 在 WOWZA 里直接建立在同一个媒体流上HLS 则是从它内部 slicing 出 ts 分片再发布。也就是说你不需要给三个协议分别推三路流只要推一路 RTMP其它两个地址自然就能访问到。如果你配置了 554 端口的 RTSP 监听那么 RTSP 地址可以简写成rtsp://IP:554/testlive/stream001。无论哪种格式拿到的这些地址都可以作为公开测试流地址发给其他同事或集成方。我自己每次都会把它们完整记录在文档里方便后续直接复制到 VLC 或测试代码中。3.4 验证播放VLC、浏览器、ffprobe拿到地址以后别急着发出去先自己把三个地址都验一遍。Windows/Mac 上最方便的是 VLC打开网络串流后分别粘贴三个地址能正常出画面和声音就算通过。HLS 地址在 VLC 里也能播但浏览器里的播放行为才是重点测试项之一因为很多前端播放器是拿 HLS 地址配合 hls.js 来播的所以我会在 Chrome 里打开http://IP:8080/testlive/stream001/playlist.m3u8确认 m3u8 索引能正常返回再用 hls.js 的官方 demo 页面去验证实际播放。命令行层面我用得最多的验证工具是ffprobe。比如ffprobe rtsp://IP:1935/testlive/stream001如果输出里能看到 Stream #0:0 Video: h264 这类信息说明这一路流在协议层面是通的且编码信息符合预期。这比打开 VLC 拉流更快适合脚本化巡检。遇到问题的时候ffprobe报错信息也能帮你快速定位是协议问题、编码问题还是网络问题。我会把验证环境搞成一条固定脚本先 ffprobe 三个地址拿到编码信息再批量用 VLC 打开三个地址人工看画面。全部通过后再把这个地址表发给测试同事。4. 常见问题与排查技巧实录4.1 端口不通这种事往往是安全组在坑你这类问题在测试过程中最多发症状是 VLC 一直显示“无法连接”或者 ffprobe 卡住不动。我先说结论操作系统防火墙和云安全组必须同时检查别以为 Services 在跑就万事大吉。我那次就是 CentOS 的 firewalld 已经放行了 1935但忘了在云控制台安全组入方向放行对应端口结果内网机器能拉流公网机器怎么都连不上白白浪费了半个小时。排查命令netstat -lnpt | grep 1935如果能看到java进程监听在 1935说明 WOWZA 这边已经就绪接下来就测端口连通性telnet IP 1935在云服务器上安全组和系统防火墙都放行后telnet 应该立即显示 Connected。这一步如果还失败就要检查是不是云厂商安全组规则没有生效或者运营商层面屏蔽了非标准端口。4.2 流明明在推为什么拉不出来管理控制台里看到 Incoming Streams 已经显示stream001在线但客户端拉 RTSP 却黑屏或卡住。这类问题通常会出现在编码格式上。WOWZA 对视频编码有严格限制H.264 和 H.265 是完全可以的但如果推流时包含了非常规的 B 帧结构、超高 profile或者音频用了非 AAC 的格式某些协议下就会被播放器拒绝。我的经验是测试源尽量使用libx264 -preset veryfast -tune zerolatency参数来压制音频保持 AAC。在推流命令层面尽量采用-c copy直接复用原始编码不要轻易做转码因为 WOWZA 默认环境里有些编解码器的转码授权没有启用触发转码链路反而容易出问题。如果还是拉不出来就去 WOWZA 的日志目录下翻wowza.log和access.log搜索流名stream001能看到它到底在哪个环节抛了异常或者是否有客户端确实建立了连接后再断开。日志时间精确到毫秒配合前后请求记录非常有用。4.3 HLS 延迟高或者起播慢很多同事反映 HLS 地址能播但延迟肉眼可见高。这很正常HLS 天然就有这个短板但在测试环境里可以通过调整相关参数改善。WOWZA 的 HLS 切片时长默认可能是 10 秒甚至更长客户端要么等第一个分片下完才开始播起播速度自然慢。把分片时长调成 2 秒到 4 秒并且在播放器里启用低延迟模式体验会明显提升。调整的位置在应用的 HTTPStreamer 配置里根据你装的 WOWZA 版本差异可能叫ChunkDurationTarget或TargetChunkDuration。不过这属于“优化类”操作测试时如果不追求低延迟可以不折腾明白改动在哪里就好。注意改配置后要重启 Stream Engine否则不会生效。4.4 并发拉流测试的几个提醒测试流地址给出去之后通常会有好几个人同时拉流这种情况下要注意几点。第一WOWZA 默认连接数限制比较低尤其是试用 License 可能会有并发限制如果多人同时拉流发现服务开始拒绝连接首先怀疑并发放到上限。第二压测时不要直接把一个地址丢给几百人同时拉WOWZA 扛不扛得住暂且不说生产环境网络带宽大概率先打满拖垮整台服务器连管理页面都进不去。我习惯把测试分成两个阶段先小范围 5 到 10 个客户端同时验证功能确认没问题后再加大并发。如果要测大并发最好单独拉一台机器或者给 WOWZA 所在服务器留足带宽余量。压测过程中我会持续关注两个指标一是管理控制台的 Connections 数二是服务器的带宽占用一旦带宽接近峰值就要赶紧叫停别等到服务完全卡死才处理。写在最后的几点经验搭建 WOWZA 测试流地址这件事做一次就会发现其实没有想象中复杂真正的价值在于把三种协议的关系、地址生成规则和常见问题串起来少走无谓的弯路。我在实际操作中有几个体会一是源流永远保持简单H.264 AAC 是最大公约数能规避绝大多数播放器兼容问题二是把端口规划当成正式配置来做安全组、系统防火墙、WOWZA 监听端口三处一一对应就不会出现“本地能拉、公网拉不了”的尴尬三是所有生成的地址一定要做记录一次搭建能产出 N 个地址不记下来后面就会陷入“这个流是哪台机器的”这种迷茫里。如果你已经能拿到稳定的 RTSP、RTMP、HLS 测试流地址接下来可以在这个基础上玩更多东西比如给 WOWZA 配置 HTTPS 播放、做多码率自适应转码或者接入自己的鉴权体系。这套基础环境搭好后后面扩展起来会顺很多。