音频的基础知识
1采样和采样频率：
现在是数字时代，在音频处理时要先把音频的模拟信号变成数字信号，这叫A/D转换。要把音频的模拟信号变成数字信号，就需要采样。一秒钟内采样的次数称为采样频率
2采样位数/位宽：
数字信号是用0和1来表示的。采样位数就是采样值用多少位0和1来表示，也叫采样精度，用的位数越多就越接近真实声音。如用8位表示，采样值取值范围就是-128 ~ 127，如用16位表示，采样值取值范围就是-32768 ~ 32767。
3声道（channel）：
通常语音只用一个声道。而对于音乐来说，既可以是单声道（mono），也可以是双声道（即左声道右声道，叫立体声stereo），还可以是多声道，叫环绕立体声
4编解码：
通常把音频采样过程也叫做脉冲编码调制编码，即PCM（Pulse Code Modulation）编码，采样值也叫PCM值。 如果把采样值直接保存或者发送，会占用很大的存储空间。以16kHz采样率16位采样位数单声道为例，一秒钟就有16/8*16000 = 32000字节。为了节省保存空间或者发送流量，会对PCM值压缩。
目前主要有三大技术标准组织制定压缩标准：
1.ITU，主要制定有线语音的压缩标准（g系列），有g711/g722/g726/g729等。
2.3GPP,主要制定无线语音的压缩标准（amr系列等）,有amr-nb/amr-wb。后来ITU吸纳了amr-wb，形成了g722.2。
3.MPEG,主要制定音乐的压缩标准，有11172-3，13818-3/7，14496-3等。
一些大公司或者组织也制定压缩标准，比如iLBC，OPUS。
编码过程：模拟信号->抽样->量化->编码->数字信号
5压缩:
对于自然界中的音频信号，如果转换成数字信号，进行音频编码，那么只能无限接近，不可能百分百还原。所以说实际上任何信号转换成数字信号都会“有损”。但是在计算机应用中，能够达到最高保真水平的就是PCM编码。因此，PCM约定俗成了无损编码。我们而习惯性的把MP3列入有损音频编码范畴，是相对PCM编码的。强调编码的相对性的有损和无损
6码率:
码率 = 采样频率 * 采样位数 * 声道个数； 例：采样频率44.1KHz，量化位数16bit，立体声(双声道)，未压缩时的码率 = 44.1KHz * 16 * 2 = 1411.2Kbps = 176.4KBps，即每秒要录制的资源大小,理论上码率和质量成正比
800 bps – 能够分辨的语音所需最低码率（需使用专用的FS-1015语音编解码器）
8 kbps —电话质量（使用语音编码）
8-500 kbps --Ogg Vorbis和MPEG1 Player1/2/3中使用的有损音频模式
500 kbps–1.4 Mbps —44.1KHz的无损音频，解码器为FLAC Audio,WavPack或Monkey's Audio
1411.2 - 2822.4 Kbps —脉冲编码调制(PCM)声音格式CD光碟的数字音频
5644.8 kbps —SACD使用的Direct Stream Digital格式
7常用音频格式
WAV 格式：音质高 无损格式 体积较大
AAC（Advanced Audio Coding） 格式：相对于 mp3，AAC 格式的音质更佳，文件更小，有损压缩，一般苹果或者Android SDK4.1.2（API 16）及以上版本支持播放,性价比高
AMR 格式：压缩比比较大，但相对其他的压缩格式质量比较差，多用于人声，通话录音
mp3 格式：特点 使用广泛， 有损压缩，牺牲了12KHz到16KHz高音频的音质
8音频开发的主要应用
音频播放器
录音机
语音电话
音视频监控应用
音视频直播应用
音频编辑/处理软件(ktv音效、变声, 铃声转换)
蓝牙耳机/音箱
9音频开发的具体内容
音频采集/播放
音频算法处理（去噪、静音检测、回声消除、音效处理、功放/增强、混音/分离，等等）
音频的编解码和格式转换
音频传输协议的开发（SIP，A2DP、AVRCP，等等）
视频基础知识
视频是一种有结构的数据
内容元素 ( Content )
图像 ( Image )
音频 ( Audio )
元信息 ( Metadata )
编码格式 ( Codec )
Video : H.264，H.265, …
Audio : AAC， HE-AAC, …
容器封装 (Container)
MP4，MOV，FLV，RM，RMVB，AVI，…
任何一个视频 Video 文件，从结构上讲，都是这样一种组成方式：
由图像和音频构成最基本的内容元素；
图像经过视频编码压缩格式处理（通常是 H.264）；
音频经过音频编码压缩格式处理（例如 AAC）；
注明相应的元信息（Metadata）；
最后经过一遍容器（Container）封装打包（例如 MP4），构成一个完整的视频文件。
视频播放流程
色彩空间
RBG:采用R、G、B相加混色的原理，通过发射出三种不同强度的电子束，使屏幕内侧覆盖的红、绿、蓝磷光材料发光而产生色彩。这种色彩的表示方法称为RGB色彩空间表示.
编解码介绍
视频编码的主要作用是将视频像素数据（RGB等）压缩成为视频码流，从而降低视频的数据量。如果视频不经过压缩编码的话，体积通常是非常大的，一部电影可能就要上百G的空间。视频编码是视音频技术中最重要的技术之一。视频码流的数据量占了视音频总数据量的绝大部分。高效率的视频编码在同等的码率下，可以获得更高的视频质量。
举个直播上的栗子：我们知道从 CCD 采集到的图像格式一般的 RGB 格式的（BMP），这种格式的存储空间非常大，它是用三个字节描述一个像素的颜色值，如果是 1080P 分辨率的图像空间：1920 x 1080 x 3 = 6MB，就算转换成 JPG 也有近 200KB，如果是每秒 12 帧用 JPG 也需要近 2.4MB/S 的带宽，这带宽在公网上传输是无法接受的。
视频编码器就是为了解决这个问题的，它会根据前后图像的变化做运动检测，通过各种压缩把变化的发送到对方，1080P 进行过 H.264 编码后带宽也就在 200KB/S ~ 300KB/S 左右。
我们平时所看到的视频，理论上就是一帧帧的图片连续的播放，形成动画效果。那么完整的保存所有图片，所占用的空间是非常巨大的。视频编码就是为了压缩这些图片，以节省空间。我先讲一下简单的理论，比如一秒钟的视频通常有24帧，这24张图画大部分区域可能都比较相近，那么我们是不是可以找到一种方法，只保存一张完整图片（我们称为关键帧），不保存其他图片，只保存和这个完整图片的不同（通过某种数学建模表达），这样就会节省很多空间，在播放的时候，通过和关键帧与每一帧的不同逆向恢复成一张完整的图片，这样就得到了24张完整的图片。（这里只是举例，实际应用中并不一定是每24帧图像被设定一个关键帧）。OK，那么所谓编码格式就指的一种压缩视频图像的算法。
H.264编码介绍
H.264是新一代的编码标准，以高压缩高质量和支持多种网络的流媒体传输著称，在编码方面，它的理论依据是：一段时间内图像的统计结果表明，在相邻几幅图像画面中，一般有差别的像素只有10%以内的点，亮度差值变化不超过2%，而色度差值的变化只有1%以内。所以对于一段变化不大的图像画面，我们可以先编码出一个完整的图像帧A，随后的B帧不编码全部图像，只写入与A帧的差别，这样B帧的大小就只有完整帧的1/10或更小！B帧之后的C帧如果变化不大，我们可以继续以参考B的方式编码C帧，这样循环下去。这段图像我们称为一个序列，当某个图像与之前的图像变化很大，无法参考前面的帧来生成，那我们就结束上一个序列，开始下一段序列。
I 帧是内部编码帧（也称为关键帧），P 帧是前向预测帧（前向参考帧），B 帧是双向内插帧（双向参考帧）。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。
视频的实时传输(直播)
视频直播技术，就是将视频内容的最小颗粒 ( I / P / B 帧，…)，基于时间序列，以高速进行传送的一种技术。
简而言之，直播就是将每一帧数据 ( Video / Audio / Data Frame )，打上时序标签 ( Timestamp ) 后进行流式传输的过程。发送端源源不断的采集音视频数据，经过编码、封包、推流，再经过中继分发网络进行扩散传播，播放端再源源不断地下载数据并按时序进行解码播放。如此就实现了 “边生产、边传输、边消费” 的直播过程。
流媒体协议
RTSP协议
该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
RTMP协议
RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据实时传输开发的开放协议，因为是开放协议所以都可以使用。
RTMP协议用于对象、视频、音频的传输，这个协议建立在TCP协议或者轮询HTTP协议之上。
RTMP协议就像一个用来装数据包的容器，这些数据可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
HLS协议
HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现基于HTTP的流媒体传输协议，传输内容包括两部分，一是M3U8描述文件，二是TS媒体文件。可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。
相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
协议间的比较:
FFmpeg
FFmpeg的名称来自MPEG视频编码标准，前面的“FF”代表“Fast Forward”，FFmpeg是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。可以轻易地实现多种视频格式之间的相互转换。
FFmpeg函数库介绍
libavutil：简化编程的工具函数库，包括随机数生成器，数据结构，数学函数，多媒体核心工具函数等等。
libavcodec：包含音视频编解码的库。
libavformat：包含复用，解复用(封装格式处理)多媒体容器的库。
libavdevice：包含输入/输出设备的库，它能从一些通用的软件框架中抓取数据，也能将多媒体数据送到一些通用软件框架中去渲染。这些通用软件框架包括：Video4Linux，Video4Linux2,VfW以及ALSA等。
libavfilter：滤镜特效处理。
libswscale：用于执行高性能的图像缩放，颜色空间或像素格式转换的库。
libswresample：用于执行高性能音频重采样，重矩阵化（rematrixing，不确定翻译是否准确），采样格式转换以及混音（主要是声道转换（如5.1声道转到立体声等））等功能的库。
实现直播整体流程
推流端（采集、美颜处理、编码、推流）、服务端处理（转码、录制、截图、鉴黄）、播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）
关于直播的优化
1. 秒开优化
改写播放器逻辑让播放器拿到第一个关键帧后就给予显示。GOP 的第一帧通常都是关键帧，由于加载的数据较少，可以达到 “首帧秒开”。如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。
GOP 体现了关键帧的周期，也就是两个关键帧之间的距离，即一个帧组的最大帧数。假设一个视频的恒定帧率是 24fps（即1秒24帧图像），关键帧周期为 2s，那么一个 GOP 就是 48 张图像。一般而言，每一秒视频至少需要使用一个关键帧。
增加关键帧个数可改善画质（GOP 通常为 FPS 的倍数），但是同时增加了带宽和网络负载。这意味着，客户端播放器下载一个 GOP，毕竟该 GOP 存在一定的数据体积，如果播放端网络不佳，有可能不是能够快速在秒级以内下载完该 GOP，进而影响观感体验。
2. 马赛克、卡顿
如果 GOP 分组中的P帧丢失会造成解码端的图像发生错误,其实这个错误表现出来的就是马赛克。因为中间连续的运动信息丢失了，H.264 在解码的时候会根据前面的参考帧来补齐，但是补齐的并不是真正的运动变化后的数据，这样就会出现颜色色差的问题，这就是所谓的马赛克现象
这种现象不是我们想看到的。为了避免这类问题的发生，一般如果发现 P 帧或者 I 帧丢失，就不显示本 GOP 内的所有帧，直到下一个 I 帧来后重新刷新图像。但是 I 帧是按照帧周期来的，需要一个比较长的时间周期，如果在下一个 I 帧来之前不显示后来的图像，那么视频就静止不动了，这就是出现了所谓的卡顿现象。如果连续丢失的视频帧太多造成解码器无帧可解，也会造成严重的卡顿现象。视频解码端的卡顿现象和马赛克现象都是因为丢帧引起的，最好的办法就是让帧尽量不丢。
3. 传输协议优化
在服务端节点和节点之间尽量使用 RTMP 而非基于 HTTP 的 HLS 协议进行传输，这样可以降低整体的传输延迟。这个主要针对终端用户使用 HLS 进行播放的情况。
如果终端用户使用 RTMP 来播放，尽量在靠近推流端的收流节点进行转码，这样传输的视频流比原始视频流更小。
如果有必要，可以使用定制的 UDP 协议来替换 TCP 协议，省去弱网环节下的丢包重传可以降低延迟。它的主要缺点在于，基于 UDP 协议进行定制的协议的视频流的传输和分发不够通用，CDN 厂商支持的是标准的传输协议。另一个缺点在于可能出现丢包导致的花屏或者模糊（缺少关键帧的解码参考），这就要求协议定制方在 UDP 基础之上做好丢包控制。
4. 传输网络优化
在服务端节点中缓存当前 GOP，配合播放器端优化视频首开时间。
服务端实时记录每个视频流流向每个环节时的秒级帧率和码率，实时监控码率和帧率的波动。
客户端（推流和播放）通过查询服务端准实时获取当前最优节点（5 秒一次），准实时下线当前故障节点和线路。
5. 推流、播放优化
考察发送端系统自带的网络 buffer 大小，系统可能在发送数据之前缓存数据，这个参数的调优也需要找到一个平衡点。
播放端缓存控制对于视频的首开延迟也有较大影响，如果仅优化首开延迟，可以在 0 缓存情况下在数据到达的时候立即解码。但如果在弱网环境下为了消除网络抖动造成的影响，设置一定的缓存也有必要，因此需要在直播的稳定性和首开延迟优化上找到平衡，调整优化缓冲区大小这个值。
播放端动态 buffer 策略，这是上面播放端缓存控制的改进版本。如果只是做 0 缓存和固定大小的缓存之间进行选择找到平衡，最终还是会选择一个固定大小的缓存，这对亿级的移动互联网终端用户来说并不公平，他们不同的网络状况决定了这个固定大小的缓存并不完全合适。因此，我们可以考虑一种「动态 buffer 策略」，在播放器开启的时候采用非常小甚至 0 缓存的策略，通过对下载首片视频的耗时来决定下一个时间片的缓存大小，同时在播放过程中实时监测当前网络，实时调整播放过程中缓存的大小。这样即可做到极低的首开时间，又可能够尽量消除网络抖动造成的影响。
动态码率播放策略。除了动态调整 buffer 大小的策略之外，也可以利用实时监测的网络信息来动态调整播放过程中的码率，在网络带宽不足的情况下降低码率进行播放，减少延迟。
参考：
