再经过转码、分发、写入分布式系统等，以及经过CDN（content delivery net，内容分发网）传输给观众端。转码，分发，切片等过程是将数据传给后端，后端进行的一系列操作，而CDN是将处理的音视频数据内容进行分发的网络，这里不讨论。我们只讨论属于移动端的音视频数据处理及传输的1），2），3）过程。

2.数据采集

直播流程中，主播端的数据处理包括：数据采集、编码和封装。数据的采集和处理包括视频和音频的采集处理。

2.1 视频数据的采集

相机的采集及预览可以通过两个方式实现：

（1）SurfaceView+Camera

（2）TextureView+Camera

这里我们详细讨论第一种实现方案。

在Android层，实现从打开相机到得到图像数据以及预览的过程大致可以分为两部分：从硬件得到Camera预览数据、SurfaceView（也可以是TextureView）显示画面，如下图所示。

SurfaceView是Camera数据的显示界面。想要将SurfaceView和Camera联系起来，需要用到Surface和SurfaceHolder。它们之间的关系是：

这里，Surface是用来处理屏幕显示内容合成器所管理的原始缓存区的工具。它通常由图像缓冲区的消费者来创建（如：SurfaceTexture，MediaRecorder，编解码时的MediaCodec），然后被移交给生产者（如：MediaPlayer）或者是显示到其上（如：CameraDevice）。正如Fig.3所示，Google提供了一个SurfaceHolder类来对Surface的属性进行控制。

接下来，分别对这三个部分进行介绍。

2.1.1 SurfaceHolder

一个抽象接口，给持有surface的对象使用。它可以控制surface的大小和格式，编辑surface中的像素格式，以及监听surface的变化。这个接口通常通过SurfaceView类获得，它有3个回调方法：


//surface第一次创建时回调
surfaceCreated(SurfaceHolder holder)
 
//surface变化的时候回调(格式/大小)，如设置横竖屏
surfaceChanged(SurfaceHolder holder, int format, int width, int height)
 
//surface销毁的时候回调
surfaceDestroyed(SurfaceHolder holder)

2.1.2 SurfaceView类

SurfaceView继承自View，其中有两个成员变量，一个是Surface对象，一个是SuraceHolder对象。surfaceView用这两个对象实现什么目的呢？

· SurfaceView把Surface显示在屏幕上。Surface是处理原始缓冲区的工具，可以理解为一块“还未看见”的画布。即在SurfaceView显示前一帧的画面时，Surface在准备即将要展示的下一帧的画面。等到下一帧准备好，就可以进行刷新。

· SurfaceView通过SuraceHolder告诉我们Surface的状态（创建、变化、销毁）

· 通过getHolder()方法获得当前SurfaceView的SuraceHolder对象，然后就可以对SuraceHolder对象添加回调来监听Surface的状态

即SuffaceView.getHolder().addCallBack(SurfaceHolder.Callback);

2.1.3 Camera

从Camera得到数据这部分来看，Camera初始化需要做的：


//1. 打开摄像头,这里，参数id是指开启前置还是后置摄像头，1代表前置，0代表后置
 
camera=android.hardware.Camera.open(int id);
 
//2. 设置各个参数，例如：
 
Camera.Parameters parameters = mCamera.getParameters(); //获取摄像头参数
 
// 可以根据情况设置参数
 
// 镜头缩放
 
parameters.setZoom(); 
 
// 设置预览照片的大小
 
parameters.setPreviewSize(200, 200);
 
// 设置预览照片时每秒显示多少帧的最小值和最大值
 
parameters.setPreviewFpsRange(4, 10);
 
// 设置图片格式
 
parameters.setPictureFormat(ImageFormat.JPEG);
 
// 设置JPG照片的质量  图片的质量[0-100],100最高
 
parameters.set("jpeg-quality", 85);
 
// 设置照片的大小
 
parameters.setPictureSize(200, 200);
 
camera.setDisplayOrientation(90)；// 预览方向,一般是通过相机设置方向来实现。

最后，将参数传给Camera

mCamera.setParameters(parameters);

此外还需要注意一个问题。即相机图像数据来自于相机硬件的图像传感器，这个传感器有一个默认的取景方向。前置摄像头需要设置展示方向为270度（camera.setDisplayOrientation(270)），后置摄像头需要设置展示方向90度（camera.setDisplayOrientation(90)）。

以上就是camera的初始化。想要将camera采集到的数据展示出来，还需要一个必不可少的将Surface和Camera联系起来的环节：

mCamera.setPreviewDisplay(holder);

然后，将camera开启预览：

mCamera.startPreview();

此过程在创建Surface成功后即可添加。一般可以添加在SurfaceHolder.Callback接口的surfaceCreated方法或者surfaceChanged接口中。

最后，记得将Camera释放：

mCamera.release();

至于相机开启后，相机初始化，native层变化的过程，可以参考：

blog：

https://blog.csdn.net/qq_38907791/article/details/87987591

2.2 获取相机数据

上述过程是直接将相机得到的数据展示在屏幕上。然而，在开发过程中，有些需求是获取相机得到的像素数据，以实现其他需求。那么如何在android中获取相关图像数据呢？

Google提供了Camera的相关接口：Camera.PreviewCallback

在接口的方法中即可获得byte[]数组。这个数组是将像素（Android 中Google支持的 Camera Preview Callback的YUV常用格式有两种：一个是NV21，一个是YV12。Android一般默认使用YCbCr_420_SP的格式（NV21））按照一定规则排列得到的一维数组。如果想要得到某个格式下的像素byte数组，可以通过相机参数设置来实现：


Camera.Parameters parameters = camera.getParameters();
 
parameters.setPreviewFormat(ImageFormat.NV21);
 
camera.setParameters(parameters);

之后，通过Camera.PreviewCallback接口的onPreviewFrame方法中获取到像素数组并展示。具体代码如下：


mCamera.setPreviewCallback(new Camera.PreviewCallback() {
 
    @Override
 
    public void onPreviewFrame(byte[] data, Camera camera) {
 
        // 处理data，这里面的data数据就是NV21格式的数据，将数据显示在ImageView控件上面
 
        mPreviewSize = camera.getParameters().getPreviewSize();// 获取尺寸,格式转换的时候要用到
        // 取发YUVIMAGE
 
        YuvImage yuvimage = new YuvImage(
 
                data,
 
                ImageFormat.NV21,
 
                mPreviewSize.width,
 
                mPreviewSize.height,
 
                null);
 
        mBaos = new ByteArrayOutputStream();
 
        // yuvimage转换成jpg格式
 
        yuvimage.compressToJpeg(new Rect(0, 0, mPreviewSize.width, mPreviewSize.height), 100, mBaos);// 80--JPG图片的质量[0-100],100最高
 
        mImageBytes = mBaos.toByteArray();
 
        // 将mImageBytes转换成bitmap
 
        BitmapFactory.Options options = new BitmapFactory.Options();
 
        options.inPreferredConfig = Bitmap.Config.RGB_565;
 
        mBitmap = BitmapFactory.decodeByteArray(mImageBytes, 0, mImageBytes.length, options);
 
        mImageView.setImageBitmap(rotateBitmap(mBitmap, getDegree()));

以上，就是通过camera实现预览以及获取数据后转换为Bitmap的全过程。

2.3 音频采集

Android一般有两种方式进行音频采集：MediaRecorder和AudioRecord。二者的区别在于，MediaRecorder是经过编码压缩的，而AudioRecord得到的是PCM（脉冲编码调制）数据，也就是原音频文件。想要对音频文件进行处理，比如变声、变速等，就需要使用AudioRecord进行音频采集，再对得到的音频数据进行变声变速等处理。

关于音频的介绍及应用可参考文章：https://www.jianshu.com/p/125b94af7c08

3 编码

通过以上过程，我们就得到音频数据，图像纹理。接下来，就需要将得到的音频和视频进行编码。那么为什么要进行编码呢？

众所周知，视频是由一张张的图片快速连续播放才形成的动画效果。一般来说，每秒钟最少15张图像，即帧率为15fps，人眼不会感觉到卡顿。每张彩色图像有RGB三通道，每个通道的数值范围是0-255，用8个二进制来表示。也就是说，每个像素点都包含3*8个二进制数值。如果一张图像的分辨率是1280*720，它的像素点个数为1280*720个。那么在没有经过编码压缩的情况下，传输或者保存一张图像需要的空间是1280*720*3*8bit.而每秒钟按照最少的15张来计算，在直播中，每秒钟就需要传送1280*720*3*8*15/8=41 472 000byte=41472kB.一秒钟最少传输41MB的数据量，现在的网络带宽明显是不能满足这个需求的。编码压缩就是利用图像的时间和空间的相关性，将图像大小压缩到远小于原图像的目的。直播中用到的视频编码有H264编码格式，音频编码格式为aac。

除了编码之外，还需要对音视频进行封装。常见的有flv，ts，mpeg4，mkv等。我们这里讨论的封装格式是flv。

3.1 常见编码格式

编码实质上就是将音视频数据进行压缩，以减少音视频数据在网络上传输的压力。

相应地，在播放端也要进行解码，以恢复出音视频数据。

编码分为软编码和硬编码。二者最主要的区别在于是否使用cpu进行编码。使用cpu进行编码的编码方式是软编码，比如FFMPEG，使用GPU，FPGA等硬件进行编码的称为硬编码。软编码是可以适配多个平台，但是内存占用率相对较高。硬编码内存占用率相对较低，但是不像软编码可以适配多个平台，有局限性。

无论是软编码还是硬编码，都需要对音频和视频编码。现有多种视频编码格式和音频编码格式。下图为常见音频编码格式比较：

下图为常见视频编码格式比较：

这里我们重点讨论h264视频编码格式。

3.2 h264原理概述

H264编码压缩技术主要采用了以下几种方法对视频数据进行压缩。包括：

帧内预测压缩，解决的是空域数据冗余问题。
帧间预测压缩（运动估计与补偿），解决的是时域数据冗余问题。
整数离散余弦变换（DCT），将空间上的相关性变为频域上无关的数据然后进行量化。
CABAC压缩。

经过压缩后的帧分为：I帧，P帧和B帧:

I帧：关键帧，采用帧内压缩技术。
P帧：向前参考帧，在压缩时，只参考前面已经处理的帧。采用帧音压缩技术。
B帧：双向参考帧，在压缩时，它即参考前而的帧，又参考它后面的帧。采用帧间压缩技术。

除了I/P/B帧外，还有图像序列GOP。

　　GOP:两个I帧之间是一个图像序列，在一个图像序列中只有一个I帧。如下图所示：

下面我们就来详细描述一下H264压缩技术。
H264的基本原理其实非常简单，下我们就简单的描述一下H264压缩数据的过程。通过摄像头采集到的视频帧（按每秒 30 帧算），被送到 H264 编码器的缓冲区中。编码器先要为每一帧图片划分宏块。

以下面这张图为例:

3.2.1 划分宏块

H264默认是使用 16X16 大小的区域作为一个宏块，也可以划分成 8X8 大小。

划分好宏块后，计算宏块的象素值。

以此类推，计算一幅图像中每个宏块的像素值，所有宏块都处理完后如下面的样子。

3.2.2 划分子块

H264对比较平坦的图像使用 16X16 大小的宏块。但为了更高的压缩率，还可以在 16X16 的宏块上更划分出更小的子块。子块的大小可以是 8X16､ 16X8､ 8X8､ 4X8､ 8X4､ 4X4非常的灵活。

上幅图中，红框内的 16X16 宏块中大部分是蓝色背景，而三只鹰的部分图像被划在了该宏块内，为了更好的处理三只鹰的部分图像，H264就在 16X16 的宏块内又划分出了多个子块。

这样再经过帧内压缩，可以得到更高效的数据。下图是分别使用mpeg-2和H264对上面宏块进行压缩后的结果。其中左半部分为MPEG-2子块划分后压缩的结果，右半部分为H264的子块划压缩后的结果，可以看出H264的划分方法更具优势。

宏块划分好后，就可以对H264编码器缓存中的所有图片进行分组了。

3.2.3 帧分组

对于视频数据主要有两类数据冗余，一类是时间上的数据冗余，另一类是空间上的数据冗余。其中时间上的数据冗余是最大的。下面我们就先来说说视频数据时间上的冗余问题。

为什么说时间上的冗余是最大的呢？假设摄像头每秒抓取30帧，这30帧的数据大部分情况下都是相关联的。也有可能不止30帧的的数据，可能几十帧，上百帧的数据都是关联特别密切的。

对于这些关联特别密切的帧，其实我们只需要保存一帧的数据，其它帧都可以通过这一帧再按某种规则预测出来，所以说视频数据在时间上的冗余是最多的。

为了达到相关帧通过预测的方法来压缩数据，就需要将视频帧进行分组。那么如何判定某些帧关系密切，可以划为一组呢？我们来看一下例子，下面是捕获的一组运动的台球的视频帧，台球从右上角滚到了左下角。

H264编码器会按顺序，每次取出两幅相邻的帧进行宏块比较，计算两帧的相似度。如下图：

通过宏块扫描与宏块搜索可以发现这两个帧的关联度是非常高的。进而发现这一组帧的关联度都是非常高的。因此，上面这几帧就可以划分为一组。其算法是：在相邻几幅图像画面中，一般有差别的像素只有10%以内的点,亮度差值变化不超过2%，而色度差值的变化只有1%以内，我们认为这样的图可以分到一组。

在这样一组帧中，经过编码后，我们只保留第一帖的完整数据，其它帧都通过参考上一帧计算出来。我们称第一帧为IDR／I帧，其它帧我们称为P／B帧，这样编码后的数据帧组我们称为GOP。

3.2.4 运动估计与补偿

在H264编码器中将帧分组后，就要计算帧组内物体的运动矢量了。还以上面运动的台球视频帧为例，我们来看一下它是如何计算运动矢量的。

H264编码器首先按顺序从缓冲区头部取出两帧视频数据，然后进行宏块扫描。当发现其中一幅图片中有物体时，就在另一幅图的邻近位置（搜索窗口中）进行搜索。如果此时在另一幅图中找到该物体，那么就可以计算出物体的运动矢量了。下面这幅图就是搜索后的台球移动的位置。

通过上图中台球位置相差，就可以计算出台图运行的方向和距离。H264依次把每一帧中球移动的距离和方向都记录下来就成了下面的样子。

运动矢量计算出来后，将相同部分（也就是绿色部分）减去，就得到了补偿数据。我们最终只需要将补偿数据进行压缩保存，以后在解码时就可以恢复原图了。压缩补偿后的数据只需要记录很少的一点数据。如下所示：

我们把运动矢量与补偿称为帧间压缩技术，它解决的是视频帧在时间上的数据冗余。除了帧间压缩，帧内也要进行数据压缩，帧内数据压缩解决的是空间上的数据冗余。下面我们就来介绍一下帧内压缩技术。

3.2.5 帧内预测

人眼对图象都有一个识别度，对低频的亮度很敏感，对高频的亮度不太敏感。所以基于一些研究，可以将一幅图像中人眼不敏感的数据去除掉。这样就提出了帧内预测技术。

H264的帧内压缩与JPEG很相似。一幅图像被划分好宏块后，对每个宏块可以进行 9 种模式的预测。找出与原图最接近的一种预测模式。

下面这幅图是对整幅图中的每个宏块进行预测的过程。

帧内预测后的图像与原始图像的对比如下：

然后，将原始图像与帧内预测后的图像相减得残差值。

再将我们之前得到的预测模式信息一起保存起来，这样我们就可以在解码时恢复原图了。效果如下：

经过帧内与帧间的压缩后，虽然数据有大幅减少，但还有优化的空间。

3.2.6 对残差数据做DCT

可以将残差数据做整数离散余弦变换，去掉数据的相关性，进一步压缩数据。如下图所示，左侧为原数据的宏块，右侧为计算出的残差数据的宏块。

将残差数据宏块数字化后如下图所示：

将残差数据宏块进行 DCT 转换。

去掉相关联的数据后，我们可以看出数据被进一步压缩了。

做完 DCT 后，还不够，还要进行 CABAC 进行无损压缩。

3.2.7 CABAC

上面的帧内压缩是属于有损压缩技术。也就是说图像被压缩后，无法完全复原。而CABAC属于无损压缩技术。

无损压缩技术大家最熟悉的可能就是哈夫曼编码了，给高频的词一个短码，给低频词一个长码从而达到数据压缩的目的。MPEG-2中使用的VLC就是这种算法，我们以 A-Z 作为例子，A属于高频数据，Z属于低频数据。看看它是如何做的。

CABAC也是给高频数据短码，给低频数据长码。同时还会根据上下文相关性进行压缩，这种方式又比VLC高效很多。其效果如下：

现在将 A-Z 换成视频帧，它就成了下面的样子。

从上面这张图中明显可以看出采用 CACBA 的无损压缩方案要比 VLC 高效的多。

以上是h264编码原理，接下来查看具体的编码实现方式：https://blog.csdn.net/murongxian_1/article/details/111224953

我也来凑个热闹

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/花生_TL007/article/detail/194870