1. 这些流媒体测试地址到底有什么用为什么大家都在找做流媒体开发、安防监控对接、直播推拉流调试的朋友应该都有过这种经历手头临时要验证一个播放器、测一下转码链路、调一下延迟参数结果手边没有一个稳定的流地址可用。自己想搭个RTSP服务又不愿意花时间拿本地摄像头推流又牵扯设备权限和环境依赖搞得本来十分钟能搞定的事折腾了一下午。我之前在调试一个H5播放器的时候就因为在网上搜不到一个能用的公网测试流反复换了五六个网页上的老旧地址不是超时就是404最后没办法自己去服务器上开了一个RTSP转发服务才把问题定位完。后来我把能找到的、实测可用的地址整理成了一份清单包含RTSP、RTMP、M3U8、FLV、MP4这些常见格式不同用途对应不同协议互相之间不能乱用。这篇文章就把这个清单和背后的原理、常见坑一起讲清楚。适合谁的场景做播放器联调的前端、做直播链路测试的后端、搞安防摄像头RTSP取流的集成工程师、还有刚入门想理解这些协议区别的学习者。每一类地址都有它的适用边界弄清楚了下一次联调就不用在网上瞎翻了。2. 先搞明白这五种格式到底是什么才不会用错地址很多人把RTSP、RTMP、M3U8当成一种“文件格式”其实它们本质上是完全不同的东西。拿生活里的比喻来说MP4和FLV是“盒子里的实物”M3U8是一张“藏宝图”而RTSP和RTMP是“传送带”一个是用来传输的通道一个是用来描述的清单。搞混了协议和封装格式的边界就很容易在选测试地址时做出错误判断。2.1 RTSP八成安防摄像头都在说这个“门牌号”RTSPReal Time Streaming Protocol是一个网络控制协议它不负责把视频数据包一股脑地丢给你而是先建立会话、协商参数、再命令服务器开始播放。你可以把它理解为去餐厅吃饭菜单是SDP描述点菜是SETUP请求服务员端菜上来才是RTP数据流。RTSP本身不传输媒体数据实际传输靠的是RTP/RTCP协议。安防摄像头比如海康威视、大华这些设备基本都内置RTSP服务默认取流地址格式长这样rtsp://用户名:密码IP地址:端口/Streaming/Channels/101不同的品牌路径规则不一样。海康是/Streaming/Channels/101大华通常是/cam/realmonitor?channel1subtype0。所以网上那些测试用的RTSP地址大多是公共演示摄像头剩下的因为直接拿别人设备地址来测试涉及隐私和安全问题没法长期保证可用。适合用RTSP地址测试的场景验证VLC、PotPlayer、FFmpeg的拉流能力测试安防平台的国标接入或者验证自己写的RTSP客户端解析逻辑。2.2 RTMP直播时代的老将延迟低但浏览器不接RTMPReal-Time Messaging Protocol是Adobe当年为Flash播放器设计的推拉流协议。它基于TCP长连接还自带分块、消息优先级、AMF格式的命令交互机制用起来非常“重”但胜在实时性好、延迟能做到一两秒以内。现在很多直播软件推流到CDN用的还是RTMP up因为它在公网传输上足够稳定而且在服务器端成熟方案多。但是注意浏览器原生不支持RTMPH5播放器也没法用这种协议。所以如果你在前端页面里需要播放RTMP流要么通过Flash插件现在基本没人用了要么经过流媒体服务网关转成HTTP-FLV或者WebRTC再播放。我在调试推流工具时就常用公开的RTMP测试地址来验证编码参数和推流密钥是否正确。常见的RTMP测试地址格式如rtmp://live.example.com/live/stream12.3 M3U8这是个“节目单”不是视频本身M3U8文件本质是一个UTF-8编码的M3U列表文件里面记录的通常是多个TS分片文件的URL以及每个分片的时长有的还挂了加密信息的EXT-X-KEY标签。播放器拿到这个列表后会按顺序去请求TS分片边下边播。HLSHTTP Live Streaming就是靠M3U8工作的Apple家的东西兼容性极好几乎所有浏览器和手机都支持。现在大部分点播平台、直播拉流包括某些安防云的hls输出都使用这种格式。但它的缺点也很明显延迟高一般有5到15秒不适合实时对讲的场景。网上很多测试M3U8地址是视频网站CDN上的加密分片只能看不能存。所以M3U8地址的价值更多在验证播放器是否支持切片格式、索引解析是否正常、EXTINF时间戳是否符合规范。2.4 FLV和MP4封装格式里的“老朋友”FLV是Adobe提出的封装格式个头小、结构简单特别适合在浏览器里通过HTTP-FLV方式播放直播流。因为它不需要像MP4那样将moov元数据放在文件头部才能播放所以FLV对直播这种顺序写入的场景更友好。MP4则是目前最通用的多媒体封装格式适合点播但不适合当直播流直接传输。因为MP4是面向随机访问设计的播放器通常需要读到moov盒子里的关键帧索引才能开始解码如果moov在文件尾部就会出现“先缓冲很久再播放”的现象。测试MP4地址一般用于验证播放器对标准封装格式的兼容性或者验证下载工具能否完整保存文件。测试FLV地址则常用于验证HTTP-FLV直播拉流功能、FLV.js播放器联调等。3. 实测可用的公开测试地址合集网上的流媒体测试地址变动非常快有些是官方演示服务器有些是爱好者分享的很难保证长期稳定。我在整理过程中做了筛选标准优先选择域名解析正常、90秒内能拉流成功、延迟不过分离谱、并且来源相对可靠的地址。以下是当前阶段实测可用的地址基于2026年初的多次连通性测试但请注意这类公网地址随时可能失效仅建议用于临时测试与学习。3.1 RTSP测试地址RTSP公网测试地址是所有类型里最稀缺的因为大多数RTSP摄像头在内网公网上的裸露摄像头属于安全问题我不建议大家扫描和连接陌生设备。这里放几个由测试服务商和开源社区提供的稳定地址rtsp://test.streamvault.cc:554/live/1 rtsp://rtsp.stream:1935/live/2 rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4最后一个用了比较久是Wowza官方演示地址虽然是VOD点播格式但走的是RTSP协议可以测试拉流的完整链路。前两个是社区维护的测试源连通率相对高。实际使用中可以用VLC直接打开验证ffprobe rtsp://test.streamvault.cc:554/live/1如果FFmpeg能够正常读取到视频流参数分辨率、编码格式、比特率说明这个地址是可用的。注意公网RTSP地址可能会因为网络运营商封锁554端口、服务端并发限制等问题导致拉流失败。如果连不上不要死磕同一个地址可以在FFmpeg后面加-timeout 5000000设置连接超时单位是微秒这样就不会一直卡住了。3.2 RTMP测试地址RTMP地址在直播推流测试中非常好用。我推荐的几个来源rtmp://live.hkstv.hk.lixn.com/live/nice rtmp://media3.scctv.net/live/scctv_1 rtmp://camlive.iqilu.com/live/streamdelivery1其中山东齐鲁网的rtmp://camlive.iqilu.com/live/streamdelivery1在热词里也出现过实测拉流正常。这三个地址都是媒体机构公开的测试拉流源可用来验证你的播放器或FFmpeg拉流能力。另外如果是要测试自己的RTMP推流功能不建议去推这些公网地址因为无授权推流会被服务器拒掉。更稳妥的办法是用SRS、Nginx-RTMP或者MediaMTX在本地搭建一个RTMP服务再往本地推流。3.3 M3U8测试地址M3U8地址相对容易获得很多视频网站的CDN都会生成。测试地址比较经典的有https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8 https://demo.unified-streaming.com/k8s/features/stable/video/tears-of-steel/tears-of-steel.ism/.m3u8 https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8这三个地址分别是Mux、Unified Streaming、Bitdash/Akamai提供的官方测试HLS流分别对应经典测试片源“Big Buck Bunny”和“Sintel”。它们支持不同转码档位适合测试多码率自适应逻辑。用PotPlayer播放这类M3U8时如果出现卡顿可以先检查网络到CDN节点的延迟然后用HLS解析工具比如ffprobe查看分片索引是否完整。3.4 FLV测试地址FLV测试地址在公网上比RTSP多但大多用于直播点播混合场景。稳定可用且容易记忆的https://www.w3schools.com/html/mov_bbb.flv严格来说这个是FLV文件不是流。真正的FLV直播拉流地址一般是http://域名/live/xxx.flv结构。如果你想测HTTP-FLV拉流建议自己在本地用MediaMTX搭一个几秒钟就能起一个HTTP-FLV服务http://你的服务器IP:8080/live/stream.flv如果只是验证FLV解析可以用这个W3Schools的演示文件不过我认为更实用的方法是直接用FFmpeg读取FLV文件并把分析日志打出来。3.5 MP4测试地址MP4测试源就很丰富了很多视频网站允许直接播放公开的MP4文件https://sample-videos.com/video321/mp4/720/big_buck_bunny_720p_1mb.mp4 https://www.w3schools.com/html/mov_bbb.mp4 https://interactive-examples.mdn.mozilla.net/media/cc0-videos/flower.mp4这些地址比较适合用来测播放器对MP4格式的基础兼容性或者测下载工具。有一点要注意如果后台日志显示“moov atom not found”说明文件可能被某些工具伪装成MP4实际是运动JPEG或其它封装格式需要进一步检查。4. 如何快速验证一个测试地址是否可用拿到地址后不要急着塞进播放器先用命令行工具做一层基本的探测。这样做的好处是能快速区分“服务不可达”“鉴权失败”“协议错误”“转码错误”这几类问题。我习惯用FFmpeg/ffprobe来验。4.1 用ffprobe验证地址连通性和媒体信息验证RTSP/RTMP/M3U8/FLV/MP4地址统一命令是ffprobe -v error -show_entries formatformat_name,duration -show_streams 地址比如ffprobe -v error -show_entries formatformat_name,duration -show_streams rtsp://test.streamvault.cc:554/live/1能正常输出Stream信息就说明地址可拉流。失败时输出Connection timeout、Connection refused或401 Unauthorized按提示定位问题。对于直播流加-timeout和-rw_timeout参数能避免卡住ffprobe -timeout 5000000 -rw_timeout 5000000 -v error -show_entries formatformat_name,duration rtsp://test.streamvault.cc:554/live/14.2 用VLC或PotPlayer做人工确认命令行验证跑通了再用播放器打开确认画面是否正常。VLC适合验证RTSP和M3U8PotPlayer对RTSP的缓冲处理有时会有问题反复缓冲的时候可以尝试把缓冲时间调大。而FLV直播流一般用浏览器VLC插件或者FLV.js播放器来测。顺带提一个热词里大家遇到的情况我们用PotPlayer播放RTSP流时反复缓冲多半是因为RTSP地址对应的视频码率超过网络带宽或者摄像头本身开启了多路码流导致主码流的帧过于密集。调节的办法是改用子码流地址如海康/Streaming/Channels/102这种第二码流码率会低很多。5. 搭建本地测试环境的实操方案公网地址毕竟是别人的不稳定、速率不受控、还可能有访问限制。想正儿八经测试推拉流全流程本地搭一个RTSP服务器的性价比最高。很多人在网上搜“怎样在本地搭一个rtsp服务器”这里给出一套最省心的方案。5.1 用MediaMTX搭一个本地RTSP服务器MediaMTX是一个轻量级开源流媒体服务器支持RTSP、RTMP、HLS、WebRTC、FLV等多种协议的输入输出转换一条命令就能跑起来。在Ubuntu/Debian上安装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://localhost:8554下比如你推流到rtsp://localhost:8554/test就能用ffplay rtsp://localhost:8554/test拉流验证。如果是Windows直接下载exe运行即可界面会打印出可用的URL列表。5.2 用FFmpeg推一个模拟摄像头流通常本地不能真正接摄像头时可以用测试视频文件作为视频源推成RTSP流ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream这里-re表示按原视频帧率读取文件-stream_loop -1表示无限循环-c copy是复制编码数据不做转码。如果测试文件格式与RTSP需要的编码不匹配比如FLV里带了AAC和H264一般直接copy是没问题的。推流起来后另开一个终端ffplay rtsp://localhost:8554/mystream如果能正常出画面说明本地RTSP服务链路是通的。这个方法也是验证RK3588这类嵌入式设备将USB摄像头转RTSP流的基本原理只是把test.mp4换成了USB摄像头的V4L2设备节点而已。5.3 RTSP转FLV的常见实现方式日常开发里经常遇到RTSP转FLV的需求比如安防摄像头是RTSP浏览器播放需要HTTP-FLV或M3U8。用MediaMTX就能原生支持这种转换只要同时开启协议它会自动为同一个流生成多种协议的播放地址比如RTSP输入: rtsp://localhost:8554/camera HTTP-FLV输出: http://localhost:8080/camera.flv HLS输出: http://localhost:8888/camera/index.m3u8这样不需要自己写转码逻辑服务器会自动复用一条输入流。如果视频源是H264AAC编码浏览器端播放FLV就能很流畅但如果是HEVCH265编码FLV.js默认可能不支持需要额外引入支持HEVC的魔改版。6. 避坑指南这些情况就是怎么调都调不通我在调试这些协议时踩过不少坑一半以上都不是协议本身的问题而是环境或工具导致的。这里整理一份速查表方便定位。症状可能原因排查方向RTSP连接超时服务器防火墙屏蔽554端口或IP不在允许范围更换网络环境用telnet测试端口连通性RTMP推流失败推流地址的路径未被服务器授权使用自己的RTMP服务器检查鉴权tokenM3U8播放只有声音没画面视频编码与播放器不兼容H265常见用ffprobe查看编码格式换支持H265的播放器M3U8视频转换失败分片下载不全、EXT-X-KEY加密没处理优先使用ffmpeg带-protocol_whitelist参数下载MP4无法播放moov元数据在文件尾部用ffmpeg -movflags faststart重新封装PotPlayer反复缓冲RTSP主码流码率过高或网络丢包改用子码流或调节播放缓冲手机浏览器播放M3U8卡顿4G/5G波动、CDN节点跨区域换其他网络或CDN节点降清晰度FLV.js播放不出来跨域CORS限制在服务端设置Access-Control-Allow-Origin: *ffprobe显示Connection reset by peer服务器只允许并发连接数极少减少并发测试连接数加重连间隔Winhex修复MP4后还是不能播修复了moov但未纠正box大小用专门工具如untrunc或restore另行修复我遇到最典型的例子是M3U8下载后合并成MP4失败。M3U8里的TS分片往往不是原生MP4封装直接用文件拼接工具合并就会损坏。正确的做法是用FFmpegffmpeg -i https://xxx/playlist.m3u8 -c copy output.mp4这条命令会边下边合并正确解析TS分片并生成合法的MP4索引。如果出现“Invalid data”报错多半是分片加密了需要在FFmpeg命令里带上解密的key。另外热词里提到的“mlist m3u8被隐藏了”这种情况很多视频网站会把M3U8索引放在一个动态JS变量里Network面板里直接搜不到。想抓这类地址一般用浏览器开发者工具在XHR/fetch请求里过滤m3u8关键字或者直接hookfetch函数打印所有异步请求URL。抓到以后再验证是否带了动态token参数。安卓手机缓存RTSP流时部分播放器会把RTSP流转成本地临时MP4文件缓存但这样缓存的文件往往缺少moov元数据无法直接播放。想保住缓存文件可以用ffmpeg -i cache.mp4 -c copy out_faststart.mp4重新封装成可播放文件参考Winhex修复MP4也是针对这个问题。7. 关于地址失效的应对思路公网测试地址的本质就是“临时借用”任何第三方源都有失效的一天。尤其是2026年之后各大平台对公开流媒体的限制越来越严格很多老地址都陆续关停。我在文章里给的地址虽然是当前能用的但并不能保证三个月后还能用。所以真正可靠的方案是坚持“本地自建为主公网测试为辅”的原则。本地用MediaMTX或者SRS搭建一套多协议测试环境用FFmpeg虚构视频源再配合一段测试MP4文件就足以覆盖RTSP、RTMP、M3U8、FLV、MP4这五种场景的日常调试。每次拿到一个新的公网地址先做一个快速连通性检测再写入自己的文档里。我自己维护了一份表格标注了可用日期、延迟、协议类型、码率等信息每半年清一次比临时搜靠谱得多。最后再分享一个小技巧如果只是想在浏览器里快速放一个M3U8流又不想装任何插件可以先用ffmpeg -i xxx.m3u8 -c copy -f flv pipe:1把M3U8转成FLV字节流再用flv.js里的fetchStream接口播放这样既避开了M3U8的CORS问题又免安装播放器。实际调试中这个办法救过我好几次。