视频自动化处理全链路：从下载到合成的命令行工作流-平芜编程栈

1. 项目概述：一个围绕视频处理全链路的实用型工具集命名逻辑

“video-use”这个名称乍看像随手打的变量名，但放在当前技术语境下，它其实是一条隐性线索——指向一套以视频为输入源、以自动化处理为核心目标、以开源工具链为执行载体的轻量级工作流。它不是某个具体软件，也不是某家公司的产品代号，而是开发者在日常实践中反复打磨出的一套“视频即数据”的操作范式。我第一次看到这个词是在一个 GitHub 仓库的 README 里，作者没写任何功能说明，只在标题栏写了 video-use，点进去才发现里面塞了 17 个 shell 脚本、3 个 Python 封装模块、2 套配置模板，以及一份手写的why-this-name.md。那篇文章里有一句话我记到现在：“video-use 不是名词，是动词短语——video use，视频被用起来的过程。”

这个命名背后藏着三重现实需求：第一，下载即用——从 YouTube、Bilibili 等平台批量抓取原始视频素材，不依赖网页端、不卡在登录态、不被限速；第二，裁剪即编排——对下载后的视频做无损切片、区域抠取、格式归一、字幕嵌入等预处理，为后续配音、转录、训练或发布做准备；第三，合成即交付——把语音合成（如 ElevenLabs）、字幕渲染、画质增强、推流封装等环节串成流水线，让一段原始视频在 5 分钟内变成可发布的成品。它解决的不是“能不能做”，而是“要不要重复点 8 次鼠标、敲 23 行命令、查 5 次文档”。

关键词里出现的 ffmpeg、yt-dlp、ElevenLabs 和 EDL，恰好构成这条链路的四大支柱：yt-dlp 是入口守门人，负责稳、准、快地把视频“请进来”；ffmpeg 是中枢调度员，干所有脏活累活——转码、抽帧、加水印、拼接、降噪、推流；ElevenLabs 是声音引擎，把文字变成有情绪、有节奏、带停顿的真实人声；EDL（Edit Decision List）则是隐形指挥棒，用纯文本描述剪辑决策，让整个流程脱离 GUI 软件、脱离时间轴拖拽、脱离鼠标依赖，真正实现“配置即剪辑”。这四者组合起来，就是 video-use 的真实骨架。它适合三类人：内容创作者需要批量处理口播素材，AI 工程师需要构造高质量训练视频集，本地化团队要为多语种视频快速生成配音版本。你不需要会写 C++，但得懂命令行参数怎么传、JSON 怎么嵌套、时间码怎么算——这些才是 video-use 真正的门槛，而不是“会不会安装”。

2. 核心工具链选型与协同逻辑：为什么是这四个，而不是别的

2.1 yt-dlp：下载层的不可替代性

很多人问：为什么不用 youtube-dl？答案很直接——它已停止维护，而 yt-dlp 是其活跃分支，且做了三类关键升级：协议兼容性、反爬鲁棒性、输出结构化。我做过对比测试：同一组 42 个 YouTube 链接，在 youtube-dl v2021.06.06 下载失败率 38%，而在 yt-dlp v2024.07.16 下仅为 2.4%。失败原因集中在两处：一是新版 YouTube 启用了更严格的 signature 混淆机制，yt-dlp 内置了动态解混淆引擎，能实时解析 JS 中的加密函数；二是部分频道启用了会员专属内容墙，yt-dlp 支持 cookie 注入和 session 复用，只要浏览器登录态有效，就能绕过前端鉴权。

更重要的是，yt-dlp 的输出控制粒度远超前辈。比如你想下载 1080p 无字幕版，但某些视频只有 720p+CC 字幕可用，传统方案只能二选一。yt-dlp 可以这样写：

yt-dlp -f "best[height<=1080][vcodec!=av01]/best" \ --write-subs --sub-lang en --sub-format vtt \ --convert-subs srt \ https://youtu.be/xxx

这段命令的意思是：优先选最高质量的 1080p 以下视频（排除 av01 编码，因部分播放器不支持），同时强制下载英文 WebVTT 字幕，并自动转成 SRT 格式。这种“条件式择优”能力，是 video-use 流程能自动化的前提。它不靠猜，靠声明式规则。

提示：不要用--all-subs，它会拉下所有语言字幕，导致后续处理时文件名冲突。固定指定--sub-lang并配合--sub-format才是生产环境做法。

2.2 ffmpeg：视频处理层的“瑞士军刀”本质

ffmpeg 常被误认为只是个“转格式工具”，但它真正的价值在于原子化操作能力——每个命令对应一个独立、可验证、可复现的媒体操作单元。video-use 中 83% 的核心步骤都由 ffmpeg 完成，但绝不是简单调用ffmpeg -i in.mp4 -c:v libx264 out.mp4。我们拆几个典型场景：

区域截取（ROI cropping）：不是裁掉黑边，而是精准抠出画面中某个人脸区域。命令如下：
```
ffmpeg -i input.mp4 -vf "crop=w=640:h=480:x=320:y=180" -c:a copy output.mp4
```
这里x/y是左上角坐标，w/h是宽高，单位是像素。关键点在于：-c:a copy表示音频流不做重编码，直接复制，避免音画不同步。实测发现，若省略此参数，ffmpeg 默认会对音频重采样，导致 0.3 秒级偏移——这对配音合成是致命伤。
M3U8 转 MP4 的无损封装：很多教程教用-c copy直接 mux，但实际会失败。原因在于 HLS 分片的 PTS（Presentation Time Stamp）常有跳变，直接 copy 会导致播放器解码错误。正确做法是先用-vsync 0强制丢帧同步，再用-avoid_negative_ts make_zero重置时间戳：
```
ffmpeg -i playlist.m3u8 -c copy -vsync 0 -avoid_negative_ts make_zero output.mp4
```
推流到 SRS 的低延迟调优：热词里提到“存在延迟”，根源不在 ffmpeg，而在 RTMP 协议本身。标准 RTMP 推流默认启用flv封装，其 keyframe interval（关键帧间隔）通常为 2 秒，加上网络缓冲，端到端延迟常达 5~8 秒。video-use 的解法是改用hls封装 + 自定义 segment 时间：
```
ffmpeg -re -i input.mp4 \ -c:v libx264 -b:v 1000k -g 60 -keyint_min 60 \ -c:a aac -b:a 128k \ -f hls -hls_time 2 -hls_list_size 3 -hls_flags delete_segments \ rtmp://srs-server/live/stream
```
这里-g 60和-keyint_min 60强制 GOP 长度为 60 帧（2 秒），-hls_time 2让每个 TS 片段正好 2 秒，配合 SRS 的hls_fragment参数，可将首屏延迟压到 2.3 秒以内。

2.3 ElevenLabs：语音合成层的工程化接入

ElevenLabs 不是唯一选择，但它是目前少数能把“情感控制”做到 CLI 可调的 API 服务。video-use 中它不直接生成.wav，而是通过curl+jq封装成管道命令，与 ffmpeg 无缝衔接。例如，把字幕文本转语音并混入原视频：

cat subtitles.srt | \ jq -r 'select(.text != "") | "\(.start) \(.end) \(.text)"' | \ while read start end text; do echo "$text" | \ curl -s -X POST "https://api.elevenlabs.io/v1/text-to-speech/{voice_id}" \ -H "xi-api-key: $API_KEY" \ -H "Content-Type: application/json" \ -d "{\"text\":\"$text\",\"model_id\":\"eleven_multilingual_v2\",\"voice_settings\":{\"stability\":0.5,\"similarity_boost\":0.75}}" \ > "/tmp/$(printf "%09d" $(echo "$start" | awk -F':' '{print $1*3600+$2*60+$3*1000}' | cut -d'.' -f1)).wav" done

这段脚本的关键在于：用jq解析 SRT 时间戳，转换为毫秒整数作为文件名前缀，确保语音片段能按时间顺序排列。后续用 ffmpeg 按文件名排序合并：

ffmpeg -f concat -safe 0 -i <(for f in /tmp/*.wav; do echo "file '$f'"; done | sort) -c:a aac -b:a 128k audio.m4a

这样做的好处是：避免一次性请求长文本导致超时，支持断点续合，且每段语音可单独调试音色参数。

注意：ElevenLabs 的stability参数控制发音稳定性（0.0 最机械，1.0 最自然），similarity_boost控制音色保真度（0.0 易失真，1.0 易卡顿）。实测 0.5/0.75 是中文播报的黄金组合，比默认值 0.3/0.75 更清晰。

2.4 EDL：剪辑决策层的文本化表达

EDL（Edit Decision List）是广播级剪辑的标准交换格式，但 video-use 对它做了极简主义改造：只保留EDIT_NUMBER,REEL,SOURCE_START,SOURCE_END,RECORD_START,RECORD_END六列，用空格分隔，去掉所有注释和元数据。例如：

001 V001 00:01:23:15 00:01:27:03 00:00:00:00 00:00:00:00 002 V001 00:01:35:10 00:01:42:18 00:00:00:00 00:00:00:00

这个文件的意义在于：它把“剪哪几段、从哪到哪”这个操作，从时间轴拖拽变成了文本编辑。video-use 的核心脚本edl-apply.sh会读取该文件，逐行生成 ffmpeg 命令：

while read edit reel src_start src_end rec_start rec_end; do ffmpeg -ss "$src_start" -to "$src_end" -i "$reel".mp4 \ -c copy -avoid_negative_ts make_zero \ "clip_${edit}.mp4" done < edits.edl

为什么不用 GUI 剪辑软件？因为 GUI 无法批量处理 200 条视频；GUI 无法用 Git 管理剪辑版本；GUI 无法把“第 3 段删掉 2 秒静音”这种需求写成一行 diff。EDL 把剪辑变成了可编程、可审查、可回滚的操作。

3. 实操全流程拆解：从 URL 到成品视频的 7 步闭环

3.1 第一步：环境初始化与依赖校验

video-use 不要求全新系统，但必须满足三个硬性条件：Python 3.9+、ffmpeg 6.0+、curl 支持 HTTP/2。我见过太多人在 Ubuntu 上用apt install ffmpeg装到 4.4 版本，结果libsvtav1编码器缺失，导致 AV1 转码失败。正确做法是：

Linux（Ubuntu/Debian）：

sudo apt remove ffmpeg && sudo apt autoremove sudo apt install wget gnupg2 curl wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-git-amd64-static.tar.xz tar -xf ffmpeg-git-amd64-static.tar.xz sudo mv ffmpeg-git-*/ffmpeg /usr/local/bin/ sudo chmod +x /usr/local/bin/ffmpeg

macOS（Intel/M1）：

brew uninstall ffmpeg && brew tap-new homebrew-ffmpeg/ffmpeg brew install homebrew-ffmpeg/ffmpeg/ffmpeg --with-libsvtav1 --with-librav1e

Windows：
下载ffmpeg-master-latest-win64-gpl.zip（注意是 gpl 版，含 x264/x265），解压后把bin目录加入 PATH。别用“免解压版”，它缺少ffprobe，而 video-use 的质检脚本重度依赖 ffprobe 获取码率、帧率、色彩空间。

校验命令：

ffmpeg -version | head -n1 # 必须显示 git-hash 或 version 6.x yt-dlp --version # 必须 ≥ 2024.04.09 curl --version | grep HTTP2 # 必须含 HTTP/2 支持

实操心得：Windows 用户常卡在ffmpeg not recognized，根本原因是 PowerShell 默认禁用脚本执行策略。运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser即可，无需管理员权限。

3.2 第二步：URL 批量采集与元数据提取

video-use 的采集不是单链接下载，而是基于 CSV 的批量作业。CSV 格式为：

url,title,channel,lang,subs_lang https://youtu.be/abc123,How to Use FFmpeg,FFmpeg Tutorials,en,en https://www.bilibili.com/video/BV1xx411x7xx,FFmpeg 编译指南,音视频开发,zn,zh-CN

主脚本batch-download.py会读取 CSV，为每行生成独立下载目录，并注入元数据 JSON：

import yt_dlp ydl_opts = { 'outtmpl': '%(uploader)s/%(title)s/%(id)s.%(ext)s', 'writethumbnail': True, 'writeinfojson': True, 'subtitleslangs': [row['subs_lang']], 'writesubtitles': True, 'convertsubtitles': 'srt', 'postprocessors': [{ 'key': 'FFmpegSubtitlesConvertor', 'format': 'srt' }] }

关键点在于writeinfojson：它生成video_id.info.json，包含上传时间、时长、分辨率、帧率等全部信息。video-use 后续所有操作（如 GOP 计算、码率匹配）都从此 JSON 读取，而非靠ffprobe临时探测——因为探测耗时，而 JSON 是秒级读取。

3.3 第三步：智能格式归一与质量质检

下载完成后，进入normalize/目录执行quality-check.sh。它不做粗暴转码，而是分三步决策：

码率分析：用ffprobe -v quiet -show_entries stream=bit_rate -of csv=p=0 input.mp4获取视频流码率。若低于 1500k，则判定为低质源，跳过后续增强；
色彩空间校验：ffprobe -v quiet -show_entries stream=color_space -of csv=p=0 input.mp4。若返回bt709，则保持；若为smpte170m（老式 NTSC），则插入-vf colormatrix=smpte170m:bt709转换；
音频标准化：用ffmpeg -i input.mp4 -af loudnorm=I=-16:LRA=11:TP=-1.5 -c:a aac -b:a 128k norm.mp4执行 EBU R128 标准响度归一，确保所有视频音量一致。

质检报告生成为report.html，含缩略图、码率曲线、音频波形图。不合格项标红，如“色域不匹配”“音频峰值超限”，点击即可跳转到对应修复命令。

3.4 第四步：EDL 驱动的无损剪辑

EDL 文件cuts.edl由人工编写或从 Premiere 导出（需用edl-converter.py转换为 video-use 格式）。执行edl-cut.sh cuts.edl后，脚本会：

检查每行时间码是否合法（src_start < src_end，且不超过源视频时长）；
用ffmpeg -ss START -to END -i src.mp4 -c copy无损切片；
对每个切片运行ffprobe -v quiet -show_entries format=duration -of csv=p=0获取真实时长，写入clip_001.meta；
最终生成clips/目录，含clip_001.mp4,clip_001.meta,clip_001.jpg（首帧缩略图）。

这里的关键是-c copy：它不重编码，只复制关键帧之间的数据包，速度是重编码的 20 倍以上。但前提是源视频 GOP 结构规整。若遇到Non-monotonous DTS错误，说明源视频时间戳混乱，此时自动 fallback 到-c:v libx264 -crf 18重编码，但会记录日志告警。

3.5 第五步：字幕驱动的语音合成与对齐

SRT 文件经srt-align.py处理，做三件事：

清洗：删除空行、合并过短句（<0.8 秒）、拆分过长句（>6 秒）；
标准化：统一时间码格式为HH:MM:SS,mmm，补零对齐；
语义分段：用 spaCy 中文模型识别句末标点，确保每行 SRT 对应完整语义单元。

然后调用 ElevenLabs API，生成.wav文件。难点在于时间对齐：API 返回的语音时长 ≠ SRT 原有时长。video-use 用sox计算实际时长：

sox clip_001.wav -n stat 2>&1 | grep "Length (seconds)" | awk '{print $3}'

若偏差 >0.3 秒，则用ffmpeg -i clip_001.wav -af atempo=1.05微调语速，目标是让语音时长 = SRT 时长 × 0.98（预留 2% 静音缓冲）。

3.6 第六步：多轨合成与画质增强

合成脚本mix.sh接收clips/和audio/目录，生成最终视频：

ffmpeg -i "concat:clip_001.mp4|clip_002.mp4|clip_003.mp4" \ -i "concat:audio_001.wav|audio_002.wav|audio_003.wav" \ -filter_complex "[0:v]scale=1280:-2:flags=lanczos,unsharp=3:3:0.8[v]; \ [v]drawtext=fontfile=/path/font.ttf:fontsize=24:fontcolor=white:x=20:y=20:text='©2024'[outv]" \ -map "[outv]" -map 1:a -c:v libx264 -crf 20 -preset slow \ -c:a aac -b:a 128k -ar 44100 \ final.mp4

其中scale=1280:-2表示宽度固定 1280，高度自适应（保持比例）；unsharp=3:3:0.8是锐化参数，实测对 1080p 源最友好；drawtext添加版权水印，字体路径必须绝对路径，否则 ffmpeg 找不到。

实操心得：-preset slow比medium多花 3.2 倍时间，但 CRF 20 下体积小 18%，且细节更锐利。对于发布用视频，值得。

3.7 第七步：交付包打包与校验

最终输出deliver/目录，含：

final.mp4（主视频）
final.srt（嵌入式字幕，用ffmpeg -i final.mp4 -c copy -c:s mov_text final-with-subs.mp4生成）
final.webm（VP9 编码，供网页嵌入）
checksums.sha256（所有文件 SHA256 值）

校验脚本verify-deliver.sh会：

用ffprobe -v quiet -show_entries format=duration -of csv=p=0 final.mp4检查时长是否等于所有 EDL 片段时长之和；
用mediainfo --Output="Video;%Duration%" final.mp4交叉验证；
用ffplay -v 0 -showmode 0 -autoexit -nodisp final.mp4静默播放，检测是否卡顿或报错。

只有全部通过，才标记deliver/为READY。否则生成failures.log，记录具体失败项。

4. 常见问题与排查技巧实录：踩过的坑比文档还厚

4.1 yt-dlp 下载中断后如何续传？

现象：下载大视频（>2GB）时网络抖动，yt-dlp 报ERROR: unable to download video data: <urlopen error [Errno 104] Connection reset by peer>，重跑命令却从头开始。

根因：yt-dlp 默认不启用断点续传，因为 HTTP Range 请求需服务端支持，而 YouTube 的分片地址是动态签发的。

解法：启用--downloader aria2c并配置 aria2c 支持断点：

# 安装 aria2c sudo apt install aria2 # Linux brew install aria2 # macOS # 创建 ~/.aria2/aria2.conf continue=true max-connection-per-server=16 split=16

然后运行：

yt-dlp --downloader aria2c --downloader-args "aria2c:-x 16 -s 16 -k 1M" URL

-x 16表示最多 16 个连接，-s 16表示分 16 段下载，-k 1M表示每段 1MB。实测 2GB 视频中断后 3 秒内恢复，进度不丢失。

4.2 ffmpeg 截取区域时画面错位？

现象：用crop=w=640:h=480:x=320:y=180截取，结果人物脸被切掉一半。

根因：ffmpeg 的crop滤镜坐标系基于原始分辨率，而非显示分辨率。若源视频是 1920x1080，但实际画面有黑边（如 1920x800 内容区），x=320,y=180是从左上角（0,0）算起，而内容区左上角可能是（0,140）。

解法：先用ffprobe -v quiet -show_entries stream=width,height -of csv=p=0 input.mp4获取原始宽高；再用ffprobe -v quiet -show_entries stream_tags=rotate -of csv=p=0 input.mp4检查旋转；最后用ffmpeg -i input.mp4 -vf "cropdetect=24:16:0" -f null -自动探测有效区域。输出类似：

[Parsed_cropdetect_0 @ 0x...] x1:0 x2:1919 y1:140 y2:939 w:1920 h:799 x:0 y:140

取x:0 y:140作为 crop 坐标偏移，再计算真实 ROI：

# 原始 ROI: x=320 y=180 w=640 h=480 # 加上偏移: x=320+0=320 y=180+140=320 ffmpeg -i input.mp4 -vf "crop=w=640:h=480:x=320:y=320" ...

4.3 ElevenLabs 语音合成后音画不同步？

现象：合成语音时长 12.3 秒，但 SRT 要求 12.0 秒，混音后口型对不上。

根因：ElevenLabs 的语音生成受文本长度、标点、模型版本影响，时长非精确可控。

解法：采用“语音驱动视频”策略，而非“视频驱动语音”。步骤：

先用ffmpeg -i input.mp4 -vf fps=1/10 -q:v 2 %04d.jpg抽帧（每 10 秒一帧）；
用whisper.cpp本地转录，生成精准时间戳 SRT；
用此 SRT 调用 ElevenLabs，确保语音严格对齐；
最后用ffmpeg -i input.mp4 -i audio.wav -filter_complex "[1:a]adelay=12300|12300[a];[0:a][a]amix=inputs=2:duration=first" -c:v copy output.mp4做毫秒级音频延迟补偿。

adelay=12300|12300表示左右声道均延迟 12.3 秒，单位是毫秒。

4.4 EDL 时间码格式错误导致切片失败？

现象：edl-cut.sh报错Invalid time format: 00:01:23:15。

根因：EDL 标准时间码格式为HH:MM:SS:FF（时:分:秒:帧），但很多工具导出为HH:MM:SS.mmm（毫秒）。video-use 严格遵循 SMPTE EDL 标准，帧率必须明确。

解法：统一转换为帧率基准。假设源视频为 30fps：

# 将 00:01:23:15 → 00:01:23;15（分号分隔，表示帧） # 或用 awk 转换毫秒：00:01:23.150 → 00:01:23:04（150ms ≈ 4 帧 @30fps） awk -F'[:.]' '{ h=$1; m=$2; s=$3; ms=$4; total_ms = h*3600000 + m*60000 + s*1000 + ms; frames = int(total_ms * 30 / 1000); ss = int(frames / 30 % 60); mm = int(frames / 1800 % 60); hh = int(frames / 108000); ff = frames % 30; printf "%02d:%02d:%02d:%02d\n", hh, mm, ss, ff; }' time.txt

4.5 ffmpeg 推流到 SRS 延迟突增？

现象：推流正常，但观看端延迟从 2 秒跳到 15 秒，持续 30 秒后恢复。

根因：SRS 默认启用mr（Merge Read）模式，当客户端拉流速度慢于推流速度时，SRS 会缓存数据，导致累积延迟。

解法：修改 SRS 配置srs.conf：

vhost __defaultVhost__ { cluster { mode local; } http_remux { enabled on; mount [vhost]/http; } rtc { enabled on; bps_limit 1000000; } # 关键：禁用 mr，改用 pure forward mr { enabled off; } }

重启 SRS 后，延迟稳定在 2.1±0.3 秒。实测mr off对 CPU 占用影响 <5%，但延迟一致性提升 92%。

5. 工具链深度优化：让 video-use 从能用到好用

5.1 yt-dlp 配置文件的隐藏能力

yt-dlp 支持~/.config/yt-dlp/config全局配置，但多数人只用-f参数。video-use 的 config 文件含 12 项关键设置：

# 优先使用 dash/mp4，避免 hls/m3u8（易断） -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" # 自动重试，但限制总次数 --retries 3 --fragment-retries 5 # 下载时并发 4 个连接（防限速） --concurrent-fragments 4 # 禁用自动更新检查（避免干扰 CI） --no-update # 输出 JSON 元数据时精简字段 --write-info-json --parse-metadata "uploader:%(uploader)s" --parse-metadata "upload_date:%(upload_date)s" # cookie 注入路径（用于会员内容） --cookies-from-browser chrome

特别注意--cookies-from-browser chrome：它自动读取 Chrome 的CookiesSQLite 数据库，无需手动导出 cookie txt。但要求 Chrome 已退出，否则数据库被锁。

5.2 ffmpeg 的硬件加速实战配置

CPU 编码太慢？video-use 在 NVIDIA GPU 环境下启用nvenc：

ffmpeg -hwaccel cuda -i input.mp4 \ -c:v h264_nvenc -b:v 2000k -cq 23 \ -c:a aac -b:a 128k \ output.mp4

-cq 23是恒定质量模式（CQ），比-crf更稳定；-b:v 2000k是码率上限，防止突发复杂场景爆码。实测 RTX 3060 下，1080p 编码速度达 120fps，是 CPU 的 8.3 倍。

AMD 用户用h264_amf，Intel 用户用h264_qsv，命令结构一致，只需替换 encoder 名。

5.3 ElevenLabs 的成本控制技巧

ElevenLabs 按字符计费，但 video-use 通过三招压降 64% 成本：

文本预处理：删除所有换行符、多余空格、HTML 标签，用正则s/<[^>]*>//g清洗；
语音复用：建立voice-cache/目录，对相同文本 MD5 值查重，命中则跳过 API 调用；
模型降级：非关键内容用eleven_turbo_v2（快 2.1 倍，贵 30%），关键口播用eleven_multilingual_v2。

成本监控脚本cost-report.py每日汇总：

# 统计今日所有请求的 total_characters 字段 total_chars = sum(j['total_characters'] for j in logs) cost_usd = total_chars * 0.00001 # $0.00001 per char print(f"Today: {total_chars} chars → ${cost_usd:.4f}")

5.4 EDL 的版本管理实践

EDL 文件用 Git 管理，但需规避两个陷阱：

时间码精度问题：Git diff 显示00:01:23:15→00:01:23:16，看似只差 1 帧，实则影响 33ms。video-use 的edl-diff工具会把时间码转为毫秒整数再 diff，输出：
```
line 3: src_start 83150ms → 83183ms (+33ms)
```
二进制污染：EDL 是纯文本，但某些编辑器（如 VS Code）默认插入 BOM。video-use 的 pre-commit hook 强制执行：
```
sed -i '1s/^\xEF\xBB\xBF//' edits.edl
```
删除 UTF-8 BOM，确保跨平台兼容。

6. 场景扩展与边界探索：video-use 还能做什么

6.1 适配 Android 设备的离线处理

热词里有ffmpeg for android，video-use 确实支持 Android。关键在交叉编译：

用android-ndk-r25c编译x264（ARM64）；
用--enable-neon --enable-armv8启用 ARM 指令集；
编译ffmpeg时加--enable-libx264 --enable-jni --disable-asm；
最终生成ffmpeg-android二进制，大小 12MB，可在 Term

视频自动化处理全链路：从下载到合成的命令行工作流