共计 5454 个字符，预计需要花费 14 分钟才能阅读完成。
本文依据 Peikang 在 WWDC 2021 分享翻译，演讲者 Peikang，来自 Video Coding 和 Processing 团队。译者陶金亮，网易云信资深音视频开发工程师，领有多年端侧音视频工作教训。
反对低提早编码已成为视频利用程序开发过程的一个重要方面，在低提早直播和 RTC 畛域有着宽泛的利用。本分享次要分享了 VideoToolbox（一个低级框架，提供对硬件编码器和解码器的间接拜访，它提供视频压缩和解压缩服务，以及存储在 CoreVideo 像素缓冲区中的光栅图像格式之间的转换）是如何反对低提早 H.264 硬件编码，以最大限度地缩小端到端提早并实现新的性能程度，最终实现最佳实时通信和高质量视频播放。
分享实录视频：https://developer.apple.com/videos/play/wwdc2021/10158
低提早编码对于许多视频利用十分重要，尤其是实时视频通信利用。在本次演讲中，我将在 VideoToolbox 中介绍一种新的编码模式，以实现低提早编码。这种新模式的指标是针对是实时视频通信利用优化现有的编码器流水线。那么实时视频通信利用须要什么？咱们须要最大限度地缩小通信中的端到端提早。
咱们冀望通过让视频应用程序与更多设施进行通信来加强互操作性。例如：当呼叫中有多个接收者时，编码器管道也应该是高效的，并且，该应用程序须要以最佳视觉品质来出现视频。那么，咱们须要一种牢靠的机制来从网络失落引入的谬误中复原通信。
我明天要讲的低提早视频编码将在这些方面进行优化。应用 低提早编码模式，咱们的实时应用程序能够达到新的性能程度。在本次演讲中，我将首先概述低提早视频编码。咱们能够对如何在管道中实现低提早有根本的理解。而后我将展现如何应用 VTCompressionSession API 来构建管道并应用低提早模式进行编码。最初，我将探讨咱们在低提早模式下引入的多个性能。
低提早视频编码
首先让我概述一下低提早视频编码。这是 Apple 平台上视频编码器管道的简图。VideoToolbox 将 CVImagebuffer 作为输出图像，它要求视频编码器执行 H.264 等压缩算法以缩小原始数据的大小。输入的压缩数据封装在 CMSampleBuffer 中，能够通过网络传输进行视频通信。从上图中咱们能够留神到，端到端提早可能受两个因素影响：解决工夫和网络传输工夫。
为了最大限度地缩小解决工夫，低提早模式打消了帧从新排序，遵循一进一出的编码模式。此外，该低提早编码模式下的速率控制器对网络变动的适应速度也更快 ，因而也能够最大限度缩小网络拥塞造成的提早。通过这两个优化，咱们曾经能够看到与默认模式相比，曾经有了显著的性能晋升。 对于 720p 30fps 的视频，低提早编码能够缩小高达 100 毫秒的提早。这种节俭对于视频会议至关重要。
通过这样的操作实现了缩小提早，咱们能够为视频会议和直播等实时通信实现更高效的编码管道。
此外，低提早模式始终应用硬件加速视频编码器以节俭电量。请留神，此模式反对的视频编解码器类型为 H.264，咱们将在 iOS 和 macOS 上引入此性能。
在 VideoToolbox 中应用低提早模式
接下来，我想谈谈如何在 VideoToolbox 中应用低提早模式。我将首先回顾 VTCompressionSession 的应用，而后向您展现启用低提早编码所需的步骤。
VTCompressionSession 的应用
当咱们应用 VTCompressionSession 时，首先要应用 VTCompressionSessionCreate API 创立会话。并通过 VTSessionSetProperty API 配置会话，例如指标比特率。如果未提供配置，编码器将以默认行为运行。
创立会话并正确配置后，咱们能够通过调用 VTCompressionSessionEncodeFrame 将 CVImageBuffer 传递给会话，同时能够从会话创立期间提供的输入处理程序中检索编码后果。
在压缩会话中启用低提早编码很容易，咱们惟一须要做的就是在会话创立过程中进行批改，如下文的代码：
- 首先，咱们须要一个用于编码器标准的 CFMutableDictionary，编码器标准用于指定会话必须应用的特定视频编码器。
- 而后咱们须要在 encoderSpecification 中设置 EnableLowLatencyRateControl 标记。
- 最初，咱们将此 encoderSpecification 赋予 VTCompressionSessionCreate，压缩会话就将在低提早模式下运行。
配置步骤和平常一样。例如，咱们能够应用 AverageBitRate 属性设置指标比特率。
好的，咱们曾经介绍了 Video Toolbox 低提早模式的基础知识。上面，我想持续介绍此模式中的新性能，它们能够进一步帮忙咱们开发实时视频应用程序。
VideoToolbox 低提早模式新性能
到目前为止，咱们曾经探讨了应用低提早模式的提早劣势，其余的益处能够通过我将要介绍的性能来实现。
第一个性能是新的 Profiles，咱们通过向管道增加两个新 Profiles来加强互操作性。也会聊聊 时域分层 SVC，此性能在视频会议中十分有用。也能够应用 最大帧量化参数 (Max QP) 对图像品质进行细粒度管制。最初，咱们心愿通过增加 长期参考 (LTR) 的反对来进步谬误恢复能力。
新的 Profiles 反对
让咱们谈谈新的 Profiles 反对。Profile 定义了一组解码器可能反对的编码算法，Profile 用于确定视频编码过程中帧间压缩应用的算法（例如是否蕴含 B 帧、CABAC 反对、色彩空间反对等），Profile 越高，就阐明采纳了越高级的压缩个性，对应的对编解码硬件的要求也越高。为了与接管方通信，编码比特流应合乎解码器反对的特定配置文件。
在 VideoToolbox 中，咱们反对一系列 profiles，例如 Baseline Profile、Main Profile 和 High Profile。明天，咱们为该系列增加了两个新 profiles：Constrained Baseline Profile (CBP) 和 Constrained High Profile (CHP)。
CBP 次要用于低成本利用，而 CHP 则具备更先进的算法以取得更好的压缩比。咱们能够先查看解码器性能以判断应该应用哪个 Profile。
想要应用 CBP，只需将 ProfileLevel 会话属性设置为 ContrainedBaseLine_AutoLevel。同样，咱们能够将 Profile 级别设置为 ContrainedHigh_AutoLevel 以应用 CHP。
时域分层 SVC
当初让咱们谈谈时域分层 SVC。咱们能够应用时域分层来进步多方视频通话的效率。
例如：一个简略的三方视频会议场景。在此模型中，接收器 A 的带宽较低，为 600kbps，而接收器 B 的带宽较高，为 1,000kbps。通常，发送端须要对两组码流进行编码，以满足每个接收端的上行带宽。这种做法可能不是最佳的。
该模型能够通过时域分层 SVC 来更加高效的实现，其中发送方只须要编码一个比特流，但最初能够比特流输入能够分为两层。
咱们来看看这个过程是如何工作的。这是一个编码视频帧序列，其中每一帧都应用前一帧作为预测参考。
咱们能够将一半的帧拉入另一层，咱们能够更改参考，以便只有原始层中的帧用于预测。原始层称为根底层，新构建的层称为加强层。加强层能够作为根底层的补充，以进步帧率。
对于接收器 A，咱们能够发送根底层帧，因为根底层自身曾经是可解码的。更重要的是，因为根底层只蕴含一半的帧，所以传输的数据速率会很低。
另一方面，接收器 B 能够享受更晦涩的视频，因为它有足够的带宽来接管根本层帧和加强层帧。
咱们来看看应用时域分层 SVC 编码的视频。我将播放两个视频，一个来自根底层，另一个来自根底层和加强层。根底层自身能够失常播放，但同时咱们可能会留神到视频不太晦涩。如果咱们播放第二个视频，咱们能够立刻看到差别。与左侧视频相比，右侧视频具备更高的帧速率，因为它同时蕴含根底层和加强层。
左侧视频具备 50% 的输出帧率，并应用 60% 的指标比特率。这两个视频只须要编码器一次编码一个比特流。当咱们进行多方视频会议时，这将更加节能。
时域分层的另一个益处是谬误恢复能力。咱们能够看到，加强层中的帧不用于预测，因而对这些帧没有依赖性。这意味着如果在网络传输过程中失落了一个或多个加强层帧，其余帧不会受到影响。这使得整个会话更加强壮。
启用时域分层的办法非常简单。咱们在低提早模式下创立了一个名为 BaseLayerFrameRateFraction 的新会话属性，只需将此属性设置为 0.5，这意味着一半的输出帧调配给根底层，其余调配给加强层。
咱们能够从示例缓冲区附件中查看图层信息。对于根底层帧，CMSampleAttachmentKey_ IsDependedOnByOthers 将为真，否则为假。
咱们还能够抉择为每一层设置指标比特率。请记住，咱们应用会话属性 AverageBitRate 来配置指标比特率。指标比特率配置实现后，咱们能够设置新的 BaseLayerBitRateFraction 属性来管制根底层所需的指标比特率百分比。如果未设置此属性，则将应用默认值 0.6。咱们倡议根底层比特率分数应在 0.6 到 0.8 的范畴内。
最大帧 QP
当初，让咱们看看最大帧量化参数或者说是最大帧 QP。帧 QP 用于调节图像品质和数据速率。
咱们能够应用低帧 QP 来生成高质量的图像。但在这种状况下，图像尺寸会很大。
另一方面，咱们能够应用高帧 QP 来生成低质量但尺寸较小的图像。
在低提早模式下，编码器应用图像复杂度、输出帧速率、视频静止等因素调整帧 QP，以在以后指标比特率束缚下产生最佳视觉品质。所以咱们激励依附编码器的默认行为来调整帧 QP。
然而在某些客户端对视频品质有特定要求的状况下，咱们能够管制编码器应用最大帧 QP。应用最大帧 QP 时，编码器将始终抉择小于此限度的帧 QP，因而客户端能够对图像品质进行细粒度的管制。
值得一提的是，即便指定了最大帧 QP，惯例速率管制依然无效。如果编码器达到最大帧 QP 下限但比特率估算用完，它将开始抛弃帧以放弃指标比特率。
应用此性能的一个示例是通过较差的网络传输屏幕内容视频。咱们能够通过就义帧速率来进行衡量，以发送清晰的屏幕内容图像，通过设置最大帧 QP 能够满足此要求。
咱们能够应用新的会话属性 MaxAllowedFrameQP 传递最大帧 QP。依据规范最大帧 QP 的值必须介于 1 到 51 之间。
长期参考帧（LTR）
说一下咱们在低提早模式下开发的最初一个性能，长期参考帧。长期参考帧即 LTR 可用于谬误复原。让咱们看一下这张图，其中显示了管道中的编码器、发送方客户端和接管方客户端。
假如视频通信通过一个连贯不良的网络，因为传输谬误，可能会产生帧失落。当接管方客户端检测到帧失落时，它能够申请刷新帧以重置会话。如果编码器收到申请，通常它会编码一个关键帧以用于刷新目标，但关键帧通常相当大。大的关键帧须要更长的工夫能力达到接收器。因为网络条件曾经很差，大帧可能会加剧网络拥塞问题。那么，咱们能够应用预测帧而不是关键帧进行刷新吗？答案是必定的，如果咱们有帧确认。让咱们来看看它是如何工作的。
首先，咱们须要决定确认的帧。咱们称这些帧为长期参考帧或 LTR，这是编码器的决定。当发送方客户端传输 LTR 帧时，还须要向接管方客户端申请确认。如果胜利接管到 LTR 帧，则须要返回确认。一旦发送方客户端取得确认并将该信息传递给编码器，编码器就晓得对方收到了哪些 LTR 帧。
再来看看网络不好的状况：当编码器收到刷新申请时，因为这次，编码器有一堆已确认的 LTR，它可能对从这些已确认的 LTR 中的一个预测的帧进行编码，以这种形式编码的帧称为 LTR-P。与关键帧相比，LTR-P 的编码帧大小通常要小得多，因而更容易传输。
当初，让咱们谈谈 LTR 的 API。请留神，帧确认须要由应用层解决，它能够通过 RTP 控制协议中的 RPSI 音讯等机制来实现。这里咱们只关注编码器和发送方客户端在这个过程中是如何通信的。启用低提早编码后，咱们能够通过设置 EnableLTR 会话属性来启用此性能。
当 LTR 帧被编码时，编码器将在示例附件 RequireLTRAcknowledgementToken 中用信号发送一个惟一的帧令牌。
发送方客户端负责通过 AcknowledgedLTRTokens 帧属性将确认的 LTR 帧报告给编码器。因为一次能够收到多个确认，咱们须要应用一个数组来存储这些帧标记。
咱们能够随时通过 ForceLTRRefresh 框架属性申请刷新框架。一旦编码器收到这个申请，一个 LTR-P 将被编码。如果没有已确认的 LTR 可用，在这种状况下，编码器将生成一个关键帧。
总结
以上就是本次 Peikang 在 WWDC 2021 大会上分享的全部内容译文，若有翻译不合理处，欢送斧正交换。
目前网易云信在客户端层面实现了软件编码的 SVC 和长期参考帧计划，同时服务器在转发下面也实现了 SVC 计划。SVC 提供了服务器一个额定的伎俩管制视频流的转发码率，再联合大小流和码率压抑，以及客户端上行的网络带宽探测和拥塞管制等伎俩，网易云信为了谋求极致的观看体验，一直的打磨产品，本次分享的内容，我置信不久就能够在云信的产品中失去很好的使用。
分享实录视频：https://developer.apple.com/v…
更多技术干货，欢送关注【网易智企技术 +】微信公众号
