RTSP与RTMP流媒体测试地址清单与实战应用指南

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 测试工具“兵器谱”

工欲善其事，必先利其器。以下是几款我常用的、跨平台的测试工具，它们能帮你快速判断一个流地址是否“活着”，以及它的基本属性。

1. VLC Media Player：这是流媒体测试的“瑞士军刀”。免费、开源、全平台支持。打开 VLC，点击“媒体” -> “打开网络串流”，粘贴地址即可。它的强大之处在于能解析绝大多数协议，并且内置了详细的日志和编解码器信息窗口（工具 -> 消息，设置 Verbosity 为 2），当播放失败时，查看日志是定位问题的第一步。

2. FFplay (FFmpeg 套件)：这是命令行下的神器。如果你在做自动化测试或开发集成，FFplay是首选。一个简单的命令ffplay -rtsp_transport tcp “rtsp://example.com/stream”就可以播放。-rtsp_transport tcp参数尤其重要，因为很多网络环境（尤其是经过 NAT 或防火墙）下，UDP传输会被阻断，强制使用TCP能解决一大半连接问题。FFplay的输出信息也非常直接，能立刻告诉你是否连接成功、音视频编码格式、分辨率、帧率等。

3. PotPlayer (Windows)或IINA (macOS)：这两款是本地播放的佼佼者，对流的兼容性和性能优化做得很好，界面也比 VLC 更友好一些。适合快速预览。

4. 在线测试网站：对于一些简单的RTMP或HLS流，可以使用像 “https://player.aliveplayer.com/” 这样的在线播放器进行快速验证。但注意，这类网站通常无法处理需要认证或特殊协议的RTSP流。

注意：测试公开流时，请务必遵守网络礼仪和法律法规。这些流主要用于技术测试，请勿长时间占用带宽或用于其他非技术目的。

3. 亲测可用的公开 RTSP 流地址与深度解析

以下地址是我在近期（请注意，公开流的可用性会随时间变化）使用VLC和FFplay进行过连通性测试的。我会对每个地址进行说明，并分享测试中遇到的情况和背后的原理。

3.1 经典公共摄像头与测试流

这类流通常由机构或个人维护，用于演示或公共服务，稳定性相对较好，但格式和参数可能比较固定。

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支持不佳。

2. 地址:rtsp://rtsp.stream/pattern

   • 协议/格式: RTSP，动态生成的各种测试图案（如彩条、时钟）。
   • 测试状态:稳定可用。这是一个专门提供测试流的服务，图案会变化，比静态文件更接近真实直播流。
   • 深度解析:
     • 价值所在：测试流的实时性。对于需要验证“流是活的”而非缓存文件的场景（比如监控画面刷新），这种动态图案流非常有用。
     • 协议细节：通过DESCRIBE命令交互后，你会发现它可能提供了多种传输方式。在复杂网络下，如果自动协商失败，可能需要像上面一样在客户端指定-rtsp_transport tcp。
     • 关联热词：这个流可以用来理解“RTSP拉流协议”的完整交互过程。用Wireshark抓包分析这个流的连接过程，是学习RTSP协议报文格式的绝佳实践。

3. 地址:rtsp://170.93.143.139/rtplive/470011e600ef003a004ee33696235daa(某公共动物园摄像头)

   • 协议/格式: RTSP over TCP/UDP，H.264。
   • 测试状态:间歇性可用。公开的动物直播流，但可能因为服务器负载、网络调整或维护而暂时不可用。
   • 深度解析:
     • “亲测”的局限性：这类流完美诠释了公开测试地址的最大问题——不确定性。它今天能通，明天可能就 404 或者连接超时了。这模拟了真实开发中对接第三方设备时常见的不稳定情况。
     • 测试意义：正因为其不稳定，它反而是一个很好的测试用例。你的应用程序或播放器需要能优雅地处理“连接失败”、“流中断”和“自动重连”的情况。在测试时，观察你的代码在流断开时是崩溃、卡住，还是能抛出清晰的错误信息并尝试恢复。
     • 安全与合规提醒：使用此类流时，务必确认其是真正公开、无隐私风险的。不要尝试连接任何看起来是私人的、未经授权的摄像头地址。

3.2 模拟设备与软件生成的流

如果你需要更稳定、更可控的测试环境，自己搭建一个流媒体服务器是最佳选择。这里给出一个用FFmpeg生成测试RTSP流的本地方法，这能解决你 90% 的开发和调试需求。

方案：使用 FFmpeg 创建本地 RTSP 测试流

1. 准备一个视频文件：例如test.mp4。

2. 启动一个简单的 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: 指定服务器地址和流路径。

3. 测试播放：在另一台机器或同一个机器的另一个终端，使用 VLC 或 FFplay 播放rtsp://[你的机器IP]:8554/mystream。

为什么推荐这个方法？

• 绝对可控：流的内容、编码、分辨率、帧率完全由你决定。
• 零网络依赖：在本地局域网或本机测试，排除了公网不稳定因素。
• 协议纯粹：这就是一个标准的RTSP流，你可以用它来调试海康、大华等设备的取流逻辑。例如，你可以模拟海康RTSP取流地址的格式（如rtsp://admin:password@ip:554/Streaming/Channels/101），虽然这里没有认证，但可以测试路径解析和连接逻辑。
• 性能测试：你可以用高码率的视频文件来测试播放器的解码性能，或者用FFmpeg模拟多路流，来测试你的NVIDIA DeepStream项目的RTSP并发路数处理能力。

4. 亲测可用的公开 RTMP 流地址与应用场景

RTMP的公开拉流地址比RTSP更少，因为RTMP现在更多地被用作推流协议和内部传输协议。不过，仍然有一些稳定的演示流存在。

1. 地址:rtmp://ns8.indexforce.com/home/mystream

   • 协议/格式: RTMP，通常包含 H.264 视频和 AAC 音频。
   • 测试状态:历史较久，可能不稳定。这是一个经典的测试地址，但近年来时常无法连接。
   • 深度解析：
     • 即使这个地址失效，它也代表了一类常见的RTMP流地址格式：rtmp://[服务器域名或IP]/[应用名]/[流名称]。理解这个结构对于配置Nginx with RTMP module或SRS等流媒体服务器至关重要。
     • 应用场景：主要用来测试RTMP拉流客户端。例如，在开发一款直播APP时，你需要一个地址来验证RTMP播放模块是否工作。也可以用于测试OBS的“媒体源”功能，看其是否能拉取并转发RTMP流。

2. 地址: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服务器并创建测试流的方案，比寻找公开流更靠谱。

1. 启动 RTMP 服务器:

   docker run -d -p 1935:1935 -p 8080:80 alfg/nginx-rtmp

   这条命令拉取一个集成了RTMP模块的Nginx镜像并运行。1935是RTMP默认端口，8080是HTTP端口（用于查看状态或播放HLS）。

2. 使用 OBS 推流:

   • 打开 OBS，进入“设置” -> “推流”。
   • 服务选择“自定义”。
   • 服务器填写：rtmp://你的服务器IP:1935/live（如果服务器在本机，IP为localhost或127.0.0.1）。
   • 串流密钥填写任意名称，如myteststream。
   • 点击“确定”并开始推流。

3. 拉流测试:

   • 此时，你的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协议。直接设置src="rtsp://..."是无效的。

解决方案核心：转协议

必须将RTSP流在服务器端转换为浏览器支持的协议，主要是HLS(.m3u8) 或WebSocket-FLV。

1. 方案一：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秒，减小这个值可以降低延迟，但会增加服务器负载和播放器请求频率。

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。
• 解决方案：
  1. 确保流地址是HLS或FLV。这就是为什么你需要先用前面提到的方法，将RTSP/RTMP流转为HLS。
  2. 正确配置<video>标签：

     <video src=“http://your-server/live/stream.m3u8” mode=“live” autoplay controls />

     注意mode=“live”对于直播流很重要。
  3. 网络请求合法域名：小程序要求所有网络请求的域名都必须在小程序管理后台的“开发设置”中添加到“request合法域名”列表。你的HLS流地址域名必须在此列表中，否则会被拦截。
  4. 对于UniApp：使用<live-player>组件而非<video>组件来播放直播流。其src属性同样需要是支持的直播协议地址。uniapp live-pusher 直播拉流 横屏这类问题，往往需要在<live-player>上设置orientation属性来控制横竖屏。

5.3 Android/iOS 原生开发缓存 RTSP 流

“安卓缓存RTSP流”是一个进阶需求。原生播放器（如ExoPlayer,IJKPlayer）播放RTSP通常没问题，但缓存（即边播边存到本地）则需要自己实现。

• 难点：RTSP/RTP流不像HTTP文件那样有明确的内容长度和范围请求，缓存策略复杂。
• 常见思路：
  1. 双路下载：一路用于播放，另一路用于完整接收流数据并写入本地文件。这需要处理协议交互和数据包重组。
  2. 使用中间代理：在本地或局域网内启一个代理服务（比如一个小的RTSP服务器），让这个代理去拉取原始流。播放器连接这个本地代理。同时，这个代理可以将收到的数据持久化到磁盘。FFmpeg可以作为一个强大的“代理”核心。
  3. 借助现有库：寻找支持缓存功能的播放器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 了。因此，建立一套应对机制比记住几个地址更重要。

1. 建立自己的测试流源：如前所述，使用FFmpeg生成本地测试流，或者搭建一个简单的RTMP/RTSP服务器。这是最可靠、最可控的方法。你可以准备几个不同分辨率、码率、编码格式（H.264/H.265）的测试视频，模拟各种真实场景。
2. 使用流媒体服务器软件的演示流：像Wowza、Ant Media Server、SRS等商业或开源流媒体服务器，它们的官方文档或演示页面通常会提供长期稳定的测试流地址。这些地址的存活率远高于个人维护的公共摄像头。
3. 编写健康检查脚本：如果你在持续集成/持续部署 (CI/CD) 流程中需要依赖某个外部测试流，可以写一个简单的脚本（用Python的requests库或FFmpeg的-timeout参数），定期尝试连接该流地址。一旦发现失效，立即告警，并切换到备用流（如你的自建流）。
4. 理解错误码：当流连接失败时，工具会给出错误信息。
   • 401 Unauthorized: 需要认证。公开流不应有此问题，但提醒你对接真实设备时需处理用户名密码。
   • 404 Not Found: 流路径不存在。
   • Connection refused或Timeout: 服务器未开启或网络不通。
   • Failed to open decoder for stream #0:0: 无法解码。可能是编码格式（如H.265）播放器不支持，需要转码。

最后，分享一个我个人的习惯：我会维护一个本地的Markdown文档，记录下那些曾经好用的公开流地址、自建流的命令、以及在不同平台上遇到的特有问题和解决方案。这个文档随着项目积累不断更新，它已经成了我处理流媒体相关问题时最快的第一参考。技术变化快，但解决问题的思路和方法是相通的。希望这份详尽的指南和地址清单，能帮你少踩些坑，更高效地完成开发测试工作。