动画编码格式（Quicktime Animation format）是苹果（Apple Inc.）公司在20世纪末（鬼知道到底是哪一年）推出的针对动画素材进行编码的编码格式。该编码格式主要使用步长压缩算法（run-length encoding）与条件补偿算法（conditional replenishment ）进行编码。
目前PR、AME与AE均支持使用Quicktime格式-动画编码器编码素材并以.MOV格式将其封装导出。
Premiere CC2018中的动画编码器
相比后期大神们常用的Avid公司推出的DNxHR系列编码格式、苹果公司推出的Prores系列编码格式以及Gopro公司并购的Gopro CineForm编码格式这样的中间编码格式，动画编码格式理论上更加适合作为板绘二维动画或MG动画素材的中间编码。 这是我在三连动画教学这期视屏中为大家分享的三连MG动画制作方式的成品截图：
这是我自己使用AI绘制、AE做动画创作的板绘二维动画作品截图：
这是我使用相机随便拍摄的一段画面截图：
可以明显看到在MG动画以及板绘动画中，画面中出现了大量的相同颜色色块。而实拍的画面即使看上去拥有有内味儿的“相同颜色色块”，但事实上，色块中的颜色只是色相、饱和度、明度都很接近的不同颜色们。
为什么要提这些色块呢？
这就要说说动画编码器所使用的步长压缩算法了。为了方便大家理解，这里我用一个简化的例子来解释压缩的逻辑，但实际情况往往更加复杂，幸好我不是程序员。简单地说，编码器会在每一帧将整个画面的像素分解为一排一排的像素。
随后将一排一排的像素逐个分解为长度不同的步格（runs），步格的长度以及所包含的颜色会根据前一帧的像素颜色以及这一帧的相同颜色色块分布情况决定。
对于每一个步格，编码器会选择这三种编码方式中的一种来将色彩信息编译为码流（Bitstream）：1.染上你的颜色（same color） 2.跳过此帧（skip） 3.PCM。
在染上你的颜色模式下，步格中的所有像素色彩信息会被步格中的一种色彩信息代替并在编译为码流时压缩为更短的“名字”来代表这个步格的色彩信息。如果步格中的颜色不同，则会造成有损压缩。
跳过此帧模式也就是条件补偿算法，这是一种帧间编码方式。将与前一帧颜色相同的步格直接按照前一帧的色彩情况编码。
PCM模式就硬编呗，对步格中的色彩信息不作任何压缩，直接编译为码流。
选择哪一种编码方式取决于编译结果的数据大小，算法会优先选择体积最小的编译方式，而在前两种方式都不适用的时候就会使用PCM编码方式。
了解这些以后，大家应该很容易理解，在视频中出现大面积相同颜色的色块且连续很多帧都不会发生变化时，比如最近流行的很多幽默小动画：
素材取自Up主：@阿幕降临
动画编码的压缩率会比较高，并且不会丢失太多细节，甚至在100%编码质量下可以做到无损。但是对于实拍的画面或者光影复杂的3D动画，画面中很少会出现这样大面积同色色块还连续多帧保持不变（由于实拍画面必然会因为传感器产生噪点，所以几乎不可能有大面积的同色色块），即使在无损模式下动画编码的压缩率也并不会比其他的中间编码高，并且由于条件补偿的算法逻辑 ，在编码质量较低时还会制造更多肉眼可见的噪点。
我自制了一个非常标准的简易MG小动画，大概是这样的：
一个五秒钟的简单MG小动画
随后我分别使用100%质量的动画编码、100%质量的CineForm编码以及100%质量的DNxHR编码来导出了视频文件，导出时间见下图。
动画编码器不出所料在面对这种大面积同色色块的情况时效率超高，不过CineForm速度居然领先DNxHR（无论是444还是HQ），这点还蛮让我惊讶的，看来CineForm的编码算法在应对这类素材时也有一定的优势。而对比生成文件的体积，动画编码器轻松取胜，甚至甩了DNxHR编码几条街。
值得一提的是，动画编码格式支持的采样深度可以高至32bit ARGB 4：4：4。在某些非动画情况下也是可以取代没有Alpha通道的DNxHR编码格式与最高16bit的Prores编码格式而作为中间编码格式的。况且100%压缩质量的动画编码格式是可以做到无损压缩的。
知道这些后，Prores和DNxHR望了望彼此，很有默契的退出了直播间。
在制作MG动画、板绘动画、简单3D动画时，使用动画编码格式作为中间编码格式。
在制作实拍视频、复杂3D动画时，使用Prores、DNxHR、CineForm作为中间编码格式。
