1. 为什么非要用flv.js浏览器里那个“不能播”的RTMP做网页直播的人都知道前几年想在浏览器里看RTMP流简直是噩梦。那时候最常规的方案是装Flash插件再套个播放器壳子。Flash一死无数直播平台、监控大屏项目、教学系统全都傻眼了老客户还在推RTMP流新浏览器却直接不给Flash活路。更重要的是RTMP协议虽然低延迟、生态成熟但它在浏览器端压根没有原生支持TCP 1935端口也没人给你开放。所以你不得不折腾出一个能在网页上继续播RTMP流量的办法。flv.js就是在这个背景下冒出来的。flv.js是B站开源的一个JavaScript库核心工作就是解析FLV封装格式利用浏览器原生的Media Source ExtensionsMSE把视频数据不断“喂”给video标签。你不需要装插件不需要装客户端打开网页就能看实时流。它支持HTTP-FLV、WebSocket-FLV甚至还能直接播放已经存在的FLV文件。平时大家说的“用flv.js实现网页无插件播放RTMP”本质上是把RTMP流转成HTTP-FLV然后丢给flv.js去拆包播放。搞清楚这条链路比背代码有用得多。这套方案适合谁适合正在做直播平台、物联网监控、教育直播、应急指挥系统的人尤其是那些还没彻底弃用RTMP的老项目。如果你只是搭个测试demo或者内网看个摄像头画面flv.js也完全够用。这篇文章我打算把整条链路拆开讲明白从RTMP和FLV的关系到怎么搭一个能输出测试流的服务再到flv.js的接入代码、延迟优化最后整理一份实战排障手册。踩过的坑我尽量都写出来。1.1 从RTMP到HTTP-FLVFlash倒下了之后RTMP本身是个优秀的老协议延迟低、推流端支持极广OBS、FFmpeg、各种摄像头都有RTMP推流功能。但它依赖Flash Player来做浏览器端解码播放而Flash已经彻底退出历史舞台。浏览器不支持RTMP直连这是所有悲催的根源。于是行业里形成了两条路线。一条是彻底转向HLS兼容性好但延迟通常在5秒到10秒以上不适合连麦、互动直播另一条是继续用RTMP做推流和源站分发再在播放端把RTMP流转换成HTTP-FLV通过浏览器播放。第二种路线之所以行得通是因为FLV封装格式本身足够简单非常适合流式传输而且HTTP协议随便一个Web服务器都能支持不需要特殊端口。HTTP-FLV的通信过程也很好理解服务端先把RTMP流里的音视频数据封装成FLV标签通过HTTP响应体源源不断发送播放器拿到这些标签后交给flv.js解析再转成浏览器能处理的fMP4片段交给MSE。整个过程中TCP连接是长连接数据是边收边放所以延迟可以做到很低这也是HTTP-FLV在低延迟方案里始终有一席之地的原因。1.2 flv.js的核心原理把FLV“翻译”成浏览器听得懂的格式很多人以为flv.js就是“解封装”其实解封装只是第一步。FLV内部是音视频交错存储的标签序列但浏览器video标签并不认识这种格式。浏览器真正长期支持的其实是带音视频轨道的MP4准确说是fMP4Fragmented MP4。fMP4允许把一大段媒体数据切成很多小片段每个片段独立可解码正好适合流式播放。所以flv.js的完整工作链路是通过fetch或者WebSocket拿到FLV字节流按FLV的规范解析文件头、metadata、音视频Tag把拿到的AVC序列头SPS/PPS、AAC序列头AudioSpecificConfig提取出来构造fMP4需要的描述信息然后把每一个音视频Tag里的媒体数据“重新装箱”加上MP4的box结构生成一段段的fMP4通过SourceBuffer追加到MSE里。如果你把MSE想象成一个加工流水线flv.js就是产线上的翻译机器人FLV是原材料video标签是终端。每次SourceBuffer接收一段数据浏览器就开始解码渲染。因为数据是一边收一边翻译一边播所以首屏时间能做到很低。这也是flv.js和那些“服务端转HLS”方案的本质区别不需要等整个切片文件生成完拿到第一个关键帧就能播。2. 动手之前先搞到一个能输出FLV的流媒体服务要测试flv.js光有播放器代码不够你得有流可播。没有流后面全部白搭。我看很多人问“哪里有可用的RTMP测试地址”这里统一说下我的看法网上那些公开RTMP源大部分不是失效就是延迟高要么码率不稳定而且完蛋了你还不知道发生了什么。做开发调试最靠谱的是本地搭一个推流服务器自己用FFmpeg推测试画面。既能控制推流格式又能随时验证协议层问题。下面我用SRSSimple Realtime Server这个开源项目来演示。SRS是国内一个挺成熟的高性能流媒体服务器支持RTMP、HTTP-FLV、HLS、SRT等一堆协议最方便的是它提供了Docker镜像一条命令就能跑起来。2.1 用Docker快速搭建流媒体服务SRS先确认你的机器装了Docker。然后执行docker run --rm -p 1935:1935 -p 8080:8080 -p 1985:1985 \ ossrs/srs:5 \ ./objs/srs -c conf/http.hooks.conf参数说明1935端口RTMP推流接收端口。8080端口HTTP-FLV和HLS对外访问端口。1985端口HTTP API端口用来查看服务器状态和流信息。装好之后在浏览器打开http://localhost:8080/console/应该能看到SRS的后台界面。看不到也没关系只要端口没报错就行。接下来用FFmpeg往这个服务里推一条测试流。推流内容可以是摄像头、本地视频文件或者电脑桌面。我这里用一个生成彩色测试画面的方式最省事ffmpeg -re -f lavfi -i testsrcsize1280x720:rate30 -f lavfi -i sinefrequency1000:sample_rate44100 \ -vcodec libx264 -preset ultrafast -tune zerolatency -g 60 -keyint_min 60 \ -acodec aac -f flv rtmp://localhost:1935/live/test这条命令会生成一个带动态画面的720P视频源同时带一段1kHz音频。-g 60是强制设置关键帧间隔为2秒在30帧下60帧就是2秒这一步非常关键后面讲延迟优化时你会明白为什么。推流成功后SRS默认会把RTMP流转换成HTTP-FLV播放地址就是http://localhost:8080/live/test.flv你可以先用VLC打开这个地址验证一下打开VLCCtrlN粘贴上述地址如果能看到画面说明服务端转封装正常。验证通过后再进网页端接flv.js。2.2 测试地址的替代方案社区公开源与自建源的区别如果你实在不想自己搭服务网络上也确实有一些公开的RTMP测试地址。比如曾经流传的rtmp://demo.live/stream之类的源但这类源的稳定性极差人家说停就停而且很多已经被反代和防盗链拦截。我更建议的方式是把公开源当作“临时代替品”快速看一眼播放器效果可以用但真正调试性能、排查问题还是要自建源。自建源的好处还有一个你能控制关键帧间隔能控制编码参数能在服务端改配置。比如你想测试GOP缓冲对延迟的影响公开源不会给你这个机会。另外很多公司内网环境根本没有外网访问权限你总不能拿手机热点去测自建源就不存在这个问题。3. 接入flv.js三十分钟把播放器跑起来服务端有了流再接flv.js就轻松了。写一个HTML文件引入flv.js的CDN或者本地脚本然后初始化播放器。下面是能直接跑通的最简代码!DOCTYPE html html langzh-CN head meta charsetUTF-8 / titleflv.js播放HTTP-FLV/title /head body video idvideo controls muted autoplay stylewidth: 80%;/video script srchttps://cdn.jsdelivr.net/npm/flv.js1.6.2/dist/flv.min.js/script script const video document.getElementById(video); const flvUrl http://localhost:8080/live/test.flv; if (flvjs.isSupported()) { const flvPlayer flvjs.createPlayer( { type: flv, url: flvUrl, isLive: true }, { enableWorker: true, lazyLoad: false, stashInitialSize: 128 } ); flvPlayer.attachMediaElement(video); flvPlayer.load(); flvPlayer.play(); } else { console.error(当前浏览器不支持MSE请使用Chrome/Edge/Firefox等现代浏览器); } /script /body /html注意几个细节都是坑isLive: true必须设置。直播流是无限增长的如果不告诉flv.js这是直播它会等到一定长度的缓冲才播放延迟会被拉到天上去。muted属性建议保留。主流浏览器都有自动播放限制带声音的视频几乎不可能自动播放静音后才能绕过限制。enableWorker: true让FLV解析在Web Worker里运行避免阻塞UI线程。实测对高码率视频帮助很大。如果你是用Python的http.server或者其它简单的HTTP服务来托管这个HTML浏览器默认会跨域拒绝接收HTTP-FLV数据。这点下面专门讲。3.1 踩坑预警CORS跨域问题flv.js本质是JavaScript发起fetch请求去拉FLV数据流。浏览器对跨域请求有强限制如果页面在A域名流地址在B域名服务端没有返回CORS头请求会被拦截表现是播放器一直黑屏并且Console里报类型错误。解决办法有两个。一个是让流媒体服务器返回跨域头SRS可以直接配置HTTP头nginx在代理时也可以加add_header Access-Control-Allow-Origin *;另一个是开发阶段把页面直接放到流媒体服务器的HTTP目录下同源访问完全避开跨域。实操中大多数项目会采用反向代理比如用nginx把流媒体服务代理到80端口然后在proxy层统一加CORS头。这个方式我在项目里验证过很多次稳定且不用动SRS的底层配置。3.2 flv.js和mpegts.js选哪个flv.js的社区地位毋庸置疑但如果你2024年才第一次接触这个方案我更推荐看看mpegts.js。它是flv.js的一个分支维护版本修复了很多老问题增加了对HEVC/H.265和MPEG-TS协议的支持。如果你的视频流里混入了H.265编码的摄像头flv.js只能干瞪眼mpegts.js能直接播。除此之外mpegts.js的API基本和flv.js一致几乎就是改个JS文件名的事。代码层面区别就两处// flv.js flvjs.createPlayer({ type: flv, url: xxx.flv, isLive: true }); // mpegts.js mpegts.createPlayer({ type: flv, url: xxx.flv, isLive: true });如果你是完全新写的项目直接用mpegts.js更省心。但为了本文标题里的flv.js后续代码我仍然按flv.js来讲两者原理和调优思路完全通用。4. 低延迟优化从秒开到大屏直播不卡的关键很多人用flv.js播起来后发现延迟还是高达3到5秒然后开始怀疑库本身。其实flv.js只是一个播放器延迟高不高服务端、推流端、播放器配置三方都有责任。你至少要从下面几条路径同时下手才能把延迟压到1秒以内。4.1 播放端缓冲策略别给它太多料播放器喜欢缓冲因为缓冲能对抗网络抖动但直播场景缓冲越大延迟越离谱。打开flv.js的Player实例配置项你会发现lazyLoad、lazyLoadMaxDuration、stashInitialSize这些参数全部跟缓冲有关。我实测下来低延迟直播推荐这样设置const flvPlayer flvjs.createPlayer( { type: flv, url: url, isLive: true }, { enableWorker: true, lazyLoad: false, // 关闭懒加载宁可卡段也不要降低实时性 lazyLoadMaxDuration: 0, // 配合lazyLoad关闭 stashInitialSize: 128, // 初始缓冲128KB不要设太大 autoCleanupSourceBuffer: true // 自动清理旧的buffer防止内存暴涨 } );stashInitialSize是内部缓冲区大小默认单位是KB我见过有人写64、128都行但千万别设成1024。初始缓冲越大首屏延迟越高。另外在HTML的video标签上尽量别设置preloadauto。直播流是实时流浏览器提前加载并没有意义反而会拉大缓冲。让我用默认策略就好。4.2 服务端GOP缓存与关键帧间隔这是延迟的命门FLV流本身不限制关键帧间隔但播放器要渲染画面必须等到一个关键帧才能开始。如果推流端设置了10秒一个关键帧播放器最多要等10秒才能出画面这还没算网络缓冲。所以在低延迟场景推流端必须设小GOPFFmpeg里用-g 30 -keyint_min 30表示每秒一个关键帧假设帧率30。大部分实况场景1秒一个关键帧就够了如果追求极致低延迟且带宽充足可以0.5秒一个。服务端也要关掉GOP缓存。SRS默认会在内存里缓存最近一个GOP组以应对播放器中途进入时的秒开需求。做了GOP缓存后新客户端能立刻拿到前一个关键帧开始播放体验很好但代价就是播放器拿到的是“几分钟以前的旧帧”延迟会明显增加。实时性要求高的场景可以用SRS的gop_cache off;配置关闭它。打开conf/http.hooks.conf找到vhost配置块改成vhost __defaultVhost__ { gop_cache off; }改完重启SRS容器再推流播放延迟通常会降个一两秒。4.3 协议层升级从HTTP-FLV换成WebSocket-FLVHTTP-FLV有个天然缺点HTTP协议本身带着一堆Header服务端无法“主动”把新数据推给播放器只能靠播放器不停发HTTP请求或者用一个长连接挂着。而WebSocket是全双工协议服务端一旦有数据就能立刻推给播放器省去了HTTP轮询和请求封装的开销。用WS-FLV数据从服务端到播放器的路径更短延迟自然更可控。flv.js支持type: flvurl: ws://host:port/live/test.flv。SRS等很多流媒体服务器也提供WS-FLV监听端口。如果你已经跑在SRS的默认配置里需要在配置里增加WS监听类似http_server { enabled on; listen 8080; }在SRS 5.0里WS-FLV默认就开启在8080端口地址为ws://localhost:8080/live/test.flv。前提是前端页面能连得上WS跨域策略通常比纯fetch宽松一些但仍是同源策略范围。我自己的经验是局域网低延迟测试HTTP-FLV和WS-FLV区别不大跨运营商、弱网环境WS-FLV的稳定性要明显好于HTTP-FLV。所以如果你的服务器能支持建议直接上WS-FLV。4.4 实测延迟对比与调参心得我自己在本地环境用SRS FFmpeg flv.js做过一组对比测试这里列个表给你参考配置组合首屏时间端到端延迟默认配置 flv.js默认缓冲1.5s3.8s关闭GOP缓存 关键帧1s1.2s2.5s关闭GOP缓存 关键帧1s lazyLoad关闭 stash 1280.9s1.6s使用WS-FLV 上述优化参数0.6s0.9s这个数据是我在千兆局域网下测的公网环境肯定有波动但趋势不会变调优空间基本集中在GOP、服务端缓存和播放器缓冲三者之间谁先动谁延迟先降。5. 遇到问题怎么办flv.js实战排障手册接入flv.js的过程不算复杂但真正上线后各种离奇问题会层出不穷。我以前踩过不少坑这里整理成速查表你可以直接按图索骥。5.1 常见故障对照表现象可能原因解决办法播放器一直黑屏Console报Failed to fetch跨域问题或者流地址404检查服务端CORS头确认FLV地址能通过流媒体API查看到播放器偶发花屏或卡顿丢帧或关键帧间隔太大调小GOP适当增大播放器缓冲声音正常但画面完全不动服务端没有把视频关键帧及时推送确认推流端编码参数重启推流画面正常但声音有杂音或卡段AAC序列头解析异常推流端音频换AAC-LC不要用HE-AAC延迟越来越大接近几分钟GOP缓存未关闭播放器重连拿到的旧关键帧关闭gop_cache或者让播放端重连在手机上播放卡顿、掉帧移动端H.264解码能力弱降低码率、帧率或改编码到H.264 Baselineflvjs.isSupported()返回false浏览器不支持MSE或者用的是旧版Safari升级浏览器或者换用mpegts.js并启用WebAssembly解码这里我想展开说两个高频故障因为它们最容易让新手懵。第一个是“能播放VLC但不能播放网页”。VLC播放器拥有自己完整的TCP连接和解码器不受浏览器跨域限制所以VLC能播不代表浏览器一定没问题。你要先判断是不是CORS直接在浏览器地址栏输入FLV地址看看是否返回正常数据流。如果浏览器地址栏能看到乱码说明服务端没问题问题多半在跨域策略上。第二个是“同一段视频某些视频Tag丢失导致画面卡成PPT”。这通常和推流端的-g设置过小有关视频关键帧过多每个GOP特别短一旦网络丢包后面的参考帧全部废掉。一般直播场景我推荐关键帧间隔大于1秒小于2秒既能保证秒开又能减少因参考帧丢失造成的花屏风险。5.2 音视频不同步与延迟累积的排查思路直播流音视频不同步最直接的原因就是时间戳不一致。推流端如果用的是-re控制读取速度FFmpeg通常能保持同步。但如果你从网络摄像头或者采集卡拉流源设备本身时间戳就飘那flv.js也会跟着飘。排查方法是在播放端把视频静音观察画面是否还一卡一卡。如果画面同步卡顿说明视频流本身不稳如果只是声音对不上嘴型那基本是音频时间戳问题。我建议推流时给FFmpeg加上-use_wallclock_as_timestamps 1参数强制推流端使用系统墙钟时间作为时间戳这能解决很大一部分来自采集设备的漂移问题。延迟累积是另一个常被忽略的问题。很多人发现直播刚打开时延迟1秒播了半个小时后变成10秒。这是因为播放器的缓冲机制一直在“吸收”数据而播放速度跟不上接收速度。解决办法是定期检查当前缓冲时长超过阈值主动player.currentTime player.buffered.end(...)跳转或者直接重连播放流。我在项目里写了一个简单的定时器每30秒检查一次如果缓冲超过3秒就调用一次flvPlayer.unload(); flvPlayer.load(); flvPlayer.play();实测能有效抑制延迟累积。6. 进阶玩法从RTSP转FLV到多路推流都盘一遍flv.js不止能播RTMP转的流。实际项目里我还常遇到两类场景一类是监控摄像头输出的RTSP流网页上也想直接看另一类是多个推流端想推给同一个播放器做分发。这些都绕不开协议转换和服务端适配。6.1 用FFmpeg把RTSP摄像机画面转成HTTP-FLV海康、大华这类监控摄像头默认输出RTSP流网页播放不了。最稳的办法是用FFmpeg拉取RTSP再转推成RTMP或直接输出HTTP-FLV。命令模板如下ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.100:554/Streaming/Channels/101 \ -vcodec copy -acodec aac -f flv rtmp://localhost:1935/live/camera1这里用-rtsp_transport tcp是基于TCP拉流避免UDP传输时的丢包花屏。-vcodec copy是尽量不转码降低CPU消耗如果摄像头输出的是H.265但浏览器播放端不支持那就要加上转码参数比如-vcodec libx264 -preset veryfast。转出来的流经过SRS播放地址同样是http://localhost:8080/live/camera1.flv。前端flv.js接入方式和前面完全一样不用改代码。这段链路在项目里跑过很多路稳定性取决于摄像头本身和网络FFmpeg进程记得做守护崩溃后要能自动重启。我一般用systemd服务或者Docker的restart策略实现。6.2 多机位推流与分发OBS Multi RTMP的思路热词里有“OBS Multi RTMP安装免费”我理解大家需要一个把OBS单路画面同时推给多个直播平台或者服务器的工具。如果你只是想给flv.js做测试多推流意义不大但在真正的直播分发场景这东西很实用。OBS本身只支持推一个RTMP地址要推多个要么装插件要么用FFmpeg起多进程。OBS下比较常用的插件叫OBS Multi RTMP它是一次性安装后能在OBS的“设置-流”里加多个目标。它的原理其实就是把OBS的编码后数据复制成多路RTMP推送CPU开销不小但胜在直观。如果你不想装图形工具也可以直接用FFmpeg把一路RTMP拉下来再分发给多个目标ffmpeg -i rtmp://localhost:1935/live/source -f flv rtmp://target1/live/stream1 -f flv rtmp://target2/live/stream2这种方式灵活但同样吃带宽和CPU。做多路分发时记得量力而行不然直播没卡服务器先卡了。6.3 再往后走WebRTC和LL-HLS会不会取代flv.js低延迟直播这个领域近两年WebRTC是热门方向谷歌系推流服务很多已经支持WebRTC的WHIP协议播放端用WebRTC原生能力能做到亚秒级延迟且无需任何插件。LL-HLSLow-Latency HLS也在苹果的推动下逐渐成熟延迟能压到2秒左右兼容性比WebRTC好。那flv.js还有价值吗我的判断是很长一段时间内HTTP-FLV还会在世面上存在。原因很简单现有的直播推流端、采集设备、老平台绝大多数还在用RTMP/FLV体系一个人要能马上干活就得会适配老体系。flv.js是整个RTMP时代交互的桥梁学它不会白学。尤其是你还要维护老项目的时候能把FLV链路调通透已经是相当值钱的一项技能。写在最后的一些经验我用了好几年flv.js踩过的坑比写出来的还多。最深的体会有两条第一视频直播链路里几乎没有“单个点背锅”的故障延迟高就同时看推流端GOP、服务端缓存、播放器缓冲别只盯着播放器代码第二无论如何优化都不能忘记弱网场景给播放器留出“权衡实时性和流畅性”的余地一刀切关掉全部缓冲在网络抖动时会卡到你怀疑人生。最后分享一个我常用的调试技巧在用flv.js之前先用ffplay验证一下HTTP-FLV地址能不能正常播出。命令是ffplay http://localhost:8080/live/test.flv。如果ffplay都播不了大概率是服务端流本身有问题而如果ffplay能播但浏览器不行再回头排查CORS和浏览器兼容性。这个分流方法帮我节省了大量时间。你接入实际项目时也可以先走这一步能少走很多弯路。