这篇文章给大家聊聊关于深入解析iOS音视频处理（第一部分），以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
一、视频的构成
图像: 视频内容本身是由一帧一帧的图片组成的。只要一秒钟连续播放超过16张图片，人眼就会认为这是一个连贯的视频。这种物理现象称为视觉暂留。
音频: 视频必须由音频+图像内容组成，因此音频是视频的独立部分，我们需要对其进行单独编码。
元信息: 元信息实际上是描述信息的信息。它用于描述信息的结构、语义、目的、用途等。例如，视频元信息包含视频的具体信息，如编码格式、分辨率、字幕等。
二、音视频的文件格式与封装格式
1.视频文件格式
我们常见的Word文档文件格式是.doc，JPG图片的文件格式是.jpg等。对于视频，我们常见的文件格式包括.mov、avi、mpg、vob、 mkv、rm、rmvb 等
文件格式通常用文件存储在操作系统上时的后缀名来表示，操作系统通常用它来关联相应的打开程序，比如你双击一个test.doc文件，系统会调用Word去打开它。你双击一个test.avi或者test.mkv系统会调用视频播放器去打开它。
2.视频封装格式
视频封装格式，简称视频格式，相当于一种储存视频信息的容器，其中包含封装视频文件所需要的视频信息、音频信息和相关的配置信息（例如：视频和音频相关信息，如何解码等）。视频封装格式的直接体现是对应的视频文件格式。
封装格式：是将编码压缩后的视频数据和音频数据按照一定的格式放入文件中。该文件可以称为容器。当然，可以理解为这只是一个外壳。
容器不仅存储音频数据和视频数据，还存储用于视频同步的元数据，例如字幕。这些类型的数据会被不同的程序处理，但在传输和存储时，这些类型的数据被绑定在一起。
下面我们列出一些文件封装格式：
封装格式说明AVI对应的文件格式是.avi，英文全称是Audio Video Interleaved，由微软于1992年推出。这种视频格式的优点是图像质量好，无损AVI可以保存alpha渠道。缺点是体积太大，压缩标准不统一，高低版本之间存在很多兼容性问题。 DV-AVI对应的文件格式是.avi，英文全称是Digital Video Format。它是由索尼、松下、JVC等厂商联合提出的一种家庭数字视频格式。常见的数码相机使用这种格式来记录视频数据。它可以通过计算机的IEEE 1394端口将视频数据传输到计算机，也可以将计算机中编辑的视频数据记录回数码相机。 WMV对应的文件格式有.wmv、asf，英文全称是Windows Media Video。它是微软推出的一种文件压缩格式，采用独立的编码方式，可以直接实时观看互联网上的视频节目。在同等视频质量的情况下，WMV格式文件可以边下载边播放，非常适合在线播放和传输。 MPEG对应的文件格式有.mpg、mpeg、mpe、dat、vob、asf、3gp、mp4等，英文全称是Moving Picture Experts Group，是由运动图像专家组。该专家组成立于1988年，负责视音频标准的制定。其成员都是视频、音频和系统领域的技术专家。 MPEG格式目前有三种压缩标准，即MPEG-1、MPEG-2和MPEG-4。 MPEG-4 是最常用的视频封装格式。它专为播放流媒体的高质量视频而设计，以便使用最少的数据获得最佳的图像质量。 Matroska对应的文件格式是.mkv。 Matroska 是一种新的视频封装格式，可以将多个不同编码的视频、超过16 种音频格式以及不同语言的字幕流封装到一个Matroska Media 文件中。 Real Video对应的文件格式有.rm、rmvb，这是Real Networks公司开发的音视频压缩规范，称为Real Media。用户可以使用RealPlayer根据不同的网络传输速率制定不同的压缩比，从而实现图像数据在低速网络上的实时传输和播放。 QuickTime File Format对应的文件格式是.mov，它是Apple开发的视频格式。默认播放器是Apple 的QuickTime。这种封装格式具有压缩比较高、视频清晰度完美的特点，并且可以节省Alpha通道。 Flash Video对应的文件格式为.flv，它是从Adobe Flash扩展而来的一种在线视频打包格式。许多视频网站都使用这种格式。
三、音视频的编码方式
音视频编解码的过程是指对数字视频进行压缩或解压缩的一个过程。在进行视频编解码时，需要考虑以下因素的平衡：
视频的质量、用来表示视频所需要的数据量（通常称之为码率）、编码算法和解码算法的复杂度、针对数据丢失和错误的鲁棒性（Robustness）、编辑的方便性、随机访问、编码算法设计的完美性、端到端的延时以及其它一些因素。
1.视频编码方式
H.26X 系列：由国际电信联盟电信标准化组织（ITU-T）主导，包括H.261、H.262、H.263、H.264、H.265H.26X系列说明H .261 主要用于较旧的视频会议和视频电话系统。是第一个使用的数字视频压缩标准。本质上，后续的所有标准视频编解码器都是基于它的。 H.262 相当于MPEG-2 Part 2，用于DVD、SVCD 以及大多数数字视频广播系统和有线分配系统。 H.263主要用于视频会议、可视电话和网络视频相关产品。在压缩逐行扫描视频源时，H.263 的性能比其先前的视频编码标准有了显着提高。尤其是在低码率端，在保证一定质量的同时，可以大大节省码率。 H.264相当于MPEG-4 Part 10，也称为高级视频编码（简称AVC）。它是一种视频压缩标准，广泛用于高精度视频的录制、压缩和发布。格式。该标准引入了一系列新技术，可以大幅提升压缩性能，在高低码率端都大幅超越之前的标准。 H.265全称为高效视频编码（High Efficiency Video Coding，简称HEVC），是一种视频压缩标准，是H.264的后继者。 HEVC被认为不仅可以提高图像质量，还可以实现H.264的两倍压缩率（相当于相同画质的码率降低50%），并且可以支持4K分辨率甚至超高清电视，最高分辨率分辨率可以达到81924320（8K分辨率），这是当前的发展趋势。MPEG 系列，由国际标准组织(ISO) 下的运动图像专家组(MPEG) 开发。 MPEG系列说明MPEG-1 Part 2主要用在VCD上，一些在线视频也使用这种格式。该编解码器的质量大致相当于原始VHS 磁带的质量。 MPEG-2 Part 2 相当于H.262，用于DVD、SVCD 以及大多数数字视频广播系统和有线分配系统。 MPEG-4 Part 2 可用于网络传输、广播和媒体存储。它提供了比MPEG-2 Part 2 和H.263 version 1 更高的压缩性能。MPEG-4 Part 10 相当于H.264，这是两个编码组织之间合作诞生的标准。其他编码方式：AMV、AVS、Bink、CineForm等，这里不再详细介绍。一个H.264/MOV的视频文件，它的封装方式就是 QuickTime File Format，编码方式是 H.264。
2.音频编码方式
音频编码方法说明AAC，英文全称Advanced Audio Coding，是由Fraunhofer IIS、杜比实验室、ATT、Sony等公司联合开发并于1997年推出的一种基于MPEG-2的音频编码技术2000年，MPEG-4标准出现后，AAC重新整合了其特性，加入了SBR技术和PS技术。为了区别于传统的MPEG-2 AAC，也被称为MPEG-4 AAC。 MP3的英文全称是MPEG-1或MPEG-2 Audio Layer III。它是一种曾经非常流行的数字音频编码和有损压缩格式。它旨在显着减少音频数据量。它是由位于德国埃尔兰根的研究组织Fraunhofer-Gesellschaft 的工程师团队于1991 年发明并标准化的。 MP3的流行对音乐产业产生了很大的影响。 WMA的英文全称是Windows Media Audio。它是微软开发的一种数字音频压缩格式。它本身包括有损和无损压缩格式。
3.直播/小视频使用的编码格式
视频编码的优点H264编码： 码率低、图像质量高、容错能力强、网络适应性强总结: H264最大的优点是数据压缩比高。在相同图像质量下，H264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5~2倍。
举例: 如果原始文件大小为88GB，采用MPEG-2压缩标准压缩后变为3.5GB，压缩比为25:1，采用H.264压缩标准压缩后变为879MB，从88GB 至879MB。 H.264的压缩比达到惊人的102:1
音频编码的优点AAC编码：AAC是目前流行的有损压缩编码技术，并衍生出三种主要编码格式：LC-AAC、HE-AAC、HE-AAC v2。
LC-AAC 是比较传统的AAC，主要用于中高码率场景（=80Kbit/s）的编码HE-AAC 主要用于低码率场景（=48Kbit/s）的编码优势: in less高于128Kbit/s 在s比特率下表现良好，多用于视频中的音频编码；
适合场景: 128Kbit/s以下的音频编码，主要用于视频中的音轨编码。
四.直播框架介绍
1.直播产品种类
泛娱乐直播
花椒、映客等娱乐直播，以及斗鱼、熊猫等游戏实时互动直播
音视频会议、教育直播等，如Zoom、声网泛娱乐化直播：大型直播（无交互），多用于观看，可以采用此架构。支持rtmp、hls、http/flv
实时互动直播：采用RTP协议，与目前的学习协议不同； webrtc常用
2.泛娱乐化直播架构
1、主播向信令服务器发送信令，创建房间，并返回房间地址；
2、主播推流到获取的房间地址；
3、同样是主播侧，与1相同，但协议不同；
4、同2；
5、观众观看节目还需要向信令服务器发送信令。获取主机节目的媒体流地址；
6、观众获得主播节目的流地址后，可以去CDN流媒体云拉流。赞赏和聊天发送至信令服务器进行处理。
3.实时互动直播架构
实时互动直播需要您创建自己的网络。使用UDP协议而不是TCP协议来创建网络（原因参考TCP和UDP）；另一个原因是业务需求，因为为了保证客户可以随时使用实时互动直播来提供服务，就必须保证服务器24小时正常运行。因此，后台服务器一般采用多个节点。当其中一个节点出现问题时，可以将该节点的所有服务切换到正常节点。
所有节点均通过控制中心进行管理。控制中心与节点之间的通信通过心跳保存。每个节点定期向控制中心报告其状态（如CPU、内存使用情况、网络使用情况等），控制中心将根据节点的状态数据做出决策。当发现某个节点的CPU过高或者某个指标不达标时，会将其业务转移到其他节点或者有新业务时，会分配给其他负载较低的节点执行确保各个节点Node负载均衡。事实上，节点和控制中心之间有一条内部总线。内部总线的作用是保证数据安全。
如果既有实时互动直播，又有观众观看，那么实时互动直播架构和泛娱乐架构就需要融合。这时泛娱乐架构中就会多出一个媒体服务器，媒体服务器主要起到转换的作用。
由于实时互动直播架构采用UDP协议和RTP（实时传输协议）传输，RTP数据包通过内部总线传输到媒体服务器。媒体服务器将RTP流转换为rtmp流并传输到CDN网络。那么观众就可以像泛娱乐直播那样获取直播内容。
4.直播App框架
进程采集视频，音频使用iOS原生框架AVFoundation.framework
视频滤镜处理使用iOS原生框架CoreImage.framework
使用第三方框架GPUImage.framework
GPUImage OC版下载地址
GPUImage Swift版本下载地址
视频音频编码压缩硬编码：
视频：VideoToolBox框架
Audio :AudioToolBox框架软编码
视频：使用FFmpeg和X264算法将原始视频数据YUV/RGB编码为H264
音频： 使用fdk_aac 将音频数据PCM 转换为AAC推流: 将采集到的音视频数据通过流媒体协议发送到流媒体服务器。推流技术：
流媒体协议： RTMPRTSPHLSFLV 视频封装格式： TSFLV 音频封装格式： Mp3AAC流媒体服务器数据分发、截屏、实时转码、内容检测拉流从流媒体服务器获取音频 视频数据
流媒体协议： RTMPRTSPHLSFLV
解码视频和音频的解码框架仍然与编码框架相同。
音视频播放ijkplayer播放框架kxmovie播放框架ijkplayer/kxmovie基于FFmpeg框架进行封装。
五、了解颜色模型
开发场景中用得最多的应该是RGB模型：
RGB 模型中的每种颜色需要3 个数字，分别代表R、G、B。通常一个数字占用1个字节，因此需要24位来表示一种颜色。
那么是否有一种更高效的颜色模型，可以使用更少的位数来表示颜色呢？
在彩色电视出现之前，人们使用的是黑白电视和YUV模型。
定义一个Y“Luminance”的概念来表示颜色的亮度，则可以表示为包含R、G、B的表达式：
Y=kr*R + kg*G + kb*BY 是“亮度”，kr、kg、kb 是R、G、B 的权重值。
定义UV“色度”的概念来表示颜色的差异：
Cr=R Y
Cg=G Y
Cb=B YCr、Cg、Cb 分别表示R、G、B 上的色度分量。上述模型就是YCbCr颜色模型的基本原理。
在YCbCr中，Y指亮度分量，Cb指蓝色色度分量，Cr指红色色度分量。
通过从ITU-R BT.601-7标准中获取推荐的相关系数，可以得到YCbCr转换为RGB的公式：
Y=0.299R + 0.587G + 0.114B
Cb=0.564(B-Y)
铬=0.713(R-Y)
R=Y+1.402Cr
G=Y - 0.344Cb - 0.714Cr
B=Y + 1.772Cb在 YUV 中 Y 表示的是「亮度」，也就是灰阶值，U 和 V 则是表示「色度」。YUV的关键在于它的亮度信号Y和色度信号U、V是分离的。
也就是说，即使只有Y信号分量而没有U、V分量，我们仍然可以表示图像，但该图像是黑白灰度图像。
YUV常见格式
YUV4:4:4 (YCbCr 4:4:4) - 理解为1:1:1，即4个Y对应4个U和4个V。 YUV4:4:4YUv4:2:2 (YCbCr 433 3602:2)--YUV4:2:2比RGB小三分之一； RGB需要8:8:8。YUV也节省了大量空间，这是历史原因。 YUv4:2:2YUV4:2:0 (YCbCr 4:2:0) - 这比RGB 少二分之一。 YUV4:2:0 最常见
YUV存储格式
plannar(平面)
I420 : YYYYYYYY UU WV --YUV420P（适用于PC）
YV12: YYYYYYYY VV UU --YUV420P
包装（#T5）
NV12: YYYYYYYY UVUV --YUV420SP (iOS)
NV21: YYYYYYYY VUVU --YUV420SP（安卓）
【深入解析iOS音视频处理（第一部分）】相关文章：
2.米颠拜石
3.王羲之临池学书
8.郑板桥轶事十则
用户评论
我一直都想学习一下 iOS 的音视频开发，这篇文章正好来得好。
有10位网友表示赞同！
听起来很专业，希望讲得通俗易懂！
有10位网友表示赞同！
最近在探索移动端音视频应用开发，这个学习路线很有帮助。
有19位网友表示赞同！
iOS 平台的音视频技术确实很强大，希望能学到更多实用的技巧。
有6位网友表示赞同！
想了解 iOS 如何处理音频和视频录制、播放等操作，期待深入讲解！
有19位网友表示赞同！
手机上玩游戏或直播都需要依赖强大的音视频支持，学习这方面知识很重要啊。
有11位网友表示赞同！
做短视频应用的同学应该会对这个主题很感兴趣吧？
有13位网友表示赞同！
iOS 的开发环境是不是比较复杂？希望能分享一些入门tips。
有18位网友表示赞同！
除了基础功能，还有什么更高级的音视频处理技术可以学习呢？
有9位网友表示赞同！
希望作者能介绍一些常用的库和框架，方便我们上手实践。
有20位网友表示赞同！
这篇文章一定能让我对 iOS 音视频开发有更全面的认识！
有13位网友表示赞同！
想了解更多关于实时音视频通话的技术细节，希望能有相关内容分享。
有7位网友表示赞同！
如果能结合一些实际案例进行讲解，理解起来会更好吧？
有16位网友表示赞同！
iOS 的音视频开发前景怎么样？未来发展方向是什么？
有12位网友表示赞同！
有没有什么好用的调试工具可以帮助我们排查音视频问题？
有20位网友表示赞同！
学习完这个系列文章以后，就能开发出自己的音视频应用了吗？
有14位网友表示赞同！
期待作者的后续文章详解具体的代码实现和操作步骤！
有14位网友表示赞同！
这种类型的分享能让我更好地了解移动软件开发者的日常工作。
有16位网友表示赞同！
这篇文章或许可以帮助我解决最近遇到的一些音视频开发问题。
有6位网友表示赞同！