2023 年 10 月论文笔记

说是加入腾讯做云游戏，但是似乎一个月过去了暂且都没有等来信息，果然还是继续积累吧。

ZGaming - Zero-Latency 3D Cloud Gaming by Image Prediction

现在论文都直接吹零延迟的吗，不过如果说 Abstract 里面这句话是真的，那确实足够猛：

与现有方法相比，ZGaming 在提供相同视频质量时，将互动延迟从 23 毫秒减少到 0 毫秒，或者在保持互动延迟为 0 毫秒时，提高了 5.4 分贝的视频质量。

Introduction

先讲了一下云游戏对 MTP 延迟很敏感，然后提出本文的目标是实现零延迟的云游戏系统。有关其他工作的部分，本文首先指出了单纯在系统上做优化的方案终究会因为网络的存在而至少具有一个 RTT 的延迟，从而零延迟的系统必定一定程度上涉及到预测操作，其中一个著名的工作是动作预取。动作预取的工作原理是对所有的可能潜在动作，都在服务端渲染下一帧，然后将这些帧发送到客户端，客户端上一旦执行操作即可直接访问到动作结果帧。但是动作预取面临两个困难：

• 用户动作的随机性极高，很容易遭遇预测未命中的情况
• 商用云游戏大部分依然采用用户动作后再渲染的方案，工业界适配困难较大

如果难以直接修改当前的工作流水线，那么一种可能的方案为基于图像的预测，常用的方法就是 DIBR。在具有 DIBR 的系统中，当用户做出操作的时候，该系统会根据最近接收到的 RGBD（即 RGB 色彩以及深度信息）直接预测接下来的视频帧，用户在此基础上几乎感知不到任何延迟。

本文基于上述方法，希望进一步精细化图像预测，主要面临的挑战有：

• 预测图像中存在伪影，即像素缺失。例如出现了遮挡和视野外，此时由于缺失图像信息，无法准确预测该部分的像素信息导致缺失。目前已经有一部分针对伪影的解决方案
• DIBR 不能应用于预测动态对象，因为动态对象的运动几乎无法通过静态的像素信息观察到，从而 DIBR 很难给出合理的预测值
• 码率和网络的匹配问题（有点奇怪，为什么这里需要考虑 ABR 相关的问题）

ZGaming 的设计在于，首先通过 DIBR 预测出静态对象的图像，然后通过运动预测模型预测动态对象的图像（本文采用了 LSTM，我严格觉得 LSTM 做不了这种任务），最后将两者结合起来得到最终的预测图像。具体而言的工作：

• 基于质量的静态场景缓存。如果完全存储所有历史静态场景则很有可能导致巨大的开销，所以 ZGaming 采用了基于质量的缓存，即只缓存质量较高的静态场景，而质量较低的场景则直接丢弃
• 服务器辅助的 LSTM 预测。在服务器端部署 LSTM 以预测动态物体的运动趋势，并预取到客户端
• ABR。我不评价这一部分

Motivation

首先说了一下云游戏条件下互动延迟的要求极高，大概限制在 60 毫秒左右。然后介绍了一下 DIBR 能够通过预测静态场景的方式做到一定程度上的零延迟，并且在工程的角度上可以增量式地连接到现有系统而不需要调整当下的云游戏渲染管线。

但是 DIBR 是有缺陷的：

简而言之本文的解决方法为：

• 重用历史帧。本文的论据是大量的场景都有可能在历史场景中出现过，所以加大追溯历史的深度可以有效缓解空洞伪影（但是全新的场景怎么办呢）
• 利用 LSTM 预测动态对象的运动模式
• ABR？（为什么 DIBR 的优化策略里面有 ABR？）

Overview

总之就是上面三个部分一个对应一个模块，也就是说 ZGaming 包括一个场景缓存，一个动态物体 LSTM 模型，一个 ABR 算法。

Quality Driven 3D Block Cache

其认为，一般的缓存设计方法无法直接应用到云游戏之中，因为传统的全量缓存会占用巨大的内存空间。一种方法是一定程度上限制缓存条目的大小，并且设计有效的缓存替换策略保证高效利用有限的内存资源。在考虑缓存替换策略的时候有以下需要注意的点：

• 不同光照条件下，同样坐标处的材质并不能直接应用于恢复。这是显然的，阳光直射的墙壁图像显然无法直接应用于恢复夜晚墙壁的空洞
• 非缓存算法的竞争。事实上，缓存并非处处是最优方法，例如墙壁、地面等较为单调的场景中，一般的插值恢复法甚至会比缓存更好。这里本文认为优先执行历史缓存恢复是合理的，如果缓存内容依然无法完全填充空缺部分，那么再通过插值方法恢复
• 用户操作会使得缓存本身具有不均衡特性，部分场景明显会比其他场景有更高频的访问次数

本文采用的策略为，将每一帧分为 \(64 \times 64\) 的块，这样做可以避免全量缓存，并且可以避免重复场景的重复存储。对每一个块 \(b\)，定义其质量为 \(U_b\)，质量越高则越有可能被缓存。质量的计算方式为：

\[ U_b := \frac{1}{T_{\rm now} - t_b}\sum_{i = 1}^{N_b} ({\rm PSNR}_{b, i} - {\rm PSNR}_{b, i}') \]

这里 \(N_b\) 表示块 \(b\) 在缓存中被使用的次数，求和项中的 PSNR 的差表示的是第 \(i\) 次使用的时候相较于插值算法，用缓存修复所能得到的 PSNR 增益，之后使用块 \(b\) 在缓存中持续的时间 \(T_{\rm now} - t_b\) 归一化收益即可得到缓存块质量。可以注意到该函数的逻辑就是，单位时间内该缓存块相较于插值算法能够获得多高的额外收益。

在此基础上，缓存的替换策略为当存储满时交换出 30% 的缓存块，并且定期逐出质量为负数的块。这里的负数质量表示该块在缓存中的收益不如插值算法，所以应当逐出。

性能评价就不说了，基本就是形势大好。

Server Assisted LSTM Predicting Foreground

首先区分背景和前景，其实就是静态部分和动态部分。本文认为，即使某一些 NPC 在交互逻辑上不应该归类为背景，但是在渲染逻辑上其不会发生相对位置移动，所以应当归类为背景。在这一部分首先需要的是区分背景和前景，然后对前景进行预测。区分前景的逻辑就是将前一帧和后一帧对齐，比较是否发生了位置偏移，发生偏移则意味着是动态对象。

而为了预测动态物体的运动，这里使用了 LSTM。然而直接使用 LSTM 会遇到渲染帧模糊的问题，所以在 LSTM 后面本文加上了一个图像超分模块（RefSR）。

工程上，另外提到了一下 LSTM 是部署在服务端的，数据传输方面则把 LSTM 预测的动态部分作为高优先级数据附加上 FEC 传输到客户端，由客户端组装具体的帧。

Prediction Performance Driven Adaptive Bitrate

这一部分整体没看明白想要做什么，似乎是根据网络情况调节预测性能？然而云游戏里面考虑网络的话还是不太会单独拉出来一个 ABR？不是很懂，这样总觉得 ABR 很孤立。

Conclusion

感觉和吴成磊学长说的一样，这篇文章总体给的感觉是很割裂，有种头痛医头脚痛医脚的感觉。而且我觉得这篇文章的 LSTM 部分一言难尽，LSTM 本身的能力不好说能不能完成这类预测任务，而且使用历史帧填充未知空洞也显得很没有道理。

总之，从 idea 到 writing 来看都不是很适合借鉴学习。

Ekho - Synchronizing cloud gaming media across multiple endpoints

简而言之就是以往的工作都把云游戏简单化为视频画面的传输，而忽略了音频等多媒体的可能。多媒体事实上意味着需要做到媒体之间的同步，例如游戏画面需要与游戏音效同步。Ekho 则通过伪噪声的方式实现了多媒体之间的同步。

Introduction

简单来说，就是注意到现在常用的云游戏系统往往除了视频流之外还会有一个反馈流，这个反馈流一般作用于各种游戏配件，作用包括：

• 在多人语音游戏的条件下混合其他玩家的声音，并提供给专用的游戏耳机等
• 对玩家的操作给出触觉反馈，如手柄震动等

这里容易出现的问题在于，视频流和反馈流作用到不同的终端（一个是显示器一个是各种其他配件），这导致这两个流会使用不同的网络连接传输，从而两者之间的同步就成为了问题。

事实上，在有观众的游戏中，除了玩家本人的耳机会有一道音频流外，普通视频流中还会负载另一道音频流，这个音频流会对外播放给观众。这一道音频流播放之后还会被玩家耳机的麦克风捕捉。所以说云游戏除了多种流的同步问题外，还需要处理多道音频流之间的同步。

一般而言，流之间会产生 100 毫秒左右的流间延迟（Inter Stream Delay / ISD），具体取决于网络情况、终端类型、连接方式甚至玩家到屏幕的距离。但是总体而言，延迟的影响因素大概可以归纳为：

• 网络延迟。大概来说就是网络延迟是相当复杂的，首先多设备的网络接入点不一定一样（屏幕直接通过以太网连接到路由器而控制器通过 AP 连接到 WiFi 等）。其次，不同设备可能使用不同的网络协议（屏幕使用 WebRTC 而控制器使用 URCP 协议）。最后，互联网提供商可能对不同端口的流量做不同的优先级处理，这也可能导致网络延迟
• 设备播放延迟。音频和视频在不同的设备上有不同的缓存管理措施，不同的播放策略也可能导致数十毫秒的 ISD
• 声音传播延迟。玩家从屏幕和耳机接收到的声音的 ISD 和玩家到屏幕的距离有关（毕竟声速也不过 340 米每秒），这可能带来十毫秒左右的延迟

本文的目标是将 ISD 限制到 10 毫秒一下，考虑到 ISD 是波动的，所以需要在游戏进程中不断观测和动态调整来平稳 ISD。事实上，测量 ISD 就足够困难，主要挑战是：

• RTT 的测量本身会因为网络往返路径不同，测量值本身具有十几毫秒的误差
• 解码、播放、声音传播延迟等影响 ISD 的重要因素往往因为缺乏合适的 API 或者硬件而难以测量

以往的设备间同步有三种常见方案：

• 通过共享的网络组件建立专用链接完成时间同步。然而云游戏系统并不强制要求各个终端共享网络组件
• 通过网络时间协议同步时间。然而该协议往往测量不精准，甚至会有百毫秒的误差
• 通过记录设备播放的声音测量误差。然而这对硬件要求较高，此外还要求周围环境噪声较低

而本文提出 Ekho，其可以在亚毫秒级别测量 ISD 并且做出调节。简要而言，Ekho 通过伪噪声序列的方式对齐各种流，并且在服务端根据测量结果调整发送序列来同步各种流。

Related Work

相关工作曾经研究过两路相似音频最大能够达到多大错位而不被用户感知，以前的研究结果认为单调、突发的信号音在错位超过 5 毫秒时就会被感知，而复杂语音则需要达到 16 毫秒左右才会感知。本文拓展了这些工作，并且通过数据论述了：

• 音频之间的错位最大为 10 毫秒
• 视频与音频之间的错位，最多允许音频提前视频 15 毫秒或视频提前音频 45 毫秒
• 触觉反馈与音频之间错位最大为 24 毫秒
• 触觉反馈与视频之间错位可以宽容到 30 至 100 毫秒

另外一部分的相关工作为媒体同步，指的是在一定范围的终端内同步媒体内容。现有的工作往往要求了下述前提（然后本文基于此做了点优化）：

• 设备有准确的时钟。然而用于同步设备时钟的网络时间协议具有不可容忍的误差
• 支持 PTP 的设备可以通过连接到同一路由器实现同步。然而 PTP 并非广泛采用的协议
• 利用这些设备往往物理距离较近的特征，通过在一个设备上记录另一个设备声音的方式实现流之间的延迟测量。然而由于环境噪声、硬件设备等问题，这一方案在先前工作中没有获得很好的效果，而本文基于此，做出了一步重要的拓展（伪噪声打点）

Background & Motivation

Time Synchronization Requirements

为了研究音频之间的错位阈值，这一章设计了用户实验。用户实验的基本方案是 ITU-T P.808 标准中规定的 DCR 测试方法。测试中使用的音频为 30 个长度为 15 秒的游戏录音，每个录音均加上了 0 到 300 毫秒不等的 ISD。

测试流程就直接翻译原文了。

人类测试者首先听取没有回声的参考音频片段，然后听取带有未知延迟量的回声的相同片段，包括 0 毫秒，即没有回声。测试者需要选择由于回声引起的注意力分散程度。此外，每个测试者会定期进行训练，即按照 P.808 标准听取带有不同回声量的六个片段，以确保标准化。

我们总共收集了 3555 个评分，根据 ITU-T P.808 的规定，去除了低质量的回应（总数据的 33%）。每个片段被评分约 10 次，每个延迟级别有 30 个不同的片段，共计每个延迟级别约 296 个投票。受访者池由 17% 的年轻人（18-25 岁）、43% 的成年人（26-35 岁）、32% 的中年人（36-50 岁）和 8% 的老年人（51 岁及以上）组成，他们的母语是英语。按照伦理准则，调查是匿名的，我们在参与之前告知受访者有关调查过程和刺激类型。我们对受访者进行了补偿，并避免了可能被认为是令人不悦的刺激。Microsoft IRB 审查并批准了这项调查。

最后的具体结果事实上已经在先前提到了，即根据音频的不同类别，玩家的忍受阈值是不同的，但最后大体可以用 10 毫秒作为阈值。

首先需要学一下 ITU 用户测试到底是个什么标准。

其次的话，这篇文章的 user study 给的启示大概就是如果要设立对比或者是五分量表类似的测试的话，需要定期通过所谓的 training phase 来保证测试者没有被“带偏”。

如果说要测试云游戏条件下画面撕裂更为显著的话，其实也可以借鉴这种主观评分模式。不同的游戏，不同的撕裂程度（或者说不同幅度的 jitter？）之下受访者到底能够容忍多少。如果发现云游戏条件下测试者的评分有显著下降，应该能说明问题了？

以及最好能提供一些现有的解决方案，证明现在的方案还不够解决这一问题？

上述实验是音频和音频之间的错位，其余种类流之间的错位本文似乎没有展开说明。

Inter Stream Delay

这一部分主要是 ISD 的建模：

可以看到基本和 Introduction 中提出的一致，分为网络延迟、解码延迟、播放延迟、声音传播延迟。

网络延迟的测量也和先前一样，否定了 NTP 协议和对称 RTT 测量两种方案。解码延迟则理论可以测量（通过对目标设备和音频格式类型的仔细测量来分析这些延迟），然而受限于终端种类繁多，API 也不总是可用，这种测量几乎实际不可行。播放延迟则来源于硬件的 jitter buffer，这种延迟几乎无法测量。声音传播延迟自然因为硬件问题无法测量。

最终归纳为下表：

总而言之，目前的测量方法的误差都过大，根本无法做到从各个环节上把握 ISD，更不用谈以此为基础控制 ISD 了（这一部分就是用于说明问题的挑战性和本文方案的创新性的）。

ISD Variation

大概的意思是继续说现有方案解决不了问题，原因是 ISD 是动态的。简而言之，ISD 的组成成分中，包含了低概率发生的 IP 路径更改或者显卡调度更改导致的大幅度震荡，以及更常见的因为网络波动和 jitter buffer 耗尽导致的小幅度震荡。

也就是说，ISD 的校正需要尽快且足够频繁以应对这些变化。实践证明，Ekho 最多间隔 15 秒测量一次 ISD 足以应对这些震荡。

Ekho

Overview of ISD Measurement in Ekho

简而言之，Ekho 采用了端到端的测量方案，即忽略掉中途环节，直接在端侧考虑延迟：

这里两路音频指的是屏幕音频和耳机音频，由于屏幕音频最终会被耳机捕捉，所以可以在耳机中直接比较两路音频得到 ISD 的估算。

这一方案的问题在于，一般的游戏音频内部没有标志点，无法快速供算法分析捕捉。其次，屏幕音频在经过空气传播削弱之后，加上环境噪声，会导致两路音频更难对齐，这还没有考虑传输过程中两路音频均可能经过了有损压缩。

所以，一种简单的解决方案是在服务器端发送音频的时候，在其内部均匀地（实验中使用 1 秒作为间隔）插入伪噪声标记，这些标记会用来对齐两路音频。这种伪噪声标记需要精心设计，因为其不能影响到玩家正常游戏，需要尽力做到不可察觉。

Reliable Marker Detection in Ekho

这里就详细介绍了伪噪声序列的构造方式和检测方式。首先分析游戏音频的频谱特征，可以看到载波的频率基本都在 12 kHz 以上，而重要游戏信息内容基本都位于 6 kHz 以下，所以伪噪声的频率范围需要限制在 6-12 kHz 范围内。此外，由于可探测性取决于振幅，这里的目标是不断探测游戏本体音频的振幅并控制伪噪声标记振幅与其的比值尽可能恒定（游戏声音小标记振幅就小，反之亦然）。

假设 \(x[t]\) 是游戏音频，\(w[t]\) 为长度为 \(L\) 的伪噪声序列，那么最终的带标记音频序列 \(x_m[t]\) 为：

\[ \begin{aligned} x_m[t] &= x[t] + C\alpha_k w[t] \\ \alpha_k &= \gamma\alpha_{k - 1} + (1 - \gamma)\rho(x[(k - 1)T : kT]) \end{aligned} \]

参数 \(L\) 影响 ISD 测量的速度和最大可测量的 ISD，一般的话设置为 48000（对应一秒音频，说明生成频率为 21 MHz 左右）。\(\rho(x[(k - 1)T : kT])\) 则表示了在 \((k - 1)T\) 到 \(kT\) 范围内的游戏音频功率，实验中选择 \(T = 960\)，这是 48 kHz 下的 20 毫秒音频。

这个公式的原理在于每 20 毫秒通过功率测算调整混入比例 \(\alpha_k\)，而 \(\alpha_k\) 采用的软更新参数 \(\gamma\) 在实验中取 0.4。

在上述混入的基础上就可以介绍检测算法了，假设耳机的录音序列为 \(x_{\rm rec}[x]\)，我们计算其交叉相关 \(Z[t]\) 如下：

\[ Z[t] = \sum_{i = 1}^L x_{\rm rec}[t + i]w[i] \]

可以注意到这里不断让录音和标记信号对齐，当标记对齐的时候 \(Z[t]\) 应当在此处出现峰值。为了让峰值检测更为可靠，需要做下述归一化：

\[ Z^*[t] = \left|\frac{Z[t]}{\sqrt{\dfrac{1}{S}\sum_{i = 1}^S Z[t + i]^2}}\right| \]

通过归一化后的 \(Z^*[t]\) 会有比较好的包络线。实际测量中会使用 \(S\) 为 100 毫秒，这个参数的来源大致是游戏音效大约都持续 100 毫秒。

为了更好检测峰值，下一步需要具体计算包络线：

\[ R[t] = \begin{cases} |Z^*[t]| & R[t - 1] \leq |Z^*[t]| \\ \beta R[t - 1] & {\rm otherwise} \\ \end{cases} \]

原理是简单的，如果出现峰值则设定峰值，如果没有出现则按照等比数列衰减包络线。这样操作可以过滤掉除了峰值之外的大量无用数据。实验中 \(\beta = 0.99995\)。在上述计算的基础上，所有 \(R[t] > \theta = 5\) 的值都认为是一次峰值。

峰值更具体的计算为：

\[ P[t] = \begin{cases} R[t] & R[t \pm 1] < R[t], R[t] > \theta \\ 0 & {\rm otherwise} \\ \end{cases} \]

此时 \(P[t]\) 已经提取出了所有的峰值并且过滤掉了较低峰值。此外，由于峰值的间隔至少应当是 \(L\)（峰值间隔应当是伪噪声间隔，如果有较近的峰值应当是游戏本身的峰值，需要过滤），所以给出了下述进一步过滤：

\[ P^*[t] = \begin{cases} P[t] & P[t] = \max_{|j| < \delta}P[t + j] > 0, \max_{|j| < \delta}P[t + j + L] > 0 \\ 0 & {\rm otherwise} \\ \end{cases} \]

全检测流程如下：

ISD Estimation

由于 \(L\) 选择了一秒，所以这里假定 ISD 不会超越 500 毫秒。在此基础上，将过滤过后的屏幕音频和耳机音频做对比，将距离最小的两个峰值之差作为 ISD 的估计：

Ekho Delay Compensation

调节的方式很简单，就是塞零音频来强制同步（毕竟已经算出来 ISD 了），本文未来计划通过数据包丢失掩盖技术来做（毕竟插入零音频实在是有点粗暴），但是至少现在没做。

Design & Implementation

结构是这样的：

总体来说的话，终端设备基本上仅仅承担了录音的任务，所有的计算负载依然放在云端。云端估算 ISD 的时候依赖于终端传回的音频数据。

具体的实现这里就不涉及了。

Evaluation

评估的话大概包括如下部分：

1. Ekho 是否成功在端到端系统中同步音频流？
2. 什么样的标记音量足以准确估算 ISD，同时又不被人察觉？
3. 在标记辅助的 ISD 测量方面，Ekho 与先前的工作相比如何？
4. 当屏幕音频流静音时，Ekho 是否可以用于视频与音频的同步？

同步音频流的实验很简单，直接把 Ekho 开起来然后在每个终端开一个 log 来记录每一帧音频的播放时间，两个设备的时钟会在实验开始前同步：

总之可以看到 Ekho 将 ISD 控制在 10 毫秒内，而不用 Ekho 的时候几乎做不到压到 10 毫秒的可能。