第一章：AV Foundation入门：
1.1 AV Foundation的含义
AV Foundation是苹果OS X系统和iOS系统中用于处理基于时间的媒体数据的高级Objective-C框架。其设计过程高度依赖多线程机制，充分利用了多核硬件的优势并大量使用block和GCD来将复杂的计算机进程放在后台线程运行。会自动提供硬件加速操作，确保在大部分设备上应用程序能以最佳性能运行，也充分考虑了电量效率来满足诸如iPhone和iPad等移动设备对电量控制的高要求。此外，从一开始该框架就是针对64位处理器设计的，可以发挥64位处理器的所有优势。-- 好像很屌的样子哦。。
1.2 AV Foundation的适用范围
Mac OS X和iOS为开发者提供了一些高基层和低级层的框架来实现时基媒体(timed media)的各功能。下图展示了AV Foundation在整个体系中所处的角色。
两个平台都针对处理媒体相关操作提供了一系列高基层的解决方案。在iOS中，利用UIKit框架可以很容易的将基本的静态图片和视频不住整合到你的应用程序中。Mac OS X和iOS两个系统都可以通过WebView或者UIWebView中添加<audio>和<video>的HTML5标签来播放音频和视频内容。此外，两个系统都还提供了AVKit框架，用于简化目前流行的视频播放应用程序的创建过程。
在这些使用范围的另一端同样给出了一些低级层的框架，他们支持所有高基层方法所使用的功能。大部分这些框架都是低级层、基于C应用程勋且功能强大和高性能的。但是往往学习起来比较复杂，并需要对硬件级媒体处理有非常深入的理解才行。下面介绍几个最主要的支撑框架及其提供的功能(低级层)：
Core Audio：Core Audio是OS X和iOS系统上处理所有音频事件的框架。Core Audio是由多个框架整合在一起的总称，为音频和MIDI(Musical Instrument Digital Interface乐器数字接口)内容的录制、播放和处理提供相应的接口。Core Audio也提供高级层的接口，比如通过Audio Queue Services框架所提供的那些接口，主要处理基本的音频播放和录音相关功能。同时还会提供想对低层级的接口，尤其是Audio Units接口，它们提供了针对音频信号进行完全控制的功能，并通过Audio Units让你能够构建一些复杂的音频处理模式。
Core Video：Core Video是OS X和iOS系统上针对数字视频所提供的管道模式。Core Video为其想对的Core Media提供图片缓存和缓存池支持，提供了一个能够对数字视频逐帧访问的接口。改框架通过像素格式之间的转换并管理视频同步事项使得复杂的工作得到了有效简化。
Core Media：Core Media是AV Foundation所用到的低级层媒体管道的一部分。它提供针对音频样本和视频帧处理所需的低级层数据类型和接口。Core Media还提供了AV Foundation用到的基于CMTime数据类型的时基模型。CMTime及其相关数据类型一般在AV Foundation处理基于时间的操作时使用。
Core Animation：Core Animation是OS X和iOS提供的合成及动画相关框架。只要功能是提供苹果平台所具有的美观流畅的动画效果。它已经封装了支持OpenGL和OpenGL ESG功能的基于Objective-C的各种类。
出于高基层和低级层中间的就是AV Foundation。在整个媒体分类图中AV Foundation的地位举足轻重，其提供了很多低级层框架才能实现的功能和性能，并且是以更简单的Objective-C接口方式时间的。同时它也可以和高级层的框架无缝衔接。此外，由于AV Foundation出于UIKit和AppKit层之下，这意味着你可以在这两个平台下使用这个媒体框架。
1.3 解析AV Foundation
在学习AV Foundation之初，最大的挑战就是理解该框架所提供的大量类及其功能。该框架包含的类超过100个，大量协议的集合及许多不同的功能和常量。但是，如果你将这个框架仔细地按照功能单元进行分解，就会变得比较容易理解。下面就看一下AV Foundation所提供的一些核心功能：
音频播放和记录：回顾一下图1-1，会发现AV Foundation方框的右上角有一个小方格被单独标记为“音频专用类”。这是由AV Foundation提供的关于音频处理的一些早期功能。AVAudioPlayer和AVAudioRecorder可以在应用程序中提供一种更简单的整合音频播放和记录的功能。这些方法并不是AV Foundation用于播放和记录视频的唯一方式，但是学习起来最简单且功能最强大的方法。
媒体文件检查：AV Foundation提供检查正在使用的媒体文件的功能。可以查看这些媒体资源来确定是否适合一些特定的任务，比如是否可以用于回访或其是否可以被编辑和导出。还可以获取该媒体资源相关的技术参数，比如内容持续时间、创建日期或首选播放音量等。此外，该框架还基于AVMetadataItem类提供功能强大的元数据支持。这就允许开发者读写关于媒体资源的描述信息，比如唱片簿和艺术家信息。
视频播放：AV Foundation提供的其中一个最常用的功能就是视频播放，这个功能通常是很多媒体应用程序最主要或次要的功能。AV Foundation框架可以让你播放从本地文件或远程流中获取的视频资源，并对视频播放和内容的展示进行控制。这一部分的核心类是AVPlayer和AVPlayerItem。正是这两个类让你能够对资源的播放进行控制，此外它还可以整合其他更高级的功能，如控制子标题和章节信息等，或者让你连接访问音频和视频这两个不同的资源。
媒体捕捉：最近推出的酥油Mac和iOS设备都内置了摄像头，作为捕捉静态图片和视频的高性能外设。AV Foundation提供了一个丰富的API集来让你可以对这些设备进行精密控制。摄像头捕捉的核心类是AVCaptureSession，其作为所有活动的汇集点来接收摄像头设备由各路流发过来的电影和图片。这也是AV Foundation框架的一个可靠功能，所以其可以根据近期发布的框架版本进行答复改进。
媒体编辑：该框架允许创建可以将多个音频和视频资源进行组合的应用程序，允许修改和编辑独立的媒体片段，随时修改音频文件的参数以及添加动画标题和场景切换效果。Mac和iPad上的一些工具，比如Final Cut Pro X和iMovie，都是使用这个功能创建的最好示例应用。
媒体处理：有时你可能需要访问更底层的数据并对其进行操作。幸运的是，当需要执行更高级的媒体处理任务时，可以使用AVAssetReader和AVAssetWriter类来实现这些功能。这些类提供直接访问视频帧和音频样本的功能，所以可以对媒体资源进行任何更高级的处理。
1.4 了解数字媒体
使用数字媒体已经成为了广大用户一种本能的习惯了。我们显然已经处于一个数字化的时代，但是我们还是更习惯模拟信息的世界。我们看到的信号标识和所听到的音乐都是通过模拟信号传递给我们的，我们的眼睛和耳朵的构造将这些信息转换为我们大脑能够解析出的电信号。现实生活中的信号是连续的，信号的频率和强度是不断变化的。但是数字世界的信号是离散的，由1和0两个状态标示。要将模拟信号转换成我们能够储存的数字信号，要经过模拟-数字转换过程，我们将这个过程称为采样（Samping）
1.4.1 数字媒体采样：对媒体内容进行数字化主要有两种方式。第一种称为时间采样，这种方式捕捉一个信号周期内的变化。第二种采样方式是空间采样，一般用在图片数字化和其他可现视化媒体内容数字化的过程中。空间采样包含对一幅图片在一定分辨率之下捕捉其亮度和色度，进而创造由该图片的像素点数据所构成的数字化结果。当对一段视频进行数字化时，这两种方式都可以使用，因为通常的视频信号既有空间属性又有时间属性。
幸运的是，开发者不需要对这两个采样过程中所用到的具体数字化信号处理原理有很深的研究，因为设备硬件可以帮助我们完成模拟信号到数字信号的转换。但是如果不了解这些采样过程的基本原理及之后数字媒体内容的储存格式的话，在你进一步深入学习AV Foundation更高级、更有趣功能的时候会感到比较吃力。所以我们还需要了解采样过程的相关知识，下面以音频采样为例逐步对其进行研究。
1.4.2 音频采样介绍：当你听到一个人的声音、号角声或者吉他弹奏声时，你真正听得的是声波通过一定介质传播过来的振动。这个振动会导致周围的空气分子移动，这些分子会依次同其临近的空气分子进行碰撞，之后再依次传递这个碰撞，将最初的振动能量不断地向各个方向进行传播。当这些波动传到接收者的耳中时，会带动耳膜以同样的频率和振幅振动。这些振动继续传递到内耳的耳蜗上，此时会将这些振动转换成电信号传给大脑，大脑会处理这个信号并知道“我听到了一个G调声音”。
当我们记录一个声音时，比如诸如钢琴或者吉他等乐器所发出的声音，一般会使用麦克风设备。麦克风是将机械能量（声波）转换成电能量（电压信号）的转换设备。目前在用的麦克风种类很多，但是这里讨论的麦克风类型我们成为电动式麦克风（dynamic microphone）。图1-2展示了电动式麦克风内部的高级视图。
在麦克风的头部设备中所包含的，作为接受声音的一部分，是薄薄的被称为“膜片”的薄膜。这个膜片连接缠绕的磁极的线圈，当你对着麦克风讲话时，膜片会根据其感受到的声波进行振动，再依次带动线圈振动，产生同输入信号相同频率和振幅的电流信号。使用示波器我们可以看到电信号的振荡，如图1-3所示。
下面再回到之前关于采样的主题上，我们应该如何将这个连续的信号转换成相应的离散形式呢？先灌输一点之后会详细介绍的音频信号处理的核心知识，即使用音频生成器，这里我们创建了两个不同的音频正弦波，如图1-4
我们队这个信号的两个方面比较感兴趣。第一个是振幅，它代表了电压的强度或相应信号的强度。它代表了电压的强度或相应信号的强度。虽然可以通过不同坐标系来呈现正弦曲线的变化，但是我们通常会选择-0.1f到1.0f作为坐标系的最大值和最小值。对于这个信号，我们感兴趣的另一个方面是频率，信号频率的测量单位是赫兹Hz，表示在一个周期内振动完成循环的次数。图1-4左边的图片展示了1Hz情况下音频信号的一个周期（1s内完成1次循环），右边的图片展示了5Hz情况下的信号情况（1s内完成5个循环）。人类可以听到的音频范围是20Hz~20kHz(20000Hz)，所以图上的两个信号都是不能被听见的，只是其更适合展示而已。
PS：虽然人类可以接收的音频范围是20Hz~20kHz(20000Hz)，不过这个频率范围也只是理论上的范围，因为几乎没有人可以听见这两个边界频率之外的声音，因为一旦处于嘈杂的环境之下听力就会减弱，同样随着年龄的增长听力也会变弱。这里我们提供一些不同频率的声音参照，如钢琴、AO最低音调的频率是27.5Hz和C8，最高频率接近4.1kHz。
音频数字化的过程包含一个编码方法，称为线性脉冲编码调制（linear pulse-code modulation），比较常见的说法是Linear PCM或LPCM。这个过程采样或测量一个固定的音频信号，过程的周期率被称为采样率。图1-5展示了在一秒内对信号进行7次采样及信号的数字化结果图。
显然低采用率的数字信号版本无法很好地表现原始数据。播放这样的音频信息通常会用在点击或弹出等动作的声音情况下。问题主要在于图1-5所示的采样频率尚无法准确地表示信号的原意。我们按照图1-6所示的情况再做一次，这次我们提高采样频率。
这次效果显然得到了提升，但仍然不能准确表示原始信号。不过通过这个示例你可以推测如果不断提高采样的频率，我们就可以以数字化方式准确表现原始信号的信息。鉴于硬件条件的限制，我们还不能复制出完全一样的效果，但是我们能否找到一个采样频率用于生成足够好的数字呈现效果？答案是肯定的。我们称其为尼奎斯特频率(Nyquist rate)。20世纪30年代，Harry Nyquist是贝尔实验室的一名工程师，他精确的捕捉到了一个特定频率，该频率为需要采样对象的最高频率的两倍。比如一个你需要捕捉的音频素材的最高频率为10kHz，你所需要的采样率起码为20kHz才能更好的数字化效果。使用CD录制的音频采样率为44.1kHz，这就意味着能捕捉到的最大频率为22.05kHz，刚刚高过人耳能够识别范围（20kHz）。44.1kHz的采样率可能还不能捕捉到初始资源中的所有频率范围，这意味着采样点可能会收到录制环境的干扰，因为其无法捕捉到Abbey Road会话的细微差别，不过对于人耳的听觉来说，这已经足够好了。
除采样率外，数字音频采样的另一个重要方面是我们能够捕捉到什么精度的音频样本。振幅在线性坐标系中进行测量，所以会有Linear PCM这个术语。用于保存样本值的字节数定义了在线性维度上可行的离散度，同时这个信息也被称为音频的位元深度。为每个样本的整体量化分配过少的位结果信息会导致数字音频信号产生噪音和扭曲。使用位元深度为8的方法可以提供256个离散级别的数据，对于一些音频资源来说，这个级别的采样率已经足够了，但是对于大部分音频内容来说还不够高。CD音质的位元深度为16，可以达到65536个离散级别。专业级别的音频录制环境的位元深度可以达到24或更高。
对信号进行数字化时，如果能够保留原始、未压缩的数字呈现效果，就是该媒体资源最纯粹的数字形式，但这样做需要大量的存储空间。比如一个44.1kHz、16位LPCM的音频文件每分钟可能要占用10MB的空间。要数字化一个含有12首歌的唱片，每首歌时间大概为5分钟的话，共需要近600MB的储存空间。即使在当今的海量储存和高宽带的情况下，这个文件体积仍然很大。所以我们可以看到不经过压缩的数字音频资源会占用大量的储存空间，但是未压缩的视频文件的情况是不是这样呢？下面了解一下组成数字视频文件的元素来判断能否满足其对储存空间的需求。
视频文件由一系列成为“帧”的图片组成，在视频文件的时间轴线上每一帧都表示一个场景。要创建连续的运动画面，我们需要在短时间间隔内提供特定数量的帧。视频文件一秒钟内所能展现的帧数成为视频的帧率，并用FPS作为单元进行测量。常见的帧率是24FPS（每秒24帧）、25FPS、30FPS。
要知道未压缩的视频内容所需的储存空间，我们首先需要确定每一个独立的帧有多大。我们知道有很多通用的视频尺寸，但是目前视频资源最流行的宽高比为16:9，意思是每16个水平像素对应9个垂直像素。在这一宽高比之下最常见的视频尺寸为1280*720和1920*1080.那么各自的像素情况是什么样的呢？如果对每个像素点使用8位RGB色彩空间，这就意味着红色占8位，绿色占8位，蓝色占8位。所有的输入手机好后，我们执行一些计算。表1-1展示了未压缩视频在30FPS帧率的情况下，上述两个分辨率的储存空间需求。
哦，天哪！我们现在遇到问题了！显然，作为储存和传输文件的格式，这简直难以想象。也许十年后这些文件看起来能够接受，但是目前对于大多数情况我们都无法方便的使用这么大的媒体文件。由于大部分情况下对视频进行储存或传输都是不可取的，所以我们需要找到一种方式缩小资源的尺寸。这就带来了我们接下来讨论的资源压缩的话题。
1.5 数字媒体压缩
为缩小数字媒体文件的大小，我们需要对其使用压缩技术。一般来说我们所欣赏的媒体内容都进行过一定程度的压缩。对数字媒体进行压缩可以大幅缩小文件的尺寸，但是通常会在资源的质量上有小幅可见的衰减。
1.5.1 色彩二次抽样
视频数据是使用称之为Y'CbCr'颜色模式的典型案例，Y'CbCr'也常称为YUV。虽然YUV术语并不是很准确，但是YUV读起来比Y-Prime-C-B-C-R方便很多。不过大部分软件开发者都更熟悉RGB颜色模式，即每个像素都是由红、绿、蓝三个颜色组合而成。YUV则使用色彩（颜色）通道UV替换了像素的亮度通道Y（亮度）。图1-7展示了一幅图片分离亮度和色彩通道后的效果。
可以看到图片的所有细节都保存在亮度通道中，如果除去亮度，剩下的就是一幅灰度图片，我们再看整合的色彩通道中几乎所有的细节都丢失了。这是因为我们的眼睛对亮度的敏感度要高于颜色，聪明的工程师们认识到，我们可以大幅减少储存在每个像素中的颜色信息，而不至于图片的质量受损。减少这个颜色数据的过程就称为色彩二次抽样。
当每次看到诸如摄像头规范和其他视频设备硬件或软件中提到的4:4:4、4:2:2及4:2:0时，这些值的含义就是这些设备所使用的色彩二次抽样的参数。根据这些值按照如下格式将亮度比例表示为色度值，这个格式写作J:a:b，具体含义如下：
J：几个关联色块（一般是4个）中所包含的像素数
a：用来保存位于第一行中的每个J像素的色度像素个数
b：用来保存位于第二行中的每个J像素的附加像素个数
为维持图片质量，每个像素点都需要有各自的亮度值，却不一定需要色度值。图1-8展示了几个常见的二次抽样比率及其效果。
在所有的格式下，每个像素的全部亮度信息都保存下来，在4:4:4的比例下全彩色信息也被保存下来。在4:2:2的情况下，色彩信息为每两个水平像素的平均值，即亮度和色度比率为2:1。在4:2:0的情况下，色彩信息为水平和垂直两个方向的4个像素的平均值，结果就是亮度和色度的比率为4:1。
色彩二次抽样一般发生在取样时，一些专业的相机以4:4:4的参数捕捉图像，但大部分情况下对于图片的拍摄是使用4:2:2的方式进行的。面向消费者的摄像头装置，比如iPhone摄像头，通常以4:2:0的方式进行拍摄。即使经过大量层级的二次抽象之后页仍然可以捕捉到高质量的图片，iPhone手机排出来的高质量视频就是很好的例证。当以色彩作为核心或生产后期矫正颜色的时候，如果色彩方面出现了衰减，那会成为一个棘手的问题。由于我们的色彩信息是通过多个像素点平均得来的，噪声点和其他的一些失真问题也会出现在图片上。（这部分没看懂。。）
1.5.2 编解码器压缩
大部分音频和视频都是使用编解码器（codec）来压缩的，编解码器这个术语是由编码器/解码器结合简写得来的（encoder/decoder）。编解码器使用高级压缩算法对需要保存或发送的音频或视频数据进行压缩和编码，同时它还可以将压缩文件解码成适合播放和编辑的媒体资源文件。
编解码器既可以进行无损压缩也可以进行有损压缩，无损压缩编解码器以一种可以完美重构解码的方式对媒体文件进行压缩，使其成为无论编辑还是发布都比较理想的文件，有时也会作为归档文件用。我们经常使用这类压缩方式，比如我们最常用的zip和gzip即是这种方式的压缩。顾名思义，有损编解码器就是在压缩过程中会有部分数据损失掉。编解码器为这一形似的压缩使用基于人类可感知的高级压缩算法。比如即使人类可以理论上听见介于20Hz~20kHz之间的声音，但是我们可能真正敏感的频率区间是1kHz~5kHz。我们对于频率的感知随着距离上述区间而逐渐减弱。在了解这一原理后，我们知道在音频文件中可以利用过滤技术来减少或消除特定频率。这只是众多方法中的一个，但有损压缩的目的是使用psycho-acoustic或psycho-visual模式作为一种方法来减少媒体内容中的冗余数据，这样会使原文件质量的损耗到最小。
1.5.3 视频编解码器
对于视频编解码而言，AV Foundation提供有限的编解码器集合，只提供苹果公司认证的目前主流的几种媒体类型的支持。具体对于视频文件来说，主要可以归结为H.264和Apple ProRes。
H.264：
当我们需要对发送的视频文件进行编码时，Henry Ford说过，只要是H.264标准的文件，AV Foundation都提供视屏编解码器支持。幸运的是，行业内也默认对该编解码器进行了整合。这个标准广泛用于消费者摄像头捕捉到的资源并成为网页流媒体视频所使用的最主要格式。所有从itunes store下载的视频文件也会使用这个编解码器进行编码。H.264规范是Motion Picture Experts Group(MPEG)所定义的MPEG-4的一部分。H.264遵循早期的MEPG-1和MEPG-2标准，但是在以更低比特率得到更高图片质量方面有了长足进步，使其更好地用于流媒体文件和移动设备及视频摄像头。
H.264与其他形式的MPEG压缩一样，通过以下两个维度缩小了视频文件的尺寸：1、空间：压缩独立视频帧，被称为帧内压缩。2、时间：通过以组为单位的视频帧压缩冗余数据，这一过程称为帧间压缩。
帧内压缩通过消除包含在每个独立视频帧内的色彩及结构中的冗余信息来进行压缩，因此可在不降低图片质量的情况下尽可能缩小尺寸。这类压缩同JEPG压缩原理类似。帧内压缩也可以作为有损压缩算法，但通常用于对原始图片的一部分进行处理以生成极高质量的照片。通过这一过程创建的帧称为I-frames。
在帧间压缩中，很多帧被组合在一起作为一组图片（简称GOP），对于GOP所存在的时间维度的冗余可以被消除。如果想象视频文件中的典型场景，就会有一些特定动作元素的概念，比如行驶的汽车或街上走路的行人，场景的背景环境通常是固定的。固定的背景环境就代表一个时间维度上的冗余，这个冗余就可以通过压缩方式进行消除。
图1-9给出了储存在GOP中的三个不同类型的帧：
I-frames：这些帧都是一些单独的帧或关键帧，包含创建完整图片所需要的所有数据。每个GOP都正好有一个I-frames。由于它是一个独立帧，其尺寸是最大的，但也是解压最快的。
P-frames：又称为预测帧，是从基于最近I-frames或P-frames的可预测的图片进行编码得到的。P-frames可以引用最近的预测P-frames或一组I-frames。你将会经常看到这些被称为“reference frames”的帧，临近的P-frames和B-frames都可以对其进行引用。
B-frames：又称为双向帧，是基于使用之前和之后的帧信息进行编码后得到的帧。几乎不需要储存空间，但其解压过程会耗费较长时间，因为它依赖于周围其他的帧。
H.264还支持编码视图，用于确定在整个编码过程中所使用的算法。共定义了3个高级标准：
Baseline：这个标准通常用于对移动设备的媒体内容进行处理，提供了最低效的压缩，因此经过这个标准压缩后的文件仍较大，但是同时这种方法也是最少计算强度的方法，因为它不支持B-frames。如果开发者的编译目标是年代比较久远的iOS设备，比如iPhone 3GS，可能需要用到Baseline标准。
Main：这个标准的计算强度要比Baseline的高，因为它使用的算法更多，但可以达到比较高的压缩率。
High：高标准的方法会得到最高质量的压缩效果，但它也是3种方法中计算复杂度最高的，因为所有能用到的编码技术和算法几乎都用到了。
Apple ProRes：
AV Foundation支持Apple ProRes编解码器的两种不同风格。Apple ProRes被认为是一个中间件或中间层编解码器，因为它的目的是为专业编辑和生产工作流服务。Apple ProRes编解码器是独立于帧的，意味着只有I-frames可以被使用，这就使其更适合用在内容编辑上。此外，Apple ProRes还使用可变比特率编码的方式来对复杂场景中的每一帧进行编码。
ProRes是有损编解码器，但是它具有最高的编解码质量。Apple ProRes 422使用4:2:2的色彩二次抽样的10位的采样深度。Apple ProRes 4444使用4:4:4色彩二次抽样，具有最终4个用于表示支持无损alpha通道和高达12位的采样深度。
ProRes编解码器只在OS X上可用，如果开发者只针对iOS进行开发工作，只能使用H.264。然而苹果公司提供了一种方法，当我们捕捉图像的目的是对其进行编辑时，可以将目标变换成通用的H.264编码格式，成为iFrame。对于编辑环境而言这是一个I-frames-only变量生成H.264视频更适合的一种方法。这种格式在AV Foundation中是受支持的，并且它还被众多摄像头生产企业所支持，比如Canon、Panasonic和Nikon。 PS：对H.264和Apple ProRes来说，AV Foundation还支持很多摄像头的编解码器，如MPEG-1、MPEG-2、MPEG-4、H.263和DV，允许用户以多种不同的视频捕捉设备导入内容资源。
1.5.4 音频编解码器
只要是Core Audio框架支持的音频编解码，AV Foundation都可以支持，这意味着AV Foundation能够支持大量不同格式的资源，然而在不用线性PCM音频的情况下，更多的只能使用AAC。
AAC：高级音频编码（AAC）是H.264标准相对应的音频处理方式，目前已成为音频流和下载的音频资源中最主流的编码方式。这种格式比MP3格式有这显著的提升，可以在低比特率的前提下提供最高质量的音频，是在Web上发布和传播的音频格式中最为理想的。此外，AAC没有来自证书和许可方面的限制，这一限制曾经在MP3格式上个饱受诟病。
PS：AV Foundation和Core Audio提供对MP3数据编码的支持，但是不支持对其进行编码。
1.6 容器格式
如果你和大家一样，喜欢在自己的电脑上查找不同类型的媒体文件，你可能会注意到以各种扩展名结尾的文件，比如.mov、.m4v、.mpg和.m4a等等。虽然我们通常将这些类型都认为是文件格式，但其正确定义应该是这些类型都是文件的容器格式（container format）。
容器可是被认为是元文件格式。从更高的角度看，可将容器格式视为包含一种或更多种媒体类型（以及描述其内容的元数据）的目录。比如QuickTime文件可以包含多种不同的媒体类型，包括视频、音频、字母和章节信息等，并且包含用于描述每个媒体片段细节的元数据。
每个格式都有一个规范用于确定文件的结构。所谓的结构并不仅是其包含的媒体资源技术领域的问题，比如媒体的周期、编码和时间信息，一般来说还定义了描述性原数据，比如电影标题或一首歌曲的作者信息等。这些元数据可以通过工具进行呈现，比如常见的iTunes或iOS的Music应用程序，而且AV Foundation还提供了相关的类用于在开发者的应用程序内读取或写入该类型的数据。
当开发者使用AV Foundation拽写代码时，将遇到两类主要的容器格式，它们分别为：QuickTime和MPEG-4
QuickTime：是苹果公司再更宏观QuickTime架构中定义的最常见格式。其具有非常高的可靠性并且是一种有着非常清晰定义的格式，被专业领域人士和普通消费者广泛使用。
MPEG-4：MPEG-4 Part14规范定义MPEG-4(MP4)容器格式。这是从QuickTime规范中直接派生出来的一种行业标准格式，所以这两个规范在结构和功能方面非常类似。MP4容器格式的官方文件扩展名是.mp4，但有很多不同的变化扩展名也在使用，尤其是在苹果系统生态环境中。这些变化的文件扩展名仍展示用相同的基本MP4容器格式，他们通常用来区分一些特定的媒体类型，如m4a格式的音频文件，还可以使用这些扩展名来标示一些基本的MP4容器，如m4a格式的视频文件。
1.7 初始 AV Foundation
现在你应该对AV Foundation有了比较深入的了解，并且对数字媒体的细节也有了一定认识，下面增添一些有趣的东西。
Mac OS X一直都有一个NSSpeechSynthesizer类，使用这个类可以很方便地在Cocoa应用中添加“文本转语音”功能。开发者可使用AV Foundation中的AVSpeechSynthesizer类向iOS应用中添加类似功能。这个类用于播放一个或多个语音内容，这些语音内容都是名为AVSpeechUtterance的类的实例。如果你希望播放语句“Hello World”，具体代码如下：
接下来是书中第一个小项目的核心代码：
1.8 小结
常规操作，略了。。。
1.9 挑战
打开AV Foundation的API文档，利用一些时间浏览一下全部文档的内容，对其中所涉及的类的逻辑关系进行了解，同事对整个框架中所使用的命名约定有所了解。这样做可以让你开始了解框架所提供的功能范围，并且使你更好地熟悉框架使用过程中的编码模式和约定。
