SpringBoot集成FFmpeg：Java视频处理服务实战与踩坑记录

简介：视频处理能力正成为许多业务系统的基础需求，但如何在Java后端工程中高效集成始终是难点。FFmpeg作为业界标准的音视频处理工具，通过命令行调用与Java调度层结合，能够实现稳定、可控的视频剪辑、拼接、音频混音与字幕烧录。SpringBoot提供了完善的异步任务管理与状态机设计，配合Redis进度缓存，可构建高可用的视频处理服务。本文从FFmpeg核心命令避坑、JavaCV等方案对比，到任务队列与并发压测实践，完整记录了一套基于SpringBoot的视频处理服务落地过程，为需要嵌入视频处理能力的Java工程师提供可复用的工程参考。

1. 项目背景与需求梳理

1.1 这个项目到底要解决什么问题

先说个背景。之前有个项目需要在业务系统里直接完成视频处理，需求听起来很简单：运营上传一段视频素材，后台自动完成裁剪、拼接、加音频、加字幕，最后输出成片。刚听到时我第一反应是——这不是剪映做的事吗？但如果要把它嵌入到一个以Java和SpringBoot为核心的后端系统里，事情就变得完全不一样了。

传统的视频处理工具链几乎都是C/C++的天下，FFmpeg、OpenCV、GStreamer，每一个都是重型武器。Java在视频处理领域的存在感一直不高，生态相对零散。但这两年情况在变，JavaCV持续迭代，FFmpeg的命令行集成也越来越成熟，再加上SpringBoot的工程化能力，用Java技术栈做一个可落地的视频处理服务已经完全走得通了。

这个项目的核心价值，是让视频处理能力成为系统的一个内部服务，而不是依赖人工去操作客户端工具。运营人员上传素材，系统自动按预设规则处理，全程无人工干预。听起来简单，真要做起来，里面那堆细节——异步任务管理、进度回传、内存控制、字体兼容、编码格式匹配——任何一个点都能让人折腾一整晚。

1.2 为什么还要用Java来做视频处理

这是很多同行会问的第一个问题。Python不是更香吗？确实，Python在多媒体处理上有不少现成库可用，但要看场景。很多公司的后端基础设施是Java统一维护的，监控、日志、权限、部署体系全部围绕Java技术栈搭建，为了一个视频处理功能单独引一套Python服务，运维成本和团队学习成本都不低。在这个背景下，用SpringBoot集成视频处理能力，意味着整个项目可以跟着主工程一起走，共用配置中心、注册中心、网关鉴权，工程化成本最小化。

另外，Java 17以上的性能已经有了相当不错的提升，配合虚拟线程处理并发IO，实际体验并不比Python方案差。而且FFmpeg这种重量级任务本身在子进程里跑，Java层只是做调度、组装、解析结果——这种模式下，Java的短板被绕开了，长板反而很突出，比如强类型对参数的严格约束、Spring生态对任务状态的完整管理能力。

只要思路清晰，Java做视频处理完全不是勉强能用的水平，而是一个正经的工程选择。

2. 技术选型：Java视频处理的四条路

2.1 方案对照：命令行调用、JavaCV、JCodec、JAVE

先说结论，Java生态做视频处理，主流路线就四种。

第一种：FFmpeg命令行 + Java调度。后端用ProcessBuilder或Runtime.exec启动FFmpeg子进程，按参数模板拼命令，解析返回码和日志输出。这是目前商业项目里最稳的方案，因为FFmpeg本身是行业标准，什么格式都能解，什么编码都能压。缺点是需要目标服务器安装FFmpeg，或者随项目打包静态编译版本。

第二种：JavaCV。JavaCV是Bytedeco团队对FFmpeg、OpenCV、OpenKinect等一系列原生库的Java封装，通过JNI调用原生能力。它的优势是不用在系统里单独安装FFmpeg，jar包自带二进制库；但代价是包体积大、版本敏感、部署环境兼容性需要额外测试。

第三种：JCodec。纯Java实现，JVM直接解析和编码视频帧，不需要任何原生依赖。理想很美，但现实很骨感——它对H.264、AAC等高压缩格式的支持一直不完整，性能和FFmpeg差距明显。我试过用JCodec做简单的MP4转GIF，小尺寸素材还行，一旦碰到1080p以上的高码率文件，CPU占用和耗时都不可接受。

第四种：JAVE。还是基于FFmpeg的一层封装，本质上是命令行的二次封装，只是把常见操作封装成了更友好的Java API。但项目维护频率比较低，新FFmpeg版本的兼容性接入需要自己改。

2.2 我最终选择：FFmpeg命令行 + 自研调度层

这个项目我选了第一种方案，也就是FFmpeg命令行为核心引擎，外面包一层自研的SpringBoot调度服务。理由很实际：

第一，功能覆盖最全。视频剪辑、音频提取、字幕烧录、编码转换这些高频需求，FFmpeg一条命令就能搞定，不需要写复杂的帧级操作代码。第二，性能最优。FFmpeg是C语言极致优化过的原生程序，针对不同CPU指令集都有专门优化，同样的裁剪任务，比纯Java实现快好几倍。第三，排错方便。FFmpeg的命令行参数可以在终端直接试跑，验证通过再搬进代码，调试效率比在Java层排查JNI错误高得多。

代价就是要在部署环境里装FFmpeg。但这个代价完全可控，生产环境用Docker镜像直接装，开发环境用包管理器装，统一版本，不折腾。

注意：如果你决定走命令行方案，我强烈建议锁定FFmpeg版本。不同版本的filter语法差异非常大，开发时用4.4跑通的命令，放到5.1环境可能直接报错。版本不一致是我踩过的最多坑之一。

2.3 SpringBoot在中间到底扮演什么角色

SpringBoot在这套架构里，核心管三件事：任务调度、参数组装、状态管理。

任务调度方面，视频处理是典型的耗时操作，一个5分钟的1080p视频做硬字幕烧录，跑个一两分钟很正常。这种任务必须异步化，不能占用HTTP请求线程。我用Spring自带的@Async配合线程池，把每个任务丢到独立线程里执行，同时支持并发任务数量上限。

参数组装是另一个关键设计。FFmpeg的命令行由大量参数拼装而成，比如裁剪用的-t / -ss、滤镜用的-vf、字幕烧录的-ass，如果直接在业务代码里手写字符串拼接，后面维护就是灾难。我把每个操作封装成独立的方法，输入是业务对象，输出是完整命令，中间参数校验、过滤转义、路径处理都在封装层完成。

状态管理负责把"任务处于什么阶段"同步给前端。视频处理对用户来说是黑盒，如果不回传进度，用户只会看到一直在转圈。这里我用数据库表记录任务状态，Redis做实时进度缓存，前端通过WebSocket轮询获取进度。

架构上总共三层：

• 接入层：Controller接收任务请求，生成任务ID
• 调度层：异步线程池执行任务，管理FFmpeg子进程和状态流转
• 执行层：对FFmpeg命令的封装，包括命令构建、执行、结果解析

3. 核心流程设计与接口实现

3.1 从零开始的接口架构

这个项目的接口设计有一个核心原则——所有视频处理任务都是异步的，同步只返回任务ID。

为什么这么设计？视频处理不是数据库查询，不可能在几百毫秒内返回结果。如果做成同步接口，前端HTTP请求会长时间占用，网关超时、负载均衡断开这些问题全都会冒出来。异步接口配合前端轮询，是解决这类问题最朴素也最可靠的方案。

核心接口我设计了这几个：

这里我补充说为什么把"上传"和"处理"分开。最初的设计是上传接口直接带处理参数，一步到位。后来发现运营人员经常先上传素材、隔天再配置剪辑参数，拆开之后素材可以复用，不用重复上传，也给后续做素材库管理留了空间。

3.2 任务状态机设计

视频处理任务从提交到完成，状态流转必须明确。我的设计里用了一套简单的状态机：

PENDING -> RUNNING -> SUCCEEDED | | v v FAILED CANCELED

PENDING是任务刚创建，还没进入线程池；RUNNING是FFmpeg子进程正在执行；SUCCEEDED是处理成功，产物文件可下载；FAILED是执行出错，错误信息已记录；CANCELED是用户主动取消。

这里有个容易忽略的细节：CANCELED状态不是随便就能进入的。FFmpeg子进程一旦启动，强制杀掉可能生成损坏的半成品文件。所以取消不是杀进程，而是先给子进程发退出信号，让FFmpeg清理临时文件后再退出。实现上，我给每个任务保存了Process对象，取消时先调destroy()，等2秒再看进程是否真的退出，不行再destroyForcibly()。

状态表里的progress字段，是用来记录FFmpeg处理进度的。FFmpeg的进度信息输出格式比较原始，一行一行的速度、时间码、比特率。我需要解析这些输出，换算成0到100的整数百分比。解析方式后面详细写，这里先不展开。

3.3 数据库表结构设计

任务管理表的设计，直接决定后面扩展是不是顺手。我的表结构大概长这样：

CREATE TABLE video_task ( id BIGINT AUTO_INCREMENT PRIMARY KEY, task_id VARCHAR(64) NOT NULL UNIQUE, task_type VARCHAR(32) NOT NULL COMMENT '任务类型: CLIP/MERGE/AUDIO/SUBTITLE', status VARCHAR(16) NOT NULL, progress INT DEFAULT 0, source_file VARCHAR(512), output_file VARCHAR(512), params_json TEXT COMMENT '附加参数JSON', error_msg VARCHAR(1024), created_at DATETIME, updated_at DATETIME );

task_type字段非常关键，它决定了任务创建后走哪条执行链路。前端提交剪辑任务，task_type就是CLIP；提交音频提取，就是AUDIO。执行层根据task_type分派到对应的CommandBuilder，每种Builder只负责自己那类命令的组装。

params_json用于存储各种处理参数。比如剪辑任务的起止时间、音频任务的音量增益、字幕任务的字幕文件路径。用JSON的好处是灵活，新增处理参数不需要改表结构，解析时用Jackson直接转成Map或对应DTO就行。

4. 视频剪辑功能实现详解

4.1 裁剪命令的坑与技巧

视频裁剪是最基础的功能，但命令怎么写，直接决定导出视频的播放流畅度。

很多教程给的命令是这样：

ffmpeg -i input.mp4 -ss 00:01:00 -to 00:02:00 -c copy output.mp4

这条命令意思是：input.mp4作为输入，从1分处开始到2分处结束，流复制模式重新封装。但如果你直接这么用，大概率会遇到一个诡异现象：视频开头会黑屏或花屏一两秒，部分播放器还会出现时间错乱。

原因在于：-ss放在-i前面和后面的行为是完全不同的。放在-i前面，FFmpeg是快速seek到指定位置，起播速度快，但因为是关键帧对齐，实际裁出来的起始帧不一定是你要的精确那一帧；放在-i后面，FFmpeg会先解码再裁，精确到帧，但seek之前的那段视频会被先解码，耗时更长。

正确处理分两种情况：

如果追求精确剪辑（比如做逐帧剪辑），用精确模式：

ffmpeg -i input.mp4 -ss 00:01:00 -to 00:02:00 -c copy -avoid_negative_ts make_zero output.mp4

如果追求速度（比如批量裁剪预览片段），用快速模式：

ffmpeg -ss 00:01:00 -to 00:02:00 -i input.mp4 -c copy -avoid_negative_ts make_zero output.mp4

我在这上面耗费了整整一个下午，才弄明白为什么同样一条命令，有的视频裁出来正常，有的开头就有花屏。后面试着用快速模式，再把-avoid_negative_ts加上，问题才彻底解决。这个参数的作用是避免输出文件的时间戳为负数，也就是它改变了整个时间基准处理方式，规避了很多播放器的兼容性bug。

4.2 多段视频拼接的两种实现方式

多段视频拼接，在项目里被用来做"把直播回放按广告点切开的片段重新拼成全片"这个场景。实现方式有两种，很多人一上来就选复杂的那种，结果给自己挖坑。

方式一：concat demuxer（推荐）

把多个片段的文件路径写进一个列表文件，然后用一条命令拼接：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4

filelist.txt内容：

file '/path/to/part1.mp4' file '/path/to/part2.mp4' file '/path/to/part3.mp4'

这种方式的前提是：所有片段的编码参数必须完全一致，分辨率、帧率、编码器、像素格式都一样，否则拼接处会出现音画不同步或花屏。优点是速度快，因为-c copy不做重编码，只是复制数据流，几乎不消耗CPU。

方式二：filter_complex（兼容性最强）

如果片段参数存在差异，concat demuxer就不能用了，必须上filter：

ffmpeg -i part1.mp4 -i part2.mp4 -filter_complex "[0:v][0:a][1:v][1:a]concat=n=2:v=1:a=1[v][a]" -map "[v]" -map "[a]" output.mp4

这条命令的意思是：concat滤镜把两路输入按视频和音频分别拼接，v=1表示输出单条视频流，a=1表示输出单条音频流。如果片段参数不一致，这个命令会自动进行参数统一处理，代价是每个片段都要重新编码，耗时和CPU开销大很多。

项目里，我做了个判断逻辑：片段列表先做参数探测，编码参数一致就走方式一，不一致就走方式二。这样速度和质量都能兼顾。

4.3 时间轴顺序控制与参数校验

视频拼接还有一个需求是打乱顺序，比如根据运营配置的片段顺序动态拼接。这个逻辑不复杂，列表文件的顺序决定了拼接顺序，只要在生成filelist.txt时按运营配置的顺序排列即可。

但参数校验这里有个很重要的点——时间点校验。用户提交的剪辑任务，起止时间必须合法，beginTime小于endTime，endTime不能超过视频总时长。这些校验应该在提交任务时做，而不是放到执行阶段。如果放到执行阶段，任务一跑起来，所有资源都开始分配，时间到了却发现参数不合法，钱和时间都浪费了。

校验方式很简单：用FFmpeg自带的ffprobe工具读取视频元信息，拿到总时长：

ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 input.mp4

Java层用ProcessBuilder执行这个命令，解析返回的秒数。这个操作本身需要几百毫秒，但对于任务校验来说是完全可以接受的。

5. 音频处理实战记录

5.1 提取音频、音量调节、格式转换

音频处理在项目里的需求很集中：从视频中提取音频、调节音量、混音、格式转换。

从视频中提取音频是最基础但同时也是最容易被忽略的功能。很多新人以为提取音频就是把视频文件里的音频流抽出来，复制一下就行，但其实音频封装格式不匹配会导致很多播放器直接打不开。实际做法是重采样：

ffmpeg -i input.mp4 -vn -acodec pcm_s16le -ar 44100 -ac 2 output.wav

这条命令的意思是：-vn表示丢弃视频流，-acodec指定音频编码为PCM 16位小端，采样率44100Hz，双声道。输出一个标准WAV文件，方便后面做音频分析或混音处理。

音量调节也常被误以为要用复杂的audio filter。其实很简单，一个volume滤镜就搞定了：

ffmpeg -i input.wav -af volume=1.5 output.wav

音量增益倍数设对了就行，不涉及什么神秘的编解码技术。混音则稍微复杂一点，需要把多个音频流按时间偏移混合成一条音轨。

5.2 音频混音：背景音乐与配音叠加

背景音乐叠加、配音与原始音频混音，这类需求在视频剪辑工具里几乎是标配。FFmpeg的amix滤镜可以直接做多路混音：

ffmpeg -i narration.wav -i bgm.mp3 -filter_complex "[0:a]volume=1.0[narr];[1:a]volume=0.3[bgm];[narr][bgm]amix=inputs=2:duration=first:dropout_transition=3[out]" -map "[out]" mixed.wav

这条命令的意图是：narration.wav作为主配音，音量保持1.0，bgm.mp3作为背景乐，音量降到0.3避免盖过配音。amix滤镜把两路输入混合，duration=first表示输出时长以第一路输入也就是配音为准，背景乐在配音结束后自动淡出，dropout_transition=3表示淡出过渡时间为3秒。

amix还有个容易踩的坑：如果输入音频的声道数不一致，比如一路是单声道、一路是双声道，amix会报错或产生奇怪的输出。所以混音前应该先统一声道数，用aresample滤镜做重采样：

ffmpeg -i narration.wav -i bgm.mp3 -filter_complex "[0:a]aformat=sample_fmts=fltp:sample_rates=44100:channel_layouts=stereo[narr];[1:a]volume=0.3,aformat=sample_fmts=fltp:sample_rates=44100:channel_layouts=stereo[bgm];[narr][bgm]amix=inputs=2:duration=first[out]" -map "[out]" mixed.wav

这样强制把两路输入统一成浮点PCM、44100Hz采样率、立体声，amix就不会出问题了。

5.3 音画同步问题的经典排查方法

音画不同步，在我做视频处理项目时遇到的频率非常高，基本每个处理流程都可能碰到。有一个排查思路值得写下来，可以让你少走很多弯路。

第一步，先确认源文件是否本来就不同步。用ffprobe看视频流和音频流的起始时间：

ffprobe -v error -select_streams v:0 -show_entries stream=start_time -of csv=p=0 input.mp4 ffprobe -v error -select_streams a:0 -show_entries stream=start_time -of csv=p=0 input.mp4

如果两个start_time相差超过50ms，源文件本身就不同步，后面处理再怎么做都白搭。

第二步，确认处理过程中的时间戳是否被打乱。特别是用-c copy模式做裁剪时，如果在关键帧位置切，可能导致音频和视频的时间基准错位。解决办法是加上-avoid_negative_ts make_zero，或者干脆改用重编码模式。

第三步，看是不是滤镜链导致的。filter_complex处理多个输入时，如果各输入的时长或时间戳不统一，会产生补偿延迟。这里可以用asetpts=PTS-STARTPTS滤镜重置时间戳：

ffmpeg -i video.mp4 -i audio.mp3 -filter_complex "[0:v]setpts=PTS-STARTPTS[v];[1:a]asetpts=PTS-STARTPTS[a]" -map "[v]" -map "[a]" output.mp4

这套三步排查法，我后来写成了内部工具脚本，每次音画不同步先跑这三步，比直接懵着改命令效率高太多。

6. 字幕处理：从软字幕到硬字幕

6.1 字幕文件格式与解析

字幕处理是这个项目里最容易让人手足无措的部分，因为字幕格式的多样性一开始会让人无从下手。最常见的三种格式是SRT、ASS和VTT，每种格式的解析方式各不相同。

SRT格式最基础，结构是序号+时间轴+文本：

1 00:00:01,000 --> 00:00:04,000 你好，欢迎观看 2 00:00:05,000 --> 00:00:08,000 这是第二行字幕

ASS格式功能最全，支持样式定义、字体、颜色、位置动画。VTT是Web字幕标准，浏览器原生支持。

Java里解析SRT很简单，正则表达式就能搞定：

Pattern pattern = Pattern.compile("(\\d{2}:\\d{2}:\\d{2},\\d{3}) --> (\\d{2}:\\d{2}:\\d{2},\\d{3})");

逐行读取文件，匹配时间轴，把起始时间、结束时间和文本内容封装成字幕对象列表。

ASS格式则推荐用第三方库JAssParser，手动解析ASS的样式标签和事件表工作量太大，没必要自己造轮子。

6.2 软字幕封装：保留原始字幕信息

软字幕是把字幕文件封装进视频容器里，播放时由播放器选择是否显示。好处是字幕可以随时切换或关闭，视频画质不受影响。

FFmpeg支持把SRT或ASS封装进MKV：

ffmpeg -i video.mp4 -i subtitle.srt -c copy -c:s srt output.mkv

但如果是MP4容器，对字幕的支持就有限了。MP4一般只支持mov_text字幕格式：

ffmpeg -i video.mp4 -i subtitle.srt -c copy -c:s mov_text output.mp4

这里有个兼容性问题：很多国产播放器对mov_text的支持很差，软字幕在MP4里可能完全不显示。所以我在这类场景下，通常会直接推荐硬字幕方案。

6.3 硬字幕烧录：把文字刻进画面

硬字幕也叫烧录字幕，是把字幕渲染到视频帧上，成为画面的一部分。所有播放器都能正常显示，代价是必须经过一次完整的视频重编码，所以耗时比软字幕长很多。

硬字幕烧录用FFmpeg的subtitles滤镜：

ffmpeg -i input.mp4 -vf "subtitles=subtitle.srt:force_style='FontName=Microsoft YaHei,FontSize=18,PrimaryColour=&H00FFFFFF'" output.mp4

这条命令会给输入视频叠加subtitle.srt字幕，字体指定为微软雅黑、字号18、颜色白色。force_style参数可以覆盖字幕文件里的样式设置。

字幕烧录最容易翻车的问题是中文字体。FFmpeg在Linux系统上默认找不到中文字体，烧出来的字幕全是方块。解决方法是确保系统里安装了中文字体，比如：

apt-get install -y fonts-wqy-zenhei

或者在force_style里指定字体的完整路径：

-force_style "FontName=/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc"

我推荐用完整路径的方式，不依赖系统字体索引，部署到新环境也不容易被遗漏。

6.4 中文字体路径问题与解决方案

中文字体问题是跨平台视频处理服务特有的坑，我第一次在Linux服务器上跑字幕烧录时，输出视频里的字幕全是"口口口"方块，排查了大半天才意识到是字体缺失。

既然说到了这里，就再补一个细节：ASS字幕和SRT字幕在烧录时的行为有所差异。ASS字幕自身带有样式定义，如果你不在命令行指定force_style，FFmpeg会使用ASS文件里的样式；但如果ASS文件里引用了系统不存在的字体，同样会出方块。解决办法是提前检查字体是否可用。

提供一个通用检查方法，列出系统已安装的中文字体：

fc-list :lang=zh

如果输出为空，说明没有中文字体，需要先安装。这个检查应该写进部署脚本里，而不是等到任务执行时才想起来。

7. 常见问题与排查技巧实录

7.1 内存溢出与异步线程池调优

这个项目上线初期，遇到的第一个大问题就是OOM。业务高峰期，同时提交多个视频处理任务，JVM直接抛出OutOfMemoryError。原因是视频处理任务的临时文件、缓存对象和Ffmpeg子进程的IO缓冲区，都在各自挤占内存。

解决方案有几个，我逐个说。

第一步，把异步线程池的配置优化好。Spring的@Async默认使用的SimpleAsyncTaskExecutor会导致每个任务创建新线程，在高并发下线程数失控。我改成自定义线程池：

@Bean("videoTaskExecutor") public ThreadPoolTaskExecutor videoTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(2); executor.setMaxPoolSize(4); executor.setQueueCapacity(100); executor.setThreadNamePrefix("video-task-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }

这里我刻意把核心线程数设得很小。视频处理任务有两个特点：一是线程阻塞时间极长，二是CPU密集型操作不多，主要瓶颈在IO和编码器。所以线程池数量不宜过大，否则频繁上下文切换会拖垮整个服务。2核4线程跑4个并发任务，实践下来最稳。

第二步，限制FFmpeg子进程的内存使用。通过limit参数限制子进程资源：

ffmpeg -i input.mp4 -vf "subtitles=subtitle.srt" -threads 2 output.mp4

-threads 2限制编码线程数，避免多任务同时启动时CPU被吃满。同时在任务执行层加一个信号量，控制同时运行的FFmpeg进程数不超过配置的上限。

7.2 中文文件名与乱码问题

Java在Linux系统上的中文路径问题，触发场景非常典型——前端上传的视频文件名是"测试视频.mp4"，后端接收后保存到本地，存到数据库里显示正常，但FFmpeg一执行就报找不到文件或者干脆解析不了参数。

这个问题的根源在于字符编码不一致。Java内部字符串是UTF-16，Linux文件系统默认UTF-8，而ProcessBuilder在Windows系统上会把字符串转成系统默认编码传递，在中文环境下可能导致参数错乱。

最稳妥的解决方案是：入库前强制重置文件名为统一规则。我坚持所有上传文件在保存时都重命名为UUID格式：

String extension = FilenameUtils.getExtension(originalFilename); String savedFileName = UUID.randomUUID() + "." + extension;

一切操作都用这个新文件名，中文只在业务数据库里保留，文件系统层面不使用中文名。这样彻底跳过了中文编码问题。

字幕文件的内容本身也可能包含中文，特别是SRT文件和UTF-8 BOM头的问题。有些Windows创建的SRT文件带BOM头，FFmpeg能正常读取，但Java读取进行解析时，BOM头会被当成三个乱码字符。处理方式是统一用InputStreamReader指定UTF-8读取，并跳过BOM：

InputStream inputStream = new FileInputStream(file); PushbackInputStream pushbackInputStream = new PushbackInputStream(inputStream, 3); byte[] bom = new byte[3]; int len = pushbackInputStream.read(bom); if (!(len == 3 && (bom[0] & 0xFF) == 0xEF && (bom[1] & 0xFF) == 0xBB && (bom[2] & 0xFF) == 0xBF)) { pushbackInputStream.unread(bom, 0, len); } BufferedReader reader = new BufferedReader(new InputStreamReader(pushbackInputStream, StandardCharsets.UTF_8));

这样BOM被检测并跳过后，后面逐行解析就不会出乱码。

7.3 编码格式不支持与转码策略

视频处理服务上线后，一定会遇到各种各样的输入文件。有些是手机录制的HEVC格式，有些是剪辑软件导出的ProRes，还有些是监控设备生成的H.265文件。这些文件用FFmpeg处理时，如果处理器不兼容源编码格式，会出现一堆报错或者干脆卡死。

最保守的做法是统一先转H.264。H.264是当前兼容性最好的视频编码，几乎所有播放器和设备都支持。处理流程改造为：

ffmpeg -i input.mov -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k output.mp4

这个命令把输入转成H.264+AAC格式的MP4文件，预设fast平衡转码质量和速度，CRF 23是画质和体积的常规平衡点。这样经过统一转码后的文件，再走后续的剪辑、拼接、字幕烧录流程，所有模块都能在已知的编码环境下运行，问题少很多。

当然，统一转码会加大处理耗时，但如果源文件编码类型不确定性较高，这也是唯一可靠的路线。如果源文件大概率是H.264编码，可以在拼接前先用ffprobe判断编码类型，只有非H.264的文件才强制转码，这样能在可靠性和性能之间取得平衡。

8. 生产环境部署与性能压测记录

8.1 Docker镜像构建与FFmpeg依赖打包

生产环境部署用的Docker镜像，需要同时包含JDK、FFmpeg和系统字体。Dockerfile写起来有几个细节需要注意：

FROM ubuntu:22.04 RUN apt-get update && apt-get install -y \ openjdk-17-jdk \ ffmpeg \ fonts-wqy-zenhei \ && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY target/video-processor.jar /app/app.jar EXPOSE 8080 CMD ["java", "-Xms512m", "-Xmx1g", "-jar", "app.jar"]

基础镜像选择Ubuntu 22.04，因为它的apt源默认自带FFmpeg 4.4，不用额外添加PPA仓库。fonts-wqy-zenhei是文泉驿正黑字体，负责中文字幕渲染。JVM参数把堆内存上限设为1GB，因为任务处理大头在FFmpeg子进程，JVM本身扮演调度角色，不需要分配太多堆内存。

8.2 并发处理能力与压测结果

上线前做了一轮压测，我直接以压测数据分析一下：

从数据可以看出，FFmpeg并发上限为2的时候，4个字幕烧录任务排到了84秒，属于可接受范围。如果业务量峰值更高，可以适当提高并发上限，但一定要注意CPU核数，不要一昧堆并发。

我有一个建议：任务队列里增加优先级字段，紧急任务可以插队执行。

8.3 任务积压与熔断机制

高并发下，任务积压无法避免。最忌讳的做法是无限堆积任务，结果服务挂掉重启，所有任务全部丢失。我在任务提交层加了一个简单的熔断逻辑：如果Redis里排队中的任务数超过预设阈值，直接拒绝新的任务提交，返回清晰提示：

if (pendingTaskCount > MAX_PENDING_TASKS) { throw new BusinessException("任务队列已满，请稍后再试"); }

这里MAX_PENDING_TASKS按实际并发能力配置，比如FFmpeg并发上限是4，队列上限就配置为100，保证任务提交永远可预期。任务积压时前端轮询状态，用户能看到等待中的提示，而不是请求超时或直接报错。

9. 写在最后：我的几点实战心得

项目从立项到上线大约花了三周时间，中间踩过的坑、填过的洞、重写的代码，比正常工作节奏多出一倍不止。复盘下来，有三点经验是真正有价值的。

第一，视频处理领域，FFmpeg就是唯一真神。Java的封装层再花哨，底层能力始终离不开FFmpeg。与其研究各种封装库，不如直接学透FFmpeg的命令行用法和filter语法。JavaCV虽然也是封装，但它的封装层只是为了让你不直接碰JNI，调试起来反而更难。

第二，状态机和异步任务是这类系统的命脉。视频处理的单次耗时很长，任务状态必须准确传递，任何一步状态丢数据，都会导致用户看到"处理中"然后永远等不到结果。用数据库记录状态，用Redis做进度缓存，两者结合才可靠。

第三，别怕临时文件和磁盘空间的消耗。视频处理大量依赖临时文件，一小时的1080p视频转码，临时空间可能吃掉几GB。上线前一定要对磁盘空间做监控和清理策略，否则服务跑几天磁盘写满，整个系统直接瘫痪。

最后再分享一个小技巧：所有FFmpeg命令在执行前，先拼好字符串，打印到日志里。故障排查时，日志里能看到完整的命令，直接复制到服务器上跑一遍，很多问题当场就能定位。这条建议，在我排查过的所有视频处理问题里，帮我节省的时间累积超过一个工作日。

本文还有配套的精品资源，点击获取