监控录像逐帧取证
深夜便利店发生争执,监控回放中关键动作只持续了不到半秒。以往需要反复暂停、肉眼估算时间点,提交给警方的证据片段缺乏精确的时序标注。使用本工具对监控片段叠加帧号和时间戳,能精确到毫秒级标记出推搡发生的第 1473 帧,让执法记录仪与店内监控的时间线严丝合缝,避免因时间表述模糊导致证据被质疑。
剪辑师导出样片前,总得给审片方标清每一帧的时间位置——手动逐帧打码,一集片子能磨掉半小时。输入视频,它用 FFmpeg 在服务端逐帧解析时间码,按需求叠加成 H:M:S 格式的时间戳、持续计时水印或帧序号,输出一个带标记的新文件。不上传原始素材到第三方存储,处理完即删。
深夜便利店发生争执,监控回放中关键动作只持续了不到半秒。以往需要反复暂停、肉眼估算时间点,提交给警方的证据片段缺乏精确的时序标注。使用本工具对监控片段叠加帧号和时间戳,能精确到毫秒级标记出推搡发生的第 1473 帧,让执法记录仪与店内监控的时间线严丝合缝,避免因时间表述模糊导致证据被质疑。
青少年篮球训练中,教练发现队员投篮出手瞬间的肘部角度总是不对。用手机拍摄慢动作视频后,需要向队员说明“起跳后第 12 帧开始压腕”这类精确指令。本工具在视频画面上叠加逐帧计数,教练可以直接圈出第 8 到第 15 帧的肘部位置,队员对照帧号回看自己的动作,比“你出手太晚了”这种模糊指导有效得多。
产品评审会录了 90 分钟,会后要整理出三个功能点的决策时刻。以往需要手动拖动进度条反复听,或依赖会议软件的自动纪要(经常识别错发言人)。用本工具给录播视频叠加实时水印时间戳,记录者只需在听到关键决策时记下屏幕上的时间(如 00:23:15),后续剪辑时直接跳转到该时间点截取片段,比听写全文节省 70% 的整理时间。
生物实验室要求记录每次 PCR 仪启动的精确时间,以及每个加样步骤的耗时。实验员戴着手套操作,不方便用手机记笔记。将实验台顶置摄像头的画面通过本工具叠加实时计时水印,启动仪器时画面显示 09:32:00,加样完成时显示 09:34:17。后续写实验记录时直接回读水印时间,无需额外计时器,也避免了手写记录时因看表分心导致的加样失误。
自媒体创作者做音乐混剪,需要让画面切换精准踩在鼓点上。在剪辑软件里对音频波形找拍子很耗时,尤其遇到变速段落。把素材先导入本工具,叠加帧号和时间戳后,在播放时用肉眼观察画面变化时刻对应的帧号(如转场发生在第 240 帧),再回到剪辑时间线上直接输入帧号进行切割,比反复拖动预览条精准度更高,且不依赖任何剪辑软件的特定功能。
| 输入 | 输出 | 说明 |
|---|---|---|
| 00:01:30.500 → 叠加时间戳水印(格式:HH:MM:SS.fff) | 视频画面左上角显示「00:01:30.500」 | 常规:带毫秒的完整时间戳,验证毫秒精度保留与显示格式 |
| 00:00:00.000 → 叠加时间戳水印 | 视频画面左上角显示「00:00:00.000」 | 边界:起始帧零时刻,验证零值正确处理(不会显示空白或报错) |
| 23:59:59.999 → 叠加时间戳水印 | 视频画面左上角显示「23:59:59.999」 | 边界:一天内最大时间值,验证进位不溢出(不会变成 24:00:00.000) |
| 00:01:30 → 叠加计时水印(格式:MM:SS,从 00:00 开始累加) | 视频画面左上角显示「01:30」 | 易错:用户常混淆「时间戳」与「计时器」,此例明确计时器从零开始累加,而非绝对时间 |
| 视频帧率 25fps,在 00:00:02.040 处叠加帧号 | 视频画面左上角显示「Frame: 51」(2.040s × 25fps = 51 帧,帧号从 0 开始) | 易错:帧号计算依赖帧率输入,且帧号从 0 开始计数,用户容易误认为从 1 开始 |
| 00:00:00.001 → 叠加时间戳水印(格式:HH:MM:SS.fff) | 视频画面左上角显示「00:00:00.001」 | 边界:最小非零毫秒值,验证毫秒精度不会因舍入丢失(不会显示 00:00:00.000) |
| 视频时长 3 秒,帧率 30fps,叠加帧号从 0 到 89 | 视频画面依次显示 Frame: 0, 1, 2, …, 89(共 90 帧) | 常规:完整帧号序列覆盖,验证工具能处理短时长高帧率视频的逐帧输出 |
| 00:01:30.500 → 叠加帧号(帧率 23.976fps) | 视频画面左上角显示「Frame: 2161」(90.5s × 23.976fps ≈ 2160.9,向下取整得 2161) | 易错:非整数帧率(23.976)导致帧号计算有小数截断差异,用户需注意工具采用向下取整而非四舍五入 |
1.时间码格式混用,FFmpeg 解析失败
00:01:30:12(冒号分隔帧号)00:01:30.12(点号分隔帧号)或 00:01:30;12(分号分隔帧号)FFmpeg 严格遵循 SMPTE 标准:时:分:秒.帧 或 时:分:秒;帧。冒号后跟帧号会被解析为无效时间码,导致叠加位置错乱或报错。
2.帧率参数与视频实际帧率不匹配
设置 -r 30 但视频是 29.97fps先通过 ffprobe -v error -select_streams v:0 -show_entries stream=r_frame_rate 获取实际帧率,再传入对应值帧率不匹配时,时间码与视频帧的对应关系会逐帧累积偏移,30 分钟后误差可达几十帧。29.97 与 30 的差异来自 NTSC 彩色电视标准。
3.叠加水印时未考虑视频像素格式
drawtext 滤镜直接叠加在 yuv420p10le 视频上先加滤镜 format=yuv420p 或使用 'drawtext=fontfile=...:text=%{pts\:hms}:fontsize=24:fontcolor=white:x=10:y=10:box=1:boxcolor=black@0.5'10-bit 像素格式(yuv420p10le)下,部分 FFmpeg 构建的 drawtext 滤镜不支持直接渲染,需先降级为 8-bit 或使用 libfreetype 编译版本。
4.帧号偏移量设置错误
想要从第 100 帧开始显示,设置 frame_offset=100使用 'drawtext=text=%{frame_num}:start_number=100' 或通过 setpts=PTS-100/FPS 调整时间戳frame_offset 是 FFmpeg 的输入选项,控制从哪一帧开始解码,而非水印显示的起始帧号。drawtext 的 %{frame_num} 从 0 开始计数,需用 start_number 参数偏移。
5.计时水印的字体路径在服务端不存在
fontfile=C:\Windows\Fonts\Arial.ttf(Windows 路径)fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf(Linux 路径)或使用 fontconfig 名称 font=DejaVu-Sans工具后端运行在 Linux 容器中,Windows 字体路径无效。应使用容器内预装字体或通过 fontconfig 系统字体名称引用,否则 drawtext 滤镜静默失败。
6.时间码位置超出视频边界被裁剪
设置 x=1920-10,y=1080-10 想放在右下角x=w-tw-10:y=h-th-10(tw/th 是文本宽高,w/h 是视频宽高)FFmpeg 的 drawtext 坐标是文本左上角位置,直接写像素坐标会导致文本超出画面被裁剪。使用 w-tw 和 h-th 表达式让文本右下角与画面右下角对齐。
7.叠加多个时间戳时未考虑滤镜链顺序
ffmpeg -i input.mp4 -vf "drawtext=text='%{pts\:hms}':x=10:y=10,drawtext=text='%{frame_num}':x=10:y=30" output.mp4在一个 drawtext 滤镜中用多行文本:drawtext=text='%{pts\:hms}\n%{frame_num}':line_spacing=10:x=10:y=10多个 drawtext 滤镜串联会生成中间帧,增加编解码开销且可能引入色彩精度损失。用 \n 换行符合并为单滤镜,性能更好且保证像素格式一致。
时间码帧号 = 帧率 × (小时×3600 + 分钟×60 + 秒) + 帧偏移
帧率视频每秒帧数,如 25、30小时时间码中的小时部分分钟时间码中的分钟部分秒时间码中的秒部分帧偏移当前秒内的帧序号,从 0 开始25fps 视频,时间码 01:23:45:12(时:分:秒:帧):帧号 = 25×(1×3600 + 23×60 + 45) + 12 = 25×(3600 + 1380 + 45) + 12 = 25×5025 + 12 = 125625 + 12 = 125637。该帧为视频的第 125637 帧。
隐私保证所有计算与处理均在你的浏览器本地完成,输入数据不会上传服务器,也不会保存或共享。