简介这是一款面向自媒体创作者与视频平台运维人员的流速监控插件用于实时监测视频流的传输表现帮助定位卡顿、缓冲与上传效率问题。插件可提供流速、丢包率、延迟及缓冲时间等关键数据便于及时调整分辨率、比特率或切换网络环境保障直播与上传质量。资源包共18个文件约286KB以9个JavaScript脚本为核心逻辑搭配2个HTML页面与1个CSS样式构成交互界面另含3张PNG图标、2个MP3提示音及1个JSON配置文件结构紧凑、便于直接部署调试。目前已有1378人学习下载适合希望提升视频传输稳定性与观看体验的自媒体人和后台管理人员参考使用。1. 流速监控插件到底在监控什么从一次视频卡顿排查说起很多人第一次听到「流速监控方便监控视频流速的插件」会以为这是给监控摄像头测网速的工具。我最初也这么想直到有次值班一台 NVR 上 16 路视频里第 7 路每隔十几秒就卡一下回放却完全正常。用常规的带宽工具看总出口流量平稳得很根本看不出问题。后来写了个小插件把每一路视频流的实时码率单独打点才发现那一路的瞬时码率会在 2Mbps 和 6Mbps 之间反复横跳——编码器在场景切换时码率控制没收敛缓冲区被瞬间打满播放端就卡了。这就是流速监控插件真正要解决的问题它监控的不是「网络快不快」而是每一路视频流在时间轴上的码率、帧率、关键帧间隔、丢包与抖动这些和「流」本身强相关的指标。它适合三类人做安防集成的工程师需要判断某路画面卡顿是网络、编码还是存储的问题做视频平台运维的人要在几十上百路流里快速定位异常源还有做交通监控视频分析的人多目标车辆检测系统跑在实时流上时输入流的稳定性直接决定检测结果的可信度。插件形态上它可以是浏览器扩展、OBS 插件、FFmpeg 的封装脚本也可以是嵌进现有监控平台的采集模块。核心逻辑都一样定时从流里取统计信息按时间窗口聚合超阈值就告警。下面几章我会把选型、实现、参数和踩过的坑一条条讲清楚让你能照着搭一套自己的流速监控。2. 流速监控插件的三种落地形态与选型理由2.1 浏览器扩展形态适合快速验证和前端展示如果你的监控视频是通过 Web 页面播放的比如大多数 NVR 的 Web 端、或自研的 H5 播放器浏览器扩展是最轻的切入点。它不需要改服务端直接挂在页面里通过performanceAPI 和MediaSource的 buffer 状态就能拿到不少信息。常见做法是用chrome.webRequest或chrome.devtools.network监听视频分片的请求统计单位时间内收到的字节数再结合video元素的buffered区间算播放缓冲。这种形态的优点是开发快、能直接看到当前页面的流状态缺点是只能监控浏览器正在播的流拿不到编码器侧的原始参数也覆盖不了 RTSP 直连的场景。我一般会把它当「第一层筛子」先确认卡顿是不是发生在播放端再决定要不要往下钻。2.2 FFmpeg 封装脚本形态适合服务端批量监控真正要监控几十路 RTSP 流绕不开 FFmpeg。它的-progress输出和ffprobe能给出非常细的流信息。你可以写一个 Python 脚本对每一路流起一个轻量 FFmpeg 进程只做-c copy的转封装把统计信息打到本地文件或消息队列。这种形态的优点是覆盖面广、指标全、能拿到关键帧间隔和码率曲线缺点是要管理进程和资源路数多了 CPU 和内存要算清楚。下面给一个最小可跑的采集脚本。import subprocess import json import time # 对单路 RTSP 流做 5 秒采样输出码率和帧率 def probe_stream(rtsp_url, duration5): cmd [ ffprobe, -v, quiet, -rtsp_transport, tcp, # 监控场景优先 TCP减少丢包 -i, rtsp_url, -show_entries, streamcodec_type,avg_frame_rate,bit_rate, -of, json, -t, str(duration) ] result subprocess.run(cmd, capture_outputTrue, textTrue, timeoutduration 5) return json.loads(result.stdout) # 每 10 秒轮询一次记录时间戳 if __name__ __main__: url rtsp://user:pass192.168.1.64:554/Streaming/Channels/101 while True: data probe_stream(url) ts time.strftime(%Y-%m-%d %H:%M:%S) print(ts, json.dumps(data, ensure_asciiFalse)) time.sleep(10)这段代码的逻辑很直白ffprobe以 TCP 方式连流采样 5 秒后输出 JSON脚本每 10 秒跑一次。参数上-rtsp_transport tcp是关键UDP 在丢包时会让码率统计失真-t控制采样窗口太短会受关键帧影响太长则告警不及时5 到 10 秒是比较稳的区间。avg_frame_rate和bit_rate是判断流是否正常的两个核心字段。2.3 平台内嵌采集模块适合已有监控系统的二次开发如果你手上已经有监控平台最干净的做法是在流接入层加一个采集模块。比如用 GStreamer 的identity元素或pad probe在数据管道里直接读 buffer 的 PTS 和大小按秒聚合。这种形态精度最高能拿到每一帧的时间戳适合做抖动和卡顿的精细分析。选型上我的建议是验证阶段用浏览器扩展批量监控用 FFmpeg 脚本要长期稳定运行且平台可控就做内嵌模块。三者不冲突可以叠着用。3. 用 FFmpeg 和 Python 搭一套可复现的流速监控3.1 环境准备与最小依赖这套方案只需要 Python 3.8 以上和 FFmpeg 4.2 以上不需要额外装重量级库。FFmpeg 建议用系统包管理器装Windows 上直接下静态构建包把bin目录加进 PATH。验证命令ffmpeg -version ffprobe -version python --version三条都能正常输出版本号即可。注意ffprobe和ffmpeg要来自同一套构建版本不一致时 JSON 字段偶尔会对不上。3.2 采集脚本把码率、帧率、关键帧间隔打点上一章的probe_stream只拿了瞬时值实际监控需要按时间窗口聚合。下面这个版本把每次采样结果写进 SQLite方便后续查曲线和做告警。import subprocess import json import time import sqlite3 DB stream_metrics.db def init_db(): conn sqlite3.connect(DB) conn.execute( CREATE TABLE IF NOT EXISTS metrics ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts TEXT, stream_url TEXT, bit_rate INTEGER, frame_rate REAL, keyframe_interval REAL ) ) conn.commit() return conn def probe(rtsp_url, duration5): cmd [ ffprobe, -v, quiet, -rtsp_transport, tcp, -select_streams, v:0, # 只看第一路视频 -show_entries, streamavg_frame_rate,bit_rate, -show_entries, framepkt_pts_time,key_frame, -of, json, -t, str(duration), rtsp_url ] r subprocess.run(cmd, capture_outputTrue, textTrue, timeoutduration 8) return json.loads(r.stdout) def parse_keyframe_interval(data): # 从帧列表里算相邻关键帧的时间差 frames data.get(frames, []) kf_times [float(f[pkt_pts_time]) for f in frames if f.get(key_frame) 1] if len(kf_times) 2: return 0.0 return sum(kf_times[i1] - kf_times[i] for i in range(len(kf_times)-1)) / (len(kf_times)-1) if __name__ __main__: conn init_db() url rtsp://user:pass192.168.1.64:554/Streaming/Channels/101 while True: data probe(url) stream data.get(streams, [{}])[0] br int(stream.get(bit_rate, 0)) fr_str stream.get(avg_frame_rate, 0/1) num, den fr_str.split(/) fr float(num) / float(den) if float(den) else 0.0 kfi parse_keyframe_interval(data) conn.execute( INSERT INTO metrics (ts, stream_url, bit_rate, frame_rate, keyframe_interval) VALUES (?,?,?,?,?), (time.strftime(%Y-%m-%d %H:%M:%S), url, br, fr, kfi) ) conn.commit() time.sleep(10)逻辑说明-select_streams v:0避免音频流干扰码率统计-show_entries frame...会输出每一帧的信息帧多时 JSON 会比较大所以采样窗口别超过 10 秒。parse_keyframe_interval算的是平均关键帧间隔正常监控流一般是 1 到 4 秒超过 6 秒就要留意可能是编码器 GOP 设得太大会导致随机访问慢、卡顿恢复时间长。参数上bit_rate是 ffprobe 根据流信息估算的不是精确值但趋势足够用。要更准可以用-show_entries formatbit_rate拿容器层码率两者对比着看。3.3 告警规则三个必须设的阈值采集只是第一步能告警才有用。我一般设三条规则指标阈值含义码率偏离基线超过基线 ±40% 持续 30 秒编码异常或场景剧变帧率下降低于标称帧率 80% 持续 20 秒采集或网络丢帧关键帧间隔大于 6 秒GOP 配置不合理基线怎么来跑一周正常数据取每路流同时段的中位数。别用平均值监控场景里白天和夜间的码率差异很大平均值会被拉偏。3.4 把结果接到现有监控平台SQLite 适合单机验证路数多了要换成时序库。常见做法是写 InfluxDB 或 Prometheus再用 Grafana 出图。如果你用的是交通监控视频的多目标车辆检测系统可以把流速指标和检测结果关联起来——比如某路流码率骤降时检测框数量往往也会异常两个信号一起看定位问题快很多。4. 流速监控插件避坑五条血泪经验4.1 用 UDP 统计码率数字全是假的现象脚本跑出来的码率忽高忽低和实际画面质量对不上。原因RTSP 默认走 UDP丢包时 ffprobe 拿到的字节数会偏少而且丢包重传的帧不计入统计自然失真。解决强制-rtsp_transport tcp。TCP 下码率统计和实际传输基本一致代价是延迟略高但监控场景可接受。4.2 采样窗口太短关键帧一出现就误报现象告警频繁触发但回看录像画面正常。原因关键帧比普通帧大好几倍如果采样窗口只有 1 到 2 秒正好卡在关键帧上码率会瞬间冲高。解决采样窗口至少 5 秒最好 10 秒并且用窗口内的中位数而不是峰值做判断。4.3 只看总带宽漏掉单路异常现象总出口流量正常但某一路就是卡。原因多路流共享带宽时一路码率暴涨会被其他路的下降抵消总量看起来平稳。解决必须按流单独打点别偷懒只看聚合值。这也是「流速监控」和普通带宽监控的本质区别。4.4 ffprobe 进程不回收跑几天就卡死现象脚本运行一两天后无响应系统进程列表里一堆 ffprobe。原因流中断时 ffprobe 可能挂住不退出subprocess.run的 timeout 没设或设得太长。解决给每次调用设timeout并在异常时kill进程。上面代码里的timeoutduration 8就是干这个的别省。4.5 关键帧间隔算成 0其实是采样里没有关键帧现象keyframe_interval一直是 0。原因采样窗口内恰好没有关键帧或者-show_entries没带上frame字段。解决确认命令里有framepkt_pts_time,key_frame并且采样窗口大于一个 GOP。如果流本身 GOP 就是 8 秒窗口至少给 10 秒。5. 进阶把流速指标和画面质量关联起来到这一步你已经能稳定采集和告警了。但流速监控真正的价值是能回答「这路流现在能不能用」。我后来加了一个小技巧在采集脚本里同时抽一帧画面算它的清晰度拉普拉斯方差和码率、帧率放一起看。import cv2 import numpy as np def frame_sharpness(rtsp_url): cap cv2.VideoCapture(rtsp_url) ret, frame cap.read() cap.release() if not ret: return 0.0 gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) return cv2.Laplacian(gray, cv2.CV_64F).var()逻辑很简单读一帧转灰度算拉普拉斯方差。值越低画面越糊。把这三个指标放一张图上看规律很明显——码率正常但清晰度骤降多半是镜头脏了或对焦跑了码率和清晰度一起掉才是传输或编码的问题。这个区分能省掉大量现场排查时间。参数上拉普拉斯方差没有绝对阈值不同场景差异大建议对每路流单独记录一周基线取基线的一半作为告警线。另外cv2.VideoCapture打开 RTSP 时也可能挂住记得加超时或放到独立线程里跑。我自己现在的习惯是新接一路流先跑三天只采集不告警把基线摸清楚再开规则。流速监控这事急不得基线不准后面全是玄学告警。希望帮到你。本文还有配套的精品资源点击获取
