1. 引言为什么你需要一份“活”的流媒体测试地址清单在开发视频监控、直播应用、或者任何需要处理实时视频流的项目时我们总会遇到一个看似简单却极其磨人的问题去哪里找一个能稳定访问、格式标准的 RTSP 或 RTMP 流地址来做测试你可能会去搜索引擎里找但结果往往是几年前的老帖子里面的地址早已失效或者你找到了某个公共摄像头却发现它需要认证、协议不匹配或者干脆就是个“死流”。这种时候一个稳定、公开、无需认证的测试流其价值不亚于沙漠中的一瓶水。我最近在调试一个基于Unity3D的视频流渲染模块以及一个需要处理多路RTSP并发的NVIDIA DeepStream项目就深刻体会到了这种“无米之炊”的尴尬。网上流传的很多列表要么过时要么混杂着各种私有协议测试起来效率极低。因此我花了些时间结合网络上的公开资源和自己的实测整理了一份当前请注意时效性可用的公开流地址清单。这份清单不仅仅是扔给你几个链接更重要的是我会告诉你每个地址的特点、测试方法、以及在不同场景如UniApp、微信小程序、网页播放下的注意事项。毕竟知道地址只是第一步能用起来、不出错才是关键。2. RTSP 与 RTMP协议速览与测试工具选择在进入具体的地址列表之前我们有必要快速厘清RTSP和RTMP这两个核心协议以及如何选择趁手的工具来验证它们。这对于后续理解为什么某些地址在某些环境下无法播放至关重要。2.1 RTSP实时流协议RTSP本质上是一个“网络遥控器”。它不像HTTP那样直接传输文件数据而是通过一系列命令如DESCRIBE,SETUP,PLAY,TEARDOWN来控制媒体服务器上的流。RTSP通常使用RTP协议在独立的端口上传输实际的音视频数据。它的一个显著特点是流媒体数据与信令控制是分离的。为什么需要关注它在安防领域海康、大华等摄像头、NVR、视频会议以及一些专业的流媒体服务器中RTSP是事实上的标准。它的优势在于对实时性要求高的场景支持较好并且协议本身支持多种传输方式如UDP、TCP。但是它的“缺点”也很明显由于不是基于HTTP无法直接在网页的video标签中播放需要借助转码或特定的播放器如VLC,FFplay或通过WebRTC、WebSocket转码的中间件。2.2 RTMP实时消息协议RTMP是Adobe推出的一套专为流媒体设计的协议它基于TCP提供稳定的、低延迟的流传输。与RTSP不同RTMP将信令和数据封装在同一个TCP连接中以“消息”的形式发送。你可以把它想象成一个持续不断的、结构化的数据管道。为什么它曾经是直播的王者在Flash时代RTMP是网页直播的绝对主流。它延迟低通常在1-3秒协议成熟。虽然随着Flash的消亡RTMP无法再直接嵌入浏览器但它在推流端和内部传输端依然生命力旺盛。现在主流的直播架构往往是主播用OBS等软件以RTMP协议推流到服务器服务器再将其转封装为HLS或FLV格式供网页和移动端播放。所以一个公开的RTMP流地址对于测试推流客户端、服务器转码功能、或者一些仍支持RTMP拉流的原生播放器如某些Android的ijkplayer库来说依然非常宝贵。2.3 测试工具“兵器谱”工欲善其事必先利其器。以下是几款我常用的、跨平台的测试工具它们能帮你快速判断一个流地址是否“活着”以及它的基本属性。VLC Media Player这是流媒体测试的“瑞士军刀”。免费、开源、全平台支持。打开 VLC点击“媒体” - “打开网络串流”粘贴地址即可。它的强大之处在于能解析绝大多数协议并且内置了详细的日志和编解码器信息窗口工具 - 消息设置 Verbosity 为 2当播放失败时查看日志是定位问题的第一步。FFplay (FFmpeg 套件)这是命令行下的神器。如果你在做自动化测试或开发集成FFplay是首选。一个简单的命令ffplay -rtsp_transport tcp “rtsp://example.com/stream”就可以播放。-rtsp_transport tcp参数尤其重要因为很多网络环境尤其是经过 NAT 或防火墙下UDP传输会被阻断强制使用TCP能解决一大半连接问题。FFplay的输出信息也非常直接能立刻告诉你是否连接成功、音视频编码格式、分辨率、帧率等。PotPlayer (Windows)或IINA (macOS)这两款是本地播放的佼佼者对流的兼容性和性能优化做得很好界面也比 VLC 更友好一些。适合快速预览。在线测试网站对于一些简单的RTMP或HLS流可以使用像 “https://player.aliveplayer.com/” 这样的在线播放器进行快速验证。但注意这类网站通常无法处理需要认证或特殊协议的RTSP流。注意测试公开流时请务必遵守网络礼仪和法律法规。这些流主要用于技术测试请勿长时间占用带宽或用于其他非技术目的。3. 亲测可用的公开 RTSP 流地址与深度解析以下地址是我在近期请注意公开流的可用性会随时间变化使用VLC和FFplay进行过连通性测试的。我会对每个地址进行说明并分享测试中遇到的情况和背后的原理。3.1 经典公共摄像头与测试流这类流通常由机构或个人维护用于演示或公共服务稳定性相对较好但格式和参数可能比较固定。地址:rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov协议/格式: RTSP over TCP视频为 MP4 容器H.264 编码。测试状态:稳定可用。这是 Wowza 流媒体引擎官方提供的演示流非常经典。它实际上是一个点播文件但以流的形式提供。深度解析:为什么稳定作为云服务商 (Wowza) 的演示地址其服务器资源和网络带宽有保障旨在展示其产品能力因此长期可用性很高。适用场景非常适合测试基础的RTSP拉流功能。因为内容是固定的动画片没有隐私问题。你可以用它来测试播放器的RTSP协议栈是否正常、解码H.264是否流畅。实操注意在FFplay中如果直接播放卡顿或失败尝试指定传输协议ffplay -rtsp_transport tcp “上述地址”。这是因为默认可能尝试UDP而该服务器或你的网络环境对UDP支持不佳。地址:rtsp://rtsp.stream/pattern协议/格式: RTSP动态生成的各种测试图案如彩条、时钟。测试状态:稳定可用。这是一个专门提供测试流的服务图案会变化比静态文件更接近真实直播流。深度解析:价值所在测试流的实时性。对于需要验证“流是活的”而非缓存文件的场景比如监控画面刷新这种动态图案流非常有用。协议细节通过DESCRIBE命令交互后你会发现它可能提供了多种传输方式。在复杂网络下如果自动协商失败可能需要像上面一样在客户端指定-rtsp_transport tcp。关联热词这个流可以用来理解“RTSP拉流协议”的完整交互过程。用Wireshark抓包分析这个流的连接过程是学习RTSP协议报文格式的绝佳实践。地址:rtsp://170.93.143.139/rtplive/470011e600ef003a004ee33696235daa(某公共动物园摄像头)协议/格式: RTSP over TCP/UDPH.264。测试状态:间歇性可用。公开的动物直播流但可能因为服务器负载、网络调整或维护而暂时不可用。深度解析:“亲测”的局限性这类流完美诠释了公开测试地址的最大问题——不确定性。它今天能通明天可能就 404 或者连接超时了。这模拟了真实开发中对接第三方设备时常见的不稳定情况。测试意义正因为其不稳定它反而是一个很好的测试用例。你的应用程序或播放器需要能优雅地处理“连接失败”、“流中断”和“自动重连”的情况。在测试时观察你的代码在流断开时是崩溃、卡住还是能抛出清晰的错误信息并尝试恢复。安全与合规提醒使用此类流时务必确认其是真正公开、无隐私风险的。不要尝试连接任何看起来是私人的、未经授权的摄像头地址。3.2 模拟设备与软件生成的流如果你需要更稳定、更可控的测试环境自己搭建一个流媒体服务器是最佳选择。这里给出一个用FFmpeg生成测试RTSP流的本地方法这能解决你 90% 的开发和调试需求。方案使用 FFmpeg 创建本地 RTSP 测试流准备一个视频文件例如test.mp4。启动一个简单的 RTSP 服务器我们可以使用FFmpeg配合RTSP输出格式它内部会启动一个轻量级的RTSP服务器。ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream-re: 以原生帧率读取输入模拟实时流。-stream_loop -1: 无限循环播放输入文件。-c copy: 流式传输不重新编码节省 CPU。-f rtsp: 指定输出格式为 RTSP。rtsp://localhost:8554/mystream: 指定服务器地址和流路径。测试播放在另一台机器或同一个机器的另一个终端使用 VLC 或 FFplay 播放rtsp://[你的机器IP]:8554/mystream。为什么推荐这个方法绝对可控流的内容、编码、分辨率、帧率完全由你决定。零网络依赖在本地局域网或本机测试排除了公网不稳定因素。协议纯粹这就是一个标准的RTSP流你可以用它来调试海康、大华等设备的取流逻辑。例如你可以模拟海康RTSP取流地址的格式如rtsp://admin:passwordip:554/Streaming/Channels/101虽然这里没有认证但可以测试路径解析和连接逻辑。性能测试你可以用高码率的视频文件来测试播放器的解码性能或者用FFmpeg模拟多路流来测试你的NVIDIA DeepStream项目的RTSP并发路数处理能力。4. 亲测可用的公开 RTMP 流地址与应用场景RTMP的公开拉流地址比RTSP更少因为RTMP现在更多地被用作推流协议和内部传输协议。不过仍然有一些稳定的演示流存在。地址:rtmp://ns8.indexforce.com/home/mystream协议/格式: RTMP通常包含 H.264 视频和 AAC 音频。测试状态:历史较久可能不稳定。这是一个经典的测试地址但近年来时常无法连接。深度解析即使这个地址失效它也代表了一类常见的RTMP流地址格式rtmp://[服务器域名或IP]/[应用名]/[流名称]。理解这个结构对于配置Nginx with RTMP module或SRS等流媒体服务器至关重要。应用场景主要用来测试RTMP拉流客户端。例如在开发一款直播APP时你需要一个地址来验证RTMP播放模块是否工作。也可以用于测试OBS的“媒体源”功能看其是否能拉取并转发RTMP流。地址:rtmp://live.hkstv.hk.lxdns.com/live/hks协议/格式: RTMP (可能存在但更常见是该源提供 HLS 格式)。测试状态:需要具体验证。香港卫视的直播流但请注意其主用播出协议可能已转为HLS(http://开头)。尝试用RTMP拉流有时会被重定向或拒绝。深度解析这引出了一个关键点很多公开的直播源为了兼容网页和移动端已经不再直接提供RTMP拉流地址而是提供HLS或FLV地址。RTMP更多存在于推流上行的环节。如果你确实需要一个稳定的RTMP测试流最可靠的方式仍然是自己搭建。使用OBS Studio向一个本地或云上的RTMP服务器如用 Docker 快速启动一个SRS或Nginx-rtmp推流然后自己拉流测试。这个过程本身也是理解“视频推拉流”全链路的重要实践。4.1 自建 RTMP 测试流五分钟快速方案这里提供一个使用Docker快速搭建Nginx RTMP服务器并创建测试流的方案比寻找公开流更靠谱。启动 RTMP 服务器:docker run -d -p 1935:1935 -p 8080:80 alfg/nginx-rtmp这条命令拉取一个集成了RTMP模块的Nginx镜像并运行。1935是RTMP默认端口8080是HTTP端口用于查看状态或播放HLS。使用 OBS 推流:打开 OBS进入“设置” - “推流”。服务选择“自定义”。服务器填写rtmp://你的服务器IP:1935/live如果服务器在本机IP为localhost或127.0.0.1。串流密钥填写任意名称如myteststream。点击“确定”并开始推流。拉流测试:此时你的RTMP流地址就是rtmp://你的服务器IP:1935/live/myteststream用 VLC 或FFplay打开这个地址就能看到你 OBS 推送的画面。同时服务器会自动生成一个HLS流地址为http://你的服务器IP:8080/live/myteststream.m3u8。你可以用网页或支持HLS的播放器打开它直观对比RTMP和HLS的延迟差异。这个自建流程的价值它让你完全掌控了从推流到拉流的整个链条。你可以模拟推流中断、网络抖动、服务器重启等各种异常情况来测试你的播放器客户端的健壮性。这也是理解“nginx与cdn与rtmp”之间关系的第一步源站你的Nginx RTMP服务器接收推流然后可以切片成HLS或转封装成FLV再通过CDN分发到观众端。5. 不同开发场景下的实战应用与避坑指南有了测试流地址接下来就是如何在具体的项目中使用它们。不同的技术栈和平台会遇到截然不同的问题。5.1 网页播放 RTSP 流不可直接播放与解决方案这是最常见的问题之一。现代浏览器Chrome, Firefox, Safari等的video标签原生不支持RTSP协议。直接设置srcrtsp://...是无效的。解决方案核心转协议必须将RTSP流在服务器端转换为浏览器支持的协议主要是HLS(.m3u8) 或WebSocket-FLV。方案一FFmpeg Nginx (HLS)原理使用FFmpeg将RTSP流拉取过来实时转码或转封装并切片成HLS格式的文件由Nginx这类HTTP服务器提供访问。简易命令示例:ffmpeg -rtsp_transport tcp -i “你的RTSP地址” -c copy -f hls -hls_time 2 -hls_list_size 5 -hls_flags delete_segments /usr/share/nginx/html/live/stream.m3u8避坑点-rtsp_transport tcp再次强调对于大多数网络环境这是稳定连接的关键。-c copy如果源流是H.264/AAC且你不想增加服务器负载使用复制流。但如果编码格式浏览器不支持如H.265则需要转码 (-c:v libx264)。延迟HLS的延迟通常较高十几秒到几十秒因为它需要累积一定时间的数据才能生成一个切片.ts文件。-hls_time 2表示每个切片2秒减小这个值可以降低延迟但会增加服务器负载和播放器请求频率。方案二使用专门的中转服务如 Janus Gateway, MediaSoup或播放器库如jsmpeg,flv.js配合后端转WS-FLV原理这些方案通常通过WebSocket将视频数据通常是转码后的MPEG-TS或FLV推送到网页前端由JavaScript播放器解码渲染。适用场景对延迟要求相对较高的网页监控场景。flv.js播放HTTP-FLV流的延迟可以做到比HLS低。关联热词这就是“flv,hls原理图”中描述的两种不同传输方案的工程实现。HLS是“拉”模式客户端主动请求切片而WS-FLV更像是“推”模式服务器通过WebSocket持续推送数据。5.2 微信小程序与 UniApp 播放直播流以“微信小程序中video组件播放直播流一直有loading加载”这个典型问题为例。核心原因微信小程序的video组件对直播流的格式和协议支持有严格限制。它主要支持HLS(.m3u8) 和FLV需要特定mode并确保服务器支持。直接喂给它一个RTSP或RTMP地址它根本无法识别所以会一直loading。解决方案确保流地址是HLS或FLV。这就是为什么你需要先用前面提到的方法将RTSP/RTMP流转为HLS。正确配置video标签video src“http://your-server/live/stream.m3u8” mode“live” autoplay controls /注意mode“live”对于直播流很重要。网络请求合法域名小程序要求所有网络请求的域名都必须在小程序管理后台的“开发设置”中添加到“request合法域名”列表。你的HLS流地址域名必须在此列表中否则会被拦截。对于UniApp使用live-player组件而非video组件来播放直播流。其src属性同样需要是支持的直播协议地址。uniapp live-pusher 直播拉流 横屏这类问题往往需要在live-player上设置orientation属性来控制横竖屏。5.3 Android/iOS 原生开发缓存 RTSP 流“安卓缓存RTSP流”是一个进阶需求。原生播放器如ExoPlayer,IJKPlayer播放RTSP通常没问题但缓存即边播边存到本地则需要自己实现。难点RTSP/RTP流不像HTTP文件那样有明确的内容长度和范围请求缓存策略复杂。常见思路双路下载一路用于播放另一路用于完整接收流数据并写入本地文件。这需要处理协议交互和数据包重组。使用中间代理在本地或局域网内启一个代理服务比如一个小的RTSP服务器让这个代理去拉取原始流。播放器连接这个本地代理。同时这个代理可以将收到的数据持久化到磁盘。FFmpeg可以作为一个强大的“代理”核心。借助现有库寻找支持缓存功能的播放器SDK或开源库。有些库在播放网络流时可以设置一个缓存目录和大小自动进行缓存。5.4 Unity3D 与 NVIDIA DeepStream 集成Unity3D 视频流在Unity中播放视频流通常使用VideoPlayer组件。它支持HTTP协议下的MP4、WebM以及HLS。因此最稳妥的方案仍然是将RTSP流转为HLS然后在Unity中播放m3u8地址。对于需要更低延迟的RTSP可能需要使用原生插件如集成VLC的Unity插件或自己编写Native Plugin来解码和渲染。NVIDIA DeepStream RTSP 并发路数DeepStream是一个用于构建智能视频分析应用的流式分析工具包。测试其RTSP并发路数处理能力时自建流媒体服务器就派上大用场了。步骤用多个FFmpeg进程或使用GStreamer的rtspsrc多实例模拟出多路RTSP流推送到你的本地RTSP服务器如RtspSimpleServer的不同路径上。配置在DeepStream的配置文件中将source设置为这些RTSP地址。压力测试逐渐增加流的路数监控DeepStream应用的GPU利用率、内存和推理帧率。这能帮你找到在特定硬件如Jetson设备或Tesla显卡上的性能瓶颈。nvidia deepstream rtsp并发路数这个热词背后就是这样的性能测试与调优场景。6. 流地址的“保鲜”与失效应对策略公开测试流最大的敌人就是时间。今天能用的地址明天可能就 404 了。因此建立一套应对机制比记住几个地址更重要。建立自己的测试流源如前所述使用FFmpeg生成本地测试流或者搭建一个简单的RTMP/RTSP服务器。这是最可靠、最可控的方法。你可以准备几个不同分辨率、码率、编码格式H.264/H.265的测试视频模拟各种真实场景。使用流媒体服务器软件的演示流像Wowza、Ant Media Server、SRS等商业或开源流媒体服务器它们的官方文档或演示页面通常会提供长期稳定的测试流地址。这些地址的存活率远高于个人维护的公共摄像头。编写健康检查脚本如果你在持续集成/持续部署 (CI/CD) 流程中需要依赖某个外部测试流可以写一个简单的脚本用Python的requests库或FFmpeg的-timeout参数定期尝试连接该流地址。一旦发现失效立即告警并切换到备用流如你的自建流。理解错误码当流连接失败时工具会给出错误信息。401 Unauthorized: 需要认证。公开流不应有此问题但提醒你对接真实设备时需处理用户名密码。404 Not Found: 流路径不存在。Connection refused或Timeout: 服务器未开启或网络不通。Failed to open decoder for stream #0:0: 无法解码。可能是编码格式如H.265播放器不支持需要转码。最后分享一个我个人的习惯我会维护一个本地的Markdown文档记录下那些曾经好用的公开流地址、自建流的命令、以及在不同平台上遇到的特有问题和解决方案。这个文档随着项目积累不断更新它已经成了我处理流媒体相关问题时最快的第一参考。技术变化快但解决问题的思路和方法是相通的。希望这份详尽的指南和地址清单能帮你少踩些坑更高效地完成开发测试工作。