Question

我有一个管道，用于从C920摄像头捕获音频和视频，对其进行一些非常简单的处理（低CPU要求），然后重新压缩并将其复制到文件。

这是管道的概要：

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

不要担心我的“简单处理”区域。我的整体CPU低于25％CPU。

我发现，Q3和Q4慢慢开始填满，直到一个达到阈值，然后我的音频变得非常不稳定（我从alsasrc'下游获得警告并没有足够快地消耗缓冲区'）。我可以在队列上泄漏，但这几乎无法解决问题。

当我的管道正在运行时，这就是我的队列的样子（以ms为单位的当前级别时间）

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

===实验===

我删除了管道的黄色分支，因此我只捕获视频，结果更好。我没有排队只是保持“成长” - 输出视频非常完美。

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，请确保您已peak-bitrate上的3650000配置为不超过uvch264src（3.65Mbps）。我也在以24khz的速度捕捉音频 - 如果你没有这样做，你可能会再多一点。

如果您将其设置为更多，或者完全省略它，您将遇到我遇到的同样奇怪的问题。视频素材中的移动和高细节将导致编码的H264超出Pi可以处理的内容。所以你的问题将是奇怪和零星的。

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

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

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

1 个答案: