C920カメラからオーディオとビデオをキャプチャし、非常に単純な処理を行い（CPU要件が低い）、再圧縮してファイルに多重化するパイプラインがあります。
これは、パイプラインの一般的な概要です。
Platform:
- Raspberry Pi 3
- Debian Jessie
- GStreamer 1.8
私の「単純な処理」領域について心配しないでください。私の全体的な CPU は 25% 未満の CPU です。
私が見つけたのは、Q3とQ4がゆっくりといっぱいになり始め、1つがしきい値に達するまで、オーディオがすべて途切れ途切れになることです(そして、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 分間は問題なく記録されました。
=== 質問 ===
何が起こっている？
私の推測では、Q3 (ビデオ出力) がいっぱいになっているため、オーディオが速度を落としているに違いありません。Q5 ではなく Q4 がいっぱいになっているため - これは aac エンコーダーが圧縮できるよりも早く alsa がオーディオを生成していることを意味するに違いありません - それは正しいですか? ただし、私の CPU 使用率は非常に低く、2 つの aac エンコーダー (voaacenc と avenc_aac) と MP3 エンコーダーを試しましたが、すべて同じ問題が発生しました。
======== 更新 =========
オーディオとビデオ (直後) の後にいくつかのアイデンティティ要素を配置し、それらの出力の PTS をグラフ化しました。それらが非常に急速に互いに離れ始めていることがわかります。ビデオが 30 秒になるまでに、オーディオは 21 秒遅れています。ここにチャートがあります
======== 更新 2 =========
私は 2 台目のカメラを持っていましたが、それを交換したところ、問題は解消されました。オーディオとビデオの PTS 値は、少なくとも 25 分間同期されていました。この新しいカメラとの違いは、C920 を改造してカスタム レンズを装着したことです。偶然にも、レンズの焦点が完全にずれていました。これが PTS ドリフトを修正したものです (カスタム レンズの焦点を合わせると、同じ PTS ドリフトが発生します)。
では、質問が少し変わりました: 焦点が合っている C920 カメラの PTS がひどくドリフトするのはなぜですか? 注: 自動露出をオフにして、露出絶対値をデフォルトの 250 に設定しています。ただし、自動露出を使用できるようにしたいのですが...