android原始数据
A. Android MediaCodec surface模式下如何读取原始视频数据
Android 用MediaCodec实现视频硬解码
本文向你讲述如何用android标准的API （MediaCodec）实现视频的硬件编解码。例程将从摄像头采集视频开始，然后进行H264编码，再解码，然后显示。我将尽量讲得简短而清晰，不展示那些不相关的代码。但是，我不建议你读这篇文章，也不建议你开发这类应用，而应该转而开发一些戳鱼、打鸟、其乐融融的程序。好吧，下面的内容是写给那些执迷不悟的人的，看完之后也许你会同意我的说法：Android只是一个玩具，很难指望它来做靠谱的应用。
1、从摄像头采集视频
可以通过摄像头Preview的回调，来获取视频数据。
首先创建摄像头，并设置参数：
[java] view plain
cam = Camera.open();
cam.setPreviewDisplay(holder);
Camera.Parameters parameters = cam.getParameters();
parameters.setFlashMode("off"); // 无闪光灯
parameters.setWhiteBalance(Camera.Parameters.WHITE_BALANCE_AUTO);
parameters.setSceneMode(Camera.Parameters.SCENE_MODE_AUTO);
parameters.setFocusMode(Camera.Parameters.FOCUS_MODE_AUTO);
parameters.setPreviewFormat(ImageFormat.YV12);
parameters.setPictureSize(camWidth, camHeight);
parameters.setPreviewSize(camWidth, camHeight);
//这两个属性 如果这两个属性设置的和真实手机的不一样时，就会报错
cam.setParameters(parameters);
宽度和高度必须是摄像头支持的尺寸，否则会报错。要获得所有支持的尺寸，可用getSupportedPreviewSizes，这里不再累述。据说所有的参数必须设全，漏掉一个就可能报错，不过只是据说，我只设了几个属性也没出错。 然后就开始Preview了：
[java] view plain
buf = new byte[camWidth * camHeight * 3 / 2];
cam.addCallbackBuffer(buf);
cam.setPreviewCallbackWithBuffer(this);
cam.startPreview();
setPreviewCallbackWithBuffer是很有必要的，不然每次回调系统都重新分配缓冲区，效率会很低。
在onPreviewFrame中就可以获得原始的图片了（当然，this 肯定要 implements PreviewCallback了）。这里我们是把它传给编码器：
[java] view plain
public void onPreviewFrame(byte[] data, Camera camera) {
if (frameListener != null) {
frameListener.onFrame(data, 0, data.length, 0);
}
cam.addCallbackBuffer(buf);
}
2、编码
首先要初始化编码器：
[java] view plain
mediaCodec = MediaCodec.createEncoderByType("Video/AVC");
MediaFormat mediaFormat = MediaFormat.createVideoFormat(type, width, height);
mediaFormat.setInteger(MediaFormat.KEY_BIT_RATE, 125000);
mediaFormat.setInteger(MediaFormat.KEY_FRAME_RATE, 15);
mediaFormat.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatYUV420Planar);
mediaFormat.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 5);
mediaCodec.configure(mediaFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
mediaCodec.start();
然后就是给他喂数据了，这里的数据是来自摄像头的：
[java] view plain
public void onFrame(byte[] buf, int offset, int length, int flag) {
ByteBuffer[] inputBuffers = mediaCodec.getInputBuffers();
ByteBuffer[] outputBuffers = mediaCodec.getOutputBuffers();
int inputBufferIndex = mediaCodec.dequeueInputBuffer(-1);
if (inputBufferIndex >= 0)
ByteBuffer inputBuffer = inputBuffers[inputBufferIndex];
inputBuffer.clear();
inputBuffer.put(buf, offset, length);
mediaCodec.queueInputBuffer(inputBufferIndex, 0, length, 0, 0);
}
MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();
int outputBufferIndex = mediaCodec.dequeueOutputBuffer(bufferInfo,0);
while (outputBufferIndex >= 0) {
ByteBuffer outputBuffer = outputBuffers[outputBufferIndex];
if (frameListener != null)
frameListener.onFrame(outputBuffer, 0, length, flag);
mediaCodec.releaseOutputBuffer(outputBufferIndex, false);
outputBufferIndex = mediaCodec.dequeueOutputBuffer(bufferInfo, 0);
}
先把来自摄像头的数据喂给它，然后从它里面取压缩好的数据喂给解码器。
3、解码和显示
首先初始化解码器：
[java] view plain
mediaCodec = MediaCodec.createDecoderByType("Video/AVC");
MediaFormat mediaFormat = MediaFormat.createVideoFormat(mime, width, height);
mediaCodec.configure(mediaFormat, surface, null, 0);
mediaCodec.start();
这里通过给解码器一个surface，解码器就能直接显示画面。
然后就是处理数据了：
[java] view plain
public void onFrame(byte[] buf, int offset, int length, int flag) {
ByteBuffer[] inputBuffers = mediaCodec.getInputBuffers();
int inputBufferIndex = mediaCodec.dequeueInputBuffer(-1);
if (inputBufferIndex >= 0) {
ByteBuffer inputBuffer = inputBuffers[inputBufferIndex];
inputBuffer.clear();
inputBuffer.put(buf, offset, length);
mediaCodec.queueInputBuffer(inputBufferIndex, 0, length, mCount * 1000000 / FRAME_RATE, 0);
mCount++;
}
MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();
int outputBufferIndex = mediaCodec.dequeueOutputBuffer(bufferInfo,0);
while (outputBufferIndex >= 0) {
mediaCodec.releaseOutputBuffer(outputBufferIndex, true);
outputBufferIndex = mediaCodec.dequeueOutputBuffer(bufferInfo, 0);
}
}
queueInputBuffer第三个参数是时间戳，其实怎么写都无所谓，只要是按时间线性增加的就可以，这里就随便弄一个了。后面一段的代码就是把缓冲区给释放掉，因为我们直接让解码器显示，就不需要解码出来的数据了，但是必须要这么释放一下，否则解码器始终给你留着，内存就该不够用了。
好了，到现在，基本上就可以了。如果你运气够好，现在就能看到视频了，比如在我的三星手机上这样就可以了。但是，我试过几个其他平台，多数都不可以，总是有各种各样的问题，如果要开发一个不依赖平台的应用，还有很多的问题要解决。说说我遇到的一些情况：
1、视频尺寸
一般都能支持176X144/352X288这种尺寸，但是大一些的，640X480就有很多机子不行了，至于为什么，我也不知道。当然，这个尺寸必须和摄像头预览的尺寸一致，预览的尺寸可以枚举一下。
2、颜色空间
根据ANdroid SDK文档，确保所有硬件平台都支持的颜色，在摄像头预览输出是YUV12，在编码器输入是COLOR_FormatYUV420Planar，也就是前面代码中设置的那样。 不过，文档终究是文档，否则安卓就不是安卓。
在有的平台上，这两个颜色格式是一样的，摄像头的输出可以直接作为编码器的输入。也有的平台，两个是不一样的，前者就是YUV12，后者等于I420，需要把前者的UV分量颠倒一下。下面的代码效率不高，可供参考。
[java] view plain
byte[] i420bytes = null;
private byte[] swapYV12toI420(byte[] yv12bytes, int width, int height) {
if (i420bytes == null)
i420bytes = new byte[yv12bytes.length];
for (int i = 0; i < width*height; i++)
i420bytes[i] = yv12bytes[i];
for (int i = width*height; i < width*height + (width/2*height/2); i++)
i420bytes[i] = yv12bytes[i + (width/2*height/2)];
for (int i = width*height + (width/2*height/2); i < width*height + 2*(width/2*height/2); i++)
i420bytes[i] = yv12bytes[i - (width/2*height/2)];
return i420bytes;
}
这里的困难是，我不知道怎样去判断是否需要这个转换。据说，Android 4.3不用再从摄像头的PreView里面取图像，避开了这个问题。这里有个例子，虽然我没读，但看起来挺厉害的样子，应该不会有错吧（觉厉应然）。http://bigflake.com/mediacodec/CameraToMpegTest.java.txt
3、输入输出缓冲区的格式
SDK里并没有规定格式，但是，这种情况H264的格式基本上就是附录B。但是，也有比较有特色的，它就是不带那个StartCode，就是那个0x000001，搞得把他编码器编出来的东西送给他的解码器，他自己都解不出来。还好，我们可以自己加。
[java] view plain
ByteBuffer outputBuffer = outputBuffers[outputBufferIndex];
byte[] outData = new byte[bufferInfo.size + 3];
outputBuffer.get(outData, 3, bufferInfo.size);
if (frameListener != null) {
if ((outData[3]==0 && outData[4]==0 && outData[5]==1)
|| (outData[3]==0 && outData[4]==0 && outData[5]==0 && outData[6]==1))
{
frameListener.onFrame(outData, 3, outData.length-3, bufferInfo.flags);
}
else
{
outData[0] = 0;
outData[1] = 0;
outData[2] = 1;
frameListener.onFrame(outData, 0, outData.length, bufferInfo.flags);
}
}
4、有时候会死在dequeueInputBuffer(-1)上面
根据SDK文档，dequeueInputBuffer 的参数表示等待的时间（毫秒），-1表示一直等，0表示不等。按常理传-1就行，但实际上在很多机子上会挂掉，没办法，还是传0吧，丢帧总比挂掉好。当然也可以传一个具体的毫秒数，不过没什么大意思吧。
B. android手机刷机怎么保存原有的程序数据
进行手机数据备份以保存手机数据：
材料工具：手机
1、打开手机“设置”功能。
C. Android 怎样稳定的获取原生GPS数据
定位了就有经纬度，没定位，则一直闪的；
一般是4个星的时候 会定位。
所以可以根据是否获取有效的经纬度信息来判断是否定位。
卫星的个数 sv_status也是可以通过API获取的。LOCATION类
给一段咱的代码，看看就知道了。
locationManager.addGpsStatusListener(statusListener);//侦听GPS状态
private GpsStatus.Listener statusListener = new GpsStatus.Listener()
{
public void onGpsStatusChanged(int event)
{
// TODO Auto-generated method stub
GpsStatus gpsStatus= locationManager.getGpsStatus(null);
Log.v(TAG,"GPS status listener ");
//Utils.DisplayToastShort(GPSService.this, "GPS status listener ");
switch(event)
{
case GpsStatus.GPS_EVENT_FIRST_FIX:{
//第一次定位时间UTC gps可用
//Log.v(TAG,"GPS is usable");
int i=gpsStatus.getTimeToFirstFix();
Utils.DisplayToastShort(GPSService.this, "GPS 第一次可用 "+i);
Utils.setGPSStatus(Utils.GPS_STATUS.START);
break;
}
case GpsStatus.GPS_EVENT_SATELLITE_STATUS:{//周期的报告卫星状态
//得到所有收到的卫星的信息，包括 卫星的高度角、方位角、信噪比、和伪随机号（及卫星编号）
Iterable<GpsSatellite> allSatellites;
allSatellites = gpsStatus.getSatellites();
Iterator<GpsSatellite>iterator = allSatellites.iterator();
int numOfSatellites = 0;
int maxSatellites=gpsStatus.getMaxSatellites();
while(iterator.hasNext() && numOfSatellites<maxSatellites){
numOfSatellites++;
iterator.next();
}
Log.v(TAG,"GPS is **unusable** "+ numOfSatellites +" "+ maxSatellites);
if( numOfSatellites < 3){
// Utils.DisplayToastShort(GPSService.this, "***卫星少于3颗***");
Utils.setGPSStatus(Utils.GPS_STATUS.STOP);
} else if(numOfSatellites > 7){
Utils.setGPSStatus(Utils.GPS_STATUS.START);
}
break;
}
case GpsStatus.GPS_EVENT_STARTED:{
//Utils.DisplayToastShort(GPSService.this, "GPS start Event");
break;
}
case GpsStatus.GPS_EVENT_STOPPED:{
//Utils.DisplayToastShort(GPSService.this, "GPS **stop*** Event");
Utils.setGPSStatus(Utils.GPS_STATUS.STOP);
break;
}
default :
break;
}
}
};
D. Android MediaCodec
MediaCodec 类为开发者提供了能访问到Android底层媒体 Codec （Encoder/Decoder）的能力，它是Android底层多媒体基础架构的一部分（通常和MediaExtractor、MediaSync、MediaMuxer、MediaCrypto、MediaDrm、Image、Surface、AudioTrack一起使用）。
Codec 对三种类型类型的数据起作用： 编码后的压缩数据 , 原始视频数据 , 原始音频数据 。这三种类型的数据都可以通过 ByteBuffer 来传递给 Codec ，但是对于 原始视频数据 我们建议使用 Surface 来传递，这样可以提高 Codec 的性能， Surface 使用的是 native video buffer ，不用映射或者拷贝成 ByteBuffer ，因此这样的方式更高效。当你使用 Surface 来传递 原始视频数据 时，也就无法获取到了 原始视频数据 ，Android 提供了 ImageReader 帮助你获取到解码后的 原始视频数据 。这种方式可能仍然有要比 ByteBuffer 的方式更加高效，因为某些 native video buffer 会直接映射成 byteBuffer 。当然如果你 ByteBuffer 的模式，你可以使用 Image 类提供的 getInput/OutputImage(int) 来获取 原始视频数据 。
给 Decoder 输入的 InputBuffer 或者 Encoder 输出的 outputBuffer 包含的都是编码后的压缩数据，数据的压缩类型由 MediaFormat#KEY_MIME 指明。对于视频类型而言，这个数据通常是一个压缩后的视频帧。对于音频数据而言，通常是一个访问单元（一个编码的音频段，通常包含几毫秒的音频数据，数据类型format type 指定），有时候，一个音频单元对于一个 buffer 而言可能有点宽松，所以一个 buffer 里可能包含多个编码后的音频数据单元。无论 Buffer 包含的是视频数据还是音频数据， Buffer 都不会再任意字节边界上开始或者结束，而是在帧（视频）或者单元（音频）的边界上开始或者结束。除非它们被BUFFER_FLAG_PARTIAL_FRAME标记。
原始音频Buffer包含PCM音频数据的整个帧，是每一个通道按着通道顺序的采样数据。每一个采样按16Bit量化。
在 ByteBuffer 模式下，视频数据的排布由 MediaFormat#KEY_COLOR_FORMAT 指定，我们可以通过 getCodecInfo().MediaCodecInfo#getCapabilitiesForType.CodecCapabilities#colorFormats 获取到一个设备支持的 color format 数组。视频 Codec 可能支持三种类型的Color Format:
从 Build.VERSION_CODES.LOLLIPOP_MR1 开始所有的视频 Codec 都支持 flexible YUV 4:2:0
对于 Build.VERSION_CODES.LOLLIPOP 之前并且支持 Image 类时，我们需要使用 MediaFormat#KEY_STRIDE 和 MediaFormat#KEY_SLICE_HEIGHT 的值去理解输出的原始视频数据的布局。
键值 MediaFormat#KEY_WIDTH 和 MediaFormat#KEY_HEIGHT 指明了视频Frame的size。然而，对于大多数用于编码的视频图像，他们只占用了video Frame的一部分。这部分用一个 'crop rectangle 来表示。
我们需要用下面的一些 keys 从获取原始视频数据的 crop rectangle ，如果 out format 中没有包含这些 keys ，则表示视频占据了整个 video Frame ，这个 crop rectangle 的解释应该立足于应用任何 MediaFormat#KEY_ROTATION 之前。
下面是在旋转之前计算视频的尺寸的案例：
从概念上讲Codec的声明周期存在三种状态： Stoped ， Executing ， Released 。 Stoped 状态是一个集合状态，它聚合了三种状态： Uninitialized ， Configured ，和 Error ，同时 Executing 状态的处理也是通过三个子状态来完成： Flushed ， Running ， End-of-Stream 。
Executing 状态有三个子状态：Flushed，Running，和End-of-Stream，当我们调用玩 Start() 函数后， Codec 就立刻进入 Flushed 子状态，这个状态下，它持有全部的buffer，只要第一个Input buffer被dequeued，Codec就转变成 Running 子状态，这个状态占据了 Codec 的生命周期的绝大部分。当入队一个带有 end-of-stream标志的InputBuffer后， Codec 将转换成 End of Stream 子状态，在这个状态下， Codec 将不会再接收任何输入的数据，但是仍然会产生output buffer ,直到end-of-Stream标记的buffer被输出。我们可以在 Executing 状态的任何时候，使用 flush() 函数，将 Codec 切换成 Flushed 状态。
调用 stop() 函数会将 Codec 返回到 Uninitialized 状态，这样我们就可以对 Codec 进行重新配置，当你用完了 Codec 后，你必须要调用 release() 函数去释放这个 Codec 。
在极少数情况下， Codec 可能也会遇到错误，此时 Codec 将会切换到 Error 状态，我们可以通过queuing操作获取到一个无效的返回值，或者有时会通过异常来的得知 Codec 发生了错误。通过调用 reset() 函数，将 Codec 进行重置，这样 Codec 将切换成 Uninitalized 状态，我们可以在任何状态下调用 rest() 函数将Codec 将切换成 Uninitalized`状态。
使用 MediaCodecList 创建一个指定 MediaFormat 的MediaCodec。当我们解码一个文件或者一个流时，我们可以通过 MediaExtractor#getTrackFormat 获取期望的Fromat，同时我们可以通过 MediaFormat#setFeatureEnabled 为 Codec 注入任何我们想要的特性。然后调用 MediaCodecList#findDecoderForFormat 获取能够处理对应format数据 Codec 的name，最后我们使用 createByCodecName(String) 创建出这个 Codec 。
我们也可以使用 createDecoder/EncoderByType(java.lang.String) 函数来创建指定的 MIME 类型的 Codec ,但是这样我们无法向其中注入一些指定的特性，这样创建的 Codec 可能不能处理我们期望的媒体类型数据。
E. Android -- 音视频基础知识
帧，是视频的一个基本概念，表示一张画面，如上面的翻页动画书中的一页，就是一帧。一个视频就是由许许多多帧组成的。
帧率，即单位时间内帧的数量，单位为：帧/秒 或fps（frames per second）。一秒内包含多少张图片，图片越多，画面越顺滑，过渡越自然。 帧率的一般以下几个典型值：
24/25 fps：1秒 24/25 帧，一般的电影帧率。
30/60 fps：1秒 30/60 帧，游戏的帧率，30帧可以接受，60帧会感觉更加流畅逼真。
85 fps以上人眼基本无法察觉出来了，所以更高的帧率在视频里没有太大意义。
这里我们只讲常用到的两种色彩空间。
RGB的颜色模式应该是我们最熟悉的一种，在现在的电子设备中应用广泛。通过R G B三种基础色，可以混合出所有的颜色。
这里着重讲一下YUV，这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。
早期的电视都是黑白的，即只有亮度值，即Y。有了彩色电视以后，加入了UV两种色度，形成现在的YUV，也叫YCbCr。
Y：亮度，就是灰度值。除了表示亮度信号外，还含有较多的绿色通道量。
U：蓝色通道与亮度的差值。
V：红色通道与亮度的差值。
音频数据的承载方式最常用的是 脉冲编码调制 ，即 PCM 。
在自然界中，声音是连续不断的，是一种模拟信号，那怎样才能把声音保存下来呢？那就是把声音数字化，即转换为数字信号。
我们知道声音是一种波，有自己的振幅和频率，那么要保存声音，就要保存声音在各个时间点上的振幅。
而数字信号并不能连续保存所有时间点的振幅，事实上，并不需要保存连续的信号，就可以还原到人耳可接受的声音。
根据奈奎斯特采样定理：为了不失真地恢复模拟信号，采样频率应该不小于模拟信号频谱中最高频率的2倍。
根据以上分析，PCM的采集步骤分为以下步骤：
采样率，即采样的频率。
上面提到，采样率要大于原声波频率的2倍，人耳能听到的最高频率为20kHz，所以为了满足人耳的听觉要求，采样率至少为40kHz，通常为44.1kHz，更高的通常为48kHz。
采样位数，涉及到上面提到的振幅量化。波形振幅在模拟信号上也是连续的样本值，而在数字信号中，信号一般是不连续的，所以模拟信号量化以后，只能取一个近似的整数值，为了记录这些振幅值，采样器会采用一个固定的位数来记录这些振幅值，通常有8位、16位、32位。
位数越多，记录的值越准确，还原度越高。
最后就是编码了。由于数字信号是由0，1组成的，因此，需要将幅度值转换为一系列0和1进行存储，也就是编码，最后得到的数据就是数字信号：一串0和1组成的数据。
整个过程如下：
声道数，是指支持能不同发声（注意是不同声音）的音响的个数。 单声道：1个声道
双声道：2个声道
立体声道：默认为2个声道
立体声道（4声道）：4个声道
码率，是指一个数据流中每秒钟能通过的信息量，单位bps（bit per second）
码率 = 采样率 * 采样位数 * 声道数
这里的编码和上面音频中提到的编码不是同个概念，而是指压缩编码。
我们知道，在计算机的世界中，一切都是0和1组成的，音频和视频数据也不例外。由于音视频的数据量庞大，如果按照裸流数据存储的话，那将需要耗费非常大的存储空间，也不利于传送。而音视频中，其实包含了大量0和1的重复数据，因此可以通过一定的算法来压缩这些0和1的数据。
特别在视频中，由于画面是逐渐过渡的，因此整个视频中，包含了大量画面/像素的重复，这正好提供了非常大的压缩空间。
因此，编码可以大大减小音视频数据的大小，让音视频更容易存储和传送。
视频编码格式有很多，比如H26x系列和MPEG系列的编码，这些编码格式都是为了适应时代发展而出现的。
其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）国际电传视讯联盟主导
MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的组织）主导。
当然，他们也有联合制定的编码标准，那就是现在主流的编码格式H264，当然还有下一代更先进的压缩编码标准H265。
H264是目前最主流的视频编码标准，所以我们后续的文章中主要以该编码格式为基准。
H264由ITU和MPEG共同定制，属于MPEG-4第十部分内容。
我们已经知道，视频是由一帧一帧画面构成的，但是在视频的数据中，并不是真正按照一帧一帧原始数据保存下来的（如果这样，压缩编码就没有意义了）。
H264会根据一段时间内，画面的变化情况，选取一帧画面作为完整编码，下一帧只记录与上一帧完整数据的差别，是一个动态压缩的过程。
在H264中，三种类型的帧数据分别为
I帧：帧内编码帧。就是一个完整帧。
P帧：前向预测编码帧。是一个非完整帧，通过参考前面的I帧或P帧生成。
B帧：双向预测内插编码帧。参考前后图像帧编码生成。B帧依赖其前最近的一个I帧或P帧及其后最近的一个P帧。
全称：Group of picture。指一组变化不大的视频帧。
GOP的第一帧成为关键帧：IDR
IDR都是I帧，可以防止一帧解码出错，导致后面所有帧解码出错的问题。当解码器在解码到IDR的时候，会将之前的参考帧清空，重新开始一个新的序列，这样，即便前面一帧解码出现重大错误，也不会蔓延到后面的数据中。
DTS全称：Decoding Time Stamp。标示读入内存中数据流在什么时候开始送入解码器中进行解码。也就是解码顺序的时间戳。
PTS全称：Presentation Time Stamp。用于标示解码后的视频帧什么时候被显示出来。
前面我们介绍了RGB和YUV两种图像色彩空间。H264采用的是YUV。
YUV存储方式分为两大类：planar 和 packed。
planar如下：
packed如下：
上面说过，由于人眼对色度敏感度低，所以可以通过省略一些色度信息，即亮度共用一些色度信息，进而节省存储空间。因此，planar又区分了以下几种格式：YUV444、 YUV422、YUV420。
YUV 4:4:4采样，每一个Y对应一组UV分量。
YUV 4:2:2采样，每两个Y共用一组UV分量。
YUV 4:2:0采样，每四个Y共用一组UV分量。
其中，最常用的就是YUV420。
YUV420属于planar存储方式，但是又分两种类型：
YUV420P：三平面存储。数据组成为YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。
YUV420SP：两平面存储。分为两种类型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）
原始的PCM音频数据也是非常大的数据量，因此也需要对其进行压缩编码。
和视频编码一样，音频也有许多的编码格式，如：WAV、MP3、WMA、APE、FLAC等等，音乐发烧友应该对这些格式非常熟悉，特别是后两种无损压缩格式。
但是，我们今天的主角不是他们，而是另外一个叫AAC的压缩格式。
AAC是新一代的音频有损压缩技术，一种高压缩比的音频压缩算法。在MP4视频中的音频数据，大多数时候都是采用AAC压缩格式。
AAC格式主要分为两种：ADIF、ADTS。
ADIF：Audio Data Interchange Format。音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。这种格式常用在磁盘文件中。
ADTS：Audio Data Transport Stream。音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。
ADIF数据格式：
ADTS 一帧 数据格式（中间部分，左右省略号为前后数据帧）：
AAC内部结构也不再赘述，可以参考AAC 文件解析及解码流程
细心的读者可能已经发现，前面我们介绍的各种音视频的编码格式，没有一种是我们平时使用到的视频格式，比如：mp4、rmvb、avi、mkv、mov...
没错，这些我们熟悉的视频格式，其实是包裹了音视频编码数据的容器，用来把以特定编码标准编码的视频流和音频流混在一起，成为一个文件。
例如：mp4支持H264、H265等视频编码和AAC、MP3等音频编码。
我们在一些播放器中会看到，有硬解码和软解码两种播放形式给我们选择，但是我们大部分时候并不能感觉出他们的区别，对于普通用户来说，只要能播放就行了。
那么他们内部究竟有什么区别呢？
在手机或者PC上，都会有CPU、GPU或者解码器等硬件。通常，我们的计算都是在CPU上进行的，也就是我们软件的执行芯片，而GPU主要负责画面的显示（是一种硬件加速）。
所谓软解码，就是指利用CPU的计算能力来解码，通常如果CPU的能力不是很强的时候，一则解码速度会比较慢，二则手机可能出现发热现象。但是，由于使用统一的算法，兼容性会很好。
硬解码，指的是利用手机上专门的解码芯片来加速解码。通常硬解码的解码速度会快很多，但是由于硬解码由各个厂家实现，质量参差不齐，非常容易出现兼容性问题。
MediaCodec 是Android 4.1(api 16)版本引入的编解码接口，是所有想在Android上开发音视频的开发人员绕不开的坑。
由于Android碎片化严重，虽然经过多年的发展，Android硬解已经有了很大改观，但实际上各个厂家实现不同， 还是会有一些意想不到的坑。
相对于FFmpeg，Android原生硬解码还是相对容易入门一些，所以接下来，我将会从MediaCodec入手，讲解如何实现视频的编解码，以及引入OpenGL实现对视频的编辑，最后才引入FFmpeg来实现软解，算是一个比较常规的音视频开发入门流程吧。