我们已注意到 Google 披露的 WebRTC 版本中存在的漏洞（更多信息请参见此处），并正在调查它对 EOS SDK 的影响以及接下来应采取的措施。
默认的像素流送配置平衡图像的质量、延迟和弹性，并假定其会用于互联网上，由用户在各种网络状态下使用。如果该假想与你计划的相同，那么你不需要要修改默认的像素流送配置。然而，像素流送是一种灵活的技术，可以在许多不同场景下使用。该指南介绍如何实现不同的质量、延迟和弹性，并且用示例说明有时优化图像质量、延迟或者弹性其中之一比平衡流送更重要。
WebRTC
对于像素流送中图像质量、延迟和弹性的平衡主要由一种叫做WebRTC的技术实现。WebRTC普遍用于视频会议和实时流送，比如Facebook Messenger、Discord、Amazon Chime以及 Google Stadia。WebRTC设计来达到低延迟、不受误差影响、支持多用户之间的多媒体和数据传输。
使用像素流送时，WebRTC参与者便是使用像素流送插件的虚幻引擎应用程序和一些支持WebRTC的客户端，比如网络浏览器。由于多种类的使用场景，WebRTC并没有模式或者预设的配置。相反，WebRTC会在面对不同网络状态和资源限制的情况下试图平衡质量、延迟和弹性。
然而，我们在像素流送中留出了一些参数来供用户按照自己的需求调整，并偏重图像质量、延迟和弹性其中之一。
请注意，如果偏重其中一项，那么另外两者便会受到影响。你需要自行决定这种牺牲对于你的使用场景能否接受。在接下里的小节中我们会介绍如何：
图像质量
视频流送的图像质量主要取决于虚幻引擎图象编码时应用多少压缩再由WebRTC输送。该压缩步骤由像素流送应用进行，默认完全由WebRTC控制。
WebRTC编码器码率适应
WebRTC会反复判断像素流送应用和WebRTC客户端之间可用的网络带宽，计算出适合的码率数值，然后用最新的预估码率更新视频流送编码器。之后视频流送编码器会将该码率作为一个最大值，并且生成码率不大于该数值的图像。
该系统在网络条件差的时候生成高度压缩的图像（成块像素化），网络条件能够支持高清视频流送时生成压缩较少的图像。也就是说，这个系统能够根据网络条件自行调整视频流送的压缩。
在不同网络状态下保留图像质量
答案： 使用 -PixelStreamingEncoderMaxQP=N （N为1到51之间的整数，包括1和51）
接下来我们会介绍QP的含义并解释使用该参数所带来的牺牲。
归根结底，真正影响视频流送图像质量的因素只有视频流送编码器进行的压缩。任意帧上进行的压缩都可以由称为 "量化参数（quantization parameter）" (QP) 的标准来度量。 在像素流送中，我们使用的编码器QP范围为1 - 51 （包括1和51）：
- 1代表最佳质量/最少的压缩编码。
- 51代表最差质量/最多的压缩编码。
默认情况下我们不限制该QP范围，也就意味着视频流送编码器可以自行根据WebRTC提供的目标码率自行选择QP。然而，在一些情况下我们的应用不能产生质量较差的图像（比如奢侈品产品配置器），那么我们需要限制编码器能够使用的QP范围。
如果MaxQP受到限制，导致码率超过了网络条件能够接受的程度，或者超过了 -PixelStreamingWebRTCMaxBitrate，那么流送的帧率会下降并移除一些帧。
像素流送视频编码器QP可以作为启动参数使用：
-PixelStreamingEncoderMinQP=-PixelStreamingEncoderMaxQP=
通常情况下，要限制图像质量只需要调整MaxQP这一个参数。要找到适用于你的应用的MaxQP，需要进行一些试验，因为这取决于你的应用场景能够接受多少压缩（尤其是在带有动作的情况下）。然而，根据我们的经验，如果要限制图像压缩，大部分用户能够接受MaxQP数值20。
已经传输的码率和QP可以用像素流送包含的页面内 settings"/"stats panel 进行追踪，也可以使用基于Chromium的浏览器中的 chrome://webrtc-internals 或者Firefox内的 about:webrtc。
以下图片展示了QP对于图像质量和码率的影响：
QP对于图像质量和码率的影响
请注意，QP和码率之间呈对数相关，意味着改变QP，比如从4到5，会比从20到21对码率产生更大的改变。
延迟
像素流送中的延迟由多个因素影响，其中一些是你能够控制的，另外一些却不能。虽然你无法控制终端用户的设备硬件、公共互联网、或者光的传播速度，但是还有一些可以控制的因素可以用于影响像素流送的延迟。接下来我们会重点介绍这些因素。
达到最低的延迟
要达到最低的延迟，你需要调整以下因素，但是请注意，一些调整可能会影响流送质量和弹性。
| 延迟因素 | 指南 |
|---|---|
| 选用的视频编码器。 | 不要使用实验性的VP8/VP9基于软件的编码器，它们会比硬件加速的H.264编码器带来更多的延迟。 |
| 应用程序的地理位置。 | 将像素流送应用部署在离目标用户尽量接近的地理位置。可能会需要在多个地区进行部署。 |
| 应用程序主机的硬件。 | 我们推荐使用支持硬件加速H.264编码的GPU。除此以外，我们还建议在目标CPU上调试你的应用，确保使用率不达到100%，否则会暂停WebRTC传输线程。 |
| 最大码率和分辨率。 | 减少分辨率和最大码率能够减少数据传输和编码复杂度，这样会让编码、 封包和解码更快。这种减少延迟的方式通常不值得其带来的质量上的牺牲。 |
| 音画同步。 | 如果你能够接受音画不同步，那么你可以通过 -PixelStreamingWebRTCDisableAudioSync 改善延迟，这会将音频和视频用分别的流进行传输。 |
| 禁用音频。 | 如果你不需要音频，可以禁用其传输来节约带宽，使用 -PixelStreamingWebRTCDisableReceiveAudio 和 -PixelStreamingWebRTCDisableTransmitAudio。 |
| 禁用动态模糊或者减少场景复杂度。 | 禁用动态模糊或者其它任何增加视觉复杂度的特效，都能够在一些场景中显著减少编码复杂度，从而达到更低的码率。 |
通常情况下，地理位置和像素流送应用与用户之间的网络状况是影响延迟的最大因素。
弹性
在这里弹性是指流送在出现丢包、网络波动和数据出错的情况时的稳定性。WebRTC本身已经带有一些动态调节机制用于管理流送弹性。举个例子，WebRTC可以增加其 "抖动缓冲（jitter buffer）" 大小，用于储存接收到的包体来补偿网络延时和重新传输，这样做的代价是会增加延迟。虽然抖动缓冲不能直接控制，但是我们可以在视频流送编码过程中控制其它的因数来通过数据重复来增加流送的弹性。
让流送在较差的网络状态下保持弹性
通过调节以下各项，可以增加像素流送中的视频流送弹性：
| 弹性因素 | 指南 |
|---|---|
| 编码器关键帧区间 | 发送关键帧可以让流送和解码器在发生严重数据丢失时进行恢复。区间关键帧可以用 -PixelStreaming.Encoder.KeyframeInterval 来控制。 请注意，关键帧比普通的帧占用更多的带宽，所以如果由于网络饱和而导致丢包，增加更多的关键帧可能没有效果。 |
| 编码器帧间刷新 | 视频流送恢复信息可以编码到在多个帧片段上。该信息会在数据丢失时使流送更加有弹性；然而，这样做会让整个流送占用更多的带宽并且在流送恢复的时候产生scanline类型的附加产物。 请注意，该选项目前只在英伟达GPU上可用，可以通过使用 -NVENCIntraRefreshPeriodFrames=N 和 -NVENCIntraRefreshCountFrames=M （N是每次发送帧间刷新间隔的帧数，M是每次编码帧间刷新数据间隔的帧数） 来在像素流送中启用。 |
通常情况下，流送弹性最容易受网络质量和传输的数据量所影响。所以，如果你的像素流送应用能够接受较低的质量来达到较高的弹性，那么通过不限制QP或者缩小应用分辨率来减少所传输的数据量也是可行的选项。
为像素流送优化你的应用
以下是我们对于为像素流送优化应用的额外建议：
-
向场景中应用胶片颗粒后效，能够大幅减少色带产物；然而，这样会增加带宽占用。
-
如果你能够接受更多的延迟并且像素流送应用不计划支持多用户像素流送，那么你可以尝试使用实验性的VP8/VP9软件编码器，使用
-PixelStreamingEncoder=。该编码器在同样的码率下能够比H.264生成质量更好的编码。 - 如果想要让多个像素流送应用在一个GPU上运行（多租户技术），你需要仔细配置优化你的应用，否则将会面临更低的帧率/分辨率。
- 如果你想要在云端成规模地运行你的应用，针对Linux构建你的虚幻应用能够更加简单并且成本较低，因为Linux有着更多诸如Kubernetes这类技术的支持。