最近手头攒了一套自己常用的视频处理脚本，起了个名字叫video-use，说白了就是一套围绕"视频怎么用起来更顺手"的日常工具集。做视频的朋友应该都有体会：素材一多，格式五花八门，有的是手机拍的MOV，有的是相机出的4K高码率素材，还有从网上下载的各种封装格式，真要开始剪的时候，第一个拦路虎往往不是剪辑软件本身，而是素材怎么统一、怎么压缩、怎么转成目标平台要的规格。这套工具的定位就是解决这一类问题——本地批量处理、不依赖在线服务、不压画质到没法看，同时把重复劳动脚本化。
这篇文章适合三类人：一是视频创作者和剪辑师，需要高频处理素材的；二是做内容归档和管理的朋友，想把大量视频统一格式和参数；三是刚接触视频处理、想搞清楚FFmpeg和各种封装格式之间关系的新手。我会把从选型到落地全链路讲清楚，包括每个命令背后的理由，以及我踩过的坑。
1. 视频处理的真实痛点：为什么我攒了一个工具集
先说个场景。上个月我给一个企业客户做项目复盘视频，对方发来的素材五花八门：有人用手机竖屏拍的，有人用单反横屏拍的，还有几个从会议系统里导出的超长录像。加起来三十多个文件，总时长超过六个小时。如果直接全部拖进剪辑软件，光导入和代理文件生成就要等半天，更别提不同帧率混在一起造成的卡顿和音画不同步问题。
我当时的处理流程很简单：先统一格式，再批量压缩成剪辑友好的参数，最后按场景分组归档。这一套流程如果手动操作，每个文件至少需要敲十几条命令，六个小时素材就是几百条命令，手动敲不完，所以必须脚本化。video-use工具集就是在这样的需求下逐步长出来的。
这类工具要解决的核心问题，总结下来其实是四件事：
- 格式统一：把不同容器、编码、帧率的素材转成同一规格，让剪辑软件不闹脾气。
- 体积瘦身：在不明显损失画质的前提下压缩码率，节省存储和传输时间。4K素材动辄单个文件几个GB，归档成本很高。
- 批量执行：同一套参数一次性处理几十个文件，跑完自动输出报告，不用守着命令行。
- 可复现可维护：参数和流程写进脚本，下个月再处理同类素材时直接复用，不靠记忆。
这四件事单独拎出来都有人解决过，但合在一起、同时支持Windows和macOS、又不需要装一堆图形界面软件，我找了一圈没有特别合手的，就自己写了。
期间也试过一些现成的图形工具。HandBrake做单文件压缩很好用，界面直观，但批量处理的时候队列管理比较呆板，且它对音频轨的处理选项不够细——比如我想批量把多音轨素材统一压成立体声，HandBrake要一个个点，很麻烦。Adobe Media Encoder功能强，但那是Adobe全家桶用户的选择，不是所有人都装得起。剪映也自带导出功能，但那是面向成片，不是面向素材预处理的。真正到了素材整理阶段，FFmpeg命令行加上一层Python封装，才是最自由、最可控的方案。
所以最终的技术栈选择是：核心引擎用FFmpeg，脚本层用Python 3，调度层用bash（Windows下用PowerShell），外加一个简单的配置文件来管理参数。工具本身没有图形界面，但输出的处理报告足够清晰，跑完看日志就能知道哪些文件成功、哪些失败、每个文件压成多大。这套组合的好处是每个环节都是成熟技术，出了问题网上有海量方案可以参考，不会遇到"某个小众工具突然不维护了"的尴尬。
2. 工具链选型：FFmpeg、Python和参数管理
确定要自建工具集之后，最先要解决的是工具链选型。FFmpeg几乎是视频处理的事实标准，它不是某个商业软件，而是一套开源命令行工具集，几乎所有你能想到的视频处理操作它都能做：转封装、转编码、裁剪、拼接、抽帧、加字幕、调音量、合成视频。它的生态非常成熟，几乎所有开源播放器、剪辑软件、转码工具的后端都是它。
不过我直接使用FFmpeg原生命令的时候，很快发现几个痛点。首先是命令太长太杂，一个稍微复杂点的压缩命令能写满一整行，各种参数缩写满屏幕飞，两周不看就得回头查文档。其次是参数容易记混，-crf 23和-crf 18的视觉差异要看素材内容，-preset slow和-preset ultrafast的耗时差好几倍，这些经验值不写下来就等于没经验。第三是批量处理没有内建的重试和错误记录机制，一个文件出错整批中断，前面处理的又得重新跑。
基于这些痛点，我在FFmpeg外面包了一层Python，做了三件事：
- 用配置文件管理参数，把常用的"高画质压缩""网络发布""代理文件生成"等场景固化下来。
- 写了一个循环调度器，按文件逐个调用FFmpeg，捕获每个文件的退出码，失败自动跳过并记录原因。
- 生成HTML和TXT双格式的报告，列出处理前后大小对比、耗时、失败原因。
参数管理这块我特别想多说两句。很多人处理视频是记命令，今天搜到一个好用参数，明天换台电脑就找不到了。我更推荐把参数和场景绑定，写进YAML格式的配置文件里。比如：
profiles: master_archive: crf: 18 preset: slow audio_bitrate: 192k audio_channels: 2 extension: mp4 web_upload: crf: 23 preset: medium max_width: 1920 audio_bitrate: 128k audio_channels: 2 extension: mp4 proxy_editing: crf: 28 preset: ultrafast max_width: 1280 audio_bitrate: 96k audio_channels: 2 extension: mkv这套配置解决了"我上次是怎么压缩的"这个问题。我只要在命令行指定--profile web_upload，剩下的参数全部从配置文件读取，不靠记忆。每个配置项的含义和作用，后面我会逐个拆解。
FFmpeg版本的选择也有讲究。市面上能搜到很多编译版本，我推荐从FFmpeg官网下载静态编译版，或者用系统包管理器安装。关键点是确认版本发布日期，尽量用较新的版本，因为视频编码器的更新速度很快，新版本通常意味着更好的压缩效率和更多编码格式的支持。比如H.266/VVC的软解支持、AV1编码的改进，都是近期版本才有明显进展的。用太老的版本，碰到新设备拍摄的10-bit H.265素材可能直接报错，排错会非常头痛。
工具链选型还有一层是"什么时候用FFmpeg，什么时候用其他工具"。我的判断标准很简单：如果是简单地修剪、转格式，FFmpeg足够；如果需要精细调整画面颜色、做关键帧动画，那回到剪辑软件；如果是要在社交媒体上做营销短视频，直接用剪映这类工具效率更高。video-use定位在"素材预处理和归档"这个环节，不越界、不贪心，专注把这个环节做到最顺手。
3. 核心场景实战：压缩、转封装、抽帧与批量拼接
工具集搭好架子之后，主要精力放在打磨具体场景的处理逻辑上。这一节我会把最常用的四个场景逐一展开，每个都给出完整命令和参数解释，标注哪些是经验值、为什么这么定。
3.1 高质量压缩：用CRF而不是固定码率
大部分人对视频压缩的理解是"码率越低文件越小"，但实际压缩时直接指定比特率（比如-b:v 5M）并不是最好的方式。原因很简单：不同画面的复杂度差别很大，静态访谈画面和快速运动画面的信息量完全不同，固定码率要么在复杂画面上糊掉，要么在简单画面上浪费流量。
更科学的做法是使用CRF（Constant Rate Factor，恒定质量因子）。CRF是x264/x265编码器提供的一种"按需分配码率"的机制，它会尽量让每一帧都达到相近的视觉质量，画面简单的地方少花码率，画面复杂的地方多花码率，最终码率是浮动的。CRF的取值范围一般是0到51，数值越小质量越高、文件越大，对于日常素材来说，18到23是比较合理的区间。
我目前的主力归档参数是这样一套：
ffmpeg -i input.mov \ -c:v libx265 \ -crf 20 \ -preset slow \ -tag:v hvc1 \ -c:a aac \ -b:a 192k \ -ac 2 \ -movflags +faststart \ output.mp4逐个解释关键参数：
-c:v libx265：选择H.265/HEVC编码器。相比H.264，HEVC在同画质下大概能省30%到50%的码率，这对大体积素材的归档很有价值。代价是编码速度慢一些，但对不需要实时处理的归档场景来说，多等几分钟完全可以接受。-crf 20：这个数值是我在测试了18、20、23、26四档之后定下的平衡点。18几乎无损，但文件仍然偏大；23在手机上看还行，投到大屏幕上色块和噪点就明显了；20是一个视觉上很难区分差异、体积又明显可控的点。-preset slow：这个参数控制编码器的"努力程度"，从ultrafast到veryslow有好几个档位。slow档比medium档压缩率更高，但耗时大概多40%。测试下来同样的CRF值，slow档的文件会比medium档小10%到15%，对于批量归档来说这笔账划算。-tag:v hvc1：这是很多人忽略的细节。在封装MP4文件时，H.265编码的视频需要正确标记扩展类型。如果不加这个参数，很多苹果设备自带的播放器、QuickTime会拒绝播放，视频能打开但只出声音，画面是黑的，调试起来非常头痛。-movflags +faststart：把moov元数据块挪到文件头部。这样视频文件放进网页播放器、或者从远端服务器播放时，能实现"边下边播"，不用等整个文件下载完才能拖动进度条。做内容分发时要特别记住这条。
音频方面统一压成AAC立体声，192kbps码率对大多数语音和配乐场景都足够。如果素材本来就是单声道，我会改成96kbps，省一点空间。
3.2 转封装和转编码：搞清楚两个不同的事
很多新手会把"转换格式"混为一谈，但转封装（remux）和转编码（transcode）是完全不同的两件事，成本差异也很大。
转封装只改变容器，不重新编码视频和音频内容。比如把MKV里的H.264视频"取出来"放进MP4容器，整个过程不涉及画面重算，速度极快，几乎无损，几个G的文件几秒钟就能完成。命令长这样：
ffmpeg -i input.mkv -c copy output.mp4-c copy的意思是一切流都直接拷贝过去，不重编码，这是最快的处理方式。但要注意MP4容器不是所有编码格式都友好：比如MKV里装的FLAC音频，放进MP4可能不被支持，或者MKV里常见的某些字幕格式，MP4容器根本放不下。遇到这种情况，通常只能选择丢弃轨道或者重编码。
转编码则是另一回事。它需要解码、再编码，计算量大，耗时以分钟或者小时计。什么时候必须转编码？
- 剪辑软件不认识原始编码格式。比如部分相机拍摄的Log视频是特定编码，剪映和Premiere不一定直接认，需要先转成更通用的格式。
- 原始码率太高，直接编辑不流畅。4K 60帧的H.265素材在普通笔记本上预览很卡，转成H.264并生成低分辨率代理文件就好很多。
- 目标平台有明确规格要求。比如某些短视频平台要求上传H.264+AAC的MP4，但你的素材是H.265，就得转编码。
转编码的时候要谨慎，因为每转一次就等于多一次画质损失，这是有损编码的本质决定的。所以我的原则是：能转封装的就别转编码，非转编码不可的，就用高质量CRF 18压一次，后续所有编辑都基于这个版本，不要再重复转。转码链一旦拉长，画质衰减是肉眼可见的，尤其是暗部细节和天空渐变区域，很容易出现色带。
3.3 批量抽帧：做片场记录和学习资料
抽帧这个需求经常被忽略，但实际用途非常大。比如我想给一段访谈快速生成"内容概览"，可以每隔几秒抽一帧出来拼成九宫格，扫一眼就知道这段讲了什么。或者做镜头学习，截取某个导演作品的代表性构图，用来做视觉参考。还有做视频封面图、素材缩略图，都离不开抽帧。
video-use里对应的命令是：
ffmpeg -i input.mp4 -vf "fps=1/10,scale=320:-1" -frame 0 output_%03d.jpg参数拆解：
fps=1/10：每10秒输出一帧。这个表达式来自FFmpeg的filter语法，注意写法是1/10不是0.1，因为fps filter要求的是分数格式。scale=320:-1：缩放到宽度320像素，高度自动按原始宽高比计算。-1表示让FFmpeg自己算，保持比例不被拉伸。-frame 0：无限抽帧，直到文件结束。如果不加这个参数，FFmpeg会一直处理到视频流结束，默认也可以实现同样的效果，但写上更明确。output_%03d.jpg：输出文件名按序号排列，%03d代表数字部分至少三位，不足补零。这样排序和后续处理都比较规范。
批量抽帧有一个常见坑：源视频帧率如果是可变帧率（VFR，Variable Frame Rate），按时间抽帧可能出现帧时间不准确的问题。比如手机录屏、视频会议软件录制的视频，经常是VFR的，FFmpeg按时间轴算抽帧位置时会偶发跳帧。稳妥的做法是先转成固定帧率（CFR），或者直接按帧数抽。按帧数抽的命令是：
ffmpeg -i input.mp4 -vf "select=not(mod(n\,120)),scale=320:-1" output_%03d.jpgselect=not(mod(n\,120))的意思是每120帧取1帧，假设源视频是24fps，那就是每5秒抽一帧。注意filter里面的逗号和括号可能需要转义，具体看你的shell环境。
抽帧环节的经验是：先小范围试抽一二十张，检查画面亮度和构图是否符合预期，再全量跑。特别是调色风格比较厚重的视频素材，直接抽出来的帧往往比预期暗一截，需要加eq=brightness=0.05:saturation=1.2之类的调参才能得到可用的参考图。
3.4 批量拼接与转场：用concat协议提高效率
拼接多个素材也是高频需求。很多人在剪辑软件里手动拼接，素材少了没问题，但如果要拼的是几十个短视频片段，比如课程录屏章节拼接、多机位素材对齐后的合成，命令行反而是更可控的方案。
FFmpeg拼接有两种主流方式：concat协议和concatfilter，它们各有适用场景。
concat协议适合所有输入文件编码参数完全一致的场景，速度快、不重编码。命令是这样：
ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4filelist.txt的内容格式为：
file 'part1.mp4' file 'part2.mp4' file 'part3.mp4'这个方案的致命限制是：如果两个片段的编码参数不一致——比如一个来自iPhone、一个来自单反，分辨率不同、编码器不同，输出就会出问题，轻则在拼接点卡顿或花屏，重则直接报错退出。而且-c copy处理的是同编码流的接续，参数不一致时不能硬拼。
concatfilter则灵活得多，它会在拼接前把所有输入先统一格式，允许不同分辨率、不同帧率的素材混合拼接。代价是要重新编码，耗时更长。我常用的命令：
ffmpeg -i part1.mp4 -i part2.mp4 -i part3.mp4 \ -filter_complex "[0:v:0][0:a:0][1:v:0][1:a:0][2:v:0][2:a:0]concat=n=3:v=1:a=1[outv][outa]" \ -map "[outv]" -map "[outa]" \ -c:v libx265 -crf 20 -preset slow \ -c:a aac -b:a 192k \ output.mp4filter_complex的写法看起来吓人，但逻辑其实清晰：把三个输入文件的视频流和音频流分别指出来，[0:v:0]表示第0个输入文件的第0路视频流，[0:a:0]表示第0个输入文件的第0路音频流，然后统一喂给concat过滤器，设置拼接数量为3，同时生成视频流和音频流，最后输出映射到[outv][outa]。这个方案我实测对"分辨率不一致但也差不多"的素材容忍度很高，不过建议在拼接前先用-vf scale统一分辨率，避免不同片段间画面比例跳变。
关于拼接还有一个容易忽略的点：音频采样率不一致。两个视频一个音频是48000Hz，另一个是44100Hz，拼接后音频可能出现音调微变或者同步偏移。稳妥起见，在concat filter方案里我会先加一个音频重采样过滤器，比如[1:a]aresample=48000[a1]，保证所有音频流都是同一采样率后再拼接。这个坑是某个项目里被甲方指出来后我才认真对待的，现在成了固定的预处理步骤。
4. 批量处理的艺术：让脚本可复用、可监控、可兜底
单项功能做利索之后，真正提升效率的是批量处理框架。video-use的核心价值也在这里：它不只是"一条命令处理一个文件"，而是一套"一条命令处理一整批文件并输出报告"的机制。
4.1 目录递归与自动发现
大多数素材不会整整齐齐堆在一个文件夹里。我的项目目录结构常常是这样的：
source/ interview/ morning/ A001C021_0101.mov A001C022_0101.mov afternoon/ A001C023_0101.mov broll/ drone/ DJI_0011.mov DJI_0012.mov timelapse/ TL_001.mov手动逐个文件夹跑命令不现实。所以批量处理第一步是递归发现文件，用Python的os.walk就能搞定，再配合文件名模式匹配，比如只处理扩展名为.mov和.mp4的文件，忽略.wav等音频文件。这样整个source目录只需跑一次批量命令，所有子目录的文件都会按规则被处理。
4.2 中途失败不中断
批量处理最怕的是跑到一半遇到坏文件。损坏的视频文件、异常编码的流、被截断的文件，都是常态。如果脚本遇到一个坏文件就整体退出，前面的劳动就白费了，后面好的文件也被拦住。
所以我设计了"失败跳过+自动报告"机制：每个文件处理前记录开始时间，处理完统计退出码和耗时，退出码非0则捕获stderr最后几行作为错误摘要，同时把文件路径写进失败列表。整个过程不中断，剩下的文件继续处理。最后生成一份报告，一目了然知道哪些文件成功、哪些失败、失败原因是什么。
4.3 并发与进度监控
单线程逐个处理几十个文件确实慢，但也不是越快越好。编码是CPU密集任务，并发跑太多会导致CPU过载、系统响应卡顿，甚至影响其他正在运行的程序。我根据自己的机器配置和实践经验，默认用--workers 2，也就是同时跑两个转换任务。在8核以上的机器上，2到4个并发是比较舒服的区间。
进度方面，不需要依赖复杂的监控面板，简单的日志就够了：
[14:32:01] Processing source/interview/morning/A001C021_0101.mov [14:36:44] OK -> 1.2GB → 480MB, time 4m43s [14:36:45] Processing source/interview/afternoon/A001C023_0101.mov [14:37:22] FAIL -> ERROR: moov atom not found这类日志看起来土，但排查问题非常高效，尤其是批量跑完回看时，几行文字就能定位问题文件。
4.4 预留"止损"机制
批量转码最忌讳的是参数没调好就全量开跑，跑完一看全废了。我的经验是任何批量任务都先小规模试跑，指定--limit 3只处理前三个文件，检查输出文件是否能正常播放、大小是否合理，确认没问题再全量跑。这个"止损"机制看起来耽误时间，实际却大幅降低了返工概率。很多参数问题——比如色彩空间变了、音画不同步了、封装格式不被目标播放器支持——在单文件测试时就能发现。
5. 踩坑实录：色彩空间、时间戳和播放器兼容性的三重门
工具集稳定运行了几个月之后，我记录的坑主要集中在三个方面。每个坑都是真实遇到过、并且花了不少时间排查才定位清楚的，写出来给有兴趣的朋友当参考。
5.1 色彩空间：为什么转出来颜色变灰了
某天我批量转了一批素材，输出文件播放时发现颜色整体发灰，暗部死黑，亮部过曝，饱和度明显偏低。排查到最后才发现问题出在色彩空间元数据上。
现代视频文件会在元数据里标记色彩空间标准，常见的有BT.709（高清视频的标准）、BT.601（标清视频的标准）、BT.2020（4K HDR视频的标准），还有DCI-P3等。不同的色彩空间对应不同的色域和Gamma曲线。如果转码工具没有正确传递这些元数据，或者在处理时把色彩空间搞错了，比如把BT.709的素材当成BT.601去解码，输出画质就会明显偏色。
我在FFmpeg里看到这类警告信息时一开始没当回事：
[hevc @ 0x7f8e2a01b200] Color space mismatch detected [hevc @ 0x7f8e2a01b200] Falling back to BT.709后来才知道，这是源文件的色彩空间元数据本身不标准，或者编码器写的标记和实际内容不一致导致的。解决办法是在转码时显式指定色彩空间：
ffmpeg -i input.mov \ -c:v libx265 -crf 20 \ -colorspace bt709 -color_trc bt709 -color_primaries bt709 \ -color_range tv \ output.mp4-colorspace、-color_trc、-color_primaries分别对应色彩空间、传递函数（即Gamma曲线）和原色色度，三个参数要配套设置。-color_range tv表示视频的动态范围是标准的16到235（视频电平），而不是0到255（全范围）。这个细节特别容易踩：有些设备拍出来的视频是full range的，但没有正确标记，FFmpeg默认按tv range处理，结果就是暗部灰蒙蒙、黑位不扎实。
排查思路很明确：先看源文件的色彩元数据，用ffprobe转储信息：
ffprobe -v error -select_streams v:0 -show_entries stream=color_space,color_transfer,color_primaries -of default=noprint_wrappers=1 input.mov如果输出的值是bt709、bt709、bt709，说明源文件标记正常。如果看到unknown，大概率就是这些设备厂商不爱规范写的锅，转码时必须手动指定，否则默认参数可能会猜错。
5.2 时间戳和音画同步问题
批量处理里另一个让我抓狂的问题是音画不同步。单个文件播放没问题，但连续处理多个片段后拼接，某些片段的声音和画面就对不上了。排查发现这主要是时间戳（PTS/DTS）在转码过程中出了问题。
FFmpeg处理视频流和音频流时，各自有一套时间基准，如果其中某一段文件的起始时间戳不是0，而是从某个偏移量开始，拼接时就会出现错位。比如某段手机录像的音频流起始PTS是512个采样点，而视频流起始PTS是0，两个流的时间锚点不同，拼接时就会差上几十毫秒，看起来就像是口型对不上。
解决方法是处理完每个文件后重置时间戳，用-fflags +genpts强制生成一致的PTS，或者在filter_complex里为每段流加上setpts=PTS-STARTPTS和asetpts=PTS-STARTPTS。我自己的习惯是在批量处理命令里的统一加一组过滤器：
-vf "setpts=PTS-STARTPTS" -af "asetpts=PTS-STARTPTS"这样每个文件处理完后，流的起始时间都会归零，后续拼接的音画同步问题从根上就杜绝了。
5.3 播放器兼容性：Mac和Windows的标准不一样
同一个MP4文件，在Windows上播放正常，到Mac上打开却提示不支持甚至只出声音、画面黑屏。这个问题其实很普遍，原因也简单：播放器和系统对编码器支持和封装格式的宽容度不一样。
最典型的是H.265/HEVC。Mac从High Sierra开始支持HEVC硬解，但前提是MP4文件里要写正确的编码器标签。Apple设备期望的是hvc1标签，而很多工具默认写入的是hev1标签。两者指向同一个编码标准，但标记不同会导致苹果设备拒绝硬解，甚至根本不播放。前面3.1节提到的-tag:v hvc1就是为了解决这个问题。
此外，音频编码也有类似的兼容性差异。MP4容器里的音频流，使用AAC编码是最稳妥的选择。如果转码出来的MP4里是FLAC或者Opus，Windows自带的播放器可能能放，但Mac的QuickTime就不一定了。还有一个真实项目里遇到的坑：某次我处理完一批视频后发现Mac能放、Windows播不了，定位到最后是色彩空间元数据缺失，Windows播放器对色彩元数据缺失时猜错了，画面发绿，Mac的播放器则自动猜对了。所以跨平台兼容性不能只看封装格式和编码格式，色彩元数据也是关键一环。
兼容性测试的实用办法是准备一个"验收清单"，每次批量处理后随机抽几个文件，在目标播放器里过一遍：画面颜色是否正常、声音是否同步、是否能拖动进度条、是否被目标剪辑软件识别。不用每个文件都测试，抽样就够，但抽样比例建议不低于10%。
6. 扩展到更多场景：字幕烧录、变速与视频信息批改
前面几节讲的都是最基础的场景，但video-use日常还承担了一些相对进阶的活儿。这里挑三个常用的展开说说，给想自己扩展的朋友参考。
字幕烧录是最常用的进阶功能之一。所谓烧录（burn-in），就是把字幕文本直接嵌进画面里，生成的字幕无法关闭，与视频合成一体。这在给客户交付审阅版本时非常有用，因为很多客户不看SRT字幕文件，他们希望直接在播放画面里看到字幕。烧录命令：
ffmpeg -i input.mp4 -vf "subtitles=subs.srt:force_style='Fontsize=18,PrimaryColour=&H00FFFFFF,Outline=1,Shadow=1'" -c:v libx265 -crf 22 -c:a copy output.mp4注意subtitles滤镜依赖FFmpeg编译时带上了libass库，很多精简版或其他发行版默认禁用，需要确认安装版本里是否有这个能力。另外字幕文字是矢量渲染的，缩略图预览、手机全屏播放和电视大屏播放的观感差异很大，字号和边距需要按目标尺寸调配。我的经验是：交付给客户全屏播放的版本，字幕字号18上下合适，但如果客户会在手机上看，字号至少26起步才算舒服。
变速处理的需求也不少，尤其是做延时摄影和慢动作展示。FFmpeg的setpts滤镜把视频帧的时间戳缩放，音频用atempo滤镜处理。2倍速的命令：
ffmpeg -i input.mp4 -vf "setpts=PTS/2" -af "atempo=2.0" -c:v libx265 -crf 20 -preset slow output.mp4这里有个限制要注意：atempo滤镜处理0.5到2.0倍之间的变速效果最好，超过这个范围音质会明显劣化。如果要做4倍速，正确做法是串联两次atempo=2.0，而不是直接用atempo=4.0。这个细节不踩一次坑是记不住的，我最初直接砸了个atempo=3.0，出来的音频像罐头里闷出来的，后来查文档才知道原因。
信息批改也是高频需求。批量把几十个视频的元数据统一修改——标题、作者、版权信息、创建时间——在视频归档和分发时非常实用。命令示例：
ffmpeg -i input.mp4 -c copy -metadata title="项目A复盘录像" -metadata artist="张三" -metadata comment="仅供内部使用" output.mp4这里用-c copy不重编码，因为元数据修改不需要动画面，瞬间完成。批量场景下我还会结合配置文件，把每批文件的公共元数据和按文件区分的定制值分开写，避免手工逐个改。
video-use工具集发展到现在，已经不只是"几个命令的集合"。它本质上是一套沉淀下来的工作习惯：什么场景用什么参数、遇到问题去哪里查、处理完怎么验证，都形成了固定套路。工具本身不复杂，复杂的是把处理流梳理得足够明白。如果你也经常和视频素材打交道，完全可以按这个思路搭建自己的版本，不需要照搬命令，关键是要把参数和场景固化下来，把每次处理的"为什么"记录清楚。这样下次再遇到相似的素材，你不是翻聊天记录找命令，而是翻开自己的配置文件，一切都在那里等着你。
