概要

2017年的WWDC，苹果给大家带来新的视频、图像格式，对苹果、对业界将产生深远影响
我们分四个主题介绍这个Session：

Media today
HEVC
HEIF
Ecosystem adoption and best practices

简介

Media today

应用越来越多以视频和图片形式
高清视频的需求日益增加：4K high FPS Video，HDR Video，Wide Color Video
媒体生态变化（社交媒体、动态照片、短视频）
受限的网络带宽，唯一能做的就是减少带宽需求
H.264/JPEG对于这些新的需求有天花板

HEVC (High Efficiency Video Coding)

2013 年被 ITU-T 一个标准化认证机构通过
被ISO/IEC认可，命名为MPEG-H Part2
被ITU-T命名为H.265

名字说明：不同标准化机构叫法不同，但都是同一个东西，就像H.264又叫 AVC (Advanced Video Coding)，苹果叫他HEVC(High Efficiency Video Coding)。

视频编码原理101

在介绍HEVC的性能提升点之前，先给大家简单介绍一下视频编码原理，否则容易晕车

编码原理101：

数据压缩是通过去除数据中的冗余信息而达成。就视频数据而言，数据中的冗余信息可以分成四类：

时间上的冗余信息（temporal redundancy）
在视频数据中，相邻的帧（frame）与帧之间通常有很强的关连性，这样的关连性即为时间上的冗余信息。
空间上的冗余信息（spatial redundancy）
在同一张帧之中，相邻的像素之间通常有很强的关连性，这样的关连性即为空间上的冗余信息。
统计上的冗余信息（statistical redundancy）
统计上的冗余信息指的是欲编码的符号（symbol）的概率分布是不均匀（non-uniform）的。
感知上的冗余信息（perceptual redundancy）
感知上的冗余信息是指在人在观看视频时，人眼无法察觉的信息。

上图为一个典型的视频编码器。在进行当前信号编码时，编码器首先会产生对当前信号做预测的信号，称作预测信号（predicted signal），预测的方式可以是时间上的预测（inter prediction），亦即使用先前帧的信号做预测，或是空间上的预测（intra prediction），亦即使用同一张帧之中相邻像素的信号做预测。得到预测信号后，编码器会将当前信号与预测信号相减得到残余信号（residual signal），并只对残余信号进行编码，如此一来，可以去除一部分时间上或是空间上的冗余信息。接着，编码器并不会直接对残余信号进行编码，而是先将残余信号经过变换（通常为离散余弦变换）然后量化以进一步去除空间上和感知上的冗余信息。量化后得到的量化系数会再通过熵编码，去除统计上的冗余信息。
在解码端，通过类似的相反操作，可以得到重建的视频数据。

和H.264类似，HEVC用temporal[1] and spatial[2]的压缩算法达到最大压缩比，H.264用宏块(microblock)[3]来处理视频帧，H.265则用CTU(Coding Tree Unit)作为处理单元，编码树单元的大小可以从16x16到64x64，使用比H.264更大的处理单元CTU(coding tree unit)[4]得到更好的压缩效果。

名词释义：

[1]temporal:时间上的冗余信息（temporal redundancy）在视频数据中，相邻的帧（frame）与帧之间通常有很强的关连性，这样的关连性即为时间上的冗余信息。
[2]spatial: 空间上的冗余信息（spatial redundancy),在同一张帧之中，相邻的像素之间通常有很强的关连性，这样的关连性即为空间上的冗余信息。
[3]microblock: 宏块（Macro Block）：H.264处理单元，一个编码图像首先要划分成多个块（4x4 像素）才能进行处理，显然宏块应该是整数个块组成，通常宏块大小为16x16个像素。宏块分为I、P、B宏块，I宏块只能利用当前片中已解码的像素作为参考进行帧内预测；P宏块可以利用前面已解码的图像作为参考图像进行帧内预测；B宏块则是利用前后向的参考图形进行帧内预测；
[4]CTU(coding tree unit):对于YUV=420格式的彩色视频：一个CTU由一个CTB of the luma samples 、2个CTBs of the choma samples和相关的语法元素组成。Luma CTB是一个2^N x 2^N的像素区域，而相应的Choma CTB是2^(N-1) x 2^(N-1)的像素区域，N的值在编码器中确定，并在SPS(sequence parameter set)中传输。N可选4，5，6，表示CTU的大小可取16、32、64。
CTU相当于H.264中的MarcoBlock划分图片的概念，是在编码过程中的独立编码单位，然后可以递归划分成CU（coding unit）。

前面的101是必要知识铺垫，下图是HEVC对比H.264各个方面的提升，演讲者只是几句话粗略的概括了这张图，但图中参数我会尽力拆开解释他的含义和原理，有些是自己的浅显概括，由于我们更多的偏向应用，由于HEVC涉及算法数以百计，没法一一深入；但为了避免从入门到放弃，我们先在脑中建立个大致的知识索引是个好的方式

参数具体的提升解释：

Coding Block：用更大更多样的编码单元是为了在预测信号这个阶段提高处理效率、提高压缩比，这一点尤其在高分辨率视频和图片更有效
Transform：H.264将当前信号与预测信号相减得到残余信号之后，会对残余信号进行变换（通常为离散余弦变换），且只有8x8、4x4两个大小，但HEVC不仅做离散余弦变换，还做离散正弦变换，并且和CodingBlock类似，大小支持到了32x32,使得处理高分辨率帧更有效率。
Intra Prediction Directional Modes:为了得到更好的帧内预测，HEVC提供的方向预测具有更高的精度,引入了更多的方向预测模式，HEVC中的帧内预测提供多达35个预测模式，H.264有9个。
Inter：想要实现更好的压缩率，就牵涉到帧间预测的运动估计，运动估计的基本思想是将图像序列的每一帧分成许多互不重叠的宏块，并认为宏块内所有象素的位移量都相同，然后对每个宏块到参考帧某一给定特定搜索范围内根据一定的匹配准则找出与当前块最相似的块，即匹配块，匹配块与当前块的相对位移即为运动矢量。视频压缩的时候，只需保存运动矢量和残差数据就可以完全恢复出当前块，得到运动矢量的过程被称为运动估计，通过运动估计可以去除帧间冗余度，使得视频传输的比特数大为减少。
在这个估算运动矢量的过程中，不一定总能正好精确到一个像素的边缘，这样会导致分区块编码的区块边界不连续，一般称为块效应（block artifacts）,那么当一个宏块相较前一帧对应块，没有正好移动5像素，可能移动了5.5或5.25像素，这时候运动估计算法应该提供更好的计算精度，HEVC有更高级的滤波算法能够处理这种情况
Loop filter: 基于宏块的H.264编码器视频在块边缘会明显看到不连续的边界，H.264采用环内滤波(去块效应滤波)来去块效应，HEVC也采用这种环路滤波，并且还采用了采样适应补偿滤波，带来更好的结果。

HEVC还有很多其他优化，但上面列出来的是比较重要的几个

下面我要说人话了，优化结果如何呢？

压缩率&视频质量的提升

一般场景下,压缩率相比H.264提升了了40%
在iOS摄像头采集情况下，压缩率两倍于H.264，苹果对他们摄像头采集也做了优化。换句话说，相同质量的视频，可以节省更多的存储，用更少的带宽传输；或者相同的存储或带宽，大幅度提升视频质量（清晰度）。

ProfileLevel

HEVC也一样支持Profile，支持Main, Main Still Picture, Main 10 Profile,这个Main 10 Profile可以使得编解码精确到10bit，这意味着你可以显示更多灰度和色彩信息，提高视频的整体质量，想大幅提升视频质量的厂商可以试试这个，但这里没提10-bit在iOS只有软编软解支持。
HEVC Codec Type是hvc1
HEVC编码的视频帧直接可以装进iOS原生支持的视频容器格式：.mov .mp4

HEVC优势：

1.整个产业和苹果支持
2.兼容现有的视频文件格式
3.高效的视频和图片编码格式，足以替代H.264和JPEG

注意第2条并不适用图片，于是苹果搞了个基于HEVC编码的图片文件格式，叫HEIF（High Efficiency Image File Format），读音是hif。

HEIF（High Efficiency Image File Format）

我们先列举这个新图片格式的重要需求：

HEVC编码支持
支持Alpha通道和Depth map即图像深度
支持动画（比如Live Photo）
支持序列帧图片（比如长曝光图片）
图片的分块独立加载的能力，随着图片越来越大，人们需要更快的预览，更快的处理效率，图片切割成更小的区块可以按需增量的加载，提升载入效率降低内存。
综合以上几点苹果选择HEIF（High Efficiency Image File Format），被ISO标准化组织在 2015年采纳，是基于ISO base的容器标准，支持单独的图片和序列图片，有着灵活的格式方便以后扩展到更多应用场景，HEIF一般用HEVC编码器做压缩编码，也允许使用其他编码格式。

HEIF压缩率提升

HEIF相较与JPEG的压缩率提升，相同质量的图片可以用JPEG一半的大小来存储：

HEIF Payload类型与扩展名

苹果支持的HEIF的payload类型和扩展名对照表：

下面从这三个方面聊聊怎么使用HEIF，

首先是Creation：

HEIF相比JPEG有更多的可配选项和扩展性

上图是HEIF的诸多特性：

HEIF是ISO base的多媒体文件格式
2倍于JPEG压缩率
Image Payload 是以HEVC编码的图片数据
为了快速增量地加载高分辨率内容，以512x512大小的Tile分区块编码
提供320x240大小的预览图，4倍于JPEG预览图的分辨率，却只有2倍的大小，因为预览图都是HEVC编码的图片。
支持和JPEG一样的Exif 元数据，便于兼容ImageIO
.heic(读音嘿克)成为iOS平台新的图片扩展名

HEIF图片的解码支持情况如下：

也就是说硬解最低配置是iPhone6s 或者iPad Pro，macOS对应最低配置是new macbook with touchbar，软解支持全平台

哪些地方支持HEIF呢？

ImageIO—supported image source 读写
Core Image—supported image source 处理
PhotoKit—image, resources, and edit 高层接口
Apple applications 系统应用支持

iPhone摄像头拍摄的HEVC视频格式就没有HEIF那么夸张了：

mov容器格式、输出文件扩展名.mov，这些都没变
Payload是HEVC编码的视频帧，两倍于之前压缩率
8-bit 和 10-bit编码支持，如果关注画面质量或者deep color,我们在macOS有非实时的10-bit软编码满足需求，

HEVC解码的最低配置，依旧是软解全平台通吃，硬解最低配需要iPhone6s或iPad Pro

哪些地方支持HEVC视频，没展开讲，后面有相关的session会讲的更详细

性能

下面说说“可播放”，可播放和可解码是有区别的，HEVC在所有iOS设备上都是可以被解码的，但好多iPhone设备配置过低，解码速度跟不上，说的可能是软解，只能支持导出和转码的工作流，无法应对实时传输的场景（比如直播），那么如何判断视频格式在一个设备上是否可流畅播放呢？AVFoundation有isPlayable来判断这个设备是否支持这个视频流畅播放，苹果所有系统都支持采集4K超清视频，但不是所有手机都可以流畅播放，比如iPhone5s，所以最好使用这个属性做判断，给用户最好的体验。

下面是如何在PhotoKit访问HEIF/HEVC内容，后续有详细的session专门讲，此处只是列出关键类

通过这些framework访问HEIF/HEVC是透明的，513 session会细讲

想要采集HEIF图片内容，手机最低配置是iPhone 7和iPhone 7 Plus，也就是说升级iOS11后，iPhone 7+设备会更省存储，照片视频平均省一半存储

如何创造HEIF内容呢：

ImageIO支持写HEIF图
AVFoundation capture API支持摄像头采集HEIF
除了bursts长曝光模式，所有拍照模式默认都输出HEIF，

HEVC视频编码最低配：8-bit视频硬件编码需要iPhone7+ ，10-bit视频软编码只支持mac，做音视频处理、直播的同学注意，HEVC/HEIF硬件编码器只支持A10处理器，甚至没有软件编码器，猜测可能是出于性能和功耗的考虑，这限制就有点大了，比如直播推流想改成HEVC，需要iPhone7+的支持才行，但也许我们多虑了，很可能天朝主播一天收入买个iPhone 7没问题。

在这些场景下使用，默认都输出HEVC movie

传输

从创建端创建的HEIF/HEVC有几种方式传输

Always transcode 总是转码
Capabilities exchange 编解码能力交换

第一种就是纯转码方案，用于没法判断所有接收设备的解码能力，甚至连server都不一定支持HEIF/HEVC的转码，这种情况就转成H.264/jpg来传输，比如发邮件的场景和通过share extension分享的场景

第二种是针对点对点的传输，可以在连接阶段交换编解码能力来决定是否转码，随着多数终端设备逐渐支持HEVC/HEIF，需要转码的场景会越来越少，这个方案目前在平台内适合P2P、AirDrop、也适用client/server结构，比如直播的Team可以尝试上行传输HEVC省带宽，Server/CDN转码H.264下发保证兼容性。