Low MIPS Video Encoder


7

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.


Wie viel von Ihrem Prozessor können Sie sich leisten, um dies zu tun? Und was ist eine akzeptable Komprimierungsrate? 5x, 2x, weniger als das?
Martin Thompson

Ich kann 80-90% widmen. Meine Idee ist es, diese komprimierten Daten mit einem parallelen Bus aus der CPU herauszuschieben. Die Daten werden nicht 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.
Ktuncer

Nur um hinzuzufügen: 10 fps, VGA generiert 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.
Ktuncer

wie Sie Sicherheit erwähnen ... Farbe oder Mono?
Martin Thompson

Mono ist das, was im Moment notwendig ist. Macht das einen Unterschied?
Ktuncer

Antworten:


2

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.


Dipan, das ist eine gute Antwort, aber ich suche etwas Quantifizierteres. Sie sagen, es kommt darauf an. Wir wissen das, ich suche eine fundierte Vermutung. Eine erfahrene Person mit diesen Dingen könnte sagen: "Kümmere dich nicht um x, konzentriere dich auf Y und dies ist das kritische Bit, auf das du achten musst. Wenn du alles richtig machst, bekommst du diese Art der Komprimierung, so viele Mips werden es tun." verwendet werden". Nach meiner Erfahrung ist die Antwort in der Nähe normalerweise 20%, sobald Sie den richtigen Mann gefunden haben.
Ktuncer

Tatsächlich habe ich auch versucht, zuerst einige detaillierte Profilinformationen zu erstellen, aber ich dachte, dass dies möglicherweise nicht direkt wiedergegeben wird, da es sich bei Ihrer um eine sehr spezifische Hardware handelt, bei der dies berücksichtigt werden muss. Ich war also darauf beschränkt, Ihnen eine Antwort zu geben, die eher direktional als quantitativ war. Außerdem könnte es wahrscheinlich am besten sein, die Antwort wegzunehmen, was ich hervorheben wollte, dass ich mich an das bekannte MPEG halte und es abstimme, anstatt es neu zu erfinden.
Dipan Mehta

Um quantitativ perfekt zu sein, würde ich vorschlagen, dass Sie einen guten (Referenz-) MPEG-Encoder nehmen und mit der Profilerstellung beginnen. Basierend auf diesen tatsächlichen Profilerstellungsergebnissen kann ich Sie bis zum Ende führen. Was genau für die Echtzeitcodierung funktioniert, hängt von den spezifischen Dingen ab, die Sie erreichen können, von Ihrer Hardwareplattform, um den Encoder speziell an die Echtzeitbeschränkungen anzupassen. (Natürlich müssten Sie dafür viele weitere Fragen stellen!)
Dipan Mehta

Ich schätze Ihre MPEG-Idee, alle iFrames usw. Dies ist ein guter Ansatz. Wenn ich jedoch mit diesen Informationen beginne, kann ich in drei Monaten feststellen, dass dies unmöglich ist, da die erforderlichen MIPS (auch für verwässerte) außerhalb der CPU oder Komprimierung liegen ist nur 10% oder so ähnlich. Ich brauche einige Nummern, auch wenn es nicht für diese Plattform ist.
Ktuncer

Was ist ein guter Open Source MPEG Encoder? Etwas, das in ANSI C geschrieben ist, kann ich nehmen und damit anfangen zu spielen.
Ktuncer

4

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.


Martin, danke für die Antwort. Ich kann und werde diesem Prozessor einen 4-Mbit-Speicher hinzufügen. So kann ich den gesamten Frame im Speicher behalten. Die Daten fließen über DMA von der Kamera-Schnittstelle zum externen Speicher. Ich habe keine (oder fast keine) Beteiligung. Ich kann diesen Teil des Codes ziemlich einfach optimieren. Wenn ich muss, kann ich auch mehr Speicher hinzufügen. Die Idee ist, den internen RAM als Cache und den externen RAM als Speicher zu verwenden, während ich die Blöcke verarbeite. So wie ich das sehe, habe ich 50 ms Zeit, um die Daten zu codieren und zu verschieben. Ich habe 300 KB Daten. Wenn ich 20fps erreichen kann, ist das erstaunlich.
Ktuncer

1
@Ktuncer: Wie viel Zeit werden Sie verwenden, um Pixel von einem externen RAM einzuziehen und wieder zurückzuschieben? Gibt es einen DMA zwischen ext & int Speicher?
Martin Thompson

Ja .. Ich werde DMA verwenden, um von der Kamera -> externen Speicher, einen anderen DMA zu externen Speicher -> internen Speicher.
Ktuncer

Die von Martin erwähnte Open-Source-JPG-Bibliothek heißt IJG. Link: ijg.org
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.