低解像度カメラから 1 分おきに画像を生成します。10 ～ 20 枚の画像を実行して圧縮し、非常に帯域幅が制限されたチャネルで送信したいと考えています。x264 の使用を検討しましたが、オーバーキルのように感じます。
私の画像が 320x240 で、フレーム間の冗長性が高い場合、最善の方法は何でしょうか?
エンコーディングは特に高速である必要はありません。組み込みデバイスでの実装の難しさと、合計ファイル サイズの縮小との間のバランスを見つけることが重要です。
私は表示ソフトウェアを完全に制御できるので、一部の圧縮スキームの修正版を使用しても問題ありません。
私はfreeRTOSを使用します
これを行う簡単で堅牢な方法は、各フレームを JPEG としてエンコードすることです。これは、M-JPEGストリームとして表示される場合があります。圧縮は、最適ではないにしても、通常は適切です。これで十分な場合は、それを選択してください。
組み込みシステムでは、H.264はやり過ぎです。エンコードには計算が必要であり、デコードにも計算が必要だからです。ffmpeg を使用する上でさらに重要な (そしてやり過ぎ) ことは、ffmpeg には 150 の奇妙なコーデックがあるという事実です。そのため、それらを移植することも問題になります。
より簡単な方法は、IJGがシステムで移植可能かどうかを確認することです。(そのため、これはさまざまなプラットフォームで最も移植性が高いことがわかっています。
この場合、連続するフレーム間で単純なフレーム差分を適用し、それらの個々の JPEG を作成できます。冗長性がある場合、後続の JPEG ははるかに小さいサイズになります。
移植を実行する前に、冗長性が実際にビット レートの削減に役立っているかどうかを確認する必要があります。
x264オーバーキルはなぜ？これは非常に効率的なエンコーダーであり、時空間冗長性を活用したい場合は、JPEG の束ではなく H.264 などの圧縮アルゴリズムを使用する必要があります。
そのデバイスへの libavcodec のポートはありますか? h.264エンコーダーが組み込まれていると思います。h.264がやり過ぎだとは思いません。
ただし、「帯域幅制限」を定義してください。1 ピクセルあたり 1 ビット (1 フレーム/分の頻度で 1 秒あたり 160 バイト) で送信するのに十分な帯域幅がある場合は、jpeg を超える必要はありません。それよりも少ない場合は、一時的な圧縮 (ある種の MPEG) が保証されます。