“App与新一代网络”讲座
演讲者：普拉巴卡尔·拉卡拉 ，斯图尔特·柴歇尔
偏离绿色应答线条 这意味着我们将数据发送到 网络的速度快于数据从另一侧被输出 和被应答的数据 如果数据被输入的速度 快于被输出的速度
情况就会变得不一样 数据将会进入缓存网络缓存中的 旧数据将会增大 由于缓存数据量增大 意味着数据包发送与 接收端应答之间的往返延迟增大
当缓存数据量达到一定程度时 网关将无法缓存更多数据 将开始出现丢包现象
将会发生混乱而且是非常严重的混乱 因此数据包进入队列末尾的速度 将会快于数据包出列的速度 我们收到数据包但是会丢失它们 其他数据包也会被丢失 队列被清空一点 我们获得一个数据包接受它 在队列的末尾是一片混乱 它获得一个数据包就会丢失一个数据包
但是在队列前部 有200个数据包依次排列等待 它们需要有序地 经过10Mb瓶颈链路 不能有间隔不能发生问题 只有在整个队列的数据 发送完之后我们才会看到 反映在发送端选择性应答消息中的 接收端的数据包丢失情况 然后开始进行补包 因此这是严重的混乱现象
由于网络传输API的工作方式 数据必须依次传输
如果一个数据包丢挡住 其后抵达的所有数据包 在内核中将被延迟 直到间隙被填满 这是有道理的 很多人曾经建议使用无序传输方法 但是结果发现几乎所有APP都很难 使用无序数据 如果你要解码H.264视频 只获得数据帧而无法获得它们 所依赖的I-Frame将不会有意义 因此顺序数据传输确实是 APP所需的传输模式
顺序数据传输导致 我们看到这些长时间的空白期 在此期间没有数据传输 对于Apple TV 视频回放流程来说 这相当于一个无信号时间段 在此期间将接收不到数据 我们不想要视频卡住 因此所有流媒体视频 都需要一个回放缓冲区
较大的回放缓冲区意味着 当你观看流媒体视频时 你会看到不断旋转的图标提示正在缓冲 因为缓冲区还有填满 因此当长时间没有数据到达时 可能会始终显示这个图标
当丢失的数据包到达时 我们开始填满间隙 并且立即播放视频
这将会给网络接收线程带来额外的负担 它需要将CPU时间分配给 视频播放线程之外的其他线程 从而造成视频播放卡顿 这不是我们想要的
这种不均衡的网络数据传输 给Apple TV等设备 造成不佳的用户体验在我们努力降低 设备的成本时 这种长时间的数据空白期 相当于我们需要增大设备内存 来缓存更多数据 并且推迟视频开始时间和降低用户体验
这种传输不均衡现象 还会导致设备需要更快的CPU 从而抬升设备价格 因此对于流媒体视频来说 这种不均衡的传输是十分有害的
最后作为总结我希望你们 记住今天讲座的要点
即 你应该尽可能地 使用最高层次的网络API 这样你将能够获得 这些API所能提供的全部功能
你绝对必须在NAT64网络上 测试你的APP 幸运的是我们进行了大量的简化工作 你只需要点击“选项”就可以了
可靠的网络回退机制 能够让你的APP提供更好的用户体验
你需要做的是注意 “Better Route”通知 这样当Wi-Fi重新可用时 你可以返回到Wi-Fi连接
“显式拥塞通知” 是一项新的基本功能
它通过降低队列等待和减少丢包 大幅提高网络数据传输的响应速度 我希望你们测试这些功能 并且报告任何问题
利用 CPNOTSENT-LOWAT选项 你可以为自己设置一个 socket选项 在下一个版本中你将可以免费使用它 从而大幅减少发送机中 缓存的迟滞数据量
深入了解HomeKit
演讲者：Keith Rauenbuehler 来自 HomeKit Engineering 团队
在iPad上进行桌面级浏览的介绍
演讲者：Charles Ying ，来自Safari WebKit团队的 Wenson Hsieh和Beth Dakin
我们认为可视化视窗API 是一个很棒的工具 可以充分利用iPad的大屏幕
让我们谈谈流媒体 在网页浏览器上提供 优质流媒体内容的用户们 很可能已经知道 最佳方式是HTTP Live Streaming 或简称为HLS
HLS在iPhone、iPad 和Mac上可用 它是一个疑难问题的简便方案 因为它替你分担了全部繁冗的工作 它可以和CDN一起使用 并且你会免费获得一些东西 比如AirPlay整合
然而有些电脑版内容使用了 Media Source Extensions 或简称为MSE MSE是一个可以让视频供应商 精确控制所提供给用户的 数据的API 比如你可以手动提升或降低视频品质 从而响应带宽变更 如果你当前有内容使用了MSE 我有一个好消息给你 iPadOS中MSE在iPad上 的电脑版网站上首次可用
如果你当前的引擎 针对电脑版网站使用了MSE 它在iPad上也没问题 并且如果你使用实施了MSE引擎的 JavaScript库 那也没问题
因为有了HLS和MSE两个选项 流媒体在iPad的Safari中 变得比以前更强大了
隐私保护方面的新功能
演讲者： Privacy Engineering 部门的 Justin ，欢迎收看
“What’s new in Privacy
以前使用这些协议流媒体时 App 需要获得访问本地网络的许可 通常还需要蓝牙 这个许可是需要的 因为管理设备选择 需要了解所有的设备 但这提供了超出必要范围的信息 并带来了设备指纹的风险 媒体设备发现可让您的 App 流传输到选定的设备 而无需显示网络或蓝牙访问提示 流媒体设备与 AirPlay 显示在 同一个选择器中 而App 只能看到 被选中的流传输到的设备 这要得益于 DeviceDiscovery 扩展
这个扩展可以搜索本地网络 和蓝牙设备 但是沙盒独立于 App 因此无法将扫描结果发回 这意味着 App 访问本地网络 或蓝牙不需要广泛的权限 因为 App 不能看到整个网络 相反 扩展只能将发现的附件 发送到 DeviceDiscoveryExtension 框架 DeviceDiscoveryExtension 框架 在选择器中显示发现的设备列表 做出选择后 系统启用与所选设备的通信 不需要其他权限
协议提供商应使用 DeviceDiscoveryExtension 来创建 App 扩展 扩展 AVRoutePickerView 以处理用户选择回调 处理您的协议中用户选择的网络设备 下载示例扩展和 App 来了解更多信息 App 开发人员应联系 他们的流协议提供商 以实现 DeviceDiscoveryExtension 媒体设备发现是构建 具有极大隐私性的 出色功能的机会 您的 App 可以准确访问 流式传输需要的数据 发现简单且无需提示 用户还能获得良好的网络隐私 各方都能受益 就像媒体设备发现提供 在没有提示的情况下 仅访问所需设备的权限一样 PHPicker API 提供了 只访问所需照片的权限而没有提示 PHPicker 现在在带有 macOS Ventura 的 Mac 以及带有 watchOS 9 的手表上 更新您的 Mac 和 Watch App 以访问照片 而不提示用户 访问所有照片
Web开发者的创新
您可以使用媒体查询来检测高动态范围显示支持。在CSS中，您可以像这样查询动态范围高的支持。或者，您可以在JavaScript中使用windows matchMedia方法，这样您就可以通过HDR显示器向用户提供逐步增强的内容。继续视频更新WebKit增加了对远程播放API的支持。我们以前一直有一个用于进行AirPlay的API，但远程播放API是一种基于标准的方式，可以将音频或视频的远程播放添加到自定义的基于网络的媒体播放器中，并将其发送到各种其他远程播放设备，如连接的电视、纯音频扬声器和任何支持AirPlay的设备。要使用它，您将在视频播放器控件上设置一个自定义按钮，并响应用户交互调用视频元素远程提示方法。然后，您可以在回调处理程序中处理远程播放状态的更新。真的那么简单。然后在您的设备上，用户可以点击控件以获取可用远程播放设备的菜单。选择后，视频将发送到该设备。支持远程播放API使您的用户能够灵活地在所有设备上欣赏媒体。另一种帮助用户享受媒体的方法是画中画API。
针对隔空播放2视频的HLS创作
演讲者： Eryk Vershen ，是HLS Streaming 团队的一名工程师 我们来聊一下 AirPlay 2 Video的HLS Authoring
自从我们在iOS上 引入隔空播放功能以来 用户们都喜欢在Apple TV 使用隔空播放视频 今年年初 我们大幅度地提升了在TV 直接使用隔空播放功能的支持
Apple TV和AirPlay capable TV 都能回放高质量的视频 你可能记得我们有 一些特殊的要求 关于投影到tvOS和 Apple TV的内容 AirPlay capable TV 是一类新的设备 所以这类设备有属于 它们自己的要求标准
接下来会有一个简单议程 我会说明新的要求标准 以及我们对验证工具 做出的修改 来帮您排查问题
我们最近发布了 一个新的HLS编写规范 关于对AirPlay 2 额外的要求标准
这是一个简练的列表 您无需现在就全部 了解整个清单 我将在一个演示文档中 详细说明每一条改动 我们来看一下细节
你需要同步 不同的视频类型 这能让转换容易点 如果彩色方块在时间线上 代表不同的视频类型 我们要做的是 将它们排列整齐 推荐你使用 毫秒级精度以上的标准 以及你的视频片段应该以 IDR帧来开始
你也要避免 不连续的变化 比如 不要在 HEVC和H.264以及 AAC和Dolby Digital 之间切换 因为这些格式不能在iOS 和Apple TV无缝转换 你可以小心地调整帧率 不要在 每秒25帧和30帧之间转换
如果你要每个编解码器都能 很好地支持每种格式 而这些视频格式使用的 一直是最开始的编解码器 所以 特别是 不要只在低分辨率视频 中使用H.264 在高分辨率视频中只使用HEVC 虽然在其他设备上起作用 但这里不行 你应该使用 I-frame方差 它们让快进 倒带 查询更有效率 因为此类设备 不太会切换编解码器 你需要使用一系列I-frame方差 来适配一般视频的编解码器
下面是关于编码的要求 并不只针对AirPlay 2 但我们要了解这些要求
一般的加密标准 推荐使用10%部分加密 我们需要使用FairPlay 其他的编码可能无法工作
对于样本加密 有两种方法 CMAF使用了一个senc box ISO则基于媒体格式 使用一对saio box和saiz box 我们推荐第二种方式 但你可以使用两者
最后 我们讲下其他要求 如果你要使用HDR内容 最好的方式是 提供多种格式类型 比如Dolby Vision和HDR 10 因为TV可能只支持 其中一种格式
使用WebVTT添加字幕 所有网络内容 我们都推荐 都使用MIME格式 下面我们来讲下具体 细节
我们使用MIME格式 发送HLS播放列表很长时间了 关于视频和音频的 MIME格式推荐 可能是你想要了解的 请留意 对于WebVTT 我们使用text/plain 尽管WebVTT文档 推荐text/VTT格式 然而text VTT格式 并不是由IANA注册 也可能不被一些客户端兼容 所以要使用text/plain格式
下面是 一些不太常用的MIME类型清单 清单的最后两个 不被AirPlay 2兼容 在这里列出 是因为我们推荐MIME格式 包括所有网站内容 而不仅仅是AirPlay 2
现在我们来看看 如何检测你的流媒体
我们记得有两个 工具来验证HLS 这些工具各有所长 Mediastreamvalidator 的特色是检测HLS是否符合标准 HLSreport则是 检测是否符合编写规范标准 你应该要始终使用这两个工具 我建议你写个脚本 使用这两个工具一并测试
至于HLSreport 我们做了重要的修改 以前你需要使用“-os”选项 测试多次 如果你想要检查iOS和tvOS 的规则的话 现在 默认情况下 它可以检测所有的规则 包括AirPlay 2的规则 设置选项的规则 来修改你的检测的测试 但通常你们不必使用它 当OS选项还在工作时 你需要停止使用它
我们来看下HLSreport 变化后的输出
请留意标题栏 所有的规则标准都被检测过了
一部分规则现在则被 分类到各个规则集 我们有通用的要求说明 每个规则集有Must Fix 和Should Fix 两个分项
在输出的最底部 有iOS要求说明
请留意规则10 上面的最后一则通规 被标记为Should Fix 然而在AirPlay 2 相同的规则是Must Fix
如果某个部分或 子部分没有违规 该部分或 子部分会被放过 比如 针对AirPlay 2 这个流媒体没有Should Fix
最需要留意的是 针对AirPlay 2的设备 我们添加了新的需求说明 记得使用HLSreport 这样你就可以 检测是否符合编写规范标准 HLSreport现在 可以检测默认设置中的所有规则
以上就是演讲507的所有内容 如你想要了解更多信息 你可通过链接 查看编写规范 以及工具 和HLS的其他信息 感谢聆听 祝你接下来的会议行程愉快