HTTP Live Streaming 改进

（HTTP实时流媒体中的改进）

嘿 你们好！ 嗨 大家好 下午好 欢迎参加今年的演讲 看看那些HLS家伙们 最近一直在搞什么鬼 尽管幻灯片上放不下 你们很可能 会得到你们要得到的东西

我是Roger Pantos 我是你们今晚的演讲人 我们将会谈到一大堆内容 我们有一些很有意思的新编解码器 我们有一些新流媒体功能 我们还对API做了一些改进 但首先我们要宣布一件事 我很高兴地宣布 IETF已经批准将HLS规范 作为因特网草案发布

那么这意味着当前在网站上发布的草案 也就是-23 将进入IETF发布过程 一旦通过 它将会被分配一个RFC编号 我们大约在过去的8年 或9年里一直在更新草案 有一点儿问题 好的 嗯 为什么是现在？ 为什么要发布RFC？ 其中一个原因是我们 从某些人中听到了一些反馈 他们说写规范有点儿恐怖 需要一直修改草稿 我们听到了这个反馈 我们非常理解 那么把规范发布为RFC 将允许它作为一个稳定的引用 意思是你可以满怀信心地 在它上边进行创建 你可以在其它规范中引用它 我们希望它可以帮助 稍微改善一下 行业某些区域中的某些事

现在我们会停止更新HLS吗？ 不 当然不会 我们会继续衍变它

我们会让它变得更好 为用户打造越来越棒的流媒体体验 从我们今天要讲的东西开始 那么我们的实现方式是 引入一个新的因特网草案 将会建在即将出现的RFC上作为基准 并关注它

好的 现在让我们来看本次演讲的 第二个大新闻 就是HEVC 你应该从主题演讲和其它地方 听到了Apple选择了HEVC 作为我们的下一代视频编解码器 现在我们为什么这么做？ 一个词就是效率 首先是编码效率

HEVC大约比AVC的效率高40% 我的意思是它取决于你的内容 和你的编码器性能 但40%是一个不错的大概估计 对于我们中 那些通过网络搬运媒体的人来说 这很令人激动 因为首先它意味着你的用户即将看到 启动速度快了40% 品质优良 当播放器随着时间的流逝 适应了它的方式 你会发现内容比原来提升了40% 这对于我们来说很重要 HEVC很棒 你能从哪儿得到它？

嗯 正如我们所说过的 我们正在扩大HEVC的可用范围 其实在我们最新设备上 装有A9 和更高版本芯片的 最新iOS设备上以及 我们最新一代的Macintosh 我们都支持把HEVC嵌入硬件 那就包含了 对FairPlay流媒体的支持

即便是在较老的设备上 没有那种硬件支持的设备 我们仍然要部署一个 软件HEVC编解码器 那将用于装有iOS 11的 全部iOS设备上 那包括装有tvOS 11 的Apple TV 升级到High Sierra 的Macintosh HEVC即将出现在许多不同的地方 我们希望你们能使用它

为了配合HLS使用它 你需要记住几个要点 第一是HEVC代表全新的内容编码 意思就是 好的一面是没有任何兼容版本的负担 所以我们决定 是时候把我们的注意力重新聚焦在 单一容器格式上来了 我们查看了可选方案并决定 碎片式的MPEG-4最有潜力 那意味着如果你要把你的HEVC内容 部署为HLS 它需要被打包为MP4碎片

现在另一件不错的事就是让编码过程 更确切地说是加密过程变得稍微 简单点了

因为我们老朋友cbcs模式的常见加密 处理HEVC的方式 与处理H.264的方式一样 所以没有什么新规则 你只需要做同样的事 来处理你的HEVC位流就可以了

有了新的编解码器 你就可以把它部署 到一个其中某些设备 不支持HEVC的生态系统中 所以你把你的位流 标记为HEVC非常关键 从而使不支持HEVC的设备绕开它 实现方式是 当然了在HLS中 是在你的主播放列表中有编解码器属性

我这里有一个HEVC的编解码器 参数的例子 它比H.264稍微复杂点 它包含了更多的东西 但没有那么糟糕 整个格式都在HEVC规范中有记录

那么说到H.264格式的老客户端 很自然地有一个兼容性的问题… 首先你能把单一资产部署 到老的和新的客户端吗？答案是是的

我们继续

你可以在同一个主播放列表中 混合HEVC和H.264变量 那将会适用于常规的视频方差 以及I-frame方差 你也可以有这些的 HEVC和H.264版本 正如我所说 你的确需要将HEVC 打包为MPEG-4碎片 但对于落后的兼容性H.264 可以是TransForce帧 或碎片式MPEG-4格式 随你选择

标注媒体播放列表 变得更加关键和重要了 从而让我们了解什么是什么

最后我们实际上更新了 如果你们还不知道的话 我们有一个文档叫作HLS编写指南 是Apple TV 及其内容的最佳范例 我认为我们修改了名称 但无论怎样都没什么关系 因为实际上今天就有一场演讲 叫作HLS编写更新 我们更新了HEVC的内容 那么现在的编写指南 有了针对HEVC的额外注意事项 以及推荐位速率层的初始设置 让你们大家能使用它 那么请参看那场演讲 我听说那场演讲的演讲者做得很棒

接下来

我们有了一个新的字母格式 叫作IMSC 现在你们中有很多人 还没有听说过IMSC 在消费者中 它目前还不像VTT那么有名

但它应该是一种更有名的格式的孙子 叫作时序文本标记语言或TTML TTML非常有表现力 但不怎么是轻量级的编辑语言 主要用作字幕编辑 用于夹层和互换之类的 那么时序文本工作组所做的工作 就是精简了TTML 稍微改进了它 从而通过因特网 给消费者提交常规字幕 那么这就叫作IMSC

现在我们也接纳VTT 那么很明显就提出了这个问题 IMSC有什么不一样？ 主要不同点就是IMSC 比VTT有更好的支持、 更广泛的样式控件 VTT只有一些基本的样式控件 然后其余的部分就依赖于CSS

IMSC有更多自带的样式功能组合 主要用于你对字幕的样式处理 因此它获得了一定量的关注 尤其是在广播行业 甚至去年被选为MPEG 公共媒体应用格式的基准格式 我们去年就跟你们提到过

那么我们在iOS 11和其它 各种发布中所做的是 我们延伸了 IMSC的第一代底层实施 已经是你们的囊中之物了 我们期待继续精炼它 那么… …对于HEVC 你需要了解几点关于IMSC的要点 从而可以与HLS一起使用 第一点是它是如何打包的 与VTT不同 VTT的片段就是小文本文件

IMSC的传输 在MPEG-4第30章有定义 从根本上来说 它实质上 是MPEG-4碎片内的XML文本 它利用了MPEG-4的全部定时设施 我说是文本 因为IMSC实际上 定义了两个配置文件 一个图像配置文件和一个文本配置文件 我们的客户端 仅支持IMSC的文本配置文件

所以当你标注你的播放列表时 你应该这样做 因为你同样面临着 老客户端不能识别IMSC的问题 你希望给IMSC添加编解码器标签 并且我在这里也提供了一个例子 就是stpp.TTML.im1t 它本质上是在表达 我的播放列表中有遵循 IMSC1文本配置文件的字幕

我几乎是同时谈了IMSC和HEVC 我只想强调它们并没有关联 你可以单独使用它们 你可以结合使用HEVC和VTT 你可结合使用IMSC和H.264 你可以将它们全部结合在一起使用

并且你甚至可以有一个VTT 和IMSC的单一播放列表 较新的客户端可受益于IMSC的样式 而较老的客户端可以继续使用VTT 让我们看一个播放列表 并演示给你们看具体的效果 我这里有一个主播放列表的碎片 上边几行你们应该非常熟悉 那是主播放列表的样子 如果你有一个 叫作bipbop gear1的 视频变量并且它含有基于VTT的字幕 接下来的几行标签有同样的视频层 但位于其编解码器属性中 你可以看到它被标记为IMSC 那么前边几行 将会拉动VTT.m3u8播放列表 后边几行会拉动IMSC 如果客户端可以识别的话 如果我们深入去看这两个媒体播放列表 它们实际上非常相似

正如你所期待的 你可以看到VTT 只是一个.VTT片段的列表 而IMSC也是一种 在本例中是一种MP4片段 因为有MPEG-4片段 它也标记了这些碎片 因为这是碎片式MPEG-4所要求的 就是我们要能指向电影盒子 那么除此之外 它们非常相似 那么IMSC和VTT非常相似 它们实现的是同样的功能

我为什么要为IMSC 切换我的HLS流媒体？ 嗯 你可能会切换你的流媒体 如果 首先是如果你想控制更多的样式 并且你的播放设备中 没有完整的CSS解析器 那么IMSC就变得很有吸引力了

第二个原因是你可能 已经以TTML编写了字幕 或者也许你从服务供应商那儿获得了 其中一种格式的字幕 你可能发现转换TTML的IMSC 比转换为VTT更简单 也许精确度也更高 因为它们是非常相似的格式 那么另一个原因也是最终的原因 即你可能发现自己不管怎样 正在创建IMSC1流媒体 我们之前提到CMAF要求 在CMAF演示中使用IMSC字幕 并且如果你发现自己想要利用 那么多我们希望CMAF 可以生产的可兼容设备 那么你最终将采纳IMSC1流媒体 并且你也许…

抱歉 你可能会…

…抛弃VTT流媒体 那将会简化你的工具链 和你的生产流程 那么…

…现在说了这么多 也许哪个也不适合你 在这种情况下 坚持VTT是一个不错的选择 它仍会继续存在 事实上 也许你主要面向的是北美市场 在这种情况下608也没问题 它哪儿也不去 那么我们有了不同的选择

现在我提到很多次IMSC1 可能会有一个疑问一直存在 即是否有IMSC2？ 答案是也许吧 还没有最终确定 实际上仍在进展中 但时序文本工作组计划 定义一个IMSC2 我们关注的其中一个功能是 一些更沉默的控件 特别针对某些高级日语塑型功能 比如“shatai”和 “tatsuyoko” 那么简而言之IMSC2 我们希望在它接下来的几年里 能取得进展 那么请大家关注它

好的 那么这就是编解码器相关的内容 现在让我们谈谈流媒体功能 首先我想谈一下我们希望能让 那些长期忍受折磨的人们在生产 实时流媒体方面变得稍微简单点儿 帮助他们维护强健的体验 因为HLS播放器通常很不错 当一切都在后台运行良好时 但当在后台发生问题时 客户端实际上可以做得更好 帮助疏通流程 让我来演示给你看 那么在这里我们有 我猜在这里 我们有典型的实时HLS播放列表 目标时长为10秒 片段是 你知道的 10秒左右 10秒之后你可能想重新加载它 底部是FileSequence12 但出现了FileSequence13 10秒之后你再次重新加载 出现了FileSequence14 当然了它们的出现并不是什么魔法 你已经有了某种编码器 正在咀嚼媒体资源 每隔10秒钟它就会在CEN中 写入一个新片段文件 如果…会怎么样呢 …不管什么原因编码器突然重启了？ 或者也许你用胳膊肘 或什么敲了微波炉里的盘子 丢掉了媒体源 嗯 在这个HLS客户端之前没有获知 那种情况发生的方式 所以也没有什么方式来解决 但现在我们定义了一个新标签 叫作GAP标签 那么现在你可以在后台做的是 当你丢掉编码器或丢掉媒体源时 你的打包工具 可以继续写入片段 但不是写入媒体数据 它可以仅仅写入一个虚拟URL 并给其附加一个GAP标签 并且它可以继续这样做 直到那个流媒体的编码被禁用 那么10秒钟之后 你可能会获得 另一个片段作为一个缺口 那么这就告诉播放器说流媒体仍然存在 它仍然在继续 它仍然在更新 但对于媒体数据来说并没有那么棒

一旦东西被重新存储 一旦你的编码器回来了 或你已经清理了你的微波炉盘子 或诸如此类 然后打包工具可以继续像以前一样 生产片段 那么对于客户端来说 GAP标签意味着什么？

它主要表达这里没有媒体数据 那么当然了 作为第一近似值 会下载它 因为并不是播放器不应该尝试 而更有意思的是一旦播放器 看到GAP标签出现 在媒体播放列表中 它可以离开并尝试寻找另一个 没有同样缺口的变量 因为你可能有多个冗余的编码器 生产不同的变量或冗余的变量 也许我们正在播放 2-megabit流媒体 且我们可能发现 当我们发现1-megabit流媒体 哦 它实际上没有缺口 那么我们只需要切换到它 我们可以通过 1-megabit流媒体播放 一旦我们完成对缺口的处理 我们切换回3-megabit流媒体 2-megabit流媒体都可以 用户甚至都感觉不到 那么…

…我们还有一种情况 就是你可能只有一个编码器 或如我所说的 你可能打破了你的媒体源 你可能没有用于整个缺口的媒体 并且在那种情况下 我们的播放器的行为是 我们将会处于实时流媒体情境中 并继续无声播放 直到媒体回来 然后我们可以恢复正常播放

现在新GAP标签和其它一些东西 在HLS规范的beta版本中有描述 我昨晚还在写 那么我认为我们今天会发布它 非常棒

我都等不及想看到它了

是的 好的 反馈当然是很受欢迎了

那么这是GAP标签 让我们谈谈另一个新功能 这也是用于后台的 我们所做的是我们支持 在m3u8播放列表中 简单的变量置换 为此我们借用了一点儿PHP语法

那么意思就是如果你看到一些 像那个突出显示的东西… …在播放列表中 它所表达的是 把那个用大括号括起来的东西 用变量值替换 变量名称就是文件名称 那么如果 变量值恰巧是foo 你最终会得到一个foo.ts字符串

现在

要定义这些东西 我们定义了一个新标签 非常简单 我稍后会向你们介绍 它要么在播放列表内定义一个变量 要么导入它 现在就是这里让事情变得有意思了 因为你记得我说过会让 创建流媒体的人们生活好过一点儿吧 那么是如何实现的呢？ 我的意思是 是的 你可以…如果你有… 大喇叭一样的URL 你可以使用变量 来让你的播放列表变短 但我的意思是已做得很好了 那么就不是…这有点儿…但是 有意思的是 当你可以在主播放列表中定义变量 并在媒体播放列表中使用它时 那允许你提前通过小占位符 来构建你的媒体播放列表 以一种有点儿像后期绑定的方式填充 当定义你的主播放列表时 那么比如说你可以 在你的媒体播放列表 或CDN中有一大堆变量引用 且你能生产自己的主播放列表 从你的应用中动态地生产 在那点上你就可以表明 “我希望我的变量像这样” 然后突然你CDN上的所有 媒体播放列表都将会利用它 那么让我们看看会是什么样子

这是主播放列表 这是个很简单的例子 我在这里有一个定义标签 我有两个属性 名称属性表明了变量名称是auth 它有一个值就是auth令牌的定义 你可以在主播放列表中的 许多地方使用这个 比如说 在这里的gear1中 我决定 把auth令牌附加给 第一个变量URL

但现在让我们想象一下 我们加载那个媒体播放列表 再一次 媒体播放列表可以有变量 就像猪播放列表一样 在本例中 我有一个路径 包含这个又大又长的路径 我不想重复输入这么一大长串 但第二个定义更有意思 在本例中 我们正在导入 我们在主播放列表中 定义的auth变量 并且我们正在把它应用到不同的地方 比如媒体播放列表中的这个URL 那么这就允许你 获得一种疏耦合效果 在你的主播放和媒体播放列表之间 我认为人们将会发现 它的很多有意思的用途

接下来 好的 那么我们谈了一些后台功能 让我们来谈一些你可以实际用来 提供引人注目的用户体验的东西 现在我是什么意思呢？嗯 比如说 如果你想让用户可以 当他们正在看比赛时 你希望他们可以看到一个摄像头 看到某人传球了 但同时又能看到守门员那儿的摄像头 他们也能从守门员的角度看比赛 或者如果你正在看比赛 并且你希望看到 哈密尔顿汽车里的摄像头 但你还想关注一下他后面的维特尔 那么在那种情况下 将这些功能合并起来的是 播放多个相互同步的 实时流媒体的功能 从而一个不会超过另一个

这是你的未来

那么为此 我们只要求你有一个 或多个实时流媒体 通过使用日期-时间标签来相互同步 从根本上说意思就是 你把日期放到播放列表中 日期就会在 全部播放列表中衍生或派生出来 来自一个公共时钟 一旦你完成了 然后你就可以创建 多个独立的AVPlayer 并且你可以开始第一个播放 然后开始同步开始第二个播放 通过使用 AVPlayer setRatetime atHostTime方法 现在我应该站出来说 AVPlayer中使用该方法会给你带来 严肃的AVFoundation街头信誉 因为它并不是世界上最简单的API

但是为了帮助你脱离困境 今年我们实际上有一些示例代码 是一款Apple TV应用 叫作SyncStartTV 我认为 我不能仅说 也许我可以展示一下 你们想看吗？ 是的 好了 让我们来实际看一下吧

我要切换到Apple TV 如果我还记得是哪台设备的话 我想应该是这台 我们有…我有我的小… 为了演示实施同步流媒体 我首先要生产一个实时流媒体组件 那么我要稍微谈一下 这里正在发生什么 我写了一个小应用… 把源从后面的摄像头取出来 进行剖析 实际上是为它服务 手机作为一个HLS流媒体 那么我有两个家伙 两台手机 两个都做同一件事 左边一台 右边一台 它们实际上已经联网了 并且它们用了一个时钟 是一个很漂亮的精确的时钟 是它们之间共享的时钟 那么它们正在做它们自己的事 那么让我开始我的…

我没有…

我没有权限来做一些更令人激动的事 所以让们来做这个吧 那么让我们看一下 我要启动我的…

这里正在发生一些事 让我们启动其中一个摄像头 事实上让我们把它们都放在这儿 你已经得到了… 右侧在线了

左侧也在线了 好的 那么…

好了

我的遥控也正确地定位了 好的 SyncStartTV 当你启动SyncStartTV时

它会给你机会选择左侧或右侧视频 让我们选择这家伙 弹出了一个Bonjour选择器 你可以在Bonjour中 看到我的两个流媒体 让我们从Stage Right开始 看看那正发生什么 那儿并没发生什么 让我们启动这家伙…

好的 现在选择左边的视频

并且

看一下

它们是同步的！

哦 天啊 等一下

好了

谢谢

我该如何返回幻灯片呢？好的 就这样

这对于各个年龄段的人来说 都很有趣 好的 那么我猜我正好 跳过了我的幻灯片 哦 嗯 关于这种演示 我想提到的一件事就是 你同时显示多个流媒体时 一定要谨慎地确保其中一个流媒体 不会占用你的全部带宽 而让另一个流媒体忍饥挨饿 那么通常你可以 通过给每个流媒体限流实现 为此 今年我们还要给你们提供 另一个工具 就是一个分辨率帽 那么本质上来说 正如它的名字所暗指的那样 它允许你以编程方式表达“你知道吗？ 我要在一个480p的 小窗口中显示这个 切换到1080p就毫无意义” 那么

当你有一个获取视频缩略图的应用 或多个流媒体或如此内容应用时 你不想深入查看 播放列表的血淋淋的细节 那么设置一个带宽帽 这是一个很方便的东西

有一种情况 当你设置最大分辨率时 实际上比任何东西都要更小… 比任何可用的层都要小 在那种情况下 我们只需要拾取最低的一个并播放 非常简单易用 如果你有一个播放项 你只需要把它的偏好 最大分辨率设置为CG大小 在几分钟之内就会起作用 两个 稍微有点儿上和下

好的 那么让我们谈谈其它东西 去年我们引入了HLS脱机支持 就是能下载你的HLS流媒体 并在其它地方播放 比如飞机上 当没有网络时 当我们谈到那个时 我们提到了 将来某一天我们会 在管理磁盘空间方面 起到一个更积极的角色 那时候说的那个将来就是现在 所以我想给你们介绍 在iOS 11中 我们的设置应用的新功能 这有一个部分 用户可以进入并查看 拥又脱机资产的全部应用 以及它们的使用占据了多少磁盘空间 并且用户可以选择删除它们 如果他们想释放磁盘空间的话 那么这对于你们这些家伙来说 意味着首先 现在的OS稍微能 离开并删除你的资产 当你的应用没在运行时 有多种不同的实现方式 用户可以自己决定实现 或我们会问用户是否可以删除 他们的某些内容 如果我们需要空间的话 比如像OS更新或之类的 那么在iOS 11中 我们引入了一个新API 允许你改变要删除哪些资产的选择 它叫作AVAssetDownload StorageManager 它的使用方式是你给你 磁盘上的每一个脱机资产 都创建一个政策 你通过管理工具设置它 现在 下载存储管理政策 有两个属性 失效日期和优先级 今天我们只需要定义两个优先级 分别是重要和默认 对于绝大多数人来说

你要做的是将用户 尚未观看的资产标记为重要 一旦我看了 就把它们切换回默认 失效日期属性 是为了防止你的资产在某一时刻 变得不再能被播放 比如你可能发现你处于这种情况下 某一个节目可能离开了你的目录 你不再有播放它的权限了 如果是这种情况 你可以设置失效日期 那么它会在删除队列中起作用

那么它的使用是非常简单直接的 DownloadStorageManager 是一个单元素集合 你可以获取它 创建一个新的可变政策 并设置属性 然后你就告诉存储管理工具 使用那个政策来处理AVAsset 在一个特别的文件URL 你稍后还可以返回并查看当前政策

那么这是按照你的方式进行的

关于脱机的另一件事是 我们从采用它的一些人那儿 得到了一些反馈 下载一个以上的表演时 比如 如果你想要英文音频 还想要西班牙语音频 也许比它预计的要难一点儿 首先如果你的应用受制于进入后台 并在半途中退出了 那么我很高兴地告诉你 在iOS 11中 我们引入了 一种新方式来分批处理你的脱机下载 它叫作AggregateAssetDownloadTask 它允许你 对于一个指定资产 表明一个像这样的媒体选择数组 然后当你踢开下载任务时 我们就开始执行 我们会下载每一个 我们会给你汇报进度 然后当整件事情完成时我们会通知你 希望它能让事情 变得稍微简单点了

谢谢

好的 今天我们要讲的另一部分内容 都与在你的设备上管理内容相关 这是一个非常复杂的话题 所以我要 把你们交给我们自己的 HLS钥匙专家Anil Katti 他会跟大家具体讲一下 谢谢大家

谢谢Roger 大家晚上好 欢迎参加WWDC

那么两年前我们引入了 FairPlay Streaming 一个概念保护技术 帮助保护你的HLS资产

自从这次引入之后 我们看到了明显的增长 FairPlay Streaming 用于生产 提交到我们平台上的高级内容 今天我很激动地宣布一些针对 FairPlay Streaming 钥匙提交过程的改进 那将允许你简化你的流程

熟练你的FairPlay Streaming采用技能 并支持新的内容生产功能

但在我们谈这些改进之前 我想先快速回顾一下 FairPlay Streaming

FairPlay Streaming 指定了如何提交 如何安全地提交内容解密钥匙 在FairPlay Streaming系统中 有三个主要元素 以媒体为中心的应用

就是拥有播放会话的应用 一方面有钥匙服务器 可以提供解密钥匙 而另一方面AVFoundation 为你提供内容的解密和播放支持

提交内容解密钥匙一共有五个步骤 那么这些步骤开始执行 是当用户浏览你的应用 尝试选择某个视频进行播放时 当用户这么做时 你的应用会创建一个资产 并且由AVFoundation决定播放

当AVFoundation 收到播放请求时 它就开始传递播放列表 当它看到内容是加密的时 就使用FairPlay Streaming提交钥匙 通过给你发送钥匙请求 向你的应用请求钥匙 通过委托回调

在那点上 你可以使用钥匙请求对象 创建一个服务器播放情境 或简称为SPC 它是一个加密的数据块 包含你的钥匙服务器所请求的信息 用以创建内容解密钥匙

然后你的应用把内容解密钥匙 发送给你的钥匙服务器 并从那儿获取内容钥匙情境 或简称为CKC

它是另一个包含解密钥匙的加密数据块

最后一步 你的应用提供CKC 作为对它最初接收到的钥匙 请求对象的一个响应

那么假如AVFoundation 已经加载了播放列表 并且现在媒体数据 拥有它用于解密内容 和开始播放的FairPlay Streaming钥匙

嗯 在某种意义上 FairPlay Streaming钥匙 类似于这些其它资源

并且事实上 如果你回顾一下 如果你今天使用 FairPlay Streaming提交钥匙 FairPlay Streaming钥匙 是通过AVAsset附件API提交的 与其它自定义资源相似

但差不多是时候 终结这种相似了 对吧？ FairPlay Streaming 钥匙是专用资源 定义有非常具体的操作 我现在要给你看一些例子

AVFoundation允许你释放 FairPlay Streaming钥匙 以便你可以把它们 保存在你的应用存储中并稍后使用 就像当用户尝试脱机播放内容时一样

你可能还会定义 FairPlay Streaming钥匙 在某时间段之后失效 钥匙必须得更新 在它们失效之前 以便继续解密

随着内容生产功能的持续衍变 FairPlay Streaming钥匙 将持续变得更具体 而钥匙提交过程也是

进一步说 FairPlay Streaming钥匙 不一定要与资产相关联 当加载时 那么我们认为通过去耦钥匙加载 从媒体加载中或甚至是播放 我们可以给你提供更多的灵活性 可以用来处理现有的一些难点 还可以提供更棒的用户体验

那么考虑到这一切 我们很高兴引入了一个新API 它将允许你更好地管理 和提交内容解密钥匙 AVContentKeySession简介

AVContentKeySession 是一个AVFoundation类 用于处理内容解密钥匙 它允许你从媒体加载中去耦钥匙加载 或甚至是播放 就此而言

它还给你提供了一个更好的控制 针对内容解密钥匙的生存周期

那么如果你回顾一下 你的应用只在收到来自 AVFoundation 的钥匙请求后才会加载钥匙

并且…但那个… 你可以通过AVContentKeySession 改变这种方式 通过AVContentKeySession 你可以决定何时加载钥匙 然而 如果你选择 在请求播放之前不加载钥匙 AVFoundation 将按需要给你发送钥匙请求 就像它今天做的这样

那么现在 我们给你提供了 两种触发钥匙加载过程的方式

你可以使用… 你的应用可以使用 AVContentKeySession 来明确启动钥匙加载过程 或AVFoundation按需要 启动钥匙加载过程 当它看到内容被加密时

那么让我们看看如何用 AVContentKeySession 启动钥匙加载过程 这对你们很有帮助 那么首先 今天我们要使用的钥匙 是关于开始播放的钥匙

钥匙加载时间对于 你的播放开始时间非常重要 因为应用通常当它们 收到按需钥匙请求时才会加载钥匙

你可以提升 你用户收到的播放开始体验 如果你可以加载钥匙 甚至在用户选择 要播放的内容之前加载

AVContentKeySession 就允许你这么做 你可以使用AVContentKeySession 启动钥匙加载过程 然后通过你得到的钥匙请求 在播放会话中独立加载钥匙

现在我们调用这个钥匙预加载

在钥匙加载完成之后 你可以请求播放 那么 在播放期间 你不必加载任何钥匙 并且播放…会立即开始解密

我今天要给大家展示的第二个用例 随着时间收到了越来越多的盛赞 它与实时播放有关

我们看到向我们平台上 提交的实时内容数量 有了显著增长 这都归因于用户在我们的设备上 获得的更拟真和更集成的体验

有更多的用户在我们的设备上关注 体育运动以及其它实时事件 开发人员也使用 更高级的内容生产功能 比如 钥匙旋转和钥匙更新 以添加额外的保护层 当提交附加实时内容时

由于实时流媒体的性质 你的钥匙服务器会同时遭受 上百万次钥匙请求的轰炸 当钥匙被旋转或更新时

嗯 你可以使用 AVContentKeySession来缓和这种情况 通过在起始点平衡加载钥匙请求

让我通过一个简单的图例 解释一下要如何实现

请考虑这么一个情境 上百万个用户 正在观看一个很受欢迎的实时流媒体 比如Apple的Keynote演讲

他们开始观看的时间点可能都不一样 但当需要升级或更新钥匙时 他们都会在完全一样的时间点 向你的钥匙服务器发送请求 那代表了短时间内 钥匙服务器上会有巨大的负载 然后一切都回归正常 直到下一次再升级或更新钥匙 对吧？ 那么这种模式会持续 给你的钥匙服务器带来输入负载

你可以使用AVContentKeySession 来分散钥匙请求 通过在一个小的时间窗口内 选择一个随机点 当钥匙失效之前 并启动钥匙加载自己

那么这就允许你调整你的实时供应 而不用给社交安全钥匙服务器增加负载

那么现在我们看了一些用例 证明通过AVContentKeySession 启动钥匙加载过程是很有帮助的 让我们来看看如何在代码中实现

你可以启动钥匙加载过程 仅通过三行代码 就那么简单 就在这里

那么你要做的第一件事 就是为FairPlay Streaming 创建AVContentKeySession实例

然后把你的应用设为 contentKeySession代理

你应该会在你在这里 指定的委托队列上收到全部委托回调

第三步是调用 processContentKeyRequest方法 那将启动钥匙加载过程

那么在这里需要注意几点

要使用这个功能不需要对你的钥匙 或你的钥匙服务器模块 实施进行任何修改

这是…这里的全部实施都是在客户端上 这很棒

第二

你在这里指定的标识符

应该与你在媒体播放列表中的 EXT-X-KEY标签中 指定的标识符相匹配 那将允许我们匹配 你在这里加载的钥匙 和你在播放过程中所请求的钥匙

第三

你应该有一个带外的过程 从钥匙服务器上获取特别资产的钥匙 以便你可以在这点上加载全部钥匙

当你在AVContentKeySession上 调用processContentKeyRequest方法时 我们给你发送一个 AVContentKey请求对象 通过一个委托回调 并且这与 当AVFoundation启动 钥匙加载过程时的委托方法一模一样

那么现在你可以使用钥匙请求对象 来执行FairPlay Streamings 全部的指定操作 比如 你可以请求SPC 这与你通过AVAsset 钥匙排序请求 来请求SPC的方式非常相似

然后你要把SPC发送到你的 钥匙服务器 获取CKC

最后一步是用CKC创建响应对象 并把它设为 对ContentKeyRequest对象的响应

那么当你响应钥匙请求时 你必须记住几点

一旦你将CKC设为对钥匙请求的响应

你就可以在设备上 使用一个安全解密slot 这些slot的数量有限

那么为任意数量的钥匙启动 钥匙加载过程都没问题 并且你可以还可以为全部 不同的钥匙请求获取CKC 但一定要小心最后一步

你应该只在那些你预测 可能在播放过程中 用的钥匙上设置CKC 而且要恰好在请求播放之前进行

那么以此为背景 让我们 改变一下方式 了解一下我们如何 在脱机HLS播放情境中 使用AVContentKeySession

去年当我们修改 FairPlay Streaming来保护 你的脱机HLS资产时 也引入了持久钥匙

AVContentKeySession 也可以用于创建持久钥匙

在请求加载HLS资产之前 你可以使用AVContentKeySession 来启动钥匙加载过程 并使用钥匙请求对象来创建持久钥匙

然后你可以把持久钥匙保存到你的应用 存储中以备将来的不时之需

然后这将会让你的流程 稍微变得简单点儿 因为现在你不必 在你的主播放列表中 定义EXT-X会话钥匙以及等等 你只需要使用 AVContentKeySession即可

更进一步 当创建和使用持久钥匙时 你应该也使用 AVContentKeyRequest的子类 即AVPersistableContentKeyRequest 我要在代码中解释一下如何请求 和AVPersistableContentKeyRequest 以及工作…以及如何使用 AVPersistableContentKeyRequest

那么如果你回顾一下 这是当你启动 钥匙加载过程时调用的那个委托方法

在这点上 如果你尝试创建一个持久钥匙 你应该只响应钥匙请求并请求 PersistableContentKeyRequest 我们将给你发送 AVPersistableContentKeyRequest对象 通过一个新委托回调

你可以使用 AVPersistableContentKeyRequest 来执行FairPlay Streaming的全部操作 比如创建SPC 把SPC发送到你的钥匙服务器 获取CKC并使用CKC 创建一个持久钥匙 你可把持久钥匙 保存在你的应用存储中 以便你可以稍后当用户脱机时使用它

当是时候使用持久钥匙时 你所要做的就是通过持久钥匙 数据块创建一个响应对象 并将其设为ContentKeyRequest 对象上的一个响应

就是这样

如果你今天使用 FairPlay Streaming 来提交钥匙 你可以观察到 AVContentKeySession与 你今天用过的AVAssetResourceLoader API的工作方式相似

我们没用AVAssetResourceLoading请求 而是用了AVContentKeyRequest

AVAsset 恰好位于委托调用分离的地方 它叫作AVContentKeySession委托

然而 这是一个关键的不同点 与AVAssetResourceLoader不同 AVContentKeySession 创建时并没有绑定 一个资产

所以你可以在任意一点上创建 AVContentKeySession 并用它加载全部钥匙 就在你请求播放之前 你应该添加你的AVAsset 作为内容钥匙接收器 这将允许你的AVAsset获取 你通过ContentKeySession 对象预加载的全部钥匙

现在我们有两个API AVContentKeySession 和AVAssetResourceLoader 你可能会在想应该用哪个API 来加载资源的不同类型 那么我们有一个建议 使用AVContentKeySession 来加载内容解密钥匙 使用AVAssetResourceLoader 来加载其它东西 我必须指出我们并没有 在这一点上复制AVAssetResource Loader的钥匙处理方式 所以你可以继续使用 AVAssetResourceLoader 来加载FairPlay Streaming钥匙 就像你今天所做的一样 但我们强烈建议你切换为 AVContentKeySession 来执行

那么谁负责 加载解密钥匙呢 如果某个资产 既有AVAssetResourceLoader委托 又有与之关联的 AVContentKeySession委托？

嗯 为了保持一致性 我们强制只使用 AVContentKeySession委托 加载全部内容解密钥匙

我们的AVAssetResourceLoader委托 会收到全部资源加载请求 包括那四个内容解密钥匙

应用应该推迟全部的内容解密钥匙加载 通过在加载请求上调用完成加载 AVFoundation可以再次允许 向AVContentKeySession委托发起请求 让我们在代码中看看是如何实现的 非常简单 那么这里有一个委托方法 当AVFoundation 尝试加载资源时调用 当你看到资源是用于内容解密钥匙时 你应该设置内容管道 表明它是一个内容钥匙 并调用完成加载 那么在那点上我们将向 AVContentKeySession委托发送 新的内容钥匙加载请求 如果是其它资源 你就可以继续在这里加载资源了

那么我希望这个新API 可以给你提供一些情境 关于通过AVContentKeySession 可以实现哪些功能

在我结束演讲之前 我还要跟你们分享一个很棒的功能 这可以通过 AVContentKeySession获得

我们为FairPlay Streaming持久钥匙 提供双重失效窗口支持 现在这个双重失效窗口是什么？

如果你曾经在iTunes上租过电影 你可以看到你有…一旦你租了一部电影 你有30天的时间来观看它 一旦你开始观看电影 你就有24小时的时间来看完它 我们把这个称为租赁的 双重失效窗口模式

那么这个功能可以允许你 定义和自定义 两个失效窗口 为FairPlay Streaming持久钥匙 那将允许你支持比如 租赁功能这样的功能项 通过…

而不需要在服务器端进行大量的编程 最棒的是它既可以在脱机播放时 使用又可以在在线播放时使用

那么为了使用这个功能 你首先要选择加入 通过在你的CKC中发送适当的描述符 那将允许你指定两个失效窗口 第一个叫作存储失效窗口 一旦创建持久钥匙即启动 然后还有一个播放失效窗口 当持久钥匙用于开始播放时启动

为了更好地描述这个功能 让我给你… 让我们一起看一个事件的时间轴 和脱机播放的情境

当用户 租了一部电影脱机播放时 你要创建一个带CKC的持久钥匙 选择加入使用这个功能

持久钥匙会在存储 失效窗口的末端失效 在我们的例子中是30天 （持久钥匙的双重失效窗口） 你可以把持久钥匙存在你应用的存储中 并可以用它来响应稍后的钥匙请求 现在当用户在这30天内返回来 并要求你开始播放时…要求你播放内容 你会得到一个钥匙请求 你可以用这个持久钥匙 来响应钥匙请求

在那点上 我们将给你发送一个 更新了的持久钥匙 这个更新了的持久钥匙 被设为在播放终点失效 在我们的例子中是24小时

同时我们还明确地 失效了你创建的原始持久钥匙 所以你要 在你的应用存储中保存 更新了的持久钥匙 并用它 响应将来的钥匙加载请求 这就是当用户停止并在 接下来的24小时内回复播放时

关于代码 这与我们 在前几张幻灯片中所看到的 持久钥匙的流程相似 然而我们将发送给你这个 新的更新了的持久钥匙 通过一个新的 AVContentKeySession委托回调

那么这是我们今年针对 FairPlay Streaming 钥匙提交过程所做出的全部改进

总之 我们引入了 两个新的编解码器 我们今年引入了 HEVC和IMSC1

我们添加了EXT-X-GAP标签 允许你在你的实时流媒体中表示缺口 现在你可以在你的HLS流媒体中定义 并使用PHP样式变量了

你现可同步两个或多个HLS流媒体

并且我们提供新API 以供你更好地控制脱机HLS资产

现在有一个新API AVContentKeySession允许你 更好地管理和提交内容解密钥匙

最后 我们给全部FairPlay Streaming 持久钥匙添加了双重失效窗口支持 那将会允许你支持脱机 HLS资产的租赁模式

我们做出了这么多的新功能 我们都感到非常激动 我们期待你们能采用它们

感谢你们来参加本场演讲 你可以在开发者网站上访问 我们的演讲页面获取更多信息 你还可以下载我们在本场演讲中 提到的全部实例代码

我们最近有许多相关的演讲 我强烈建议你们 观看错误处理最佳范例 和HLS编写更新演讲 这些有在线视频 并且你的WWDC应用中也有 如果你错过了其它现场演讲 你总是可以从你的WWDC应用中 观看它们的视频 脱机或在线看均可 非常感谢 希望你们在本周剩余大会中 度过一段美好时光 晚安