android音

㈠ Android音视频【八】音频基础

前些文章讲了视频，我们开始音频。

开始介绍前，先看一个声音的波形图：

声音是一种压力波，当敲击键盘或者撞击物体时，它们的震动会引起空气的震动，使空气产生疏密变化，由此就形成了一种声波。

声波的三要素是频率、振幅、和波形，频率代表音阶的高低，振幅代表响度，波形代表音色。

频率 ： 频率 越高，波长越短，低频声响的波长则越长，所以更容易越过障碍物，能量衰减就小，声音传播的就远。反之则会得到相反的结论。

振幅：用不同的力度敲击物体，它的声音大小不一样，它的能量也不一样，声音越大振幅越高。

波形/音色： 音色就是在同样的频率（音调）和响度（振幅）下，敲击键盘或者撞击物体是完全不同的。波的形状代表了声音的音色。

如何进行声音进行保存呢？ 对声音的采样常用麦克风等设备将声音信号转换成电信号，再用模/数转换器将电信号转换成一串用1和0表示的二进制数字（数字信号）。每秒对声音采样上万次，获得上万个按照时间顺序排列的二进制数字，然后将连续变化不断的声音转化成了计算机可储存并识别的二进制数字。

为了将模拟信号数字化，需要进行：采样，量化，编码。

首先要对模拟信号进行采样，所谓采样就是在时间轴上对信号进行数字化。根据奈奎斯特定理（也称采样定理），按比声音最高频率高 2 倍以上的频率对声音进行采样，对于高质量的音频信号，其频率范围在 20Hz ~ 20kHz ，所以采样频率一般为 44.1kHz ,这样就保证采样声音达到 20kHz 也能被数字化，从而使得经过数字化处理之后，人耳听到的声音质量不会被降低。而所谓的 44.1 kHz 就是代表 1 s 会采样 44100 次。

每个采样又该如何表示呢？进行量化。量化是指在幅度轴上对信号进行数字化。量化位数越大，声音的质量越高。常用的量化位数有8位、16位和32位。量化位数指用几位二进制数来存储采样获得的数据。量化位数为8即指用8位二进制数来存储数据，如0001011

比如用 16 bit 的二进制信号来表示声音的一个采样，而 16 bit 所表示的范围是 [-32768 , 32767] , 共有 65536 个可能取值，因此最终模拟的音频信号在幅度上也分为了 65536 层。

编码，就是按照一定的格式记录采样和量化后的数字数据，比如顺序存储或压缩存储等等蠢凯。

这里涉及了很多种格式，通常所说的音频的裸数据就是 PCM (Pulse Code Molation) 数据。描述一段 PCM 数据一般需要以下几个概念：量化格式(sampleFormat)、采样率（sampleRate）、声道数 (channel) 。以 CD 的音质为例：量化格式为 16 bit （2 byte）,采样率 44100 ，带哗唤声道数为 2 ，这些信息就描述了 CD 的音质。而对于声音的格式，还有一个概念用来描述它的大小，称为数据比特率，即 1s 时间内的比特数目，它用于衡量音频数据单位时间内的容量大小。而对于 CD 音质的数据，比特率为多少呢？ 计算如下:

那么在一分钟里，这类 CD 音质的数据需要占据多大的存储空间呢？计算如下:

当然，如果 sampleFormat 更加精确 (比如用 4 个字节来描述一个采样)，或者 sampleRate 更加密集 (比如 48kHz 的采样率)， 那么所占的存储空间就会更大，同时能够描述的声音细节就会越精确。存储的这段二进制数据即表示将模拟信号转为数字信号了，以后就可以对这段二进制数据进行存储，播放，复制，或者进行其它操作。

关于这3个过程，可以看下这篇文章，图形表示采样，量化，编码的过程更容易理解。 https://www.bilibili.com/read/cv1771961/

所以说：

1）采样：在时间轴上对信号数字化；

2）量化：在幅度轴上对信号数字化；

3）编码：按一定格式记录采样和量化后的数字数据。

声道（sound channel）是指声音在录制或播放时在不同空间位置采集或回放的相互独立的音频信号，所以声道数也就是声音录制时的声音源数量或者回放时相应的扬声器数量。

常见的有：单声道，立体声道芦拆，4声道，5.1声道，7.1声道等。在移动端一般是单声道，立体声道。

上面提到了 CD 音质的数据采样格式，曾计算出每分钟需要的存储空间约为 10.09 MB ,如果仅仅是将其存储在光盘或者硬盘中，可能是可以接受的，但是若要在网络中实时在线传输的话，那么这个数据量可能就太大了，所以必须对其进行压缩编码。压缩编码的基本指标之一就是压缩比，压缩比通常小于 1 。压缩算法包括有损压缩和无损压缩。无损压缩是指解压后的数据可以完全复原。在常用的压缩格式中，用的较多的是有损压缩，有损压缩是指解压后的数据不能完全恢复，会丢失一部分信息，压缩比越小，丢失的信息就比越多，信号还原后的失真就会越大。根据不同的应用场景 (包括存储设备、传输网络环境、播放设备等)，可以选用不同的压缩编码算法，如 PCM 、WAV、AAC 、MP3 、Ogg 等。

WAV 编码就是在 PCM 数据格式的前面加了 44 个字节，分别用来存储 PCM 的采样率、声道数、数据格式等信息。

特点: 音质好，大量软件支持。

场景: 多媒体开发的中间文件、保存音乐和音效素材。

MP3 具有不错的压缩比，使用 LAME 编码 （MP3 编码格式的一种实现）的中高码率的 MP3 文件，听感上非常接近源 WAV 文件，当然在不同的应用场景下，应该调整合适的参数以达到最好的效果。

特点: 音质在 128 Kbit/s 以上表现还不错，压缩比比较高，大量软件和硬件都支持，兼容性好。

场景: 高比特率下对兼容性有要求的音乐欣赏。

AAC 是新一代的音频有损压缩技术，它通过一些附加的编码技术(比如 PS 、SBR) 等，衍生出了 LC-AAC 、HE-AAC 、HE-AAC v2 三种主要的编码格式。LC-AAC 是比较传统的 AAC ,相对而言，其主要应用于中高码率场景的编码 (>=80Kbit/s) ; HE-AAC 相当于 AAC + SBR 主要应用于中低码率的编码 （<= 80Kbit/s）; 而新推出的 HE-AAC v2 相当于 AAC + SBR + PS 主要用于低码率场景的编码 (<= 48Kbit/s) 。事实上大部分编码器都设置为 <= 48Kbit/s 自动启用 PS 技术，而 > 48Kbit/s 则不加 PS ，相当于普通的 HE-AAC。

特点: 在小于 128Kbit/s 的码率下表现优异，并且多用于视频中的音频编码。

场景: 128 Kbit/s 以下的音频编码，多用于视频中音频轨的编码。

Ogg 是一种非常有潜力的编码，在各种码率下都有比较优秀的表现，尤其是在中低码率场景下。Ogg 除了音质好之外，还是完全免费的，这为 Ogg 获得更多的支持打好了基础，Ogg 有着非常出色的算法，可以用更小的码率达到更好的音质，128 Kbit/s 的 Ogg 比 192kbit/s 甚至更高码率的 MP3 还要出色。但是目前因为还没有媒体服务软件的支持，因此基于 Ogg 的数字广播还无法实现。Ogg 目前受支持的情况还不够好，无论是软件上的还是硬件上的支持，都无法和 MP3 相提并论。

特点: 可以用比 MP3 更小的码率实现比 MP3 更好的音质，高中低码率下均有良好的表现，兼容性不够好，流媒体特性不支持。

场景: 语言聊天的音频消息场景。

压缩编码的原理实际上就是压缩调冗余信号，冗余信号是指哪些不能被人感知到的信号，包含人耳听觉范围之外的音频信号以及被屏蔽掉的音频信号等，这些冗余信息进行编码处理。

一般在音视频通话，直播中，短视频，以及大部分的视频都是用aac编码。

本篇主要是介绍了音频的一些基础知识和概念，对于后续学习音频的编解码有帮助，而不会一脸懵。

备注

㈡ android音视频开发怎么做

android音视频开发要想不费什么功夫的话，可以选择接入第三方的SDK，比如ZEGO即构科技，开发者可以调用ZEGO的API，4行代码30分钟就可以在应用内搭建出音视频场景，应用在视频会议、语音交友、秀场直播都可以

㈢ android音视频开发一安卓常用API

Android SDK 提供了两套音频采集的API，分别是：MediaRecorder 和 AudioRecord，前者是一个更加上层一点的API，它可以直接把手机麦克风录入的音频数据进行编码压缩（如AMR、MP3等）并存成文件，而后者则更接近底层，能够更加自由灵活地控制，可以得到原始的一帧帧PCM音频数据。如果想简单地做一个录音机，录制成音频文件，则推荐使用 MediaRecorder，而如果需要对音频做进一步的算法处理、或者采用第三方的编码库进行压缩、以及网络传输等应用，则建议使用 AudioRecord，其实 MediaRecorder 底层也是调用了 AudioRecord 与 Android Framework 层的 AudioFlinger 进行交互的。直播中实时采集音频自然是要用AudioRecord了。

2.1 播放声音可以用MediaPlayer和AudioTrack，两者都提供了Java API供应用开发者使用。虽然都可以播放声音，但两者还是有很大的区别的。

2.2 其中最大的区别是MediaPlayer可以播放多种格式的声音文件，例如MP3，AAC，WAV，OGG，MIDI等。MediaPlayer会在framework层创建对应的音频解码器。而AudioTrack只能播放已经解码的PCM流，如果对比支持的文件格式的话则是AudioTrack只支持wav格式的音频文件，因为wav格式的音频文件大部分都是PCM流。AudioTrack不创建解码器，所以只能播放不需要解码的wav文件。

2.3 MediaPlayer在framework层还是会创建AudioTrack，把解码后的PCM数流传递给AudioTrack，AudioTrack再传递给AudioFlinger进行混音，然后才传递给硬件播放,所以是MediaPlayer包含了AudioTrack。

2.4 在接触Android音频播放API的时候，发现SoundPool也可以用于播放音频。下面是三者的使用场景：MediaPlayer 更加适合在后台长时间播放本地音乐文件或者在线的流式资源; SoundPool 则适合播放比较短的音频片段，比如游戏声音、按键声、铃声片段等等，它可以同时播放多个音频; 而 AudioTrack 则更接近底层，提供了非常强大的控制能力，支持低延迟播放，适合流媒体和VoIP语音电话等场景。

使用 Camera API 采集视频数据并保存到文件，分别使用 SurfaceView、TextureView 来预览 Camera 数据，取到 NV21 的数据回调。

4.1 一个音视频文件是由音频和视频组成的，我们可以通过MediaExtractor、MediaMuxer把音频或视频给单独抽取出来，抽取出来的音频和视频能单独播放； 

4.2 MediaMuxer的作用是生成音频或视频文件；还可以把音频与视频混合成一个音视频文件。

文献资料  https://www.cnblogs.com/renhui/p/7452572.html

㈣ 安卓的英语android怎么读怎么发音

android
英音 [ 'ændrɔid ] ； 美音 [ 'ændrɔid ]
名词
1.机器人
2.Google开发的基于Linux平台的开源手机操作系统
同义词：humanoid，mechanical man。
例句：
Android and ios are well entrenched.
安卓和ios系统已经深入民心。
Android is facing more than forty lawsuits.
安卓正在面临超过40项的诉讼。
This android was laying down some licks with the Computer Robot Band.
这个仿真机器人正随着电脑机器人乐队的节拍轻轻舞动。

㈤ Android音视频系列（六）：PCM音频的存储格式

我们已经了解了如何使用AudioRecord录制pcm音频，所以我们要了解pcm数据的存储格式，才能对其进行链者转换。

首先看一下图片:

以上图为例，在初始化AudioRecord的时候可以设置录制的格式：

其中最常用的是ENCODING_PCM_16BIT，在网上查看一下很多的资料，ENCODING_PCM_8BIT已经处于半废弃状态，随着科技的樱竖进步，就连小孩子的玩具播放的音频都是16位的。

另外一个参数是声道数：

双声道会以LRLRLR的格式保存左右声道的内容，组合成一个完成的样本。

从上图我们可以总结：8个比特的位置，8位单声道可以存储8个样本，8位双声道能存储个样本，16位双声道能存储4个，16位双声道只能存储2个。

今天的内容非常的简单，主要是为了下一篇做准备，下一篇我们会实际操作：pcm单声道和双声道的转换。脊唤大

㈥ 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来实现软解，算是一个比较常规的音视频开发入门流程吧。

㈦ Android音视频(六) 使用OpenGL ES 3.0预览Camera

刚学习了OpenGL的纹理相关知识，终于可以接着写Android音视频系列了。

本篇博客会介绍使用OpenGL ES 3.0相关知识预览Camera，并且提供Camera和Camera2两个版本实现。

顶点着色器

片段着色器

纹理的类型需要使用 samplerExternalOES ，而不是之前渲染图片的 sampler2D。

我们知道Android相机输出的原始数据一般都为YUV数据，而在OpenGL中使用的绝大部分纹理ID都是RGBA的格式，所以原始数据都是无法直接用OpenGL ES来渲染的。所以我们添加了一个扩展 #extension GL_OES_EGL_image_external_essl3 : require ，其中定义了一个纹理的扩展类型 GL_TEXTURE_EXTERNAL_OES 。后面绑定纹理时需要绑定到 GL_TEXTURE_EXTERNAL_OES 上，而不是类型GL_TEXTURE_2D上。

其实前面部分和加载图片没有什么区别，最后两行，对应上面流程中的1、2步。创建纹理，绑定外部纹理，然后根据纹理ID创建SurfaceTexture作为相机预览输出。

使用Camera2在OpenGL方面其实是一样的，并没有什么改动。所以只需要看一下Camera2的调用就好。

源码地址