首先，说出症状
记录确切的消息或记下统计数据中上升计数器的名称。仅总体 CPU 利用率并不能解释所有问题。这样您就不必通过更改覆盖颜色来修复互联网。
| 症状 | 比较什么 |
|---|---|
| 播放和预览不均匀 | 计算机负载和游戏设置。 |
| 预览不错，编码问题 | 编码器统计数据和本地记录。 |
| 录音好，LIVE丢数据 | 平台发送和接收稳定。 |
| 只有部分观众有这个问题 | 播放质量、网络和接收设备。 |
一本没有困难缩写的词典
| 概念 | 这在实践中意味着什么？ |
|---|---|
| FPS | 每秒的图像帧数。更多帧需要适当的性能和传输设置。 |
| 比特率 | 随着时间的推移发送的图像或音频数据量。相对于链接而言过高的值可能会导致丢帧。 |
| 来源 | 一种场景组件：游戏、相机、文本、音频或带有叠加层的页面。来源的顺序决定了哪些内容涵盖哪些内容。 |
| 场景 | 现成的图像布局：例如使用相机或断线板的游戏。你选择的场景决定了你展示的内容。 |
| 分辨率 | 区域的宽度×高度，例如1920 × 1080。这与用鼠标缩小源矩形不同。 |
一步一步 · 1–4
- 操作步骤
请注意预览、文件或仅查看器播放器是否出现卡顿。
✓ 完成此步骤后您将看到您知道在哪个阶段寻找问题。
- 操作步骤
在视图或面板菜单中打开统计信息，具体取决于版本。
✓ 完成此步骤后您将看到您会看到不同类型的丢帧。
- 操作步骤
选择游戏中可重复的运动分钟。
✓ 完成此步骤后您将看到随后的试验具有类似的负载。
- 操作步骤
进行本地录制，无需流式传输。
✓ 完成此步骤后您将看到您将计算机与互联网分开。
放大截图 ↗一步一步 · 5–8
- 操作步骤
检查渲染延迟计数器。
✓ 完成此步骤后您将看到您认识到将场景组合在一起的问题。
- 操作步骤
限制游戏的 FPS 并重复相同的尝试。
✓ 完成此步骤后您将看到您可以评估 GPU 空间的影响。
- 操作步骤
在场景副本中，关闭不必要的重光源。
✓ 完成此步骤后您将看到您可以在不破坏原始图像的情况下检查图像合成的效果。
- 操作步骤
检查单独的编码延迟计数器。
✓ 完成此步骤后您将看到您不会将编码器与网络连接混淆。
放大截图 ↗一步一步 · 9–12
- 操作步骤
测试可用的要求较低的预设或硬件编码器。
✓ 完成此步骤后您将看到您正在比较一项更改的结果。
- 操作步骤
对于网络损失，请检查上传利用率。
✓ 完成此步骤后您将看到下载速度并不能取代上传测量。
- 操作步骤
停止大量上传并比较有线连接（如果可用）。
✓ 完成此步骤后您将看到您知道本地网络是否重要吗？
- 操作步骤
测试与您的平台兼容的较低比特率。
✓ 完成此步骤后您将看到您检查恒定数据流的稳定性。
放大截图 ↗一步一步 · 13–14
- 操作步骤
比较第二个接收设备。
✓ 完成此步骤后您将看到一位观众的失败并不被视为所有人的失败。
- 操作步骤
记录结果，然后再更改下一步。
✓ 完成此步骤后您将看到您能指出什么真正有帮助吗？
您可以重现的示例
尝试 A：同一游戏 60 秒，没有 FPS 限制。尝试B：相同的场景，但游戏FPS有限。渲染帧数下降表明 GPU 空间有所改善。这项测试本身并没有说明互联网质量的改变。
构建简短、可重复的测试
在进行重大更改之前保留场景集合或配置文件的副本。在安静的桌面上尝试不会重现要求较高的游戏、许多动画和嘈杂的聊天。该测试应类似于您实际驾驶 LIVE 的方式。
- 设置一个具有相同图像、麦克风和运动片段的场景。
- 尝试几分钟并保存您的分辨率、帧速率和编码设置。
- 选择一个可疑项目并将其禁用以进行另一次尝试。
- 比较统计数据和记录。如果没有改善，则在测试下一个假设之前恢复之前的状态。
当没有足够的资源进行渲染时
检查游戏是否未使用显卡的所有可用电量。降低游戏的帧速率或简化场景可以为广播图像的合成留出空间。
查看源、过滤器和打开视图的数量。对于常规静态图形，请使用适当的图像源。保留您需要的功能并实际删除您不需要的副本，而不是随机隐藏内容。
当编码器跟不上时
不要盲目地从功能更强大的计算机上复制配置文件。适合一种游戏、场景和卡的设置可能不适用于不同的工作负载。可重复的试验结果比设置中的最大数量更重要。
- 检查编码消息和可用的硬件或软件编码器。
- 比较输出分辨率较低或帧数较少的示例。
- 保持其余参数不变，以了解改进的原因。
- 一旦图像稳定，逐渐提高要求并检查运动的质量。
当发送问题时
发送广播需要稳定上传到平台服务器。从网上下载文件的结果是不一样的测量结果。检查来自其他应用程序和设备的并行上传。
将比特率与您选择的服务和稳定连接带宽的建议进行比较。更改服务器或对不同平台进行对照试验可以帮助区分特定路线的问题。在没有准备的情况下，请勿在有效的 LIVE 中间执行此类切换。
测试期间的叠加、TTS 和音乐
逐一检查工具：首先是基础场景，然后是聊天、警报、音乐和其他效果。同一源的多个独立副本可能会不必要地增加负载并使声音复杂化。
有意识地调整覆盖区域以适应其配置。以牺牲切削元件为代价来减少源并不是一种成功的优化。如果您使用的是桌面应用程序，请检查其资源设置，但不要将所有系统内存分配给它。
您在屏幕上看到什么以及如何修复它
一次修复一件事，然后再尝试同样的事情。如果同时更改多个选项，将很难确定是什么解决了问题。不要仅仅因为一个小部件没有响应而删除工作源或整个配置。
如果您仍然需要帮助，请写下程序名称和版本、平台、大概的试用时间、预期结果以及实际发生的情况。附加没有密码、密钥和完整私人链接的转储。该描述比仅仅“不工作”消息有用得多。
| 症状 | 先检查一下 | 做吧 |
|---|---|---|
| 预览和文件卡住。 | 可能的场景或编码器过载。 | 检查两个计数器和更简单的场景。 |
| 文件有效，网络损耗增加。 | 发送或路由问题。 | 比较上传、电缆和比特率。 |
| 只有一名观众缓冲。 | 可能是它的链接或播放器。 | 检查第二个设备和不同的质量。 |
| 较低的质量没有帮助。 | 您正在更改与原因无关的参数。 | 返回指定的帧丢失类型。 |
在 LIVE 上使用之前的最后一次尝试
- 使用分配给已编辑功能的按钮保存更改。如果有单独的表格，请分别检查每个更改的部分。
- 再次打开设置并比较最重要的值。简单地移动滑块并不总是意味着永久保存。
- 在编辑器本身之外检查结果：在目标场景中、在录制中或在重新打开的配置中。
- 如果该功能使用平台，则在 LIVE 活动期间单独确认新处理的事件。不要指望外观测试可以确认帐户授权。
- 保存工作值并在下次重大更改之前制作副本。下次启动时，请先进行快速检查。
LIVE之前检查
- 已识别出一种递增错误计数器。
- 本地测试和传输进行了比较。
- 每个更改都会保存结果并且可以撤消。
- 最终测试包括真实工具和图像移动。
- 重新打开的设置保留保存的值。
- 在目标输出上确认单次尝试。
最常出现的问题
更高的比特率总是能改善传输吗？
不。它必须与质量、平台和上传稳定性相匹配。要求过高的设置可能会导致发送或接收变得困难。
大内存储备是否可以排除过载的情况？
不。限制可能是不同的资源、编码或网络。检查具体的统计数据和记录行为。
为什么本地录音很好但LIVE卡顿？
在观看端查看平台的发送、接收、播放情况。本地分数不会一路在线探索。
如果我的屏幕看起来与照片不同该怎么办？
检查程序名称、版本和所选功能。该转储是真实的，但它来自特定版本和语言。按任务搜索描述的字段。如果该选项不可用，请检查您帐户中当前的官方支持和可用性。