企业官网建设流程全解析

开头我先说个真实场景。你接了个视频处理任务，需求不复杂：从一批高清监控录像里抽帧、转码、拼成回放文件。你打开IDE，自然地用了Java，半小时后天真地以为调个开源库就行，结果第一帧画面出来是花的、第二帧直接OOM、第三帧日志开始刷Unsafe.park。这不是玩笑，而是JVM生态里做高清视频处理最常见的开局。Java本身没有任何原生视频解码能力，你真正要面对的是JNI边界、Native内存、时间基、像素格式转换这一堆看起来和业务无关、但每一条都能让你通宵的问题。

这篇文章就是把我处理过的若干视频项目里踩通的路径完整走一遍：先从原理层面说清楚Java和视频处理之间那道墙在哪，再到JNA/JavaCV/命令行三类方案的选型逻辑，然后一步步拆解核心调用链、播放渲染、流式处理、性能优化和交付前的测试清单。内容按照"能直接复现"的标准来写，适合那些已经能写Java业务、但第一次碰FFmpeg相关技术栈的开发者，也适合被视频内存问题折磨过、想搞清楚根因的人。

1. 先说清楚：Java处理视频这件事的边界到底在哪

1.1 你真正在做的是"封装"，不是"算法"

绝大多数Java开发者第一次接触视频处理时都会犯一个认知错误：以为视频的解码、编码、滤镜这些操作，应该是某个Java库内部的事情，自己只要调API就行。真做起来才会发现，JVM生态里所有能跑的视频能力，本质上都是C/C++库通过某种方式暴露出来的封装。解码一帧H.264 1080p视频，纯Java实现的开源库性能差距和C版本差一到两个数量级，而且没有任何生产环境的稳定性保障。我见过某位开发者试图用纯Java库去实现RTSP拉流解码，最后在CPU占用率和内存碎片问题上彻底放弃。

所以要建立的第一认知是：Java只负责业务调度、数据流转和UI展示，真正吃帧、吃像素的是FFmpeg这类Native库。你的工作重点不是实现算法，而是管理好JVM和Native之间的数据通道、内存生命周期和线程模型。

这张图可以用一句话概括：Java是"老板"，Native是"车间"，两者之间隔着一堵叫JNI的墙，你的本职工作就是当好墙两边的传送带管理员。

1.2 三套技术路线的取舍逻辑

实际项目里，Java接视频处理有三条主流路线，每条路线的代价和适应性完全不同，我用一个真实项目的选型过程来说明。

路线A：命令行调FFmpeg可执行文件

最简单，ProcessBuilder直接执行ffmpeg -i input.mp4 ...。优点是零部署成本、隔离性好（崩溃不影响JVM）、开发速度快。缺点也非常明显：无法拿到解码后的帧数据做自定义处理，每路视频都要起进程，CPU内存开销大，帧级控制基本为零。处理单文件转码、格式转换这类"不需要碰像素"的业务够用。

路线B：JavaCV/JavaCPP封装

JavaCV是对FFmpeg和OpenCV的自动生成封装，代码里可以直接操作FFmpegFrameGrabber、FFmpegFrameRecorder这些类。优点是上手快、API比JNA优雅得多、示例丰富，内部已经帮你做了大量内存管理的细节。缺点是引入了比较重的依赖链，对Native库版本的控制不如编译期直接指定来得严格。大多数Java视频业务，JavaCV都是最优解。

路线C：JNA直接封装FFmpeg API

自己用JNA定义FFmpeg的接口，管理指针、结构体、内存回收。这是最接近底层、也是坑最多的路线。优点是调用链完全透明、可以精确控制每一帧、资源占用做到最小；缺点是要自己处理AVFormatContext指针生命周期、AVFrame的av_frame_free、回调线程等大量C语言的约定。适合需要深度定制播放器、流媒体处理引擎的项目。

我印象很深的一个视频处理Demo就是用了路线C：需要把某设备的私有编码流拉下来，每帧做区域裁剪后转H.264推流。这个过程不仅要吃帧、改帧，还要在Java侧做目标检测预处理，JavaCV绕了很多弯路，最终用JNA直封FFmpeg才把延迟压到可接受的范围内。

2. 环境准备：搞定Native库版本和加载链路

2.1 版本匹配是第一个深坑

很多人忽略的第一件事：FFmpeg的API在4.x和5.x之间有过多次签名变更，如果你用JavaCV 1.8.3对应的FFmpeg版本去对接一套基于旧版本编译的动态库，轻则运行时报符号找不到，重则直接JVM崩溃且没有任何Java异常可捕获。

JavaCV场景下，org.bytedeco:javacv-platform会带一组已经编译好的Native二进制，版本内部是匹配好的。但JNA场景下没有这个保障，你需要自己面对系统里安装的FFmpeg版本和编译时对应的头文件版本是否一致的问题。

我建议的处理方式：

1. 只在pom或gradle里固定一个JavaCV版本，不要混合多个不同版本的JavaCV模块。
2. 自己下载FFmpeg源码静态编译风险更低，为了更稳，可以选择固定的release版本。
3. 启动时打印FFmpeg版本号做成启动检查，避免运行时才发现接口不匹配。

// 启动时快速验证Native库可用性 FFmpegFrameGrabber grabber = new FFmpegFrameGrabber("test.mp4"); try { grabber.start(); System.out.println("FFmpeg started, format: " + grabber.getFormat()); grabber.stop(); } catch (Exception e) { throw new IllegalStateException("FFmpeg Native库加载失败或版本不匹配", e); }

这段代码看着简单，但它能帮你把"环境问题"和"代码问题"在第一时间分开，排查效率会高很多。

2.2 库文件的加载路径问题

JNA加载动态库时，默认搜索路径是jna.library.path、系统LD_LIBRARY_PATH（Linux）或PATH（Windows）。JavaCV的JavaCPP则使用javacpp.properties里定义的平台路径。

实际部署时最容易出现的问题是：开发环境（Mac或Windows）的库路径和Linux服务器不一致，代码写完在自己机器上跑得好好的，丢到服务器上直接UnsatisfiedLinkError。

一套比较稳妥的做法：把Native库文件打进jar的/natives目录，启动时用System.setProperty("jna.library.path", ...)把路径动态设置成jar释放出的临时目录。JavaCV则是已经帮你做了这一步，它会从classpath里的/natives/<platform>/目录自动释放。

// 自定义Native库释放逻辑的简版实现 public class NativeLibraryLoader { public static void loadFromClasspath(String resourcePrefix) throws IOException { String tmpDir = Files.createTempDirectory("native-libs").toAbsolutePath().toString(); try (InputStream in = NativeLibraryLoader.class.getResourceAsStream(resourcePrefix)) { Files.copy(in, Paths.get(tmpDir, "libavformat.so"), StandardCopyOption.REPLACE_EXISTING); } System.setProperty("jna.library.path", tmpDir); } }

这里要提醒一点：如果多个组件各自释放自己的FFmpeg库，会出现版本抢占。某开发者的项目里同时引入了A模块的JavaCV和B模块的手工FFmpeg封装，结果解码出来的画面全是乱码，查了两天才发现是libavcodec.so被加载了两份不同版本。

2.3 跨平台部署的注意事项

生产环境通常是Linux，而开发环境可能是Windows或Mac。这里最隐蔽的问题是Linux下FFmpeg编译时如果没开--enable-pic，Java加载动态库时可能因为地址重定位问题直接崩溃。另外，Linux的libavdevice依赖的alsa、x11等在无头服务器上可能缺失，虽然你根本用不到这些功能，但动态库加载时启动器仍会因为依赖链不完整而失败。

我的坑经验：部署目标锁定Linux后，第一时间在目标系统上跑一遍最小编解码链路验证，不要在容器镜像里只装JRE不装FFmpeg系统依赖。用下面这段启动参数，可以打印出Native库加载实际走到的路径：

java -Djna.debug_load=true -Djavacpp.debug=true -jar video-processing.jar

看到实际加载的.so路径，很多莫名其妙的问题能省下至少半天的排查时间。

3. 核心调用链：JNA封装FFmpeg的三个高频操作

这个章节以JNA直封FFmpeg为例，因为JavaCV的用法到处都有，但真正把底层原理讲清楚的内容很少。理解了JNA的逻辑，JavaCV的使用和理解会顺畅很多。

3.1 解码与截帧：从AVFormatContext到AVFrame

JNA方式下，核心流程固定在四步：打开输入、找解码器、循环读包、发包收帧。用代码描述就是：

// 简化的JNA接口定义（关键部分） public interface FFmpegLib extends Library { FFmpegLib INSTANCE = Native.load("avformat", FFmpegLib.class); Pointer avformat_open_input(Pointer[] ctx, String url, Pointer fmt, Pointer options); int avformat_find_stream_info(Pointer ctx, Pointer options); Pointer av_read_frame(Pointer ctx, Pointer packet); int avcodec_send_packet(Pointer codecCtx, Pointer packet); int avcodec_receive_frame(Pointer codecCtx, Pointer frame); }

真正花费最多时间的是解码器上下文和帧对象的创建与释放。avcodec_alloc_context3返回的指针必须配对调用avcodec_free_context，av_frame_alloc必须配对av_frame_free。Java没有析构函数，所以这些资源必须用try-finally或者封装成AutoCloseable接口来管理。

public class VideoFrameExtractor implements AutoCloseable { private Pointer formatCtx; private Pointer codecCtx; public BufferedImage grabFrameAt(int targetSeconds) { Pointer packet = FFmpegLib.INSTANCE.av_packet_alloc(); Pointer frame = FFmpegLib.INSTANCE.av_frame_alloc(); try { // seek到目标时间附近，再逐帧解码直到接近目标时间 long targetTs = targetSeconds * timeBase.seconds(); FFmpegLib.INSTANCE.av_seek_frame(formatCtx, streamIndex, targetTs, 0); while (FFmpegLib.INSTANCE.av_read_frame(formatCtx, packet) >= 0) { if (packet.streamIndex() != streamIndex) continue; FFmpegLib.INSTANCE.avcodec_send_packet(codecCtx, packet); while (FFmpegLib.INSTANCE.avcodec_receive_frame(codecCtx, frame) >= 0) { return convertFrameToImage(frame); } } } finally { FFmpegLib.INSTANCE.av_packet_free(packet); FFmpegLib.INSTANCE.av_frame_free(frame); } return null; } }

这段代码的关键除了API调用顺序，还有av_seek_frame的第三个参数：它需要的是时间基上的时间戳。很多第一次做的人直接填秒数，结果seek到完全不相关的位置。我这里偷了个懒用timeBase.seconds()计算，真实场景下一般用av_rescale系列函数，但逻辑是一致的：必须把秒换算成流的时间基。

3.2 转码与重封装：别忽略时间基

转码流程就是在解码的基础上加一个编码器。看起来是"解码出来什么就喂给编码器"，实际没那么简单。

每个流都有自己独立的时间基（time_base），源视频的时间基可能是1/90000（H.264常见），输出MP4的编码器期望的时间基可能是1/12800。如果不做av_rescale_q的换算，直接喂时间戳，出来的文件要么播放进度跳跃，要么音画不同步。

我自己曾经在转码时直接传原始pts，结果生成的文件在播放器里显示总时长只有实际的三分之一，后来打印每个frame的pts才发现，源封装和输出封装的时间基确实不同。修正代码时用到了这个关键换算：

private long rescaleTimestamp(long pts, AVRational src, AVRational dst) { // 对应FFmpeg的av_rescale_q，自动处理舍入方向，避免累积误差 return (pts * dst.den / src.den * src.num + src.num - 1) / src.num; }

AVRational就是分子分母结构体，这个换算的原理和小学的比例运算一样，但方向很容易搞反。稳定做法是：从源读到一个AVPacket，先av_packet_rescale_ts(pkt, srcTimeBase, dstTimeBase)，再写入输出上下文。不要自己写公式，直接用库函数最稳。

3.3 多路拼接：复杂程度远高于单路处理

多路视频拼接（concat）是另一个和想象差距很大的需求。直接顺序写入多个文件的包会导致时间戳回零或者重叠，必须逐路累积时间偏移。

落地方案通常两种：

1. 解码重编码式拼接：每路视频解码成帧，按统一输出参数（分辨率、帧率、码率）重编码进输出文件。最灵活，但CPU开销大。
2. 流拷贝式拼接：要求所有输入文件的编码参数完全一致（相同分辨率、帧率、编码器、GOP大小）。直接拷贝包并做时间戳偏移，速度极快，但条件苛刻。

流拷贝式的时间戳偏移逻辑核心就一行：后续每个包的pts和dts都加上累计时长，也就是前一路的总时长换算成输出时间基后的数值。但问题是GOP边界和keyframe连续性，如果第一路文件结束时不是关键帧，第二路的首帧就会踩参考帧缺失的坑，解码器输出花屏。多数场景为了稳妥，会选择方案1重编码拼接，这也是很多剪辑业务宁愿牺牲实时性的原因。

4. 播放器渲染链路：从解码帧到屏幕像素

4.1 渲染方案选择：AWT/Swing与JavaFX的取舍

解码拿到的是AVFrame里的YUV数据，但Java侧的图像API原生只支持RGB（或ARGB），所以你必须做一次像素格式转换。这里有两种选择：

1. 用FFmpeg的sws_scale做YUV到RGB转换（推荐，性能极高）。
2. 用JavaCV的Java2DFrameConverter转成BufferedImage（简单但多一次内存拷贝）。

渲染方案上，桌面端用JavaFX的WritableImage+PixelWriter，性能比Swing的BufferedImage绘制高不少，因为可以走DirectBuffer路径。实测下来，1080p 30fps的视频在JavaFX下渲染约占25%的CPU（纯软件渲染路径），Swing路径要35%-40%。

public void renderFrame(PixelWriter writer, Frame frame, int width, int height) { // frame已经从YUV转换为BGRA格式，直接写入像素 ByteBuffer buffer = frame.getByteBuffer(); writer.setPixels(0, 0, width, height, PixelFormat.getByteBgraPreInstance(), buffer, frame.getStride()); }

要点在frame.getStride()：YUV转RG B后的数据每行可能有对齐填充，不传递stride直接用width会让画面倾斜。这个坑几乎所有做渲染的人都踩过。

4.2 同步机制：音画同步的三个锚点

视频播放不是"循环解码+渲染"就行的，因为音频和视频速度天然不一致。常见做法是拿音频时钟（audio clock）做主时钟，视频帧循环里比较帧的pts和主时钟的差距，决定立即渲染、等待、还是丢帧。

伪代码逻辑：

double clock = audioClock.getTime(); double frameTime = frame.getTimestamp(); // 秒 double diff = frameTime - clock; if (diff > 0.05) { Thread.sleep((long) ((diff - 0.03) * 1000)); // 超前就等一小段 } else if (diff < -0.05) { continue; // 落后超过50ms就丢帧 } renderFrame(writer, frame);

三个锚点的含义：音频时钟提供时间基准（一般从音频设备回调里取播放位置），视频帧携带PTS作为自己的时间标签，二者差值在一个小范围内波动是正常的（一般容忍±40ms以内）。如果静音视频没有音频轨，就需要用系统System.nanoTime()配合帧率做自建时钟。

4.3 像素格式转换最容易踩的坑

为什么视频解码出来后大多是YUV420P，而不是RGB？因为视频压缩算法为了压缩率，人眼对亮度敏感、对色度不敏感，YUV在存储时按4:2:0采集，色度信息只有亮度的四分之一。这个特性是视频编码节省码率的核心，但也意味着你要在某个环节把它转回RGB才能用通用图像API。

JavaCV做转换很方便：

FFmpegFrameConverter converter = new FFmpegFrameConverter(); Frame rgbFrame = converter.convert(yuvFrame);

但JavaCV底层还是走sws_scale，转换是CPU密集操作。1080p一帧经过YUV420P到RGB24的转换需要大约2-4ms（取决于CPU），30fps就是60-120ms的CPU时间，这部分优化空间很大：

1. 提前申请转换输出缓冲，不要在每帧循环里反复malloc/free。
2. 输出格式选BGRA而不要选RGB24，因为BGRA是4字节对齐，写入时可以直接按int拷贝，速度快得多。
3. 如果只是预览，降到960x540再转换，人眼基本分辨不出差异，CPU开销能降到1/4。

5. 高清视频流式处理：不落盘才是真正的实战门槛

前面几章虽然操作的都是文件，但生产环境里真正高频的需求是对网络流（RTSP/RTMP/HTTP-FLV）做实时的帧处理。不落盘的处理才是走向实战的门槛。

5.1 流式处理的架构差异

文件处理和流处理的本质区别，体现在三个维度的变化上：

1. 输入端不再是可seek的文件，读到的包可能迟到、乱序，甚至中途断流。
2. 时间约束变得严格，解码慢一帧，整个管线就会实时性崩盘。
3. 资源生命周期变长，一个流可能持续数小时，内存里的对象复用变得非常重要。

一个高清视频推流转发的架构图（用描述代替）：源端RTSP流进入Java进程，解码线程负责拉流和解包；中间一个有界队列把原始帧传递给处理线程池，处理线程做目标检测或画质增强后封装成新帧；处理完的帧进入编码器，编码后的包交给推流线程发往目标RTMP服务器。

拉流解码线程 -> 有界队列 -> 处理线程池 -> 编码线程 -> 推流线程

关键在有界队列。用ArrayBlockingQueue<FrameRef>，容量8-16，满了直接丢弃最旧的帧（不做阻塞），因为视频实时性场景里延迟比丢帧更致命。一次RTSP拉流连续运行6小时，如果队列满时选择阻塞而不是丢弃，任何一处的瞬时卡顿都会传导到整条链路，最终表现出来就是画面越来越卡、内存越涨越高。

5.2 推流对接与回调线程模型

JavaCV推流的常规写法是FFmpegFrameRecorder配合start()，和本地文件录制几乎无差别。但流式输出有两个很重要的差异。

第一个是编码参数：流媒体平台（RTMP）对GOP大小、profile、level有约定。常见配置是preset("ultrafast")+tune("zerolatency")+gopSize(60)+keyframeInterval(60)。这里zerolatency会显著降低编码延迟，但也提高码率波动，适合实时直播场景；而本地录播用preset("medium")更好，体积小画质高。

第二个是回调线程模型。如果你的处理逻辑需要调用Native回调（比如某个算法库走的是C回调），这个事情要非常小心：FFmpeg内部网络回调可能在StreamCallback线程里执行，如果你在这个线程里直接操作Java的共享对象，很可能会出现不可见的偶发问题。处理方式是把回调内容包装成任务提交到独立线程池，保证Native回调返回极快。

5.3 断点续传与状态恢复

流式处理在真实场景里必然遇到断流。RTSP源设备重启、网络闪断、服务器主动断开，都需要业务层做重连和恢复。

踩坑经验有两个：

1. 重连不能太频繁，否则源服务器会把你当垃圾流量封掉。退避策略一般是1秒、2秒、4秒、8秒指数级，最大不超过60秒。
2. 重连后解码器要重新初始化，不要复用旧上下文。某些解码器在断流重连后内部状态已经不可靠，继续用旧codec上下文会导致花屏。

public void runReconnectLoop(String url, int maxAttempts) { int delaySec = 1; for (int i = 0; i < maxAttempts; i++) { try { grabber.start(); while (grabber.isStreaming()) { // 主循环处理帧 } // 流自然结束后重连 } catch (Exception e) { log.error("stream dropped", e); } finally { grabber.stop(); grabber.release(); } Thread.sleep(delaySec * 1000L); delaySec = Math.min(delaySec * 2, 60); } }

这段逻辑里最重要的一点是grabber.release()之后必须重建对象，不要试着start()同一个实例，JavaCV的FFmpegFrameGrabber在stop后复用某些资源会有未知问题。

6. 内存、并发和GPU：用好性能这把刀

6.1 内存问题的三个层次

视频处理跑时间长了出现内存问题，几乎都是以下三个层次之一：

层次一：Java堆内存不足。每帧BufferedImage是重量级对象，1080p一张约6MB，30帧就有180MB瞬时压力。对策是对象复用：用固定大小的BufferedImage，每帧直接往里面画，不要新建。

层次二：DirectBuffer/Native内存溢出。JavaCV的Frame对象背后是Native内存，GC无法自动回收它。如果每帧都new Frame而不frame.release()，即使Java堆毫无压力，Native内存也会涨到系统OOM。这是最容易被忽视的一层。

层次三：JNA指针泄漏。使用JNA时，每一个av_frame_alloc()都必须有对应释放，否则内存只增不减。这类泄漏用常规java内存分析工具看不出来，必须用jcmd VM.native_memory或valgrind级别的工具才能看到。

解决这三个层次的建议：

• 帧对象池化：创建完一个Frame后就一直复用同一个对象，处理完清空再填充。
• 编码器recorder在stop()后及时release()。
• 如果用了JNA的方式，在finally里释放所有指针是铁律。

# 启动时开启Native内存追踪，排查Native泄漏 java -XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics -jar app.jar

6.2 I/O瓶颈是异步化

高清视频处理里，I/O写入往往是隐形瓶颈。硬件编码器速度快，但写盘速度跟不上，就会造成背压。FileChannel写MP4和普通FileOutputStream差距很大，用FileChannel做好顺序写、设置ByteBuffer为DirectBuffer，能明显提升写吞吐。实测4K视频转码写盘时，普通流式写约70MB/s，FileChannel+DirectBuffer可以到120MB/s以上。

如果目标是网络推流，缓冲区设置就很重要。RTMP推流缓冲区默认较小，网络有抖动就丢包，视频花屏。建议推流前设置：

recorder.setOption("rtmp_buffer_size", "4096"); recorder.setOption("rtmp_live", "live"); recorder.setOption("rtmp_playpath", streamKey); recorder.setOption("max_delay", "1000000");

max_delay单位是微秒，1000000也就是1秒，可以容忍较大的网络波动。但加大缓冲区意味着延迟上升，要结合业务对实时性的要求权衡。

6.3 GPU加速的落地现状

Java侧想用上GPU硬编解码，实际落地的路径没有想象中的丝滑，因为JNI层基本不变，关键在FFmpeg编译时是否开启了对应能力。

硬解码常用的是NVDEC（N卡）或VAAPI（Intel核显），硬编码常用NVENC。FFmpeg里对应的能力名称和参数差异不大：

recorder.setOption("c:v", "h264_nvenc"); recorder.setOption("preset", "p4"); // p1最快，p5质量更高 recorder.setOption("rc", "vbr"); recorder.setOption("cq", "23");

实测下来，4K视频软解码后NVENC硬编码，编码速度能提升5倍以上，CPU占用从70%降到15%左右。但踩过的坑也值得说：硬编码的GOP和B帧行为与软件编码器不同，某些播放器对特定profile支持不好，会造成拖影或花屏。生产环境里如果目标播放器不可控，建议用profile baseline或者main。

另一个常见坑是驱动和FFmpeg的兼容。某台Linux服务器上h264_nvenc初始化报错，查半天发现N卡驱动版本和CUDA版本不匹配，重装驱动后问题消失。所以部署GPU编码前，先把下面的测试跑通：

ffmpeg -hide_banner -encoders 2>/dev/null | grep nvenc

如果列表里没有nvenc，说明编译时没有NVENC支持，需要换支持GPU版本的库。

7. 交付前的测试清单：画质、兼容性和稳定性

这个章节放在最后，因为很多人做完功能就直接上线了，结果在真实环境里被各种怪问题砸得头破血流。视频处理项目的验收不只是"跑通了"，要从画质、兼容性、稳定性三个维度全面过一遍。

7.1 画质验收的量化指标

不要用肉眼判断画质好坏。两路视频差异对比时，人的眼睛会被色彩偏好、码率分配、锐化策略影响，而且在快速移动场景下肉眼几乎分辨不出10%的码率差异。量化指标至少要看两个：

• PSNR（峰值信噪比）：数值越高越好，一般转码场景下要求≥35dB，低于30dB画质就会明显劣化。
• SSIM（结构相似性）：越接近1越好，一般要求≥0.95。

FFmpeg可以直接计算这两个指标：

# 原视频与转码后视频的PSNR和SSIM对比 ffmpeg -i original.mp4 -i transcoded.mp4 -lavfi "psnr" -f null - ffmpeg -i original.mp4 -i transcoded.mp4 -lavfi "ssim" -f null -

注意对比前要用同一时间基对齐，否则误差极大。我见过某团队拿两段长度相同但起始帧不同的视频对比，PSNR得出32dB的"高质量"结论，实际上这只是"内容相似"，根本不是同一帧的对比。

7.2 兼容性矩阵

视频容器和编码的组合非常多，常见组合至少有：MP4+H.264、MP4+H.265、TS+H.264、FLV+H.264、MKV+VP9、WebM+VP9。业务上如果无法做到"输出一种固定组合"，就要有一个兼容性矩阵来明确每个组合的关键约束。

实测时还要注意：同样是H.264，profile级别会影响兼容性。baseline几乎所有设备都能解，main较新，high最老设备可能不支持。做多平台分发时优先main，能兼容绝大多数设备，只牺牲一点压缩率。

7.3 稳定性的长时间验证

视频处理的稳定性问题，往往不会在5分钟测试中出现，而是要在长时间运行后暴露。我见过监控视频连续处理6小时后内存涨到3GB的案例，问题根源就是每帧创建的临时Frame没有完全释放，属于典型的Native内存泄漏。所以交付前必须做：

• 用恒定帧率的测试源（如循环播放的视频文件）至少跑24小时。
• 每30分钟记录一次jstat -gc、jcmd VM.native_memory summary。
• 检查Java堆、Native内存、线程数量三项指标是否最终回到初始值附近。

如果内存曲线持续上升，先用线程栈定位是否是某个线程累积了对象，再用NMT定位是否Native层泄漏。

# 获取Native内存详细快照，对比24小时前后差异 jcmd <pid> VM.native_memory summary.diff

另外一个隐蔽的坑是线程数泄漏。每次断流重连如果都创建新线程而不是复用旧线程，连续断流100次后线程数就会涨到不可控。所以在重连逻辑里，线程池必须显式复用，不能每次都new Thread。

最后再分享一个容易被忽视的小细节

关于视频处理的Java实战，我最后的建议听起来可能有点反直觉：尽量把处理流程写成"从内存到内存"，而不要陷入"从文件到文件"的思维定式。也就是说，无论输入是文件还是流，第一时间统一解析成帧数据流，所有处理都在内存中完成，最后再统一封装输出。这样可以让你后续想切换输入源、增加滤镜效果、接入实时检测算法时，不需要改动主体流程，只需要在链路上加节点。

另一个小细节是日志：视频处理里每帧的时间戳极其关键，排查问题时要能看到每个关键节点的耗时分布。在拉流、解码、处理、编码、推流五个环节都加上轻量耗时统计（用System.nanoTime()，不能在关键路径上做字符串拼接），出现问题后能立刻定位是哪一段变慢了。

我目前的经验是：Java视频处理项目的复杂度不在Java语句本身，而是在你如何管理Native生命周期、线程调度和时序约束。把这三件事想明白，剩下的都是调参和打磨的活。希望这篇基于实战的拆解能让你少走几晚的弯路。