DE112014004432T5 - Parallele Hardware- und Software-Blockverarbeitungspipelines - Google Patents

Parallele Hardware- und Software-Blockverarbeitungspipelines Download PDF

Info

Publication number
DE112014004432T5
DE112014004432T5 DE112014004432.6T DE112014004432T DE112014004432T5 DE 112014004432 T5 DE112014004432 T5 DE 112014004432T5 DE 112014004432 T DE112014004432 T DE 112014004432T DE 112014004432 T5 DE112014004432 T5 DE 112014004432T5
Authority
DE
Germany
Prior art keywords
block
pipeline
stage
component
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112014004432.6T
Other languages
English (en)
Inventor
James E. Orr
Timothy John Millet
Joseph J. Cheng
Nitin Bhargava
Guy Cote
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Inc filed Critical Apple Inc
Publication of DE112014004432T5 publication Critical patent/DE112014004432T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/43—Hardware specially adapted for motion estimation or compensation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/43—Hardware specially adapted for motion estimation or compensation
    • H04N19/433—Hardware specially adapted for motion estimation or compensation characterised by techniques for memory access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Image Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Image Generation (AREA)

Abstract

Eine Blockverarbeitungspipeline, die eine Softwarepipeline und eine Hardwarepipeline einschließt, die parallel ausgeführt werden. Die Softwarepipeline wird der Hardwarepipeline mindestens einen Block voraus ausgeführt. Die Stufen der Pipeline können jeweils eine Hardwarepipelinekomponente aufweisen, die eine oder mehrere Operationen an einem aktuellen Block in der Stufe ausführt. Mindestens eine Stufe der Pipeline kann zudem eine Softwarepipelinekomponente einschließen, die eine Konfiguration für die Hardwarekomponente in der Stufe der Pipeline zum Verarbeiten eines nächsten Blocks ermittelt, während die Hardwarekomponente der aktuellen Block verarbeitet. Die Softwarepipelinekomponente kann die Konfiguration gemäß Informationen bezüglich des nächsten Blocks verarbeiten, die aus einer vorgeschalteten Stufe der Pipeline erhalten werden. Die Softwarepipelinekomponente kann zudem Informationen bezüglich eines Blocks erhalten, der zuvor in der Stufe verarbeitet wurde.

Description

  • HINTERGRUND
  • Technisches Gebiet
  • Diese Offenbarung betrifft allgemein die Video- bzw. Bildverarbeitung und insbesondere Verfahren und Einrichtungen zum Verarbeiten digitaler Video-Frames in Blockverarbeitungspipelines.
  • Beschreibung der verwandten Technik
  • Verschiedene Vorrichtungen, darunter Personal Computersysteme, Desktop-Computersysteme, Laptop- und Notebook-Computer, Tablet- oder Pad-Geräte, Digitalkameras, digitale Videorecorder und Mobiltelefone oder Smartphones, ohne darauf beschränkt zu sein, können Software und/oder Hardware enthalten, die ein Videoverarbeitungsverfahren implementieren kann. Beispielsweise kann eine Vorrichtung eine Einrichtung (z. B. eine integrierte Schaltung (IC), wie etwa ein System-on-Chip (SOC), oder ein Teilsystem einer IC) aufweisen, die digitale Videoeingaben von einer oder mehreren Quellen empfangen und verarbeiten kann und die verarbeiteten Video-Frames entsprechend einem oder mehreren Videoverarbeitungsverfahren ausgibt. Als ein anderes Beispiel, ein Softwareprogramm kann auf einem Gerät implementiert sein, das digitale Videoeingaben von einer oder mehreren Quellen empfangen und verarbeiten kann und die verarbeiteten Video-Frames entsprechend einem oder mehreren Videoverarbeitungsverfahren ausgibt. Als ein Beispiel stellt ein Videocodierer 10, wie in 1 gezeigt, eine Einrichtung oder alternativ ein Softwareprogramm dar, bei dem digitale Videoeingaben (Eingabe-Frames 90) entsprechend einem Videocodierungsverfahren in ein anderes Format (Ausgabe-Frames 92) codiert oder konvertiert werden, beispielsweise ein komprimiertes Videoformat wie etwa H.264/ein der fortgeschrittenen Videocodierung (AVC: Advanced Video Coding) entsprechendes Format (auch als MPEG 4 Part 10 bezeichnet). Eine Einrichtung oder Softwareprogramm, wie etwa ein Videocodierer 10, kann sowohl mehrere Funktionsbausteine oder -einheiten als auch externe Schnittstellen zu beispielsweise Videoeingabequellen und externem Speicher aufweisen.
  • Bei einigen Videoverarbeitungsverfahren wird, um die Verarbeitung durchzuführen, jedes Eingabe-Video-Frame 90 in Zeilen und Spalten von Pixelblöcken (z. B. 16×16-Pixelblöcke) unterteilt, beispielsweise wie in 2 veranschaulicht, wo ein beispielhaftes Frame mit 192×192 Pixel in 144 16×16-Pixelblöcke unterteilt ist. Jeder Block eines Eingabe-Video-Frame 90 wird separat verarbeitet und anschließend werden die verarbeiteten Blöcke kombiniert, um das Ausgabe-Video-Frame 92 zu bilden. Dies kann als Blockverarbeitungsverfahren bezeichnet werden. Herkömmlicherweise werden die Blöcke durch das Blockverarbeitungsverfahren in Abtastreihenfolge, wie in 2 gezeigt, beginnend mit dem ersten Block der ersten Zeile des Frames (als Block 0 dargestellt) verarbeitet, wobei der Reihe nach die Blöcke in der Zeile verarbeitet werden und, wenn eine Zeile komplett ist, mit dem ersten Block der nächsten Zeile fortgesetzt wird.
  • Ein Blockverarbeitungsverfahren kann mehrere Verarbeitungsschritte oder -operationen umfassen, die der Reihe nach auf jeden Block in einem Video-Frame angewendet werden. Um ein solches Blockverarbeitungsverfahren zu implementieren, kann eine Einrichtung oder ein Softwareprogramm, wie etwa ein Videocodierer 10, eine Blockverarbeitungspipeline 40 aufweisen oder implementieren. Eine Blockverarbeitungspipeline 40 kann zwei oder mehr Stufen aufweisen, wobei jede Stufe einen oder mehrere der Schritte bzw. eine oder mehrere der Operationen des Blockverarbeitungsverfahrens implementiert. 1 zeigt einen beispielhaften Videocodierer 10, der eine beispielhafte Blockverarbeitungspipeline 40 implementiert, die mindestens die Stufen 42A bis 42C aufweist. Ein Block wird in eine Stufe 42A der Pipeline 40 eingegeben, entsprechend der von der Stufe 42A implementierten Operation(en) verarbeitet, und die Ergebnisse werden an die nächste Stufe 42B (bzw. als fertig von der letzten Stufe 42) ausgegeben. Die nächste Stufe 42B verarbeitet den Block, während in die vorhergehende Stufe 42A ein nächster Block zum Verarbeiten eingegeben wird. So bewegen sich die Blöcke von Stufe zu Stufe durch die Pipeline, wobei jede Stufe jeweils einen Block verarbeitet und mehrere Stufen gleichzeitig verschiedene Blöcke verarbeiten. Herkömmlich werden die Blöcke in Abtastreihenfolge, wie in 2 gezeigt, in die Blockverarbeitungspipeline 40 eingegeben und von dieser verarbeitet. Beispielsweise befindet sich in 1 der erste Block der ersten Zeile des in 2 gezeigten Frames (Block 0) in der Stufe 42C, der zweite Block (Block 1) befindet sich in der Stufe 42B und der dritte Block (Block 2) befindet sich in der Stufe 42A. Der nächste Block, der in die Blockverarbeitungspipeline 40 einzugeben ist, wird der vierte Block in der ersten Zeile sein.
  • H.264/Fortgeschrittene Videocodierung (AVC)
  • H.264/AVC (offiziell als ITU-T-Empfehlung H.264 bezeichnet und auch als MPEG-4 Part 10 bezeichnet) ist ein blockorientierter bewegungskompensationsbasierter Codec-Standard, entwickelt von der Video Coding Experts Group (VCEG) der ITU-T (International Telecommunications Union – Telecommunication Standardization Sector) in Zusammenarbeit mit der Moving Picture Experts Group (MPEG) der ISO/IEC JTC1. Der H.264/AVC-Standard wurde von der ITU-T in einem Dokument mit dem Titel „ITU-T Recommendation H.264: Advanced video coding for generic audiovisual services” veröffentlicht. Dieses Dokument wird mitunter auch als H.264-Empfehlung bezeichnet.
  • ÜBERBLICK ÜBER AUSFÜHRUNGSFORMEN
  • Es sind Ausführungsformen von Blockverarbeitungsverfahren und -einrichtungen beschrieben, wobei eine Blockverarbeitungspipeline eine Softwarepipeline und eine Hardwarepipeline, die parallel arbeiten, aufweist. Die Softwarepipeline eilt jedoch der Hardwarepipeline um einen Block oder mehrere Blöcke voraus. Die Stufen der Pipeline können jeweils eine Hardwarepipelinekomponente aufweisen, die eine oder mehrere Operationen an einem aktuellen Block in der Stufe ausführt. Mindestens eine Stufe der Pipeline kann auch eine Softwarepipelinekomponente aufweisen, die eine Konfiguration für die Hardware-Komponente auf der Stufe der Pipeline für ein Verarbeiten eines kommenden Blocks (z. B. des nächsten Blocks) bestimmt, während die Hardware-Komponente den aktuellen Block verarbeitet. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auf einer Stufe die Konfiguration für ein Verarbeiten des nächsten Blocks in der Stufe entsprechend der den nächsten Block betreffenden Informationen, erhalten von einer vorgeschalteten Stufe der Pipeline, ermitteln. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auch Informationen, die mit einem Block in Beziehung stehen, der zuvor in der Stufe verarbeitet wurde, erhalten und verwenden, um die Konfiguration für ein Verarbeiten des nächsten Blocks zu ermitteln. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auf einer Stufe Information vom Verarbeiten eines Blocks oder von Blöcken in der Stufe erhalten und die Informationen an eine oder mehrere vorgeschaltete Stufen der Pipeline zurückgeben, um diese vorgeschalteten Stufen für ein Verarbeiten aktueller oder kommender Blöcke zu konfigurieren. Zudem kann in mindestens einigen Ausführungsformen eine Softwarepipelinekomponente am oder nahe am Ende der Pipeline Blockverarbeitungsergebnisse oder statistische Angaben an eine andere Softwarepipelinekomponente am oder nahe am Anfang der Pipeline zurückgeben und zwar für eine Verwendung beim Verarbeiten kommender Blöcke in der Pipeline.
  • In mindestens einigen Ausführungsformen empfängt eine Softwarepipelinekomponente auf einer Stufe Blockinformationen für einen nächsten Block von einer vorgeschalteten Stufe. Außerdem kann die Softwarepipelinekomponente auch Informationen von einem Block des Frames empfangen, das zuvor in der Stufe verarbeitet wurde. Die Softwarepipelinekomponente kann eine Konfiguration für den Block entsprechend der empfangenen Informationen für den Block ermitteln, die Konfiguration für den Block in einen Konfigurationsspeicher schreiben und ein „Los”-Bit (GO) oder anderweitiges Signal für die Hardwarepipelinekomponente auf der Stufe setzen, das angibt, dass die Konfiguration für den nächsten Block im Konfigurationsspeicher bereitsteht. Die Softwarepipelinekomponente kann dann die Blockinformationen für den Block zu einer nachgeschalteten Stufe schieben.
  • Die Hardwarepipeline-Komponente auf der Stufe empfängt Blöcke von einer früheren Stufe. Wenn die Hardwarepipelinekomponente bereit ist, den nächsten Block zu verarbeiten, der nächste Block im Speicher bereitsteht und die Softwarepipelinekomponente der Hardwarepipelinekomponente signalisiert hat, dass eine Konfiguration für den nächsten Block im Konfigurationsspeicher bereitsteht, dann kann die Hardwarepipelinekomponente beginnen, den nächsten Block zu verarbeiten. Die Hardwarepipelinekomponente stellt die Konfiguration für ein Verarbeiten des nächsten Blocks entsprechend der Konfiguration im Konfigurationsspeicher ein und signalisiert der Softwarepipelinekomponente, dass der Konfigurationsspeicher zur Verfügung steht. Die Hardwarepipelinekomponente verarbeitet dann den Block gemäß der Konfiguration für den Block und schreibt den verarbeiteten Block in die nächste Stufe.
  • Die vorstehenden Operationen der Softwarepipelinekomponente und der Hardwarepipelinekomponente in einer Stufe der Pipeline können in der Stufe wiederholt werden, bis alle Blöcke eines Eingabe-Frame in der Stufe verarbeitet worden sind.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 veranschaulicht einen beispielhaften Videocodierer, der eine herkömmliche Blockverarbeitungspipeline umfasst, die Blöcke von Eingabe-Frames in Abtastreihenfolge verarbeitet.
  • 2 veranschaulicht ein herkömmliches in Abtastreihenfolge erfolgendes Verarbeiten von Blöcken von einem Video-Frame.
  • 3 ist ein High-Level-Blockdiagramm einer beispielhaften Blockverarbeitungspipeline, die eine Softwarepipeline und eine Hardwarepipeline implementiert, entsprechend mindestens einigen Ausführungsformen.
  • 4A bis 4C veranschaulichen, entsprechend mindestens einigen Ausführungsformen, ein Verarbeiten von Blöcken in einer Stufe in einer beispielhaften Blockverarbeitungspipeline, die eine Softwarepipeline und eine Hardwarepipeline implementiert.
  • 5 veranschaulicht, entsprechend mindestens einigen Ausführungsformen, eine beispielhafte Blockverarbeitungspipeline, die eine Softwarepipeline und eine Hardwarepipeline implementiert, wobei durch die Softwarepipeline mindestens eine Stufe übersprungen wird.
  • 6 veranschaulicht, entsprechend mindestens einigen Ausführungsformen, eine beispielhafte Blockverarbeitungspipeline, die eine Softwarepipeline und eine Hardwarepipeline implementiert, wobei mindestens eine Stufe mehrere Pipelineeinheiten umfasst.
  • 7 veranschaulicht, entsprechend mindestens einigen Ausführungsformen, eine beispielhafte Pipelineeinheit, die auf einer Stufe einer Blockverarbeitungspipeline verwendet werden kann, die eine Softwarepipeline und eine Hardwarepipeline implementiert.
  • 8A und 8B sind, entsprechend mindestens einigen Ausführungsformen, Ablaufdiagramme von Verfahren zum Betrieb einer Softwarepipeline und einer Hardwarepipeline, die in einer Blockverarbeitungspipeline parallel arbeiten.
  • 9 zeigt Nachbarblöcke eines aktuellen Blocks in einem Frame, und veranschaulicht ferner ein Rösselsprung-Verarbeitungsverfahren für die Blöcke entsprechend mindestens einigen Ausführungsformen.
  • 10A und 10B veranschaulichen graphisch das Rösselsprung-Verarbeitungsverfahren einschließlich des Algorithmus zum Ermitteln eines nächsten Blocks entsprechend mindestens einigen Ausführungsformen.
  • 11A und 11B sind High-Level-Ablaufdiagramme eines Rösselsprung-Verarbeitungsverfahrens für eine Blockverarbeitungspipeline entsprechend mindestens einigen Ausführungsformen.
  • 12 zeigt einen Teil einer Viererzeile (Engl. Quadrow), wie sie in einer Pipeline gemäß dem Rösselsprung-Verarbeitungsverfahren verarbeitet wird und die in dem Puffer für die aktuelle Viererzeile zwischengespeichert werden kann, entsprechend mindestens einigen Ausführungsformen.
  • 13 veranschaulicht graphisch Blöcke in einer aktuellen Viererzeile, die gerade gemäß dem Rösselsprung-Verarbeitungsverfahren verarbeitet wird, wie auch Nachbarblöcke in der letzten Zeile der vorhergehenden Viererzeile, die in einem Puffer für die vorhergehende Viererzeile zwischengespeichert sein kann, entsprechend mindestens einigen Ausführungsformen.
  • 14 ist ein Ablaufdiagramm eines Verfahrens zum Verarbeiten von Blöcken in einer Blockverarbeitungspipeline, wobei auf den Stufen der Pipeline Nachbardaten in lokalen Puffer zwischengespeichert werden, entsprechend mindestens einigen Ausführungsformen.
  • 15A und 15B sind Blockdiagramme für beispielhafte Pipeline-Verarbeitungseinheiten, die auf den Stufen einer Blockverarbeitungspipeline verwendet werden können, die eine oder mehrere der Blockverarbeitungsverfahren und -einrichtungen, wie hier beschrieben, implementiert, entsprechend mindestens einigen Ausführungsformen.
  • 15C zeigt, dass einer Gruppe von zwei oder mehr Pipelineeinheiten ein einziger Prozessor zugeordnet sein kann.
  • 16 ist ein High-Level-Blockdiagramm für die allgemeine Arbeitsweise bei einem beispielhaften Blockverarbeitungsverfahren, das von einer Blockverarbeitungspipeline implementiert werden kann, die eine oder mehrere der Blockverarbeitungsverfahren und -einrichtungen, wie hier beschrieben, implementiert, entsprechend mindestens einigen Ausführungsformen.
  • 17 ist ein Blockdiagramm einer beispielhaften Videocodierereinrichtung entsprechend mindestens einigen Ausführungsformen.
  • 18 ist ein Blockdiagramm einer Ausführungsform eines Systems-on-Chip (SOC).
  • 19 ist ein Blockdiagramm einer Ausführungsform eines Systems.
  • Obwohl die Erfindung in verschiedenen Abwandlungen und alternativen Formen auftreten kann, sind konkrete Ausführungsformen davon beispielhaft in der Zeichnung dargestellt und werden hier im Detail beschrieben. Es versteht sich jedoch, dass die Zeichnung und die detaillierte Beschreibung dazu die Erfindung nicht auf die konkrete offenbarte Form beschränken sollen, sondern im Gegenteil, es ist beabsichtigt, sämtliche Abwandlungen, Äquivalente und Alternativen abzudecken, die unter den Erfindungsgedanken und in den Schutzbereich der vorliegenden Erfindung, wie durch die beigefügten Ansprüche definiert, fallen. Wie in dieser Anmeldung verwendet, wird das Wort „können” im ermöglichenden Sinn verwendet (d. h. das Potential aufweisend) und nicht im zwingenden Sinn (d. h. im Sinne von müssen). Ähnlich bedeuten die Wörter „aufweisen”, „enthalten”, „einschließen” einschließlich, sind jedoch nicht darauf beschränkt.
  • Verschiedene Einheiten, Schaltungen oder andere Komponenten können als zum Durchführen einer oder mehrerer Aufgaben bzw. Tasks „konfiguriert” beschrieben sein. In solchen Kontexten ist „konfiguriert” eine weit gefasste Darstellung von Struktur, die generell bedeutet, „Schaltungen aufweisend, die” den Task oder die Tasks während des Betriebs ausführen. Somit kann die Einheit/Schaltung/Komponente so konfiguriert sein, dass sie den Task ausführt, auch wenn die Einheit/Schaltung/Komponente derzeit nicht eingeschaltet ist. Im Allgemeinen können die Schaltungen, die die Struktur bilden, die „konfiguriert” entspricht, Hardware-Schaltungen einschließen. Ähnlich können verschiedene Einheiten/Schaltungen/Komponenten aus praktischen Gründen in der Beschreibung so beschrieben sein, dass sie einen Task oder Tasks ausführen. Solche Beschreibungen sollten so ausgelegt werden, als würden sie den Ausdruck „konfiguriert” enthalten. Das Nennen einer Einheit/Schaltung/Komponente, die zum Ausführen eines oder mehrerer Tasks konfiguriert ist, soll ausdrücklich nicht nach 35 USC § 112, Paragraph 6 für die Einheit/Schaltung/Komponente gedeutet werden.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung sind zahlreiche spezifische Einzelheiten dargelegt, um für ein umfassendes Verständnis der vorliegenden Erfindung zu sorgen. Dem Fachmann wird jedoch offensichtlich sein, dass die Erfindung ohne diese spezifischen Einzelheiten ausgeübt werden kann. In einigen Fällen sind allgemein bekannte Schaltungen, Strukturen und Techniken nicht im Detail dargestellt worden, um ein Verschleiern der vorliegenden Erfindung zu vermeiden.
  • Es sind verschiedene Ausführungsformen von Verfahren und Einrichtungen zum Verarbeiten digitaler Video-Frames in Blockverarbeitungspipelines beschrieben. Ausführungsformen von Blockverarbeitungsverfahren und -einrichtungen werden hier in allgemeiner Weise im Kontext einer Videoverarbeitung beschrieben, wobei Eingabe-Video-Frames in Blöcke von Elementen (z. B. 16×16-, 32×32- oder 64×64-Pixelblöcke) unterteilt und entsprechend diesen Blöcken verarbeitet werden. Es werden hier Ausführungsformen eines beispielhaften Videocodierers nach H.264 beschrieben, der eine Blockverarbeitungspipeline umfasst und der ein(en) oder mehrere der Blockverarbeitungsverfahren und -einrichtungen implementieren kann. Der H.264-Videocodierer konvertiert Eingabe-Video-Frames aus einem Eingabeformat in das H.264/AVC-Format, wie im H.264/AVC-Standard (der H.264-Empfehlung) beschrieben. 16 veranschaulicht eine beispielhafte Blockverarbeitungspipeline eines beispielhaften H.264-Videocodierers, und 17 veranschaulicht einen beispielhaften H.264-Videocodierer, der eine Blockverarbeitungspipeline umfasst. Ausführungsformen der Blockverarbeitungsverfahren und -einrichtungen können jedoch in Codierern für andere Videocodierungsformate verwendet werden, beispielsweise in Blockverarbeitungspipelines von HEVC-(High Efficiency Video Encoding)Videocodierern, die Eingabe-Video-Frames aus einem Eingabeformat in das HEVC-Format, wie im HEVC-Standard beschrieben, konvertieren. Weitere Videocodierer, die Ausführungsformen der Blockverarbeitungsverfahren und -einrichtungen verwenden können, sind u. a., ohne darauf beschränkt zu sein, H.263-, MPEG-2-, MPEG-4- und JPEG-2000-Videocodierer. Es ist jedoch darauf hinzuweisen, dass Ausführungsformen der Blockverarbeitungsverfahren und -einrichtungen in jeder Blockverarbeitungspipeline verwendet werden können, einschließlich, jedoch nicht beschränkt auf, Blockverarbeitungspipelines, die in verschiedenen anderen Videocodierern und/oder Video-Decodierern (die auch als Codecs bezeichnet werden können) implementiert sind, wobei digitale Video-Frames, die in einem Format eingegeben werden, in ein anderes Format codiert oder konvertiert werden. Ferner ist zu beachten, dass die Blockverarbeitungsverfahren und -einrichtungen in Software- und/oder Hardware-Implementierungen von Videocodierern verwendet werden können. Über Videocodierer/Decoder hinausgehend können die hier beschriebenen Blockverarbeitungsverfahren und -einrichtungen bei verschiedenen anderen Anwendungen verwendet werden, bei denen Blöcke von einem Video-Frame oder einem digitalen Standbild verarbeitet werden, beispielsweise in Pipelines, die bei verschiedenen Bildbearbeitungsanwendungen digitale Standbilder verarbeiten. Demnach versteht sich, dass der Begriff Frame oder Video-Frame, wie hier gebraucht, auch verwendet werden kann, um irgendein digitales Bild zu bezeichnen.
  • Ausführungsformen der Blockverarbeitungsverfahren und -einrichtungen, wie hier beschrieben, können in zwei oder mehreren parallelen Blockverarbeitungspipelines implementiert sein. Beispielsweise können 2, 4, 8 oder mehr Pipelines dafür konfiguriert sein, parallel zu arbeiten, wobei jede Pipeline eine Viererzeile von einem Eingabe-Video-Frame verarbeitet, wobei beispielsweise die Blöcke in einer einem Rösselsprung entsprechenden Reihenfolge eingegeben werden.
  • Ausführungsformen der Blockverarbeitungsverfahren und -einrichtungen werden hier in allgemeiner Weise im Kontext der Videoverarbeitung beschrieben, wobei Eingabe-Frames in Blöcke von Bildelementen (auch als Pixel oder PELs bezeichnet) unterteilt und entsprechend diesen Blöcken verarbeitet werden, insbesondere 16×16-Pixelblöcke, auch als Makroblöcke bezeichnet, die beispielsweise bei einer H.264-Codierung verwendet werden. Jedoch können Ausführungsformen bei Pipelines angewendet werden, bei denen Blöcke anderer Größen und Geometrien oder aus anderen Elementen verarbeitet werden. Beispielsweise verwendet eine HEVC-Codierung Blöcke, auch als Coding Tree Units (CTUs) bezeichnet, die innerhalb des Bereichs von 16×16 Pixel bis 64×64 Pixel variieren können. Bei einigen Implementierungen, wie etwa H.264 Codierern, können die Blöcke, die in die Pipeline eingegeben werden, als Makroblöcke bezeichnet werden, wobei jeder Makroblock zwei oder mehr Blöcke oder Teilbereiche aufweist, die auf den Stufen der Pipeline separat verarbeitet werden können. Beispielsweise kann bei Eingabe-Video-Frames, die im YUV-(z. B. YUV420-Format) oder YCbCr-(z. B. die Formate YCbCr 4:2:0, 4:2:2 oder 4:4:4) Farbraum codiert sind, ein Makroblock aus separaten Blöcken von Chroma- und Luma-Elementen gebildet sein, die in den Stufen in einer Pipeline separat verarbeitet werden können. Über Anwendungen, bei denen Frames in einer Pipeline entsprechend Blöcken von Elementen (z. B. Blöcken von Pixeln) verarbeitet werden, hinaus können die Blockverarbeitungsverfahren und -einrichtungen bei Anwendungen eingesetzt werden, bei denen digitale Bilder (z. B. Video-Frames oder Standbilder) einzelelementweise (z. B. pixelweise) verarbeitet werden.
  • Parallele Hardware- und Software-Blockverarbeitungspipelines
  • Es sind Ausführungsformen von Blockverarbeitungsverfahren und -einrichtungen beschrieben, wobei eine Blockverarbeitungspipeline eine Softwarepipeline und eine Hardwarepipeline, die parallel arbeiten, aufweist. Die Softwarepipeline eilt jedoch der Hardwarepipeline um einen Block oder mehrere Blöcke voraus. Die Stufen der Pipeline können jeweils eine Hardwarepipelinekomponente aufweisen, (z. B. eine Schaltung) die eine oder mehrere Operationen an einem aktuellen Block in der Stufe ausführt. Mindestens eine Stufe der Pipeline kann auch eine Softwarepipelinekomponente aufweisen, die eine Konfiguration für die Hardware-Komponente auf der Stufe der Pipeline für ein Verarbeiten eines kommenden Blocks (z. B. des nächsten Blocks) bestimmt, während die Hardware-Komponente den aktuellen Block verarbeitet. Die Softwarepipelinekomponente kann mindestens einen Prozessor umfassen. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auf einer Stufe die Konfiguration für ein Verarbeiten des nächsten Blocks in der Stufe entsprechend der den nächsten Block betreffenden Informationen, erhalten von einer vorgeschalteten Stufe der Pipeline, ermitteln. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auch Informationen, die mit einem Block in Beziehung stehen, der zuvor in der Stufe verarbeitet wurde, erhalten und verwenden, um die Konfiguration für ein Verarbeiten des nächsten Blocks zu ermitteln. In mindestens einigen Ausführungsformen kann die Softwarepipeline auch einen Block oder mehrere Blöcke (stromaufwärts) „vorausschauen”, um Informationen von kommenden Blöcken zu erhalten, die verwendet werden können, um die Konfigurationen für ein Verarbeiten der nächsten Blöcke auf den Stufen zu ermitteln. Die Softwarepipelinekomponenten können statistische Angaben für einen Block oder mehrere Blöcke generieren, die verwendet werden, um die Konfigurationen zu ermitteln. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auf einer Stufe Information vom Verarbeiten eines Blocks oder von Blöcken in der Stufe erhalten und die Informationen an eine oder mehrere vorgeschaltete Stufen der Pipeline zurückgeben, um diese vorgeschalteten Stufen für ein Verarbeiten aktueller oder kommender Blöcke zu konfigurieren. Zudem kann in mindestens einigen Ausführungsformen eine Softwarepipelinekomponente am oder nahe am Ende der Pipeline Blockverarbeitungsergebnisse oder statistische Angaben an eine andere Softwarepipelinekomponente am oder nahe am Anfang der Pipeline zurückgeben und zwar für eine Verwendung beim Verarbeiten kommender Blöcke in der Pipeline.
  • Die Blockinformationen, die von einer Softwarepipelinekomponente auf einer Stufe erhalten werden und verwendet werden, um eine Konfiguration für ein Verarbeiten eines nächsten Blocks in der Stufe zu ermitteln, können beispielsweise verschiedene statistische Angaben im Zusammenhang mit dem Block und/oder einem oder mehreren anderen Blöcken enthalten. Im Folgenden werden Beispiele für Blockstatistikangaben gegeben, die in Ausführungsformen verwendet werden können, was jedoch nicht als beschränkend auszulegen ist:
    • • Summe der Pixel (s).
    • • Summe der Pixel ins Quadrat erhoben (s2).
    • • Blockvarianz (kann aus s und s2 geschätzt werden, z. B. var = s2 – (s)^2).
    • • Horizontaler und vertikaler Gradient (Gx und Gy).
    • • Gradientenhistogramme für Gx und Gy.
  • Die Operationen, die von den Hardwarepipelinekomponenten auf den verschiedenen Stufen ausgeführt werden, können variieren und dementsprechend kann die Konfiguration für die Hardwarepipelinekomponenten auf den Stufen variieren. Folglich können die Softwarepipelinekomponenten auf den Stufen bestimmte Konfigurationsparameter entsprechend den jeweiligen Hardwarepipelinekomponenten auf den Stufen ermitteln und einstellen. Nachstehend ist jedoch ein allgemeines und nicht als beschränkend auszulegendes Beispiel für Konfigurationsparameter angegeben, die auf einer Stufe durch die Softwarepipelinekomponente auf der Grundlage einer Analyse der Informationen bestimmt und eingestellt werden können.
  • Eine oder mehrere Stufen einer Pipeline können Operationen ausführen, um eine optimale Betriebsweise zum Verarbeiten von Pixeln in einem gegebenen Block zu ermitteln. Auf einer bestimmten Stufe kann die Hardwarepipelinekomponente Informationen von einer oder mehreren vorgeschalteten Stufen (und möglicherweise Feedback von einer oder mehreren nachgeschalteten Stufen) empfangen und diese Informationen verwenden, um eine bestimmte von mehreren Betriebsweisen auszuwählen. Die Softwarepipelinekomponente auf dieser Stufe kann auf den Block bezogene statistische Angaben (z. B. Blockvarianz) empfangen, generieren und analysieren und einen oder mehrere Konfigurationsparameter gemäß der Analyse, beispielsweise, derart einstellen, dass die Hardwarepipelinekomponente veranlasst wird, mehrere Betriebsweisen auszuprobieren, wenn die Blockvarianz hoch ist, oder die Hardware-Komponente auf eine bestimmte Betriebsweise oder bestimmte Betriebsweisen voreinzustellen, wenn die Blockvarianz niedrig ist.
  • In mindestens einigen Ausführungsformen kann eine Blockverarbeitungspipeline, die parallele Software- und Hardwarepipelines implementiert, Blöcke in einer einem Rösselsprung entsprechenden Reihenfolge eingeben und in den Pipelines verarbeiten, wie im Abschnitt Rösselsprung-Verarbeitung beschrieben. Jedoch können in einigen Ausführungsformen andere Reihenfolgen für Blockeingabe und -verarbeitung verwendet werden. In mindestens einigen Ausführungsformen kann mindestens eine Stufe einer Blockverarbeitungspipeline, die parallele Software- und Hardwarepipelines implementiert, einen oder mehrere lokale Puffer zum Zwischenspeichern von Daten von Nachbarblöcken in der Stufe implementieren, wie im Abschnitt Zwischenspeicherung von Nachbardaten beschrieben.
  • 3 ist ein High-Level-Blockdiagramm einer beispielhaften Blockverarbeitungspipeline 300, die eine Softwarepipeline 302 und eine Hardwarepipeline 304 implementiert, entsprechend mindestens einigen Ausführungsformen. Die Softwarepipeline 302 und die Hardwarepipeline 304 verarbeiten Blöcke von einem Frame parallel, wobei die Softwarepipeline 302 der Hardwarepipeline 304 um mindestens einen Block voraus ist. Die Pipeline 300 kann mehrere Stufen 320 aufweisen, wobei jede Stufe dafür konfiguriert ist, an einem Block von Pixeln von einem Frame (z. B. einem Video-Frame) eine oder mehrere Operationen auszuführen. Mindestens einige der Stufen (Stufen 320A und 320B in 3) können jeweils mindestens eine Pipelineeinheit 330 umfassen, die eine Softwarepipelinekomponente 322 und eine Hardwarepipelinekomponente 326 umfasst. Die Hardwarepipelinekomponente 326 jeder Pipelineeinheit 330 kann eine oder mehrere bestimmte Operationen eines Blockverarbeitungsverfahrens an einem Block ausführen, der aktuell in der Stufe 320 in der Hardwarepipeline 304 ist. Während die Hardwarepipelinekomponente 326 einer gegebenen Pipelineeinheit 330 an dem aktuellen Block in der Stufe 320 arbeitet, kann die Softwarepipelinekomponente 322 der Pipelineeinheit 330 auf der Stufe 320 die Hardwarepipelinekomponente 326 für ein Verarbeiten eines kommenden Blocks, welcher der nächste Block sein kann, vorkonfigurieren. Demzufolge arbeitet die Softwarepipeline 302 einen Block oder mehrere Blöcke vor der Hardwarepipeline 304.
  • Beispielsweise, wie in 3 gezeigt, verarbeitet in der Stufe 320B die Hardwarepipelinekomponente 326B aktuell den Block i, während die Softwarepipelinekomponente 322A gerade die Hardwarepipelinekomponente 326B für die Verarbeitung des Blocks i + 1 konfiguriert, und in der Stufe 320A verarbeitet die Hardwarepipelinekomponente 326A aktuell den Block i + 1, während die Softwarepipelinekomponente 322A gerade die Hardwarepipelinekomponente 326A für die Verarbeitung des Blocks i + 2 konfiguriert.
  • Die Softwarepipelinekomponente 322 einer Pipelineeinheit 330 auf einer Stufe 320 kann eine Konfiguration für ein Verarbeiten eines kommenden Blocks (z. B. eines nächsten Blocks) in der Hardwarepipelinekomponente 326 der jeweiligen Pipelineeinheit 330 entsprechend den Informationen für den Block ermitteln. Die Informationen für den Block können mindestens Blockinformationen umfassen, die von einer vorgeschalteten Stufe erhalten wurden. In mindestens einigen Ausführungsformen können die Informationen auch Feedback-Informationen von einem oder mehreren Blöcken einschließen, die zuvor in der Stufe 320 verarbeitet wurden. Die Softwarepipelinekomponente 322 kann die Hardwarepipelinekomponente 326 der Pipelineeinheit 330 auf der Stufe 320 für ein Verarbeiten des Blocks entsprechend der bestimmten Konfiguration vorkonfigurieren, beispielsweise durch Festsetzen eines oder mehrerer Konfigurationswerte in einem Satz von Registern oder anderem Speicher, der an die Hardwarepipelinekomponente 326 gekoppelt ist. Sobald die Konfiguration für ein Verarbeiten des Blocks in der Hardwarepipelinekomponente 326 der Pipelineeinheit 330 bereit ist, kann die Softwarepipelinekomponente 322 dies der Hardwarepipelinekomponente 326 der Pipelineeinheit 330 signalisieren. Angenommen, die Hardwarepipelinekomponente 326 hat das Verarbeiten eines vorhergehenden Blocks abgeschlossen und der nächste Block ist für die Hardwarepipelinekomponente 326 verfügbar (z. B. bereit, aus seinem Puffer gelesen zu werden), dann kann die Hardwarepipelinekomponente 326 der Pipelineeinheit 330 beginnen, den nächsten Block entsprechend der Konfiguration für den Block, die von der Softwarepipelinekomponente 322 der Pipelineeinheit 330 bestimmt und vorkonfiguriert wurde, zu verarbeiten.
  • In mindestens einigen Ausführungsformen kann eine Anfangsstufe 310 der Pipeline Blockinformationen in die Softwarepipeline 302 und Blöcke in die Hardwarepipeline 304 eingeben. Die Anfangsstufe 310 kann eine Blockeingabe erhalten, beispielsweise mittels eines direkten Speicherzugriffs (DMA) aus einem externen Speicher, und die Blöcke in einer Blockpufferkomponente 312 zwischenspeichern. Die Blockpufferkomponente 312 kann dafür ausgelegt sein, einen, zwei oder mehrere Blöcke zu halten. Beispielsweise kann die Blockpufferkomponente 312 in einigen Ausführungsformen imstande sein, 16 Blöcke zwischenzuspeichern. In mindestens einigen Ausführungsformen kann die Blockpufferkomponente 312 einen, zwei oder mehrere Blöcke für eine Eingabe in die Hardwarepipeline 304 zwischenspeichern, bevor die Anfangsstufe 310 mit der Eingabe von Blöcken in die Hardwarepipeline 304 beginnt. In mindestens einigen Ausführungsformen kann, sobald die Anfangsstufe 310 mit der Eingabe von Blöcken in die Hardwarepipeline 304 beginnt, die Anfangsstufe 310 einen nächsten Block von der Blockpufferkomponente 312 in einen Pufferspeicher der Hardwarepipelinekomponente 326A der Pipelineeinheit 330A auf der Stufe 320A schreiben, wenn die Pipelineeinheit 330A bereit ist, den nächsten Block zu empfangen. Die Anfangsstufe 310 kann weiterhin Blockeingaben für ein Frame empfangen, die Blöcke in der Blockpufferkomponente 312 zwischenspeichern und Blöcke in die Hardwarepipeline 304 eingeben, bis alle Blöcke in dem Frame verarbeitet sind.
  • Eine Blockanalysekomponente 314 auf der Anfangsstufe 310 kann eine oder mehrere Analysefunktionen an einem oder mehreren Blöcken ausführen, die aktuell in der Blockpufferkomponente 312 zwischengespeichert sind, u. a. an einem nächsten Block, der in die Hardwarepipeline 304 einzugeben ist, um Blockinformationen für den nächsten Block zu generieren. Die Blockinformationen können beispielsweise eine oder mehrere Blockstatistikangaben umfassen. Einige nicht einschränkende Beispiele für Blockstatistikangaben, die generiert werden können, wurden bereits dargestellt. Sobald die Blockinformationen für den nächsten Block generiert sind, kann die Anfangsstufe 310 die Blockinformationen an die Softwarepipelinekomponente 322A der Pipelineeinheit 330A auf der Stufe 320A der Pipeline 300 senden. Die Blockanalysekomponente 314 kann weiterhin Blockinformationen generieren und die Blockinformationen in die Softwarepipeline 302 eingeben, bis alle Blöcke in dem Frame verarbeitet sind.
  • In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente 322 jeder Pipelineeinheit 330 einen Speicher zum Zwischenspeichern von Blockinformationen für einen, zwei oder mehrere kommende Blöcke umfassen. In mindestens einigen Ausführungsformen kann die Hardwarepipelinekomponente 326 jeder Pipelineeinheit 330 einen Speicher zum Zwischenspeichern eines oder mehrerer Blöcke, die in der Stufe 320 verarbeitet werden sollen, umfassen. In mindestens einigen Ausführungsformen kann der Speicher ein Doppelpuffer sein, sodass eine frühere Stufe einen nächsten Block in den Speicher schreiben kann, während die Hardwarepipelinekomponente 326 einen aktuellen Block aus dem Speicher ausliest.
  • In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente 322 einer Pipelineeinheit 330 Blockinformationen für jeden Block in die Softwarepipelinekomponente 322 einer Pipelineeinheit 330 auf einer nachgeschalteten Stufe 320 schieben, sodass die Softwarepipelinekomponente 322 auf der nachgeschalteten Stufe 320 die entsprechende Hardwarepipelinekomponente 326 auf der Stufe konfigurieren kann. In mindestens einigen Ausführungsformen schiebt die Softwarepipelinekomponente 322 einer Pipelineeinheit 330 auf der Stufe 320 erst dann Blockinformationen für einen Block zu einer nachgeschalteten Stufe 320, wenn die Vorkonfiguration für ein Verarbeiten des Blocks in der Stufe 320 abgeschlossen ist. In mindestens einigen Ausführungsformen können die Blockinformationen für einen Block entsprechend den Informationen, die auf einer Stufe 320 zur Verfügung stehen, aktualisiert werden, bevor die Blockinformationen zur nachgeschalteten Stufe 320 geschoben werden.
  • Sobald eine Hardwarepipelinekomponente 326 auf einer Stufe 320 ein Verarbeiten eines Blocks abgeschlossen hat, kann der verarbeitete Block an eine Hardwarepipelinekomponente 326 auf der nächsten Stufe 320 für ein Verarbeiten gesendet werden. Die Hardwarepipelinekomponente 326 auf der nächsten Stufe 320 kann den Block in ihrem Speicher halten, bis die Hardwarepipelinekomponente 326 das Verarbeiten eines aktuellen Blocks abgeschlossen hat und ein Signal von der Softwarepipelinekomponente 322 der Pipelineeinheit 330 auf der Stufe 320 empfangen hat, das angibt, dass die Konfiguration für ein Verarbeiten des Blocks bereit ist. Es ist zu beachten, dass ein verarbeiteter Block stattdessen von einer letzten Stufe 320 der Pipeline 300 in einen Speicher außerhalb der Pipeline 300 geschrieben werden kann.
  • 4A bis 4C veranschaulichen, entsprechend mindestens einigen Ausführungsformen, ein Verarbeiten von Blöcken in einer Pipelineeinheit einer Stufe in einer beispielhaften Blockverarbeitungspipeline, die eine Softwarepipeline und eine Hardwarepipeline implementiert. 4A bis 4C zeigen eine Pipelineeinheit 330, die auf einer Stufe in einer Blockverarbeitungspipeline verwendet werden kann, die eine Softwarepipelinekomponente 322 und eine Hardwarepipelinekomponente 326 umfasst. Die Hardwarepipelinekomponente 326 der Pipelineeinheit 330 kann eine oder mehrere bestimmte Operationen eines Blockverarbeitungsverfahrens an einem Block ausführen, der aktuell in der Stufe in der Hardwarepipeline 304 ist. Während die Hardwarepipelinekomponente 326 am aktuellen Block arbeitet, kann die Softwarepipelinekomponente 322 der Pipelineeinheit 330 die Hardwarepipelinekomponente 326 für ein Verarbeiten eines kommenden Blocks, beispielsweise des nächsten Blocks, vorkonfigurieren. Dementsprechend arbeitet die Softwarepipelinekomponente 322 einer Pipelineeinheit 330 mindestens einen Block vor der Hardwarepipelinekomponente 326 der Pipelineeinheit 330.
  • Außerdem kann die Pipelineeinheit 330 einen Konfigurationsspeicher (in 4A bis 4C als Konfig.-Speicher 324A und 324B gezeigt) umfassen. Bei dem Konfigurationsspeicher kann es sich beispielsweise um einen Satz Hardware-Register handeln. Entsprechend der Darstellung in 4A bis 4C kann, in mindestens einigen Ausführungsformen, der Konfigurationsspeicher in zwei Speicher (Konfig.-Speicher 324A und 324B) untergliedert sein, sodass die Softwarepipelinekomponente 322 der Pipelineeinheit 330 in einen Speicher schreiben kann, während die Hardwarepipelinekomponente 326 aus dem anderen Speicher liest. Der Konfigurationsspeicher kann beispielsweise ein Satz Register sein, der in einen Teilsatz aktiver Register, in welche die Softwarepipelinekomponente 322 die Konfiguration für einen nächsten Block schreibt, und einen Teilsatz Schattenregister, aus welchen die Hardwarepipelinekomponente 326 die Konfiguration für einen aktuellen Block liest, untergliedert ist. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente 322 in jeden der Konfig.-Speicher 324A und 324B schreiben, und die Hardwarepipelinekomponente 326 kann aus jedem der Konfig.-Speicher 324A und 324B lesen; die zwei Komponenten können zwischen den Speichern 324 umschalten, wobei die Softwarepipelinekomponente 322 in einen schreibt, während die Hardwarepipelinekomponente 326 aus dem anderen liest. Alternativ, in einigen Ausführungsformen, kann die Softwarepipelinekomponente 322 in nur einen der Konfig.-Speicher 324 (z. B. den Konfig.-Speicher 324A) schreiben und die Hardwarepipelinekomponente 326 kann nur aus dem anderen Konfig.-Speicher 324 (z. B. dem Konfig.-Speicher 324B) lesen; wenn die Hardwarepipelinekomponente 326 für eine neue Konfiguration bereit ist und die Konfiguration bereit ist, kann die Konfiguration aus dem Konfig.-Speicher 324A in den Konfig.-Speicher 324B kopiert werden. Es ist zu beachten, dass auch Ausführungsformen implementiert werden können, bei denen nur ein einziger Konfigurationsspeicher verwendet wird oder bei denen mehr als zwei Konfigurationsspeicher verwendet werden.
  • 4A zeigt eine Pipelineeinheit 330 auf einer Stufe in einem Anfangszustand. Die Softwarepipelinekomponente 322 empfängt von einer vorgeschalteten Stufe Blockinformationen für einen ersten Block (Block i) von einem in der Stufe zu verarbeitenden Frame. Die Hardwarepipelinekomponente 326 verarbeitet aktuell keinen Block. Die Softwarepipelinekomponente 322 bestimmt eine Konfiguration für ein Verarbeiten des Blocks i gemäß den empfangenen Blockinformationen und schreibt die Konfiguration in den Konfig.-Speicher 324A. Die Softwarepipelinekomponente 322 signalisiert der Hardwarepipelinekomponente 326 der Pipelineeinheit 330, dass die Konfiguration für den Block i bereit ist, beispielsweise durch Setzen eines „Los”-Bits oder Flags.
  • 4B zeigt die Pipelineeinheit 330 im nächsten Zyklus. Die Softwarepipelinekomponente 322 schiebt Blockinformationen für den Block i zu einer nachgeschalteten Stufe. Die Hardwarepipelinekomponente 326 empfängt den Block i und verarbeitet den Block i gemäß der Konfiguration im Konfig.-Speicher 324A. Die Softwarepipelinekomponente 322 empfängt Blockinformationen für einen nächsten Block (Block i + 1), der in der Stufe zu verarbeiten ist. Die Softwarepipelinekomponente 322 bestimmt eine Konfiguration für ein Verarbeiten des Blocks i + 1 gemäß den empfangenen Blockinformationen und schreibt die Konfiguration in den Konfig.-Speicher 324B. Die Softwarepipelinekomponente 322 signalisiert der Hardwarepipelinekomponente 326, dass die Konfiguration für den Block i + 1 bereitsteht, beispielsweise durch Setzen eines „Los”-Bits oder Flags.
  • 4C zeigt die Pipelineeinheit 330 im nächsten Zyklus. Die Softwarepipelinekomponente 322 schiebt Blockinformationen für den Block i + 1 zu einer nachgeschalteten Stufe. Die Hardwarepipelinekomponente 326 empfängt den Block i + 1 und verarbeitet den Block i + 1 gemäß der Konfiguration im Konfig.-Speicher 324B. Die Softwarepipelinekomponente 322 empfängt Blockinformationen für einen nächsten Block (Block i + 2), der in der Stufe zu verarbeiten ist. Die Softwarepipelinekomponente 322 bestimmt eine Konfiguration für ein Verarbeiten des Blocks i + 2 gemäß den empfangenen Blockinformationen und schreibt die Konfiguration in den Konfig.-Speicher 324A. Die Softwarepipelinekomponente 322 signalisiert der Hardwarepipelinekomponente 326, dass die Konfiguration für den Block i + 2 bereitsteht, beispielsweise durch Setzen eines „Los”-Bits oder Flags.
  • Außerdem zeigt 4C, dass Informationen von einem zuvor in der Stufe verarbeiteten Block mittels der Softwarepipelinekomponente 322 auf der Stufe erhalten und beim Ermitteln einer Konfiguration für einen nächsten Block, der von der Hardwarepipelinekomponente 326 auf der Stufe verarbeitet werden soll, verwendet werden können. Die Hardwarepipelinekomponente 326 beendete das Verarbeiten des Blocks i in einem früheren Zyklus, wie in 4B gezeigt, und verarbeitet nun, in 4C, den Block i + 1. Folglich sind Informationen von der Verarbeitung des Blocks i in der Stufe verfügbar und können zur Softwarepipelinekomponente 322 der Pipelineeinheit 330 auf der Stufe zurückgeleitet werden. Diese Informationen von der Verarbeitung des Blocks i in der Stufe können zusammen mit den Blockinformationen für den Block i + 2, die von einer vorgeschalteten Stufe erhalten werden, verwendet werden, um die Konfiguration für den Block i + 2 zu ermitteln. Folglich kann ein Feedback von Informationen aus der Verarbeitung von Blöcken in einer Stufe für einen Block sein, der zwei Blöcke vor dem Block ist, für den gerade eine Konfiguration generiert wird.
  • Alternativ, bei einigen Implementierungen, kann die Softwarepipelinekomponente 322 auf den Abschluss der Verarbeitung eines aktuellen Blocks durch die Hardwarepipelinekomponente 326 auf der Stufe warten und diese Informationen dazu verwenden, eine Konfiguration für den nächsten Block zu ermitteln. In diesem Fall kann ein Feedback von Informationen aus der Verarbeitung von Blöcken in einer Stufe für einen Block sein, der dem Block, für den gerade eine Konfiguration generiert wird, nur einen Block voraus ist.
  • 5 veranschaulicht, entsprechend mindestens einigen Ausführungsformen, eine beispielhafte Blockverarbeitungspipeline 300, die eine Softwarepipeline und eine Hardwarepipeline implementiert, wobei durch die Softwarepipeline mindestens eine Stufe übersprungen wird. Bei einigen Pipeline-Implementierungen können eine oder mehrere Pipelineeinheiten 330 der Pipeline 300 eine Hardwarepipelinekomponente 326 umfassen, die keine dynamische Konfiguration benötigt. 5 zeigt drei Stufen 320A, 320B und 320C. Die Stufe 320A umfasst die Pipelineeinheit 330A, die sowohl eine Softwarepipelinekomponente 322A als auch eine Hardwarepipelinekomponente 326A umfasst, und die Stufe 320C umfasst eine Pipelineeinheit 330C, die sowohl eine Softwarepipelinekomponente 322B als auch eine Hardwarepipelinekomponente 326C umfasst. Jedoch umfasst die Stufe 320B eine Pipelineeinheit 330B, die eine Hardwarepipelinekomponente 326B umfasst, die keine dynamische Konfiguration benötigt, da die Operation(en), welche die Komponente 326 an einem Block ausführt, für sämtliche Blöcke gleich ist (sind). Folglich benutzt die Pipelineeinheit 330B keine Softwarepipelinekomponente 322.
  • Entsprechend der Darstellung in 5 verarbeitet die Hardwarepipelinekomponente 326A auf der Stufe 320A aktuell den Block i + 2, während die Softwarepipelinekomponente 322A auf der Stufe 320A gerade die Konfiguration für ein Verarbeiten des nächsten Blocks (i + 3) in der Stufe 320A bestimmt und einstellt. Die Hardwarepipelinekomponente 326B auf der Stufe 320B verarbeitet aktuell den Block i + 1. Die Hardwarepipelinekomponente 326C auf der Stufe 320C verarbeitet aktuell den Block i, während die Softwarepipelinekomponente 322B auf der Stufe 320C gerade die Konfiguration für ein Verarbeiten des nächsten Blocks (i + 1) in der Stufe 320A bestimmt und einstellt. In mindestens einigen Ausführungsformen können die Blockinformationen für den Block i + 2 von der Softwarepipelinekomponente 322A stromabwärts zur Softwarepipelinekomponente 322B geschoben werden, sobald die Stufe 320A die Konfiguration für ein Verarbeiten des Blocks i + 2 abgeschlossen und in der Softwarepipelinekomponente 322B zwischengespeichert hat, bis die Softwarepipelinekomponente 322B bereit ist, die Hardwarepipelinekomponente 322C für ein Verarbeiten des Blocks i + 2 zu konfigurieren. Alternativ kann die Stufe 320B Puffer umfassen, in die von der Stufe 320A Blockinformationen geschoben werden und aus denen Blockinformationen zur Stufe 320C geschoben werden. Als eine andere Alternative kann die Stufe 320A Blockinformationen zwischenspeichern und zwar, bis die Stufe 320C für die Informationen bereit ist.
  • 6 veranschaulicht, entsprechend mindestens einigen Ausführungsformen, eine beispielhafte Blockverarbeitungspipeline 300, die eine Softwarepipeline und eine Hardwarepipeline implementiert, wobei mindestens eine Stufe mehrere Pipelineeinheiten umfasst. Entsprechend der Darstellung in 6 umfasst die Stufe 320A eine einzige Pipelineeinheit 330A, die eine Softwarepipelinekomponente 322A und eine Hardwarepipelinekomponente 326A umfasst, und die Stufe 320C umfasst eine einzige Pipelineeinheit 330C, die eine Softwarepipelinekomponente 322C und eine Hardwarepipelinekomponente 326D umfasst. Die Stufe 320B umfasst jedoch zwei Pipelineeinheiten, nämlich 330B und 330C. Die Pipelineeinheit 330B umfasst eine Softwarepipelinekomponente 322B und eine Hardwarepipelinekomponente 326B. Die Pipelineeinheit 330C umfasst nur eine Hardwarepipelinekomponente 326C. In der Hardwarepipeline 304 durchlaufen Blöcke oder Abschnitte von Blöcken von der Pipelineeinheit 330A auf der Stufe 320A sowohl die Hardwarepipelinekomponente 326B als auch die Hardwarepipelinekomponente 326C der Stufe 320B, die verarbeitete Blöcke oder Abschnitte von Blöcken an die Hardwarepipelinekomponente 326D der Pipelineeinheit 330D in der Stufe 320C ausgeben. In der Softwarepipeline 302 werden Blockinformationen von der Softwarepipelineeinheit 322A auf der Stufe 320A zur Softwarepipelineeinheit 322B auf der Stufe 320B sowie von der Softwarepipelineeinheit 322B auf der Stufe 320B zur Softwarepipelineeinheit 322C auf der Stufe 320C weitergereicht.
  • Obwohl dies nicht gezeigt ist, kann bei einigen Implementierungen eine Stufe zwei oder mehrere Pipelineeinheiten 330 umfassen, die sowohl eine Softwarepipelinekomponente 322 als auch eine Hardwarepipelinekomponente 336 umfassen. In diesem Fall können der Softwarepipelinekomponente 322 jeder Pipelineeinheit auf der Stufe 320 Blockinformationen von einer vorgeschalteten Stufe zugeleitet werden. In mindestens einigen Ausführungsformen kann jedoch nur eine der Softwarepipelinekomponenten 322 die Blockinformationen zu einer Softwarepipelinekomponente 322 einer Pipelineeinheit 330 auf einer nachgeschalteten Stufe 320 schieben.
  • 7 veranschaulicht, entsprechend mindestens einigen Ausführungsformen, eine beispielhafte Pipelineeinheit, die auf einer Stufe einer Blockverarbeitungspipeline verwendet werden kann, die eine Softwarepipeline und eine Hardwarepipeline implementiert. Entsprechend der Darstellung in 7 kann die Hardwarepipelinekomponente 404 einer Pipelineeinheit 400 mindestens einen Speicher 432 und einen Einheitskern 430 umfassen. Der Einheitskern 430 kann eine Komponente (z. B. eine Schaltung) sein, die dafür konfiguriert ist, auf einer bestimmten Stufe der Blockverarbeitungspipeline eine bestimmte Operation an einem oder für einen Block oder Abschnitt eines Blocks auszuführen. Der Speicher 432 kann beispielsweise ein Doppelpufferspeicher sein, der dem Einheitskern 430 ermöglicht, Daten für einen Block aus dem Speicher 432 auszulesen und zu verarbeiten, während von einer vorhergehenden Pipelineeinheit Daten für einen nächsten Block in den Speicher 432 geschrieben werden.
  • Entsprechend der Darstellung in 7 kann eine Pipelineeinheit 400 zusätzlich zu einer Hardwarepipelinekomponente 404, die einen Speicher 432 und einen Einheitskern 430 aufweist, auch eine Softwarepipelinekomponente 402 aufweisen, die mindestens einen Prozessor 410 und einen Speicher 412 umfasst. Der Prozessor 410 kann beispielsweise ein Mobile-Prozessor oder Prozessor der M-Klasse sein. Die Prozessoren 410 können beispielsweise dafür konfiguriert sein, dass sie entsprechend den Blockinformationen, die von der Softwarepipelinekomponente 402 empfangen werden, Konfigurationen für einen nächsten zu verarbeitenden Block ermitteln und bei der Hardwarepipelineeinheit 404 einstellen. In mindestens einigen Ausführungsformen kann der Prozessor 410 auch konfigurierbar sein, beispielsweise mit Low-Level-Firmware-Mikrocode, um Flexibilität bei Algorithmen zu ermöglichen, die von der Blockverarbeitungspipeline für verschiedene Anwendungen implementiert werden.
  • In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente 402 dafür konfiguriert sein, Blockinformationen von einer vorhergehenden (vorgeschalteten bzw. stromaufwärts befindlichen Stufe) der Pipeline zu empfangen und Blockinformationen an eine nachfolgende (nachgeschaltete bzw. stromabwärts befindliche) Stufe der Pipeline zu senden. Außerdem kann eine Softwarepipelinekomponente 402 auf mindestens einer Stufe der Pipeline dafür konfiguriert sein, Feedback-Daten an eine vorgeschaltete Stufe (z. B. die erste Stufe) der Pipeline zu senden. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente 402 auch Informationen für einen Block empfangen, der zuvor von der Hardwarepipelinekomponente 404 der Pipelineeinheit 400 verarbeitet wurde.
  • Die Softwarepipelinekomponente 402 kann Blockinformationen, die von einer vorgeschalteten Stufe der Pipeline empfangen werden, im Speicher 412 zwischenspeichern und Blockinformationen aus dem Speicher 412 zu einer nachgeschalteten Stufe der Pipeline schieben. In mindestens einigen Ausführungsformen kann der Speicher 412 ein Doppelpufferspeicher sein, sodass eine vorgeschaltete Stufe Blockinformationen für einen nächsten Block zur Softwarepipelinekomponente 402 schieben kann, während der Prozessor 410 auf Blockinformationen für einen vorhergehenden Block im Speicher 412 zugreift. In einigen Ausführungsformen kann der Speicher 412 imstande sein, mehr als zwei Sätze Blockinformationen zwischenzuspeichern, beispielsweise in Fällen, in denen die vorhergehende Stufe, wie anhand der Stufe 320B in 5 gezeigt, keine Softwarepipelinekomponente umfasst.
  • Die Prozessoren 410 können Blockinformationen für einen nächsten Block aus dem Speicher 412 auslesen und entsprechend den Blockinformationen eine Konfiguration für den nächsten Block ermitteln. In mindestens einigen Ausführungsformen kann der Prozessor 410 auch Informationen für einen Block empfangen, der zuvor von der Hardwarepipelinekomponente 404 der Pipelineeinheit 400 verarbeitet wurde, und diese Information bei der Bestimmung der Konfiguration für den nächsten Block verwenden.
  • Entsprechend der Darstellung in 7 kann eine Pipelineeinheit 400 außerdem eine Schnittstelle 406 zwischen der Softwarepipelinekomponente 402 und der Hardwarepipelinekomponente 404 umfassen. In mindestens einigen Ausführungsformen kann die Schnittstelle 406 ein Satz Register sein. Es ist jedoch zu beachten, dass die Schnittstelle 406 auch auf andere Weise implementiert werden kann. Bei der Pipelineeinheit 400, wie in 7 gezeigt, umfasst die Schnittstelle 406 mindestens den Konfig.-Speicher 420A, den Konfig.-Speicher 402B und GO 422. In mindestens einigen Ausführungsformen kann der Prozessor 410 in jeden der Konfig.-Speicher 420A und 420B schreiben, und der Einheitskern 430 kann aus jedem der Konfig.-Speicher 420A und 420B lesen; der Prozessor 410 und der Einheitskern 430 können zwischen den zwei Speichern 420 umschalten, wobei der Prozessor 410 in einen schreibt, während der Einheitskern 430 aus dem anderen liest. Alternativ, in einigen Ausführungsformen, kann der Prozessor 410 in nur einen der Konfig.-Speicher 420 (z. B. den Konfig.-Speicher 420A) schreiben und der Einheitskern 430 kann nur aus denn anderen Konfig.-Speicher 420 (z. B. dem Konfig.-Speicher 420B) lesen; wenn der Einheitskern 430 für eine neue Konfiguration bereit ist und die Konfiguration bereit ist, kann die Konfiguration aus dem Konfig.-Speicher 420A in den Konfig.-Speicher 420B kopiert werden. Es ist zu beachten, dass auch Ausführungsformen implementiert werden können, bei denen nur ein einziger Konfigurationsspeicher verwendet wird oder bei denen mehr als zwei Konfigurationsspeicher verwendet werden.
  • GO 422 kann beispielsweise als ein oder mehrere Bits in einem Register oder anderem Speicher implementiert sein oder kann auf andere Weise implementiert werden. In mindestens einigen Ausführungsformen kann der Prozessor 410, wenn er eine Konfiguration für einen nächsten Block abschließt und den Konfig.-Speicher 420 (z. B. den Konfig.-Speicher 420A) mit der Konfiguration geladen hat, GO 422 so setzen, dass dem Einheitskern 430 signalisiert wird, dass die Konfiguration für den nächsten Block im Konfig.-Speicher 420 (z. B. dem Konfig.-Speicher 420A) bereitsteht. Sobald GO 422 für den nächsten Block gesetzt ist, kann der Einheitskern 430 mit dem Verarbeiten des nächsten Blocks beginnen, wenn die Verarbeitung des aktuellen Blocks abgeschlossen ist und der nächste Block im Speicher 432 bereitsteht. Andernfalls kann der Einheitskern 430 warten, bis die Verarbeitung des aktuellen Blocks abgeschlossen ist und/oder der nächste Block im Speicher 432 bereitsteht. Es ist zu beachten, dass zunächst (für einen ersten Block in der Pipeline) kein Block in der Stufe verarbeitet wird, während der Prozessor 410 die Stufe für den ersten Block konfiguriert, und folglich der Einheitskern 430 mit dem Verarbeiten des ersten Blocks beginnen kann, sobald GO 422 für den ersten Block gesetzt ist und der erste Block im Speicher 432 bereitsteht. Sobald der Einheitskern 430 mit der Konfiguration in einem Konfig.-Speicher 420 fertig ist, kann der Einheitskern 430 GO 422 zurücksetzen, um dem Prozessor 410 zu signalisieren, dass der Konfig.-Speicher 420 zum Empfangen der Konfiguration für einen nächsten Block zur Verfügung steht.
  • 8A und 8B sind, entsprechend mindestens einigen Ausführungsformen, Ablaufdiagramme von Verfahren zum Betrieb einer Softwarepipeline und einer Hardwarepipeline, die in einer Blockverarbeitungspipeline parallel arbeiten, um Blöcke von einem Frame zu verarbeiten. 8A zeigt Operationen in einer Stufe für die Softwarepipeline, und 8B zeigt Operationen in der Stufe für die Hardwarepipeline. Es ist zu beachten, dass die Softwarepipeline der Hardwarepipeline um mindestens einen Block vorauseilt.
  • Mit Bezug auf 8A: Eine Softwarepipelinekomponente auf einer Stufe empfängt Blockinformationen, wie unter 500 angegeben. Die Blockinformationen können von einer vorgeschalteten Stufe empfangene Blockinformationen und/oder von einer nachgeschalteten Stufe empfangene Blockinformationen umfassen. In mindestens einigen Ausführungsformen kann die Softwarepipelinekomponente auch Informationen von einem Block des Frames empfangen, der zuvor in der Stufe verarbeitet wurde. Die Blockinformationen für einen, zwei oder mehrere Blöcke können in einem lokalen Speicher der Softwarepipelinekomponente zwischengespeichert werden. Wie durch den Pfeil angegeben, der zum Element 500 zurückweist, kann das Element 500 iterativ ausgeführt werden, so lange es zu verarbeitende Blöcke in dem Frame gibt.
  • Sobald die Blockinformationen für einen nächsten Block auf der Stufe bereit sind, kann die Softwarepipelinekomponente wie unter 502 angegeben entsprechend den fit. den Block empfangenen Informationen eine Konfiguration für den Block ermitteln. Die Softwarepipelinekomponente kann wie unter 504 angegeben die Konfiguration für den Block in einen Konfigurationsspeicher der Stufe schreiben. Die Softwarepipelinekomponente kann wie unter 506 angegeben ein „Los”-Bit (GO) setzen oder der Hardwarepipelinekomponente auf der Stufe anderweitig signalisieren, dass die Konfiguration für den nächsten Block im Konfigurationsspeicher bereitsteht. Die Softwarepipelinekomponente kann dann wie unter 506 angegeben die Blockinformationen für den Block zu einer nachgeschalteten Stufe schieben. Unter 510 kann das Softwarepipeline-Verfahren, wenn in der Stufe noch mehr Blöcke des Frame zu verarbeiten sind, zum Element 502 zurückspringen, um mit dem Konfigurieren der Hardwarepipelinekomponente für einen nächsten Block zu beginnen. Andernfalls ist die Verarbeitung des Frames auf dieser Stufe erledigt und das Verfahren wird abgeschlossen.
  • Mit Bezug auf 8B: Eine Hardwarepipelinekomponente auf einer Stufe empfängt zu verarbeitende Blöcke von einer früheren Stufe. Die Blockinformationen können in einem lokalen Speicher der Hardwarepipelinekomponente zwischengespeichert werden. In mindestens einigen Ausführungsformen kann der lokale Speicher ein Doppelpufferspeicher sein, sodass die vorhergehende Stufe einen nächsten Block in die Stufe schreiben kann, während die Hardwarepipelinekomponente einen aktuellen Block aus dem Speicher verarbeitet. Wie durch den Pfeil angegeben, der zum Element 550 zurückweist, kann das Element 550 iterativ ausgeführt werden, so lange es zu verarbeitende Blöcke in dem Frame gibt.
  • Wenn, unter 552, die Hardwarepipelinekomponente aktuell keinen Block verarbeitet, ein nächster Block im Speicher bereitsteht und die Softwarepipelinekomponente der Hardwarepipelinekomponente signalisiert hat (z. B. durch Setzen eines „Los”-Bits (GO) oder Flags), dass eine Konfiguration für den nächsten Block im Konfigurationsspeicher bereitsteht, dann kann die Hardwarepipelinekomponente beginnen, den nächsten Block zu verarbeiten. Wenn eine dieser drei Bedingungen nicht erfüllt ist, wartet die Hardwarepipelinekomponente, in mindestens einigen Ausführungsformen, bis alle drei erfüllt sind. Es ist jedoch zu beachten, dass es für einen ersten zu verarbeitenden Block in dem Frame keinen aktuellen Block gibt, der gerade in der Hardwarepipelinekomponente verarbeitet wird, wenn der erste Block für ein Verarbeiten in der Hardwarepipelinekomponente empfangen wird.
  • Wenn alle notwendigen Bedingungen erfüllt sind, dann stellt die Hardwarepipelinekomponente wie unter 554 angegeben die Konfiguration für ein Verarbeiten des nächsten Blocks gemäß der Konfiguration im Konfigurationsspeicher ein. Wie unter 556 angegeben, setzt die Hardwarepipelinekomponente das „Los”-Bit (GO) zurück oder signalisiert der Softwarepipelinekomponente anderweitig, dass der Konfigurationsspeicher zur Verfügung steht. Wie unter 558 angegeben, verarbeitet die Hardwarepipelinekomponente den Block gemäß der Konfiguration für den Block. Wie unter 560 angegeben schreibt die Hardwarepipelinekomponente den verarbeiteten Block in die nächste Stufe. Alternativ, auf einer letzten Stufe, kann der verarbeitete Block mittels eines direkten Speicherzugriffs (DMA) in einen Speicher geschrieben werden, beispielsweise einen externen Speicher. Unter 562 kann das Hardwarepipeline-Verfahren, wenn in der Stufe noch mehr Blöcke des Frame zu verarbeiten sind, zum Element 552 zurückspringen, um mit einem Verarbeiten eines nächsten Blocks zu beginnen, wenn alle Bedingungen erfüllt sind. Andernfalls ist die Verarbeitung des Frames auf dieser Stufe erledigt und das Verfahren wird abgeschlossen.
  • Es ist zu beachten, dass die Elemente 502 bis 508 von 8A von der Softwarepipelinekomponente auf einer Stufe für einen Anfangsblock in dem Frame ausgeführt werden, bevor die Elemente 554 bis 560 von 8B von der Hardwarepipelinekomponente auf der Stufe ausgeführt werden. Danach können die Elemente 502 bis 508 von 8A von der Softwarepipelinekomponente auf der Stufe ausgeführt werden, um die Hardwarepipelinekomponente für einen nächsten Block zu konfigurieren, während die Elemente 554 bis 560 von 8B von der Hardwarepipelinekomponente ausgeführt werden, um einen aktuellen Block zu verarbeiten.
  • Rösselsprung-Verarbeitung
  • Es werden Ausführungsformen von Blockverarbeitungsverfahren und -einrichtungen beschrieben, wobei die Böcke gemäß einer Reihenfolge eingegeben und in der Pipeline verarbeitet werden, die hier als „Rösselsprung” oder „Rösselsprung-Reihenfolge” bezeichnet wird, und die Blöcke eben nicht wie bei herkömmlichen Verfahren gemäß der Abtastreihenfolge in einer Pipeline verarbeitet werden. Rösselsprung ist eine Anspielung auf die Bewegungsweise des Rössels (Springers) beim Schach, das sich eine Zeile nach unten und zwei Spalten nach links bewegt. Es ist jedoch zu beachten, dass „Rösselsprung” oder „Rösselsprung-Reihenfolge”, wie hier verwendet, allgemeiner Bewegungen eine Zeile nach unten und p Zeilen nach links umfasst, wobei p 2 sein kann aber nicht unbedingt sein muss.
  • Das Rösselsprung-Verarbeitungsverfahren kann Abstände (eine oder mehrere Stufen) zwischen benachbarten Blöcken in der Pipeline vorsehen, was beispielsweise ein Feedback von Daten von einer nachgeschalteten Stufe der Pipeline, die einen ersten Block verarbeitet, zu einer vorgeschalteten Stufe der Pipeline, die einen zweiten Block verarbeitet und von den Daten von dem ersten Block abhängt, erleichtert. Eine oder mehrere Stufen einer Blockverarbeitungspipeline können bei der Verarbeitung eines gegebenen Blocks Informationen von einem oder mehreren anderen Nachbarblöcken benötigen. 9 zeigt Nachbarn eines aktuellen Blocks (m, n), von dem ggf. Informationen benötigt werden – links (m – 1, n); oben (m, n – 1); oben links (m – 1, n – 1); oben rechts (m + 1, n – 1) und oben zweimal rechts (m + 2, n – 1). Dieser Bedarf an Informationen von Nachbarblöcken kann auch als Abhängigkeiten bezeichnet werden. Beispielsweise, mit Bezug auf 9, können Informationen vom linken Nachbar des Blocks (m, n) erforderlich sein, um eine bestimmte Operation an dem Block auszuführen. Bei dem Rösselsprung-Verarbeitungsverfahren ist der nächste Block, der unmittelbar nach dem Block (m, n) in die Pipeline eingegeben wird, der Block (m – 2, n + 1), statt den Block (m + 1, n) in die Pipeline einzugeben. Bei Eingabe der Blöcke in die Pipeline in Rösselsprung-Reihenfolge statt in Abtastreihenfolge entstehen Abstände (z. B. eine oder mehrere Stufen) zwischen benachbarten Blöcken einer Zeile in der Pipeline.
  • In mindestens einigen Ausführungsformen des Rösselsprung-Verarbeitungsverfahrens können die Zeilen von Blöcken im Eingabe-Frame in Sätze von vier Zeilen unterteilt werden, hier als Viererzeilen (Engl. Quadrows) bezeichnet, wobei das Rösselsprung-Verarbeitungsverfahren durch die Viererzeilen-Grenzen beschränkt wird. Mit Bezug auf 9, bei einer Verwendung von Viererzeilen-Grenzen wird bei einer Rösselsprung-Verarbeitung der Block (m – 1, n) vier Stufen nachgeschaltet sein, wenn der Block (m, n) in die Pipeline eingegeben wird, und der Block (m, n) wird vier Stufen nachgeschaltet sein, wenn der Block (m + 1, n) in die Pipeline eingegeben wird. Folglich werden Blöcke, die in einer Zeile benachbart sind, in der Pipeline vier Stufen voneinander beabstandet sein. Folglich ist es bei Stufen, in denen an einem Block Operationen ausgeführt werden, die von Informationen vom linken Nachbarn abhängen, wahrscheinlicher, dass die Informationen für den linken Nachbarn ohne Weiteres mit geringer Latenz verfügbar sind, als das bei einer Verarbeitung der Blöcke in Abtastreihenfolge der Fall wäre. Über die Abhängigkeiten vom linken Nachbarn hinausgehend können eine oder mehrere Operationen eines Blockverarbeitungsverfahrens von Nachbarblöcken aus der vorhergehenden (oder oberen) Zeile abhängen, wie etwa vom oberen Nachbarn, vom Nachbarn oben links, vom Nachbarn oben rechts und vom Nachbarn oben zweimal rechts, wie in 9 gezeigt. Das Rösselsprung-Verarbeitungsverfahren mit Viererzeilen-Beschränkungen liefert eine Örtlichkeit für Nachbarinformationen, die genutzt werden kann, um ein lokales Caching dieser Nachbardaten auf jeder Stufe in verhältnismäßig kleinen Puffer zu ermöglichen.
  • In mindestens einigen Ausführungsformen ist ein Grundalgorithmus zum Ermitteln eines nächsten Blocks, der in die Pipeline einzugeben ist, gemäß dem Rösselsprung-Verarbeitungsverfahren bei Viererzeilen-Beschränkungen wie folgt:
    Wenn nicht in der untersten Zeile einer Viererzeile:
    Der nächste Block ist zwei Spalten nach links, eine Zeile nach unten (–2, +1).
    Ansonsten, in der untersten Zeile einer Viererzeile:
    Der nächste Block ist sieben Spalten nach rechts, drei Zeilen nach oben (+7, –3).
  • Das Rösselsprung-Verarbeitungsverfahren kann jedoch auch mit anderen Abständen als zwei Blöcke nach links, einen Block nach unten (–2, +1) implementiert werden. Beispielsweise kann das Verfahren derart implementiert werden, dass, statt zwei Blöcke nach links und einen Block nach unten zu gehen, drei Blöcke nach links und einen Block nach unten gegangen wird, um den nächsten Block zu erhalten. Als ein anderes Beispiel, das Verfahren kann derart implementiert werden, dass einen Block nach links und einen Block nach unten (–1, +1) gegangen wird, um den nächsten Block zu erhalten. Zudem kann das Rösselsprung-Verarbeitungsverfahren mit anderen Zeilenbeschränkungen als Viererzeilen-Beschränkungen (Beschränkungen auf vier Zeilen) implementiert werden. Anders ausgedrückt, in Ausführungsformen können zur Beschränkung des Rösselsprung-Verarbeitungsverfahrens Zeilengruppen von mindestens zwei Zeilen verwendet werden. Angenommen, r ist die Anzahl der Zeilen, die verwendet werden, um das Rösselsprung-Verarbeitungsverfahren zu beschränken, dann kann der Algorithmus wie folgt verallgemeinert werden:
    Wenn nicht in der untersten Zeile einer Zeilengruppe:
    Der nächste Block ist p Spalten nach links, eine Zeile nach unten (–p, +1).
    Ansonsten, in der untersten Zeile einer Zeilengruppe:
    Der nächste Block ist q Spalten nach rechts, (r – 1) Zeilen nach oben (+q, –(r – 1)).
  • Ein Ändern des Werts von p würde sich auf den Wert von q auswirken, würde sich nicht auf die Abstände zwischen benachbarten Blöcken aus einer Zeile in der Pipeline auswirken, aber würde sich auf die Abstände zwischen einem gegebenen Block und seinen anderen Nachbarblöcken (z. B. seinen Nachbarn oben links, oben und oben rechts) auswirken. Insbesondere ist zu beachten, das eine Verwendung der Abstände (–1, +1) dazu führen würde, dass ein Block und sein diagonal (oben rechts) benachbarter Block gleichzeitig in benachbarten Stufen der Pipeline verarbeitet werden. Folglich können Abstände von mindestens zwei Blöcken nach links verwendet werden, damit diagonal benachbarte Blöcke nicht gleichzeitig in benachbarten Stufen der Blockverarbeitungspipeline verarbeitet werden. Ein Ändern des Werts von r würde sich auf den Wert von q auswirken, würde sich auf die Abstände zwischen benachbarten Blöcken aus einer Zeile in der Pipeline auswirken und würde sich auf die Abstände zwischen dem Block und seinen anderen Nachbarblöcken (z. B. seinen Nachbarn oben links, oben und oben rechts) auswirken.
  • Der vorstehende Algorithmus zum Ermitteln eines nächsten Blocks kann bei einem Anfangsblock beginnen. Bei Erreichen des Ende einer Viererzeile, auf die eine weitere Viererzeile folgt, springt der Algorithmus zum ersten Block der nächsten Viererzeile und wechselt dann einige Zyklen lang zwischen der Viererzeile und der nächsten Viererzeile hin und her, was ein Verschränken einiger Blöcke vom Ende der Viererzeile mit einigen Blöcken vom Beginn der nächsten Viererzeile zur Folge hat. Anders ausgedrückt, das Rösselsprung-Verarbeitungsverfahren behandelt die Viererzeilen, als ob sie nahtlos aneinandergereiht wären. Um Komplikationen bei den Algorithmen zu vermeiden und einheitliche Abstände der Blöcke in der Pipeline beizubehalten, können mindestens einige Ausführungsformen den Beginn der ersten Viererzeile und das Ende der letzten Viererzeile mit ungültigen Blöcken auffüllen. Ein ungültiger Block lässt sich als ein Block definieren, der außerhalb der Begrenzung des Frames ist und der in die Pipeline eingegeben wird, jedoch keine gültigen Framedaten enthält und daher auf den Stufen nicht verarbeitet wird. Der Algorithmus zum Ermitteln eines nächsten Blocks kann demnach bei einem Anfangsblock beginnen, der entweder der erste Block in der obersten Zeile der ersten Viererzeile oder ein ungültiger Block links vom ersten Block in der obersten Zeile der ersten Viererzeile sein kann, sämtliche Viererzeilen abarbeiten und am Ende der letzten Viererzeile fortfahren, bis der letzte Block der letzten Viererzeile in die Pipeline eingegeben worden ist. Am Anfang und Ende des Frames werden „Blasen” in der Pipeline sein, doch die Abstände der gültigen Blöcke aus dem Frame in der Pipeline werden durchweg einheitlich sein. In einigen Ausführungsformen kann, als Alternative zum Auffüllen des Endes der letzten Viererzeile eines Video-Frame mit ungültigen Blöcken, die letzte Viererzeile eines Video-Frame mit der ersten Zeile des nächsten Video-Frames, das in der Blockverarbeitungspipeline zu verarbeiten ist, überlappend sein.
  • 10A und 10B veranschaulichen graphisch das Rösselsprung-Verarbeitungsverfahren entsprechend mindestens einigen Ausführungsformen. Der Einfachheit halber wird in diesen Figuren ein 192×192 Pixel umfassendes Frame verwendet, das in 144 16×16-Pixelblöcke, bei 12 Zeilen und 12 Spalten von Blöcken, unterteilt ist. Es ist jedoch zu beachten, dass das Rösselsprung-Verarbeitungsverfahren angewendet werden kann, um Video-Frames beliebiger Abmessungen einzugeben. In 10A ist ein beispielhaftes Frame in Zeilen und Spalten von Blöcken unterteilt. Die Zeilen der Blöcke sind auf drei Viererzeilen, jeweils vier Zeilen umfassend, aufgeteilt. Die letzten drei Zeilen der ersten Viererzeile sind auf der linken Seite mit ungültigen Blöcken aufgefüllt, und die ersten drei Zeilen der letzten (dritten) Viererzeile sind an der rechten Seite mit ungültigen Blöcken aufgefüllt. Bei diesem Beispiel repräsentieren die Nummern in den Blöcken die Reihenfolge, in der die Blöcke gemäß dem Rösselsprung-Verarbeitungsverfahren in die Blockverarbeitungspipeline eingegeben werden, wobei mit dem Block 0 (dem ersten Block in der obersten Zeile der ersten Viererzeile) begonnen wird. Der Block 0 wird in die erste Stufe der Pipeline eingegeben, und wenn die erste Stufe für einen weiteren Block bereit ist, fährt das Verfahren fort, indem es zwei Spalten nach links eine Zeile nach unten zum nächsten Block für eine Eingabe (Block 1, in 10A) geht. Dieses Muster wird so lange wiederholt, bis das untere Ende der Viererzeile erreicht ist. Am unteren Ende der Viererzeile geht das Verfahren sieben Spalten nach rechts, drei Zeilen nach oben, um den nächsten Block zu erhalten. Dies wird so lange fortgesetzt, bis alle Blöcke in dem Frame (und auch alle ungültigen Blöcke, die in 10A gezeigt sind) in die Pipeline eingegeben sind. Wenn das Ende einer Viererzeile erreicht ist, geht der Eingabealgorithmus, wenn es nach der Viererzeile eine weitere Viererzeile gibt, zum Beginn der nächsten Viererzeile weiter. In diesem Beispiel geht das Verfahren, nachdem der Block 47 eingegeben wurde, zum Block 48 (dem ersten Block in der obersten Zeile der zweiten Viererzeile) weiter. Wie durch den gestrichelten Pfeil vom Block 47 zu dem gestrichelten Rechteck, das mit 48 beschriftet ist, rechts vom Block 44, gezeigt, wird der erste Block der obersten Zeile der zweiten Viererzeile (Block 48) als unmittelbar auf der rechten Seite des letzten Blocks der obersten Zeile der ersten Viererzeile (Block 44) behandelt und wird folglich vom Block 47 aus erreicht, indem sieben Spalten nach rechts, drei Spalten nach oben gegangen wird. Anders ausgedrückt, das Rösselsprung-Verarbeitungsverfahren behandelt die Viererzeilen, als ob sie nahtlos aneinandergereiht wären, mit ungültigen Blöcken an jedem Ende, wie in 10B gezeigt. Folglich bleibt der Algorithmus zum Ermitteln eines nächsten Blocks über dem gesamten Frame gleich.
  • In einigen Ausführungsformen kann jede Zeile der ersten Viererzeile mit zusätzlichen ungültigen Blöcken aufgefüllt werden, beispielsweise mit zwei zusätzlichen ungültigen Blöcken. Statt wie in 10A gezeigt mit dem ersten Block in der obersten Zeile der ersten Viererzeile zu beginnen, kann die Eingabe in die Pipeline mit dem ersten ungültigen Block auf der linken Seite des ersten Blocks in der obersten Zeile der ersten Viererzeile beginnen.
  • 11A und 11B sind High-Level-Ablaufdiagramme eines Rösselsprung-Verarbeitungsverfahrens für eine Blockverarbeitungspipeline entsprechend mindestens einigen Ausführungsformen. In 11A wird, wie unter 3100 angegeben, ein nächster Block gemäß dem Algorithmus zum Ermitteln eines nächsten Eingabeblocks bestimmt, der durch das Rösselsprung-Verarbeitungsverfahren implementiert wird. Wie unter 3102 angegeben, wird der Block in die Pipeline eingegeben, beispielsweise mittels eines direkten Speicherzugriffs (DMA) aus einem Speicher. Wie durch 3104 dargestellt wird die Eingabe der Elemente 3100 und 3102 so lange fortgesetzt, wie es Blöcke gibt, die zu verarbeiten sind. Jeder durch Elemente 3100 und 3102 in die Pipeline eingegebene Block wird, wie unter 3106 angegeben, in der Pipeline verarbeitet. Jeder Block wird zunächst in eine erste Stufe der Pipeline eingegeben, verarbeitet, an eine zweite Stufe ausgegeben, verarbeitet usw. Wenn sich ein Block von einer Stufe zur nächsten Stufe der Pipeline bewegt, kann die Stufe mit dem Verarbeiten des nächsten Blocks in der Pipeline beginnen. Folglich bewegen sich die eingegebenen Blöcke durch die Stufen der Pipeline, wobei jede Stufe jeweils einen Block verarbeitet. Wie unter 3108 angegeben, wird, sobald ein Block von einer letzten Stufe der Pipeline verarbeitet worden ist, der verarbeitete Block ausgegeben, beispielsweise mittels eines direkten Speicherzugriffs (DMA) an einen Speicher.
  • 11B ist ein Ablaufplan eines Beispielalgorithmus zum Ermitteln eines nächsten Eingabeblocks, der durch das Rösselsprung-Verarbeitungsverfahren implementiert werden kann, und erweitert sich aus Element 3100 von 11A. In 11B wird davon ausgegangen, dass das Frame in Viererzeilen aufgeteilt ist und dass der zum Ermitteln des nächsten Frame verwendete Algorithmus zwei Spalten links, eine Zeile nach unten (–2, +1), falls er sich nicht in der unteren Zeile einer Viererzeile befindet, sieben Spalten nach rechts, drei Zeilen nach oben liegt (+7, –3), falls er sich in der unteren Zeile befindet. Es können jedoch andere Zeilengruppierungen und/oder Beabstandungsalgorithmen verwendet werden. In 3150 erhält das Verfahren einen Anfangsblock, wie in 3152 angegeben, falls es sich am Beginn des Frame befindet. Wenn dies nicht der Beginn des Frames ist, ist in 3154 der nächste Block sieben Spalten rechts, drei Zeilen nach oben, wie in 3156 angegeben, falls dies die letzte Zeile der Viererzeile ist. Falls dies nicht die letzte Zeile der Viererzeile ist, ist der nächste Block zwei Spalten nach links, eine Zeile nach unten, wie in 3158 angegeben.
  • Caching von Nachbardaten
  • Eine oder mehrere in Stufen einer Blockverarbeitungspipeline durchgeführte Operationen können von einem oder mehreren der Nachbarblöcke aus der vorherigen (oder darüber liegenden) Zeile von Blöcken abhängen, wie beispielsweise dem Nachbarn oben, dem Nachbarn oben links, dem Nachbarn oben rechts und dem Nachbarn oben rechts rechts, sowie vom linken Nachbar, wie in 9 gezeigt. Das Rösselsprung-Verarbeitungsverfahren mit Viererzeilen-Bedingungen stellt eine Lage von Nachbarinformationen bereit, die eingesetzt werden können, um ein lokales Caching von Nachbardaten in jeder Stufe der Pipeline in relativ kleinen lokalen Puffer bereitzustellen. In zumindest manchen Ausführungsformen können die lokalen Puffer unter Verwendung von SRAM(static random access memory, statischer Speicher mit wahlfreiem Zugriff)-Technologie implementiert sein. Die lokalen Puffer können jedoch in manchen Ausführungsformen unter Verwendung anderer Speichertechnologien implementiert sein.
  • Es ist zu beachten, dass Blöcke in der ersten Spalte eines Frame keinen Nachbarn links oder links oben besitzen, Blöcke in der letzten Spalte keinen Nachbarn oben rechts oder oben rechts rechts besitzen und Blöcke in der vorletzten Spalte keinen Nachbarn oben rechts rechts besitzen. Für Blockverarbeitungsverfahren, die Informationen aus diesen Nachbarpositionen verwenden, sind somit die Informationen in den lokalen Puffer für diese Nachbarpositionen relativ zu Blöcken in diesen Spalten nicht gültig und werden nicht beim Verarbeiten der Blöcke in diesen Spalten in den Stufen der Pipeline verwendet. Des Weiteren gibt es keine Zeilen über der oberen Zeile der ersten Viererzeile, sodass die Blöcke in dieser Zeile keine Nachbarn oben, oben links, oben rechts und oben rechts rechts besitzen.
  • In zumindest manchen Ausführungsformen einer Blockverarbeitungspipeline, die das Rösselsprung-Verarbeitungsverfahren verwendet, kann ein erster Puffer ausreichender Größe zum Caching der C als letztes verarbeiteten Blöcke in der aktuellen Viererzeile in jeder von einer oder mehreren Stufen der Pipeline implementiert sein. Dieser Puffer kann als der Puffer der aktuellen Viererzeile bezeichnet werden und kann zum Beispiel als ein FIFO-Ringpuffer implementiert sein. In zumindest manchen Ausführungsformen kann C so bestimmt werden, dass der Puffer einen Eintrag einschließt, der dem Nachbarn oben links des aktuellen Blocks in der Stufe gemäß dem Algorithmus zum Ermitteln eines nächsten Blocks und der Zeilengruppengröße entspricht, die verwendet wird, um Bedingungen für das Rösselsprung-Verfahren bereitzustellen. Der Puffer kann zudem Einträge einschließen, die den Nachbarn oben rechts rechts, links, oben rechts und oben für den aktuellen Block gemäß dem Algorithmus entsprechen. Beim Verarbeiten eines Blocks kann eine Stufe auf den Puffer der aktuellen Viererzeile zugreifen, um Nachbarinformationen für den Block zu erhalten, wenn die Nachbarinformationen des Blocks im Puffer der aktuellen Viererzeile gültig sind. Es ist zu beachten, dass manche Blockverarbeitungsverfahren unter Umständen keine Informationen zum Nachbarn oben links erfordern und der Puffer der aktuellen Viererzeile in diesen Implementierungen kleiner sein kann.
  • Wenn eine Stufe die Verarbeitung eines Blocks abschließt, werden die Informationen des Blocks in die letzte Position im Puffer der aktuellen Viererzeile geschrieben, wobei der Eintrag an der Position des Nachbarn oben links des Blocks überschrieben und somit der Puffer für den nächsten in der Stufe zu verarbeitenden Block vorbereitet wird Es ist zu beachten, dass anfänglich zu Beginn eines Frame keine Informationen im Puffer der aktuellen Viererzeile sind, da keine Blocks im Frame verarbeitet wurden, sodass keine Blockinformationen im Puffer überschrieben werden, bis der Puffer gefüllt ist. Wenn sich der nächste Block in der Stufe befindet, sind die vorherigen Informationen des Blocks im Puffer die Informationen zum Nachbarn oben rechts rechts des Blocks.
  • Zum Beispiel wäre unter Verwendung von Viererzeilengrenzen und des Algorithmus zum Ermitteln eines nächsten Blocks, wobei der nächste Block zwei Spalten links, eine Zeile nach unten ist, wenn sich der Algorithmus nicht in der unteren Zeile einer Viererzeile befindet, C = 13 ausreichend, um den Nachbarn oben links des aktuellen Blocks einzuschließen, da der Abstand zwischen dem aktuellen Block und seinen Nachbarn oben links 13 beträgt. 12 zeigt gemäß zumindest manchen Ausführungsformen einen Abschnitt einer Viererzeile wie er in einer Pipeline gemäß dem Rösselsprung-Verarbeitungsverfahren verarbeitet wird, der im Puffer der aktuellen Viererzeile gecached sein kann. Block 19 steht für einen aktuellen Block in einer Stufe. Die schattierten Blöcke stehen für die 13 als Letztes durch die Stufe verarbeiteten Blöcke. Es ist zu beachten, dass der zeitlich am weitesten entfernte Block von Block 19 sein Nachbar oben links ist (Block 6) und der zeitlich am nächsten liegende Block sein Nachbar oben rechts rechts ist (Block 9).
  • Für die Blöcke in der oberen Zeile einer Viererzeile befinden sich im Puffer der aktuellen Viererzeile keine Informationen für Nachbarn in der Zeile darüber. Es gibt keine Zeilen über der oberen Zeile einer ersten Viererzeile, und für alle anderen Viererzeilen ist die Zeile über der oberen Zeile die untere Zeile der vorherigen Viererzeile. Somit schließt der Puffer der aktuellen Viererzeile für alle Blöcke in der oberen Zeile einer Viererzeile die Informationen des linken Nachbarn ein (außer dem ersten Block, der keinen linken Nachbar besitzt), schließt jedoch nicht die Informationen zum Nachbarn oben links, oben, oben rechts und oben rechts rechts für die Blöcke in der oberen Zeile der Viererzeile ein. Um diese Nachbarinformationen für Blöcke in den oberen Zeilen der Viererzeilen bereitzustellen, kann in einer oder mehreren Stufen der Pipeline ein zweiter Puffer ausreichender Größe zum Speichern von Informationen für die erforderlichen Nachbarblöcke aus der letzten Zeile der vorherigen Viererzeile implementiert werden. Dieser Puffer kann als der Puffer der vorherigen Viererzeile bezeichnet werden und kann zum Beispiel als ein FIFO-Ringpuffer implementiert sein. Die Anzahl von Einträgen im Puffer der vorherigen Viererzeile sowie die bestimmten Nachbarblöcke, die im Puffer der vorherigen Viererzeile gecached werden, können von den Anforderungen des bestimmten Blockverarbeitungsverfahrens abhängen, das durch die Blockverarbeitungspipeline implementiert wird. In zumindest manchen Ausführungsformen können beim Verarbeiten einer Viererzeile gemäß dem Rösselsprung-Verarbeitungsverfahren Informationen für jeden Block in der unteren Zeile der Viererzeile in einen externen Speicher geschrieben werden, zum Beispiel, wenn der Block in einer letzten Stufe der Pipeline ist. Für jeden Block in der oberen Zeile einer Viererzeile können Nachbardaten (z. B. zum Nachbarn oben rechts rechts), zum Beispiel in einer ersten Stufe der Pipeline, aus dem externen Speicher gelesen werden. Diese Nachbarinformationen können dann zusammen mit dem entsprechenden Block aus der oberen Zeile die Pipeline nach unten zu den andern Stufen geleitet werden.
  • 13 veranschaulicht gemäß zumindest manchen Ausführungsformen grafisch Blöcke in einer aktuellen Viererzeile, die gemäß dem Rösselsprung-Verarbeitungsverfahren verarbeitet werden, sowie Nachbarblöcke in der letzten Zeile der vorherigen Viererzeile, Blöcke A, A + 4, A + 8 und A + 12 wurden in der vorherigen Viererzeile gemäß dem Rösselsprung-Verarbeitungsverfahren verarbeitet. Block A wurde als Erstes verarbeitet, Block A + 4 wurde vier Zyklen später verarbeitet und so weiter. Block B steht für einen Block in der aktuellen Viererzeile, der derzeit in einer bestimmten Stufe der Pipeline ist. Blöcke B – 1 (B minus 1) bis B – 13 (B minus 13) stehen für die dreizehn Blöcke, die als letzte in der Stufe in der aktuellen Viererzeile verarbeitet wurden. Information aus diesen Blöcken können derzeit im Puffer der aktuellen Viererzeile der Stufe gecached werden, mit B – 1 als jüngsten Eintrag und B – 13 als ältesten Eintrag. B – 4 ist der linke Nachbar des aktuellen Blocks B. Die Nachbarn oben links (Block A), oben (Block A + 4), oben rechts (Block A + 8) und oben rechts rechts (Block A + 12) von B sind in der unteren Zeile der vorherigen Viererzeile und sind nicht im Puffer der aktuellen Viererzeile für Block B eingeschlossen. Um Nachbarinformationen für Blöcke in der oberen Zeile der aktuellen Viererzeile (z. B. Informationen zu Nachbarn oben links, oben, oben rechts und oben rechts rechts) bereitzustellen, kann in zumindest manchen Ausführungsformen ein Puffer der vorherigen Viererzeile in jeder der einen oder mehreren Stufen der Pipeline implementiert werden. Bei Verarbeiten einer Viererzeile werden Informationen für jeden Block in der unteren Zeile der Viererzeile in eine Nachbardatenstruktur in einem externen Speicher geschrieben, zum Beispiel durch eine letzte Stufe der Pipeline. Bei Verarbeiten von Blöcken aus der oberen Zeile einer nächsten Viererzeile werden Informationen für Nachbarblöcke in der unteren Zeile der vorherigen Viererzeile zum Beispiel durch eine erste Stufe der Pipeline aus dem externen Speicher gelesen und mit den Blöcken der oberen Zeile die Pipeline abwärts zu anderen Stufen geleitet. In zumindest manchen Ausführungsformen werden Informationen für den Nachbarblock oben rechts rechts eines Blocks in der oberen Zeile aus dem externen Speicher gelesen. In zumindest manchen Ausführungsformen ist der Puffer der vorherigen Viererzeile ein Ringpuffer, und ein ältester Eintrag im Puffer der vorherigen Viererzeile wird durch die Nachbarinformationen ersetzt, die aus dem externen Speicher gelesen werden. In verschiedenen Ausführungsformen kann der externe Speicher, in den Blöcke in der unteren Zeile geschrieben werden und aus dem Nachbarblockinformationen gelesen werden, ein Speicher der Pipelinekomponente, der für die letzte Stufe extern ist, ein Speicher eines Videocodierers, der die Pipeline implementiert, oder ein für den Videocodierer externer Speicher sein. In manchen Ausführungsformen kann der Speicher jedoch ein lokaler Speicher der letzten Stufe der Pipeline sein. Zumindest manche Ausführungsformen können einen Sperrmechanismus einschließen, um die Lesevorgänge und Schreibvorgänge auf den externen Speicher zwischen Zeilen zu steuern, um ein Überschreiben der Daten im externen Speicher zu verhindern.
  • 14 ist ein Ablaufdiagramm eines Verfahrens zum Verarbeiten von Blöcken in einer Blockverarbeitungspipeline, wobei auf den Stufen der Pipeline Nachbardaten in lokalen Puffer zwischengespeichert werden, entsprechend mindestens einigen Ausführungsformen. Zum Beispiel kann das Verfahren von 14 in Element 3106 von 11A verwendet werden, um in die Pipeline eingegebene Blöcke gemäß dem Rösselsprung-Verarbeitungsverfahren zu verarbeiten, wie in den Elementen 3100, 3102 und 3104 von 11A gezeigt. In 14 wird ein Block in die Pipeline eingegeben. Wenn der Block in der oberen Zeile einer Viererzeile ist, können in 4200 in einer ersten Stufe der Pipeline Nachbardaten für den Block aus dem externen Speicher (z. B. über DMA) in einen Puffer der vorherigen Viererzeile gelesen werden, wie in 4202 angegeben. In zumindest manchen Ausführungsformen entsprechen die Nachbardaten dem Nachbarn oben rechts rechts des aktuellen Blocks in der unteren Zeile der vorherigen Viererzeile. Wie in 4204 angegeben, wird der Block dann in der aktuellen Stufe verarbeitet. Wenn eine Operation in der Stufe Nachbarinformationen erfordert, um den Block zu verarbeiten, kann die Stufe die Nachbarinformationen im Puffer der aktuellen Viererzeile und/oder im Puffer der vorherigen Viererzeile verwenden, um die Operation durchzuführen. Wenn der Block in der oberen Zeile einer Viererzeile ist, können zumindest manche der Nachbarinformationen aus dem Puffer der vorherigen Viererzeile erworben werden; andernfalls können Nachbarinformationen aus dem Puffer der aktuellen Viererzeile erworben werden. Wie in 4206 angegeben, können Informationen über den aktuellen Block in der Stufe zur Verwendung bei nachfolgenden Blöcken in den Puffer der aktuellen Viererzeile geschrieben werden. Die Informationen können einen ältesten Eintrag im Puffer der aktuellen Viererzeile überschreiben.
  • Wenn es in 4208 weitere Stufen gibt, kann der Block an eine nächste Stufe gesendet werden, wie in 4210 angegeben. In 4212 können Nachbarinformationen aus dein Puffer der vorherigen Viererzeile auch an die nächste Stufe gesendet werden. In zumindest manchen Ausführungsformen werden diese Nachbarinformationen nur an die nächste Stufe gesendet, wenn der aktuelle Block in der oberen Zeile einer Viererzeile ist. Die Elemente 4204 bis 4212 können wiederholt werden, bis der Block eine letzte Stufe der Pipeline erreicht und durch sie verarbeitet wird. Wenn es in 4208 keine weiteren Stufen gibt, ist die Verarbeitung des Blocks in der Pipeline fertig. Wenn der Block in 4214 in der unteren Zeile einer Viererzeile ist, werden Informationen für den Block in einen externen Speicher geschrieben (z. B. über DMA), um als Nachbardaten für Blöcke in der oberen Zeile einer nächsten Viererzeile gelesen zu werden. Zusätzlich werden alle der verarbeiteten gültigen Blöcke ausgegeben, wie durch Element 3108 von 11A angegeben.
  • Beispielhafte Pipelineeinheiten
  • 15A bis 15C sind gemäß zumindest manchen Ausführungsformen Blockdiagramme von beispielhaften Pipelineverarbeitungseinheiten, die in den Stufen einer Blockverarbeitungspipeline verwendet werden können, die eines oder mehrere oder eine oder mehrere der hierin beschriebenen Blockverarbeitungsverfahren und -einrichtungen implementiert. Zum Beispiel können eine oder mehrere Pipelineeinheiten 5000A und/oder 5000B, wie in 15A und 15B gezeigt, in jeder Stufe der in 16 gezeigten Beispiel-Blockverarbeitungspipeline verwendet werden. Es ist zu beachten, dass 15A bis 15C nicht einschränkend beabsichtigt sind; eine Pipelineverarbeitungseinheit kann mehr oder weniger Komponenten und Merkmale als die in den Figuren gezeigten einschließen.
  • Wie in 15A gezeigt, kann eine Pipelineeinheit 5000A mindestens einen Speicher 5010 und einen Einheitskern 5020 einschließen. Der Einheitskern 5020 kann eine Komponente (z. B. eine Schaltung) sein, die dafür konfiguriert ist, auf einer bestimmten Stufe der Blockverarbeitungspipeline eine bestimmte Operation an einem oder für einen Block oder Abschnitt eines Blocks auszuführen. Der Speicher 5010 kann beispielsweise ein Doppelpufferspeicher sein, der dem Einheitskern 5020 ermöglicht, Daten für einen Block aus dem Speicher 5010 auszulesen und zu verarbeiten, während von einer vorhergehenden Pipelineeinheit Daten für einen nächsten Block in den Speicher 5010 geschrieben werden.
  • Wie in 15B gezeigt, kann eine Pipelineeinheit 5000B zusätzlich zu einem Speicher 5010 und einem Einheitskern 5020, wie in 15A gezeigt, auch einen Prozessor 5030 einschließen. Der Prozessor 5030 kann beispielsweise ein Mobile-Prozessor oder Prozessor der M-Klasse sein. Die Prozessoren 5030 in den Pipelineeinheiten 5000B einer Blockverarbeitungspipeline können zum Beispiel verwendet werden, um die Blockverarbeitungspipeline an Blockgrenzen zu steuern. Die Prozessoren 5030 in den Pipelineeinheiten 5000B können zum Beispiel mit Firmware-Mikrocode der unteren Ebene konfigurierbar sein, um Flexibilität bei Algorithmen zu erlauben, die durch die Blockverarbeitungspipeline für vielfältige Anwendungen implementiert werden. In zumindest manchen Ausführungsformen kann ein Prozessor 5030 einer Pipelineeinheit 5000B in der Pipeline konfiguriert sein, Daten von einem Prozessor 5030 einer vorherigen (vorgeschalteten) Pipelineeinheit 5000B zu empfangen und Daten an einen Prozessor 5030 einer nachfolgenden (nachgeschalteten) Pipelineeinheit 5000B zu senden. Des Weiteren kann ein Prozessor 5030 einer Pipelineeinheit 5000B in einer letzten Stufe der Pipeline konfiguriert sein, Feedback-Daten an einen Prozessor 5030 einer Pipelineeinheit 5000B in einer ersten Stufe der Pipeline zu senden.
  • Wie in 15A und 15B gezeigt, kann eine Pipelineeinheit 5000A oder 5000B konfiguriert sein, auf einen externen Speicher zuzugreifen, zum Beispiel gemäß „Direct Memory Access” (DMA). Des Weiteren kann eine Pipelineeinheit 5000A oder 5000B konfiguriert sein, Informationen zu einer oder mehreren vorherigen (vorgeschalteten) Stufen der Pipeline zurückzuleiten und/oder Informationen zu empfangen, die von einer oder mehreren nachfolgenden (nachgeschalteten) Stufen der Pipeline zurückgeleitet werden. Des Weiteren kann eine Pipelineeinheit 5000A oder 5000B konfiguriert sein, Informationen zu einem oder mehreren nachfolgenden (nachgeschalteten) Stufen der Pipeline vorwärtszuleiten und/oder Informationen zu empfangen, die von einer oder mehreren vorherigen (vorgeschalteten) Stufen der Pipeline vorwärts geleitet werden.
  • Wie in 15C gezeigt, können zwei oder mehr Einheiten 5000A, wie in 15A gezeigt, miteinander gruppiert werden und konfiguriert sein, eine Operation in der Pipeline durchzuführen. Ein einziger Prozessor 5030 kann verwendet werden, um die Pipelineeinheiten 5000A zu steuern und/oder zu konfigurieren.
  • Beispiel-Blockverarbeitungspipeline
  • 16 ist gemäß zumindest manchen Ausführungsformen ein übergeordnetes Blockdiagramm von allgemeinen Operationen in einem Beispiel-Blockverarbeitungsverfahren 6000 zur H.264-Codierung, das in den Stufen durch eine Blockverarbeitungspipeline implementiert werden kann, die ein oder mehrere oder eine oder mehrere der hierin beschriebenen Blockverarbeitungsverfahren und -einrichtungen implementieren kann. Eine Blockverarbeitungspipeline, die das Blockverarbeitungsverfahren 6000 implementiert, kann zum Beispiel als eine Komponente einer H.264-Videocodiereinrichtung implementiert sein, die konfiguriert ist, Eingabevideo-Frames aus einem Eingabeformat in ein H.264/„Advanced Video Coding”(AVC)-Format, wie im Standard H.264/AVC beschrieben, umzuwandeln. Der Standard H.264/AVC wurde durch die ITU-T in einem Dokument mit dem Titel „ITU-T Recommendation H.264: Advanced video coding for generic audiovisual services” veröffentlicht, das als die H.264-Empfehlung bezeichnet werden kann. Ein Beispiel-Eingabevideoformat ist 1080p (1920×1080 Pixel; 2,1 Megapixel), das im YCbCr-Farbraum codiert ist. Andere Eingabevideoformate können jedoch unter Verwendung von Ausführungsformen der Pipeline in einer Videocodiereinrichtung in H.264 codiert werden.
  • Die Videocodiereinrichtung kann zum Beispiel als eine integrierte Schaltung (integrated circuit (IC)) oder als Teilsystem auf einer IC, wie beispielsweise ein System auf einem Chip (system-on-a-chip (SOC)) implementiert werden. In zumindest manchen Ausführungsformen kann die Videocodiereinrichtung mindestens eine Pipelinekomponente, eine Prozessorkomponente (z. B. einen Mehrfachkernprozessor mit geringer Leistung (low power) und ein Busteilsystem oder eine Busstruktur (bus fabric) einschließen, welche die funktionellen Komponenten der Einrichtung miteinander verbindet. Die Prozessorkomponente der Videocodiereinrichtung kann zum Beispiel eine Steuerung der Pipeline auf Frame-Ebene, wie beispielsweise eine Ratensteuerung, durchführen, eine Pipelinekonfiguration durchführen und über einen Treiber eine Schnittstellenverbindung mit Anwendungssoftware herstellen. Die Pipelinekomponente kann mehrere Verarbeitungsstufen implementieren, von denen jede konfiguriert ist, einen Abschnitt oder alles von einer oder mehreren der in 16 gezeigten Operationen durchzuführen, wobei jede Stufe eine oder mehrere Verarbeitungseinheiten einschließt. Mindestens eine der Verarbeitungseinheiten in der Pipeline kann eine Prozessorkomponente einschließen (z. B. einen Prozessor der M-Klasse), die zum Beispiel Parameter der Verarbeitungseinheit in der jeweiligen Stufe auf Ebene des Makroblocks konfigurieren kann. Die Videocodiereinrichtung kann weitere funktionelle Komponenten oder Einheiten, wie beispielsweise Speicherkomponenten, sowie externe Schnittstellen zu zum Beispiel einer oder mehreren Videoeingabequellen und einem externen Speicher einschließen. Beispiel-Videoeingabequellen für die Videocodiereinrichtung können eines oder mehrere von einer Videokamera für Rohvideoeingabeverarbeitung, eine Decodiereinichtung zum wiedercodieren/transcodieren, einen Flash- oder anderen Speicher und einem JPEG-Decodierer einschließen, sind jedoch nicht auf diese beschränkt. Eine Beispiel-Videocodiereinrichtung ist in 15 veranschaulicht. Ein Beispiel-SOC, das eine Videocodiereinrichtung einschließt, ist in 16 veranschaulicht. Obwohl Ausführungsformen allgemein in Bezug auf Hardwareimplementierungen einer Blockverarbeitungspipeline beschrieben sind, die das Blockverarbeitungsverfahren 6000 mit der Rösselsprung-Verarbeitung, implementiert, ist zu beachten, dass das Blockverarbeitungsverfahren 6000 mit der Rösselsprung-Verarbeitung durch eine in Software implementierte Blockverarbeitungspipeline implementiert werden kann.
  • Eine Pipeline, die das Verfahren 6000 implementiert, wie in 16 gezeigt, kann 16×16 Pixelmakroblöcke aus Eingabevideo-Frames gemäß dem Standard H.264 verarbeiten, wobei jeder Makroblock zwei oder mehr Blöcke oder Partitionen einschließt, die separat in Stufen der Pipeline verarbeitet werden können. Die Eingabevideo-Frames können zum Beispiel im YCbCr-Farbschema codiert sein; jeder Makroblock kann aus separaten Blöcken von Chroma- und Luma-Elementen zusammengesetzt sein, die separat in den Stufen der Pipeline verarbeitet werden können. Eine Pipeline, die das Blockverarbeitungsverfahren 6000 implementiert, kann Eingabemakroblöcke von einem Speicher empfangen und verarbeitete Makroblöcke in ihn eingeben. Der Speicher kann einen Speicher der Videocodiereinrichtung und/oder einen Speicher einschließen, der für die Videocodiereinrichtung extern ist. In zumindest manchen Ausführungsformen kann durch die Pipeline nach Bedarf auf den Speicher zugegriffen werden, zum Beispiel über „Direct Memory Access” (DMA). In zumindest manchen Ausführungsformen kann der Speicher als ein Mehrebenenspeicher mit einem zwischen der Pipeline und dem externen Speicher implementierten Cache-Speicher implementiert sein. Zum Beispiel können in manchen Implementierungen eine oder mehrere Viererzeilen aus einem externen Speicher gelesen und in den Cache-Speicher zum Zugriff durch die Pipeline gespeichert werden, um die Anzahl von Lesevorgängen auf einen externen Speicher zu verringern.
  • Die allgemeinen Operationen des H.264-Beispiel-Videocodierverfahrens 6000, wie in 16 gezeigt, das durch eine Pipeline in Stufen durchgeführt werden kann, sowie ein allgemeiner Datenfluss durch die Pipeline werden nachstehend kurz beschrieben. Jede der allgemeinen Operationen des Verfahrens 6000 kann durch eine oder mehrere Pipelineeinheiten in einer oder mehreren Stufen der Pipeline implementiert werden. Beispielhafte Pipelineeinheiten sind in 13A bis 13C veranschaulicht. Es ist zudem zu beachten, dass jede in 16 gezeigte allgemeine Operation in zwei oder mehr Operationen unterteilt werden kann, die durch Pipelineeinheiten in einer, zwei oder mehr Stufen der Pipeline implementiert werden können. Zwei oder mehr der in 16 gezeigten Operationen könne in derselben Stufe der Pipeline durchgeführt werden. Jede Stufe in der Pipeline verarbeitet einen Makroblock auf einmal, und somit können zwei oder mehr der Operationen gleichzeitig an demselben Makroblock arbeiten, der derzeit in der entsprechenden Stufe ist. Es ist zu beachten, dass eine Pipeline mehr, weniger oder andere Operationen als die in 16 gezeigten und nachstehend beschriebenen durchführen kann.
  • Makroblockeingabe
  • In zumindest manchen Ausführungsformen kann eine Makroblockeingabe 6002 durch eine Anfangsstufe der Pipeline durchgeführt werden. In zumindest manchen Ausführungsformen empfängt die Makroblockeingabe 6002 Luma- und Chroma-Pixel aus einem Speicher, zum Beispiel über DMA, berechnet Statistiken zu Eingabepixeln, die durch Firmware in nachgeschalteten Stufen der Pipeline verwendet werden, und puffert Eingabemakroblöcke, um ein Vorausschauen der Firmware zu erlauben. Die Eingabemakropixeldaten und entsprechenden Statistiken werden gepuffert und an eine oder mehrere nachgeschaltete Stufen der Pipeline gesendet, die Operationen einer Intra-Frame- und Inter-Frame-Abschätzung 6010 erlauben. In zumindest manchen Ausführungsformen wird ein Eingabepuffer von bis zu 16 Makroblöcken für Eingabepixel und Statistiken unterhalten. Die Makroblockpixeldaten und entsprechenden Statistiken können in nachgeschaltete Stufen der Pipeline gemäß einem Rösselsprung-Eingabealgorithmus eingegeben werden, wie zuvor in Bezug auf 3 bis 8B beschrieben.
  • In zumindest manchen Ausführungsformen liest die Makroblockeingabe 6002 Nachbardaten aus der unteren Zeile einer vorherigen Viererzeile aus einem Speicher an Viererzeilengrenzen und leitet die Nachbardaten an mindestens eine nachgeschaltete Stufe.
  • Intra-Frame- und Inter-Frame-Abschätzung
  • Die Operationen einer Intra-Frame- und Inter-Frame-Abschätzung 6010 können Blöcke von zuvor codierten Pixeln ermitteln, die beim Codieren von in die Pipeline eingegebenen Makroblöcken zu verwenden sind. Bei der H.264-Videocodierung kann jeder Makroblock unter Verwendung von Blöcken von Pixeln codiert werden, die bereits innerhalb des aktuellen Frames codiert sind. Der Prozess des Ermittelns dieser Blöcke kann als Intra-Frame-Abschätzung oder einfach Intra-Abschätzung bezeichnet werden. Makroblöcke können jedoch auch unter Verwendung von Blöcken von Pixeln aus einem oder mehreren zuvor codierten Frames (als Referenz-Frames bezeichnet) codiert werden. Der Prozess des Suchens von passenden Pixelblöcken in Referenz-Frames kann als Inter-Frame-Abschätzung oder allgemeiner als Bewegungsabschätzung bezeichnet werden. Die Operationen der Intra-Frame- und Inter-Frame-Abschätzung 6010 können in zwei oder mehr Teiloperationen unterteilt werden, die in einer, zwei oder mehr Stufen der Pipeline durchgeführt werden können, wobei eine oder mehrere Komponenten oder Pipelineeinheiten in jeder Stufe konfiguriert sind, eine bestimmte Teiloperation durchzuführen.
  • In zumindest manchen Ausführungsformen liest die Makroblockeingabe 6002 Nachbardaten aus der unteren Zeile einer vorherigen Viererzeile an Viererzeilengrenzen aus einem Speicher und leitet die Nachbardaten an die Intra-Frame- und Inter-Frame-Abschätzung 6010, zum Beispiel an eine Komponente zur Intra-Frame-Abschätzung. Zusätzlich kann eine Bewegungskompensation und Rekonstruktion 6030, zum Beispiel eine Luma-Rekonstruktionskomponente, Nachbardaten als Feedback an die Intra-Frame- und Inter-Frame-Abschätzung 6010 leiten, zum Beispiel an die Komponente zur Intra-Frame-Abschätzung.
  • Bewegungsabschätzung
  • In zumindest manchen Ausführungsformen kann die Pipeline eine Instanz einer Bewegungsabschätzungs-Engine für jedes zu durchsuchende Referenz-Frame einschließen, um eine Bewegungsabschätzung durchzuführen. Jede Bewegungsabschätzungs-Engine durchsucht nur ein einziges Referenz-Frame. In zumindest manchen Ausführungsformen kann jede Bewegungsabschätzungs-Engine eine Bewegungsabschätzungskomponente mit niedriger Auflösung, eine Vollpixel-Bewegungsabschätzungskomponente und eine Teilpixel-Bewegungsabschätzungskomponente einschließen In zumindest manchen Ausführungsformen können die drei Komponenten jeder der Bewegungsabschätzungs-Engines in unterschiedlichen Stufen der Pipeline implementiert sein. In zumindest manchen Ausführungsformen kann jede Bewegungsabschätzungs-Engine zudem eine Speicherkomponente einschließen, die Referenz-Frame-Daten nach Bedarf aus einem Speicher liest und speichert. In zumindest manchen Ausführungsformen verwaltet eine einzige Instanz eines Prozessors alle Instanzen der Bewegungsabschätzungs-Engine. In zumindest manchen Ausführungsformen kann der Prozessor einen oder mehrere Kandidaten unter Verwendung von vorhergesagten und gleich angeordneten Bewegungsvektoren ermitteln und die Kandidaten in die Vollpixel-Abschätzungskomponenten der Bewegungsabschätzungs-Engines eingeben.
  • In zumindest manchen Ausführungsformen führt die Bewegungsabschätzungskomponente mit niedriger Auflösung jeder Bewegungsabschätzungs-Engine eine erschöpfende Suche an einer abwärts skalierten Version mit niedriger Auflösung eines entsprechenden Referenz-Frame durch, um Kandidaten zu erzeugen. In zumindest manchen Ausführungsformen führt die Vollpixel-Bewegungsabschätzungskomponente eine Suche an Pixeln mit voller Größe unter Verwendung von Kandidaten aus der Bewegungsabschätzungskomponente mit niedriger Auflösung durch. In zumindest manchen Ausführungsformen führt die Teilpixel-Bewegungsabschätzungskomponente eine Suche an Pixeln mit halber und viertel Größe unter Verwendung der besten Kandidaten durch, die von der Vollpixel-Bewegungsabschätzungskomponente empfangen wurden. In manchen Ausführungsformen können die Vollpixel-Bewegungsabschätzung und die Teilpixel-Bewegungsabschätzung auf der Grundlage von Ergebnissen einer Direktmodusabschätzung deaktiviert werden, die in einer vorgeschalteten Stufe der Pipeline durchgeführt wurde. In zumindest manchen Ausführungsformen gibt jede Bewegungsabschätzungs-Engine Ergebnisdaten an eine Modusentscheidung 6020 aus.
  • In zumindest manchen Ausführungsformen kann die Bewegungsabschätzung auch eine Direktmodus-Abschätzungskomponente einschließen, die gleich angeordnete und räumliche Bewegungsvektordaten empfängt und Direkt/Überspringmoduskosten berechnet, die sie der Modusentscheidung 6020 bereitstellt. Auf der Grundlage der Ergebnisse kann die Direktmodus-Abschätzungskomponente die Vollpixel-Bewegungsabschätzung und die Teilpixel-Bewegungsabschätzung deaktivieren.
  • Intra-Abschätzung
  • In zumindest manchen Ausführungsformen führt eine Intra-Abschätzungskomponente der Pipeline eine Intra-Modusauswahl durch, um Blöcke von Pixeln zu ermitteln, die bereits innerhalb des aktuellen Frame codiert sind, die beim Codieren eines aktuellen Makroblocks verwendet werden können. In zumindest manchen Ausführungsformen führt die Intra-Abschätzungskomponente eine Intra-Modusauswahl nur für Luma durch. In diesen Ausführungsformen wird eine Chroma-Intra-Abschätzung durch eine Chroma-Rekonstruktionskomponente in einer nachgeschalteten Stufe der Pipeline durchgeführt. In zumindest manchen Ausführungsformen kann die Intra-Abschätzungskomponente die Intra-Abschätzung unabhängig für jeden oder jede von zwei oder mehr Blöcken oder Partitionen (z. B. 4 × 4, 8 × 8, 4 × 8, 8 × 4, 16 × 8 und/oder 8 × 16 Blöcke) in einem Makroblock durchführen. Für jeden Block werden zuerst Vorhersagepixel aus Nachbarblöcken extrahiert (Nachbarblöcke können außerhalb des aktuellen Makroblocks im Frame oder innerhalb des aktuellen Makroblocks sein). Für jeden Vorhersagemodus im aktuellen Block werden die Kosten des aktuellen Modus durch Erstellen eines Vorhersageblocks aus Nachbarpixeln, Berechnen von Moduskosten und Vergleichen der Moduskosten mit Mindestkosten für diesen Block bewertet. Sobald alle Vorhersagemodi bewertet wurden und der beste Modus ermittelt wurde, kann die Rekonstruktion für den besten Modus durchgeführt werden, sodass rekonstruierte Pixel verwendet werden können, um zukünftige Blöcke innerhalb eines Makroblocks vorherzusagen. Die Intra-Abschätzungskomponente kann die Informationen zum besten Intra-Modus an die Modusentscheidung 6020 leiten.
  • In zumindest manchen Ausführungsformen liest die Makroblockeingabe 6002 Nachbardaten aus der unteren Zeile einer vorherigen Viererzeile aus einem Speicher an Viererzeilengrenzen und leitet die Nachbardaten an die Intra-Abschätzungskomponente. In zumindest manchen Ausführungsformen kann mindestens eine nachgeschaltete Stufe (z. B. eine Luma-Rekonstruktionskomponente in einer nachgeschalteten Stufe) Nachbardaten an die Intra-Abschätzungskomponente zurückleiten.
  • Modusentscheidung
  • In zumindest manchen Ausführungsformen kann die Modusentscheidung 6020 durch eine Modusentscheidungskomponente in einer Stufe der Pipeline implementiert sein, die der einen oder den mehreren Stufen nachgeschaltet ist, welche die Operationen der Intra-Frame- und Inter-Frame-Abschätzung 6010 implementieren. In manchen Ausführungsformen können die Operationen der Modusentscheidung 6020 jedoch in zwei oder mehr Teiloperationen unterteilt werden, die in einer, zwei oder mehr Stufen der Pipeline durchgeführt werden können, wobei eine oder mehrere Komponenten oder Pipelineeinheiten in jeder Stufe konfiguriert sind, eine bestimmte Teiloperation durchzuführen. In zumindest manchen Ausführungsformen empfängt die Komponente der Modusentscheidung 6020 den besten Intra-Modus von der Intra-Abschätzung, Direkt/Überspringmoduskosten von der Direktmodusabschätzung und Bewegungsvektorkandidaten von den Bewegungsabschätzungs-Engines. In zumindest manchen Ausführungsformen berechnet die Modusentscheidungskomponente zusätzliche Kosten für bidirektionale Modi und ermittelt den besten Makroblocktyp einschließlich Makroblockpartitionen, Teilpartitionen, Vorhersagerichtung und Referenz-Frame-Indices. In zumindest manchen Ausführungsformen führt die Komponente der Modusentscheidung 6020 zudem eine Vorhersage aller Bewegungsvektoren aus. Die Ergebnisse der Bewegungsvektorvorhersage können verwendet werden, wenn die Bewegungsvektorrate während der Modusentscheidung abgeschätzt wird. In zumindest manchen Ausführungsformen können die Ergebnisse der Bewegungsvektorvorhersage zudem aus der Modusentscheidungskomponente 6020 zur Bewegungsabschätzung zurückgeführt werden, zum Beispiel zur Verwendung in der Direktmodusabschätzung und der Bewegungsvektorratenabschätzung.
  • Bewegungskompensation und Rekonstruktion
  • In zumindest manchen Ausführungsformen können die Operationen der Bewegungskompensation und Rekonstruktion 6030 in zwei oder mehr Teiloperationen unterteilt werden, die in einer, zwei oder mehr Stufen der Pipeline durchgeführt werden können, wobei eine oder mehrere Komponenten oder Pipelineeinheiten in jeder Stufe konfiguriert sind, eine bestimmte Teiloperation durchzuführen. Zum Beispiel kann in manchen Ausführungsformen die Bewegungskompensation und Rekonstruktion 6030 in eine Luma-Bewegungskompensation und -Rekonstruktion und eine Chroma-Bewegungskompensation und -Rekonstruktion unterteilt werden. In zumindest manchen Ausführungsformen kann jede dieser Teiloperationen der Bewegungskompensation und Rekonstruktion 6030 durch eine oder mehrere Komponenten oder Pipelineeinheiten in einer oder mehreren Stufen der Pipeline durchgeführt werden.
  • Luma-Bewegungskompensation und -Rekonstruktion
  • In zumindest manchen Ausführungsformen empfängt eine Luma-Bewegungskompensationskomponente der Pipeline den besten Modus und entsprechende Bewegungsvektoren von der Modusentscheidung 6020. Wie zuvor festgehalten, kann jede Bewegungsabschätzungs-Engine eine Speicherkomponente einschließen, die Referenz-Frame-Daten aus einem Speicher liest und speichert. Wenn der beste Modus Inter-vorhergesagt wird, fordert die Luma-Bewegungskompensationskomponente Referenz-Frame-Makroblöcke aus der Bewegungsabschätzungs-Engine an, die den Bewegungsvektoren entsprechen. Die Bewegungsabschätzungs-Engine gibt teilpixelintrapolierte 4 × 4- oder 8 × 8-Blöcke aus, die von der angeforderten Größe abhängen. Die Luma-Bewegungskompensationskomponente kombiniert dann die Blöcke in Vorhersagemakroblöcken. Die Luma-Bewegungskompensationskomponente wendet dann eine gewichtete Vorhersage auf die Vorhersagemakroblöcke an, um den endgültigen Makroblockvorhersager zu erstellen, der dann an die Luma-Rekonstruktionskomponente geleitet wird.
  • In zumindest manchen Ausführungsformen führt eine Luma-Rekonstruktionskomponente der Pipeline eine Makroblockrekonstruktion für Luma einschließlich Intra-Vorhersage (in zumindest manchen Ausführungsformen führt die Luma-Bewegungskompensationskomponente eine Intra-Vorhersage durch), Vorwärtsumwandlung und Quantisierung (forward transform and quantization (FTQ)) und inverse Transformation und Quantisierung (inverse transform and quantization (ITQ)) durch.
  • In zumindest manchen Ausführungsformen wird auf der Grundlage des besten Modus von der Modusentscheidung 6020 entweder ein Inter-Vorhersagemakroblock aus der Luma-Bewegungskompensationskomponente weitergeleitet, oder eine Intra-Vorhersage wird durch die Luma-Rekonstruktionskomponente durchgeführt, um einen Vorhersageblock zu erzeugen. Im Intra-Modus wird die Vorhersage in Block(abstast)reihenfolge durchgeführt, da rekonstruierte Pixel aus Nachbarblöcken für die Vorhersage zukünftiger Blöcke benötigt werden. Der Eingabeblock wird vom Vorhersageblock subtrahiert, um einen Bleibeblock (residual block) zu erzeugen. Die Bleibepixeldaten werden durch eine durch die Luma-Rekonstruktionskomponente implementierte FTO-Technik transformiert und quantisiert. Die Koeffizientendaten werden an die durch die Luma-Rekonstruktionskomponente implementierte ITQ-Technik gesendet und können auch abwärts zur CAVLC-Codierung gesendet werden. Die ITQ-Technik erzeugt einen rekonstruierten Bleibepixelblock. Der Vorhersageblock wird zum Bleibeblock addiert, um den rekonstruierten Block zu erzeugen. Rekonstruierte Pixel können abwärts zu ein Entsperrfilter geleitet werden. In zumindest manchen Ausführungsformen können rekonstruierte Pixel auch zur Vorhersage zukünftiger Blöcke innerhalb des aktuellen Makroblocks zurück zu einer Intra-Frame-Abschätzungskomponente der Intra-Frame- und Inter-Frame-Abschätzung 6010 geleitet werden.
  • Chroma-Bewegungskompensation und Rekonstruktion
  • In zumindest manchen Ausführungsformen wird die Chroma-Rekonstruktion in zwei Stufen durchgeführt. In der ersten Stufe werden für die Inter-Vorhersage benötigte Chroma-Referenzblöcke auf der Grundlage von Eingabemakroblocktyp, Bewegungsvektoren und Referenz-Frame-Index aus einem Speicher gelesen. Dann wird eine Teilpixelinterpolation und gewichtete Vorhersage angewandt, um einen Vorhersagemakroblock zu erzeugen. In der zweiten Stufe wird die Chroma-Intra-Vorhersage und die Chroma-Intra/Inter-FTQ/ITQ durchgeführt. Dies ermöglicht eine zusätzliche Pipelinestufe zum Laden von Chroma-Vorhersagepixeldaten. Da Chroma-Pixel nicht durch die Bewegungsabschätzung durchsucht werden, werden die Chroma-Vorhersagedaten aus einem externen Speicher gelesen und können eine große Latenz aufweisen. In zumindest manchen Ausführungsformen führt eine Chroma-Bewegungskompensationskomponente die erste Stufe durch, während eine Chroma-Rekonstruktionskomponente die zweite Stufe durchführt.
  • In zumindest manchen Ausführungsformen erzeugt die Chroma-Bewegungskompensationskomponente einen Vorhersageblock einschließlich Teilpixelinterpolation für Cb- und Cr-Chroma-Blöcke; die Größe beruht auf der Partitionsgröße und Chroma-Formaten. Ein Chroma-Block voller Größe ist 8×8, 8×16 oder 16×16 Pixel für die Chroma-Formate 4:2:0, 4:2:2 bzw. 4:4:4. In zumindest manchen Ausführungsformen kann die Chroma-Bewegungskompensationskomponente Chroma-Vorhersagepixel aus einem (für die Pipeline) externen Speicher vorab abrufen und cachen. In zumindest manchen Ausführungsformenkönnen Referenzdaten auf der Grundlage der Ergebnisse der Modusentscheidung 6020 gelesen werden. Die Chroma-Bewegungskompensationskomponente führt eine Teilpixelinterpolation durch, um einen Vorhersageblock zu erzeugen. Die Modusentscheidung 6020 stellt den Makroblocktyp und Untertypen, den Referenz-Frame-Index je Partition und entsprechende Bewegungsvektoren bereit. Die Vorhersage wird der Chroma-Rekonstruktionskomponente ausgegeben.
  • In zumindest manchen Ausführungsformen führt die Chroma-Rekonstruktionskomponente eine Chroma-Vorhersage, eine Chroma-Intra-Abschätzung und eine Chroma-Rekonstruktion für Inter- und Intra-Modi durch. Für die Chroma-Formate 4:2:0 und 4:2:2 wird eine Intra-Chroma-Abschätzung und -Vorhersage durchgeführt. In zumindest manchen Ausführungsformenwird die Chroma-Intra-Abschätzung in dieser Stufe statt bei der Intra-Frame- und Inter-Frame-Abschätzung 6010 durchgeführt, sodass rekonstruierte Pixel während des Abschätzungsprozesses verwendet werden können. Wenn der beste Modus in Intra ist, kann in zumindest manchen Ausführungsformeneine Intra-Chroma-Abschätzung auf der Grundlage des besten Intra-Chroma-Modus durchgeführt werden, und eine Intra-Vorhersage kann unter Verwendung eines von vier Intra-Chroma-Modi durchgeführt werden. Für Inter-Makroblöcke werden Inter-Chroma-Vorhersagepixel aus der Chroma-Bewegungskompensation empfangen. Für das Chroma-Format 4:4:4 werden die Luma-Intra-Vorhersagemodi verwendet, um die Chroma-Blockvorhersage zu erzeugen, und die Inter-Chroma-Vorhersage wird auf dieselbe Weise wie für Luma durchgeführt. Daher schließt die Chroma-Rekonstruktion konzeptionell eine 4:2:0- und 4:2:2-Chroma-Rekonstruktion und -Luma-Rekonstruktion ein, die verwendet werden, um die Chroma im 4:4:4-Chroma-Format zu rekonstruieren.
  • CAVLC-Codieren und -Entsperren
  • In zumindest manchen Ausführungsformen kann ein CAVLC-Codieren und -Entsperren durch eine oder mehrere Komponenten in einer letzten Stufe der Pipeline durchgeführt werden. In zumindest manchen Ausführungsformen empfängt eine Entsperrfilterkomponente der Pipeline rekonstruierte Luma- und Chroma-Pixel von der Chroma-Rekonstruktionskomponente und führt ein Entsperrfiltern gemäß der H.264-Empfehlung durch. Die Ergebnisse können in einen Speicher ausgegeben werden.
  • In zumindest manchen Ausführungsformen empfängt eine CAVLC-Codierkomponente der Pipeline mindestens Luma- und Chroma-quantisierte Komponenten, Nachbardaten und Chroma-Rekonstruktionsergebnisse von der Chroma-Rekonstruktionskomponente und erzeugt einen CAVLC(context-adaptive variable-length coding)-codierten Ausgabedatenstrom in einem Speicher.
  • In zumindest manchen Ausführungsformen schreiben die Entsperrfilterkomponenten und die CAVLC-Codierkomponente Nachbardaten für die untere Zeile einer Viererzeile an Viererzeilengrenzen in einen Speicher. Für die obere Zeile einer nächsten Viererzeile kann die Makroblockeingabe 6002 dann diese Nachbardaten an Viererzeilengrenzen aus dem Speicher lesen und die Nachbardaten zu mindestens einer nachgeschalteten Stufe der Pipeline leiten.
  • Transcoder
  • In zumindest manchen Ausführungsformen kann eine Transcodieroperation durch einen Transcoder 6050 durchgeführt werden. Der Transcoder kann als eine funktionelle Komponente der Pipeline oder als eine funktionelle Komponente, die für die Pipeline extern ist, implementiert werden. In zumindest manchen Ausführungsformen kann der Transcoder 6050 eine Speicher-zu-Speicher-Umwandlung eines durch die Pipeline ausgegebenen CAVLC(lcontext-adaptive variable-length coding)-codierten Datenstroms in einen CABAC(context-adaptive binary arithmetic coding)-codierten Datenstrom durchführen.
  • In zumindest manchen Ausführungsformen kann die Pipeline in einer anderen Reihenfolge als der Abtastreihenfolge codieren, zum Beispiel der Rösselsprung-Reihenfolge „Knight's Order”, wie zuvor hierin beschrieben. Letztendlich sollte jedoch der codierte Bitdatenstrom des H.264-Videocodierers in herkömmlicher Makroblockabtastreihenfolge übermittelt werden. In zumindest manchen Ausführungsformen wird das Neuordnen der aus dem Rösselsprung ausgegebenen Makroblocks dadurch erreicht, dass die CAVLC-Codierkomponente codierte Daten in vier unterschiedliche Ausgabepuffer schreibt, wobei jeder Ausgabepuffer einer Makroblockzeile entspricht. Am Ende einer Viererzeile wird jeder Zeilenpuffer einen Abtastreihenfolgendatenstrom codierter Makroblöcke für eine entsprechende Zeile aufweisen. Der Transcoder 6050 wickelt das Festlegen des Starts und den Endes jeder Zeile ab, um einen kontinuierlichen Datenstrom an Makroblock-Zeilengrenzen zu erzeugen. In zumindest manchen Ausführungsformen kann die Pipeline Metadaten in den CAVLC-Ausgabedatenstrom einbetten, um das Festlegen der Zeilen durch den Transcoder 6050 zu ermöglichen.
  • Beispiel-Videocodiereinrichtung
  • 17 ist ein Blockdiagramm einer Beispiel-Videocodiereinrichtung 7000 gemäß zumindest manchen Ausführungsformen. Die Videocodiereinrichtung 7000 kann zum Beispiel als eine integrierte Schaltung (integrated circuit (IC)) oder als Teilsystem auf einer IC, wie beispielsweise ein System auf einem Chip (system-on-a-chip (SOC)) implementiert werden. In zumindest manchen Ausführungsformen kann die Videocodiereinrichtung 7000 eine Komponente einer Pipeline 7040, eine Komponente eines Prozessors 7010 (z. B. ein Mehrfachkernprozessor mit geringer Leistung), eine Speicherverwaltungseinheit (memory management unit (MMU)) 7020, eine DMA 7030 und eine Verbindung 7050, wie beispielsweise ein Busteilsystem oder eine Busstruktur (fabric), einschließen, welche die funktionellen Komponenten der Einrichtung miteinander verbindet. Die Komponente eines Prozessors 7010 der Videocodiereinrichtung 7000 kann zum Beispiel eine Steuerung der Pipeline 7040 auf Frame-Ebene, wie beispielsweise eine Ratensteuerung, eine Konfiguration der Pipeline 7040 einschließlich einer Konfiguration einzelner Pipelineeinheiten innerhalb der Pipeline 7040 durchführen und eine Schnittstellenverbindung mit Anwendungssoftware über einen Treiber, zum Beispiel zur Konfiguration des Videocodierers 7000, herstellen. Die MMU 7020 kann als eine Schnittstelle zu einem externen Speicher, zum Beispiel zum Streaming von Videoeingabe und/oder -ausgabe, dienen. Die Komponente einer Pipeline 7040 kann auf den Speicher über den DMA 7030 durch die MMU 7020 zugreifen. In manchen Ausführungsformen kann die Videocodiereinrichtung 7000 weitere funktionelle Komponenten oder Einheiten, die in 17 nicht gezeigt sind, oder weniger funktionelle Komponenten als die in 17 gezeigten einschließen. Ein Beispiel-Blockverarbeitungsverfahren, das durch die Komponente einer Pipeline 7040 implementiert werden kann, ist in 16 gezeigt. Ein Beispiel-System auf einem Chip (SOC), das mindestens eine Videocodiereinrichtung 7000 einschließen kann, ist in 18 veranschaulicht.
  • Beispielsystem auf einem Chip (SOC)
  • Unter Hinwendung zu 18 wird nun ein Blockdiagramm einer Ausführungsform eines Systems auf einem Chip (SOC) 8000 gezeigt, das mindestens eine Instanz einer Videocodiereinrichtung einschließlich einer Blockverarbeitungspipeline einschließen kann, die ein oder eine oder mehrere der Blockverarbeitungsverfahren und -einrichtungen, wie in 3 bis 17 veranschaulicht, implementieren kann. Das SOC 8000 ist mit einem Speicher 8800 gekoppelt gezeigt. Wie durch den Namen impliziert, können die Komponenten des SOC 8000 auf einem einzigen Halbleitersubstrat als ein „Chip” einer integrierten Schaltung integriert sein. In manchen Ausführungsformen können die Komponenten auf zwei oder mehr diskreten Chips in einem System implementiert sein. Das SOC 8000 wird jedoch hierein als ein Beispiel verwendet. In der veranschaulichten Ausführungsform schließen die Komponenten des SOC 8000 einen Komplex einer Zentraleinheit (central processing unit (CPU)) 8020, chipinterne Peripheriekomponenten 8040A bis 8040B (kürzer „Peripherieeinheiten”), eine Speichersteuereinheit (memory controller (MC)) 8030, einen Videocodierer 7000 (der selbst als eine Peripheriekomponente bezeichnet werden kann) und eine Kommunikationsstruktur (communication fabric) 8010 ein. Die Komponenten 8020, 8030, 8040A bis 8040B und 7000 können alle mit der Kommunikationsstruktur 8010 gekoppelt sein. Die Speichersteuereinheit 8030 kann während der Verwendung mit dem Speicher 8800 gekoppelt sein, und die Peripherieeinheit 8040B kann während der Verwendung mit einer externen Schnittstelle 8900 gekoppelt sein. In der veranschaulichten Ausführungsform schließt der CPU-Komplex 8020 einen oder mehrere Prozessoren (P) 8024 und einen Cache der Ebene 2 (L2) 8022 ein.
  • Die Peripherieeinheiten 8040A bis 8040B können jeder beliebige Satz zusätzlicher Hardwarefunktionalität sein, die im SOC 8000 eingeschlossen ist. Zum Beispiel können die Peripherieeinheiten 8040A bis 8040B Videoperipherieeinheiten, wie beispielsweise einen Bildsignalprozessor, der konfiguriert ist, Bilderfassungsdaten aus einer Kamera oder einem anderen Bildsensor zu verarbeiten, Anzeigesteuereinheiten, die konfiguriert sind, Videodaten auf einer oder mehreren Anzeigevorrichtungen anzuzeigen, Grafikverarbeitungseinheiten (graphics processing units (GPUs)), Videocodierer/-decodierer, Skalierer, Dreher, Mischer usw. einschließen. Die Peripherieeinheiten können Audioperipherieeinheiten, wie beispielsweise Mikrofone, Lautsprecher, Schnittstellen zu Mikrofonen und Lautsprechern, Audioprozessoren, digitale Signalprozessoren, Mischer usw., einschließen. Die Peripherieeinheiten können Peripherieschnittstellen-Steuereinheiten für verschiedene Schnittstellen 8900, die für das SOC 8000 extern sind (z. B. die Peripherieeinheit 8040B), und Schnittstellen, wie beispielsweise „Universal Serial Bus” (USB), „Peripheral Component Interconnect” (PCI) einschließlich „PCI Express” (PCIe), serielle und parallele Anschlüsse usw., einschließen. Die Peripherieeinheiten können Netzwerkperipherieeinheiten, wie beispielsweise Medienzugangssteuereinheiten (media access controllers (MACs)), einschließen. Jeder beliebige Satz von Hardware kann eingeschlossen sein.
  • Genauer kann das SOC 8000 in 18 mindestens eine Instanz einer Komponente eines Videocodierers 7000 einschließen, zum Beispiel einen Videocodierer 7000, wie in 17 veranschaulicht, der eine Komponente einer Blockverarbeitungspipeline 7040 einschließt, die ein Blockverarbeitungsverfahren 6000, wie in 16 veranschaulicht, implementiert. Der Videocodierer 7000 kann eine H.264-Videocodiereinrichtung sein, die konfiguriert sein kann, Eingabevideo-Frames aus einem Eingabeformat in ein H.264/„Advanced Video Coding”(AVC)-Format, wie im Standard H.264/AVC beschrieben, umzuwandeln. Die Blockverarbeitungspipeline 7040 kann eines oder mehrere oder eine oder mehrere der Blockverarbeitungsverfahren und -einrichtung implementieren, wie hierin in Beziehung zu 3 bis 16 beschrieben.
  • Der CPU-Komplex 8020 kann einen oder mehrere CPU-Prozessoren 8024 einschließen, die als die CPU des SOC 8000 dienen. Die CPU des Systems schließt den einen oder die mehreren Prozessoren ein, welche die Hauptsteuersoftware des Systems, wie beispielsweise ein Betriebssystem, ausführen. Allgemein kann durch die CPU während der Verwendung ausgeführte Software die anderen Komponenten des Systems steuern, um die gewünschte Funktionalität des Systems zu verwirklichen. Die Prozessoren 8024 können auch andere Software ausführen, wie beispielsweise Anwendungsprogramme. Die Anwendungsprogramme können Benutzerfunktionalität bereitstellen und können zur Steuerung von Vorrichtungen niedriger Ebene auf dem Betriebssystem beruhen. Dementsprechend können die Prozessoren 8024 auch als Anwendungsprozessoren bezeichnet werden. Der CPU-Komplex 8020 kann ferner weitere Hardware, wie beispielsweise den L2-Cache 8022 und/oder eine Schnittstelle zu den anderen Komponenten des Systems (z. B. eine Schnittstelle zur Kommunikationsstruktur 8010), einschließen. Allgemein kann ein Prozessor jede beliebige Schaltlogik und oder jeden beliebigen Mikrocode einschließen, die oder der konfiguriert ist, Anweisungen auszuführen, die in einer durch den Prozessor implementierten Anweisungssatzarchitektur definiert sind. Die Anweisungen und Daten, an denen durch den Prozessor als Reaktion auf ein Ausführen der Anweisungen gearbeitet wird, können allgemein im Speicher 8800 gespeichert werden, obwohl bestimmte Anweisungen auch für einen direkten Prozessorzugriff auf Peripherieeinheiten definiert sein können. Prozessoren können Prozessorkerne, die auf einer integrierten Schaltung mit anderen Komponenten als ein System auf einem Chip (SOC 8000) implementiert sind, oder andere Ebenen der Integration umfassen. Prozessoren können ferner diskrete Mikroprozessoren, Prozessorkerne und/oder Mikroprozessoren, die in Mehrfachchipmodul-Implementierungen integriert sind, Prozessoren, die als mehrere integrierte Schaltungen implementiert sind, usw. umfassen.
  • Die Speichersteuereinheit 8030 kann allgemein die Schaltlogik zum Empfangen von Speicheroperationen von den anderen Komponenten des SOC 8000 und zum Zugreifen auf den Speicher 8800 einschließen, um die Speicheroperationen durchzuführen. Die Speichersteuereinheiten 8030 können konfiguriert sein, auf jeden beliebigen Typ von Speicher 8800 zuzugreifen. Zum Beispiel kann der Speicher 8800 ein statischer Speicher mit wahlfreiem Zugriff (SRAM), dynamischer RAM (DRAM), wie beispielsweise synchroner DRAM (SDRAM) einschließlich DRAM mit doppelter Datenübertragungsrate (DDR, DDR2, DDR3 usw.), sein. Versionen mit geringer Leistung/mobile Versionen des DDR DRAM können unterstützt werden (z. B. LPDDR, mDDR, usw.). Die Speichersteuereinheit 8030 kann Warteschlangen für Speicheroperationen, zum Ordnen (und potenziellen Umordnen) der Operationen und zum Vorlegen der Operationen für den Speicher 8800 einschließen. Die Speichersteuereinheit 8030 kann ferner Datenpuffer einschließen, um Schreibdaten, die auf das Schreiben in den Speicher warten, und Lesedaten, die auf die Ausgabe an die Quelle der Speicheroperation warten, zu speichern. In manchen Ausführungsformen kann die Speichersteuereinheit 8030 einen Speicher-Cache einschließen, um Speicherdaten zu speichern, auf die kürzlich zugegriffen wurde. In SOC-Implementierungen kann der Speicher-Cache zum Beispiel den Energieverbrauch im SOC verringern, indem ein erneuter Zugriff von Daten aus dem Speicher 8800 vermieden wird, wenn erwartet wird, dass bald erneut auf sie zugegriffen wird. In manchen Fällen kann der Speicher-Cache, im Gegensatz zu privaten Caches, wie beispielsweise dem L2-Cache 8022 oder Caches in den Prozessoren 8024, die nur bestimmten Komponenten dienen, auch als ein System-Cache bezeichnet werden. Zusätzlich muss in manchen Ausführungsformen ein System-Cache nicht innerhalb der Speichersteuereinheit 8030 angeordnet sein.
  • In einer Ausführungsform kann der Speicher 8800 mit dem SOC 8000 in einer Chip-auf-Chip- oder Packung-auf-Packung-Konfiguration gepackt sein. Eine Mehrfachchipmodul-Konfiguration des SOC 8000 und des Speichers 8800 kann ebenfalls verwendet werden. Solche Konfiguration können (hinsichtlich der Datenbeobachtbarkeit) relativ sicherer sein als Übertragungen an andere Komponenten im System (z. B. an die Endpunkte 16A bis 16B). Dementsprechend können sich geschützte Daten unverschlüsselt im Speicher 8800 befinden, wohingegen die geschützten Daten für einen Austausch zwischen dem SOC 8000 und externen Endpunkten verschlüsselt werden können.
  • Die Kommunikationsstruktur 8010 kann jede beliebige Kommunikationsverbindung und jedes beliebige Protokoll zum Kommunizieren zwischen den Komponenten des SOC 8000 sein. Die Kommunikationsstruktur 8010 kann busgestützt sein, einschließlich gemeinsam genutzte Buskonfigurationen, Crossbar-Konfigurationen und hierarchische Busse mit Brücken. Die Kommunikationsstruktur 8010 kann auch paketgestützt sein und kann hierarchisch mit Brücken, Crossbar, Punkt-zu-Punkt oder andere Verbindungen sein.
  • Es wird festgehalten, dass die Anzahl von Komponenten des SOC 8000 (und die Anzahl von Teilkomponenten für die in 18 gezeigten, wie beispielsweise innerhalb des CPU-Komplexes 8020) von Ausführungsform zu Ausführungsform variieren kann. Es kann mehr oder weniger von jeder Komponente/Teilkomponente geben als die in 18 gezeigte Anzahl.
  • Beispielsystem
  • 19 ist ein Blockdiagramm einer Ausführungsform eines Systems 9000. In der veranschaulichten Ausführungsform schließt das System 9000 mindestens eine Instanz des SOC 8000 ein, die mit einer oder mehreren externen Peripherieeinheiten 9020 und dem externen Speicher 8800 gekoppelt ist. Eine Energieverwaltungseinheit (power management unit (PMU)) 9010 wird bereitgestellt, die dem SOC 8000 die Versorgungsspannungen sowie dem Speicher 8800 und/oder den Peripherieeinheiten 9020 eine oder mehrere Versorgungsspannungen zuführt. In manchen Ausführungsformen kann mehr als eine Instanz des SOC 8000 eingeschlossen sein (und auch mehr als ein Speicher 8800 kann eingeschlossen sein).
  • Die Peripherieeinheiten 9020 können jede gewünschte Schaltlogik einschließen, abhängig vom Typ des Systems 9000. Zum Beispiel kann in einer Ausführungsform das System 9000 eine mobile Vorrichtung (z. B. ein persönlicher digitaler Assistent (PDA), ein Smartphone usw.) sein, und die Peripherieeinheiten 9020 können Vorrichtungen für verschiedene Typen von drahtloser Kommunikation einschließen, wie beispielsweise WiFi, Bluetooth, Mobilfunk, globales Positionsbestimmungssystem usw. Die Peripherieeinheiten 9020 können auch zusätzlichen Speicher aufweisen, einschließlich RAM-Speicher, Halbleiterspeicher (solid state storage) oder Plattenspeicher. Die Peripherieeinheiten 9020 können Benutzerschnittstellenvorrichtungen, wie beispielsweise einen Anzeigebildschirm, einschließlich Anzeigetouchscreens oder Anzeige-Multitouchscreens, Tastatur- oder anderen Eingabevorrichtungen, Mikrofone, Lautsprecher usw., einschließen. In anderen Ausführungsformen kann das System 9000 ein beliebiger Typ von Computersystem sein (z. B. Desktop-Personal-Computer, Laptop, Workstation, Nettop usw.).
  • Der externe Speicher 8800 kann jeden beliebigen Speichertyp einschließen. Zum Beispiel kann der externe Speicher 8800 ein SRAM, dynamischer RAM (DRAM), wie beispielsweise synchroner DRAM (SDRAM), SDRAM mit doppelter Datenübertragungsrate (DDR, DDR2, DDR3 usw.), RAMBUS DRAM, Versionen des DDR DRAM mit geringer Leistung (z. B. LPDDR, mDDR usw.) usw. sein. Der externe Speicher 8800 kann ein oder mehrere Speichermodule einschließen, auf denen die Speichervorrichtungen gemountet sind, wie beispielsweise „Single Inline Memory Modules” (SIMMs), „Dual Inline Memory Modules” (DIMMs) usw. Alternativ dazu kann der externe Speicher 8800 eine oder mehrere Speichervorrichtungen einschließen, die auf dem SOC 8000 in einer Chip-auf-Chip- oder Packung-auf-Packung-Implementierung gemountet sind.
  • Die hierin beschriebenen Verfahren können in Software, Hardware oder einer Kombination davon in verschiedenen Ausführungsformen implementiert werden. Zusätzlich kann die Reihenfolge der Blöcke der Verfahren geändert werden, und verschiedene Elemente können hinzugefügt, umgeordnet, kombiniert, weggelassen, modifiziert werden usw. Verschiedene Modifikationen und Änderungen können vorgenommen werden, wie dies für einen Fachmann, der sich dieser Offenbarung bedient, naheliegen würde. Die verschiedenen hierin beschriebenen Ausführungsformen sollen veranschaulichend und nicht einschränkend sein. Es sind zahlreiche Variationen, Modifikationen, Hinzufügungen und Verbesserungen möglich. Dementsprechend können für Komponenten, die hierin als einzelne Instanz beschrieben sind, mehrere Instanzen bereitgestellt werden. Grenzen zwischen verschiedenen Komponenten, Operationen und Datenspeicherungen sind in gewissem Maß willkürlich, und bestimmte Operationen sind im Kontext spezifischer veranschaulichender Konfigurationen veranschaulicht. Andere Zuordnungen von Funktionalitäten sind denkbar und können in den Umfang der folgenden Ansprüche fallen. Schließlich können Strukturen und Funktionalitäten, die in den Beispielkonfigurationen als diskrete Komponenten dargestellt werden, als eine kombinierte Struktur oder Komponente implementiert werden. Diese und andere Variationen, Modifikationen, Hinzufügungen und Verbesserungen können in den Umfang der Ausführungsformen fallen, wie er in den folgenden Ansprüchen definiert ist.

Claims (15)

  1. Einrichtung, aufweisend: eine Blockverarbeitungspipeline, die eine Mehrzahl von Stufen aufweist, wobei eine oder mehrere der Mehrzahl von Stufen der Blockverarbeitungspipeline jeweils eine Komponente einer Softwarepipeline und eine Komponente einer Hardwarepipeline aufweisen, wobei die Software- und die Hardwarepipeline konfiguriert sind, Blöcke von Pixeln aus einem Frame parallel zu verarbeiten; wobei die Softwarepipelinekomponente in jeder der einen oder mehreren Stufen konfiguriert ist, Konfigurationen zum Verarbeiten der Blöcke bei der Hardwarepipelinekomponente der Stufe gemäß erhaltenen Informationen für die Blöcke iterativ zu ermitteln; wobei die Hardwarepipelinekomponente in jeder der einen oder mehreren Stufen konfiguriert ist, die Blöcke gemäß den Konfigurationen zum Verarbeiten der Blöcke, die durch die Softwarepipelinekomponente in der Stufe ermittelt werden, iterativ zu verarbeiten; und wobei die Hardwarepipelinekomponente in jeder der einen oder mehreren Stufen einen aktuellen Block in der Stufe verarbeitet, während die Softwarepipelinekomponente in der Stufe eine Konfiguration für einen durch die Hardwarepipelinekomponente in der Stufe zu verarbeitenden kommenden Block ermittelt.
  2. Einrichtung nach Anspruch 1, wobei die Softwarepipelinekomponente in jeder der einen oder mehreren Stufen ferner konfiguriert ist, mindestens einen Abschnitt der Informationen für die Blöcke von einer vorgeschalteten Stufe der Blockverarbeitungspipeline zu empfangen.
  3. Einrichtung nach Anspruch 1 oder 2, wobei die Informationen für die Blöcke Informationen aus Blöcken einschließen, die zuvor durch die Hardwarepipelinekomponente in der Stufe verarbeitet wurden.
  4. Einrichtung nach einem der Ansprüche 1 bis 3, wobei mindestens eine der Softwarepipelinekomponenten ferner konfiguriert ist, die Informationen für die Blöcke an eine nachgeschaltete Stufe der Blockverarbeitungspipeline auszugeben.
  5. Einrichtung nach einem der Ansprüche 1 bis 4, wobei die Hardwarepipelinekomponente in jeder der einen oder mehreren Stufen ferner konfiguriert ist: die zu verarbeitenden Blöcke von einer vorherigen Stufe der Blockverarbeitungspipeline zu empfangen; und die verarbeiteten Blöcke an eine nächste Stufe der Blockverarbeitungspipeline oder an einen externen Speicher auszugeben.
  6. Einrichtung nach einem der Ansprüche 1 bis 5, wobei die Blockverarbeitungspipeline eine Anfangsstufe einschließt, die konfiguriert ist: Blöcke für eine Eingabe in die Hardwarepipeline zu puffern; Blockstatistiken für einen oder mehrere der gepufferten Blöcke zu berechnen; und die Blockstatistiken in eine Softwarepipelinekomponente in einer nachgeschalteten Stufe der Blockverarbeitungspipeline als Informationen für die Blöcke einzugeben.
  7. Einrichtung nach einem der Ansprüche 1 bis 6, wobei die Softwarepipelinekomponente in jeder Stufe konfiguriert ist, für jeden durch die Hardwarepipelinekomponente in der Stufe zu verarbeitenden Block: eine bestimmte Konfiguration zum Verarbeiten des Blocks bei der Hardwarepipelinekomponente in der Stufe gemäß erhaltenen Informationen für den Block zu ermitteln; die Konfiguration in einen Konfigurationsspeicher zu schreiben; und der Hardwarepipelinekomponente in der Stufe zu signalisieren, dass die Konfiguration im Konfigurationsspeicher bereit ist.
  8. Einrichtung nach Anspruch 7, wobei die Hardwarepipelinekomponente in der Stufe konfiguriert ist: das Signal von der Softwarepipelinekomponente in der Stufe zu erkennen; auf die Konfiguration aus dem Konfigurationsspeicher zuzugreifen; der Softwarepipelinekomponente zu signalisieren, dass der Konfigurationsspeicher klar ist; und den Block gemäß der Konfiguration aus dem Konfigurationsspeicher zu verarbeiten.
  9. Einrichtung nach Anspruch 8, wobei die Softwarepipelinekomponente in der Stufe ferner konfiguriert ist, eine Konfiguration für einen nächsten Block in einem ersten Teil des Konfigurationsspeichers zu schreiben, während die Hardwarepipelinekomponente auf eine Konfiguration für einen aktuellen Block aus einem zweiten Teil des Konfigurationsspeichers zugreift.
  10. Verfahren, umfassend: Erhalten von Informationen für einen durch eine Hardwarepipelinekomponente in einer Stufe einer Blockverarbeitungspipeline zu verarbeitenden Block durch eine Softwarepipelinekomponente in der Stufe, wobei die Blockverarbeitungspipeline Blöcke von Pixeln aus einem Frame in parallelen Software- und Hardwarepipelines verarbeitet, wobei eine oder mehrere einer Mehrzahl von Stufen der Blockverarbeitungspipeline jeweils eine Softwarepipelinekomponente und eine Hardwarepipelinekomponente aufweisen; Ermitteln einer Konfiguration zum Verarbeiten des Blocks bei der Hardwarepipelinekomponente gemäß erhaltenen Informationen für den Block durch die Softwarepipelinekomponente; Signalisieren der Hardwarepipelinekomponente, dass die Konfiguration für den Block bereit ist; und als Reaktion auf das Signalisieren, Verarbeiten des Blocks bei der Hardwarepipelinekomponente gemäß der ermittelten Konfiguration für den Block; wobei die Hardwarepipelinekomponente den Block verarbeitet, während die Softwarepipelinekomponente eine Konfiguration für einen durch die Hardwarepipelinekomponente zu verarbeitenden kommenden Block ermittelt.
  11. Verfahren nach Anspruch 10, wobei die Informationen für den Block aus einer vorgeschalteten Stufe der Blockverarbeitungspipeline empfangene Blockinformationen und Informationen aus einem anderen Block einschließen, der zuvor durch die Hardwarepipelinekomponente in der Stufe verarbeitet wurde.
  12. Verfahren nach Anspruch 10 oder 11, ferner umfassend: Schreiben der Konfiguration für den Block in einen Konfigurationsspeicher durch die Softwarepipelinekomponente; und als Reaktion auf das Signalisieren, Lesen der Konfiguration für den Block aus dem Konfigurationsspeicher durch die Hardwarepipelinekomponente.
  13. Vorrichtung, umfassend: einen Speicher; und eine Einrichtung, die konfiguriert ist, Video-Frames zu verarbeiten und die verarbeiteten Video-Frames als Frame-Daten im Speicher zu speichern, wobei die Einrichtung eine Blockverarbeitungspipeline umfasst, die eine Mehrzahl von Stufen implementiert, die jeweils eine oder mehrere Pipelineeinheiten umfassen, wobei jede Pipelineeinheit konfiguriert ist, eine oder mehrere Operationen an einem Block von Pixeln aus einem durch die Pipeline laufenden Frame durchzuführen; wobei eine oder mehrere der Pipelineeinheiten in der Blockverarbeitungspipeline konfiguriert sind: einen aktuellen Block bei einem Einheitskern der Pipelineeinheit gemäß einer aktuellen Konfiguration zu verarbeiten; eine Konfiguration zum Verarbeiten eines nächsten Blocks bei dem Einheitskern gemäß erhaltenen Informationen für den nächsten Block zu ermitteln; dem Einheitskern zu signalisieren, dass die Konfiguration zum Verarbeiten des nächsten Blocks bereit ist; und als Reaktion auf das Signal den nächsten Block bei dem Einheitskern gemäß der Konfiguration für den nächsten Block zu verarbeiten; wobei die Pipelineeinheit die Konfiguration zum Verarbeiten des nächsten Blocks beim Einheitskern ermittelt, während der Einheitskern der Pipelineeinheit den aktuellen Block verarbeitet.
  14. Vorrichtung nach Anspruch 13, wobei die Informationen für den nächsten Block aus einer vorgeschalteten Verarbeitungseinheit der Blockverarbeitungspipeline empfangene Informationen und Informationen aus einem Block einschließen, der zuvor durch die Verarbeitungseinheit verarbeitet wurde.
  15. Vorrichtung nach Anspruch 13 oder 14, wobei jede der einen oder mehreren Pipelineeinheiten ferner konfiguriert ist, die Konfiguration zum Verarbeiten des nächsten Blocks bei dem Einheitskern in einem Konfigurationsspeicher zu speichern, wobei der Einheitskern konfiguriert ist: als Reaktion auf das Signal die Konfiguration aus dem Konfigurationsspeicher zu lesen; und der Pipelineeinheit zu signalisieren, dass der Konfigurationsspeicher klar ist.
DE112014004432.6T 2013-09-27 2014-08-20 Parallele Hardware- und Software-Blockverarbeitungspipelines Pending DE112014004432T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/039,729 2013-09-27
US14/039,729 US9215472B2 (en) 2013-09-27 2013-09-27 Parallel hardware and software block processing pipelines
PCT/US2014/051799 WO2015047601A1 (en) 2013-09-27 2014-08-20 Parallel hardware and software block processing pipelines

Publications (1)

Publication Number Publication Date
DE112014004432T5 true DE112014004432T5 (de) 2016-06-16

Family

ID=51539325

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112014004432.6T Pending DE112014004432T5 (de) 2013-09-27 2014-08-20 Parallele Hardware- und Software-Blockverarbeitungspipelines

Country Status (7)

Country Link
US (1) US9215472B2 (de)
JP (1) JP6225250B2 (de)
KR (1) KR101834901B1 (de)
CN (1) CN105684036B (de)
DE (1) DE112014004432T5 (de)
TW (1) TWI533209B (de)
WO (1) WO2015047601A1 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10313683B2 (en) * 2014-08-30 2019-06-04 Apple Inc. Video encoder with context switching
US9626286B2 (en) * 2014-10-03 2017-04-18 Sandisk Technologies Llc Hardware and firmware paths for performing memory read processes
US10218983B2 (en) 2015-09-30 2019-02-26 Apple Inc. Adapting mode decisions in video encoder
US20170164041A1 (en) * 2015-12-07 2017-06-08 Le Holdings (Beijing) Co., Ltd. Method and electronic device for playing videos
US10728546B2 (en) 2016-02-05 2020-07-28 Apple Inc. Sample adaptive offset systems and methods
US10460642B2 (en) 2016-06-30 2019-10-29 Apple Inc. Noise reduction in LED sensing circuit for electronic display
US20180122038A1 (en) * 2016-10-28 2018-05-03 Qualcomm Incorporated Multi-layer fetch during composition
KR20180080463A (ko) 2017-01-04 2018-07-12 삼성전자주식회사 반도체 장치 및 반도체 장치의 동작 방법
CN107483948A (zh) * 2017-09-18 2017-12-15 郑州云海信息技术有限公司 一种webp压缩处理中像素宏块处理方法
DE112019003203T5 (de) * 2018-06-28 2021-05-27 Apple Inc. Ratensteuerung für videocodierung und -übertragung mit niedriger latenz
CN112335244B (zh) 2018-06-28 2022-12-23 苹果公司 基于优先级的视频编码和传输
US11653026B2 (en) 2018-06-28 2023-05-16 Apple Inc. Video encoding system
US10812823B2 (en) 2018-07-11 2020-10-20 Apple Inc. Global motion vector video encoding systems and methods
CN113965534B (zh) * 2020-06-29 2024-09-10 阿里巴巴集团控股有限公司 多通道数据的处理方法、装置、设备和存储介质
US11330296B2 (en) 2020-09-14 2022-05-10 Apple Inc. Systems and methods for encoding image data
US11206415B1 (en) 2020-09-14 2021-12-21 Apple Inc. Selectable transcode engine systems and methods
US11778211B2 (en) 2021-09-16 2023-10-03 Apple Inc. Parallel video parsing for video decoder processing
US12075074B2 (en) 2021-09-24 2024-08-27 Apple Inc. Systems and methods for multi-core image encoding

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6005624A (en) 1996-12-20 1999-12-21 Lsi Logic Corporation System and method for performing motion compensation using a skewed tile storage format for improved efficiency
JP3007612B2 (ja) * 1997-09-01 2000-02-07 松下電器産業株式会社 マイクロコントローラ、データ処理システム及びタスクスイッチの制御方法
US8284844B2 (en) 2002-04-01 2012-10-09 Broadcom Corporation Video decoding system supporting multiple standards
KR100846778B1 (ko) 2002-07-16 2008-07-16 삼성전자주식회사 복수개의 주사 패턴을 이용한 부호화 방법, 복호화 방법,및 그 장치
GB0323284D0 (en) 2003-10-04 2003-11-05 Koninkl Philips Electronics Nv Method and apparatus for processing image data
KR20050078099A (ko) 2004-01-30 2005-08-04 삼성전자주식회사 적응적으로 키 프레임을 삽입하는 비디오 코딩 장치 및 방법
US7558428B2 (en) * 2004-09-13 2009-07-07 Microsoft Corporation Accelerated video encoding using a graphics processing unit
US7822116B2 (en) 2005-04-14 2010-10-26 Broadcom Corporation Method and system for rate estimation in a video encoder
US8537111B2 (en) 2006-02-08 2013-09-17 Oblong Industries, Inc. Control system for navigating a principal dimension of a data space
US7929599B2 (en) * 2006-02-24 2011-04-19 Microsoft Corporation Accelerated video encoding
US7768520B2 (en) 2006-05-03 2010-08-03 Ittiam Systems (P) Ltd. Hierarchical tiling of data for efficient data access in high performance video applications
US7725745B2 (en) * 2006-12-19 2010-05-25 Intel Corporation Power aware software pipelining for hardware accelerators
US20080170611A1 (en) * 2007-01-17 2008-07-17 Srikrishna Ramaswamy Configurable functional multi-processing architecture for video processing
US8213511B2 (en) 2007-04-30 2012-07-03 Texas Instruments Incorporated Video encoder software architecture for VLIW cores incorporating inter prediction and intra prediction
JP2009134391A (ja) * 2007-11-29 2009-06-18 Renesas Technology Corp ストリーム処理装置、ストリーム処理方法及びデータ処理システム
US8754895B2 (en) * 2008-09-09 2014-06-17 Sony Corporation Pipelined image processing engine
US8320448B2 (en) 2008-11-28 2012-11-27 Microsoft Corporation Encoder with multiple re-entry and exit points
US9179166B2 (en) 2008-12-05 2015-11-03 Nvidia Corporation Multi-protocol deblock engine core system and method
US20120076207A1 (en) 2008-12-31 2012-03-29 Advanced Micro Devices, Inc. Multiple-candidate motion estimation with advanced spatial filtering of differential motion vectors
CN102687510B (zh) 2009-07-06 2014-11-05 松下电器产业株式会社 图像解码装置、图像编码装置、图像解码方法、图像编码方法及集成电路
US8379718B2 (en) 2009-09-02 2013-02-19 Sony Computer Entertainment Inc. Parallel digital picture encoding
US8488673B2 (en) 2009-09-09 2013-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Latency rate distortion optimisation
US9190012B2 (en) * 2009-12-23 2015-11-17 Ati Technologies Ulc Method and system for improving display underflow using variable HBLANK
US8879619B2 (en) 2010-07-15 2014-11-04 Sharp Laboratories Of America, Inc. Method of parallel video coding based on scan order
US8532397B1 (en) 2010-09-16 2013-09-10 Pixia Corp. Method of creating a container file for large format imagery and organizing data within the container file
US9288496B2 (en) 2010-12-03 2016-03-15 Qualcomm Incorporated Video coding using function-based scan order for transform coefficients
US9288500B2 (en) 2011-05-12 2016-03-15 Texas Instruments Incorporated Luma-based chroma intra-prediction for video coding
US20130003837A1 (en) 2011-06-29 2013-01-03 General Instrument Corporation Methods and system for using a scan coding pattern during intra coding
US9749661B2 (en) 2012-01-18 2017-08-29 Qualcomm Incorporated Sub-streams for wavefront parallel processing in video coding
CN104380730B (zh) 2012-01-19 2017-12-22 华为技术有限公司 模式依赖帧内平滑的简化
KR102210228B1 (ko) 2012-01-20 2021-02-01 지이 비디오 컴프레션, 엘엘씨 병렬 처리, 전송 디멀티플렉서 및 비디오 비트스트림을 허용하는 코딩 개념
US9179144B2 (en) * 2012-11-28 2015-11-03 Cisco Technology, Inc. Fast switching hybrid video decoder
US10349069B2 (en) * 2012-12-11 2019-07-09 Sony Interactive Entertainment Inc. Software hardware hybrid video encoder

Also Published As

Publication number Publication date
TW201528135A (zh) 2015-07-16
US20150092854A1 (en) 2015-04-02
CN105684036A (zh) 2016-06-15
JP2016537845A (ja) 2016-12-01
JP6225250B2 (ja) 2017-11-01
TWI533209B (zh) 2016-05-11
KR20160065900A (ko) 2016-06-09
CN105684036B (zh) 2019-01-22
US9215472B2 (en) 2015-12-15
KR101834901B1 (ko) 2018-03-08
WO2015047601A1 (en) 2015-04-02

Similar Documents

Publication Publication Date Title
DE112014004432T5 (de) Parallele Hardware- und Software-Blockverarbeitungspipelines
US9843813B2 (en) Delayed chroma processing in block processing pipelines
US20160021385A1 (en) Motion estimation in block processing pipelines
US9380312B2 (en) Encoding blocks in video frames containing text using histograms of gradients
US9292899B2 (en) Reference frame data prefetching in block processing pipelines
US9473778B2 (en) Skip thresholding in pipelined video encoders
US9106888B2 (en) Reducing quantization artifacts using neighbor-based weighted dithering
TWI586149B (zh) 用於在區塊處理管線中處理視訊圖框之視訊編碼器、方法及計算器件
US9571846B2 (en) Data storage and access in block processing pipelines
US9299122B2 (en) Neighbor context processing in block processing pipelines
US9224186B2 (en) Memory latency tolerance in block processing pipelines
US9948934B2 (en) Estimating rate costs in video encoding operations using entropy encoding statistics
US9392292B2 (en) Parallel encoding of bypass binary symbols in CABAC encoder
US9218639B2 (en) Processing order in block processing pipelines
US9305325B2 (en) Neighbor context caching in block processing pipelines
DE102020125206A1 (de) Verfahren und system zur mehrkanalvideocodierung mit frameratenänderung und kanalübergreifender referenzierung
DE102016200001A1 (de) Verfahren, Systeme und Einrichtungen mit einem Kodierer für Bildverarbeitung
TWI583180B (zh) 具有上下文切換之視訊編碼器
CN101459839A (zh) 去块效应滤波方法及实现该方法的装置
Kim et al. Merge mode estimation for a hardware-based HEVC encoder
DE102011002325A1 (de) Einrichtung mit vertikalem und/oder horizontalem Cachespeicher und in einem Kodierer und/oder Dekodierer verwendete Verfahren
WO2023123358A1 (zh) 编解码方法、码流、编码器、解码器以及存储介质

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication