前言

从2016年6月开始写《javacv开发详解》系列，到而今的《javacv入门指南》，虽然仅隔了两年多时间，却也改变了很多东西。

比如我们的流媒体技术群从刚开始的两三个人发展到现在的三个500人群。又比如博主刚开始也想放弃，期间自行脑洞内心挣扎的场面也就不详说了，结果是现在还在坚持更新博客。当然这期间离不开群里小伙伴们一直以来的陪伴和支持，感谢大家一起默默为java流媒体技术踩坑，踩的多了也就真的成了路（也可能踩成深坑）。另外感谢雷霄骅博士的ffmpeg博客，给予博主很大帮助，2016年刚开始接触ffmpeg就忽闻博士去世，甚为感慨，大家且行且珍惜吧。

以前从来不觉得java可以做流媒体、音视频编解码这些，直到现在，顶多说java做流媒体是非主流。业界广泛应用的librtmp、live555、ffmpeg也都是c/c++的库，刚开始也确实尝试过使用jni方式调ffmpeg，发现做起来吃力不讨好，后来在github发现了新大陆：javaCV。

有，总比没有强。虽然连个API文档都没有，通过github项目描述的那可怜的几个字勉勉强强知道它对ffmpeg、opencv等等等十几个库做了封装，用javacpp方式为fmpeg、opencv等库编译了各个系统环境的包方便跨平台调用。

JavaCV入门指南系列：

JavaCV入门指南：序章

JavaCV入门指南：调用FFmpeg原生API和JavaCV是如何封装了FFmpeg的音视频操作

JavaCV入门指南：调用opencv原生API和JavaCV是如何封装了opencv的图像处理操作

JavaCV入门指南：帧抓取器(FrameGrabber)的原理与应用

JavaCV入门指南：帧录制器/推流器(FrameRecorder)的原理与应用

JavaCV入门指南：帧过滤器(FrameFilter)的原理与应用

JavaCV入门指南：FrameConverter转换工具类及CanvasFrame图像预览工具类

一些题外话

踩坑到今天，可能还会有许多人踌躇疑惑javacv除了可以在音视频和图像处理这块稍微可以施展手脚外，还可以做什么？除了这些，在应对各种纷繁复杂的流媒体协议（rtp/rtsp/rtmp/flv/hls等等）也不在话下，当然一些小众和国产协议（比如sip/gb28181/jtt178等）可能需要依赖netty/mina等网络库来实现，编解码上结合javaCV，性能上也已经没有什么顾虑。另外在深度学习领域，deeplearning4j借助javaCV的东风令java在深度学习领域也同样引领风骚。

本系列将结合《javacv开发详解》系列作为实战教程，结合实例，力求简单易懂，快速上手。

一、老生常谈

javaCV能做什么，既然是"CV"大法，那自然是计算机视觉领域的库，诸如音视频、流媒体、图像处理、深度学习、机器学习、人工智能等等等（现在流行后面这三个，写上去应该能唬住不少人，deeplearning晓得不，里面一堆的javaCV库没发现吗）。

二、入门基础

以上全是些空话，我们无非就是要用javaCV采集视频和音频，给这些音视频编解码，然后是用什么封装格式封装这些音视频数据，以及用什么协议传输，可能还要对视频里的图像进一步进行处理（这个属于图像处理范畴），流程大致如此（音频方面了解不多，大家见谅）：

拉流（采集）--->图像像素数据/音频数据<---->编/解码 <---->音/视频帧<---->解封装/封装---->推流

举例：编解码过程（以hevc编码的rtsp转rtmp/flv为例，无音频数据）：

rtsp流---拉流解复用--->h265(hevc)---解码--->yuv像素数据---编码--->h264---封装推流--->rtmp/flv

1、图像像素格式与图片封装格式

图像像素格式（简称像素格式），一般指的是没有经过编码的按照原始像素排列的数据。

举个栗子，一个完整图像的像素排列一般是这样的（以4*4像素的rgb像素格式为例）：

rgbrgbrgbrgb

当然我们存储的时候一般使用一维数组来存这些数据，所以排列顺序就变成这样：rgbrgbrgbrgb.......以此类推。

图片封装格式指的我们日常见到的png，jpg，bmp，gif等等图片格式，其中bmp是无损格式，里面的数据格式就是图片头信息加上rgb排列的像素数据，png/jpg这些都是有损压缩格式，但是压缩比还是很高的，为什么要压缩下面会讲到。

2、图像？视频帧？傻傻分不清楚

图像像素数据指的是yuv、rgb，rbga，bgr，gbra等图像像素格式，经过编码后才是视频帧。比如我们常见的h264编码，编码其实就是对图像像素数据的压缩，（以rgb为例，假如当前图像像素尺寸为1920*1080，，每种颜色用一个字节表示，也就是说每个像素点有红绿蓝三色共3字节，图像有1920*1080个像素点，也就是说这张图像大小为1920*1080*3字节，显然数据太大了），可以这样理解，h264编码本质上就是一种图像数据压缩算法。

补充：视频帧中常常提到的I帧，B帧和P帧指的是什么？i帧也叫关键帧，实际上就是一张完整的静态图像，而B帧和P帧只是用来记录画面的运动矢量等非图像数据，B/P帧都需要依赖i帧才能够正确解码出完整图像（有损的图像画面）。在实际应用中各种视频源中很少使用B帧，原因是虽然使用大量B帧可以提高压缩率，但也会消耗更多的硬件性能，所以大多数情况下的视频源都以i帧（关键帧）和大量P帧为主。

另外在直播应用中i帧间隔会很低，这样能够更快的显示首帧画面（B/P帧需要i帧才能够解码），但是这样也增加了传输的数据量，因为一个i帧通常会很大。

3、编码？封装？傻傻分不清楚

编码上面已经讲了，是一种压缩算法；那么封装格式又是什么呢，封装格式就是我们日常见到的视频文件了，比如mp4，avi，mkv，flv等等等，按照每种封装格式的规范把视频帧和音频按照一定顺序存起来就成我们日常看到的视频文件了，这些封装格式一般都会包含一些头/尾标识和一些视频描述信息，这样播放器读取视频文件的时候就知道该怎么播放这些视频文件了（可以把封装格式理解成收纳箱，上面贴着小纸条说明里面放了哪些东西）。

压缩图片格式也可以参考视频编码格式，原理都一样，都是对图像数据做有损/无损压缩。

什么是转封装？为什么转封装比转码消耗更少？为什么转封装无法改动视频尺寸？

先举个栗子：假设视频格式(mp4,flv,avi等)是盒子，里面的视频编码数据(h264,hevc)是苹果，我们把这个苹果从盒子里取出来放到另一个盒子里，盒子是变了，苹果是没有变动的，因此视频相关的尺寸数据是没有改动的，这个就是转封装的概念。

有了上面这个例子，我们可以把“转码”理解为：把这个盒子里的苹果(hevc)拿出来削皮切块后再加工成樱桃(h264)后再装到另一个盒子里，多了一步对苹果(hevc)转换为樱桃(h264)的操作，自然比直接把苹果拿到另一个盒子（转封装）要消耗更多机器性能。