ffmpeg - h264 通过 WebRTC 延迟问题

Question

我正在尝试通过 WebRTC 发送使用 h264 编码的视频流(使用 nvidia 编码器加速的硬件)，以便在浏览器上进行低延迟显示。
更准确地说，我有一个线程以固定帧速率编码 opengl 帧缓冲区，然后通过 WebRTC 将生成的 AVPacket 的数据(我使用 ffmpeg 的 C api 编码)转发到客户端(使用 aiortc)
问题是我观察到明显的延迟，这似乎取决于我使用的帧速率。
例如，在本地运行它，以 30fps 运行时延迟约为 160ms，以 90fps 编码时延迟约为 30ms。
这里的延迟是编码+传输+解码的测量时间，我有一个强烈的印象，即在呈现视频帧时会发生问题，就像浏览器没有立即呈现帧一样......(编码很快，我希望本地设置的传输速度也相当快，并且解码似乎也很好，正如浏览器中的 RTP 统计信息所报告的那样)。
我尝试使用 RTP 时间戳，但这并没有改变任何东西，似乎影响延迟的唯一变量是编码线程“频率”。
关于什么可能导致这种延迟的任何想法？我错过了一个参数吗？
此外，这里是我使用的编解码器选项:(它们不会对我的实验产生太大影响)

profile = high
preset = llhq  # low latency, high quality
tune = zerolatency
zerolatency = 1
g = 2 * FRAME_PER_SECOND  # key frame every 2s
strict-gop = 1

更新
我的印象是 Chrome 端的 jitter buffer 会阻止 rtp 数据包立即被解码，这可能吗？
更新 2

使用 RTP playout-delay header 扩展略微减少了延迟。

设置playoudDelayHint在浏览器中似乎也有点帮助

更新 3
经过进一步调查，我得出的结论是，通过视频流的标准 webrtc 无法获得更低的延迟，因为对视频缓冲几乎没有控制，我认为这是观察到的潜伏。
在旁注中，我试图检查 google stadia 是如何做到的，因为他们似乎也使用 WebRTC，但他们使用了一些内部框架......(加上 Chrome 是唯一受支持的浏览器)

Answer 1

如果您将 NvFBC 与 NvENC 一起使用，则不应使用 ffmpeg 对帧进行编码，将帧缓冲区存储为 opengl 纹理并将其提供给编码器，您当前正在将帧缓冲区数据从 VRAM 复制到系统内存，然后再复制到 VRAM 和然后再回来。他们网站上的 Nvidia Capture zip 文件中有一个示例。
我目前正在处理一个非常相似的问题，但 jitter buffer 堆积的原因可能是由于时间戳问题，而不是协议(protocol)本身。