Java不直接支持H.264原始码流解码，需通过byte数组接收并确认封装格式（如RTP/RTSP或Annex-B），按起始码切分NALU，再交由JCodec或FFmpeg等库解码，注意缓冲复用与线程安全。
Java 本身不直接支持 H.264 原始码流的解码或渲染，但可以通过 byte 数组接收、缓存、转发或交由外部解码器处理。关键在于：明确数据来源协议（如 RTP/RTSP 或 MJPEG 封装）、避免直接解析 H.264 NAL 单元、借助成熟库完成后续工作。
确认 H.264 数据的封装格式和传输协议
网络摄像头通常不裸发 H.264 码流，而是封装在 RTP 包、RTSP 会话中，或以 Annex-B 格式（0x00000001 或 0x000001 起始码）分帧发送。byte 数组接收到的可能是：
- 单个 NAL 单元（带起始码，长度不定）
- RTP 负载（需剥离 RTP 头，提取 FU-A 分片或 STAP-A 聚合包）
- TS 流片段（较少见，需解析 PAT/PES）
务必先用 Wireshark 抓包确认帧结构；若使用 OpenCV + VideoCapture，它内部已处理封装，返回的是解码后帧（Mat），不是原始 H.264 byte[]。
用 byte[] 接收并安全拼接完整帧
H.264 网络传输常将一帧拆为多个 RTP 包（FU-A 分片），需按 RTP 序列号和 NAL 类型重组。简单场景下（如摄像头支持“single NAL unit”模式），可直接按起始码切分：
立即学习“Java免费学习笔记（深入）”；
- 扫描 byte[] 查找 0x00 0x00 0x00 0x01 或 0x00 0x00 0x01
- 从起始码到下一个起始码前一个字节即为一个 NALU（注意排除 0x00 0x00 0x00 0x00 的防竞争码）
- 使用 ByteArrayOutputStream 累积未完成帧，避免频繁 new byte[]
不要假设每个 UDP 包含一帧——这是常见误判点。
交给解码器（推荐 JCodec 或 FFmpeg Java 绑定）
纯 Java 解码 H.264 性能有限，建议桥接：
-
JCodec：轻量，支持 Annex-B 输入，调用
H264Decoder.decodeFrame()，输入是 ByteBuffer 封装的 NALU - JavaCPP Presets + FFmpeg：功能全，支持硬件加速（如 vaapi/nvdec），需预编译 native 库
- 绕过 Java：将 byte[] 写入管道或临时文件，用 ffmpeg 命令行解码（适合调试）
示例（JCodec）：
ByteBuffer buf = ByteBuffer.wrap(naluBytes);
Picture out = decoder.decodeFrame(buf, yuvBuffer);
注意线程安全与内存管理
摄像头流是持续高速数据源，byte[] 频繁创建易触发 GC：
- 复用 ByteBuffer 或 byte[] 缓冲池（如 Netty 的 PooledByteBufAllocator）
- 解码逻辑放在独立线程，避免阻塞接收线程
- 及时释放解码后的 BufferedImage 或 OpenGL 纹理引用
若仅需转发（如推流到 RTMP），可跳过解码，直接对 NALU 做时间戳修正和打包。
