背景痛点：为什么需要H.264转AV1？

最近接手了一个视频处理项目，需要将大量H.264格式的视频转码为AV1格式。AV1作为新一代开源视频编码标准，相比H.264能节省30%-50%的带宽，同时保持相同画质。但实际开发中发现两个头疼问题：

• 性能瓶颈：传统FFmpeg单线程转码速度慢，处理1080P视频仅能达到0.5x实时速度
• 资源消耗：频繁的内存分配导致GC压力大，长时间运行易出现OOM

技术选型：三大方案横向对比

1. FFmpeg-Java绑定（最终选择）
2. 优势：成熟稳定，参数调节灵活，社区支持完善

3. 劣势：需要处理native库依赖

4. JCodec原生实现

5. 优势：纯Java实现，部署简单

6. 劣势：AV1编码功能不完善，性能较差

7. GPU加速方案

8. 优势：Intel Media SDK可提升5-8倍速度
9. 劣势：硬件依赖性强，成本高

核心实现：FFmpeg最佳实践

基础转码命令封装

ProcessBuilder pb = new ProcessBuilder(
    "ffmpeg",
    "-i", inputPath,
    "-c:v", "libaom-av1",
    "-crf", "30",          // 质量参数(0-63)
    "-cpu-used", "4",      // 速度/质量权衡
    "-g", "240",           // 关键帧间隔
    "-threads", "8",       // 并行线程数
    outputPath);

// 错误流重定向到标准输出
pb.redirectErrorStream(true);
Process process = pb.start();

多线程任务队列

ExecutorService executor = Executors.newFixedThreadPool(
    Runtime.getRuntime().availableProcessors() / 2);

ConcurrentLinkedQueue<File> taskQueue = new ConcurrentLinkedQueue<>(videoFiles);

while (!taskQueue.isEmpty()) {
    executor.submit(() -> {
        File video = taskQueue.poll();
        if (video != null) {
            transcode(video); // 封装转码逻辑
        }
    });
}

性能优化关键点

1. 内存池技术
2. 复用FFmpeg进程避免重复创建

3. 使用ByteBuffer池管理帧数据

4. JMH基准测试结果

5. 单线程：128秒/视频
6. 4线程：42秒/视频
7. 8线程：38秒/视频（收益递减）

避坑指南（血泪经验）

1. 版本兼容性
2. FFmpeg 4.4+才支持完整的AV1编码

3. 注意libaom版本与FFmpeg的匹配

4. 幂等处理

   if (outputFile.exists() && 
       outputFile.length() > 1024 * 1024) { // 大于1MB视为有效文件
       return; // 跳过已处理文件
   }

5. Linux库路径

   # 启动时指定so库路径
   java -Djava.library.path=/usr/local/ffmpeg/lib

延伸思考：WebAssembly的未来

最近发现Emscripten可以将FFmpeg编译为WASM，这意味着： - 浏览器端直接转码成为可能 - 减轻服务器负载 - 但当前性能仅为native的1/10，值得持续关注

整个项目做完最大的体会是：参数调优比算法选择更重要。通过调整CRF、cpu-used等参数，我们最终在画质和速度间找到了最佳平衡点。