尧图网页设计 
1. 项目概述Java漫剧系统的视频处理到底在做什么这两年动漫短剧漫剧平台越来越多本质上就是把原本静态的漫画分镜配上动态效果、配音、音效切成3到5分钟一集的竖屏短内容。我自己用Java技术栈从零搭过一套漫剧后台核心业务除了用户、会员、支付最重的一块反而是视频处理。它不像普通视频网站那样只做点播转码漫剧内容有非常强的批量属性——一部漫画动辄上百集每集只有几分钟但上线周期极短视频处理这条链路如果设计不好后面审核、上架、分发全部会被卡住。这篇文章围绕Java漫剧系统也适用动漫短剧系统的视频处理方案展开重点讲清楚从原始视频上传到最终播放的这一整条链路在Java后端里怎么设计、怎么实现、有哪些坑。内容包括视频处理的整体技术选型、FFmpeg转码与封面抽帧、HLS切片与加密、任务调度与失败重试、以及上线之后真实遇到过的环境问题和性能问题。适合正在做或准备做漫剧、短剧类平台的Java开发同学参考也适合想了解视频处理服务端怎么落地的人。不是教科书是我实际跑过、踩过、优化过的项目经验。因为我负责的主要是后端所以内容会集中在Java这一侧任务编排、进程管理、数据模型、异步重试、踩坑排查。至于FFmpeg本身我不讲那些天花乱坠的滤镜参数只讲漫剧这个场景下真正用得到、压得住线上问题的方案。2. 整体设计思路先想清楚视频处理链路的边界2.1 漫剧视频的特殊性批量、短小、并发集中漫剧系统和传统的长视频平台有个非常大的区别内容生产是批量的。一部漫画授权下来制作方会一次性交付几十上百集原始视频。如果视频处理流程是串行的、人工操作的那上线进度会被拖死。所以从设计第一天视频处理就不能定位成“管理员上传一个视频后台转一下”而是一个自动化的批量流水线视频进来之后自动入队、自动转码、自动切片、自动加密、自动通知上架。另一个特点是短。单集时长通常3到8分钟分辨率以竖屏为主常见的是1080x1920、720x1280也有部分平台支持横屏。短带来一个好处单次转码耗时可控。中等配置的服务器一集3分钟的竖屏视频FFmpeg转码加切片基本在1分钟内能完成。这让Java后端做进程编排时不用太担心单个任务把服务器拖垮更大的压力来自高并发集中提交比如制作方一次性推了100集进来。还有一点容易被忽略漫剧视频通常需要保留封面图。平台首页、剧集列表、详情页都要用封面而且不同位置需要的尺寸不一样。封面怎么从视频里抽帧、抽哪一帧、怎么裁剪这些也是视频处理要解决的问题。2.2 Java在视频处理链路中的定位不是处理视频而是编排处理很多Java开发第一次接触视频处理会有一个误区想用Java代码直接去改视频。实际没必要也不现实。视频编解码这种活行业标准就是FFmpeg底层是C语言实现的性能和稳定性经过了大规模验证。Java在其中的定位是“总调度”负责接收任务、调起FFmpeg进程、监控执行结果、把产物上传到对象存储、更新任务状态、处理失败重试。这个边界想清楚之后技术上反而简单了Java不需要懂音视频编解码的细节只需要学会怎么正确地和FFmpeg进程打交道。具体来说有三个关键点进程管理用ProcessBuilder或者Apache Commons Exec调起FFmpeg关键是处理好stdin、stdout、stderr避免进程阻塞或者僵尸进程。参数拼装转码参数、切片参数、抽帧参数本质上是拼命令行字符串参数错了FFmpeg直接报错退出。异步与重试每个视频任务耗时几十秒到几分钟不能同步等待必须异步化而且要有失败重试机制。我之前见过有团队把转码做成同步接口前端上传视频后HTTP请求挂着等5分钟负载均衡都超时了这就是没想清楚边界。Java处理视频的正确姿势是接口只负责接收任务立刻返回“处理中”真正的转码全部丢到异步队列里慢慢跑。2.3 核心技术栈选型为什么是Spring Boot FFmpeg Redis MQ我做的这套系统核心组件包括Spring Boot 2.7老规矩稳定生态全招人好招。FFmpeg 4.4命令行工具负责所有视频编解码、切片、抽帧。为什么不用Java系的JCodec或者JavaCV后面细说。Redis用来做分布式锁、任务计数器、去重。RocketMQ异步任务队列削峰填谷。如果用不上MQ至少也要用线程池加数据库任务表不能裸同步。MinIO私有化部署的对象存储兼容S3协议存原始视频和转码产物。云上直接用阿里云OSS或者腾讯云COS也行。MySQL存视频素材表、任务表、转码产物表。选这套组合的核心逻辑是视频处理是重I/O、重进程的任务Java只做协调和编排队列选MQ是为了应对批量提交的流量冲击同时天然支持失败重试和延迟重试Redis则负责解决多实例部署时的并发冲突。3. 核心流程拆解从上传到上架一条链路六步走3.1 完整流程上传、入库、转码、切片、审核、上架我实际落地的时候把整条视频处理链路拆成了六个阶段每一阶段对应一个任务状态。这里直接用状态机来理解上传制作方或运营在后台上传原始视频上传接口接收文件流先传到临时目录或对象存储的raw桶然后向任务表插入一条初始记录状态为UPLOADED。入库上传完成后写入视频素材表记录文件大小、原始文件名、MD5、存储路径同时把任务状态改成PENDING等待被消费者拉取。转码消费者拿到任务调起FFmpeg把原始视频转成多码率MP4同时抽帧生成封面产物上传到对象存储状态改成TRANSCODED。切片把转码后的MP4再切成HLS分片m3u8 ts这一步顺手做AES加密产物上传状态改成SLICED。审核切片完成后通知审核系统。因为是漫剧很多平台会做人机结合的抽帧审核脚本会自动抽取关键帧送到审核接口状态是REVIEWING。上架审核通过后更新视频状态为PUBLISHED同时生成播放列表CDN刷新预热整个流程结束。状态流转是我后来反复调整的重点。刚开始我只用了“待处理”和“已完成”两个状态结果线上出了问题根本定位不到是哪一步失败的。后来改成六状态之后排查问题效率高了很多哪个环节挂了看状态就知道。3.2 任务表怎么设计一张表撑起整个视频处理流水线任务表是整个视频处理系统的中枢所有环节都在围着它转。表结构我是这么设计的CREATE TABLE video_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, video_id BIGINT NOT NULL COMMENT 视频素材ID, task_type TINYINT NOT NULL COMMENT 任务类型1转码 2切片 3封面抽帧, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待处理 1处理中 2成功 3失败, retry_count INT NOT NULL DEFAULT 0 COMMENT 重试次数, max_retry INT NOT NULL DEFAULT 3 COMMENT 最大重试次数, priority TINYINT NOT NULL DEFAULT 5 COMMENT 优先级 1-10越小越优先, source_path VARCHAR(512) COMMENT 源文件路径, output_path VARCHAR(512) COMMENT 产物路径, error_msg VARCHAR(1024) COMMENT 失败原因, next_retry_time DATETIME COMMENT 下次重试时间, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, KEY idx_status_priority (status, priority, next_retry_time), KEY idx_video_id (video_id) ) COMMENT 视频处理任务表;几个字段的设计意图task_type是为了让一条流水线可以由多个独立任务组合比如转码和抽帧是两个任务可以并行next_retry_time配合status做延迟重试避免失败任务无限重刷priority是为了支持加急处理比如付费剧集的优先上架。索引的用法是消费者每次查询都走WHERE status 0 AND next_retry_time NOW() ORDER BY priority LIMIT 10配合MQ消费双保险。数据库表只是最终落点真正的任务触发还是走MQ。我用的RocketMQ生产者在上传接口里把videoId发到VIDEO_PROCESS_TOPIC消费者收到消息后先通过Redis的SETNX做分布式锁防止同一个videoId被多实例重复消费然后再去数据库把对应任务状态从PENDING改成PROCESSING再开始干活。3.3 为什么用MQ而不是直接用线程池这是个很经典的问题。单机场景下一个ThreadPoolExecutor加一个任务表确实够用我也见过很多项目是这么干的。但漫剧系统的视频任务有两个特点一是批量提交量很大制作方经常一次性传几十集二是任务执行时间长每个任务要占用独立进程跑FFmpeg线程池的核心线程数稍微设置不合理就可能出现大量任务排队等待而且一旦服务重启内存队列里的任务全丢。MQ的价值在这时就体现出来了削峰填谷、持久化不丢消息、天然支持延迟消息重试。RocketMQ的延迟消息可以做到10秒、30秒、1分钟、2分钟等不同等级正好用来做失败重试的退避。我之前踩过线程池方案的坑某天制作方一次性推了200集线程池队列堆到几千个任务服务OOM直接挂掉重启后队列清空那200集全丢了还得手工补任务。换成RocketMQ之后消息只要发出去就在Broker上存着消费者处理不过来就堆积服务重启也不丢稳得多。4. 视频转码与封面抽帧的Java落地4.1 为什么不用JavaCV直接用FFmpeg命令Java生态里有个JavaCV封装了FFmpeg的Java接口可以做到不依赖外部进程纯JVM内做编解码。我早期在调研阶段试过最后还是放弃原因有三个内存占用不可控JavaCV是在JVM堆内做编解码一个1080p视频的转码堆内存轻松吃掉几百MB多个任务并发时GC压力巨大很容易OOM。FFmpeg作为独立进程内存是系统级管理的用完即释放Java这边只需要管理进程生命周期。版本兼容问题JavaCV的FFmpeg版本是内置的想升级要跟着JavaCV发版节奏走但FFmpeg命令行工具直接下载新版二进制就行灵活得多。出问题好排查FFmpeg进程如果转码失败会在stderr输出非常详细的日志直接搜“Error”就能定位。JavaCV的异常栈往往很模糊真出了问题社区资料也少。所以我的选择是Java只负责拼参数、起进程、看日志、查结果FFmpeg老老实实当命令行工具用。4.2 Java如何正确调用FFmpeg进程这里直接给一段我线上在用的代码精简过。核心是用ProcessBuilder注意三点合并标准输出和错误输出、异步读取输出流防止缓冲区阻塞、设置超时强杀进程。public ExecResult execFFmpeg(ListString command, long timeoutSeconds) { ProcessBuilder pb new ProcessBuilder(command); pb.redirectErrorStream(true); // 合并stdout和stderr方便统一捞日志 long start System.currentTimeMillis(); Process process null; try { process pb.start(); // 必须异步消费输出流否则缓冲区写满后进程会被阻塞 AtomicReferenceString outputLog new AtomicReference(); Thread outputThread new Thread(() - { try (BufferedReader reader new BufferedReader( new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8))) { StringBuilder sb new StringBuilder(); String line; while ((line reader.readLine()) ! null) { sb.append(line).append(\n); // 只保留最后200行日志避免OOM if (sb.length() 100_000) { sb.delete(0, sb.length() - 100_000); } } outputLog.set(sb.toString()); } catch (IOException ignored) { } }); outputThread.setDaemon(true); outputThread.start(); boolean finished process.waitFor(timeoutSeconds, TimeUnit.SECONDS); if (!finished) { process.destroyForcibly(); // 超时强杀 return ExecResult.fail(执行超时已强制终止); } int exitCode process.exitValue(); if (exitCode 0) { return ExecResult.success(outputLog.get()); } return ExecResult.fail(exitCode exitCode 日志 outputLog.get()); } catch (IOException e) { return ExecResult.fail(启动进程失败: e.getMessage()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return ExecResult.fail(线程被中断); } finally { if (process ! null process.isAlive()) { process.destroyForcibly(); } } }这段代码有一些细节值得提redirectErrorStream(true)是我吃了亏才加的。刚开始没合并stderr单独一个流我偷懒没去读结果FFmpeg日志一多stderr缓冲区堵死进程卡住不动了。日志只保留后200行因为FFmpeg日志太啰嗦全量保留容易内存溢出。timeoutSeconds一定要设置。我设的是300秒一集短剧就算转码三档分辨率加切片正常不会超过5分钟超时基本就是输入文件损坏或者参数有问题直接杀掉重试更合理。4.3 转码参数设计竖屏漫剧的三种码率漫剧是竖屏内容我在线上用的分辨率和码率配比是档位分辨率视频码率音频码率适用场景高清1080P1080x19204000kbps128kbpsVIP/付费用户标清720P720x12802000kbps96kbps默认播放流畅540P540x9601000kbps64kbps弱网/低端机码率不是拍脑袋定的我算过短剧画面相对静态漫画分镜加轻度动效运动量远小于电影电视剧1080P用4000kbps足够清晰再高纯粹浪费存储和带宽。720P用2000kbps是我实测多轮之后得到的“画质和体积平衡点”。如果你做的是动态感很强的3D短剧码率适当上浮20%。对应的FFmpeg转码命令模板是这样ffmpeg -y -i input.mp4 \ -vf scale720:1280:force_original_aspect_ratiodecrease,pad720:1280:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -preset medium -b:v 2000k -maxrate 2200k -bufsize 4000k \ -c:a aac -b:a 96k -ar 44100 -ac 2 \ -movflags faststart \ output_720.mp4这里有个行业里常见的坑原始视频可能不是标准竖屏比例直接scale720:1280会把画面拉变形。所以必须用force_original_aspect_ratiodecrease加pad组合等比缩放后用黑边补齐。漫剧的制作方给的源文件倒基本都是1080x1920但总会有例外这个兜底逻辑必须写。4.4 封面抽帧不是随便抽一帧就行封面质量直接影响漫剧的点击率。我最初的做法是取视频第5秒的帧作为封面结果有些集数的第5秒正好是黑场过渡或者字幕叠底封面很难看。后来改成等间隔抽6帧用图像清晰度算法挑一帧最清晰的。FFmpeg抽帧命令ffmpeg -y -i input.mp4 -vf fps1/5,scale540:960 -frames:v 6 cover_%02d.jpg这段命令的意思是每隔5秒抽一帧最多抽6帧统一缩放到封面尺寸。抽完之后Java端用BufferedImage算每帧的拉普拉斯方差方差越大说明画面细节越丰富、越清晰挑最大的那张作为封面。这个逻辑不复杂但效果提升非常明显运营那边再也不用手工换封面了。5. HLS切片与视频加密把MP4变成可分发的内容5.1 为什么选择HLS而不是直接播放MP4MP4其实也能点播但漫剧这种多集内容我最后选了HLS切片方案。原因不复杂秒开体验好HLS是分段加载播放器先拉m3u8索引文件再拉前几个ts分片就能起播比整段MP4边下边播的起播速度快很多。防盗链HLS可以和AES-128加密配合ts分片全是密文即使被人扒了下载地址没有key也看不了。对漫剧平台来说版权保护是刚需。多码率无缝切换同一个视频出多档码率的m3u8播放器可以根据网络带宽自适应切换不会出现看一半卡住的情况。代价是多了一层切片存储ts分片数量多、大小碎对象存储的请求量会明显增加。这个开销换体验值得。5.2 Java调用FFmpeg做HLS切片和AES加密切片用FFmpeg可以一步到位命令模板如下ffmpeg -y -i input_720.mp4 \ -c:v copy -c:a copy \ -hls_time 10 \ -hls_list_size 0 \ -hls_key_info_file key_info.txt \ -hls_segment_filename output_720_%04d.ts \ output_720.m3u8重点说下hls_key_info_file这个参数。它指向一个文本文件内容格式是三行key_uri key_file_path iv_hex第一行是播放器用来拉取密钥的URI我们线上配的是/api/video/key/keyId由Java接口动态返回十六进制key内容。第二行是FFmpeg在切片时读取key内容的本地文件路径。第三行是IV向量可以固定也可以随机生成。实际 Java漫剧系统视频处理全链路：转码、切片与加密实践
1. 项目概述Java漫剧系统的视频处理到底在做什么这两年动漫短剧漫剧平台越来越多本质上就是把原本静态的漫画分镜配上动态效果、配音、音效切成3到5分钟一集的竖屏短内容。我自己用Java技术栈从零搭过一套漫剧后台核心业务除了用户、会员、支付最重的一块反而是视频处理。它不像普通视频网站那样只做点播转码漫剧内容有非常强的批量属性——一部漫画动辄上百集每集只有几分钟但上线周期极短视频处理这条链路如果设计不好后面审核、上架、分发全部会被卡住。这篇文章围绕Java漫剧系统也适用动漫短剧系统的视频处理方案展开重点讲清楚从原始视频上传到最终播放的这一整条链路在Java后端里怎么设计、怎么实现、有哪些坑。内容包括视频处理的整体技术选型、FFmpeg转码与封面抽帧、HLS切片与加密、任务调度与失败重试、以及上线之后真实遇到过的环境问题和性能问题。适合正在做或准备做漫剧、短剧类平台的Java开发同学参考也适合想了解视频处理服务端怎么落地的人。不是教科书是我实际跑过、踩过、优化过的项目经验。因为我负责的主要是后端所以内容会集中在Java这一侧任务编排、进程管理、数据模型、异步重试、踩坑排查。至于FFmpeg本身我不讲那些天花乱坠的滤镜参数只讲漫剧这个场景下真正用得到、压得住线上问题的方案。2. 整体设计思路先想清楚视频处理链路的边界2.1 漫剧视频的特殊性批量、短小、并发集中漫剧系统和传统的长视频平台有个非常大的区别内容生产是批量的。一部漫画授权下来制作方会一次性交付几十上百集原始视频。如果视频处理流程是串行的、人工操作的那上线进度会被拖死。所以从设计第一天视频处理就不能定位成“管理员上传一个视频后台转一下”而是一个自动化的批量流水线视频进来之后自动入队、自动转码、自动切片、自动加密、自动通知上架。另一个特点是短。单集时长通常3到8分钟分辨率以竖屏为主常见的是1080x1920、720x1280也有部分平台支持横屏。短带来一个好处单次转码耗时可控。中等配置的服务器一集3分钟的竖屏视频FFmpeg转码加切片基本在1分钟内能完成。这让Java后端做进程编排时不用太担心单个任务把服务器拖垮更大的压力来自高并发集中提交比如制作方一次性推了100集进来。还有一点容易被忽略漫剧视频通常需要保留封面图。平台首页、剧集列表、详情页都要用封面而且不同位置需要的尺寸不一样。封面怎么从视频里抽帧、抽哪一帧、怎么裁剪这些也是视频处理要解决的问题。2.2 Java在视频处理链路中的定位不是处理视频而是编排处理很多Java开发第一次接触视频处理会有一个误区想用Java代码直接去改视频。实际没必要也不现实。视频编解码这种活行业标准就是FFmpeg底层是C语言实现的性能和稳定性经过了大规模验证。Java在其中的定位是“总调度”负责接收任务、调起FFmpeg进程、监控执行结果、把产物上传到对象存储、更新任务状态、处理失败重试。这个边界想清楚之后技术上反而简单了Java不需要懂音视频编解码的细节只需要学会怎么正确地和FFmpeg进程打交道。具体来说有三个关键点进程管理用ProcessBuilder或者Apache Commons Exec调起FFmpeg关键是处理好stdin、stdout、stderr避免进程阻塞或者僵尸进程。参数拼装转码参数、切片参数、抽帧参数本质上是拼命令行字符串参数错了FFmpeg直接报错退出。异步与重试每个视频任务耗时几十秒到几分钟不能同步等待必须异步化而且要有失败重试机制。我之前见过有团队把转码做成同步接口前端上传视频后HTTP请求挂着等5分钟负载均衡都超时了这就是没想清楚边界。Java处理视频的正确姿势是接口只负责接收任务立刻返回“处理中”真正的转码全部丢到异步队列里慢慢跑。2.3 核心技术栈选型为什么是Spring Boot FFmpeg Redis MQ我做的这套系统核心组件包括Spring Boot 2.7老规矩稳定生态全招人好招。FFmpeg 4.4命令行工具负责所有视频编解码、切片、抽帧。为什么不用Java系的JCodec或者JavaCV后面细说。Redis用来做分布式锁、任务计数器、去重。RocketMQ异步任务队列削峰填谷。如果用不上MQ至少也要用线程池加数据库任务表不能裸同步。MinIO私有化部署的对象存储兼容S3协议存原始视频和转码产物。云上直接用阿里云OSS或者腾讯云COS也行。MySQL存视频素材表、任务表、转码产物表。选这套组合的核心逻辑是视频处理是重I/O、重进程的任务Java只做协调和编排队列选MQ是为了应对批量提交的流量冲击同时天然支持失败重试和延迟重试Redis则负责解决多实例部署时的并发冲突。3. 核心流程拆解从上传到上架一条链路六步走3.1 完整流程上传、入库、转码、切片、审核、上架我实际落地的时候把整条视频处理链路拆成了六个阶段每一阶段对应一个任务状态。这里直接用状态机来理解上传制作方或运营在后台上传原始视频上传接口接收文件流先传到临时目录或对象存储的raw桶然后向任务表插入一条初始记录状态为UPLOADED。入库上传完成后写入视频素材表记录文件大小、原始文件名、MD5、存储路径同时把任务状态改成PENDING等待被消费者拉取。转码消费者拿到任务调起FFmpeg把原始视频转成多码率MP4同时抽帧生成封面产物上传到对象存储状态改成TRANSCODED。切片把转码后的MP4再切成HLS分片m3u8 ts这一步顺手做AES加密产物上传状态改成SLICED。审核切片完成后通知审核系统。因为是漫剧很多平台会做人机结合的抽帧审核脚本会自动抽取关键帧送到审核接口状态是REVIEWING。上架审核通过后更新视频状态为PUBLISHED同时生成播放列表CDN刷新预热整个流程结束。状态流转是我后来反复调整的重点。刚开始我只用了“待处理”和“已完成”两个状态结果线上出了问题根本定位不到是哪一步失败的。后来改成六状态之后排查问题效率高了很多哪个环节挂了看状态就知道。3.2 任务表怎么设计一张表撑起整个视频处理流水线任务表是整个视频处理系统的中枢所有环节都在围着它转。表结构我是这么设计的CREATE TABLE video_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, video_id BIGINT NOT NULL COMMENT 视频素材ID, task_type TINYINT NOT NULL COMMENT 任务类型1转码 2切片 3封面抽帧, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待处理 1处理中 2成功 3失败, retry_count INT NOT NULL DEFAULT 0 COMMENT 重试次数, max_retry INT NOT NULL DEFAULT 3 COMMENT 最大重试次数, priority TINYINT NOT NULL DEFAULT 5 COMMENT 优先级 1-10越小越优先, source_path VARCHAR(512) COMMENT 源文件路径, output_path VARCHAR(512) COMMENT 产物路径, error_msg VARCHAR(1024) COMMENT 失败原因, next_retry_time DATETIME COMMENT 下次重试时间, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, KEY idx_status_priority (status, priority, next_retry_time), KEY idx_video_id (video_id) ) COMMENT 视频处理任务表;几个字段的设计意图task_type是为了让一条流水线可以由多个独立任务组合比如转码和抽帧是两个任务可以并行next_retry_time配合status做延迟重试避免失败任务无限重刷priority是为了支持加急处理比如付费剧集的优先上架。索引的用法是消费者每次查询都走WHERE status 0 AND next_retry_time NOW() ORDER BY priority LIMIT 10配合MQ消费双保险。数据库表只是最终落点真正的任务触发还是走MQ。我用的RocketMQ生产者在上传接口里把videoId发到VIDEO_PROCESS_TOPIC消费者收到消息后先通过Redis的SETNX做分布式锁防止同一个videoId被多实例重复消费然后再去数据库把对应任务状态从PENDING改成PROCESSING再开始干活。3.3 为什么用MQ而不是直接用线程池这是个很经典的问题。单机场景下一个ThreadPoolExecutor加一个任务表确实够用我也见过很多项目是这么干的。但漫剧系统的视频任务有两个特点一是批量提交量很大制作方经常一次性传几十集二是任务执行时间长每个任务要占用独立进程跑FFmpeg线程池的核心线程数稍微设置不合理就可能出现大量任务排队等待而且一旦服务重启内存队列里的任务全丢。MQ的价值在这时就体现出来了削峰填谷、持久化不丢消息、天然支持延迟消息重试。RocketMQ的延迟消息可以做到10秒、30秒、1分钟、2分钟等不同等级正好用来做失败重试的退避。我之前踩过线程池方案的坑某天制作方一次性推了200集线程池队列堆到几千个任务服务OOM直接挂掉重启后队列清空那200集全丢了还得手工补任务。换成RocketMQ之后消息只要发出去就在Broker上存着消费者处理不过来就堆积服务重启也不丢稳得多。4. 视频转码与封面抽帧的Java落地4.1 为什么不用JavaCV直接用FFmpeg命令Java生态里有个JavaCV封装了FFmpeg的Java接口可以做到不依赖外部进程纯JVM内做编解码。我早期在调研阶段试过最后还是放弃原因有三个内存占用不可控JavaCV是在JVM堆内做编解码一个1080p视频的转码堆内存轻松吃掉几百MB多个任务并发时GC压力巨大很容易OOM。FFmpeg作为独立进程内存是系统级管理的用完即释放Java这边只需要管理进程生命周期。版本兼容问题JavaCV的FFmpeg版本是内置的想升级要跟着JavaCV发版节奏走但FFmpeg命令行工具直接下载新版二进制就行灵活得多。出问题好排查FFmpeg进程如果转码失败会在stderr输出非常详细的日志直接搜“Error”就能定位。JavaCV的异常栈往往很模糊真出了问题社区资料也少。所以我的选择是Java只负责拼参数、起进程、看日志、查结果FFmpeg老老实实当命令行工具用。4.2 Java如何正确调用FFmpeg进程这里直接给一段我线上在用的代码精简过。核心是用ProcessBuilder注意三点合并标准输出和错误输出、异步读取输出流防止缓冲区阻塞、设置超时强杀进程。public ExecResult execFFmpeg(ListString command, long timeoutSeconds) { ProcessBuilder pb new ProcessBuilder(command); pb.redirectErrorStream(true); // 合并stdout和stderr方便统一捞日志 long start System.currentTimeMillis(); Process process null; try { process pb.start(); // 必须异步消费输出流否则缓冲区写满后进程会被阻塞 AtomicReferenceString outputLog new AtomicReference(); Thread outputThread new Thread(() - { try (BufferedReader reader new BufferedReader( new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8))) { StringBuilder sb new StringBuilder(); String line; while ((line reader.readLine()) ! null) { sb.append(line).append(\n); // 只保留最后200行日志避免OOM if (sb.length() 100_000) { sb.delete(0, sb.length() - 100_000); } } outputLog.set(sb.toString()); } catch (IOException ignored) { } }); outputThread.setDaemon(true); outputThread.start(); boolean finished process.waitFor(timeoutSeconds, TimeUnit.SECONDS); if (!finished) { process.destroyForcibly(); // 超时强杀 return ExecResult.fail(执行超时已强制终止); } int exitCode process.exitValue(); if (exitCode 0) { return ExecResult.success(outputLog.get()); } return ExecResult.fail(exitCode exitCode 日志 outputLog.get()); } catch (IOException e) { return ExecResult.fail(启动进程失败: e.getMessage()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return ExecResult.fail(线程被中断); } finally { if (process ! null process.isAlive()) { process.destroyForcibly(); } } }这段代码有一些细节值得提redirectErrorStream(true)是我吃了亏才加的。刚开始没合并stderr单独一个流我偷懒没去读结果FFmpeg日志一多stderr缓冲区堵死进程卡住不动了。日志只保留后200行因为FFmpeg日志太啰嗦全量保留容易内存溢出。timeoutSeconds一定要设置。我设的是300秒一集短剧就算转码三档分辨率加切片正常不会超过5分钟超时基本就是输入文件损坏或者参数有问题直接杀掉重试更合理。4.3 转码参数设计竖屏漫剧的三种码率漫剧是竖屏内容我在线上用的分辨率和码率配比是档位分辨率视频码率音频码率适用场景高清1080P1080x19204000kbps128kbpsVIP/付费用户标清720P720x12802000kbps96kbps默认播放流畅540P540x9601000kbps64kbps弱网/低端机码率不是拍脑袋定的我算过短剧画面相对静态漫画分镜加轻度动效运动量远小于电影电视剧1080P用4000kbps足够清晰再高纯粹浪费存储和带宽。720P用2000kbps是我实测多轮之后得到的“画质和体积平衡点”。如果你做的是动态感很强的3D短剧码率适当上浮20%。对应的FFmpeg转码命令模板是这样ffmpeg -y -i input.mp4 \ -vf scale720:1280:force_original_aspect_ratiodecrease,pad720:1280:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -preset medium -b:v 2000k -maxrate 2200k -bufsize 4000k \ -c:a aac -b:a 96k -ar 44100 -ac 2 \ -movflags faststart \ output_720.mp4这里有个行业里常见的坑原始视频可能不是标准竖屏比例直接scale720:1280会把画面拉变形。所以必须用force_original_aspect_ratiodecrease加pad组合等比缩放后用黑边补齐。漫剧的制作方给的源文件倒基本都是1080x1920但总会有例外这个兜底逻辑必须写。4.4 封面抽帧不是随便抽一帧就行封面质量直接影响漫剧的点击率。我最初的做法是取视频第5秒的帧作为封面结果有些集数的第5秒正好是黑场过渡或者字幕叠底封面很难看。后来改成等间隔抽6帧用图像清晰度算法挑一帧最清晰的。FFmpeg抽帧命令ffmpeg -y -i input.mp4 -vf fps1/5,scale540:960 -frames:v 6 cover_%02d.jpg这段命令的意思是每隔5秒抽一帧最多抽6帧统一缩放到封面尺寸。抽完之后Java端用BufferedImage算每帧的拉普拉斯方差方差越大说明画面细节越丰富、越清晰挑最大的那张作为封面。这个逻辑不复杂但效果提升非常明显运营那边再也不用手工换封面了。5. HLS切片与视频加密把MP4变成可分发的内容5.1 为什么选择HLS而不是直接播放MP4MP4其实也能点播但漫剧这种多集内容我最后选了HLS切片方案。原因不复杂秒开体验好HLS是分段加载播放器先拉m3u8索引文件再拉前几个ts分片就能起播比整段MP4边下边播的起播速度快很多。防盗链HLS可以和AES-128加密配合ts分片全是密文即使被人扒了下载地址没有key也看不了。对漫剧平台来说版权保护是刚需。多码率无缝切换同一个视频出多档码率的m3u8播放器可以根据网络带宽自适应切换不会出现看一半卡住的情况。代价是多了一层切片存储ts分片数量多、大小碎对象存储的请求量会明显增加。这个开销换体验值得。5.2 Java调用FFmpeg做HLS切片和AES加密切片用FFmpeg可以一步到位命令模板如下ffmpeg -y -i input_720.mp4 \ -c:v copy -c:a copy \ -hls_time 10 \ -hls_list_size 0 \ -hls_key_info_file key_info.txt \ -hls_segment_filename output_720_%04d.ts \ output_720.m3u8重点说下hls_key_info_file这个参数。它指向一个文本文件内容格式是三行key_uri key_file_path iv_hex第一行是播放器用来拉取密钥的URI我们线上配的是/api/video/key/keyId由Java接口动态返回十六进制key内容。第二行是FFmpeg在切片时读取key内容的本地文件路径。第三行是IV向量可以固定也可以随机生成。实际