vMix现场直播推流到网页：RTMP转HLS/FLV配置与排障

1. 把链路拆开看vMix 到浏览器之间真正缺的那一环做线下活动导播的人基本都遇到过一个很具体的场景现场用 vMix 切完机位、叠了字幕条、加了画中画返送屏上一切正常主办方转头问一句“能不能放到网页上让外地同事直接在浏览器里打开就看”。这时候你会发现 vMix 本身并不产出“一个网页直播间”它产出的是一路持续变化的音视频数据流。vMix 编辑输出的视频要嵌入网页直播核心动作其实只有一句话把 vMix 编码出来的实时流交给一个能被浏览器识别的传输协议去分发。想明白这句话后面的所有配置都只是填空。这篇内容面向三类人手里已经有 vMix、能正常切画面的现场导播需要把活动现场信号挂到自己网站或活动页面前端工程师以及被临时拉来救火、只要求“明天上午十点能看”的运维同学。不管你是哪一类看完都应该能独立把一条从采集端到浏览器播放器的链路搭起来并且知道每个参数为什么这么填。先说清楚 vMix 在整条链路里究竟站在哪个位置。它在链路里承担的是“采集—切换—合成—编码”这四件事输出的是一个已经压缩好的码流。而浏览器能直接消费的东西非常有限要么是一个.m3u8播放列表HLS要么是一个.flv长连接HTTP-FLV要么是一路 WebRTC 会话。这三样东西 vMix 一个都不直接给所以中间必然存在一个“协议转换 分发”的环节。很多人卡住不是因为不会点 vMix 的按钮而是没意识到这个中间环节必须存在试图在 vMix 里找一个“生成网页”的开关翻遍设置也找不到。我见过最典型的误区是把 vMix 的输出当成“文件”。vMix 确实可以录制录出来是 mp4但录播文件丢到网页上不是直播观众看到的是延迟几分钟的“准直播”互动完全没法做。另一个误区是以为局域网能预览就等于公网能播vMix 较新版本内置了基于浏览器的输出预览能力同一网段用手机打开确实能看到画面但它面向的是现场监看并发能力、鉴权、公网带宽、移动端兼容性全都不在设计目标里直接拿来做对外直播十个人同时打开就会开始转圈。1.1 为什么中间必须有一个“转封装”角色压缩后的音视频数据本身是一串连续的字节问题是不同协议对这串字节的“包装方式”完全不同。RTMP 用的是基于 TCP 的块传输HLS 是把流切成一个个几秒的小文件放在 HTTP 服务器上WebRTC 走的是 UDP 上的 RTP。vMix 最擅长、也最稳定的输出方式是把流推给一个 RTMP 地址这是它内置编码器最成熟的一条路径。而浏览器最擅长的是发 HTTP 请求拿文件或者拿长连接。中间这个角色做的事情学术上叫转封装或转协议通俗点说就是“把自来水厂的管道接进你家水龙头”。它不改变水质不重新编码只是换一种接法。这一层通常由一个流媒体服务承担负责接收推流、切片或转协议、再通过标准 HTTP 提供给前端。理解这一点之后你会发现选型的本质是选“中间这层用什么”而不是选 vMix 怎么设。也因此中间层放在哪儿会直接决定延迟和成本。放在本地一台闲置机器上局域网观看延迟很低但公网观众进不来放在有公网带宽的服务器上任何人能看但带宽账单会很实在交给第三方分发网络省心但需要额外配置回源和鉴权。这三条路我在不同项目里都走过后面会分别讲清楚各自的门槛。1.2 三条主流路线摆在台面上对比真正可落地的方案就那么几种我把它们拆成一张表你按现场条件对号入座就行。路线vMix 侧输出中间层网页端协议典型延迟适用场景A. RTMP 推流 服务端切片Stream 推 RTMP流媒体服务HLS8~25 秒对外公开观看人数多容忍延迟B. RTMP 推流 长连接转发Stream 推 RTMP流媒体服务HTTP-FLV2~5 秒内部培训、需要互动人数中等C. SRT 推流 低延迟切片Output 走 SRT流媒体服务LL-HLS / WebRTC1~3 秒远程连线、需要双向沟通D. 局域网直出内置浏览器输出无HTML51~3 秒现场监看、同网段少量人路线 A 是绝大多数人的第一选择原因很朴素稳、兼容性最好、几乎所有浏览器和手机都认 HLSiOS Safari 甚至原生支持连播放器库都不用引。代价就是延迟HLS 本质是“切片 缓冲”你不可能既要切片又要零延迟。路线 B 是我个人在内部场景里最常用的延迟压到三五秒主持人说一句话弹幕里三秒后就有反应互动感完全不一样缺点是依赖服务端支持 FLV 长连接且部分老旧设备兼容性略差。路线 C 适合那种“必须实时对话”的场景比如远程嘉宾点评。SRT 本身是为不稳定网络设计的传输协议抗丢包能力强vMix 较新版本已经内置 SRT 输出。不过它的配置复杂度明显高一档要处理端口映射、加密口令、以及对端是否支持。路线 D 只适合现场前面已经说过它的问题这里再强调一次局域网能看不等于能对外直播这两件事的技术要求差了一个量级。1.3 延迟、成本、并发这个三角你只能选两条这句话听着像废话但在实际项目里它是最有用的一句。4 Mbps 的 1080p 码流一百个人同时看理论出口带宽就是 400 Mbps这个数字摆在任何一台单机服务器面前都不现实而且这还是不考虑突发和重传的理想值。所以一旦观众规模超过几十人第三方分发基本是绕不开的。反过来如果只是十几个人的内部评审你自己一台带宽 20 Mbps 的小机器跑起来绰绰有余完全没必要上分发网络配置还简单。我在一个小型项目里试过用一台 2 核 4G 的机器承接三十人观看的 720p 流CPU 占用不到 30%跑了一整天没出问题。所以别一上来就堆资源先把观众数量算清楚。延迟这边同理。你要先问清楚业务方“晚十秒能接受吗”多数公开活动答案是能那就老老实实 HLS别折腾低延迟只有明确的互动需求才值得为 WebRTC 或 LL-HLS 付出额外的配置成本和兼容性代价。把这个问题在动手之前问出来能省掉后面一大半返工。2. 输出侧怎么定参数编码器、码率、关键帧一个都不能拍脑袋vMix 里有两个容易混淆的概念我见过不少人在这上面栽跟头Output和Stream。Output 是给外部设备或 NDI 用的那一路你可以在设置里把 Output 1 设成全屏、NDI、SRT 等Stream 才是真正做编码推流的那一路有独立的编码参数。很多人跑去 Output 面板里找推流地址找半天找不到就是因为这两个是分开的模块。实际操作路径是打开 vMix 设置进到输出相关的面板找到 Stream 分页。vMix 支持多路 Stream也就是最多四路同时推每一路可以设不同的分辨率、码率和目标地址。这个能力非常关键后面讲多码率自适应时会用到它能让你在服务端完全不转码的情况下同时提供高清和标清两路省掉大量 CPU。推流目标选 Custom RTMP Server地址填rtmp://live.example.com/liveStream Key 填program这个值要和中间层的应用名对上。填完点开始面板上会显示连接状态、已推时长、当前码率和丢帧计数。这个面板是你排查问题的第一现场推不上去的时候先看它比在后面瞎猜快得多。2.1 分辨率与帧率先问播出终端是什么现场制作很容易陷入“越高越好”的冲动4K 采集、4K 输出结果推流端一压画质还不如老老实实 1080p。原因很简单推流码率是有限的同样的码率下分辨率越高每个像素分到的比特越少压缩痕迹越明显。1080p 用 4 Mbps 和 4K 用 4 Mbps观感差距是非常直观的。我的经验判断是观众主要在手机上看1280×720 就够把码率省下来给稳定性和并发观众在电脑大屏上看1920×1080 起步只有明确要求投大屏或做素材留存才考虑更高分辨率。帧率同理25 或 30 帧覆盖 95% 的场景访谈、讲座、产品演示都够用只有体育赛事、舞蹈、游戏这类快速运动内容才需要 50 或 60 帧而且帧率翻倍意味着码率至少要提高 30% 到 50% 才能维持同等画质。还有一个细节常被忽略vMix 工程本身的帧率要和推流帧率一致。如果采集卡是 60 帧输入工程设 30 帧vMix 会做帧率转换画面里快速横移的物体会出现轻微抖动。这不影响能不能播但影响观感属于“能优化就该优化”的项。2.2 码率不是越大越好算一下上行余量码率的确定有一套很朴素的算法先查经验值再看上行带宽最后取两者较小值再打八折。分辨率帧率视频码率音频码率合计推流上行建议1920×1080304500 kbps128 kbps约 4.7 Mbps≥8 Mbps1920×1080606000 kbps128 kbps约 6.3 Mbps≥10 Mbps1280×720302500 kbps128 kbps约 2.7 Mbps≥5 Mbps854×480301200 kbps96 kbps约 1.4 Mbps≥3 Mbps为什么上行建议要留出接近一倍余量因为推流是持续性的网络不是恒定的。你按 4.7 Mbps 配了一条刚好 5 Mbps 的线路只要中间出现几秒钟的波动vMix 就会开始丢帧观众看到的是画面卡一下、声音断一下。留余量就是给波动留缓冲空间。单路推流之外如果你打算同时推高清和标清两路上行带宽要按两路之和再乘 1.3 来算。比如 1080p 那路 4.7 Mbps 加上 480p 那路 1.4 Mbps加起来 6.1 Mbps建议上行至少 8 Mbps。现场做这个预算的时候千万别拿“测速软件跑出来的峰值”当依据要用持续上传测试的稳定值。2.3 关键帧间隔为什么必须卡在 2 秒这是我踩过最多次坑的一个参数。关键帧I 帧是完整画面播放器从任意位置接入时必须等下一个关键帧才能出画面。HLS 切片是按关键帧切的如果你的关键帧间隔是随机的或者特别长比如 10 秒切片就会变得又大又不均匀观众打开页面要等很久才有画面切换清晰度时也会黑屏好几秒。标准做法是把关键帧间隔固定为 2 秒也就是帧率乘以 230 帧的流设 6025 帧的流设 50。这样 HLS 切 4 秒的片每片正好包含两个关键帧切片边界整齐首帧加载快多码率切换也顺滑。在 vMix 的 Stream 高级设置里能找到关键帧间隔或 GOP 的选项有些版本把它藏在自定义编码参数里需要手动填。如果面板上找不到可以在推流地址后面加参数或者干脆用 vMix 自带的编码预设它默认就是这个值。顺带说一个相邻问题B 帧。B 帧能提高压缩效率但会增加编码延迟而且某些低延迟播放器处理不好。直播场景我一般把 B 帧设成 0 或者最多 2宁可牺牲一点压缩率换稳定。这个参数在 vMix 里通常不暴露走默认即可不用专门去调。2.4 音频参数和音画同步翻车重灾区音频被轻视的程度远超它应得的。视频糊一点观众能忍声音断断续续或者和画面差半秒投诉立刻就来。参数上没什么可纠结的AAC-LC、48 kHz 采样率、立体声、128 kbps。这个组合兼容性最好从老旧安卓机到 iOS 到桌面浏览器全都认。不要用 AC-3浏览器不支持不要用太低的采样率44.1 kHz 在某些采集链路里会引起重采样反而更容易出问题。音画同步的问题通常不出在编码环节而出在采集环节。摄像机通过采集卡进来音频走调音台另一路进来两条链路的延迟天然不同可能差几十毫秒到几百毫秒。vMix 里有音频延迟补偿的设置可以按毫秒调整某一路音频把它对齐到画面。判断方法很直接让现场拍手看画面里手合上的瞬间和听到声音的瞬间是否同步差多少就补多少。还有一个隐蔽的坑如果音频源在 vMix 里被设成了“跟随某个输入”而你中途把这个输入切走了音频可能会跟着断。稳妥做法是把音频单独固定到总输出别让它跟着画面切换乱跑。这个设置在现场彩排时一定要试一次切换别等正式开播才发现。3. 中间层搭建让 vMix 推出来的流变成浏览器能吃的格式这一层是整个链路的技术核心。你要做的事情是接收 RTMP 推流把它转成 HLS 或 HTTP-FLV再通过 HTTP 提供给前端。可选的开源方案不少思路大同小异我这里按“能跑起来”的顺序讲一遍完整配置你照抄改域名就行。服务器准备上最低配一台 2 核 4G、带宽按并发算的机器就能起步。系统装常见的 Linux 发行版开放两个端口1935 给 RTMP 推流用80 或 443 给 HTTP 分发用。如果走 HTTPS现在基本是必须的后面会讲原因记得提前把证书配好因为网页如果是 https加载 http 的流会被浏览器直接拦掉。3.1 协议选择HLS 做底FLV 做体验HLS 的优势是普适几乎所有浏览器、所有手机、所有智能电视都支持而且它基于普通 HTTP 文件请求能直接套 CDN扩容几乎无痛。缺点是延迟标准 HLS 的延迟是“切片时长 × 播放列表长度 播放器缓冲”三片 4 秒加上缓冲十几二十秒很正常。HTTP-FLV 的优势是延迟低它是把 FLV 标签通过 HTTP 长连接持续推给播放器不需要等切片两到五秒就能出画面。缺点是依赖服务端模块支持而且它不是标准协议播放器得用专门的库。另外它在移动端的兼容性不如 HLS部分浏览器对长连接的处理会有问题比如切后台再回来需要重连。我的常规做法是两条都开桌面端优先用 FLV 拿低延迟移动端和兼容性存疑的环境回落到 HLS。这个降级逻辑在前端几行代码就能写完成本很低收益很明显。3.2 一份可以直接抄的配置用常见的开源流媒体服务来搭核心配置大概是这样以 RTMP 模块 HLS 输出为例worker_processes auto; events { worker_connections 1024; } rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # HLS 输出 hls on; hls_path /var/www/hls; hls_fragment 4s; hls_playlist_length 20s; hls_cleanup on; hls_nested on; # 只允许本机或指定来源推流 allow publish 127.0.0.1; allow publish 203.0.113.10; deny publish all; # 允许任意来源拉流 allow play all; } } } http { include mime.types; default_type application/octet-stream; server { listen 443 ssl; server_name live.example.com; ssl_certificate /etc/ssl/fullchain.pem; ssl_certificate_key /etc/ssl/privkey.pem; location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } root /var/www; add_header Cache-Control no-cache; add_header Access-Control-Allow-Origin *; } } }几个地方值得单独说。hls_fragment 4s是切片时长的下限实际切片由关键帧触发所以前面强调的 2 秒 GOP 在这里起作用——关键帧对齐了切片才会整齐。hls_playlist_length 20s决定播放列表里保留几个切片太长会增加延迟太短会让网络差的观众频繁卡顿20 秒是个折中值。add_header Access-Control-Allow-Origin *这行如果你漏了前端页面和流不在同一个域名下就会直接报跨域错误画面永远出不来而控制台报错信息又很含蓄新手极容易卡在这里。allow publish那几行是安全底线。不设限制的话任何人知道你的地址都能往你的服务器上推流把你辛苦搭的分发通道变成别人的免费通道。至少要把推流来源限制成现场固定出口 IP如果现场 IP 不固定就用推流密钥校验的方式多数服务端都支持。3.3 多码率优先在 vMix 侧解决很多人一想到多码率就想到服务端转码其实 vMix 的多路 Stream 才是更省事的路子。你可以在 vMix 里开两路 Stream一路 1080p 4.5 Mbps一路 720p 2.5 Mbps分别推到服务端的两个应用比如live/hd和live/sd服务端只做切片不做转码CPU 占用几乎为零。代价是上行带宽翻倍所以这条路适合现场有专线或者上行充裕的情况。如果上行紧张那就只能在服务端转码但一定要评估 CPU软件转一路 1080p 到 720p在普通云主机上大概吃满一到两个核转两路以上就得考虑用带硬件编码的机型。多码率还需要一个主播放列表把两路流的地址写在一起播放器才能自动切换。手写一个master.m3u8就可以#EXTM3U #EXT-X-VERSION:3 #EXT-X-STREAM-INF:BANDWIDTH4800000,RESOLUTION1920x1080 hd/program.m3u8 #EXT-X-STREAM-INF:BANDWIDTH2700000,RESOLUTION1280x720 sd/program.m3u8BANDWIDTH要填得比实际码率略高一点播放器会根据这个值和当前网速决定切哪一路。填得太保守会导致明明网速够却一直停在低清填得太夸张会在网络波动时频繁切换看得很闹心。3.4 鉴权播放地址不能裸奔公开活动还好内部会议、付费内容就必须控制谁能看。最简单的做法是给播放地址加一个有时效的签名前端请求时带上服务端校验签名和过期时间。签名内容一般包括路径、过期时间戳再加一个只有服务端知道的密钥做哈希。这个逻辑不必自己写多数流媒体服务和反向代理都支持。核心原则是推流密钥绝对不能出现在前端代码里播放地址也不要长期有效。我见过有人把推流地址直接写死在活动页面的 JS 里任何人打开开发者工具就能拿到后果就是被人拿去推别的内容。这种低级错误一旦发生排查起来非常难受因为从服务端看推流是正常的只是内容不对。4. 网页端落地播放器选型与几行关键代码到了前端这一层工作量比想象中小。核心就是选一个播放器库把流地址喂给它再处理几个兼容性细节。4.1 播放器怎么选看你的协议组合播放器支持协议优势局限浏览器原生 video 标签HLSSafari 原生零依赖最轻桌面 Chrome 不认 m3u8hls.jsHLS兼容性最好可调参数多包体积约 200KB 级flv.js / mpegts.jsHTTP-FLV延迟低实现成熟移动端兼容性一般服务端 SDK 播放器WebRTC / LL-HLS延迟最低依赖特定服务端如果是标准的 HLS 方案直接用 hls.js 就够了它会在不原生支持 HLS 的浏览器上做解析在 Safari 上则可以直接交给原生播放。判断逻辑我一般这么写video idplayer controls autoplay muted playsinline stylewidth:100%;max-width:1280px;background:#000/video script src/static/hls.min.js/script script (function () { var video document.getElementById(player); var src https://live.example.com/hls/program.m3u8; if (video.canPlayType(application/vnd.apple.mpegurl)) { // Safari / iOS 原生支持 video.src src; } else if (window.Hls window.Hls.isSupported()) { var hls new window.Hls({ liveDurationInfinity: true, // 直播模式下不按点播算时长 maxBufferLength: 10, // 缓冲上限压低延迟 maxMaxBufferLength: 20, manifestLoadingTimeOut: 8000, manifestLoadingMaxRetry: 4 }); hls.loadSource(src); hls.attachMedia(video); hls.on(window.Hls.Events.ERROR, function (evt, data) { if (data data.fatal) { switch (data.type) { case window.Hls.ErrorTypes.NETWORK_ERROR: hls.startLoad(); // 网络抖动重新拉流 break; case window.Hls.ErrorTypes.MEDIA_ERROR: hls.recoverMediaError(); break; default: hls.destroy(); break; } } }); } else { video.outerHTML p当前浏览器不支持该播放格式请更换浏览器。/p; } })(); /scriptautoplay和muted必须同时出现这不是可选项。现代浏览器普遍禁止带声音的自动播放只写 autoplay 会被静默拦截画面停在第一帧不动用户以为流挂了。加上 muted 之后自动播放就能过再提供一个“点击开启声音”的按钮让用户主动解除静音这是目前最通行的做法。playsinline则是为了防止 iOS 上一播放就强制全屏那个体验在嵌入页里非常糟糕。maxBufferLength这个参数值得单独说。HLS 播放器默认会往前缓冲比较长的时间网络一波动它就想多存点货结果延迟越积越大播了半小时之后延迟可能到一分钟。把这个值压到 10 秒左右延迟能稳定在一个可接受的区间。代价是网络差的时候更容易卡所以要根据实际网络条件微调不要无脑往小里设。4.2 嵌入已有页面iframe 还是直接放 video如果活动页是别人维护的你只负责提供一路流最省事的是给对方一个独立的观看页地址让他用 iframe 嵌进去iframe srchttps://live.example.com/watch/program stylewidth:100%;aspect-ratio:16/9;border:0 allowautoplay; fullscreen; picture-in-picture allowfullscreen /iframeallow这个属性必须写尤其autoplay。默认情况下 iframe 里的自动播放是被禁止的即使里面加了 muted 也不行必须有父页面显式授权。这个坑很隐蔽因为你在自己页面里直接打开是正常的一嵌到别人页面就变成一帧静止画面两边互相甩锅。aspect-ratio也是我强烈建议用的。用固定高度做视频容器的老办法在移动端会变形用 aspect-ratio 让高度跟着宽度走竖屏横屏都不会出问题。如果要兼容很老的浏览器就得用 padding-top 百分比的老套路现在基本不需要了。4.3 一个容易被忽略的点https 页面不能加载 http 流现在活动页基本都是 https而你的流地址如果还是http://浏览器会把它当作混合内容直接拦掉控制台报一个 mixed content 的警告画面永远是黑的。这个问题在新手那里发生频率极高因为本地测试的时候用的是 http 页面一切正常上线换成 https 就挂了。解决办法只有一条给流地址也配上证书走 https。用反向代理把 443 转发到内部的 HTTP 服务即可配置不复杂但一定要在彩排阶段就验证别在开播前十分钟才发现。5. 排障实录从推流到播放的一条检查链直播这行的特点是问题一定会在最不该出现的时候出现所以排查顺序比排查技巧更重要。我一般按“从后往前”或者“从前往后”走一条固定链路不跳步这样最慢五分钟能定位到环节。5.1 固定检查链五步定位法第一步看 vMix 的 Stream 面板状态。是不是绿色的“Streaming”已推时长在增长丢帧计数是不是 0。如果状态是红色的或者一直在重连问题在推流侧地址写错、密钥不对、端口被封、上行带宽不够。这一步能在十秒内排除掉一半的可能性。第二步在服务器上看有没有收到流。查流媒体服务的日志或者直接看切片目录里有没有新的 ts 文件在生成。如果 vMix 显示推流成功但服务器上没文件那多半是应用名对不上rtmp://host/live里的live和配置里的application live必须完全一致多一个斜杠都不行。第三步用播放器直接打开播放地址。拿 VLC 或者浏览器直接访问 m3u8绕开你自己的网页。这一步能区分“流本身有问题”和“网页代码有问题”。VLC 能播而网页不能问题就在前端或者跨域VLC 也播不了问题在服务端或者编码。第四步看浏览器控制台。网络面板里看 m3u8 请求是不是 200ts 请求是不是 403 或 404控制台有没有 CORS 报错。跨域和权限这两类问题在这里一目了然不用猜。第五步看编码参数是否被浏览器接受。如果前面都正常但画面就是黑的检查是不是用了浏览器不支持的编码。H.264 是安全牌H.265 在多数浏览器上直接不支持音频用 AC-3 同理。这种情况在 VLC 上可能能播因为 VLC 解码器全浏览器就未必。5.2 常见问题速查表现象最可能原因处理方式vMix 显示推流中网页黑屏编码为浏览器不支持的格式视频改 H.264音频改 AAC-LC首帧加载特别慢关键帧间隔过长GOP 固定为帧率×2画面花屏、马赛克上行带宽不足或丢包降码率或提升上行查丢帧计数声音正常画面卡视频码率超出网络承载降分辨率优先于降帧率音画不同步采集链路延迟不一致用 vMix 音频延迟补偿对齐移动端不能自动播放缺 muted 或 playsinline两个属性都补上iframe 嵌入后不动父页面未授权 autoplay加 allowautoplayhttps 页面加载不出流地址是 http流也走 https播放半小时后延迟越来越大播放器缓冲无上限限制 maxBufferLength切换清晰度黑屏几秒多码率切片边界不对齐统一 GOP 和切片时长5.3 几条踩出来的经验别在开播前十分钟改参数。这句话听起来像废话但我真的见过有人在开场前把码率从 4M 调到 6M结果上行扛不住前十分钟全是卡顿。所有参数调整必须在彩排时完成正式开播只做“开始推流”这一个动作。提前半小时推流预热。有些分发网络对新建的流有缓存预热过程第一分钟可能拉不到。提前推上去让流先跑一会儿正式开始时观众点开就是秒开。这个习惯养成之后开场事故率能降一大截。准备一路本地录制备份。vMix 在推流的同时可以录制把整场录下来。万一网络中途彻底断了至少还有完整素材可以事后补发。这个成本几乎为零收益极大。观众端的网络差异比你想象的大。你在办公室千兆网络下测得很顺观众可能在地铁上用手机看。所以多码率不是奢侈品是必需品。哪怕只做高清和标清两路体验差距也非常明显。注意 vMix 工程里的音频是否被静音。这个错误低级到不好意思写出来但发生频率真的不低画面切得好好的推流也正常就是没声音最后发现是某一路输入的音频被误关或者总线被静音。彩排时一定要用另一台设备实际听一遍。6. 上线前的压测与一份可执行的检查清单链路搭通不等于能上线。我见过太多“本地测试完美、正式开播崩盘”的案例共同点都是没做压测。压测不需要多专业找几个不同网络环境的人同时打开观看页看十分钟观察三件事开播到出画面的时间、十分钟内卡顿次数、延迟是否在持续增长。这三项都过关基本就稳了。如果条件允许用工具模拟二三十个并发拉流同时观察服务器 CPU、内存、出口带宽和磁盘写入。HLS 的磁盘写入量不小切片一直在生成和清理磁盘 IO 打满会导致切片延迟进而让所有人都卡。这个指标很多人不看出了问题时又很难联想到。我平时用的一份上线检查清单可以直接拿去改推流地址和密钥是否正确是否已限制推流来源 IP视频编码 H.264、音频 AAC-LC 48kHz关键帧间隔 2 秒多码率是否配置主播放列表能否正常解析服务端切片目录权限是否正确磁盘剩余空间是否充足播放页在 https 下能否正常加载跨域头是否配置桌面 Chrome、Safari、iOS、安卓各测一遍iframe 嵌入场景单独测一次自动播放断流后能否自动恢复恢复时间是多久录制是否同时开启录制文件路径是否有空间现场专线的实际上行是不是持续测过不是峰值测速关于断流恢复这个点值得多说一句。现场网络偶尔会瞬断一两秒vMix 会自动重连但服务端那边可能已经把流标记为结束播放列表停更观众端就卡在那里不动了。解决办法是在前端加一个检测如果播放列表超过一定时间没更新就重新加载播放地址。hls.js 里监听错误事件重新 startLoad 就能覆盖大部分情况我上面那段代码里已经写了。这个小逻辑看着不起眼实际能救回不少场次。最后分享一个我个人很受用的小技巧在 vMix 里做一个“信号提示”图层用文字或角标显示当前时间和码流状态把它叠在画面角落。彩排和正式播出时只要看一眼画面就知道流是不是实时的、有没有卡在某一帧。这比盯着后台面板直观得多尤其是在多机位、多屏监看的现场一眼就能发现异常。另一件事是我这两年越来越重视的把整条链路的配置写成文档包括服务器配置、域名、端口、密钥存放位置、每一步的验证方法。现场换人或者半年后再做一场类似的翻出文档半小时就能复现不用重新踩一遍坑。直播这行临时性太强能沉淀下来的东西不多配置文档算一个。