问题排查#

延迟和动画或音频卡顿可能由多种因素引起。本节列出了一些常见问题,以及如何缩小根本原因的范围。

Audio2Face-3D 微服务过慢#

在某些情况下,来自 Audio2Face-3D 微服务的动画数据流的流式传输速度低于实时速度(例如,低于每秒 30.0 帧)。在这种情况下,动画图微服务不会播放所有动画数据,而只会丢弃到达时间过晚的动画数据帧。发生这种情况时,以下消息会打印在动画图微服务日志中

Warning: buffer underrun. Discarding current data

当这种情况经常发生,并且根本原因是 Audio2Face-3D 微服务提供数据太慢或非常不规律时,可以通过增加动画图微服务的 animationSource.bufferSize UCS 微服务参数的值来在某种程度上缓解这种情况。该值越高,播放前缓冲的动画数据就越多。这使得连接对抖动和延迟的动画数据更具鲁棒性,但代价是更高的延迟。我们发现 0.1s 的值是可以接受的。请注意,此值取决于您的系统配置和性能特征。

Audio2Face-3D 微服务不发送动画数据#

在极少数情况下,我们观察到 Audio2Face-3D 微服务可能不发送任何动画数据块,也不发送动画数据流标头。发生这种情况时,不会播放任何动画数据,并且以下消息会打印在日志中

Received SUCCESS status before the header in the animation data stream!

我们仅在实验场景中遇到过此问题。如果发生这种情况,请考虑调查 Audio2Face-3D 微服务是否正在正确运行,并考虑在可能的情况下升级。

动画图微服务过慢#

有时,来自动画图微服务的动画数据到达 Omniverse 渲染器微服务的速度慢于实时速度。发生这种情况时,以下消息会打印在 Omniverse 渲染器微服务日志中

Display time is in the past! Skipping frame!

这通常意味着动画图微服务在短时间内被减速,例如,当 CPU 忙于处理另一个进程时。同样,如果问题经常发生,您可以通过增加 Omniverse 渲染器微服务的 animationSource.bufferSize UCS 参数的值来缓解这种情况。该值越高,动画数据输入缓冲区就越大。这降低了动画数据流抖动的风险,但代价是更高的延迟。我们发现 0.1s 的值是可以接受的。请注意,此值取决于您的系统配置和性能特征。

语音音频和嘴唇动画同步#

可能会发生动画数据流中没有警告,并且动画数据播放流畅,但是,语音音频和嘴唇动画不同步。

根本原因是 Livestream 扩展通过两个不同的 RTP 流发送音频和视频。这些流不支持同步协议,这可能会导致动画和音频流之间存在可感知的时序偏移。

为了解决这个问题,Omniverse 渲染器微服务有一个 livestream.audioDelay UCS 参数,可以将音频延迟指定的秒数。我们发现大约 0.1s 的值可以解决系统上的问题。

性能监控#

如果您观察到延迟或中断不是由上述任何问题引起的,则下一步是检查动画图和 Omniverse 渲染器微服务的帧率。

动画图微服务的帧率打印在日志中

Output animation data | Stream ID: <stream_id> | Mean frame time: 0.0334

以及 Omniverse 渲染器微服务的帧率

Rendering animation data | Time since start [s]: 1314.159 | Port: 8000 | Mean frame time: 0.0334

这些值通常非常相似。

如果动画图微服务和/或 Omniverse 渲染器微服务的 平均帧时间 经常高于约 0.034 秒,那么这通常与一般性能问题有关。这通常是由于 GPU 使用率达到 100% 并减慢整个系统速度引起的。

虚拟化身手势未触发#

如果您触发了无效的动画手势或姿势状态,则 HTTP 调用将成功,而不会发出警告或错误。但是,虚拟化身会进入中立姿势并伸出左手的一个或多个手指。这就是所谓的测试姿势。这表明动画图已收到无效或无输入。例如,如果手势的字符串拼写错误,或者微服务未找到角色。您可以通过使用有效值触发新的手势和新的姿势来从这种状态恢复。

This image shows the test pose the avatar will go into when an invalid gesture or posture is triggered.

此图显示当触发无效手势或姿势时,虚拟化身将进入的测试姿势。#

Glfw 警告#

当使用 docker 运行动画管线时,您可能会在动画图微服务日志中遇到 glfw 警告,如下所示。当这些情况发生时,您将无法看到场景。如果使用 Unreal 渲染器,UI 将卡在消息“WebRTC Connection Negotiated”上。

2024-05-24 16:41:09 [1,094ms] [Warning] [carb.windowing-glfw.plugin] GLFW initialization failed.
2024-05-24 16:41:09 [1,094ms] [Warning] [carb] Failed to startup plugin carb.windowing-glfw.plugin (interfaces: [carb::windowing::IGLContext v1.0],[carb::windowing::IWindowing v1.4]) (impl: carb.windowing-glfw.plugin)

要解决此问题,请运行以下命令

sudo xhost +

并使用以下额外参数 图像名称之前 重新运行动画图容器:-v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY

内存不足#

如果 docker 容器或 kubernetes 部署启动失败,则可能是内存不足。在 kubernetes 中,这表现为 pod 卡在 CrashloopBackoff 状态。在容器的日志中,您会看到类似于以下的行

[A2F SDK] [ERROR] [TensorRT] 1: [defaultAllocator.cpp::allocate::20] Error Code 1: Cuda Runtime (out of memory)
[A2F SDK] [ERROR] [TensorRT] 2: [executionContext.cpp::ExecutionContext::410] Error Code 2: OutOfMemory (no further information)
[A2F SDK] [ERROR] Unable to create TensorRT Execution Context
[A2F SDK] [ERROR] Unable to initialize inference engine
[A2F SDK] [ERROR] SetNetwork Processor failed
[A2F SDK] [ERROR] Cannot Initialize from Json file: /opt/nvidia/a2f_pipeline/a2f_data/data/networks/claire_v1.3/a2f_ms_config.json

EpicGames Docker 镜像权限被拒绝#

当尝试运行 Pixel Streaming Signalling Server 时,您可能会遇到 Permission denied 消息。如果发生这种情况,请确保

  1. 您的 GitHub Personal Access Token 具有 read:projectread:packages 的权限

  2. 您是 您的组织 中的 EpicGames GitHub 组织的成员。您可能需要手动接受加入该组织的邀请

Unreal 渲染器微服务视频抖动#

在某些机器上和使用某些质量设置(通常是较低质量设置)时,我们偶尔注意到流式视频中出现一些抖动。根本问题尚未找到根本原因,但作为一种解决方法,我们建议通过更改项目中与质量相关的设置来稍微增加 GPU 负载。例如,提高分辨率、提高 Scalability 质量设置、提高 Fixed Frame Rate 或将 Pixel Streaming 视频编解码器从 H264 更改为 V9 有助于减轻抖动。