1. 项目整体设计与思路拆解这个标题看起来很简单一句话就能念完但在真正的视频业务里它是所有点播系统、课程平台、短视频后台绕不开的基础设施问题。我先从业务场景说起用户上传了一个MP4文件服务器要把它变成能在网页端、移动端流畅播放的视频流。直接丢给播放器一个MP4链接行不行小文件可以大文件就出问题了——网速一波动播放器要么一直转圈要么用户拖进度条的时候卡死体验很差。M3U8切片方案从根上解决这个问题把一个完整视频切成一段段小TS文件再用一个索引文件M3U8告诉播放器“先播哪几段、每段多长、后面的哪几段”。播放器可以边下边播切换清晰度、做倍速、拖动进度条都变得很轻量。这就是HLSHTTP Live Streaming协议的核心思路也是苹果推出后、整个流媒体行业沉淀下来的主流方案。用Java来做这件事本质不是因为Java擅长转码而是因为Java是服务端最常用的业务语言只需要让Java去调用FFmpeg这个真正干活的引擎就行。FFmpeg负责“切”Java负责“调”、负责“管”——调度任务、管理并发、处理失败、对接数据库和OSS存储这才是合理分工。我见过不少新手在这个环节犯迷糊试图用纯Java代码去读取MP4文件、手动切割字节流结果不仅代码复杂到没法维护切出来的分片在播放器里还会花屏或音画不同步。正确做法是让FFmpeg做它擅长的事Java只做流程编排。如果你正在做一个档案存储系统、在线教育平台、企业内部媒体库或者任何“用户上传视频后要在网页里看”的场景这篇内容都合适。我的目标是让你不仅学会跑通一条命令还知道它在生产环境里怎么落得稳。想清楚这个划分整个项目的架构就清晰了一个接收任务并写入队列的入口、一个限制并发数的线程池、一个负责拼接并执行FFmpeg命令的调用器、一个监听执行过程的回调机制最后是产物M3U8索引 TS分片的存储与校验环节。下面我会一步步拆开。2. FFmpeg切片命令拆解一条命令背后的全套逻辑2.1 核心命令与参数速查FFmpeg切片转HLS的命令在官方文档里有标准写法我先给你一条最常用的、区分了H.264视频和AAC音频的命令ffmpeg -i input.mp4 \ -c:v libx264 -profile:v main -level:v 3.1 \ -preset veryfast -crf 23 \ -c:a aac -b:a 128k \ -hls_time 6 \ -hls_list_size 0 \ -hls_segment_filename output_%03d.ts \ -f hls output.m3u8参数含义我在实际项目中踩过一遍给你整理成表参数作用我的建议值备注-i input.mp4指定输入文件完整绝对路径路径含空格必须加引号-c:v libx264视频用H.264编码libx264兼容性最好的选择播放器基本都支持-profile:v mainH.264编码档次main老设备也能播别选high里的高Level-preset veryfast编码速度与压缩率权衡veryfast服务端追求速度压缩率略降没关系-crf 23恒定质量参数值越小质量越高23范围0-51大于28画质明显下降-hls_time 6每隔6秒切一个分片6并非严格6秒关键帧错位会导致误差-hls_list_size 0生成的m3u8里保留全部分片列表0不设0则只保留最近几条点播场景必须设0-f hls输出格式为HLShls也有hls,mpegts等2.2 分片时长到底是由谁决定的很多人以为-hls_time 6就是绝对准时6秒切一个片实际用一次就会发现生成的TS文件名可能标着6秒但有个别分片是7.2秒、4.8秒。这个现象不是bug因为HLS切片必须以视频的关键帧IDR帧为切割点。FFmpeg只能“尽量”按你指定的时间找最近的、可以独立解码的关键帧去切否则把两个关键帧中间的数据硬切开播放器拿到的是一个没法开头的分片。所以如果你要求服务器生成整整齐齐的6秒分片我建议加上强制关键帧间隔参数-force_key_frames expr:gte(t,n_forced*6)这条表达式的意思是每6秒的位置强制插入一个关键帧让后续的-hls_time 6能比较精确地对齐。代价是编码器会在指定位置主动插入大一点的帧导致整体码率略微上升但在服务器硬盘充裕的情况下换来的是均匀的分片时长和更稳定的播放体验划算。2.3 一定要重新编码吗直接复制流行不行从技术上说如果源视频本身就是H.264 AAC编码加个-c copy就能做到“不转码直接切”速度快得惊人。但从真实业务角度我强烈不建议在通用业务里这么干。理由有三个你无法控制用户上传的MP4格式。真遇到H.265HEVC编码的MP4-c copy能切出TS文件但绝大多数网页播放器不支持H.265直接播放黑屏没商量。源MP4的音频编码五花八门有的还是MP3或AC-3切出来的TS兼容性参差不齐。如果源文件里有损坏的包或者奇怪的元数据-c copy会把问题原封不动带进TS里而重新编码可以部分“洗掉”脏数据。所以在生产环境里我默认走转码路线。如果你闲着没事、只想本机快速看效果可以拿-c copy对比一下输出文件但你一定会发现源文件里某个花屏片段在切片后依然花屏因为数据没有被重新处理过。2.4 不想改编码参数做一条保底命令综合以上我把生产环境常用的一条保底命令贴出来照着抄不会出大问题ffmpeg -y -i input.mp4 \ -c:v libx264 -profile:v high -level:v 4.0 \ -preset veryfast -crf 22 -r 25 \ -force_key_frames expr:gte(t,n_forced*6) \ -c:a aac -b:a 128k -ac 2 \ -hls_time 6 \ -hls_list_size 0 \ -hls_segment_filename output_%03d.ts \ -f hls output.m3u8-r 25强制输出帧率25fps让关键帧间隔的计算更规整。-ac 2把音频强制转成双声道避免某些播放器对多声道AAC解析出错。-y表示覆盖输出文件防止同路径重复执行时报交互提示导致进程挂住。你把这些参数组装进Java后面就省心很多。3. Java调用FFmpeg的方案选型三种主流方式对比3.1 Runtime.getRuntime().exec 与 ProcessBuilder 的真实差距早期教程里最常见的写法是Runtime.getRuntime().exec(cmd)一行执行命令。但它在生产环境里有两个硬伤第一传参时如果命令里含空格和引号exec内部解析容易出错第二它默认通过字符串拆分命令遇到含特殊字符的文件路径例如英文括号、中文空格会拆错。ProcessBuilder从JDK 5就有了它支持直接传String数组或List天然规避了空格和特殊字符问题。我个人在实际项目中只用ProcessBuilder原因很简单用List传参时每个参数都是独立元素不需要自己拼转义字符更不用管操作系统是Windows还是Linux。某个文件名里有中文空格也不会把命令“拦腰截断”。3.2 阻塞、死锁与错误流新手最容易翻车的点调用FFmpeg这类继承了标准输出的外部进程时有个经典坑很多人会踩用process.getInputStream()去读输出日志但忘了同时处理getErrorStream()。FFmpeg默认把进度日志打到标准错误流如果你只读标准输出错误流的缓冲区很快就被写满进程会阻塞住一直等着父进程来取数据。我封装执行器的时候至少会起两个线程分别读标准输出和标准错误流。如果只是为了判断执行成功与否可以简化为只读错误流但如果要实现进度监控两个流都得保留。ProcessBuilder builder new ProcessBuilder(command); Process process builder.start(); // 必须同时消费两个流否则缓冲区满会导致子进程挂起 BufferedReader errorReader new BufferedReader( new InputStreamReader(process.getErrorStream()));3.3 三个可选方案对比Java世界里调用FFmpeg有三条路直接ProcessBuilder、封装命令行工具类、集成JAVE等第三方库。JAVE这类库本质是包了一层FFmpeg二进制调用省事但版本滞后遇到自定义参数反而束手束脚。我的选型建议是对于大多数业务系统自己封装ProcessBuilder执行器 命令拼接器最灵活、最可控、依赖也最少。4. 核心代码实现完整实现一个Java转M3U8执行器4.1 目录结构设计业务隔离与文件命名如果多个用户同时上传视频切出来的TS和M3U8不能全堆在同一个目录否则文件覆盖、命名冲突都是问题。我的做法是这样规划目录/home/www/video-store/{业务ID}/{视频ID}/ ├── source.mp4 ├── play.m3u8 └── ts/ ├── play_000.ts ├── play_001.ts └── ...业务ID可以是“课程”、“纪录片”、“用户投稿”视频ID是每条视频的唯一标识。顺着目录能让排查问题的人节省大量时间。文件名统一用play_%03d.ts格式保证播放器能按数字序号遍历分片。4.2 FFmpegCommandBuilder把命令拼装逻辑独立出来public class FfmpegCommandBuilder { public ListString buildHlsCommand(String inputPath, String m3u8Path, String tsDir) { ListString cmd new ArrayList(); cmd.add(/usr/local/bin/ffmpeg); cmd.add(-y); cmd.add(-i); cmd.add(inputPath); cmd.add(-c:v); cmd.add(libx264); cmd.add(-profile:v); cmd.add(high); cmd.add(-preset); cmd.add(veryfast); cmd.add(-crf); cmd.add(22); cmd.add(-hls_time); cmd.add(6); cmd.add(-hls_list_size); cmd.add(0); cmd.add(-hls_segment_filename); cmd.add(tsDir /play_%03d.ts); cmd.add(-f); cmd.add(hls); cmd.add(m3u8Path); return cmd; } }这里用到的是绝对路径/usr/local/bin/ffmpeg比直接写ffmpeg更稳。服务器上可能会装多个FFmpeg或者环境变量PATH没有把FFmpeg目录加进去真要执行失败的时候你会感谢自己写死了完整路径。4.3 执行器带超时与输出日志消费的调用实现public class FfmpegExecutor { public boolean execute(ListString command, long timeoutSeconds) throws IOException, InterruptedException { ProcessBuilder builder new ProcessBuilder(command); builder.redirectErrorStream(true); // 合并错误流到标准输出减少一个流处理 Process process builder.start(); // 单独线程消费输出避免缓冲区占满 Thread outputThread new Thread(() - { try (BufferedReader reader new BufferedReader( new InputStreamReader(process.getInputStream()))) { String line; while ((line reader.readLine()) ! null) { // 打印或解析 } } catch (IOException e) { // 日志记录 } }); outputThread.start(); boolean finished process.waitFor(timeoutSeconds, TimeUnit.SECONDS); if (!finished) { process.destroyForcibly(); return false; } // 等待输出线程结束确保日志都读完 outputThread.join(); return process.exitValue() 0; } }redirectErrorStream(true)这行值得单独说它把子进程的错误流合并到标准输出流这样父进程只要读一个流就行节省一个线程。这个写法在排查问题时也很舒服因为FFmpeg的日志按时间顺序混在一起输出不会被拆成两个互相穿插的乱序流。4.4 进度监控如何知道切片进行到百分之几waitFor只能告诉你“成功”还是“失败”如果用户上传了个几十GB的大视频转码过程可能持续十几分钟没有任何进度反馈会让用户以为系统挂了。FFmpeg输出日志里有特殊格式的进度字段形如frame 1200 fps135 q28.0 size 5120kB time00:00:48.00 bitrate 853.4kbits/s。解析方法不复杂读错误流时按time字段截取换算成秒再除以总时长就是百分比。代码可以这样处理String timePart line.replaceAll(.*time([\\d:.]).*, $1); String[] parts timePart.split(:); long totalSeconds Long.parseLong(parts[0]) * 3600 Long.parseLong(parts[1]) * 60 Long.parseLong(parts[2]); float progress (float) totalSeconds / videoDuration * 100;第一行正则里特别注意前后的.*要能覆盖整行内容。解析到进度后通过回调接口把值推给上层任务上层任务再对接WebSocket或消息推送业务端就能实时看到一个进度条。4.5 产物校验转码成功不等于产物可用切片任务返回exit code 0不代表M3U8一定能在播放器里播。生产环境里我见过好几次FFmpeg进程正常退出但M3U8文件是空的或者索引指向不存在的TS文件。这种情况常见于磁盘空间满、写入过程中被中断、并发清理任务误删文件等。我的校验流程收口于三件事M3U8文件非空且文件大小大于某个阈值几十字节都不到基本就是空的。M3U8里引用的所有TS文件真实存在。抽样检查M3U8里第一个TS文件的大小不是0字节。ListString tsNames readTsNamesFromM3u8(m3u8Path); boolean allExists tsNames.stream() .allMatch(name - Files.exists(tsDir.resolve(name)) Files.size(tsDir.resolve(name)) 0);这一步做完我才会认为任务真正成功再把产物路径写入数据库。5. 工程化落地并发、容错与资源控制的硬经验5.1 为什么不建议一次性并发跑100个FFmpegFFmpeg转码是CPU密集型任务单路1080p的转码能让一个2核的小服务器满载。如果业务接口收到10个上传请求代码里直接开10个线程各自跑FFmpeg服务器很容易被打挂其他服务的接口也跟着变慢。实际经验是用信号量控制并发数跑批任务时并发数不超过CPU核心数减一。Semaphore ffmpegSlots new Semaphore(availableProcessors - 1);如果CPU只有1核这个公式会得到0所以我是这样写的int slots Math.max(Runtime.getRuntime().availableProcessors() - 1, 1); Semaphore ffmpegSlots new Semaphore(slots);拿到信号量再启动ProcessBuilder否则任务进入等待队列。5.2 超时、重试与失败处理策略转码任务不是不能重试而是要有上限和策略。我用的规则是失败后先查日志如果是输入文件损坏FFmpeg直接打印Invalid data重试也没用直接标记失败。如果是磁盘空间不足或进程被杀杀完僵尸进程、清掉残留TS后再重试最多两次两次之间等待几秒。这些逻辑适合收口在一个TaskExecStatus状态机里初始状态NEW执行中RUNNING重试时RETRYING成功SUCCESS放弃FAILED。状态流转不做在Java代码里到处散落的if而是集中在一个接口里不然排查问题时光靠日志看状态极其痛苦。5.3 过期的M3U8和TS分片谁来清理切分片任务跑完目录里会残留很多TS文件。如果用户后来重新上传了视频旧分片没人清理几年下来会占用大量磁盘空间。我在项目中加了一个定时清理任务按目录记录最近访问时间超过设定周期且没有对应新产物引用的TS和M3U8直接删除。这里有一个顺序问题**先删旧分片再写新产物和先写新产物再删旧分片结果完全不一样。**我踩过坑最终定成“先生成新M3U8和TS到临时目录再原子替换M3U8最后清理旧目录”。这样就算替换过程中服务重启也不会出现播放器索引指向空分片的情况。5.4 线程池与任务队列把任务从接口里摘出来Web接口如果同步等待FFmpeg执行完一个路由请求可能挂好几分钟前端等到超时不说后端线程池也被占满。正确做法是接口把“转码任务”写入队列立刻返回“处理中”状态后台工作线程从队列里拿任务慢慢跑。推荐用ThreadPoolExecutor 有界队列队列大小设为100超过后直接拒绝新任务让上层入口提示“系统繁忙请稍后重试”而不是默默堆积几百个任务把内存吃光。ThreadPoolExecutor executor new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(100), new ThreadPoolExecutor.AbortPolicy());这里特地说一下拒绝策略AbortPolicy会在队列满时抛出异常虽然“不够友好”但至少让业务侧第一时间知道压力过剩而不是任务排队排到天荒地老。6. 常见问题与排查技巧实录我把自己在项目中遇到的高频问题整理成了一张表附上根因和解决办法方便你复制进自己的问题手册现象根本原因解决办法m3u8生成后播放器黑屏源视频编码可能是H.265先跑ffmpeg -i看编码格式强制转H.264分片时长忽长忽短不规律源视频关键帧间隔不固定加-force_key_frames expr:gte(t,n_forced*6)Java进程执行后卡住不动只读了标准输出没管错误流用redirectErrorStream(true)合并流并消费路径带空格导致命令失败字符串拆分成命令时被错误切开改用ProcessBuilder List传参m3u8里有TS但第一个TS无法播放强制关键帧与切片起点不对齐检查源文件是否存在B帧间隔换很保守的-keyint_min 60转码任务并发后服务器变卡没有限制并发数用Semaphore限流或把任务丢进线程池有界队列Windows下执行正常Linux下找不到ffmpegWindows安装时注册了PATHLinux没配置在代码里写死FFmpeg的绝对路径部分老手机播放TS花屏编码Profile过高或Level过高降到-profile:v main -level:v 3.16.1 排查方法先脱离Java跑通命令行不管报什么错我的第一反应永远是先把Java代码放一边手动在命令行执行一遍拼出来的FFmpeg命令。这个习惯帮我排除了至少一半的“假问题”——很多所谓的Java集成错误调试到最后发现是FFmpeg参数本身就写错了或者服务器上的FFmpeg版本与本地不一致。/usr/local/bin/ffmpeg -y -i /path/to/input.mp4 -c:v libx264 -preset veryfast -crf 22 -hls_time 6 -hls_list_size 0 -hls_segment_filename /path/to/ts/play_%03d.ts -f hls /path/to/play.m3u8命令能手动跑通然后再从Java里跑。这条经验听着简单但它确实最管用。有一次排查了很久花屏问题最后发现是服务器上FFmpeg版本太旧不支持某个新的编码flag手动跑一遍直接报错问题立刻定位。6.2 怎么确认生成的M3U8内容是正确的M3U8内容本身应该有明确结构手动打开看一眼就能发现异常。一个正常的点播M3U8开头加上分片列表大概长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:6 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:6.000000, ts/play_000.ts #EXTINF:6.000000, ts/play_001.ts #EXT-X-ENDLIST注意几个容易看错的点点播文件必须有#EXT-X-ENDLIST#EXT-X-TARGETDURATION必须大于等于所有分片实际时长取整后否则播放器可能提前认为某个分片超时分片路径如果是相对路径播放器解析时是相对M3U8所在目录来找TS的所以目录层次不能摆错。6.3 分片与加密如果需要防下载正规业务里总会有人问“能不能让用户下载不了视频”完全防不住是事实但能做一层威慑。FFmpeg原生支持HLS AES-128加密切分片时指定一个密钥文件生成的M3U8里会有#EXT-X-KEY标记播放器拿密钥正常在线播放但直接下载TS拼合出来的文件则无法播放。操作上不复杂先生成一个16字节的密钥文件再在FFmpeg命令里加两个参数-hls_key_info_file key_info_file -hls_key_file key.bin不过这个方案的价值在业务上要权衡一下密钥最终要发给播放器而播放器在客户端手里懂技术的人能抓到密钥所以它只能防“小白式下载”阻挡不了真正花力气的人。真要想加强得配合业务方的防盗链和DRM体系那已经是另一个话题。6.4 视频源不是标准MP4怎么办有的平台允许用户上传MKV、FLV、MOV甚至录屏生成的WebM。我的FFmpeg命令在-i后面其实自适应了大多数容器格式但如果遇到音频编码是AAC以外的比如PCM、Vorbis建议在转码时加-c:a aac强制转成AAC否则切出来的TS可能在某个播放器里没有声音。如果输入文件是FLV或WebM里面视频是VP8/VP9编码-c:v libx264会把它们重新编码成H.264这一步是必须的不然HLS标准与TS容器对编码格式的兼容性会让你体验一遍“为什么我这个片子在浏览器里不能播”的原因。6.5 磁盘IO瓶颈与带宽占用别只看CPU转码一台机器上同时跑多个任务时除了CPU磁盘IO也会成为瓶颈。TS分片写入非常频繁尤其是保持在多线程并发写入场景下机械硬盘会明显拖慢速度SSD就显得重要。我遇到过服务器CPU占用率不高但转码就是很慢的情况排查后发现磁盘IO队列深度非常高罪魁祸首是同时跑了八个FFmpeg任务每个都在写大量文件。解决办法很简单把并发数降低到4并给每个任务规划独立目录。如果给云存储回传产物带宽占用也要考虑。M3U8切片任务生成几百个TS后如果代码里逐个上传单个文件很小但请求次数很多反而比上传一个大MP4更耗时。批量打包上传或直接用分片并发上传效果会好很多。个人实操体会我最初做一个在线教学视频平台的后台时也犯过“把所有请求全部同步等待转码完成再返回”的错结果是页面卡顿、线程堆积、服务彻底不可用。后来一步步改成现在的方案任务先进队列FFmpeg由信号量限流产物校验通过后才更新数据库状态整个系统才真正稳定下来。如果你只打算记住一件事那就是先手动跑通FFmpeg命令再动手写Java。多花十分钟验证工具链本身后面节省的是几天的排查时间。V视频切片这件事本身没有玄学FFmpeg参数写对了Java代码把进程管理好业务就成功了大半。
