低MIPSビデオエンコーダ

低MIPS、低圧縮のビデオエンコーダーを探しています。これは、10fps、VGAタイプの品質の圧縮用です。私のオプションは何ですか？浮動小数点をサポートする1​​50MHz ARM M4 CPUを使用してこの圧縮を実行できるようにする必要があります。（STM32F4）。

私の考えは、この圧縮データを並列バスでCPUから押し出すことです。データに対して処理は行われません。圧縮率に関しては、できる限り境界を確認したいと考えています。これは低コストのCCTVアプリケーション用です。5USDのCPUと多くの伝送帯域で、低データ伝送帯域幅の30USDエンコーダーで何ができるかを知りたいです。

10fps、VGAは約25Mbit /秒のデータを生成します。これは、そこにあるものにとってはかなり高いデータレートです。これを5Mビット/秒に下げることができれば、非常に低コストのCCTVシステムを構築できると思います。データをベースに取得したら、データを再エンコードできます。そのため、非常に損失が少ない限り、圧縮メカニズムが何であってもかまいません。

単色ビデオは、色よりも今必要なものです。

更新

• このCPUには、このタスクに120MHzが割り当てられています。
• メモリインターフェイスは16ビットであるため、外部メモリの書き込み/読み取りは内部メモリに比べて遅くなります。
• 内部メモリは120KByteで、32ビットアクセスの高速アクセスがあります。どちらの場合も、メモリはAHBバスを介してアクセスされ、クロック周波数として60MHzを想定する必要があります。
• 次のデータフローが予想されます。
  1. カメラ-> DMA->外部メモリ（CPUの関与なし）
  2. 外部メモリ-> CPU->圧縮->内部メモリ
  3. 内部メモリ-> DMA->データバス->外部デバイス

CPUは、データ圧縮のチャンクを読み取り、その内部メモリ（圧縮データ）に書き込むだけで、後でDMA転送を開始します。

1.必要なMIPSが低いか、全体的に複雑さが低いかを分類する
この問題を2つの部分に分割するために、少し自由に考えてみましょう。

1. 複雑さの低いエンコーディング-（特にメモリ内の）より少ないリソースで、特定のシステムでの応答の速いエンコーディングを可能にします。
2. 計算で明示的に低い（MIPS）。-可能な最小限のCPUサイクルのみに関係しています。

3番目の基準-人々が「低遅延」について話す場所-計算リソースが問題にならない可能性があるビデオ会議のようなアプリケーションに対して-しかし、コード化によって導入される全体的な遅延

複雑性の低いシステムでは、メモリへのアクセス（メモリバスの速度と幅）とIOが一般的に非常に遅いため、計算アルゴリズムが単純な場合でも、MPEGクラスのアルゴリズムが影響を受けることに注意してください。

コーデックの要件について判断する前に、次の点で予算を立てる必要があります-

a。1秒あたりのCPUサイクル。
b。putを介した最大メモリ。
c。IOレイテンシ

2.再発明するのではなく、MPEGをカスタマイズする必要があります。
一般的に、MPEGクラスのコーデックは、これを行うための非常に柔軟なメカニズムを提供します。その意味で、MPEG 2またはMPEG 4をカスタマイズして作業を完了するよりも、コーデックを再発明する必要はほとんどありません。

まず、すべての要素が圧縮を可能にし、複雑さの順に配置するとします。

1. 動き推定と動き補償。1.a. フォワード予測（Pフレーム）1.b. 二重予測（Bフレーム）1.c. 高解像度モーションベクトル
2. イントラコーディング-DCT（+ IDCT）
3. 量子化-およびエンコーダーモードの選択
4. VLC-可変長コーディング。（H.264のCABAC）
5. 係数予測[mpeg2のみDC予測-MPEG4はそれ以上]

MPEGクラスのアルゴリズムでは、DCTベースのエンコーディングとVLCは、選択の余地なくかなり強制的になりますが、残りのすべてのメカニズムは非常に重要です

たとえば、モーション推定とモーション補正は、MIPSを最も消費する要素の1つです。これを行うためのリソースがない場合は、すべてのフレームをIフレームとして単純にエンコードできます（これにより、MJPEGとほぼ同じになりますが、標準のMPEGデコーダーでデコードできます）。少し多くのリソースを使用できる場合は、フレーム差分を使用して些細なモーション補正を行うことができます。すべてのフレームをイントラとして送信する代わりに、前のフレームブロックからすべてのブロックを差し引くことができます。差が元の信号よりも大きい場合は、イントラとして送信します。

もちろん、これはすべて、上記のエンコーダーによって約束された効率がいくらか失われることを意味しますが、それをあきらめても構わないと思います！

編集：
以下のコーデックを参考にしてください。

1. MSSG：http ://www.mpeg.org/MPEG/video/mssg-free-mpeg-software.html
   理解には優れていますが、世界で最も遅いものになるかもしれません。

2. FFMPEG：http ://ffmpeg.org/ おそらく地球上で最速。ブラックボックスとして開始するのが適切ですが、コードを内部から変更しないでください。ライブラリAPIを使用するときに、制御するための適切なオプションを提供する場合があります。すでに多くのプラットフォームに移植されていますが、新しいプラットフォームでそれを実行することは、いくつかの作業かもしれません。

3. 名声：http : //fame.sourceforge.net/ これは当初、あなたが説明したのと同じ目的で開始されました。しかし、私はこれに少し触れていません-しかし、あなたはこれを試すことができます。

4. Xvid：http : //www.xvid.org/ これはMPEG-4です。これは、クリーンなコードと妥当な速度の間の最良のバランスの1つです。エンコーダの内部に住むことになる場合は、最も扱いやすいはずです。

5. JPEG：http : //www.ijg.org/ これはJPEGです。これは、プラットフォーム間で移植するのに最適なライブラリの1つです。また、JPEGは本質的にMPEGのいくつかの側面よりも単純です。最初に試してみてください。世界中のほとんどのカメラは、おそらく独自のライブラリを作成するのではなく、このライブラリをそのまま使用しています。

MPEGの使い方が間違っているかもしれません！しかし、それは取るに値する一種のリスクです。

おそらく、それが機能するかどうかを確認するための最善の方法は、画像上で量子化された標準の8x8 DCTを試すことです。これだけを最適化します。すべてのJPEGフレームまたはすべてのIフレームMPEGコーデックについて実行することをお勧めします。あなたがターゲットから離れている場合-それはそれだけの価値はありません。

あなたの最初の問題はメモリです-そのプロセッサの最大バージョンでも内部SRAMはそれほど多くありません（ビデオ用語では-多くの場合と比較してそれはストンキング組み込みプロセッサです！）-VGAフレームは300kBですが、プロセッサの100ishkBです。 。つまり、入ってきたとおりに処理する必要があります。つまり、8または16行のチャンクで処理する必要があります。これにより、締め切りのたるみが少なくなるため、「ハードリアルタイム」の問題が大幅に増加します。

データをどのようにキャプチャするかは明確ではありませんが、ADCまたはデジタルポートから何らかのDMAが発生すると想定します。そうしないと、半分の時間を費やしてデータをシャッフルします。

低めの圧縮率を目指して、ラインまたは3x3の正方形に沿ってピクセル間のデルタをエンコードしてから、それらを算術符号化したい場合があります。

シンプル、ストリーミング、ロスレスの画像圧縮もご覧ください。私は明示的にロスレスの圧縮を求めていましたが、そこにはいくつかのアイデアがあるかもしれません。

データポイントとして、私の同僚の1人が、浮動小数点ユニットと小さなキャッシュを備えた60MHz 32ビットマイクロで320x240 8ビットモノJPG圧縮を実装しました。彼はいくつかの参照コード（つまり、パフォーマンスではなく可読性に最適化されている）を使用して、5 fpsをかなり簡単に取得しました。圧縮率は、IIRCの10倍程度でした。画像のキャプチャは、マイクロの外部RAMにデータをバスマスタリングする外部ハードウェアによって行われました。