做流媒体开发的朋友应该都体会过这种尴尬代码写完了播放器调通了推流服务也架起来了结果手头连一段像样的测试流都找不到。网上搜出来的地址要么早就失效要么是别人内网里的资源要么压根就是用来钓鱼的假源。我自己入行这几年光是整理测试地址就花了不少功夫踩过无数坑今天就把目前还在用的RTSP、RTMP、M3U8直播流测试地址一次性整理出来顺便把验证方法、本地自建方案和常见的排查手段一起讲透。先说清楚这篇文章能帮你解决什么。如果你在做播放器开发、流媒体服务端、摄像头对接、或者Web端视频播放你需要一段稳定的直播流来做功能验证如果你在搭推流服务你需要一个能接收RTMP的测试端如果你在做视频下载、转码、合并之类的工具你需要一段分片清晰的HLS流。这篇文章给的地址能覆盖这些场景同时我会教你怎么用本地环境造流从根源上摆脱对公共测试源的依赖。1. 搞懂三类测试流的底细才能选对地址在把地址甩出来之前先花点时间把RTSP、RTMP、M3U8这三兄弟的工作原理过一遍。很多人调试直播流半天调不通不是地址有问题而是根本没搞清楚自己拿的是什么协议、这个协议适合干什么。1.1 RTSP摄像头和监控场景的地基RTSP全称Real Time Streaming Protocol直译是实时流传输协议。它本身不负责传输媒体数据而是负责协商和控制——比如发起会话、请求播放、暂停、停止等真正跑音视频数据的是RTP/RTCP。打个比方RTSP像是饭店里的服务员负责点菜和催菜RTP才是后厨真正端上来的菜。RTSP典型的默认端口是554你说 rtsp://192.168.1.64:554/xxx 这种地址就是直接访问摄像头的RTSP服务。市面上的安防设备和方案商基本都支持RTSP取流比如海康威视、大华、宇视这些。大华和海康的RTSP地址格式网上流传很多版本我用了多次比较稳定的通用格式是这样海康威视rtsp://用户名:密码IP:554/Streaming/Channels/101大华rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0其中101里面的第一个1代表通道101代表主码流换成102就是子码流。subtype0是主码流subtype1是子码流。调试的时候建议先用子码流因为码率低、起播快等链路通了再切主码流。1.2 RTMP直播推流的元老级协议RTMP是Adobe当年为了Flash播放器设计的协议基于TCP长连接默认端口1935。它最大的特点是稳定、低延迟而且握手流程是Adobe定的协议格式相对固定所以推流端几乎统一用它。国内早期直播平台基本清一色RTMP直到现在很多企业级直播方案依然保留RTMP推流入口。RTMP协议分推流和拉流两种。推流地址一般长这样rtmp://server-ip:1935/live/streamkey后面的live是应用名streamkey是流名。服务端通过这两个参数区分不同直播间或不同频道。拉流地址就是把推流地址直接用播放器打开只要流在推就能看到画面。用RTMP做测试最大的坑是它的端口容易被防火墙挡。如果你在公司内网测试记得确认1935端口是通的否则播放器会一直卡在连接阶段。1.3 M3U8HLS协议的核心索引文件M3U8不是一种独立协议它是Apple HLSHTTP Live Streaming技术体系里的索引文件。HLS的大致工作流程是服务端把一段视频切成很多个TS分片比如每6秒一片然后生成一个M3U8索引文件里面记录了所有分片的URL和播放顺序。播放器先下载M3U8再按索引逐个加载TS分片播放。M3U8有两种形态。一种是点播VOD索引文件里是所有分片的完整列表可以拖动进度条。另一种是直播LIVE索引文件里是滑动窗口只保留最近若干分片播放器会跟着最新分片一直播下去。由于HLS走的是HTTP协议天然能穿过大多数防火墙而且Apple家的iOS和macOS原生支持所以HLS在OTT、短视频、直播回放场景里是无处不在的。缺点也很明显切片带来的延迟比较高一般都在10秒以上不适合做互动直播。1.4 测试地址选型的核心原则实际测试的时候不要看到地址就往上冲。先想清楚你的测试目标是什么。验证纯播放器功能优先选M3U8因为它走HTTP链路干扰最少。验证摄像头接入直接找海康大华的公开RTSP源。验证推流服务最好用自己的RTMP服务器因为公共RTMP推流地址极少有人开放。另外记住一句话任何公共测试地址都有失效的一天。所以好用的测试方案一定是公共地址优先、本地自建兜底。2. 实测可用的测试地址合集按协议分类整理下面这些地址都是我在开发过程中实际用过的有几个在社区里流传很多年也有近期新增的。我按协议分类列出来每个都会标注适用场景。公共测试源最大的痛点是稳定性所以我会在每个类别后面都补充自建方案这才是真正能长期依赖的路径。2.1 RTSP测试地址优先看这几个RTSP的公共测试源比较稀缺因为安防设备一般都在内网很少有人愿意把摄像头裸奔到公网。目前业界提得比较多的是WOWZA提供的演示流和几个公共演示摄像头。地址来源特点rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4WOWZA演示服务器经典短视频多用于RTSP播放器联调rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mp4WOWZA服务器IP直连和上面同一个服务器IP访问形式rtsp://media1.law.harvard.edu:554/medias/mp4/berkeley_2.mp4哈佛法学院公开课拉流中转质量较高rtsp://admin:123456218.204.223.252:5554/0网络公开摄像头民间分享可用但随时会挂用WOWZA的地址测试时有一个很实用的点它支持seek操作也就是随时往后拖进度条所以适合拿来测试RTSP的点播回放逻辑。如果要测试纯直播模式那个网络摄像头的地址更合适但稳定性就看运气了。这些公网RTSP地址经常遇到一个问题——UDP端口被封。很多播放器默认用UDP拉流如果路由器和防火墙策略比较严格就会一直转圈。遇到这种情况记得在播放器里强制切换TCP模式VLC和FFplay都有相关参数我在后面实操章节细讲。2.2 RTMP测试地址公共可用的极少公共RTMP测试地址是真的难找。原因是RTMP推流端口如果完全开放任何人都能往服务器推垃圾流服务器资源很快被打满所以很少有公共服务器长期开放RTMP推流。目前还能用的基本都是大厂CDN赠送的测试流或者电视台的直播拉流地址。地址来源特点rtmp://liteavapp.qcloud.com/live/liteavdemoplayerstreamid腾讯云测试流CDN稳定适合拉流测试rtmp://ns8.indexforce.com/home/mystream国际公开测试流需外网访问偶尔不稳定rtmp://camlive.iqilu.com/live/streamdelivery1齐鲁网直播流国内电视台源竖屏为主腾讯云的这个测试流地址在国内基本是最靠谱的延迟低还稳定适合做RTMP拉流播放器的调试。齐鲁网那个是地方台的直播流适合测试真实直播场景。不过电视台的流一般有地域和时效性限制而且可能带防盗链你必须带着正确的Referer和User-Agent才能拉通。RTMP的推流测试我建议直接忽略公共服务器自己拿FFmpeg在本地推一个就好方法在下一章展开。2.3 M3U8测试地址种类最丰富M3U8的公共测试源是三个协议里最多的因为HLS走HTTP部署成本低而且Apple官方就提供了一套非常标准的测试流。这里分享几个我常用的地址来源特点https://devstreaming-cdn.apple.com/videos/streaming/examples/img_bipbop_adv_example_hevc/master.m3u8Apple官方多码率自适应含HEVC视频画质高https://cph-p2p-msl.akamaized.net/hls/live/2000341/test/master.m3u8Akamai CDN测试流真正的LIVE流24小时循环https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8Mux测试流多码率自适应适合HLS播放器功能验证https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8Bitdash测试流经典电影片段支持清晰度切换Apple官方的bipbop流是我最推荐的数据链路干净、码率层次分明测试多码率切换逻辑非常好用。而且它主流的M3U8标签都有包括EXT-X-STREAM-INF这种多码率入口以及稍后我讲到的EXT-X-KEY加密分片结构都能在上面验证。Akamai那个是真正的live流24小时循环播放测试直播拉流、断线重连、网络切换等场景再合适不过。Mux提供的版本则有更多音视频轨适合做高级功能验证。2.4 本地自建测试流彻底告别依赖公共地址终究是不可控的我现在的开发流程里本地自建流占据了90%以上的场景。自建方案说白了就是用FFmpeg把本地视频文件推给本地服务器然后从本地服务器拉流测试。当前最推荐的本地服务器是mediamtx原rtsp-simple-server这个项目一是支持RTSP、RTMP、HLS、WebRTC多种协议同时输出二是配置简单下载二进制直接运行。更关键的是它跨平台运行Windows、Linux、macOS都能跑。假设你想搭一个既能拉RTSP又能拉RTMP的测试环境用mediamtx只需要做三件事从GitHub下载对应系统的release包。解压后直接运行可执行文件默认监听8554RTSP和1935RTMP。用FFmpeg把本地视频推上来ffmpeg -re -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/test推完以后你的播放器直接打开rtsp://localhost:8554/test就能看到画面。同样的地址也支持RTMP播放mediamtx会自动做协议转换。如果你不想下载第三方程序还想顺便学习一下RTSP协议内部细节可以用GStreamer的RTSP Server插件。GStreamer的rtsp server库支持Python和C绑定可以写一个小脚本动态生成测试流。一行核心命令gst-rtsp-server -a 0.0.0.0 -p 8554 /video这个方案的好处是你可以精确控制测试流的内容比如用videotestsrc生成彩色测试图案或者同时推一路音频一路视频非常适合做自动化测试环境。2.5 地址可用性自查先用这把瑞士军刀拿到任何地址我都建议先用FFmpeg全家桶里的ffprobe验证一下一行命令就能看出流的基本信息ffprobe -v error -show_entries formatformat_name,duration -show_streams -of defaultnoprint_wrappers1 rtmp://liteavapp.qcloud.com/live/liteavdemoplayerstreamid执行后如果正常返回视频分辨率、编码格式、码率这些信息说明流是可用的。如果返回Connection refused或者404说明地址失效。我用这个命令不知道省了多少时间建议你也养成这个习惯。3. 从拿到地址到跑通全链路一步步操作地址拿到手只是第一步如何在实际开发中把流跑起来才是重点。这一节我会分几条链路来演示播放器侧验证、本地服务器搭建、推流侧操作以及Web播放场景的集成。3.1 播放器侧快速验证FFplay/VLC/PotPlayer三件套验证流是否可用的最快方式是命令行播放器。FFplay是FFmpeg自带的播放器一条命令就能拉流并播放ffplay -fflags nobuffer -analyzeduration 1000000 -rtsp_transport tcp rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4-nobuffer参数是去掉缓冲延迟-analyzeduration是缩短探测时间-rtsp_transport tcp是强制走TCP。这组参数组合能让FFplay在1秒左右出画面非常适合快速判断流是否活着。VLC作为全平台播放器操作更简单。打开媒体-打开网络串流填入URL直接回车。VLC的流信息里能看到很多有用的数据比如当前码率、编码格式、缓冲进度。如果你要测试流是否支持seek回拖VLC左下角的进度条可以直接拖动这在RTSP点播流上非常直观。PotPlayer在国内用户很多它有个额外的坑就是RTSP反复缓冲。我之前调试时遇到播放几秒就转圈排查下来是两个原因一是默认缓冲区设得太大二是解码器对高码率H.265兼容性一般。解决方案是在偏好设置里把网络缓冲调低到500ms左右同时在源过滤器里强制开启TCP模式。3.2 本地RTSP服务器搭建拿手边视频当测试源自行搭建一个测试RTSP服务器是很多开发者的第一道坎。网上流传的方案很多有让你用live555的有让用nginx加插件转的但体验都不太顺。我推荐mediamtx的原因前面说过这里给一个更完整的操作示意。假设你在Linux服务器上操作wget https://github.com/bluenviron/mediamtx/releases/download/v1.8.0/mediamtx_v1.8.0_linux_amd64.tar.gz tar -xzf mediamtx_v1.8.0_linux_amd64.tar.gz ./mediamtx启动后控制台会打印当前监听的端口。默认情况下RTSP是8554RTMP是1935HLS是8888。配置文件mediamtx.yml里可以改端口、开启鉴权、设置录制路径。把本地视频推给mediamtx做测试源可以这样ffmpeg -re -stream_loop -1 -i /path/to/test.mp4 -c copy -f rtsp rtsp://127.0.0.1:8554/loop-stream_loop -1表示无限循环推送这样你的播放器随时打开这个地址都有画面。如果是摄像头设备还可以推摄像头的流过来做中转比如USB摄像头ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -preset veryfast -tune zerolatency -f rtsp rtsp://127.0.0.1:8554/usbcam这条命令在树莓派、RK3588这类开发板上特别常用把USB摄像头的画面转成RTSP流解决嵌入式设备上没有RTSP服务的痛点。3.3 推流端实操用FFmpeg推本地文件或摄像头RTMP推流测试是另一块高频需求。即便没有服务端你也可以用FFmpeg往自己的mediamtx实例推RTMP流ffmpeg -re -i test.mp4 -c:v libx264 -preset fast -b:v 2500k -c:a aac -b:a 128k -f flv rtmp://127.0.0.1:1935/live/test这里的-live/test对应mediamtx中的应用名live和流名test。推流成功后你可以用任意支持RTMP的播放器打开rtmp://127.0.0.1:1935/live/test来验证。如果是推摄像头实时画面把输入源换成设备节点同时加上-tune zerolatency参数来压低延迟ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -preset ultrafast -tune zerolatency -f flv rtmp://127.0.0.1:1935/live/test这里有一个关键参数-re它的意思是按原视频帧率匀速推送。如果不加这个参数FFmpeg会以最快速度一口气把文件推完在服务端表现为视频几秒钟就结束了。3.4 Web端播放M3U8Vue项目里怎么接前端播放M3U8是现在最常见的需求毕竟视频网站和OTT业务的播放链路基本都是HLS。Vue项目里最经典的方案是用video.js加videojs-contrib-hls插件或者直接用一个封装好的vue-video-player组件。npm install video.js videojs-contrib-hls组件里这样用template video refvideoPlayer classvideo-js vjs-default-skin controls/video /template script import videojs from video.js import videojs-contrib-hls export default { mounted() { this.player videojs(this.$refs.videoPlayer, { sources: [{ src: https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8, type: application/x-mpegURL }] }) }, beforeDestroy() { if (this.player) { this.player.dispose() } } } /script需要特别注意一点浏览器直接播放M3U8对跨域要求很严格你的M3U8服务端必须返回Access-Control-Allow-Origin响应头否则播放器会报跨域错误视频根本起不来。自己搭测试服务时记得把CORS配好。还有一个新手常踩的坑打开浏览器的开发者工具在Network面板里看不到m3u8请求。这通常不是代码问题而是视频流在Media Source ExtensionsMSE内部获取不走普通XHR请求流程。所以不要习惯性地认为Network面板里没有m3u8就代表播放器没请求要看Media面板或者使用其他抓包工具判断。3.5 手机端播放M3U8安卓和iOS的差异要摸清手机播放M3U8iOS端最简单因为Safari原生支持HLS直接给video标签塞src就行连插件都不用装。安卓端就比较麻烦系统WebView默认不支持HLS尤其是高版本安卓的Chrome内核必须用hls.js这类JavaScript库来做兼容。安卓端直接用hls.js的方式是import Hls from hls.js if (Hls.isSupported()) { const video document.getElementById(video) const hls new Hls() hls.loadSource(https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8) hls.attachMedia(video) }手机上播放M3U8建议优先选择码率自适应版本的地址比如Apple官方那个bipbop流因为手机网络波动大自适应码率能在卡顿和清晰度之间自动平衡。如果你拿到的M3U8是超清单码率的在4G/5G环境切换时很容易出现缓冲。还有一个操作习惯值得养成手机上如果临时要播放一段m3u8又不想写代码直接用VLC for Mobile或MX Player输入URL就能播放这个用来做真机验证非常方便。4. 常见问题排查与避坑技巧实录做流媒体开发对接到的各种报错一半是地址问题一半是链路细节问题。这一节我把遇到频率最高的问题整理出来直接给排查思路。4.1 M3U8下载或转换失败多数是忽略了分片加密很多朋友喜欢用FFmpeg或者IDM下载M3U8视频经常失败。M3U8本身是个索引文件真正的视频数据在TS分片里。FFmpeg转换命令很简单ffmpeg -i input.m3u8 -c copy output.mp4但这条命令对以下两种情况会失败第一种情况是分片加密。现代M3U8索引里如果有EXT-X-KEY标签说明分片被AES-128加密了直接拼接会得到花屏或者完全没有画面。FFmpeg其实能自动识别密钥并解密前提是密钥URL能正常访问并且服务端不校验Referer。如果防盗链校验了密钥URL你必须手动在M3U8里把密钥URL改成可访问的地址或者用带Referer参数的方式下载。第二种情况是部分分片缺失或404。你可以把M3U8下载到本地用脚本逐行检查TS分片是否存在。这里用aria2c会更方便它能并发下载所有分片aria2c -i ts_urls.txt -x 8 -s 8下载完所有TS分片后用文本编辑器新建一个list.txt按顺序写入每个TS文件再用FFmpeg合并ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4这条命令比直接吃在线M3U8更可靠因为它避开了网络波动带来的单分片下载失败。4.2 Web播放M3U8常见的三个拦截点Web端接入M3U8出问题最多的三个位置是跨域、混合内容、编码格式。跨域前面已经提过服务端必须配CORS。混合内容指的是你页面是HTTPS但M3U8地址是HTTP浏览器会直接拦截。解决办法是CDN上换HTTPS或开启内容安全策略。编码格式这个坑更隐蔽一些老监控流的TS分片是H.264 High Profile加上AC3音频而很多浏览器的视频解码器不支持AC3结果就是画面出来了没有声音或者视频直接黑屏。遇到这种情况用FFmpeg把音频转成AAC或MP3再重新切片ffmpeg -i source.ts -c:v copy -c:a aac output.ts转完后替换M3U8里的分片名就能解决。顺带提醒一下如果你自己用FFmpeg生成M3U8建议分片时长控制在4到10秒之间太短会产生大量请求太长又影响起播速度。4.3 RTSP拉流缓冲和重连问题往往藏在传输层RTSP拉流经常出现的两个现象一是缓冲很久才能出画面二是播放过程中反复缓冲甚至断流。出画面慢大概率是播放器在探测流信息时超时了。FFplay可以用-analyzeduration限制分析时间VLC里可以调低缓存时长。还有一个原因是服务端不支持快进快退请求播放器反复尝试导致起播慢。对这类问题优先把播放器强制切到TCP模式通常能立竿见影。默认UDP模式在跨网段时丢包严重TCP能大幅减少花屏和卡顿。反复缓冲断流则要区分是推流端问题还是拉流端问题。如果是摄像头作为源先确认摄像头是否限制了并发连接数很多中低端摄像头只支持4路或者8路并发超出后新的RTSP会话会被拒绝。如果是自己用FFmpeg推的流要注意源文件码率是否超过网络带宽比如在办公室Wi-Fi下推10Mbps的4K流缓冲就是必然的。还有一个经常被忽略的点是连接超时后的重连机制。标准的RTSP协议支持通过发送RTSP OPTIONS请求来保活会话播放器和拉流端要定期发送否则服务端会认为客户端已断开主动关闭连接。如果你在开发自定义播放器记得实现这个心跳逻辑否则每隔一段时间就会莫名掉线。4.4 关于GStreamer、VLC和本地服务器搭配的经验GStreamer路由器里涉及的RTSP服务器有很多细节尤其是服务端要同时服务多个客户端时需要合理设置超时和并发。GStreamer rtsp server默认支持并发会话但每个session默认不限制带宽如果多个客户端同时拉高码率流可能把服务器带宽打满。建议在媒体配置中设置文件传输的最大比特率并监控服务器日志中的客户端连接数。VLC播放RTSP时还有一个隐藏问题它默认会在流开始时对每个TS分片做二次解析这在某些非标准编码流上会误判导致画面出不来。如果遇到其他播放器都能放只有VLC黑屏的情况可以在首选项里关闭即时播放选项让它等缓冲区充足后再渲染。本地自建服务器时我也建议养成看服务端日志的习惯。mediamtx每个客户端连接、断开、错误都会打日志很多问题一目了然。比如连接被拒要么是端口被占要么是鉴权失败看日志几秒钟就定位了比在播放器端瞎猜快得多。我在实际开发里有一个习惯每次做新项目先把本地自建的测试流环境跑通再用公共测试地址做补充验证。这样既保证开发进度不依赖外部网络也确保最后联调时能跟上公网环境的变化。调试流媒体问题本来就容易让人焦头烂额把最基础的工具链准备好能省下一大半查错的时间。如果哪天发现我列的公共地址失效了别慌用FFmpeg加mediamtx自己造一条就是。
RTSP、RTMP、M3U8直播流测试地址大全与本地自建方案
做流媒体开发的朋友应该都体会过这种尴尬代码写完了播放器调通了推流服务也架起来了结果手头连一段像样的测试流都找不到。网上搜出来的地址要么早就失效要么是别人内网里的资源要么压根就是用来钓鱼的假源。我自己入行这几年光是整理测试地址就花了不少功夫踩过无数坑今天就把目前还在用的RTSP、RTMP、M3U8直播流测试地址一次性整理出来顺便把验证方法、本地自建方案和常见的排查手段一起讲透。先说清楚这篇文章能帮你解决什么。如果你在做播放器开发、流媒体服务端、摄像头对接、或者Web端视频播放你需要一段稳定的直播流来做功能验证如果你在搭推流服务你需要一个能接收RTMP的测试端如果你在做视频下载、转码、合并之类的工具你需要一段分片清晰的HLS流。这篇文章给的地址能覆盖这些场景同时我会教你怎么用本地环境造流从根源上摆脱对公共测试源的依赖。1. 搞懂三类测试流的底细才能选对地址在把地址甩出来之前先花点时间把RTSP、RTMP、M3U8这三兄弟的工作原理过一遍。很多人调试直播流半天调不通不是地址有问题而是根本没搞清楚自己拿的是什么协议、这个协议适合干什么。1.1 RTSP摄像头和监控场景的地基RTSP全称Real Time Streaming Protocol直译是实时流传输协议。它本身不负责传输媒体数据而是负责协商和控制——比如发起会话、请求播放、暂停、停止等真正跑音视频数据的是RTP/RTCP。打个比方RTSP像是饭店里的服务员负责点菜和催菜RTP才是后厨真正端上来的菜。RTSP典型的默认端口是554你说 rtsp://192.168.1.64:554/xxx 这种地址就是直接访问摄像头的RTSP服务。市面上的安防设备和方案商基本都支持RTSP取流比如海康威视、大华、宇视这些。大华和海康的RTSP地址格式网上流传很多版本我用了多次比较稳定的通用格式是这样海康威视rtsp://用户名:密码IP:554/Streaming/Channels/101大华rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0其中101里面的第一个1代表通道101代表主码流换成102就是子码流。subtype0是主码流subtype1是子码流。调试的时候建议先用子码流因为码率低、起播快等链路通了再切主码流。1.2 RTMP直播推流的元老级协议RTMP是Adobe当年为了Flash播放器设计的协议基于TCP长连接默认端口1935。它最大的特点是稳定、低延迟而且握手流程是Adobe定的协议格式相对固定所以推流端几乎统一用它。国内早期直播平台基本清一色RTMP直到现在很多企业级直播方案依然保留RTMP推流入口。RTMP协议分推流和拉流两种。推流地址一般长这样rtmp://server-ip:1935/live/streamkey后面的live是应用名streamkey是流名。服务端通过这两个参数区分不同直播间或不同频道。拉流地址就是把推流地址直接用播放器打开只要流在推就能看到画面。用RTMP做测试最大的坑是它的端口容易被防火墙挡。如果你在公司内网测试记得确认1935端口是通的否则播放器会一直卡在连接阶段。1.3 M3U8HLS协议的核心索引文件M3U8不是一种独立协议它是Apple HLSHTTP Live Streaming技术体系里的索引文件。HLS的大致工作流程是服务端把一段视频切成很多个TS分片比如每6秒一片然后生成一个M3U8索引文件里面记录了所有分片的URL和播放顺序。播放器先下载M3U8再按索引逐个加载TS分片播放。M3U8有两种形态。一种是点播VOD索引文件里是所有分片的完整列表可以拖动进度条。另一种是直播LIVE索引文件里是滑动窗口只保留最近若干分片播放器会跟着最新分片一直播下去。由于HLS走的是HTTP协议天然能穿过大多数防火墙而且Apple家的iOS和macOS原生支持所以HLS在OTT、短视频、直播回放场景里是无处不在的。缺点也很明显切片带来的延迟比较高一般都在10秒以上不适合做互动直播。1.4 测试地址选型的核心原则实际测试的时候不要看到地址就往上冲。先想清楚你的测试目标是什么。验证纯播放器功能优先选M3U8因为它走HTTP链路干扰最少。验证摄像头接入直接找海康大华的公开RTSP源。验证推流服务最好用自己的RTMP服务器因为公共RTMP推流地址极少有人开放。另外记住一句话任何公共测试地址都有失效的一天。所以好用的测试方案一定是公共地址优先、本地自建兜底。2. 实测可用的测试地址合集按协议分类整理下面这些地址都是我在开发过程中实际用过的有几个在社区里流传很多年也有近期新增的。我按协议分类列出来每个都会标注适用场景。公共测试源最大的痛点是稳定性所以我会在每个类别后面都补充自建方案这才是真正能长期依赖的路径。2.1 RTSP测试地址优先看这几个RTSP的公共测试源比较稀缺因为安防设备一般都在内网很少有人愿意把摄像头裸奔到公网。目前业界提得比较多的是WOWZA提供的演示流和几个公共演示摄像头。地址来源特点rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4WOWZA演示服务器经典短视频多用于RTSP播放器联调rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mp4WOWZA服务器IP直连和上面同一个服务器IP访问形式rtsp://media1.law.harvard.edu:554/medias/mp4/berkeley_2.mp4哈佛法学院公开课拉流中转质量较高rtsp://admin:123456218.204.223.252:5554/0网络公开摄像头民间分享可用但随时会挂用WOWZA的地址测试时有一个很实用的点它支持seek操作也就是随时往后拖进度条所以适合拿来测试RTSP的点播回放逻辑。如果要测试纯直播模式那个网络摄像头的地址更合适但稳定性就看运气了。这些公网RTSP地址经常遇到一个问题——UDP端口被封。很多播放器默认用UDP拉流如果路由器和防火墙策略比较严格就会一直转圈。遇到这种情况记得在播放器里强制切换TCP模式VLC和FFplay都有相关参数我在后面实操章节细讲。2.2 RTMP测试地址公共可用的极少公共RTMP测试地址是真的难找。原因是RTMP推流端口如果完全开放任何人都能往服务器推垃圾流服务器资源很快被打满所以很少有公共服务器长期开放RTMP推流。目前还能用的基本都是大厂CDN赠送的测试流或者电视台的直播拉流地址。地址来源特点rtmp://liteavapp.qcloud.com/live/liteavdemoplayerstreamid腾讯云测试流CDN稳定适合拉流测试rtmp://ns8.indexforce.com/home/mystream国际公开测试流需外网访问偶尔不稳定rtmp://camlive.iqilu.com/live/streamdelivery1齐鲁网直播流国内电视台源竖屏为主腾讯云的这个测试流地址在国内基本是最靠谱的延迟低还稳定适合做RTMP拉流播放器的调试。齐鲁网那个是地方台的直播流适合测试真实直播场景。不过电视台的流一般有地域和时效性限制而且可能带防盗链你必须带着正确的Referer和User-Agent才能拉通。RTMP的推流测试我建议直接忽略公共服务器自己拿FFmpeg在本地推一个就好方法在下一章展开。2.3 M3U8测试地址种类最丰富M3U8的公共测试源是三个协议里最多的因为HLS走HTTP部署成本低而且Apple官方就提供了一套非常标准的测试流。这里分享几个我常用的地址来源特点https://devstreaming-cdn.apple.com/videos/streaming/examples/img_bipbop_adv_example_hevc/master.m3u8Apple官方多码率自适应含HEVC视频画质高https://cph-p2p-msl.akamaized.net/hls/live/2000341/test/master.m3u8Akamai CDN测试流真正的LIVE流24小时循环https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8Mux测试流多码率自适应适合HLS播放器功能验证https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8Bitdash测试流经典电影片段支持清晰度切换Apple官方的bipbop流是我最推荐的数据链路干净、码率层次分明测试多码率切换逻辑非常好用。而且它主流的M3U8标签都有包括EXT-X-STREAM-INF这种多码率入口以及稍后我讲到的EXT-X-KEY加密分片结构都能在上面验证。Akamai那个是真正的live流24小时循环播放测试直播拉流、断线重连、网络切换等场景再合适不过。Mux提供的版本则有更多音视频轨适合做高级功能验证。2.4 本地自建测试流彻底告别依赖公共地址终究是不可控的我现在的开发流程里本地自建流占据了90%以上的场景。自建方案说白了就是用FFmpeg把本地视频文件推给本地服务器然后从本地服务器拉流测试。当前最推荐的本地服务器是mediamtx原rtsp-simple-server这个项目一是支持RTSP、RTMP、HLS、WebRTC多种协议同时输出二是配置简单下载二进制直接运行。更关键的是它跨平台运行Windows、Linux、macOS都能跑。假设你想搭一个既能拉RTSP又能拉RTMP的测试环境用mediamtx只需要做三件事从GitHub下载对应系统的release包。解压后直接运行可执行文件默认监听8554RTSP和1935RTMP。用FFmpeg把本地视频推上来ffmpeg -re -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/test推完以后你的播放器直接打开rtsp://localhost:8554/test就能看到画面。同样的地址也支持RTMP播放mediamtx会自动做协议转换。如果你不想下载第三方程序还想顺便学习一下RTSP协议内部细节可以用GStreamer的RTSP Server插件。GStreamer的rtsp server库支持Python和C绑定可以写一个小脚本动态生成测试流。一行核心命令gst-rtsp-server -a 0.0.0.0 -p 8554 /video这个方案的好处是你可以精确控制测试流的内容比如用videotestsrc生成彩色测试图案或者同时推一路音频一路视频非常适合做自动化测试环境。2.5 地址可用性自查先用这把瑞士军刀拿到任何地址我都建议先用FFmpeg全家桶里的ffprobe验证一下一行命令就能看出流的基本信息ffprobe -v error -show_entries formatformat_name,duration -show_streams -of defaultnoprint_wrappers1 rtmp://liteavapp.qcloud.com/live/liteavdemoplayerstreamid执行后如果正常返回视频分辨率、编码格式、码率这些信息说明流是可用的。如果返回Connection refused或者404说明地址失效。我用这个命令不知道省了多少时间建议你也养成这个习惯。3. 从拿到地址到跑通全链路一步步操作地址拿到手只是第一步如何在实际开发中把流跑起来才是重点。这一节我会分几条链路来演示播放器侧验证、本地服务器搭建、推流侧操作以及Web播放场景的集成。3.1 播放器侧快速验证FFplay/VLC/PotPlayer三件套验证流是否可用的最快方式是命令行播放器。FFplay是FFmpeg自带的播放器一条命令就能拉流并播放ffplay -fflags nobuffer -analyzeduration 1000000 -rtsp_transport tcp rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4-nobuffer参数是去掉缓冲延迟-analyzeduration是缩短探测时间-rtsp_transport tcp是强制走TCP。这组参数组合能让FFplay在1秒左右出画面非常适合快速判断流是否活着。VLC作为全平台播放器操作更简单。打开媒体-打开网络串流填入URL直接回车。VLC的流信息里能看到很多有用的数据比如当前码率、编码格式、缓冲进度。如果你要测试流是否支持seek回拖VLC左下角的进度条可以直接拖动这在RTSP点播流上非常直观。PotPlayer在国内用户很多它有个额外的坑就是RTSP反复缓冲。我之前调试时遇到播放几秒就转圈排查下来是两个原因一是默认缓冲区设得太大二是解码器对高码率H.265兼容性一般。解决方案是在偏好设置里把网络缓冲调低到500ms左右同时在源过滤器里强制开启TCP模式。3.2 本地RTSP服务器搭建拿手边视频当测试源自行搭建一个测试RTSP服务器是很多开发者的第一道坎。网上流传的方案很多有让你用live555的有让用nginx加插件转的但体验都不太顺。我推荐mediamtx的原因前面说过这里给一个更完整的操作示意。假设你在Linux服务器上操作wget https://github.com/bluenviron/mediamtx/releases/download/v1.8.0/mediamtx_v1.8.0_linux_amd64.tar.gz tar -xzf mediamtx_v1.8.0_linux_amd64.tar.gz ./mediamtx启动后控制台会打印当前监听的端口。默认情况下RTSP是8554RTMP是1935HLS是8888。配置文件mediamtx.yml里可以改端口、开启鉴权、设置录制路径。把本地视频推给mediamtx做测试源可以这样ffmpeg -re -stream_loop -1 -i /path/to/test.mp4 -c copy -f rtsp rtsp://127.0.0.1:8554/loop-stream_loop -1表示无限循环推送这样你的播放器随时打开这个地址都有画面。如果是摄像头设备还可以推摄像头的流过来做中转比如USB摄像头ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -preset veryfast -tune zerolatency -f rtsp rtsp://127.0.0.1:8554/usbcam这条命令在树莓派、RK3588这类开发板上特别常用把USB摄像头的画面转成RTSP流解决嵌入式设备上没有RTSP服务的痛点。3.3 推流端实操用FFmpeg推本地文件或摄像头RTMP推流测试是另一块高频需求。即便没有服务端你也可以用FFmpeg往自己的mediamtx实例推RTMP流ffmpeg -re -i test.mp4 -c:v libx264 -preset fast -b:v 2500k -c:a aac -b:a 128k -f flv rtmp://127.0.0.1:1935/live/test这里的-live/test对应mediamtx中的应用名live和流名test。推流成功后你可以用任意支持RTMP的播放器打开rtmp://127.0.0.1:1935/live/test来验证。如果是推摄像头实时画面把输入源换成设备节点同时加上-tune zerolatency参数来压低延迟ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -preset ultrafast -tune zerolatency -f flv rtmp://127.0.0.1:1935/live/test这里有一个关键参数-re它的意思是按原视频帧率匀速推送。如果不加这个参数FFmpeg会以最快速度一口气把文件推完在服务端表现为视频几秒钟就结束了。3.4 Web端播放M3U8Vue项目里怎么接前端播放M3U8是现在最常见的需求毕竟视频网站和OTT业务的播放链路基本都是HLS。Vue项目里最经典的方案是用video.js加videojs-contrib-hls插件或者直接用一个封装好的vue-video-player组件。npm install video.js videojs-contrib-hls组件里这样用template video refvideoPlayer classvideo-js vjs-default-skin controls/video /template script import videojs from video.js import videojs-contrib-hls export default { mounted() { this.player videojs(this.$refs.videoPlayer, { sources: [{ src: https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8, type: application/x-mpegURL }] }) }, beforeDestroy() { if (this.player) { this.player.dispose() } } } /script需要特别注意一点浏览器直接播放M3U8对跨域要求很严格你的M3U8服务端必须返回Access-Control-Allow-Origin响应头否则播放器会报跨域错误视频根本起不来。自己搭测试服务时记得把CORS配好。还有一个新手常踩的坑打开浏览器的开发者工具在Network面板里看不到m3u8请求。这通常不是代码问题而是视频流在Media Source ExtensionsMSE内部获取不走普通XHR请求流程。所以不要习惯性地认为Network面板里没有m3u8就代表播放器没请求要看Media面板或者使用其他抓包工具判断。3.5 手机端播放M3U8安卓和iOS的差异要摸清手机播放M3U8iOS端最简单因为Safari原生支持HLS直接给video标签塞src就行连插件都不用装。安卓端就比较麻烦系统WebView默认不支持HLS尤其是高版本安卓的Chrome内核必须用hls.js这类JavaScript库来做兼容。安卓端直接用hls.js的方式是import Hls from hls.js if (Hls.isSupported()) { const video document.getElementById(video) const hls new Hls() hls.loadSource(https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8) hls.attachMedia(video) }手机上播放M3U8建议优先选择码率自适应版本的地址比如Apple官方那个bipbop流因为手机网络波动大自适应码率能在卡顿和清晰度之间自动平衡。如果你拿到的M3U8是超清单码率的在4G/5G环境切换时很容易出现缓冲。还有一个操作习惯值得养成手机上如果临时要播放一段m3u8又不想写代码直接用VLC for Mobile或MX Player输入URL就能播放这个用来做真机验证非常方便。4. 常见问题排查与避坑技巧实录做流媒体开发对接到的各种报错一半是地址问题一半是链路细节问题。这一节我把遇到频率最高的问题整理出来直接给排查思路。4.1 M3U8下载或转换失败多数是忽略了分片加密很多朋友喜欢用FFmpeg或者IDM下载M3U8视频经常失败。M3U8本身是个索引文件真正的视频数据在TS分片里。FFmpeg转换命令很简单ffmpeg -i input.m3u8 -c copy output.mp4但这条命令对以下两种情况会失败第一种情况是分片加密。现代M3U8索引里如果有EXT-X-KEY标签说明分片被AES-128加密了直接拼接会得到花屏或者完全没有画面。FFmpeg其实能自动识别密钥并解密前提是密钥URL能正常访问并且服务端不校验Referer。如果防盗链校验了密钥URL你必须手动在M3U8里把密钥URL改成可访问的地址或者用带Referer参数的方式下载。第二种情况是部分分片缺失或404。你可以把M3U8下载到本地用脚本逐行检查TS分片是否存在。这里用aria2c会更方便它能并发下载所有分片aria2c -i ts_urls.txt -x 8 -s 8下载完所有TS分片后用文本编辑器新建一个list.txt按顺序写入每个TS文件再用FFmpeg合并ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4这条命令比直接吃在线M3U8更可靠因为它避开了网络波动带来的单分片下载失败。4.2 Web播放M3U8常见的三个拦截点Web端接入M3U8出问题最多的三个位置是跨域、混合内容、编码格式。跨域前面已经提过服务端必须配CORS。混合内容指的是你页面是HTTPS但M3U8地址是HTTP浏览器会直接拦截。解决办法是CDN上换HTTPS或开启内容安全策略。编码格式这个坑更隐蔽一些老监控流的TS分片是H.264 High Profile加上AC3音频而很多浏览器的视频解码器不支持AC3结果就是画面出来了没有声音或者视频直接黑屏。遇到这种情况用FFmpeg把音频转成AAC或MP3再重新切片ffmpeg -i source.ts -c:v copy -c:a aac output.ts转完后替换M3U8里的分片名就能解决。顺带提醒一下如果你自己用FFmpeg生成M3U8建议分片时长控制在4到10秒之间太短会产生大量请求太长又影响起播速度。4.3 RTSP拉流缓冲和重连问题往往藏在传输层RTSP拉流经常出现的两个现象一是缓冲很久才能出画面二是播放过程中反复缓冲甚至断流。出画面慢大概率是播放器在探测流信息时超时了。FFplay可以用-analyzeduration限制分析时间VLC里可以调低缓存时长。还有一个原因是服务端不支持快进快退请求播放器反复尝试导致起播慢。对这类问题优先把播放器强制切到TCP模式通常能立竿见影。默认UDP模式在跨网段时丢包严重TCP能大幅减少花屏和卡顿。反复缓冲断流则要区分是推流端问题还是拉流端问题。如果是摄像头作为源先确认摄像头是否限制了并发连接数很多中低端摄像头只支持4路或者8路并发超出后新的RTSP会话会被拒绝。如果是自己用FFmpeg推的流要注意源文件码率是否超过网络带宽比如在办公室Wi-Fi下推10Mbps的4K流缓冲就是必然的。还有一个经常被忽略的点是连接超时后的重连机制。标准的RTSP协议支持通过发送RTSP OPTIONS请求来保活会话播放器和拉流端要定期发送否则服务端会认为客户端已断开主动关闭连接。如果你在开发自定义播放器记得实现这个心跳逻辑否则每隔一段时间就会莫名掉线。4.4 关于GStreamer、VLC和本地服务器搭配的经验GStreamer路由器里涉及的RTSP服务器有很多细节尤其是服务端要同时服务多个客户端时需要合理设置超时和并发。GStreamer rtsp server默认支持并发会话但每个session默认不限制带宽如果多个客户端同时拉高码率流可能把服务器带宽打满。建议在媒体配置中设置文件传输的最大比特率并监控服务器日志中的客户端连接数。VLC播放RTSP时还有一个隐藏问题它默认会在流开始时对每个TS分片做二次解析这在某些非标准编码流上会误判导致画面出不来。如果遇到其他播放器都能放只有VLC黑屏的情况可以在首选项里关闭即时播放选项让它等缓冲区充足后再渲染。本地自建服务器时我也建议养成看服务端日志的习惯。mediamtx每个客户端连接、断开、错误都会打日志很多问题一目了然。比如连接被拒要么是端口被占要么是鉴权失败看日志几秒钟就定位了比在播放器端瞎猜快得多。我在实际开发里有一个习惯每次做新项目先把本地自建的测试流环境跑通再用公共测试地址做补充验证。这样既保证开发进度不依赖外部网络也确保最后联调时能跟上公网环境的变化。调试流媒体问题本来就容易让人焦头烂额把最基础的工具链准备好能省下一大半查错的时间。如果哪天发现我列的公共地址失效了别慌用FFmpeg加mediamtx自己造一条就是。
