ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

RTSP/RTMP公开测试流地址大全：音视频开发调试必备资源

2026/8/5 11:54:23 拓冰建站 浏览量
RTSP/RTMP公开测试流地址大全：音视频开发调试必备资源 1. 项目概述为什么我们需要公开的流媒体测试地址做音视频开发、安防监控对接或者只是想测试一下自己的播放器、推流软件你是不是也经常卡在第一步——找不到一个稳定、可用的在线视频流地址我干了十几年音视频相关的工作从早期的Flash流媒体到现在的WebRTC最头疼的不是写代码而是调试时找不到合适的测试源。一个“亲测可行”的公开RTSP/RTMP地址列表对开发者来说价值不亚于一份清晰的API文档。RTSP和RTMP这两个协议可以说是流媒体领域的“老将”了。RTSPReal Time Streaming Protocol更像是一个“遥控器”它负责建立和控制媒体会话告诉你从哪里开始播、暂停、快进真正的音视频数据通常通过RTP协议传输。它常见于网络摄像头、IP Camera、安防监控系统像海康、大华这些厂商的设备默认的取流方式就是RTSP。而RTMPReal-Time Messaging Protocol则是Adobe的“亲儿子”在直播领域统治了很长一段时间。它基于TCP将音视频数据打包成“消息块”进行传输延迟相对较低是早期直播平台和推流软件如OBS的标配。现在问题来了你想测试一个播放器能否正常解码H.264或者验证你的服务端能否稳定拉流上哪找这些地址自己搭一套太麻烦。用网上搜到的老旧地址十有八九已经失效。这就是为什么整理一份实时更新的、可用的公开测试流地址成了一个刚需。这份资源不仅能帮你快速验证功能还能作为学习协议、分析流媒体格式的绝佳样本。接下来我会把我这些年积累的、以及近期反复验证过的地址分享出来并详细拆解如何使用它们以及背后可能遇到的坑。2. 核心资源列表亲测可用的公开流地址经过近期请注意公开流地址的可用性会随时间变化本文更新于近期的多轮测试我从众多来源中筛选出了以下一批稳定性和可用性较高的地址。我将它们按协议和用途分类并附上了简单的描述。2.1 RTSP 测试流地址RTSP流多来源于一些开放的摄像头或测试服务器。它们的共同特点是协议交互完整但可能对并发连接数有限制高峰期可能出现连接缓慢或失败的情况。2.1.1 综合类公开摄像头这类地址通常来自一些教育机构或公共服务机构开放的测试流格式标准适合基础功能测试。rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov描述Wowza官方提供的经典测试流内容是《Big Buck Bunny》动画片。该服务器位于海外国内连接可能较慢或不稳定但作为RTSP协议标准的参考流非常合适。视频编码通常为H.264音频编码AACrtsp://rtsp.stream/pattern描述一个提供各种测试图案如彩条、时钟的流媒体服务。图案流的好处是数据量稳定没有复杂运动非常适合测试解码器的稳定性和渲染性能。特点流持续可用图案会周期性变化。2.1.2 动物与景观摄像头稳定性相对较高这些是真实的、持续运行的摄像头流内容生动但同时也意味着其可用性取决于摄像头维护方。rtsp://170.93.143.139/rtplive/470011e600ef003a004ee33696235daa描述一个位于某水族馆的公开摄像头。我测试时能看到鱼群游动延迟在2-3秒左右。这类地址是测试“实时流”感觉的好选择。注意IP地址形式的流需要确保你的测试环境网络能够访问该IP和端口默认554。rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov描述另一个提供《Big Buck Bunny》的RTSP流有时作为备选。重要提示使用公开IP摄像头地址时务必遵守网络礼仪和法律法规。仅用于测试和学习目的不得进行恶意扫描、攻击或侵犯隐私。这些地址是他人提供的公共服务请勿滥用。2.2 RTMP 测试流地址RTMP流现在多见于一些直播平台的回源或测试服务器。由于Adobe已停止对Flash的支持纯粹的RTMP播放场景减少但在推流测试、服务器转发测试中仍是核心协议。2.2.1 直播平台测试流rtmp://live.hkstv.hk.lxdns.com/live/hks描述香港卫视的直播流历史非常悠久是RTMP测试界的“常青树”。可用性极高内容为新闻节目等。是测试RTMP拉流功能的首选。格式通常是标准RTMP流视频编码为H.264。rtmp://ns8.indexforce.com/home/mystream描述一个经典的测试流地址但稳定性不如前者有时会断开或无法连接可作为备选测试。2.2.2 点播文件测试流rtmp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov描述与上述RTSP地址同源但使用RTMP协议传输同样的《Big Buck Bunny》影片。这非常适合用于对比测试RTMP和RTSP协议在拉取同一内容时的行为差异。2.3 其他相关格式的测试地址HLS/FLV在实际测试中我们经常需要多协议对比。这里也提供几个常用的HLS和FLV地址它们虽然不属于RTSP/RTMP但在完整的工作流中常被涉及。HLS (HTTP Live Streaming) 测试地址:https://devstreaming-cdn.apple.com/videos/streaming/examples/img_bipbop_adv_example_fmp4/master.m3u8描述苹果官方提供的标准HLS测试流包含多码率自适应是测试HLS播放器兼容性的黄金标准。http://playertest.longtailvideo.com/adaptive/wowzaid3/playlist.m3u8描述JW Player提供的测试流也非常稳定。FLV 文件测试地址:http://vjs.zencdn.net/v/oceans.flv描述一个直接的FLV文件地址可用于测试FLV解封装和播放。为了方便查阅我将上述核心的RTSP/RTMP地址整理成下表协议地址内容描述稳定性评级主要用途RTSPrtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov动画片《Big Buck Bunny》★★★☆☆RTSP协议标准测试、播放器开发RTSPrtsp://rtsp.stream/pattern测试图案彩条、时钟★★★★☆解码器稳定性测试、渲染测试RTSPrtsp://170.93.143.139/rtplive/470011e600ef003a004ee33696235daa实时水族馆摄像头★★☆☆☆实时流延迟测试、场景测试RTMPrtmp://live.hkstv.hk.lxdns.com/live/hks香港卫视直播★★★★★RTMP拉流功能测试、直播流测试RTMPrtmp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov动画片《Big Buck Bunny》★★★☆☆RTMP点播测试、协议对比3. 工具与方法论如何测试与使用这些流地址拿到地址只是第一步如何验证它是否真的“可用”以及如何将它集成到你的项目中才是关键。这里我分享一套从快速验证到深度集成的完整方法论。3.1 快速验证工具推荐在写代码之前先用现成工具看一眼流是否正常能节省大量时间。VLC Media Player这是流媒体测试的“瑞士军刀”。免费、开源、跨平台支持几乎所有协议。使用方法打开VLC点击“媒体” - “打开网络串流”将RTSP或RTMP地址粘贴进去即可播放。进阶技巧在“工具” - “编解码器信息”中你可以看到流的详细技术参数如视频分辨率、编码格式、码率、音频编码等这对于调试至关重要。FFplayFFmpeg套件中的简易播放器命令行操作非常适合自动化测试和脚本集成。基础命令ffplay -rtsp_transport tcp “rtsp://地址”。这里指定-rtsp_transport tcp是一个关键技巧。默认情况下RTSP over UDP可能在复杂网络环境下丢包严重导致无法播放强制使用TCP传输可以极大提高连接成功率。RTMP命令ffplay “rtmp://地址”查看流信息使用ffprobe “rtsp://地址”可以不用播放直接输出最详细的流媒体信息包括流格式、编码器、时长、码率等。专业流媒体测试软件如EasyPlayer、PotPlayer等。PotPlayer对多种协议的支持也很好且硬件解码优化做的不错。3.2 在代码中集成拉流工具测试通过后就可以集成到你的项目里了。这里以几个常见场景为例。3.2.1 使用FFmpeg库C/C/命令行FFmpeg是处理流媒体的基石。一个最简单的拉流并保存到本地的命令是ffmpeg -rtsp_transport tcp -i “rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov” -c copy -f mp4 output.mp4-rtsp_transport tcp再次强调使用TCP传输RTSP。-c copy表示直接复制流不重新编码速度最快。-f mp4指定输出容器格式。如果你想在程序中集成需要使用libavformat库打开网络流avformat_open_input然后读取数据包进行解码或转发。3.2.2 在Web前端播放在网页上直接播放RTSP/RTMP是一个经典难题因为浏览器原生不支持。目前成熟的方案是转协议服务端转换在服务器端使用Nginx with RTMP module或SRS、ZLMediaKit等媒体服务器将RTSP/RTMP流拉取过来然后转换成Web端友好的协议如HLS或HTTP-FLV。HLS将流切片成.ts文件通过.m3u8播放列表分发。兼容性最好所有现代浏览器都支持但延迟通常较高10-30秒。HTTP-FLV基于HTTP长连接分发FLV格式流。延迟可做到2-5秒但需要前端使用flv.js等库进行播放。前端播放播放HLS可使用hls.js库针对MSE或直接使用video标签如果浏览器原生支持HLS。播放HTTP-FLV使用flv.js库。一个简单的Nginx RTMP转HLS配置示意rtmp { server { listen 1935; application live { live on; # 将推送的流转换为HLS hls on; hls_path /tmp/hls; hls_fragment 2s; } application pull { live on; # 主动拉取远端RTSP流 pull rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov namebunny static; } } } http { server { ... location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } alias /tmp/hls; add_header Cache-Control no-cache; # 禁用缓存对直播很重要 } } }这样RTSP流就被Nginx拉取并转换成HLS前端通过访问http://你的服务器地址/hls/bunny.m3u8就能播放了。3.2.3 在移动端Android/iOS播放移动端有更丰富的原生支持。Android可以使用ExoPlayer或ijkplayer。ExoPlayer是Google官方推荐功能强大支持DASH、HLS、SmoothStreaming通过扩展也能支持RTSP/RTMP。ijkplayer是基于FFmpeg的播放器对非常规协议支持更好。iOS使用AVPlayer框架可以完美支持HLS。对于RTSP/RTMP通常需要集成FFmpeg编译的库如kxmovie或使用VLCKit等第三方框架。3.3 测试要点与排查清单当你连接失败时别急着放弃按照这个清单一步步排查网络连通性这是最常见的问题。先用ping和telnet检查目标地址的IP和端口RTSP默认554RTMP默认1935是否能通。很多公司网络或家庭路由器会限制外网访问。协议与传输方式对于RTSP尝试在工具或代码中强制指定rtsp_transport为tcp。UDP在跨网、有防火墙的情况下极易失败。认证信息部分公开流后期可能增加了认证。检查地址中是否包含用户名和密码格式通常为rtsp://username:passwordip:port/path。流格式兼容性用ffprobe检查流的编码格式。你的播放器或解码库是否支持该编码如H.265/HEVC是否支持音频编码如G.711并发与限制公开服务器往往有连接数限制。如果你短时间内多次连接失败可能是触发了限制。稍等片刻再试。防火墙与安全软件本地电脑的防火墙或安全软件可能阻止了播放器或你的应用程序访问网络。尝试暂时禁用它们进行测试。4. 进阶应用与原理浅析掌握了基本用法我们再来深入一点看看这些测试流能帮助我们理解哪些更深层的知识以及如何应对更复杂的场景。4.1 协议交互过程抓包分析要真正理解为什么一个流能播或不能播抓包分析是最直接的手段。使用Wireshark或tcpdump。RTSP交互分析过滤rtsp协议。你会看到典型的OPTIONS,DESCRIBE,SETUP,PLAY等命令交互。DESCRIBE的响应中包含了SDPSession Description Protocol信息这里详细描述了媒体流的编码、格式、传输地址RTP端口。如果这一步失败说明服务器不认可你的请求。SETUP阶段会协商RTP/RTCP的传输通道。如果这里失败可能是端口被占用或防火墙阻止。RTMP交互分析过滤rtmp协议。RTMP连接始于一个简单的握手然后是connect、createStream、play或publish等命令。你可以清晰地看到“消息块”的流动。如果握手成功但play命令后没有数据流可能是流名称不对或服务器内部错误。通过抓包你可以精确地定位问题发生在协议交互的哪一步这是解决疑难杂症的金钥匙。4.2 处理海康、大华等私有协议变种在实际的安防项目对接中你遇到的不会是标准的、简单的RTSP地址。海康威视Hikvision、大华Dahua等厂商的摄像头或NVR网络视频录像机虽然也支持RTSP但地址格式和参数常有私有化扩展。一个典型的海康摄像头RTSP取流地址模板是rtsp://username:passwordip:port/Streaming/Channels/[ID]?transportmodeunicast/Streaming/Channels/是固定路径。[ID]通常由三部分组成通道号:码流类型:视频编码类型。例如101表示1号通道的主码流高清102表示1号通道的子码流标清。transportmode参数可以指定单播unicast或多播multicast。实操心得最可靠的方式是查阅设备对应的官方SDK文档或ONVIF协议实现说明。使用ONVIF协议一种网络视频设备通用接口标准的GetStreamUri命令可以让设备自己告诉你标准的RTSP地址这是最兼容的方法。直接拼接地址虽然快但不同型号、不同固件版本可能有细微差别容易踩坑。4.3 性能测试并发拉流与压力测试当你开发一个视频平台或中间件需要知道它同时能处理多少路流。这时你可以利用这些公开流特别是稳定的测试图案流进行压力测试。使用FFmpeg模拟多路拉流写一个Shell脚本或Python脚本循环启动多个FFmpeg进程每个进程拉取同一路或不同的测试流并输出到/dev/nullLinux或NULWindows以模拟纯消耗。# 一个简单的bash循环示例模拟10路拉流 for i in {1..10}; do ffmpeg -rtsp_transport tcp -i “rtsp://rtsp.stream/pattern” -f null - done注意请谨慎对同一公开服务器发起过高并发连接这可能被视为攻击行为。最好在自己的内网搭建测试服务器如用ffmpeg循环推流一个文件到本地的SRS或Nginx-RTMP进行压力测试。监控指标在测试过程中监控你的服务器或应用程序的CPU和内存占用网络带宽入向和出向连接数丢包率对于RTSP/RTP延迟从拉流到播放/转发的端到端延迟分析瓶颈如果并发数上不去瓶颈可能出现在网络I/O服务器网卡带宽或内核网络参数限制。磁盘I/O如果涉及录像或截图。解码能力如果服务器需要先解码再转码TranscodingCPU会迅速成为瓶颈。此时应考虑使用硬件加速如GPU、Intel QSV、NVIDIA NVENC或直接流转发Stream Copy。4.4 流媒体服务器搭建与推流测试“授人以鱼不如授人以渔”。长期依赖公开流不是办法自己搭建一个简单的测试环境才是最可靠的。方案一使用SRSSimple Realtime ServerSRS是一个国产优秀的开源流媒体服务器支持RTMP、HLS、HTTP-FLV、WebRTC等安装和使用非常简单。安装按照官方GitHub仓库的说明几行命令就能在Ubuntu上完成安装。推流测试使用OBS Studio设置推流地址为rtmp://你的服务器IP/live/流名称。拉流测试用VLC或FFplay拉取rtmp://你的服务器IP/live/流名称或者播放其生成的HLS地址http://你的服务器IP:8080/live/流名称.m3u8。方案二使用Nginx with nginx-rtmp-module这是一个更经典的组合配置灵活社区资料多。编译安装需要下载Nginx源码和RTMP模块源码一起编译。配置如前文所示配置RTMP服务和应用。测试与SRS类似使用OBS推流再用工具拉流。拥有自己的测试服务器后你可以随意测试各种编码参数码率、分辨率、帧率、各种协议转换完全掌控测试环境。5. 常见问题与避坑指南实录在这一行摸爬滚打踩过的坑比写过的代码都多。下面这些是我和同事们用“血泪”换来的经验你在文档里很难看到。问题一连接RTSP流时VLC能播但自己的代码连不上。排查99%的问题出在**Transport头或User-Agent头**上。一些RTSP服务器尤其是一些摄像头对客户端发出的请求头有严格要求。解决用Wireshark抓包对比VLC发出的DESCRIBE请求和你代码发出的请求。重点看Transport字段VLC可能会发送Transport: RTP/AVP/TCP;interleaved0-1而你的代码可能只写了Transport: RTP/AVP;unicast。把User-Agent头改成Lavf/或VLC有时也能“骗过”服务器。模仿一个成熟客户端的请求是最快的解决方案。问题二播放公开RTMP流有声音没画面或者花屏。排查这通常是视频编码格式不支持导致的。特别是有些老旧的RTMP流可能使用VP6或Screen Video等编码而现代播放器默认只支持H.264。解决用ffprobe确认视频编码。如果是非常用编码需要在播放器或解码库中启用对应的解码器。对于开发而言使用FFmpeg库通常能自动处理但若使用某些精简版的播放器SDK可能需要额外配置。问题三延迟巨大达到几十秒甚至分钟级。排查首先区分是网络延迟还是播放缓冲延迟。解决网络延迟选择地理位置上更近的测试源或者检查本地网络是否有拥塞。播放缓冲延迟这是最常见的原因。播放器包括VLC为了应对网络抖动默认会设置一个较大的缓冲区如2-4秒。对于需要低延迟的监控场景必须调整这个参数。在VLC中工具 - 偏好设置显示所有设置 - 输入/编解码器 - 网络缓存时间可以调小如300ms但网络不好时容易卡顿。在FFplay中使用-fflags nobuffer -flags low_delay参数来减少缓冲。在代码中如果你使用FFmpeg库设置AVFormatContext的flags为AVFMT_FLAG_NOBUFFER并调整probesize和max_analyze_duration为较小值。问题四公开流地址突然失效了怎么办心态这是常态不是意外。公开资源没有服务等级协议SLA。对策建立自己的备用测试源库平时多收集像本文一样整理成文档。自建测试服务器如前所述这是最根本的解决方案。在本地或内网用FFmpeg循环播放一个测试视频文件并推流到自己的媒体服务器生成一个永不失效的测试地址。使用动态发现对于学习而言可以关注一些提供公共流列表的网站或开源项目但它们的维护情况也参差不齐。一个重要的避坑技巧关于“NVIDIA DeepStream RTSP并发路数”很多人在做AI视频分析时会用到NVIDIA的DeepStream SDK。当需要处理多路RTSP流时经常会遇到性能瓶颈。这里的关键点不在于RTSP客户端本身而在于解码环节。默认陷阱DeepStream默认可能使用CPU进行RTSP流的解码这在大并发下会立即成为瓶颈。正确姿势务必启用硬件解码。在DeepStream的pipeline配置中确保decoder组件使用的是nvv4l2decoder用于Jetson平台或基于CUDA的解码器用于GPU服务器。这样RTSP拉流和解码的压力就从CPU转移到了GPU的专用解码引擎NVDEC并发路数可以提升一个数量级。同时RTSP拉流客户端本身最好也使用能异步IO的高性能库避免阻塞主线程。