flvmux 没有以与音频相同的速率拉取视频

Question

我有一个管道，旨在从 C920 相机捕获音频和视频，对其进行一些非常简单的处理（低 cpu 要求），然后重新压缩并将其混合到文件中。

这是管道的大致轮廓：

Platform:
- Raspberry Pi 3
- Debian Jessie
- GStreamer 1.8

不用担心我的 'simple processing' 地区。我的总体 CPU 低于 25% CPU。

我发现，Q3 和 Q4 慢慢开始充满，直到一个达到阈值，然后我的音频变得断断续续（我从 alsasrc 'downstreaming is not consuming buffers fast enough' 收到警告）。我可以将泄漏放在队列中，但这很难解决问题。

由于我的管道是运行，这就是我的队列的样子（当前级别时间，以毫秒为单位）

QUEUE CONTENTS IN MILLISECONDS

TIME(s)     Q1     Q2    Q3    Q4    Q5    Q6
      0      0      0     0     0     0     0
      5      0      0   252   380     0     0
     10      0      0   293   460     0     0
     15      0      0   332   470     0     0
     20      0      0   378   451     0     0
     25      0      0   333   460     0     0
     30      0      0   383   480     0     0
     35      0      0   500   550     0     0
     40      0      0   500   610     0     0
     45      0      0   539   630     0     0
     50      0      0   584   670     0     0

=== 实验 ===

我删除了管道的黄色段，这样我就只捕捉视频了，结果更好了。我没有排队 'growing' - 输出视频很完美。

QUEUE CONTENTS IN MILLISECONDS

TIME(s)     Q1     Q2    Q3    Q4    Q5    Q6
      0      0      0     0     0     0     0
      5      0      0     2     0     0     0
     10      0      0     5     0     0     0
     15      0      0     8     0     0     0
     20      0      0     8     0     0     0
     25      0      0     8     0     0     0
     30      0      0     8     0     0     0
     35      0      0     8     0     0     0
     40      0      0     8     0     0     0
     45      0      0     8     0     0     0
     50      0      0     8     0     0     0

此外，我尝试了以下管道（图中省略了队列），完全成功 - 视频至少录制了 10 分钟，没有任何问题。

=== 问题 ===

这是怎么回事？

我的猜测是，由于 Q3（视频输出）已满，因此音频一定会放慢速度。因为 Q4 正在填满，而不是 Q5 - 这一定意味着 alsa 产生音频的速度比 aac 编码器压缩它的速度更快 - 对吗？但是，我的 CPU 使用率非常低 - 我试过 2 个 aac 编码器（voaacenc 和 avenc_aac）和一个 MP3 编码器，都存在同样的问题。

========更新=========

我在音频和视频之后（紧跟其后）放置了几个标识元素，并绘制了它们输出的 PTS。你可以看到他们很快就开始疏远彼此。当视频为 30 秒时，音频远远落后于 21 秒。这是图表

======== 更新 2 =========

我有第二个摄像头，把它换过来，问题就解决了。音频和视频 PTS 值保持同步至少 25 分钟。这款新相机的不同之处在于它是经过改装的 C920，装有定制镜头。镜头碰巧完全失焦 - 这就是 PTS 漂移的原因（如果我聚焦自定义镜头，我会得到相同的 PTS 漂移）。

所以 - 问题有点变化：为什么对焦 C920 相机的 PTS 漂移如此严重？注意：我正在关闭自动曝光，并将曝光绝对值设置为默认值 250。但是我更希望能够使用自动曝光...

Answer 1

好的，我已经解决了这个问题。对于任何阅读 :)

如果您使用的是 Raspberry Pi，即使是 v3 - 确保您在 uvch264src 上将 peak-bitrate 配置为不超过 3650000 (3.65Mbps)。我还在以 24khz 的频率捕获音频 - 如果你不这样做，你可能会稍微多一点。

如果您将其设置为更多，或完全忽略它，您将遇到与我相同的奇怪问题。视频片段中的运动和高细节会导致编码的 H264 超出 Pi 的处理能力。所以你的问题会很奇怪和零星。

我只能认为 C920 使 USB 总线饱和 - 很奇怪，因为 USB2 应该可以达到 480Mbps - 而我设置的限制是 3.65Mbps。我听说 Raspberry 有一个非常有缺陷的 USB 固件 blob - 但从未遇到过，直到现在。

问题已解决。我一直在考虑转向龙板...这可能给了我最好的理由。

flvmux 没有以与音频相同的速率拉取视频

flvmux not pulling video at same rate as audio

raspberry-pi

gstreamer

raspberry-pi3

gstreamer-1.0