Low MIPS Video Encoder

Ich suche einen Video-Encoder mit niedrigem MIPS und geringer Komprimierung. Dies ist für eine Komprimierung in VGA-Qualität mit 10 fps vorgesehen. Was sind meine Optionen? Ich muss in der Lage sein, diese Komprimierung mit einer 150-MHz-ARM-M4-CPU mit Gleitkomma-Unterstützung durchzuführen. (STM32F4) ..

Meine Idee ist es, diese komprimierten Daten mit einem parallelen Bus aus der CPU herauszuschieben. Es werden keine Daten verarbeitet. In Bezug auf die Komprimierungsrate möchte ich so weit wie möglich nur die Grenzen sehen. Dies ist für eine kostengünstige CCTV-Anwendung. Ich möchte sehen, was ich mit einer 5-US-Dollar-CPU und viel Übertragungsband im Vergleich zu einem 30-US-Dollar-Encoder mit geringer Datenübertragung erreichen kann.

10 fps, VGA erzeugt ungefähr 25 Mbit / s Daten. Dies ist eine ziemlich hohe Datenrate für alles da draußen. Wenn ich dies auf 5 Mbit / s reduzieren kann, kann ich ein sehr kostengünstiges CCTV-System bauen. Sobald ich die Daten zur Basis gebracht habe, kann ich sie neu codieren. Daher spielt es keine Rolle, wie der Komprimierungsmechanismus aussieht, solange er nicht sehr verlustbehaftet ist.

Monochromatisches Video ist im Moment über Farbe notwendig.

Aktualisieren

• Dieser CPU sind 120 MHz für diese Aufgabe zugeordnet.
• Die Speicherschnittstelle ist 16 Bit, daher ist das Schreiben / Lesen des externen Speichers im Vergleich zum internen Speicher langsamer.
• Der interne Speicher ist 120 KByte groß und verfügt über einen schnellen 32-Bit-Zugriff. In beiden Fällen wird über den AHB-Bus auf den Speicher zugegriffen, wobei 60 MHz als Taktfrequenz angenommen werden sollten.
• Der folgende Datenfluss wird erwartet:
  1. Kamera -> DMA -> Externer Speicher (keine CPU-Beteiligung)
  2. Externer Speicher -> CPU -> Komprimierung -> Interner Speicher
  3. Interner Speicher -> DMA -> Datenbus -> Externes Gerät

Die CPU liest nur einen Teil der Datenkomprimierung und schreibt in ihren internen Speicher (die komprimierten Daten). Später startet sie eine DMA-Übertragung.

1. Klassifizieren Sie, ob Sie insgesamt niedrige MIPS oder geringe Komplexität benötigen.
Lassen Sie mich ein wenig frei, um dieses Problem in zwei Teile aufzuteilen.

1. Codierung mit geringer Komplexität - Dies ermöglicht weniger Ressourcen (insbesondere im Speicher), um eine schnell reagierende Codierung im angegebenen System zu ermöglichen.
2. Niedrig explizit in der Berechnung (MIPS). - die sich nur mit minimal möglichen CPU-Zyklen befassen.

Es gibt dritte Kriterien - bei denen von "geringer Latenz" die Rede ist - für Anwendungen wie Videokonferenzen, bei denen Rechenressourcen möglicherweise keine Rolle spielen - aber die durch Codierung verursachte Gesamtverzögerung

Was zu beachten ist, ist, dass in Systemen mit geringerer Komplexität der Zugriff auf den Speicher (Speicherbusgeschwindigkeit und -breite) und manchmal die E / A im Allgemeinen extrem langsamer sind, weshalb die MPEG-Algorithmusklasse leidet, obwohl der Rechenalgorithmus einfach sein könnte.

Bevor Sie die Anforderung an den Codec beurteilen, sollten Sie versuchen, ein Budget in Bezug auf Folgendes zu erstellen:

ein. CPU-Zyklen pro Sekunde.
b. Maximaler Speicherdurchsatz.
c. IO-Latenz

2. Sie sollten MPEG anpassen, anstatt es neu zu erfinden.
Im Allgemeinen bietet Ihnen die Codec-Klasse MPEG sehr flexible Mechanismen, um dies zu tun. In diesem Sinne müssen Sie den Codec nicht ganz neu erfinden, sondern MPEG 2 oder MPEG 4 anpassen , um Ihre Arbeit zu erledigen.

Lassen Sie uns zunächst sagen, was alle Elemente die Komprimierung ermöglichen, und sie in der Reihenfolge ihrer Komplexität anordnen:

1. Bewegungsschätzung und Bewegungskompensation. 1.a. Vorwärtsvorhersage (P-Frames) 1.b. Doppelte Vorhersage (B-Frames) 1.c. hochauflösende Bewegungsvektoren
2. Intra-Codierung - DCT (+ IDCT)
3. Qunatization - und Auswahl des Encoder-Modus
4. VLC - Codierung mit variabler Länge. (CABAC in H.264)
5. Koeffiziente Vorhersage [In mpeg2 hat nur die DC-Vorhersage - MPEG4 hat mehr]

In der MPEG-Klasse von Algorithmen werden die DCT-basierte Codierung und VLC ohne große Auswahl ziemlich obligatorisch - aber der Rest aller Mechanismen ist sehr wichtig

Beispielsweise ist die Bewegungsschätzung und Bewegungskompensation eines der Elemente mit dem höchsten MIPS-Verbrauch. Wenn Sie dazu keine Ressourcen haben, können Sie einfach alle Frames als I-Frames codieren (was MJPEG ziemlich ähnlich macht - aber der Standard-MPEG-Decoder kann dies decodieren). Wenn Sie sich etwas mehr Ressourcen leisten können - Sie können mithilfe des Frame-Unterschieds eine geringfügige Bewegungskompensation vornehmen -, anstatt jedes Frame als Intra zu senden, können Sie jeden Block vom vorherigen Frame-Block subtrahieren. Wenn die Differenz höher als das ursprüngliche Signal ist, senden Sie es als Intra.

Natürlich - all dies würde bedeuten, dass Sie die von dem oben genannten Encoder versprochene Effizienz verlieren -, aber ich denke, Sie sind bereit, darauf zu verzichten!

BEARBEITEN:
Sie können die folgenden Codecs als gute Referenzpunkte betrachten:

1. MSSG: http://www.mpeg.org/MPEG/video/mssg-free-mpeg-software.html
   Gut zum Verständnis, aber möglicherweise am langsamsten auf der Welt.

2. FFMPEG: http://ffmpeg.org/ Wahrscheinlich der schnellste der Welt. Gut, um als Black Box zu beginnen, aber versuchen Sie nicht, den Code von innen zu ändern. Könnte Ihnen gute Möglichkeiten bieten, Dinge zu steuern, wenn Sie die Bibliotheks-API verwenden. Es ist bereits auf vielen Plattformen portiert - aber es auf einer neuen Plattform zu machen, könnte eine Aufgabe sein.

3. FAME: http://fame.sourceforge.net/ Dies wurde ursprünglich mit dem von Ihnen beschriebenen Zweck gestartet. Ich bin zwar ein bisschen außer Kontakt - aber Sie können es versuchen.

4. Xvid: http://www.xvid.org/ Dies ist MPEG-4. Dies ist eine der besten Balance zwischen sauberem Code und angemessener Geschwindigkeit. Sollte am einfachsten zu handhaben sein, wenn Sie sich im Inneren des Encoders befinden.

5. JPEG: http://www.ijg.org/ Dies ist JPEG. Dies ist eine der besten Bibliotheken, um sie plattformübergreifend zu portieren. Außerdem ist JPEG von Natur aus einfacher als einige Aspekte von MPEG. Vielleicht sollten Sie dies zuerst versuchen. Die meisten Kameras auf der Welt haben diese Bibliothek wahrscheinlich so verwendet, wie sie ist - anstatt etwas Eigenes zu erstellen!

Vielleicht irre ich mich bei der Verwendung von MPEG! Aber das ist eine Art Risiko, das es wert ist, eingegangen zu werden.

Die wahrscheinlich beste Maßnahme, um zu überprüfen, ob dies funktioniert oder nicht, ist - versuchen Sie einfach, eine Standard-8x8-DCT mit Quantisierung Ihres Bildes zu erstellen. Optimieren Sie genau dies. Wenn Sie in der Lage sind, Ihre Echtzeitanforderungen zu erfüllen, sind Sie meiner Meinung nach gut darin, alle JPEG-Frames oder den gesamten I-Frame-MPEG-Codec zu bearbeiten. Wenn Sie weit vom Ziel entfernt sind - dann lohnt es sich nicht.

Ihr erstes Problem ist der Arbeitsspeicher - selbst die größte Version dieses Prozessors verfügt nicht über so viel internen SRAM (in Bezug auf Videos - es ist ein beeindruckender eingebetteter Prozessor im Vergleich zu vielen anderen!) - ein VGA-Frame hat 300 KB gegenüber 100 KB im Prozessor . Das bedeutet, dass Sie es so verarbeiten müssen, wie es eingeht - beispielsweise in 8 oder 16 Zeilenabschnitten, was es viel mehr zu einem "Hard-Realtime" -Problem macht, da die Fristen weniger locker sind.

Es ist nicht klar, wie Sie Daten erfassen, aber ich gehe davon aus, dass Sie eine Art DMA entweder vom ADC oder von einem digitalen Port haben, sonst verbringen Sie die Hälfte Ihrer Zeit damit, Daten zu mischen!

Mit dem Ziel niedriger Komprimierungsverhältnisse möchten Sie möglicherweise nur die Codierung der Deltas zwischen Pixeln entlang einer Linie oder eines 3x3-Quadrats betrachten und sie dann arithmetisch codieren.

Siehe auch Einfache, streamende, verlustfreie Bildkomprimierung - obwohl ich ausdrücklich um verlustfreie Komprimierung gebeten habe, gibt es dort möglicherweise einige Ideen für Sie.

Als Datenpunkt implementierte einer meiner Kollegen eine 320x240 8-Bit-Mono-JPG-Komprimierung in einem 60-MHz-32-Bit-Mikro mit Gleitkommaeinheit und kleinem Cache. Er verwendete einen Referenzcode (dh optimiert für Lesbarkeit, nicht Leistung) und bekam ziemlich leicht 5 fps. Die Kompressionsverhältnisse lagen in der Größenordnung von 10 × IIRC. Die Bilderfassung erfolgte durch externes Hardware-Bus-Mastering der Daten im externen RAM des Mikros.