1

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

这是管道的大致轮廓：

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

坏管道

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

我发现，Q3 和 Q4 慢慢开始填满，直到达到阈值，然后我的音频变得断断续续（我从 alsasrc 收到警告“下游没有足够快地消耗缓冲区”）。我可以将泄漏放在队列上，但这很难解决问题。

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

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 分钟，没有任何问题。

良好的管道

=== 问题 ===

到底是怎么回事？

我的猜测是，因为第三季度（视频输出）正在填满，那么音频一定会减慢速度。因为 Q4 正在填满，而不是 Q5 - 这一定意味着 alsa 产生音频的速度比 aac 编码器压缩它的速度要快 - 这是正确的吗？但是，我的 CPU 使用率非常低 - 我尝试使用 2 个 aac 编码器（voaacenc 和 avenc_aac）和一个 MP3 编码器，都存在相同的问题。

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

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

A/V 漂移

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

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

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

4

1 回答 1

1

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

如果您使用的是 Raspberry Pi，甚至是 v3 - 确保peak-bitrate您3650000的uvch264src. 我也在捕捉 24khz 的音频——如果你不这样做，你可能会多出一点。

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

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

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

于 2017-04-08T23:34:55.570 回答