androidpcmaac

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

‘贰’ 移动端短语音消息音频格式选择

1. 移动端原生音频支持

1.1 android Supported media formats

https://developer.android.com/guide/topics/media/media-formats

Format / File Type(s) / Container Formats

AAC LC••Support for mono/stereo/5.0/5.1 content with standard sampling rates from 8 to 48 kHz.• 3GPP (.3gp)

• MPEG-4 (.mp4, .m4a)

• ADTS raw AAC (.aac, decode in Android 3.1+, encode in Android 4.0+, ADIF not supported)

• MPEG-TS (.ts, not seekable, Android 3.0+)

HE-AACv1 (AAC+)•

(Android 4.1+)

•

HE-AACv2 (enhanced AAC+)•Support for stereo/5.0/5.1 content with standard sampling rates from 8 to 48 kHz.

AAC ELD (enhanced low delay AAC)•

(Android 4.1+)

•

(Android 4.1+)

Support for mono/stereo content with standard sampling rates from 16 to 48 kHz

AMR-NB••4.75 to 12.2 kbps sampled @ 8kHz3GPP (.3gp)

AMR-WB••9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz3GPP (.3gp)

FLAC•

(Android 4.1+)

•

(Android 3.1+)

Mono/Stereo (no multichannel). Sample rates up to 48 kHz (but up to 44.1 kHz is recommended on devices with 44.1 kHz output, as the 48 to 44.1 kHz downsampler does not include a low-pass filter). 16-bit recommended; no dither applied for 24-bit.FLAC (.flac) only

MIDI•MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for ringtone formats RTTTL/RTX, OTA, and iMelody• Type 0 and 1 (.mid, .xmf, .mxmf)

• RTTTL/RTX (.rtttl, .rtx)

• OTA (.ota)

• iMelody (.imy)

MP3•Mono/Stereo 8-320Kbps constant (CBR) or variable bit-rate (VBR)MP3 (.mp3)

Opus•

(Android 5.0+)

Matroska (.mkv)

PCM/WAVE•

(Android 4.1+)

•8- and 16-bit linear PCM (rates up to limit of hardware). Sampling rates for raw PCM recordings at 8000, 16000 and 44100 Hz.WAVE (.wav)

Vorbis•• Ogg (.ogg)

• Matroska (.mkv, Android 4.0+)

1.2 Supported Audio File and Data Formats in OS X

https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/CoreAudioOverview/SupportedAudioFormatsMacOSX/SupportedAudioFormatsMacOSX.html

Allowable data formats for each file format.

File FormatData Formats

AAC (.aac, .adts)'aac '

AC3 (.ac3)'ac-3'

AIFC (.aif, .aiff,.aifc)BEI8, BEI16, BEI24, BEI32, BEF32, BEF64, 'ulaw', 'alaw', 'MAC3', 'MAC6', 'ima4' , 'QDMC', 'QDM2', 'Qclp', 'agsm'

AIFF (.aiff)BEI8, BEI16, BEI24, BEI32

Apple Core Audio Format (.caf)'.mp3', 'MAC3', 'MAC6', 'QDM2', 'QDMC', 'Qclp', 'Qclq', 'aac ', 'agsm', 'alac', 'alaw', 'drms', 'dvi ', 'ima4', 'lpc ', BEI8, BEI16, BEI24,BEI32, BEF32, BEF64, LEI16, LEI24, LEI32, LEF32, LEF64, 'ms\x00\x02', 'ms\x00\x11', 'ms\x001', 'ms\x00U', 'ms \x00', 'samr', 'ulaw'

MPEG Layer 3 (.mp3)'.mp3'

MPEG 4 Audio (.mp4)'aac '

MPEG 4 Audio (.m4a)'aac ', alac'

NeXT/Sun Audio (.snd, .au)BEI8, BEI16, BEI24, BEI32, BEF32, BEF64, 'ulaw'

Sound Designer II (.sd2)BEI8, BEI16, BEI24, BEI32

WAVE (.wav)LEUI8, LEI16, LEI24, LEI32, LEF32, LEF64, 'ulaw', 'alaw'

Core Audio includes a number of audio codecs that translate audio data to and from Linear PCM. Codecs for the following audio data type are available in OS X v10.4. Audio applications may install additional encoders and decoders.

Audio data typeEncode from linear PCM?Decode to linear PCM?

MPEG Layer 3 ('.mp3')NoYes

MACE 3:1 ('MAC3')YesYes

MACE 6:1 ('MAC6')YesYes

QDesign Music 2 ('QDM2')YesYes

QDesign ('QDMC')NoYes

Qualcomm PureVoice ('Qclp')YesYes

Qualcomm QCELP ('qclq')NoYes

AAC ('aac ')YesYes

Apple Lossless ('alac')YesYes

Apple GSM 10:1 ('agsm')NoYes

ALaw 2:1 'alaw')YesYes

Apple DRM Audio Decoder ('drms')NoYes

AC-3NoNo

DVI 4:1 ('dvi ')NoYes

Apple IMA 4:1 ('ima4')YesYes

LPC 23:1 ('lpc ')NoYes

Microsoft ADPCMNoYes

DVI ADPCMYesYes

GSM610NoYes

AMR Narrowband ('samr')YesYes

µLaw 2:1 ('ulaw')YesYes

1.3 总结:

android/ios都可以对mp3解码,但不能编码,编码依赖lame;

android/ios支持对aac进行编解码;

mp3,aac均是音乐编码器,android支持对amr窄带与宽带编解码,ios文档显示对窄带支持编解码,但有人说ios4.3.x版本之后不再支持AMR，剔除了AMR的硬解,如需使用依赖libopencore库;

结论:

h5 audio标签对mp3支持最好(audio标签除了firefox与opera都支持mp3,ogg,wav;flash播放器可以支持到mp3,aac,speex,nellymoser),考虑对纯web的兼容性,使用mp3;

android,ios硬件对aac支持最好,考虑硬编码的性能与效率,使用aac;

amr是语音编码器,考虑使用场景,推荐amr.

对比微信,微信短语音,6.0之前用的amr,6.0之后用的silk_v3.

2.音频基础概念

2.1声音三要素

声音的特性可由三个要素来描述，即响度、音调和音色。

响度：人耳对声音强弱的主观感觉称为响度。响度和声波振动的幅度有关。一般说来，声波振动幅度越大则响度也越大。当我们用较大的力量敲鼓时，鼓膜振动的幅度大，发出的声音响；轻轻敲鼓时，鼓膜振动的幅度小，发出的声音弱。音叉振动时发出的声波为单音，即只有一个频率成分。若设法将音叉的振动规律记录下来，可发现其振动波形为一正弦波。当用不同力量敲击某个音叉时，音叉发出的声波幅度不同，这意味着声音的响度不同。给出了两个声音波形，其幅度一大一小，幅度大的波形其声音响度大，幅度小的波形其声音响度小。另外，人们对响度的感觉还和声波的频率有关，同样强度的声波，如果其频率不同，人耳感觉到的响度也不同。

音调：人耳对声音高低的感觉称为音调。音调主要与声波的频率有关。声波的频率高，则音调也高。当我们分别敲击一个小鼓和一个大鼓时，会感觉它们所发出的声音不同。小鼓被敲击后振动频率快，发出的声音比较清脆，即音调较高；而大鼓被敲击后振动频率较慢，发出的声音比较低沉，即音调较低。如果分别敲击一个小音叉和一个大音叉时，同样会感觉到小音叉所发声音的音调较高，大音叉所发声音音调较低。如果设法把大、小音叉所发出的声波记录下来，可发现小音叉在单位时间内振动的次数多，即频率高，大音叉在单位时间内振动的次数少，即频率低。给出了两个频率不同的声音波形，从声音可听出，频率高的声音波形听起来音调较高，而频率低的声音波形听起来则音调较低。

音色：音色是人们区别具有同样响度、同样音调的两个声音之所以不同的特性，或者说是人耳对各种频率、各种强度的声波的综合反应。音色与声波的振动波形有关，或者说与声音的频谱结构有关。前面说过，音叉可产生一个单一频率的声波，其波形为正弦波。但实际上人们在自然界中听到的绝大部分声音都具有非常复杂的波形，这些波形由基波和多种谐波构成。谐波的多少和强弱构成了不同的音色。各种发声物体在发出同一音调声音时，其基波成分相同。但由于谐波的多少不同，并且各次谐波的幅度各异，因而产生了不同的音色。例如当我们听胡琴和扬琴等乐器同奏一个曲子时，虽然它们的音调相同，但我们却能把不同乐器的声音区别开来。这是因为，各种乐器的发音材料和结构不同，它们发出同一个音调的声音时，虽然基波相同，但谐波构成不同，因此产生的波形不同，从而造成音色不同。给出了小提琴和钢琴的波形和声音，这两个声音的响度和音调都是相同的，但听起来却不一样，这就是因为这两个声音的音色不同（波形不同）。

2.2采样率和采样大小

声音其实是一种能量波，因此也有频率和振幅的特征，频率对应于时间轴线，振幅对应于电平轴线。波是无限光滑的，弦线可以看成由无数点组成，由于存储空间是相对有限的，数字编码过程中，必须对弦线的点进行采样。采样的过程就是抽取某点的频率值，很显然，在一秒中内抽取的点越多，获取得频率信息更丰富，**为了复原波形，一次振动中，必须有2个点的采样**，人耳能够感觉到的最高频率为20kHz，因此要满足人耳的听觉要求，则需要至少每秒进行40k次采样，用40kHz表达，这个40kHz就是采样率。我们常见的CD，采样率为44.1kHz。光有频率信息是不够的，我们还必须获得该频率的能量值并量化，用于表示信号强度。量化电平数为2的整数次幂，我们常见的CD位16bit的采样大小，即2的16次方。采样大小相对采样率更难理解，因为要显得抽象点，举个简单例子：假设对一个波进行8次采样，采样点分别对应的能量值分别为A1-A8，但我们只使用2bit的采样大小，结果我们只能保留A1-A8中4个点的值而舍弃另外4个。如果我们进行3bit的采样大小，则刚好记录下8个点的所有信息。采样率和采样大小的值越大，记录的波形更接近原始信号。

2.3有损和无损

根据采样率和采样大小可以得知，相对自然界的信号，音频编码最多只能做到无限接近，至少目前的技术只能这样了，相对自然界的信号，任何数字音频编码方案都是有损的，因为无法完全还原。在计算机应用中，能够达到最高保真水平的就是PCM编码，被广泛用于素材保存及音乐欣赏，CD、DVD以及我们常见的WAV文件中均有应用。因此，PCM约定俗成了无损编码，因为PCM代表了数字音频中最佳的保真水准，并不意味着PCM就能够确保信号绝对保真，PCM也只能做到最大程度的无限接近。我们而习惯性的把MP3列入有损音频编码范畴，是相对PCM编码的。强调编码的相对性的有损和无损，是为了告诉大家，要做到真正的无损是困难的，就像用数字去表达圆周率，不管精度多高，也只是无限接近，而不是真正等于圆周率的值。

2.4频率与采样率的关系

采样率表示了每秒对原始信号采样的次数，我们常见到的音频文件采样率多为44.1KHz，这意味着什么呢？假设我们有2段正弦波信号，分别为20Hz和20KHz，长度均为一秒钟，以对应我们能听到的最低频和最高频，分别对这两段信号进行40KHz的采样，我们可以得到一个什么样的结果呢？结果是：20Hz的信号每次振动被采样了40K/20=2000次，而20K的信号每次振动只有2次采样。显然，在相同的采样率下，记录低频的信息远比高频的详细。这也是为什么有些音响发烧友指责CD有数码声不够真实的原因，CD的44.1KHz采样也无法保证高频信号被较好记录。要较好的记录高频信号，看来需要更高的采样率，于是有些朋友在捕捉CD音轨的时候使用48KHz的采样率，这是不可取的！这其实对音质没有任何好处，对抓轨软件来说，保持和CD提供的44.1KHz一样的采样率才是最佳音质的保证之一，而不是去提高它。较高的采样率只有相对模拟信号的时候才有用，如果被采样的信号是数字的，请不要去尝试提高采样率。

亨利·奈奎斯特(Harry Nyquist)采样定理:当对连续变化的信号波形进行采样时,若采样率fs高于该信号所含最高频率的两倍,那么可以由采样值通过插补技术正确的回复原信号中的波形,否则将会引起频谱混叠(Aliasing),产生混叠噪音(Aliasing Noise),而重叠的部分是不能恢复的.(同样适用于模拟视频信号的采样)

根据人声语音的特点,人类的听力感知范围是从20Hz到20kHz。这个频宽范围被划分成四个频宽类别：窄带、宽带、超宽带和全带。

窄带（narrowband）普通电话所覆盖的频宽，从300Hz到3.4kHz，对应采样率6.8kHz。普通电话的采样率是8kHz，对应频宽4kHz，对于人声语音是足够的。

宽带（wideband）从50Hz到7kH的频宽，对应采样率14khz，可以很好地捕捉和还原人声，然而对于音乐声还是不够的。这是在人声语音通话场景下的所谓高清语音。

超宽带（super-wideband）从50Hz到14kHz，对应采样率28kHz，基本可以覆盖人声和音乐声，对于非专业音乐人的用户来说，不管是人声通话还是音乐直播，这样的频宽都是足够的。

全带（fullband）从20Hz到20kHz，对应40kHz采样率，全面覆盖人类的听觉范围，能够满足音乐发烧友或者专业音乐人的需求。超过40Hz都可以称作全带语音。CD的采样率就是44.1kHz。

因此，窄带(narrowband)的音质是能满足人声录制回放的。

从四个角度衡量音频编码:

成本:开发成本,服务器流量成本

音质:

系统影响:对系统资源的暂用,软编解码器比硬编解码器占用更多cpu

兼容性:对移动端以及web端的兼容

适合产品场景的编码器具备以下四个特点

码率相对低，满足成本可控的要求，一般不要超过16kbps。一个sample用1bit就能编好，那么8kHz采样率（narrowband）对应8kbps的码率，16kHz采样率（wideband）对应16kbps的码率。码率的本质就是成本。

算法复杂度要比较低，对系统CPU、内存和电量消耗少，对系统影响要尽量低。

音质可以适当作出牺牲，以保障上面三个因素，8kHz采样率对人声场景是够用的，16kHz采样率可以提供高清语音。

兼顾兼容性

3.主流音频编码器

音频编码格式的比较: https://zh.wikipedia.org/wiki/%E9%9F%B3%E9%A2%91%E7%BC%96%E7%A0%81%E6%A0%BC%E5%BC%8F%E7%9A%84%E6%AF%94%E8%BE%83

下图列举一组主流的音频编解码器，展示了随着码率变化，音质相应变化的情况。这是基于编解码器听音测试的结果绘画出来的，对选取音频编解码器有参考意义。根据上面的分析并且参照下图，发现码率低于16kbps的低码率人声编解码器（speech codecs）包含：Opus（SILK）,Speex，AMR-NB，AMR-WB，和iLBC。

下图是另外一组主流的音频编解码器，展示了随着码率的变化，算法延迟时间相应变化的情况。根据上面的分析并且参照下图，发现算法延迟时间低于60毫秒，码率低于16kbps的人声编解码器（speech codecs）包含：Opus（SILK）、Speex(NB,WB)、G.729、和G.729.1。

从图中我们可以获得如下几方面信息：

对于固定码率的编码标准：如G.711或者G.722，图中采用单点表示，说明这两个编码标准是固定码率编码标准。其他如Opus、Speex，它们的曲线是连续的，说明这类编码标准是可变码率的编码标准。

从频带方面看：G.711、G.722、AMR和iLBC等标准适用于narrowband（8khz采样率）和wideband（16khz采样率）范围，针对普通的语音通话场景。AAC和MP3适用于fullband（48khz采样率）范围，针对特殊的音乐场景。而Opus适用于整个频带，可以进行最大范围的动态调节，适用范围最广。

从标准的收费情况看：适用于互联网传输的iLBC、Speex和Opus都是免费且开源的；适用于音乐场景的MP3和AAC，需要license授权，而且不开源。

综合上面的两个图，我们可以大致总结，比较适合人声短语音的音频编解码器包含Opus（SILK）、Speex（NB,WB）、AMR-NB、AMR-WB、iLBC、G.729、和G.729.1。

码率采样率算法延迟

OPUS(SILK)6-12,7-25，

8-30,12-40kbps

8，12，

16，24kHz

25ms

Speex2.15–24.6 kbps (NB)

4–44.2 kbps (WB)

8, 16,

32, 48kHz

30 ms(NB)

34 ms (WB)

AMR-NB4.75, 5.15, 5.90,

6.70, 7.40, 7.95,

10.20, 12.20 kbps

8kHz25ms (20ms per frame

plus 5ms look-ahead,

20ms for 12.2 kbps)

AMR-WB6.60, 8.85, 12.65,14.25, 15.85, 18.25, 19.85, 23.05, 23.85 kbps16kHz25ms (20ms per frame

plus 5ms look-ahead)

iLBC13.33 kbps

15.20 kbps

8kHz25 ms

40 ms

G.7298kbps8kHz15 ms

G.729.18 kbps,

12–32 kbps

8kHz

16kHz

48.94ms

Codec20.7, 1.2, 1.3, 1.4,

1.6, 2.4, 3.2 kbps

8kHz20–40 ms

（额外增加的，超低码率）

短语音不同于实时语音,可以忽略延迟

上面都是为人声场景设计的低码率音频编解码器，具有码率低（16kbps以下），算法延迟低（大部分在40ms以下），和采样率在8kHz和16kHz之间的特点，都可供短语音编码方案选择。其中，有几个语音编解码器值得在这里稍作介绍：

Opus（SILK）

https://en.wikipedia.org/wiki/Opus_(audio_format)

完全开源而且免费，包含了SILK、CELT、以及两者的混合模式，是目前最为兼容并包的音频编解码器。在处理窄带和宽带人声语音（speech）的时候，采用SILK; 在处理超宽带和全带音乐声音（music）的时候，采用CELT。在人声和音乐声混合的场景中，甚至可以智能切换两个编解码器。WebRTC就采用了Opus作为语音编解码器。而SILK是Skype网络电话所用的语音编解码器。Opus真可谓是久经考验的名门精品。根据即构科技的测试结果，Opus虽然在音乐场景中表现并非首选，但是在人声场景中表现十分出色。

iLBC

完全开源而且免费的，由GIPS开发并被IETF标准化，曾经被QQ和Skype使用过，现在被WebRTC使用，是被世界顶级产品证明过的窄带实时语音编解码器。iLBC能够通过平滑降低语音质量的方式来处理IP网络丢包。由于iLBC的语音帧块之间是相互独立的，在丢帧出现的时候也不会导致错误蔓延，因此具有较强的抗丢包能力。在窄带应用环境中，iLBC具有延迟低，无断续或杂音的特点，通话效果可以和移动电话媲美。

Speex

免费的人声音频编解码器。因为Speex是为VoIP专门设计的，所以Speex对IP网络有很强的抗丢包能力。为了达到这个目的，Speex采用了CELP算法。市场上狼人杀产品的游戏实时语音技术，厂商自研的方案采用了Speex。

Codec2

开源并且专利免费，码率超低的人声语音编解码器。码率在0.7 kbps至3.2 kbps。Codec2填补了开源编码器在5 kbps码率以下的空白。

评估音频编码指标,除码率、采样率、和算法延迟以外，还要参考MOS、VBR/CBR、和基础算法等。其中，MOS （Mean Opinion Score）是语音编解码器的主观评估指标。MOS是一个广为接受的有统计意义的主观听音指标。上面音视频编解码器的列表没有把它包含进去，是因为同一个编解码器，在不同码率下，表现出来的MOS值是会变化的。对一个音频编解码器给出一个固定的MOS值，反而会起误导的作用。另外，虽然MOS值已经是主观的听觉测试评估结果，但是音频工程师在选用音频编解码器的时候，还要以自己亲身的听感作为最终的依据。

下图是Nokia在2011年的时候对Opus、AMR、和G.722.1C等音频编解码器在无噪音和有噪音的环境里做的MOS语音测试的结果。我们可以从语音测试的结果看出：

1）MOS值会随着码率变化。固定的MOS值并没有绝对的参考意义。

2）在低码率情况下，AMR-NB和AMR-WB都表现相对出色。

参考:

1.Getting Started with Audio & Video: https://developer.apple.com/library/content/referencelibrary/GettingStarted/GS_MusicAudio/_index.html

2.Opus ios: https://github.com/chrisballinger/Opus-iOS

3.android opus: https://gitlab.com/axet/android-opus

4.opus_android: https://github.com/louisyonge/opus_android

5.opuscodec: https://github.com/martoreto/opuscodec

6.与大家讨论如何用opencore amr在iOS上decode: https://blog.csdn.net/devday/article/details/6804553

7. ios支持 https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioEssentials/CoreAudioEssentials.html#//apple_ref/doc/uid/TP40003577-CH10-SW13

‘叁’ android中播放音频有哪几种方式

哪几种格式吧？音频格式：MP1，MP2，MP3，OGG，FLAC（8,16,24,32位），WMA，AC3，AAC，M4A，M4B，M4R，MP4，3GP，3G2，MOV，APE（猴子的音频）ALAC，西弗吉尼亚州（WavPack），MPC（MusePack），WAV（PCM {8,16,24,32-位乐}，ima4，MS -ADPCM，U -法律，法律），AU（PCM {8， 16,24,32,64位}，U -法律，法），MPEG（音频），AVI（音频），

‘肆’ 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音频开发：音频相关知识

现在是数字时代，在音频处理时要先把音频的模拟信号变成数字信号，这叫A/D转换。要把音频的模拟信号变成数字信号，就需要采样。一秒钟内采样的次数称为采样频率

数字信号是用0和1来表示的。采样位数就是采样值用多少位0和1来表示，也叫采样精度，用的位数越多就越接近真实声音。如用8位表示，采样值取值范围就是-128 ~ 127，如用16位表示，采样值取值范围就是-32768 ~ 32767

通常语音只用一个声道。而对于音乐来说，既可以是单声道（mono），也可以是双声道（即左声道右声道，叫立体声stereo），还可以是多声道，叫环绕立体声。

通常把音频采样过程也叫做脉冲编码调制编码，即PCM（Pulse Code Molation）编码，采样值也叫PCM值。 如果把采样值直接保存或者发送，会占用很大的存储空间。以16kHz采样率16位采样位数单声道为例，一秒钟就有16/8*16000 = 32000字节。为了节省保存空间或者发送流量，会对PCM值压缩。
目前主要有三大技术标准组织制定压缩标准：

对于自然界中的音频信号，如果转换成数字信号，进行音频编码，那么只能无限接近，不可能百分百还原。所以说实际上任何信号转换成数字信号都会“有损”。但是在计算机应用中，能够达到最高保真水平的就是PCM编码。因此，PCM约定俗成了无损编码
。我们而习惯性的把MP3列入有损音频编码范畴，是相对PCM编码的。强调编码的相对性的有损和无损

码率 = 采样频率 * 采样位数 * 声道个数； 例：采样频率44.1KHz，量化位数16bit，立体声(双声道)，未压缩时的码率 = 44.1KHz * 16 * 2 = 1411.2Kbps = 176.4KBps，即每秒要录制的资源大小,理论上码率和质量成正比

1.WAV 格式：音质高 无损格式 体积较大
2.AAC（Advanced Audio Coding） 格式：相对于 mp3，AAC 格式的音质更佳，文件更小，有损压缩，一般苹果或者Android SDK4.1.2（API 16）及以上版本支持播放,性价比高
3.AMR 格式：压缩比比较大，但相对其他的压缩格式质量比较差，多用于人声，通话录音

4.mp3 格式：特点 使用广泛， 有损压缩，牺牲了12KHz到16KHz高音频的音质

延时敏感、卡顿敏感、噪声抑制（Denoise）、回声消除（AEC）、静音检测（VAD）、混音算法，等等。

参考：
Android音频开发（1）：音频基础知识

‘陆’ 怎样用AACLib V1.0在Android上音频编码解码

这几天在 android上的音频项目，顺便把用到的aac编解码库封装了一下，有需要的可以从上面下载。当然是没有本事自己写编解码器的，还是用FFmpeg + FDK_aac来做。下面介绍一下其java接口的使用。java库见libaac.jar文件，把libaac.jar加到 libs目录下，把libaac.so加到 libs/armeabi目录即可使用。

AAC编码：
(1) 创建一个Encoder对象作为成员变量
aac.Encoder encoder;

(2) 初始化它

encoder = new aac.Encoder();
if(! encoder.open(11025, 1))
{
Log.d("mylog", "failed to open encoder !\n");
encoder = null;
}

这里要指定输入音频源(PCM格式）的sampe_rate和channel个数，如果为CHANNEL_OUT_MONO，则channel=1，否则为2。 sample_rate一般设置为11025，因为手机性能有限，设置太高的话也处理不过来，而且处理人声的话11025也是足够了。


(3) 编码

把接收到PCM数据交给encoder来处理即可，要求输入源为ENCODING_PCM_16BIT，即每个sample是16BIT的。这个encoder对象内有2个缓冲区：inbuf, outbuf。显然，在编码时，inbuf就是用于存储接收到的PCM数据，outbuf就是存编码后得到的数据。

int out_size = encoder.encode(in_size);
其返回值out_size，表示在outbuf里的有效数据长度。此时可以把outbuf里的aac数据通过网络发送或其他用途。

其中，用户需要知道encoder每次处理多长的数据，即一个frame的大小。对于单声道MONO来说，每次应该输入2048byte的数据。对于双声道STEREO来说，应该输入4096byte的数据。下面这一行可以根据声道数来计算输入的frame的大小:

int in_size = aac.Encoder.frameSize(1);

AAC解码：
(1) 创建一个Decoder对象作为成员变量

aac.Decoder decoder;

(2) 初始化

decoder = new aac.Decoder();
if( ! decoder.open())
{
Log.d("mylog", "failed to open decoder !\n");
decoder = null;
}

(3) 解码
Decoder对象也有inbuf和outbuf，把待解码的aac frame放到inbuf里

int pcm_size = decoder.decode(aac_size);

解得到数据在outbuf里，其有效长度为上述函数的返回值pcm_size，此时可以把outbuf里的PCM数据取出来播放或其他用途。

‘柒’ android如何使用fdk-aac编码库来把aac转成pcm

线性PCM就是WAV。
AAC-LC是AAC的一个规格，你下载到或者转换的这些高码率的AAC都是AAC-LC的。
扩展名是.m4a。

.aac 是aac的音频数据流，m4a是aac的一个封装方式。其内容本身是一样的。
我用s754，和e453功能是一样的。m4a和wav的我都放了，没问题，只是.aac的我还没试过。
但我相信lz没有.aac的。。因为这年头你下载到的或者转换出来的都是m4a的

‘捌’ 小米5c参数

‘玖’ Android音频开发（三）——音频编解码

上一节中我们讲了怎么采集音频并播放，由于AudioRecord采集的是PCM数据，没有经过处理，所有播放的时候会有杂音，啸叫等现象出现。因此处理掉这些不需要的数据就是本节的内容，编码与解码。

Android官方提供给我们的用于编解码的类是 MediaCodec ,它是android 4.1（API 16）才引入的，所以只能工作于andorid4.1以上的手机，如果想兼容4.1以下版本的手机，只能使用第三方库，如大名鼎鼎的 ffmpeg ,B站的 ijkplayer 等。

（1）提供了一套访问 Android 底层多媒体模块的接口，主要是音视频的编解码接口

（2）在Android上，预设的多媒体框架是基于第三方PacketVideo公司的OpenCORE来实现，OpenCORE的优点是兼顾了跨平台的移植性，而且已经过多方验证，所以相对来说较为稳定；缺点是国语庞大复杂，需要耗费相当多的时间去维护。因此从Android 2.0开始，Google引进了较为简洁的StageFright。Android 底层多媒体模块采用的是 StageFright 框架，它是基于OpenMax标准实现的，任何 Android 底层编解码模块的实现，都必须遵循 OpenMax 标准。值得一提的是，OpenMAX是Khronos制定的API，Khronos也是OpenGL的制定者。Google 官方默认提供了一系列的软件编解码器：包括：OMX.google.h264.encoder，OMX.google.h264.encoder， OMX.google.aac.encoder， OMX.google.aac.decoder 等等，而硬件编解码功能，则需要由芯片厂商依照 OpenMax 框架标准来完成，所以，一般采用不同芯片型号的手机，硬件编解码的实现和性能是不同的

（3）Android 应用层统一由 MediaCodec API 来提供各种音视频编解码功能，由参数配置来决定采用何种编解码算法、是否采用硬件编解码加速等等

根据android官方文档的描述，MediaCodec的核心就是使用缓冲区队列来操作数据，使用流程如下：

//name既是媒体文件的类型，如audio/3gpp，详情参考MediaFormat的MIMETYPE常量
MediaCodec codec = MediaCodec.createByCodecName(name);
codec.configure(format, …);
MediaFormat outputFormat = codec.getOutputFormat(); // option B
codec.start();
for (;;) {
////获取可用的inputBuffer -1代表一直等待，0表示不等待 建议-1,避免丢帧
int inputBufferId = codec.dequeueInputBuffer(-1);
if (inputBufferId >= 0) {
ByteBuffer inputBuffer = codec.getInputBuffer(…);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
//执行上面的操作后就把待编解码的数据存入了输入缓冲区，然后下一步就是操作然后把编解码的数据存入输出缓冲区
int outputBufferId = codec.dequeueOutputBuffer(…);
if (outputBufferId >= 0) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is identical to outputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
outputFormat = codec.getOutputFormat(); // option B
}
}
codec.stop();
codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);
MediaFormat mOutputFormat; // member variable
codec.setCallback(new MediaCodec.Callback() {
@Override
void onInputBufferAvailable(MediaCodec mc, int inputBufferId) {
ByteBuffer inputBuffer = codec.getInputBuffer(inputBufferId);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}

@Override
void onOutputBufferAvailable(MediaCodec mc, int outputBufferId, …) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is equivalent to mOutputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
}

@Override
void onOutputFormatChanged(MediaCodec mc, MediaFormat format) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
mOutputFormat = format; // option B
}

@Override
void onError(…) {
…
}
});
codec.configure(format, …);
mOutputFormat = codec.getOutputFormat(); // option B
codec.start();
// wait for processing to complete
codec.stop();
codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);
codec.configure(format, …);
codec.start();
//API的区别在这里
ByteBuffer[] inputBuffers = codec.getInputBuffers();
ByteBuffer[] outputBuffers = codec.getOutputBuffers();
for (;;) {
int inputBufferId = codec.dequeueInputBuffer(…);
if (inputBufferId >= 0) {
// fill inputBuffers[inputBufferId] with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
int outputBufferId = codec.dequeueOutputBuffer(…);
if (outputBufferId >= 0) {
// outputBuffers[outputBufferId] is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) {
outputBuffers = codec.getOutputBuffers();
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
// Subsequent data will conform to new format.
MediaFormat format = codec.getOutputFormat();
}
}
codec.stop();
codec.release();