视频这块的需求说实话这几年我接过的项目加起来能凑一桌子了从短视频账号矩阵的批量剪辑到网课平台的格式转换再到监控视频的关键帧提取五花八门。但拿到video-use这个项目标题时我还是愣了一下——这名字取得太偷懒了却又精准得可怕。它几乎涵盖了我过去几年里遇到的百分之八十的视频使用场景怎么拿视频、怎么改视频、怎么从视频里挖出有用的东西。这篇文章我就以这个项目为线索把视频处理这条线上最核心的思路、最实用的工具组合、以及我踩过的那些坑一次性给你捋清楚。这个项目本质上解决的是三件事格式统一、内容提取、批量自动化。它适合的人也很明确刚接触视频处理、想知道从哪下手的自媒体运营者接了视频处理需求、却不知道怎么构建流程的开发新手以及那些天天和视频打交道、想把手动操作变成一键脚本的效率党。整体技术路线以FFmpeg为底层核心配合Python脚本做批处理调度再加上简单的文件管理策略组合出一套不需要高端设备、不需要商业软件授权、纯命令行加脚本就能跑起来的完整方案。我会把选型原因、核心参数、完整代码、运行效果和避坑经验都拆开讲确保你按着走一遍就能直接用到自己的项目里。1. 项目定位与核心需求拆解1.1 视频使用的三大痛点格式、内容、流程做视频处理的都知道真正让人头疼的往往不是剪辑软件操作多复杂而是各种琐碎得不能再琐碎的事情。我早年帮一个教育机构处理课程录像几百个视频文件有的用手机拍的有的是录屏软件导出的还有几个是从旧平台上扒拉下来的什么格式都有。当时第一反应就是这活不干到天亮干不完。后来大量实践下来发现所有视频使用的需求归根到底逃不开这三大类。一是格式问题。国内用MP4最多但总有那么些老设备、老平台会产出AVI、FLV、MKV甚至更冷门的格式。不同播放器、不同平台对格式的支持还各不相同有的平台单独要求H.264编码有的要求特定分辨率有的限制码率上限。这就导致每次上线一个平台就得手工导出一遍。二是内容提取问题。视频里藏着的关键信息怎么拿出来比如一段产品发布会视频需要按产品切片成十几段一段培训录像需要把PPT静态画面识别出来并截成图片。单纯靠剪辑软件手动定位、手动导出效率低得让人想砸电脑。三是流程自动化问题。明明是一个加字幕、转格式、改分辨率、压缩大小的固定流程每一次都手动操作每一次都可能漏掉某个环节这种重复性劳动不仅浪费时间还非常容易出错。所以这个video-use项目一开始的定位就很清楚不做一个大而全的剪辑软件而是做一套能覆盖格式转换—内容提取—批处理自动化这三条主线的命令行工具集。每个模块只干一件事但干得干净利落而且模块之间能串联能组合能一次性跑完整条流水线。1.2 方案的选型思路为什么是FFmpeg加脚本选型这个环节我其实比较过好几条路子。商业软件不用说剪映、Premiere功能强大但它们的强项是交互式剪辑不是批量处理。你让剪辑师手动处理几百个视频还能接受让一个自动化脚本去调用它们那就别扭了而且商业授权和命令行接口都是问题。开源剪辑软件像是OpenShot这类剪起来确实方便但底层能力有限批量调用同样不理想。最后落在FFmpeg加脚本这条路上原因很朴素。第一FFmpeg是命令行工具天生适合脚本调用和批处理。第二它覆盖面广得惊人解码、编码、滤镜、封装、拆流、缩放、裁剪、抽帧这些需求它全部原生支持不需要额外装一堆依赖。第三它跨平台Windows、macOS、Linux都能跑团队协作时大家的机器环境不一致这个优势尤其明显。第四它完全免费开源没有授权成本部署到服务器上做持续处理也毫无压力。那为什么还要配合Python脚本而不是直接靠FFmpeg参数因为FFmpeg确实强大但它是一条命令处理一个文件。真实项目里我们要的是扫一遍文件夹、批量处理所有符合条件的文件、生成处理日志、甚至按文件属性自动决定处理策略这些逻辑用批处理脚本写起来太痛苦了。Python的优势在于文件系统操作、逻辑判断、异常捕获、多线程调度这些能力都很成熟代码结构也容易维护。组合起来的模式就是Python负责编排和调度FFmpeg负责底层音视频处理各干各最擅长的事。1.3 项目目录与整体架构设计这个video-use项目我一开始就按模块化思路来组织整体结构并不复杂但每个目录职责清晰后续扩展起来非常省事。video-use/ ├── input/ # 待处理的原始视频统一丢这里 ├── output/ # 处理完成的结果输出目录 ├── logs/ # 运行日志方便回溯和排错 ├── scripts/ # 核心脚本目录 │ ├── convert.py # 格式转换与压缩模块 │ ├── extract_frames.py # 关键帧提取模块 │ ├── merge_videos.py # 视频拼接模块 │ └── batch_process.py # 批处理调度入口 ├── config.json # 全局配置文件集中管理参数 └── requirements.txt # Python依赖清单我见过不少项目一开始随意堆放脚本处理逻辑越加越多最后自己都看不懂哪个脚本是干嘛的。模块化不是给自己找麻烦而是给未来的自己省时间。input和output目录分离处理前和处理后的文件互不混淆这能避免不少误操作。logs目录也很容易被忽略但等到处理到一半发现某个环节出了问题没有日志的话排查起来就像大海捞针。2. 核心技术点与方案设计思路2.1 FFmpeg核心能力梳理视频处理的瑞士军刀聊FFmpeg得先理清一个概念它不是一个软件而是一整套音视频处理框架。你日常用得最多的命令行工具叫ffmpeg但它底层还有libavcodec、libavformat这一堆库。正因为有这一堆底层的库支撑FFmpeg才能做到凡是你能想到的格式基本都能解能编。我平时使用频率最高的几个模块先列个清单这能帮你在碰到具体问题时快速对号入座视频转码核心参数是-c:v指定视频编码器-c:a指定音频编码器。比如转H.264就写-c:v libx264转H.265就写-c:v libx265。分辨率缩放-vf scale1920:1080这属于视频滤镜的范畴。滤镜体系是FFmpeg最强大的部分缩放、裁剪、旋转、加水印全走-vf参数。帧提取-ss配合-frames:v可以实现从指定时间点开始提取指定数量的帧常用于生成预览图、场景封面。视频拼接先得把需要拼接的文件写进一个列表文件然后用-f concat -safe 0 -i list.txt进行拼接。直接丢多个输入文件给FFmpeg是不行的。码率控制-b:v指定视频码率-crf指定质量因子。CRF是x264/x265编码器独有的质量控制方式数值越小质量越高文件越大。音频处理-af系列滤镜常见的有音量标准化loudnorm、降噪arnndn、音量调整volume。这些功能单看参数好像不复杂真正的坑在于参数的组合顺序和具体编码器特性。同样的命令换个编码器可能效果完全不同换个源文件格式也可能报错。所以我做项目时很少裸写FFmpeg命令,都是写进脚本里用参数拼接的方式统一管理。2.2 Python脚本设计逻辑编排者而非替代者有的朋友可能会问为什么不直接用FFmpeg的批处理模式还要多套一层Python这个我之前在一次技术分享时解释过FFmpeg本身确实能处理单条命令内的多输入多输出但它对遍历文件夹、按条件筛选文件、动态拼参数、失败重试、生成日志这一层业务逻辑的支持几乎为零。批处理文件确实能把命令串起来但处理不了复杂的文件筛选条件比如处理所有修改时间在三天以内的mp4文件这种需求用批处理写起来要人命。Python脚本在这套架构里的职责是编排不是替代FFmpeg去做音视频处理。它负责的事情很纯粹用os.walk遍历目录用glob匹配文件扩展名用subprocess调用FFmpeg命令并捕获输出用json读取配置文件用logging写运行日志。如果处理过程中某个文件失败了Python脚本可以捕获异常记录到日志里然后继续处理下一个文件而不是像批处理那样直接中断。这种容错能力在批量处理上百个文件时尤其重要。脚本的公共部分我习惯抽取成通用函数这样每个模块不用重复造轮子。比如run_ffmpeg_command这个函数负责拼装命令、执行命令、检查返回码、记录日志所有具体处理模块都调它这样至少保证了日志格式统一、错误处理方式统一。2.3 工具链的完整闭环从一个文件到一条流水线当FFmpeg和Python脚本各自就位接下来就是让它们协同工作形成完整的工具链闭环。我建这个项目时的核心思路可以理解为把一次性的手工操作变成可重复执行的自动化工作流。一个典型的使用场景是这样的你把几十个不同格式、不同分辨率、不同码率的源视频丢进input/文件夹然后运行python scripts/batch_process.py --config config.json脚本会自动扫描文件夹里的所有视频文件读取配置文件里的目标参数按顺序执行三个环节统一转成H.264编码的MP4格式、按预设规则截取片段或提取关键帧、把处理完成的文件按日期重命名归类到output/目录。整个过程不需要人守在电脑前跑完看一眼日志有问题的地方单独处理。这套工具链的闭环价值在于把重复劳动压缩到极致把人为失误降到最低。一开始搭建这套东西可能要花一两天时间但之后每一次处理视频都能省下以小时计的时间。这种投入产出比做内容相关的朋友应该都能算明白。3. 实操过程与核心环节实现3.1 环境准备依赖项安装与校验动手之前先把环境搞定。FFmpeg的安装方式各个平台不太一样我直接按平台说一遍。Windows环境下推荐去FFmpeg官网下载编译好的二进制包把bin目录加到系统PATH里。这个步骤在百度上一搜一大把但我更推荐用包管理器来弄省得手动配环境变量。Windows下我试过choco install ffmpeg一行命令装完省心很多。macOS用户也一样brew install ffmpeg把一堆依赖自动装好。Linux用户分叉多一点Debian/Ubuntu系用apt install ffmpegCentOS/RHEL系用yum install ffmpeg。装完以后先别急着写脚本跑一下ffmpeg -version确认能正常输出版本信息再看看常用编码器是否支持。这个步骤很多人容易跳过但等到跑项目时才发现缺了某个编码器再回头补环境那心情是真的差。Python环境方面我需要用到的核心库其实只有三个subprocess是标准库不需要额外安装glob和os也都是标准库。严格来说这个项目甚至不需要requirements.txt但为了后续扩展方便我还是习惯性地建了一个万一以后要用到PIL处理图片或者tqdm做进度条直接加进去就行。校验环境有一个技巧拿一段小视频试跑一条最简单的转码命令。如果这段视频能正常从一种格式转成另一种格式说明解码器和编码器都正常工作后面的大批量处理才能放心跑。3.2 格式转换模块核心参数与CRF简史格式转换是这个项目里最实用的模块没有之一。我写的convert.py脚本核心就一个函数输入文件路径、目标格式、分辨率、质量等级然后拼出FFmpeg命令并执行。这里的质量等级我用的不是码率而是CRF值这是x264编码器的一个核心概念。CRF全称是Constant Rate Factor恒定质量因子。它的原理是让编码器根据画面的复杂程度动态分配码率画面细节丰富的帧用多一些码率画面简单的帧用少一些码率从而在整个视频保持视觉质量稳定的前提下控制文件大小。这个参数取值范围是0到51数值越小质量越高文件越大数值越大画质越差文件越小。实际操作中18到28是常用区间23是x264的默认值主观画质和文件大小平衡得比较好。我做常规网络传播视频时一般用23需要高画质留档的用18到20只在画面里放文字信息、不需要高保真的内容用26到28。这里插一句关于码率的对比如果直接用-b:v 2M这种固定码率方式画面简单时浪费空间画面复杂时又可能不够用整体质量控制远不如CRF细腻。这也是为什么现在主流视频处理基本都用CRF的原因。当然CRF只适用于一次性编码的场景如果你需要严格控制输出文件大小以适配平台上传限制那就得反过来用码率控制。两种方式各有用武之地我通常的做法是平台限制文件大小时用码率控制追求统一画质时用CRF。convert.py里还有一个容易被忽略但极其重要的参数-movflags faststart。这个参数的意思是把MP4文件的moov元数据块放到文件头部而不是默认的放在文件尾部。它的实际效果是视频不需要完整下载就能在线播放。网页端、移动端点开视频就能秒开而不是等文件全部缓冲完才开始播。做网络传输场景的朋友一定要记住这个参数它能显著提升播放体验。3.3 抽帧模块按时间点提取与按场景切分格式转换属于人人都能想到的用途抽帧才是video-use这个项目里真正体现技术价值的部分。我做过一个案例客户给了我一小时的产品介绍视频需要按产品段落切成十几段短视频。手动做法是拖播放器进度条、记录时间点、手工切割一个半小时才能弄完。用这个抽帧模块我把脚本先跑一遍每隔2秒提取一帧画面生成预览图人只需要看图就能快速确定每个产品段的起止时间十分钟搞定所有切片点位。实现提取帧的FFmpeg命令是这样组织的ffmpeg -ss 00:01:30 -i input.mp4 -frames:v 1 -q:v 2 output_frame.jpg-ss指定开始提取的时间点-frames:v 1表示只提取一帧-q:v 2控制输出图片的质量数值越小质量越好。还有一个更强大的滤镜模式按固定间隔抽帧ffmpeg -i input.mp4 -vf fps1/10 -q:v 2 frame_%04d.jpg这行命令的意思是每秒输出一帧1/10表示每10秒输出一帧。输出文件名中的%04d会自动补零成四位数序号。这种模式用于做视频内容预览、快速浏览视频结构非常方便。至于场景切分FFmpeg还提供了一个select滤镜配合场景检测效果比较有意思。它会分析每一帧画面的差异画面切换较大时认为是场景变化从而在切换点输出帧。这对处理教学视频、课程录制这类有PPT切换的内容非常有用它能直接把PPT页面的切换点全抓出来。命令大致是这样ffmpeg -i input.mp4 -vf selectgt(scene,0.3),showinfo -fps_mode vfr frame_%04d.jpg这里的scene阈值0.3是可以调的数值越接近1场景切换检测越迟钝抓到的帧越少越接近0检测越敏感抓到的帧越多。具体调多少取决于你的视频内容变化频率拍脑袋试几次就能找到合适的值。3.4 批量调度模块从单文件到目录级处理上面讲的都是单个文件怎么处理但实际项目里真正的效率提升来自批处理。batch_process.py这个脚本做的事情本质上是三步扫描、读取配置、循环调用。但我写了这么多年代码想说的是批处理最核心的不是怎么跑而是跑挂了怎么恢复。我的做法是在脚本里维护一个处理状态记录。每成功处理完一个文件就把它的路径和状态写进一个JSON文件下次再跑的时候脚本先检查这个记录已经处理成功的就直接跳过只有没处理过的或者上次失败的才重新处理。这个机制在文件很多、处理时间很长的时候能救命——一旦中途断网、断电、机器重启你能从断点继续跑而不是从头再来。批处理脚本里我还用了concurrent.futures做多线程并发。FFmpeg转码本身是CPU密集型的操作但处理多个文件的时候用多线程调度可以让几个FFmpeg进程同时跑充分利用多核CPU。这里有个注意点并发数不是你机器CPU核数越多越好。转码时内存占用不小并发太多可能导致内存耗尽系统卡死。我的经验是8核16线程的机器跑4到6个并发比较稳4核机器老老实实跑2个就行。这个数字你可以通过config.json里的max_workers字段自己调。config.json这个配置文件承担了所有参数的中心化管理目录设置、目标格式、目标分辨率、CRF值、抽帧间隔、并发数全都放进去。改参数不用动代码这让非技术背景的运维同事也能直接上手我感觉这在团队协作场景里价值很大。3.5 模块间的串联组合把单点工具变成完整流水线单个模块能跑通只是第一步真正让它值钱的是模块间的串联能力。我设计batch_process.py的时候专门留了--pipeline参数让它能顺序执行多个处理步骤。比如输入的是一个AVI格式的课程录像最终需要的是切成小段、转换成标准MP4、每段提取一张封面图。以前的流程是转码→手动切割→逐段截图全程人工守在电脑前。现在脚本按流水线跑一遍所有环节自动完成。流水线的核心在于串联参数传递转码模块处理完输出的文件路径要传给切分模块当输入切分模块产出的每个小文件路径再传给抽帧模块。这个链式调用在Python里实现并不复杂每个处理函数接收一个文件路径返回一个或多个输出路径下一个函数拿这些路径继续处理就行。但这里有个参数组织的问题如果每个模块都按自己的参数结构返回结果下游模块就得做一堆适配。我的做法是定义一个统一的VideoFile数据结构每个模块处理后返回的还是一个VideoFile对象只是里面的路径、格式、状态变了。这样不管加多少处理环节整个流水线的骨架都不会变。这种设计也方便以后扩展新的处理模块。想加一个视频加水印的环节写一个add_watermark.py接收VideoFile对象调用FFmpeg加完水印后更新VideoFile里的路径字段然后把它挂到流水线上就行不用动其他任何模块的代码。4. 常见问题与排查技巧实录4.1 FFmpeg常见报错与对应处理方案FFmpeg的报错信息初看很吓人一大段乱七八糟的输出但实际上高频率出现的问题就那么几种。我按踩坑频率排个序把所有常见问题的特征、原因和解决办法整理成了一张速查表方便你对照着排查。报错特征常见原因解决思路Unknown encoder libx264FFmpeg编译时没包含x264编码器重装带完整编码器版本的FFmpeg或用apt/brew安装扩展包Invalid data found when processing input文件损坏或不是真正的视频文件用ffprobe检查文件头信息确认文件完整性No such file or directory输出目录不存在或输入路径错误创建目录检查路径有没有中文、空格、特殊字符Error while opening encoder编码参数与容器格式不兼容检查编码器和封装格式的搭配是否合理如H.265尽量封装成MP4/MKVframe rate not supported输出帧率参数超出支持范围检查-r参数按标准帧率值设置或用-fps_mode代替moov atom not found视频文件本身损坏或未完整下载重新获取源文件或用-movflags faststart重新转码这几类问题覆盖了绝大多数日常报错。遇到不认识的报错信息不要慌先看最后几行FFmpeg通常会把最核心的错误原因放在末尾。然后就是看有没有Unknown、Invalid、Error这种关键词定位到具体是哪一环节出了问题。这里特别提一下中文路径的问题。Windows系统下文件路径含中文时FFmpeg偶尔会出现解析异常表现是路径被截断或乱码。虽然现在新版本已经好很多但我还是建议项目目录统一用英文命名源文件如果带着中文文件名在脚本里做好重命名映射别直接拿原始文件名拼命令。这算是我踩过不少次坑后总结出的血泪教训。4.2 视频处理结果与原视频方向不一致这个坑我之前帮朋友调试的时候遇到过他转出来的视频播放时是旋转了90度的。原因在于现在手机、运动相机拍摄的视频画面方向信息存在元数据里而不是真的把像素转了方向。FFmpeg转码时如果不处理这个元数据播放器可能正常显示因为播放器读了元数据自动旋转但转出来的文件在某些平台播放时就直接歪了。处理办法是在转码命令里加上自动旋转的滤镜ffmpeg -i input.mp4 -vf transpose1 output.mp4transpose参数有4个值1和2表示顺时针和逆时针旋转90度0和3表示水平或垂直翻转。有一种更省心的做法是加autorotate滤镜它会自动读取元数据处理方向ffmpeg -i input.mp4 -vf autorotate output.mp4不过这个滤镜也不是万能的某些文件在转码前已经被错误旋转过自动判断就可能出问题。我的建议是处理前先用ffprobe看一下元数据里的rotate字段再决定用哪种策略特殊情况再单独手工指定。4.3 批量处理中断后的恢复与日志分析批量处理跑了一半挂了这事谁都遇过。一堆文件的处理状态五花八门有的成功了有的还在进行中有的压根没开始。我早期写批处理脚本时踩过这个坑当时处理200多个视频跑到第137个的时候断电了重启后重新跑结果前面已经成功的137个又白跑一遍白白浪费了一个多小时。后来我就把断点续跑机制加了进去核心代码长这样import json import os def load_progress(progress_file): if os.path.exists(progress_file): with open(progress_file, r, encodingutf-8) as f: return json.load(f) return {} def save_progress(progress_file, done_list): with open(progress_file, w, encodingutf-8) as f: json.dump(done_list, f, ensure_asciiFalse, indent2) def should_skip(file_path, done_list): return file_path in done_list每次成功处理完一个文件就把文件路径追加到done_list里循环开始前先比对一下已经在列表里的直接跳过。这个逻辑实现起来只要几行代码但省下的时间可不止几小时。顺带说一句日志也是排查问题时最好的线索。我在logs/目录里按日期存了每次运行的日志这样跑完发现某些文件没处理成功直接翻日志就能看到具体是哪个环节、什么时间、报了什么错不用靠脑子回忆。4.4 视频处理工具链的高阶避坑清单除了上面这些已经报错的场景还有一些不会报错、但结果不符合预期的情况这些往往更坑。我列几个自己亲身经历过的典型问题帮你提前避雷。第一个是音画不同步。这在批量转码时偶尔会出现多半是因为源文件的音频采样率和帧率不标准转码时FFmpeg没有做正确的重采样。解决办法是在转码命令里显式指定-ar 44100或-ar 48000把音频采样率固定下来同时确保视频帧率和-fps_mode设置正确。遇到个别顽固文件加-async 1强制音频同步也好使但这是兜底方案正常流程里不建议标配。第二个是导出后文件大小暴增。有次我处理一段1080P课堂录像转完发现文件比源文件大了一倍。排查下来是源文件本身是高度压缩的流媒体格式码率很低我用默认参数重新编码后CRF值设定太严格等于把画面细节重新编码得更精细了。这种情况你得想到源文件本身的画质有限太小的CRF值只是浪费空间。我当时的处理方式是调高CRF到28文件体积一下下来了观感也基本没差别。第三个是拼接视频时接缝处出现黑屏或跳帧。这种情况多半是拼接的几个视频分辨率、帧率、编码参数不一致导致的。FFmpeg做concat拼接时要求源文件的编码参数尽量一致否则它会在切换编码参数时出现短暂的解码失败直观表现就是黑屏或跳帧。解决办法是拼接前先做统一转码把分辨率、帧率、编码器、像素格式全部统一后再拼或者用scale和fps滤镜在拼接时动态修正。第四个是文本字幕可能是乱码或直接不显示。字幕文件编码格式不统一是元凶FFmpeg对UTF-8的支持最好GBK等中文编码字幕经常出问题。处理方法是用文本编辑器把字幕转成UTF-8编码并在命令行里通过-sub_charenc参数指定编码。第五个是输出文件名冲突。批量处理时如果没设计好命名规则两个不同来源的文件很可能生成同一个输出文件名导致后一个覆盖前一个。我的习惯是统一按源文件名_处理时间戳_操作类型的规则生成新文件名从根上杜绝覆盖问题。5. 项目扩展思路与进阶方向5.1 从命令行工具到Web服务video-use起步是一个命令行工具集但用久了你会发现它的潜力远不止于此。我后来的做法是给它加了一个简单的Web层用Flask写了一个API接口前端页面提供文件上传、参数选择、进度展示后端调用现有的脚本模块处理完以后返回下载链接。这样做的价值在于让不熟悉命令行的同事也能使用这套工具而且可以部署到一台公用服务器上整个团队共享处理能力不用每台机器都装一遍FFmpeg环境。开发量其实不大因为核心逻辑都已经在脚本里了Web层只是包了一层壳。5.2 引入自动化监控与事件驱动如果你觉得手动丢文件进input/目录还不够自动化可以考虑加一个目录监控模块。Python的watchdog库能监听一个文件夹的变化一旦有新文件进入就自动触发处理流程。这样你只需要把源视频拖进指定文件夹后续的转码、抽帧、归档全部自动完成。我当时给一个做课程内容的朋友搭了这个机制她每天到公司把当天录好的课程拖进目录下班前处理结果已经在output/目录里整理好了体验非常顺畅。5.3 与内容分发平台的对接视频处理完之后还有一个环节上传到各个内容平台。这个其实也可以打通。以我自己的实践为例处理完的视频文件按平台要求命名好然后用各平台开放API或第三方发布工具的接口做自动上传。整个链路就变成了源视频进来→自动处理→自动发布人工只需要做最终的内容审核。这种自动化方案对做矩阵账号、多平台分发的团队来说节省的时间不是按分钟算而是按小时算的。这个话题如果再展开还能聊很多比如加人脸检测、语音识别转字幕、AI自动剪辑等等不过那已经超出video-use本体的范围了。说实话我搭这套工具的初衷就是帮自己和朋友摆脱重复劳动现在看来这个目标已经达到了。如果你也在视频处理这条路上挣扎希望这篇文章里的思路、代码和踩坑记录能让你少走几段弯路。最后友情提示一句批量处理真跑起来之前拿一两个文件先试跑一下确认输出效果符合预期再全量启动这句话能帮你省下不知道多少返工时间。