DE102010030973B4

DE102010030973B4 - Videocodierer und Verfahren zum Decodieren einer Sequenz von Bildern

Info

Publication number: DE102010030973B4
Application number: DE102010030973A
Authority: DE
Inventors: Volker Bruns; Heiko Sparenberg; Siegfried Fössel
Original assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Current assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date: 2010-07-06
Filing date: 2010-07-06
Publication date: 2012-02-02
Anticipated expiration: 2030-07-07
Also published as: US20130121421A1; EP2591599B1; WO2012004164A1; DE102010030973A1; EP2591599A1

Abstract

Ein Videodecodierer zum Decodieren einer Sequenz von Bildern, von denen jedes in eine Mehrzahl von Transformationskoeffizientenblöcken codiert ist, ist ausgebildet, um Transformationskoeffizientenblöcke verschiedener Bilder zeitgleich auf verschiedenen Rechenkernen einer ersten SIMD-Gruppe zu decodieren.

Description

Ausführungsbeispiele der vorliegenden Erfindung beschreiben einen Videodecodierer und ein Verfahren zum Decodieren einer Sequenz von Bildern, beispielsweise eines Videos. Ausführungsbeispiele der vorliegenden Erfindung können beispielsweise zur Decodierung von Bildsequenzen gemäß dem JPEG2000-Standard verwendet werden.
JPEG2000 ist ein modernes Bildkompressionsverfahren, welches in verschiedenen Anwendungsgebieten, wie z. B. im digitalen Kino, in digitalen Filmarchiven oder in der Medizintechnik zum Einsatz kommt. Besonders bei hohen Bitraten liefert es bessere Bildqualität als vergleichbare Kompressionsverfahren. Allerdings sind die Berechnungen für das Erstellen und Interpretieren eines JPEG2000-Bildes enorm hoch, so dass aktuelle PCs dies nur unter besonderen Bedingungen in Echtzeit schaffen. Echtzeitfähigkeit ist allerdings bei vielen Anwendungen eine Grundvoraussetzung.
In einem JPEG2000-Datenstrom sind Bilder typischerweise in eine Mehrzahl von Transformationskoeffizientenblöcken codiert. Diese Transformationskoeffizientenblöcke sind typischerweise aus einer diskreten Wavelet-Transformation mit einer anschließenden skalaren Quantisierung der Wavelet-Koeffizienten in einem JPEG2000-Encodierer entstanden. Ein Transformationskoeffizientenblock (welcher allgemeiner auch als Codeblock bezeichnet werden kann) kann dabei jeweils genau einem bei der diskreten Wavelet-Transformation entstanden Frequenzband zugeordnet werden. In einem JPEG2000-Decodierer werden diese Transformationskoeffizientenblöcke typischerweise unter Nutzung des EBCOT-(embedded block coding with optimized truncation – eingebettete Blockcodierung mit optimierter Approximation) Algorithmus entropiedecodiert. Der EBCOT-Algorithmus ist ein kontextadaptiver, binärer, arithmetischer Entropiecodierungsalgorithmus. Die entropiedecodierten Daten werden dann typischerweise dequantisiert und es wird eine inverse Wavelet-Transformation (beispielsweise eine inverse diskrete Wavelet-Transformation) durchgeführt. Bei Farbbildern kann zusätzlich eine inverse Farbtransformation durchgeführt werden, um die in dem JPEG2000-Datenstrom codierten Bilder decodiert zu erhalten und diese beispielsweise zur Ausgabe auf einem Display zur Verfügung zu stellen.
Der rechenintensivste Schritt ist hierbei die oben beschriebene EBCOT-Entropiedecodierung. Es ist daher wünschenswert, die EBCOT-Decodierung zu beschleunigen und/oder zu vereinfachen, um eine Echtzeitwiedergabe JPEG2000-komprimierter Bildsequenzen zu ermöglichen. Eine Möglichkeit zur Echtzeitwiedergabe von JPEG2000-komprimierten Bildsequenzen besteht darin, integrierte Schaltungen einzusetzen.
Allerdings handelt es sich dabei um kostenintensive Hardware, die lediglich im professionellen Rahmen Anwendung findet.
Nicht oder nur beschränkt echtzeitfähig sind existierende Software-Dekoder. Hierzu gibt es eine Vielzahl an kommerziellen und freien JPEG2000-Implementierungen, die in ihrer Grundversion keine Echtzeit erreichen.
Weiterhin kann das Problem dadurch umgangen werden, dass in den Arbeitsschritten, bei denen Echtzeitfähigkeit notwendig ist, auf das JPEG2000-Format verzichtet wird. Hierzu werden zunächst alle Bilder in ein anderes, schneller zu dekodierendes, Format konvertiert. Erst dann werden die kritischen Arbeitsschritte ausgeführt. Schließlich werden die Bildsequenzen wieder nach JPEG2000 konvertiert. Hierbei kommt es durch das Komprimieren und Dekomprimieren zu unnötiger Ressourcenverschwendung.
Weiterhin bietet das JPEG2000-Format die Möglichkeit der Skalierung. Hierdurch ist es möglich, bestimmte Teile des Datenstroms nicht zu dekodieren um dadurch die Geschwindigkeit zu erhöhen. Der Anwender kann entscheiden, welche Teile der Daten er nicht komplett dekodieren möchte. Als Resultat liefert der Dekoder ein Bild, welches beispielsweise in Qualität oder Bildgröße reduziert ist. Allerdings ist diese Skalierung insbesondere in der Kinotechnik nicht erwünscht.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Konzept zu schaffen, welches eine verbesserte Decodierung von Bildsequenzen ermöglicht.
Diese Aufgabe wird gelöst durch einen Videodecodierer gemäß Anspruch 1, ein Verfahren gemäß Anspruch 14 und ein Computerprogramm gemäß Anspruch 15.
Ausführungsbeispiele der vorliegenden Erfindung schaffen einen Videodecodierer zum Decodieren einer Sequenz von Bildern, von denen jedes in eine Mehrzahl von Transformationskoeffizientenblöcken codiert ist, wobei der Videodecodierer ausgebildet ist, um Transformationskoeffizientenblöcke verschiedener Bilder zeitgleich auf verschiedenen Rechenkernen einer ersten SIMD-Gruppe zu decodieren.
Es ist ein Kerngedanke der vorliegenden Erfindung, dass eine verbesserte Decodierung von Transformationskoeffizientenblöcken einer Sequenz von Bildern (wie beispielsweise einer Videosequenz) geschaffen werden kann, wenn die Videodecodierung verschiedener Transformationskoeffizientenblöcke verschiedener Bilder zeitgleich auf verschiedenen Rechenkernen einer ersten SIMD-Gruppe ausgeführt wird. Durch die parallele Durchführung der Decodierung der Transformationskoeffizienten kann, insbesondere im Vergleich zu Systemen, in welchen eine streng sequentielle Durchführung der Decodierung erfolgt, ein immenser Geschwindigkeitsvorteil erzielt werden. Es wurde erkannt, dass bei der Decodierung von Transformationskoeffizientenblöcken verschiedener Bilder (insbesondere bei JPEG2000-codierten Bildern) die durchzuführenden Schritte in dem Decodierprozess ähnlich oder gleich sind. Dies ermöglicht eine parallele Decodierung der Transformationskoeffizienten auf Rechenkernen einer SIMD-Gruppe.
Figurenkurzbeschreibung
Ausführungsbeispiele der vorliegenden Erfindung werden im Folgenden anhand der beiliegenden Figuren näher erläutert. Es zeigen:
1a ein Blockdiagramm eines Videodecodierers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
1b eine schematische Darstellung einer Zuordnung von Transformationskoeffizientenblöcken auf Rechenkerne, wie sie von dem Videodecodierer gemäß 1a durchgeführt werden kann;
2a eine weitere Zuordnung von Transformationskoeffizientenblöcken auf Rechenkerne, wie sie von dem Videodecodierer aus 1a durchgeführt werden kann;
2b eine weitere Zuordnung von Transformationskoeffizientenblöcken auf Rechenkerne, wie sie von dem Videodecodierer aus 1a durchgeführt werden kann;
3 ein Ablaufdiagramm zur Decodierung von JPEG2000-Datenströmen, wie es bei dem Videodecodierer gemäß 1a verwendet werden kann;
4 eine schematische Darstellung von Kernel-Funktionen aus dem Ablaufdiagramm aus 3, welche auf einem Stream-Prozessor ausgeführt werden können;
5 ein Struktogramm zur Bestimmung zu verwerfender Codeblöcke;
6 eine weitere Zuordnung von Transformationskoeffizientenblöcken auf Rechenkerne, wie sie von dem Videodecodierer aus 1a durchgeführt werden kann
7 eine schematische Darstellung eines beispielhaften Transformationskoeffizientenblocks und dessen Zerlegung in einzelne Bitebenen;
8 ein Sequenzdiagramm zur Decodierung des Transformationskoeffizientenblocks aus 7;
9 ein Ablaufschema eines Codierdurchlaufs bei der Decodierung eines Transformationskoeffizientenblocks; und
10 ein Flussdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
Detaillierte Beschreibung von Ausführungsbeispielen
Bevor im Folgenden Ausführungsbeispiele der vorliegenden Erfindung anhand der beiliegenden Figuren beschrieben werden, wird darauf hingewiesen, dass in den Figuren gleiche Elemente oder Elemente gleicher Funktion dieselben Bezugszeichen erhalten und dass auf eine wiederholte Beschreibung dieser Elemente verzichtet wird. Eine Beschreibung von Elementen, welche mit gleichen Bezugszeichen versehen sind, ist daher untereinander austauschbar bzw. aufeinander anwendbar.
1a zeigt einen Videodecodierer 100 zum Decodieren einer Sequenz von Bildern, von denen jedes in eine Mehrzahl von Transformationskoeffizientenblöcken codiert ist, wobei der Videodecodierer 100 ausgebildet ist, um Transformationskoeffizientenblöcke verschiedener Bilder zeitgleich auf verschiedenen Rechenkernen einer ersten SIMD-Gruppe zu decodieren. Der Videodecodierer 100 kann beispielsweise einen Datenstrom 101 (beispielsweise einen JPEG2000-Datenstrom) an einem Eingang empfangen, um Transformationskoeffizientenblöcke der in den Datenstrom 101 codierten Bilder zu decodieren, um diese als eine Sequenz von decodierten Transformationskoeffizientenblöcken 102 an einem Ausgang zur Verfügung zu stellen.
Eine SIMD-(single instruction multiple data – eine Anweisung, mehrere Daten) Gruppe zeichnet sich dadurch aus, dass sie mehrere Rechenkerne aufweist, wobei alle Rechenkerne der SIMD-Gruppe zeitgleich die gleiche Anweisung auf verschiedene Daten ausführen. Derartige SIMD-Gruppen finden sich beispielsweise auf sogenannten Stream-Prozessoren, welche beispielsweise in Grafikkarten verwendet werden. Dabei weist ein solcher Stream-Prozessor typischerweise eine Mehrzahl von SIMD-Gruppen auf, welche jeweils eine Mehrzahl von Rechenkernen und ein Instruktionsregister aufweisen. Jede der SIMD-Gruppen kann dabei eine eigene Instruktion auf ihren Rechenkernen, unabhängig von Instruktionen weiterer SIMD-Gruppen desselben Stream-Prozessors, bearbeiten.
Gemäß einigen Ausführungsbeispielen kann der Videodecodierer 100 ausgebildet sein, um die Transformationskoeffizientenblöcke unter Nutzung eines EBCOT Tier 1 Entropiedecodierungsalgorithmus, welcher im Folgenden anhand eines beispielhaften JPEG2000 Decodierer noch beschrieben wird, zu dekodieren.
Gemäß weiteren Ausführungsbeispielen kann der Videodecodierer eine Wavelet-Syntheseeinheit 110 aufweisen, die ausgebildet ist, um die Transformationskoeffizientenblöcke einer Wavelet-Synthese pro Bild zu unterziehen. Die Transformationskoeffizientenblöcke können beispielsweise aus einer Wavelet-Analyse in einem Video-Encodierer hervorgegangen sein und jeder Transformationskoeffizientenblock kann genau einem bei der Wavelet-Analyse entstandenen Frequenzband zugeordnet sein.
Im Folgenden kann ein Transformationskoeffizientenblock auch allgemeiner als Codeblock bezeichnet werden.
Im Folgenden kann eine SIMD-Gruppe auch als SIMD-Vektor bezeichnet werden.
1b zeigt eine Zuordnung von ersten Transformationskoeffizientenblöcken 103a–103d zu Rechenkernen 104a–104d einer ersten SIMD-Gruppe 105, wie dies beispielsweise in dem Videodecodierer 100 aus 1a erfolgen kann. Aus 1b wird ersichtlich, dass erste Transformationskoeffizientenblöcke 103a–103d verschiedener Bilder 106a–106d auf verschiedenen Rechenkernen 104a–104d derselben ersten SIMD-Gruppe 105 decodiert werden. So wird beispielsweise ein erster Transformationskoeffizientenblock 103a eines ersten Bildes 106a auf einem ersten Rechenkern 104a der ersten SIMD-Gruppe 105 decodiert und ein erster Transformationskoeffizientenblock 103b eines zweiten Bildes 106b auf einem zweiten Rechenkern 104b der ersten SIMD-Gruppe 105 decodiert usw. Da die Rechenkerne 104a–104d der ersten SIMD-Gruppe 105 parallel arbeiten, d. h. sie führen die gleichen Instruktionen auf verschiedene Daten aus (wie dies bereits im Vorhergehenden beschrieben wurde), kann gegenüber einer rein sequentiellen Abarbeitung der Transformationskoeffizientenblöcke 103a–103d eine, um einen Faktor der Anzahl der Rechenkerne der ersten SIMD-Gruppe 105 (und der damit parallel decodierbaren Transformationskoeffizientenblöke), niedrigere Decodierzeit erzielt werden.
Die Bilder 106a–106d, welche zu einer ersten Gruppe von Bildern 107 zusammengefasst werden können, können beispielsweise in der Sequenz von Bildern, welche der Videodecodierer 100 decodiert, aufeinander folgen. Eine Gruppe von Bildern wird im Fachjargon auch als GOP (group of pictures) bezeichnet. SIMD-Gruppen (auch bezeichnet als SIMD-Vektoren) in Stream-Prozessoren sind typischerweise so aufgebaut, dass sobald eine zu bearbeitende Funktion in einem Rechenkern einer SIMD-Gruppe von einer zu bearbeitenden Funktion in einem anderen Rechenkern der SIMD-Gruppe zu dem gleichen Zeitpunkt abweicht (beispielsweise aufgrund unterschiedlicher Eingangsdaten in einer wenn-dann-Abfrage), eine Abarbeitung dieser beiden Funktionen rein sequentiell in den jeweiligen Rechenkernen der SIMD-Gruppe ausgeführt wird. Eine Verwendung von aufeinanderfolgenden Bildern 106a–106d in einer Gruppe von Bildern 107, deren erste Transformationskoeffizientenblöcke 103a–103d von derselben ersten SIMD-Gruppe 105 bearbeitet werden, kann daher bei der parallelen Berechnung in den Rechenkernen 104a–104d der ersten SIMD-Gruppe 105 Vorteile aufgrund von Ähnlichkeiten zwischen den aufeinanderfolgenden Bildern 106a–106d, insbesondere gegenüber einer rein zufälligen Wahl der Bilder, bieten.
Aufeinanderfolgende Bilder 106a–106d weisen dabei Ähnlichkeiten insbesondere an selben oder Ähnlichen Positionen innerhalb der aufeinanderfolgenden Bilder 106a–106d auf. Positionen der ersten Transformationskoeffizientenblöcke 103a–103d der (aufeinanderfolgenden) Bilder 106a–106d, welche auf den Rechenkernen 104a–104d der gemeinsamen ersten SIMD-Gruppe 105 dekodiert werden, können sich gemäß einigen Ausführungsbeispielen der vorliegenden Erfindung räumlich überlappen. Ferner können die ersten Transformationskoeffizientenblöcke 103a–103d in ihren Positionen in den jeweiligen Bildern 106a–106d identisch sein. Dadurch kann eine maximal mögliche Ähnlichkeit der ersten Transformationskoeffizientenblöcke 103a–103d erreicht werden. In den Rechenkernen 104a–104d, in welchen die ersten Transformationskoeffizientenblöcke 103a–103d decodiert werden, lässt sich damit innerhalb der ersten SIMD-Gruppe 105 eine maximale Parallelität erreichen und damit eine Berechnungszeit für die Decodierung der ersten Transformationskoeffizientenblöcke 103a–103d minimieren.
Dies hat insbesondere gegenüber einer Verteilung von Transformationskoeffizientenblöcken ein und desselben Bildes auf Rechenkerne ein und derselben SIMD-Gruppe einen Vorteil, da sich typischerweise Transformationskoeffizientenblöcke verschiedener Positionen innerhalb eines Bildes mehr voneinander unterscheiden, als Transformationskoeffizientenblöcke gleicher Position in aufeinanderfolgenden Bildern. Transformationskoeffizientenblöcke innerhalb eines Bildes können beispielsweise keinerlei Ähnlichkeit aufweisen, beispielsweise wenn zwischen zwei Transformationskoeffizientenblöcken eines Bildes eine Objektgrenze ist.
Eine Decodierung weiterer Transformationskoeffizientenblöcke der Bilder 106a–106d, beispielsweise zweiter Transformationskoeffizientenblöcke 108a–108d, kann dann beispielsweise zeitlich nach der Decodierung der ersten Transformationskoeffizientenblöcke 103a–103d auf den Rechenkernen 104a–104d der ersten SIMD-Gruppe 105 erfolgen, oder gemäß einem weiteren Ausführungsbeispiel, zeitgleich zu der Decodierung der ersten Transformationskoeffizientenblöcke 103a–103d, auf Rechenkernen einer weiteren SIMD-Gruppe ausgeführt werden.
Gemäß einigen Ausführungsbeispielen der vorliegenden Erfindung ist jeder Transformationskoeffizientenblock 103a–103d, 108a–108d eines Bildes 106a–106d genau einem Frequenzband der Wavelet-Synthese zugeordnet, und der Videodecodierer 100 kann dabei so ausgebildet sein, dass Transformationskoeffizientenblöcke verschiedener Bilder, welche zeitgleich auf den verschiedenen Kernen einer SIMD-Gruppe decodiert werden, demselben Frequenzband zugeordnet sind. Die kann beispielsweise den Vorteil bergen, dass in JPEG2000 die Transformationskoeffizientenblöcke eines Frequenzbandes gleich genau quantisiert werden und somit mit der selben Anzahl von Bitebenen dargestellt werden.
Obwohl in dem in 1b dargestellten Ausführungsbeispiel die erste SIMD-Gruppe 105 lediglich vier Rechenkerne 104a–104d umfasst, so kann gemäß weiteren Ausführungsbeispielen eine SIMD-Gruppe auch eine beliebige Mehrzahl von Rechenkernen umfassen. SIMD-Gruppen von Stream-Prozessoren weisen dabei typischerweise acht oder sechzehn Rechenkerne auf. Eine Anzahl der Rechenkerne pro SIMD-Gruppe kann damit damit auch die Anzahl von Bildern in einer Gruppe von Bildern, deren Transformationsblöcke zeitgleich auf Rechenkernen einer SIMD-Gruppe decodiert werden, bestimmen. Weist eine SIMD-Gruppe beispielsweise acht Rechenkerne auf, so können zeitgleich acht Transformationskoeffizientenblöcke von acht verschiedenen Bildern auf den acht Rechenkernen dieser SIMD-Gruppe decodiert werden Wie bereits im Vorhergehenden beschrieben, kann ein Stream-Prozessor eine Mehrzahl von SIMD-Gruppen aufweisen, welche parallel zueinander arbeiten. Damit ist es beispielsweise möglich, alle Transformationskoeffizientenblöcke mehrerer Bilder parallel zu berechnen, wobei beispielsweise Transformationskoeffizientenblöcke verschiedener Bilder aber überlappender Positionen auf Rechenkernen jeweils derselben SIMD-Gruppe decodiert werden.
Als einfaches Beispiel wird angenommen, dass ein Stream-Prozessor sechzehn SIMD-Gruppen aufweist, wobei jede der SIMD-Gruppen vier Rechenkerne aufweist. In diesem Fall können beispielsweise sechzehn Transformationskoeffizientenblöcke von vier Bildern zeitgleich decodiert werden. Angenommen, jedes Bild weist lediglich sechzehn Transformationskoeffizientenblöcke auf so können diese alle zeitgleich decodiert werden.
Eine Voraussetzung für die zeitgleiche Decodierung dieser Transformationskoeffizientenblöcke eines Bildes ist natürlich, dass die Transformationskoeffizientenblöcke unabhängig voneinander, d. h. nicht prädiktiv, codiert sind. Angenommen, der Stream-Prozessor weist statt sechzehn SIMD-Gruppen zweiunddreißig SIMD-Gruppen mit jeweils vier Rechenkernen auf, so können gleichzeitig Transformationskoeffizientenblöcke von einer ersten Gruppe von Bildern (bestehend aus vier Bildern) auf den ersten sechzehn SIMD-Gruppen des Stream-Prozessors decodiert werden und Transformationskoeffizientenblöcke von einer zweiten Gruppe von Bildern (welche verschieden ist zu der ersten Gruppe und aus vier Bildern besteht) auf den zweiten sechzehn SIMD-Gruppen des Stream-Prozessors decodiert werden. Ausführungsbeispiele der vorliegenden Erfindung ermöglichen damit durch eine Skalierbarkeit abhängig von der Größe des Stream-Prozessors, eine optimale Auslastung des Stream-Prozessors, und damit eine effektive Decodierung der Transformationskoeffizientenblöcke.
Gemäß weiteren Ausführungsbeispielen kann eine Anzahl von Bildern deren Transformationskoeffizientenblöcke gleichzeitig dekodiert werden, also beispielsweise eine Größe einer oben genannten Gruppe von Bildern auch kleiner als eine Anzahl von Rechenkernen einer SIMD-Gruppe sein. In diesem Fall können auch benachbarte Transformationskoeffizientenblöcke eines Bildes gleichzeitig auf Rechenkernen ein und derselben SIMD-Gruppe bearbeitet werden Bei einer Größe einer Gruppe von Bildern gleich 4 und einer Anzahl der Rechenkerne einer SIMD-Gruppe von 8 können dann beispielsweise von jedem Bild gleichzeitig jeweils zwei Transformationskoeffizientenblöcke auf Rechenkernen ein und derselben SIMD-Gruppe dekodiert werden Obwohl hier mehr Divergenzen innerhalb der SIMD-Gruppe auftreten können, als in dem Fall der Dekodierung jedes Transformationskoeffizientenblock eines Bilds auf einer anderen SIMD-Gruppe, so kann dieser Nachteil dadurch ausgeglichen werden, dass eine bessere Auslastung der SIMD-Gruppen erreicht werden kann. Weiterhin ist dieses Vorgehen immer noch vorteilhaft im Gegensatz dazu, die Ähnlichkeiten der (aufeinanderfolgenden) Bilder gar nicht auszunutzen
In diesem Fall ist es sinnvoll in einem Bild benachbarte Transformationskoeffizientenblöcke zur Dekodierung auf ein und derselben SIMD-Gruppe zu wählen, da sich diese innerhalb eines Bildes typischerweise weniger unterschieden als nicht benachbarte.
2a zeigt eine weitere Zuordnung von Transformationskoeffizientenblöcken von verschiedenen Bildern auf verschiedene Rechenkerne verschiedener SIMD-Gruppen. Die in 2a gezeigte Zuordnung könnte beispielsweise von dem Videodecodierer 100 gemäß 1a durchgeführt werden. Die in 2a gezeigte Zuordnung basiert auf dem im Vorhergehenden beschriebenen Prinzip, dass verschiedene Transformationskoeffizientenblöcke gleicher Bilder verschiedenen SIMD-Gruppen (beispielsweise eines Stream-Prozessors) zur Decodierung zugeordnet werden, um diese verschiedenen Transformationskoeffizientenblöcke eines Bildes zeitgleich mit den verschiedenen Transformationskoeffizientenblöcken weiterer Bilder zu decodieren. Eine erste in 2a gezeigte SIMD-Gruppe 105a mit Rechenkernen 104aa, 104ba, 104ca, 104da ist beispielsweise identisch zu der ersten SIMD-Gruppe 105 aus 1b. Eine zweite in 2a gezeigte SIMD-Gruppe 105b mit Rechenkernen 104ab, 104bb, 104cb, 104db kann auch identisch der ersten SIMD-Gruppe 105 gemäß 1b sein. Obwohl die Hardwarerealisierung (der strukturelle Aufbau) der beiden SIMD-Gruppen 105a und 105b identisch sein kann, so können auf diesen beiden SIMD-Gruppen komplett unterschiedliche Programme bzw. Befehle parallel auf deren Rechenkernen ausgeführt werden.
In dem in 2a gezeigten Beispiel wird ein erster Transformationskoeffizientenblock 103a eines ersten Bildes 106a aus einer Gruppe von Bildern 107 einem ersten Rechenkern 104aa der ersten SIMD-Gruppe 105a zugeordnet. Ein erster Transformationskoeffizientenblock 103b eines zweiten Bildes 106b aus der Gruppe von Bildern 107 wird einem zweiten Rechenkern 104ba der ersten SIMD-Gruppe 105a zur Decodierung zugeordnet usw. 2a unterscheidet sich zu 1b dadurch, dass zusätzlich zu der Zuordnung erster Transformationskoeffizientenblöcke 103a–103d der Bilder 106a–106d aus der Gruppe von Bildern 107 auf die Rechenkerne 104aa–104da der ersten SIMD-Gruppe 105a, zweite Transformationskoeffizientenblöcke 108a–108d der Bilder 106a–106d aus der Gruppe von Bildern 107 den Rechenkernen 104ab–104db der zweiten SIMD-Gruppe 105b zugeordnet werden. So wird beispielsweise ein zweiter Transformationskoeffizientenblock 108a des ersten Bildes 106a aus der Gruppe von Bildern 107 einem ersten Rechenkern 104ab der zweiten SIMD-Gruppe 105b zur Decodierung zugeordnet. Ferner wird ein zweiter Transformationskoeffizientenblock 108b des zweiten Bildes 106b aus der Gruppe von Bildern 107 einem zweiten Rechenkern 104bb der zweiten SIMD-Gruppe 105b zur Decodierung zugeordnet usw.
In dem in 2a gezeigten Ausführungsbeispiel wird nicht nur pro Bild jeweils ein Transformationskoeffizientenblock zeitgleich decodiert, sondern es werden zwei Transformationskoeffizientenblöcke pro Bild zeitgleich dekodiert. Es ist für einen Fachmann klar, dass dieses Prinzip beliebig erweitert werden kann, beispielsweise so weit, dass sämtliche Transformationskoeffizientenblöcke eines Bildes zeitgleich auf verschiedenen SIMD-Gruppen eines Stream-Prozessors decodiert werden. Wie aus 2a ersichtlich ist, überlappen sich sowohl die Positionen der ersten Transformationskoeffizientenblöcke 103a–103d als auch die Positionen der zweiten Transformationskoeffizientenblöcke 108a–108d. Diese jeweilige Überlappung der Transformationskoeffizientenblöcke und die Decodierung von in der Position überlappenden Transformationskoeffizientenblöcken verschiedener Bilder auf einer gemeinsamen SIMD-Gruppe nutzt dabei die Ähnlichkeit der überlappenden Transformationskoeffizientenblöcke in aufeinanderfolgenden Bildern aus. Dadurch kann eine parallele Decodierung der überlappenden Transformationskoeffizientenblöcke auf den Rechenkernen einer SIMD-Gruppe optimiert werden Wie im Vorhergehenden beschrieben wurde, basiert dies auf der Tatsache, dass Rechenkerne einer SIMD-Gruppe nur rein parallel arbeiten, wenn Befehlsschritte der verschiedenen Rechenkerne identisch sind, andernfalls werden die Befehlsschritte der verschiedenen Rechenkerne sequentiell abgearbeitet. Bei einer Verwendung von Transformationskoeffizientenblöcken mit ähnlichen Inhalten sind diese Befehlsschritte in einem größeren Teil identisch als bei einer Verwendung von nicht zusammenhängenden (bzw. nicht ähnlichen) Transformationskoeffizientenblöcken.
2b zeigt eine Zuordnung von Transformationskoeffizientenblöcken verschiedener Bilder verschiedener Gruppen von Bildern zu verschiedenen Rechenkernen verschiedener SIMD-Gruppen. Im Vorhergehenden wurde bereits erwähnt, dass es auch möglich ist, dass eine Anzahl von Bildern (bzw. deren Transformationskoeffizientenblöcke) gleichzeitig decodiert werden kann, welche eine Anzahl von Rechenkernen einer SIMD-Gruppe übersteigt. Dies ist in 2b gezeigt. Dabei sind vier Bilder (beispielsweise in einer Sequenz von Bildern aufeinanderfolgende Bilder) 106a–106d einer ersten Gruppe von Bildern 107a zugeordnet und weitere Bilder 106e–106h (welche beispielsweise in der Sequenz von Bildern den Bildern 106a–106d folgen) einer zweiten Gruppe von Bildern 107b zugeordnet. In einer Sequenz von Bildern kann beispielsweise ein erstes Bild 106e der zweiten Gruppe von Bildern 107b auf ein letztes (viertes) Bild 106d der ersten Gruppe 107a folgen Eine Einteilung der einzelnen Bilder aus der Sequenz von Bildern in Gruppen von Bildern kann dabei basierend auf einer Anzahl von Rechenkernen einer SIMD-Gruppe basieren. Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung können aber auch die Bilder 106a–106h zu einer gemeinsamen Gruppe von Bildern gefasst werden, beispielsweise da deren Transformationskoeffizientenblöcke zeitgleich auf Rechenkernen verschiedener SIMD-Gruppen eines Stream-Prozessors decodiert werden können. Die Einteilung von Bildern in Gruppen von Bildern kann daher auch unabhängig von der Anzahl von Rechenkernen einer SIMD-Gruppe erfolgen.
In dem in 2b gezeigten Beispiel weist jedes der Bilder 106a–106h der beiden Gruppen von Bildern 107a, 107b jeweils X Transformationskoeffizientenblöcke auf. Transformationskoeffizientenblöcke der ersten Gruppe von Bildern 107a werden daher auf Rechenkernen X verschiedener SIMD-Gruppen decodiert, wobei pro SIMD-Gruppe jeweils genau ein Transformationskoeffizientenblock eines der Bilder 106a–106d der ersten Gruppe 107a auf einem Rechenkern der SIMD-Gruppe decodiert wird. Analog dazu werden Transformationskoeffizientenblöcke der Bilder 106e–106h der zweiten Gruppe 107b von Bildern auf X weiteren SIMD-Gruppen des Stream-Prozessors decodiert. Dabei wird jeder Transformationskoeffizientenblock eines Bildes der Bilder 106e–106h der zweiten Gruppe 107b genau einem Rechenkern genau einer SIMD-Gruppe der zweiten X SIMD-Gruppen zugeordnet.
Es ist zu beachten, dass eine Zuordnung der Transformationskoeffizientenblöcke der Bilder 106a–106d der ersten Gruppe von Bildern 107a sowie der Bilder 106e–106h der zweiten Gruppe von Bildern 107b auf die Rechenkerne der 2X SIMD-Gruppen so erfolgt, dass auf keiner der SIMD-Gruppen zeitgleich zwei oder mehr Transformationskoeffizientenblöcke ein und desselben Bildes der Bilder 106a–106h decodiert werden. Es sei nochmals kurz erwähnt, dass Rechenkerne einer SIMD-Gruppe parallel stets dieselbe Instruktion ausführen und bei einer Abweichung der Instruktionen in den Rechenkernen einer SIMD-Gruppe (beispielsweise wenn eine wenn-dann-Abfrage ein anderes Ergebnis liefert) eine sequentielle Abarbeitung auf den Rechenkernen erfolgt, bis die Instruktionen auf den einzelnen Rechenkernen der SIMD-Gruppe wieder gleich sind und damit eine parallele Abarbeitung fortgesetzt werden kann.
Eine Ähnlichkeit der Transformationskoeffizientenblöcke, welche auf Rechenkernen ein und derselben SIMD-Gruppe decodiert werden, ist daher von Vorteil, da diese Fälle, in welchen die Instruktionen voneinander abweichen (wie oben anhand der wenn-dann-Abfrage erwähnt), seltener auftreten als in Fällen, in denen sich die Transformationskoeffizientenblöcke nicht ähneln bzw. signifikant voneinander unterscheiden. Im Gegensatz zu der streng parallelen Abarbeitung der Rechenkerne einer SIMD-Gruppe können einzelne SIMD-Gruppen eines Stream-Prozessors gleichzeitig verschiedene Instruktionen ausführen. Mit anderen Worten kann jede SIMD-Gruppe auf ihren Rechenkernen eine Operation ausführen, welche unabhängig von einer Operation auf Rechenkernen einer weiteren SIMD-Gruppe ist. Eine Ähnlichkeit von Transformationskoeffizientenblöcken, welche auf verschiedenen SIMD-Gruppen bearbeitet werden, ist daher nicht benötigt und würde zu keinem Geschwindigkeitsvorteil führen, da jede SIMD-Gruppe eine Abarbeitung unabhängig von den anderen SIMD-Gruppen durchführen kann.
Das in 2b gezeigte Beispiel zur Decodierung von Transformationskoeffizientenblöcken mehrerer Gruppen von Bildern gleichzeitig kann beliebig erweitert werden, beispielsweise solange, bis ein Stream-Prozessor vollständig ausgelastet ist. Im Folgenden sollen nun die im Vorhergehenden erläuterten Aspekte und weitere Aspekte anhand eines Beispiels eines Videodecodierers für den JPEG2000-Standard detailliert beschrieben werden.
Bei dem folgenden beschriebenen Beispiel werden die wesentlichen parallelisierbaren Codierungsschritte auf einen Stream-Prozessor ausgelagert und somit von vielen parallelen Vektorprozessoren (im Folgenden als SIMD-Gruppen bezeichnet) ausgeführt. Zudem kann eine entlastete CPU (welche beispielsweise den Stream-Prozessor ansteuert) parallel benutzt werden, um verbleibende Codierungsschritte schon für folgende Bilder auszuführen. Ein Beispiel für einen Stream-Prozessor, der schon in vielen modernen Desktop-Computern und Notebooks verfügbar ist, ist die Recheneinheit einer Grafikkarte (auch bezeichnet als GPU – graphics processing unit). Highend-GPUs bestehen heute aus Hunderten von parallel arbeitenden Prozessorkernen (der SIMD-Gruppen), wobei ständig neue Chips entwickelt werden und sich die Anzahl dieser Kerne stetig erhöht. Zudem gibt es erste Grafikkarten, welche zwei GPUs auf einer Karte vereinen. Die Rechenleistung von GPUs, gemessen in Fließkommazahlenoperationen pro Sekunde (FLOPS), steigt exponentiell an und hat die von CPUs lange übertroffen. Durch GPGPU-Technologien lässt sich diese Rechenleistung effizient für datenparallele Aufgaben nutzen. Dabei steht GPGPU für General Purpose Computing an GPUs (Berechnung allgemeiner Aufgaben auf Grafikkartenprozessoren).
3 zeigt einen Programmablaufplan 300 für eine Decodierung einer JPEG2000-Sequenz von Bildern, wie er auf einem Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung (beispielsweise auf dem Videodecodierer 100 gemäß 1a) ausgeführt werden kann. In dem in 3 gezeigten Programmablaufplan 300 sind so genannte Kernel-Funktionen, welche auf einem Stream-Prozessor ausgeführt werden, schraffiert dargestellt. Im Folgenden soll insbesondere die in 3 gezeigte Kernel-Funktion EBCOT Tier-1 von Interesse sein, da in dieser Transformationskoeffizientenblöcke von verschiedenen Bildern decodiert werden, was wie bereits im Vorhergehenden beschrieben durch einen Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt werden kann.
Die grobe Vorgehensweise des in 3 gezeigten Programmablaufplans 300 zur Decodierung von codierten JPEG2000-Bildern ist, dass in einem ersten Schritt 301 komprimierte JPEG2000-Bitströme oder Datenströme (beispielsweise Bitströme einer Gruppe von Bildern 107) zunächst beispielsweise von einer Festplatte in einen Arbeitsspeicher eingelesen werden. In einem nichtparallelen Schritt 302 werden, beispielsweise mittels der CPU (und nicht mittels des Stream-Prozessors), Metadaten (beispielsweise Metadaten für die Transformationskoeffizientenblöcke) aus den Bitströmen extrahiert. Dieser Schritt 302 kann auch als EBCOT Tier-2 bezeichnet werden. Als nächstes können in einem Schritt 303 die Bitströme in den Speicher der Grafikkarte kopiert werden. Oder allgemeiner, die Daten zur Decodierung können in den Speicher eines Stream-Prozessors transferiert werden. Da die Transfergeschwindigkeit auf manchen Hardwareplattformen mit der Menge der Daten zunehmen kann, werden alle Bitströme (insbesondere Bitströme verschiedener, beispielsweise aufeinanderfolgender, Bilder) zuvor hintereinander kopiert, um so in einem einzigen Vorgang transferiert werden zu können. In einem Schritt 304 können die einzelnen Bit- oder Datenströme der verschiedenen Bilder und damit deren Transformationskoeffizientenblöcke unter Nutzung des EBCOT Tier-1 Entropiedecodierungsalgorithmus (mit einem Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung) auf dem Stream-Prozessor decodiert werden. Dieser Prozess des EBCOT Tier-1 Algorithmus und insbesondere die Vorteile der Verwendung eines Videodecodierers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung bei der EBCOT Tier-1 Decodierung wird später noch detaillierter erläutert.
Nach einer Überprüfung, in einem Schritt 305, ob nur ein Gleichanteilsfrequenzband (beispielsweise ein sogenanntes LL0-Subband), welches bei einer Wavelet-Analyse in einem Videoencodierer, welcher die JPEG2000-Datenströme encodiert hat, entstanden ist rekonstruiert wird, wird basierend auf dieser Entscheidung auf dem Stream-Prozessor entweder eine Dequantisierung und eine inverse Farbtransformation in einem Schritt 306 durchgeführt, oder eine Dequantisierung und eine inverse diskrete Wavelet-Transformation in einem Schritt 307 durchgeführt. In dem Fall der Dequantisierung und inversen diskreten Wavelet-Transformation wird anschließend noch eine inverse Farbtransformation in einem Schritt 308 durchgeführt. Durch die Zusammenfassung verschiedener Decodierungsschritte in gemeinsamen Funktionen können teure Speicherzugriffe minimiert werden indem Ergebnisse lokal zwischengespeichert werden. Mit anderen Worten werden in mehreren Decodierungsschritten die Bilder auf der Grafikkarte (auf dem Stream-Prozessor der Grafikkarte) rekonstruiert. Anschließend können die Rohdaten in einem Schritt 309 entweder zurück in den Arbeitsspeicher transferiert oder aber über den Grafikkartenausgang direkt angezeigt werden.
Zur Ausführung dieser Funktionen existiert eine so genannte GPGPU-Technologie. Diese Technologie erlaubt Softwareentwicklern Instruktionen auf der Grafikkarte (auf der GPU der Grafikkarte) auszuführen, ohne zweckfremde Grafik-APIs, wie OpenGL oder Direct3D, benutzen zu missen. Beispielhafte proprietäre Lösungen sind die sogenannte „Compute Unified Device Architecture” (CUDA) und die sogenannte „ATI Stream Technology”. Darüber hinaus gibt es mit OpenCL aber auch einen nichtproprietären Standard. Wie im Vorhergehenden bereits erwähnt, besitzen GPUs (Prozessoren von Grafikkarten) typischerweise eine Stream-Prozessor-Architektur. Diese GPUs haben viele einzelne Prozesseinheiten (im Vorhergehenden auch als Rechenkerne 104a–104d bezeichnet), die in SIMD-Gruppen (beispielsweise die im Vorhergehenden erwähnte SIMD-Gruppe 105) zusammengefasst sind. Eine solche SIMD-Gruppe kann auch als Vektorprozessor oder SIMD-Vektor bezeichnet werden. SIMD steht dabei, wie im Vorhergehenden bereits erläutert, für das Single-Instruction Multiple-Data Paradigma. Die Prozessoren (die Rechenkerne) einer solchen SIMD-Gruppe führen dabei stets parallel die gleiche Instruktion auf verschiedenen Eingangsdaten aus. Bezogen auf die Ausführungsbeispiele in den 1b, 2a, 2b sind diese verschiedenen Eingangsdaten die verschiedenen Transformationskoeffizientenblöcke, die auf den Rechenkernen der einzelnen SIMD-Gruppen decodiert werden.
Manche Hardwareplattformen zeichnen sich dadurch aus, dass es mehrere Speicherregionen gibt, die sich durch Eigenschaften wie z. B. Größe, Lese- und Schreibgeschwindigkeit unterscheiden. Eine optimale Leistung eines Stream-Prozessors wird nur erreicht, wenn mehrere Regeln beachtet werden. Um die Rechenressourcen voll ausnutzen zu können, sollte ein Algorithmus ausreichend Datenparallelität aufweisen. Mit anderen Worten sollte ein Algorithmus die gleichen Instruktionen auf möglichst viele Daten gleichzeitig ausführen. Zur Ausnutzung der Ressourcen eines Stream-Prozessors ist dabei typischerweise eine Grüße von Tausenden von Threads (Prozessen) notwendig. Dabei wird ein Thread typischerweise auf einem Rechenkern einer SIMD-Gruppe ausgeführt. Auf die vorhergehenden Ausführungsbeispiele angewandt kann dabei ein Thread beispielsweise die Decodierung eines Transformationskoeffizientenblocks sein. Des Weiteren sollten Threads (Prozesse) einer SIMD-Gruppe möglichst zu jedem Zeitpunkt die gleiche Instruktion ausführen (wie bereits im Vorhergehenden erwähnt). Führen ein oder mehrere Threads andere Instruktionen aus, muss der Rest der Gruppe so lange warten, bis diese Threads mit der Abarbeitung fertig sind, um dann die parallele Abarbeitung fortzusetzen. Speicherbänke eines Stream-Prozessors sind teilweise darauf optimiert, dass benachbarte Threads (Prozesse, welche auf benachbarten Rechenkernen laufen) innerhalb einer SIMD-Gruppe parallel auf benachbarte Speicheradressen zugreifen. Aufgrund der langsamen Zugriffsgeschwindigkeit sollte das Schreiben und Lesen aus dem globalen Speicher (des Stream-Prozessors) minimiert werden. Dies lässt sich neben dem parallelen Zugriff (alle Threads können gleichzeitig auf ihre Speicheradressen zugreifen) auch durch Zwischenspeicherung (sogenanntes Cashing) in kleineren, schnelleren Speicherregionen erreichen.
In dem Beispiel des hier beschriebenen JPEG2000-Decodierers sind die einzelnen Decodierungsschritte (in 3 schraffiert markiert) auf der Grafikkarte in sogenannten Kernel-Funktionen implementiert. Eine solche Kernel-Funktion wird dabei von der CPU (Hauptprozessor eines Systems) aus aufgerufen, aber auf dem Stream-Prozessor (auf dem Prozessor der Grafikkarte) ausgeführt. Im Sinne des im Vorhergehenden erwähnten Single-Instruction Multiple-Date-(SIMD-)Paradigmas wird dabei eine Kernel-Funktion in vielen Threads (Prozessen) parallel ausgeführt, wobei jeder Thread auf einem der Prozessorkerne (einem Rechenkern einer SIMD-Gruppe) läuft und aufgrund seiner individuellen ID (Identifikationsnummer) errechnen kann, für welche Eingangsdaten (für welchen Transformationskoeffizientenblock) er zuständig ist.
In dem vorliegenden JPEG2000-Decodierer gibt es im Wesentlichen vier verschiedene Kernel-Funktionen, welche auf dem Stream-Prozessor ausgeführt werden. 4 zeigt diese verschiedenen vier Kernel-Funktionen. Eine erste Kernel-Funktion ist die Entropiedecodierung unter Nutzung des EBCOT Tier-1 Algorithmus zur Kontextmodellierung und MQ-Decodierung. Diese Kernel-Funktion ist als Block 304 in 3 gezeigt Eine zweite Kernel-Funktion ist die Dequantisierung mit anschließender horizontaler Wavelet-Synthese. Eine dritte Kernel-Funktion ist eine vertikale Wavelet-Synthese. Die zweite und die dritte Kernel-Funktion sind zusammengefasst in dem Block 307 in der 3 dargestellt Eine vierte Kernel-Funktion besteht aus einer optionalen Dequantisierung, einer inversen Farbraumtransformation, Clipping und einer Denormalisierung. Diese vierte Kernel-Funktion ist anhand des Blocks 308 in 3 dargestellt.
Aus 4 wird ersichtlich, dass jedes Bild 106a–106c in mehrere bei einer Wavelet-Analyse in einem JPEG2000-Encodierer entstandene Frequenzbänder 411a–411j eingeteilt ist. Das Frequenzband 411a ist dabei ein sogenanntes Gleichanteilsfrequenzband. Das Gleichanteilsfrequenzband 411a ist dabei typischerweise ein meist signifikantes Frequenzband, d. h. es enthält die für das Bild wichtigsten Informationen, und ein Frequenzband 411j, welches hohen Frequenzen zugeordnet ist, ist typischerweise ein wenigst signifikantes Frequenzband, d. h. es enthält die für das Bild unwichtigsten Informationen. In einem JPEG2000-Datenstrom 410 können beispielsweise codierte Transformationskoeffizientenblöcke des Gleichanteilsfrequenzbands 411a zuerst und codierte Transformationskoeffizientenblöcke des Frequenzbands 411j zuletzt übertragen werden. Eine Übertragung der Transformationskoeffizientenblöcke der weiteren Frequenzbänder in dem Datenstrom 410 erfolgt dabei in der Reihenfolge ihrer Bezugszeichen. Das heißt, als erstes werden Transformationskoeffizientenblöcke für das Frequenzband 411a, danach für das Frequenzband 411b, danach für das Frequenzband 411c usw. bis zu dem Frequenzband 411j übertragen. Ein Vorteil der JPEG2000-Decodierung ist dabei, dass die Übertragung jederzeit abgebrochen werden kann, aber trotzdem ein Bild rekonstruiert werden kann (zumindest falls das Gleichanteilsfrequenzband 411a vollständig übertragen wurde) und immer die maximal mögliche Qualität erreicht werden kann. Es sei nochmals erwähnt, dass jeder Transformationskoeffizientenblock oder Codeblock genau einem Frequenzband zugeordnet ist. Wie in 4 gezeigt, weist der Datenstrom 410 zusätzlich zu den Transformationskoeffizientenblöcken 103 Header-(Kopf)Informationen 412 auf, welche beispielsweise in Form von Metadaten eine Position eines korrespondierenden Transformationskoeffizientenblocks in einem Bild beschreiben.
Die Kernel-Funktionen zur Wavelet-Synthese (2, 3) sowie die Quantisierung, inverse Farbtransformation, Clipping und Denormalisierung (4) sind bereits veröffentlicht in Bruns, V., Acceleration of a JPEG2000 coder by outsourcing arithmetically intensive computations to a GPU, Master of Science Thesis, Tampere University of Technology, Mai 2008, und sind somit in dieser Schrift nicht weiter beschrieben, noch werden sie näher erläutert.
Wie aus 4 ersichtlich wird, ist der erste auf dem Stream-Prozessor ausgeführte Decodierungsschritt die EBCOT Tier-1 Entropiedecodierung 304 mit Kontextmodellierung. Dieser Schritt macht einen Großteil des gesamten Arbeitsaufwandes bei einer JPEG2000-Decodierung aus, ist aber stark vom Bildinhalt abhängig. Der EBCOT-Algorithmus arbeitet auf unabhängigen Codeblöcken (den Transformationskoeffizientenblöcken) und bietet somit nur eine grobe Segmentierung zur Parallelisierung. Die einzelnen, durch die Wavelet-Transformation (im JPEG2000-Encodierer) entstandenen Frequenzbänder 411a–411j (Subbänder) werden dabei in solche Codeblöcke 103 unterteilt. Da innerhalb eines Codeblocks 103 kausale Abhängigkeiten bestehen, ist ein Codeblock 103 die kleinste Einheit, die zu diesem Zeitpunkt parallel decodiert werden kann.
Wie bereits im Vorhergehenden beschrieben decodiert jeder Rechenkern einer SIMD-Gruppe einen Transformationskoeffizientenblock 103 oder, anders ausgedrückt, jeweils ein Thread rekonstruiert einen Codeblock 103. Die Position eines Codeblocks 103 innerhalb der Bitströme (der Datenströme der einzelnen Bilder, beispielsweise innerhalb des Datenstroms 410) wurde bereits im, von der CPU ausgeführten, EBCOT Tier-2 Algorithmus 302 ermittelt und zusammen mit anderen Metadaten (beispielsweise als eine Header-Information 412) über die Codeblöcke 103 dem Stream-Prozessor zugänglich gemacht. Auch sind die Koordinaten eines jeden Codeblocks 103 innerhalb des rekonstruierten Bildes bzw. der Subbänder (der Frequenzbänder) bekannt, so dass die decodierten Daten (die decodierten Transformationskoeffizientenblöcke) von den Threads (den Prozessen, welche auf den Rechenkernen laufen) direkt an die richtige Stelle (im jeweiligen Bild) geschrieben werden können und nicht anschließend umsortiert werden müssen. Wie im Vorhergehenden bereits beschrieben, lässt sich die Auslastung eines Stream-Prozessors erhöhen, indem man Codeblöcke 103 mehrerer Bilder gleichzeitig decodiert und so mehr Threads erzeugt. Eine solche Gruppe kann, wie im Vorhergehenden bereits beschrieben, als Group of Pictures (GOP – Gruppe von Bildern) bezeichnet werden. In dem hier gezeigten Beispiel eines JPEG2000-Decodierers ist diese Kernel-Funktion 304 die Einzige, die das Vorhandensein mehrerer Bilder ausnutzt. Alle folgenden Kernel-Funktionen erreichen schon innerhalb eines einzigen Bildes ausreichende Parallelität, da zumeist ein Thread für ein oder wenige Pixel erstellt werden kann.
In dem hier vorgestellten JPEG2000-Decodierer müssen nicht zwangsläufig immer alle Codeblöcke rekonstruiert werden. Beispielsweise ist es möglich, dass Codeblöcke leer sein können oder aber zu einem Frequenzband gehören, das verworfen werden kann, da unter Umständen nicht die ursprüngliche Auflösung, sondern nur eine reduzierte Auflösung, beispielsweise für eine Vorschau, rekonstruiert werden soll.
5 zeigt ein Struktogramm 500, welches beschreibt, welche Codeblöcke verworfen werden. Codeblöcke mit den an derselben Position (und in demselben Frequenzband) liegenden Codeblöcken der anderen Bilder in der Gruppe von Bildern werden gruppiert. Aus 3 geht hervor, dass nur ganze Gruppen (von Codeblöcken mit dem selben Index i) verworfen werden, um die im Vorhergehenden anhand der 1b–2b und im Nachfolgenden anhand der 6 beschriebene Zuordnung zwischen Codeblöcken und Thread-IDs bzw. Rechenkernen von SIMD-Gruppen zu ermöglichen.
Im Folgenden soll das Struktogramm 500 kurz erläutert werden. N steht dabei für die Anzahl der Codeblöcke in einem Bitstrom. Ein Bitstrom korrespondiert typischerweise mit einem Bild, und damit beschreibt N auch die Anzahl der Codeblöcke in einem Bild G beschreibt die Anzahl der Bilder in einer Gruppe von Bildern, welche gleichzeitig auf verschiedenen Rechenkernen und verschiedenen SIMD-Gruppen eines Stream-Prozessors berechnet werden. r beschreibt die Anzahl der zu rekonstruierenden Codeblöcke pro Bitstrom (oder pro Bild). r kann von N abweichen, da, wie im Vorhergehenden bereits beschrieben, es möglich sein kann, dass Codeblöcke leer sind oder nicht rekonstruiert werden müssen, da sie in einem falschen (nicht benötigten) Frequenzband liegen. Cblk_g beschreibt einen Vektor mit Codeblöcken für einen Bitstrom g (oder für ein Bild g). Cblk beschreibt einen Vektor mit Indizes nicht verworfener Codeblöcke (Codeblöcke, welche decodiert werden müssen).
Eine erste Schleife 501 zählt einen Index i von 0 bis N – 1 (über die Anzahl der Codeblöcke in einem Bitstrom) mit einer Schrittweite 1 durch. Die Anzahl N der Codeblöcke ist dabei typischerweise für jeden Bitstrom oder für jedes Bild identisch. Eine erste Abfrage 502 bestimmt, ob ein Codeblock aus dem Vektor Cblk₀ für den Bitstrom 0 mit dem Index i in einem zu verwerfenden Subband liegt, und falls er dies tut, werden alle Codeblöcke mit diesem Index i für alle Bitströme (für alle Bilder) verworfen und nicht decodiert. Liegt dieser Codeblock nicht in einem zu verwerfenden Subband, so wird anhand einer zweiten Zählschleife 503 und einer zweiten Abfrage 504 bestimmt, ob Codeblöcke aller Bitströme mit diesem Index i einen leeren Codeblock beschreiben, und falls sie dies tun, kann diese Gruppe von Codeblöcken mit dem Index i verworfen bzw. nicht decodiert werden. Falls mindestens ein Codeblock eines Bitstroms g nicht leer ist, so werden alle Codeblöcke der Bitströme mit diesem Index i decodiert. Eine Anzahl der Codeblöcke, die für einen Index i decodiert werden, kann daher immer gleich der Anzahl der Bilder G sein.
Indizes zum Rekonstruieren der Codeblöcke werden in dem Vektor Cblk gespeichert. r gibt dann an, wie viele Codeblöcke pro Bitstrom g (oder pro Bild) rekonstruiert werden und ist, wie im Vorhergehenden beschrieben, für alle Bitströme bzw. Bilder der Gruppe von Bildern identisch.
Nach der Bestimmung der zu verwerfenden Codeblöcke bzw. der zu decodierenden Codeblöcke wird die Kernel-Funktion 304 der EBCOT Tier-1 Decodierung mit einer Funktion 505 gestartet. Dabei werden G × r Threads gestartet. Diese Threads werden dabei, wie dies in den 1b–2b beschrieben wurde, so auf Rechenkerne von SIMD-Gruppen verteilt, dass Transformationskoeffizientenblöcke verschiedener Bilder bzw. verschiedener Bitströme zeitgleich auf verschiedenen Rechenkernen einer oder mehrerer SIMD-Gruppen decodiert werden.
Aus 5 wird ersichtlich, dass eine Anzahl von Threads zur Decodierung der Codeblöcke der Bilder einer Gruppe von Bildern bei verschiedenen Gruppen von Bildern variieren kann. Daraus folgt, dass auch eine für die Decodierung der Codeblöcke der Bilder benötigte Anzahl von Rechenkernen und SIMD-Gruppen variieren kann. Um einen Stream-Prozessor auszulasten kann damit auch eine Anzahl der Bilder in einer Gruppe von Bildern, welche gleichzeitig decodiert werden, variiert werden. So kann beispielsweise in dem Fall, dass weniger Codeblöcke pro Bild decodiert werden müssen, eine gröbere Anzahl von Bildern gleichzeitig decodiert werden als in einem Fall, in welchem mehr Codeblöcke pro Bild decodiert werden müssen. Mit anderen Worten kann ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgebildet sein, um eine Anzahl von gleichzeitig zu decodierenden Bildern zu variieren, basierend auf einer Anzahl von zu decodierenden Transformationskoeffizientenblöcke der Bilder und abhängig von einer Anzahl von Rechenkernen und SIMD-Gruppen eines Stream-Prozessors.
Aus 5 wird weiterhin ersichtlich, dass auch Codeblöcke, welche leer sind, aber in einer Gruppe mit Codeblöcken (welche alle den gleichen Index i haben) sind, in der wenigstens ein Codeblock nicht leer ist, decodiert werden.
Da der Ablauf des EBCOT Tier-1 Algorithmus inhaltsabhängig ist, ist es von Vorteil, aber nicht notwendig, wenn die Bilder einer Gruppe von Bildern Ähnlichkeiten aufweisen, also innerhalb einer Bildsequenz nah beieinander liegen. Durch geschickte Zuordnung von Codeblöcken zu Threads lässt sich die Wahrscheinlichkeit erhöhen, dass Threads innerhalb eines SIMD-Vektors gleiche Instruktionen ausführen.
6 zeigt eine Zuordnung von Codeblöcken zu Threads. 6 ist ähnlich der 2b mit dem Unterschied dazu, dass alle Bilder 106a–106n, deren Transformationskoeffizientenblöcke gleichzeitig auf Rechenkernen 104a–104d verschiedener SIMD-Vektoren 105a–105n decodiert werden, zu einer gemeinsamen Gruppe von Bildern 107 zusammengefasst sind. Mit anderen Worten sind in 6 auch Bilder in einer gemeinsamen Gruppe von Bildern 107, deren Transformationskoeffizientenblöcke nicht auf denselben SIMD-Gruppen decodiert werden. In 6 sind korrespondierende Codeblöcke (Codeblöcke mit der gleichen Position innerhalb ihres Bildes) aufeinanderfolgender Bilder einheitlich schattiert. In dem Beispiel in 6 werden beispielsweise Codeblöcke, welche mit einer ersten Schraffierung 601 schraffiert sind, auf Threads oder Rechenkernen eines ersten SIMD-Vektors 105a decodiert. Codeblöcke, welche mit einer zweiten Schraffierung 602 schattiert sind, werden auf Threads oder Rechenkernen eines zweiten SIMD-Vektors 105b decodiert. Wie aus 6 ersichtlich ist, können in dem Beispiel jeweils vier Codeblöcke auf einem SIMD-Vektor decodiert werden, da jeder SIMD-Vektor genau vier Rechenkerne zur Ausführung von vier parallelen Threads aufweist. Gemäß weiteren Ausführungsbeispielen kann eine SIMD-Gruppe aber auch eine beliebige Anzahl von Rechenkernen aufweisen, so dass eine beliebige Anzahl von Codeblöcken verschiedener Bilder (beispielsweise aufeinanderfolgender Bilder) gleichzeitig auf einer SIMD-Gruppe decodiert werden können. Die in 6 gezeigte Gruppe von Bildern 107 besteht aus G Bildern, wobei jedes Bild R zu rekonstruierende Codeblöcke enthält. Ein Codeblock ist jeweils durch BildID.CblkID gekennzeichnet. Eine BildID eines Codeblocks und eine CblkID eines Codeblocks berechnet sich wie folgt: BildID = modulo(ThreadID, G) CblkID = BildID × R + (ThreadID – BildID)/G
Messungen haben gezeigt, dass EBCOT Tier-1 für eine Gruppe von Bildern aus aufeinanderfolgenden Bildern einer Sequenz zwischen 5–10% schneller berechnet wird, als für eine Gruppe von Bildern bestehend aus sehr unterschiedlichen Einzelbildern der Sequenz. Für eine Gruppe aus identischen Bildern beschleunigt sich (durch die parallele Abarbeitung mehrerer Bilder gleichzeitig) die Berechnungszeit um 20–25%.
7 zeigt einen Transformationskoeffizientenblock 103, beispielsweise einen Transformationskoeffizientenblock eines Bildes 106a einer Gruppe von Bildern 107, vor dessen Decodierung unter Nutzung des Videodecodierers 100 gemäß 1a. Der Transformationskoeffizientenblock 103, welcher auch als Codeblock 103 bezeichnet werden kann, weist 16 Koeffizienten auf. Der Transformationskoeffizientenblock 103 ist beispielsweise ein JPEG2000-Transformationskoeffizientenblock. 7 zeigt die Zerlegung des Transformationskoeffizientenblocks 103 in vier Bitebenen 701, 702, 703, 704. Eine vierte Bitebene 701 enthält dabei signifikante Bits (MSB) der Koeffizienten des Transformationskoeffizientenblocks 103. Eine erste Bitebene 704 enthält am wenigsten signifikante Bits (LSB) der Koeffizienten des Transformationskoeffizientenblocks 103. Der Transformationskoeffizientenblock 103 kann zusätzlich noch eine Ebene enthalten, welche Vorzeichen der einzelnen Koeffizienten definiert. Die Koeffizienten des Transformationskoeffizientenblocks 103 können beispielsweise Wavelet-Indizes sein. Innerhalb eines Codeblocks (innerhalb des Transformationskoeffizientenblocks 103) werden die Wavelet-Indizes in einem JPEG2000-Decodierer (beispielsweise mit dem Videodecodierer 100 gemäß 1a) Bitebene für Bitebene rekonstruiert. Dabei wird mit der signifikantesten Bitebene angefangen und mit der am wenigsten signifikanten Bitebene aufgehört.
In dem Beispiel in 7 würde zuerst die vierte Bitebene 701 und zuletzt die erste Bitebene 704 decodiert werden. Codeblöcke können dabei unterschiedliche Bittiefen aufweisen. Die Anzahl von Bittiefen der Codeblöcke kann dabei sowohl innerhalb eines Bildes als auch innerhalb einer Gruppe von Bildern variieren So beinhaltet beispielsweise ein Codeblock aus einem niedrigen Frequenzband (beispielsweise dem Frequenzband 411a gemäß 4) wichtigere Informationen und sie werden mit einer höheren Bittiefe (d. h. mit einer höheren Anzahl von Bitebenen) angegeben, als die Informationen eines Codeblocks aus einem höheren Frequenzband (beispielsweise aus dem Frequenzband 411j gemäß 4). Bei der Decodierung wird innerhalb eines Codeblocks mit der wichtigsten Bitebene, die nicht nur aus 0 Bits besteht, begonnen In dem in 7 gezeigten Beispiel würde daher zuerst die vierte Bitebene 701 decodiert werden.
8 zeigt ein Sequenzdiagramm zur Decodierung eines Transformationskoeffizientenblocks am Beispiel des Transformationskoeffizientenblocks 103 aus 7. Jede Bitebene eines Codeblocks (außer die wichtigste Bitebene des Codeblocks) wird in drei verschiedenen Pässen (auch bezeichnet als Codierdurchläufe) durchlaufen, wobei jedes Bit einer Bitebene in genau einem der drei Pässe rekonstruiert wird. Ein erster Codierdurchlauf wird auch als „Significance-Pass” (deutsch: Signifikanz-Durchlauf) oder „Significance-Propagation-Pass” (deutsch: Signifikanzausbreitungs-Durchlauf) bezeichnet, ein zweiter Codierdurchlauf wird auch als „Magnitude-Refinement-Pass” (deutsch: Betragsverfeinerungs-Durchlauf) bezeichnet und ein dritter Codierdurchlauf wird auch als „Clean-up-Pass” (deutsch: Aufräume-Durchlauf) bezeichnet. Wie aus 8 ersichtlich wird, wird die vierte und wichtigste Bitebene 701 des Transformationskoeffizientenblocks 103 nur von dem dritten Codierdurchlauf durchlaufen, d. h. alle Bits dieser vierten Bitebene 701 werden innerhalb diesem dritten Codierdurchlauf decodiert. Eine dritte Bitebene 702, eine zweite Bitebene 703 und die erste Bitebene 704 werden dahingegen jeweils von allen drei Codierdurchläufen durchlaufen Auf eine genaue Beschreibung der einzelnen Codierdurchläufe wird hier verzichtet und es sei auf die Fachliteratur, wie beispielsweise das Dokument [Michael W. Marcellin, An Overview of JPEG2000, Proc. of IEEE Data Compression Conference, Seiten 523–541, 2000] verwiesen. In den Metadaten eines Codeblocks ist angegeben, wie viele Passe in einem Codeblock enthalten sind, d. h. wie viele Pässe zur vollständigen Decodierung des Codeblocks benötigt werden Bei dem in 7 gezeigten Transformationskoeffizientenblock 103 werden beispielsweise vier Bitebenen mit insgesamt zehn Pässen oder Codierdurchläufen decodiert. Wie im Vorhergehenden bereits erwähnt, kann die Anzahl der Bitebenen der Transformationskoeffizienten verschieden sein und damit auch die Anzahl der Pässe, die für eine Decodierung eines Transformationskoeffizientenblocks benötigt werden.
Mit anderen Worten werden die Codeblöcke mit drei verschiedenen Prozeduren, sogenannten Passtypen oder Codierdurchläufen, decodiert. Jede dieser Prozeduren wird, abhängig vom Bildinhalt, viele Male ausgeführt. Gemäß weiteren Ausführungsbeispielen der vorliegenden Erfindung ist eine weitere Strategie daher, um zu erreichen, dass Threads einer SIMD-Gruppe oft gleiche Instruktionen ausführen, benachbarte Threads (Threads, welche auf Rechkernen derselben SIMD-Gruppe laufen) zu einem Zeitpunkt (zeitgleich) immer die gleiche Prozedur (den gleichen Codierdurchlauf) ausführen zu lassen.
Wie im Vorhergehenden beschrieben, ist für jeden Codeblock innerhalb seiner Metadaten angegeben, wie viele Pässe in einem Codeblock enthalten sind. Ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann daher zunächst die maximale und minimale Passnummer aller Codeblöcke ermitteln. Eine maximale null-basierte Passnummer des in 7 gezeigten Transformationskoeffizientenblocks 103 wäre beispielsweise 9 (der 4x3-2. Pass) und eine minimale Passnummer des Transformationskoeffizientenblocks 103 wäre beispielsweise 0, wenn in der Kompression keine Passe verworfen wurde um eine maximale Größe des komprimierten Bildes einhalten zu können. Ein weiterer Transformationskoeffizientenblock, welcher beispielsweise an einer überlappenden Position zu dem Transformationskoeffizientenblock 103 in einem verschiedenen Bild als das Bild des Transformationskoeffizientenblocks 103 angeordnet ist, kann beispielsweise Bits in einer höheren Bitebene (beispielsweise einer sechsten Bitebene – ein gesetztes Bit 1 hat somit den absoluten Wert 2^5) aufweisen, dafür aber beispielsweise um 5 Pässe verkürzt worden sein, um eine maximale Datenrate einhalten zu können. Eine maximale Passnummer dieses zweiten Transformationskoeffizientenblocks wäre dann beispielsweise 15 (der 6x3-2. Pass) und eine minimale Passnummer des weiteren Transformationskoeffizientenblocks wäre dann beispielsweise 5 (der 6. Pass). Der Transformationskoeffizientenblock 103 und der weitere Transformationskoeffizientenblock könnten beispielsweise auf zwei Rechenkernen einer gemeinsamen SIMD-Gruppe decodiert werden.
Es sei erwähnt, dass nur weil eine Bitebene nur Nullen aufweist nicht automatisch Passe dieser Bitebene oder Passe in der Signifikanz folgender Bitebenen wegelassen werden. Es ist lediglich wahrscheinlich, dass die untersten Pässe (beispielsweise die untersten 2x3 Pässe) bei verlustbehafteter Kompression in der „PCRD-Optimization” (Post-Compression Rate-Distortion-Optimization, deutsch: Datenraten-/Störungsoptimierung nach der Kompression) abgeschnitten werden, da das Beibehalten der Passe das Ergebnis nicht verbessert (zumindest in dem Fall, in dem nur Nullen rekonstruiert würden, die im Falle von verworfenen Pässen eh angenommen würden)
Innerhalb der Kernel-Funktion (des EBCOT Tier-1 Decodierungsalgorithmus 304) wird nun genau über diese Passnummern iteriert. Einzelne Threads (einzelne Rechenkerne) führen im Folgenden aber nur die entsprechende Passdecodierungsprozedur aus, wenn ihr Codeblock die Passnummer auch enthält. Als Beispiel würde ein erster Rechenkern einer SIMD-Gruppe, welcher den weiteren Transformationskoeffizientenblock decodiert, mit der Decodierung der sechsten Bitebene anfangen, und ein zweiter Rechenkern der gleichen SIMD-Gruppe, welcher den Transformationskoeffizientenblock 103 decodiert, solange mit seiner Verarbeitung warten, bis der erste Rechenkern bei der Decodierung der vierten Bitebene 701 (genauer bei dem Clean-up-Pass oder dem dritten Codierdurchlauf der vierten Bitebene) angekommen ist und erst dann die Decodierung der vierten Bitebene 701 des Transformationskoeffizientenblocks 103 mit dem dritten Codierdurchlauf starten. Der zweite Rechenkern, welcher den Transformationskoeffizientenblock 103 decodiert, beendet seine Decodierung dann mit dem Clean-up-Pass (oder dem dritten Codierdurchlauf) in der untersten Bitebene (in der ersten Bitebene 704). Der erste Rechenkern, welcher den weiteren Transformationskoeffizientenblock decodiert, läuft nur weiter, bis der erste Codierdurchlauf (der Significance-Propagation-Pass) der zweituntersten Bitebene (also beispielsweise der zweiten Bitebene 703) beendet ist, weil ja die letzten Senf Pässe abgeschnitten wurden. Mit anderen Worten laufen die beiden Rechenkerne rein parallel ab dem dritten Codierdurchlauf der vierten Bitebene 701 bis zu dem ersten Codierdurchlauf der zweiten Bitebene 703.
Aus diesem Beispiel geht hervor, dass eine möglichst parallele Abarbeitung bzw. Decodierung erreicht werden kann, wenn Transformationskoeffizientenblöcke, welche auf Rechenkernen einer gemeinsamen SIMD-Gruppe decodiert werden, eine ähnliche oder gleiche Anzahl von Pässen bzw. Codierdurchläufen benötigen. Dies kann dadurch erreicht werden, dass Transformationskoeffizientenblöcke gleicher oder überlappender Positionen verschiedener Bilder auf verschiedenen Rechenkernen der gleichen SIMD-Gruppe decodiert werden. Aufgrund der örtlich gleichen Position der Transformationskoeffizientenblöcke in den Bildern ist insbesondere bei aufeinanderfolgenden Bildern eine hohe Ähnlichkeit der Transformationskoeffizientenblöcke und damit auch eine ähnliche oder gleiche Anzahl von Codierdurchläufen annehmbar.
Ein Vorteil von Ausführungsbeispielen der vorliegenden Erfindung ist damit, dass durch eine zeitlich parallele Decodierung von Transformationskoeffizientenblöcken überlappender Positionen verschiedener Bilder auf Rechenkernen einer gemeinsamen SIMD-Gruppe Ähnlichkeiten der Transformationskoeffizientenblöcke ausgenutzt werden und damit eine maximal mögliche parallele Abarbeitung ermöglicht wird. Die verschiedenen Bilder können dabei aufeinanderfolgende Bilder innerhalb einer Sequenz von Bildern sein.
Wie aus dem vorherigen Beispiel ersichtlich wurde, können Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung daher ausgebildet sein, um bei der zeitgleichen Decodierung von Transformationskoeffizientenblöcken verschiedener Bilder auf verschiedenen Rechenkernen einer SIMD-Gruppe auf den verschiedenen Rechenkernen der SIMD-Gruppe zeitgleich jeweils die gleiche Bitebene zu decodieren.
Gemäß weiteren Ausführungsbeispielen kann, wie im Vorhergehenden beschrieben, auf den Rechenkernen einer SIMD-Gruppe jeweils der gleiche Codierdurchlauf der drei oben beschriebenen Codierdurchläufe zur Decodierung einer Bitebene genutzt werden.
Soll die gleiche GPU (der gleiche Stream-Prozessor) zum Dekodieren und Anzeigen eines Bildes benutzt werden, konkurrieren die entsprechenden Funktionen um die GPU. Wie bereits erwähnt, können die Codeblöcke mehrerer Bilder (einer Gruppe von Bildern oder mehrere Gruppen von Bildern) auf einmal dekodiert werden, um die Auslastung der GPU zu erhöhen. Als Beispiel, möchte man eine Bildsequenz mit 24 Bildern pro Sekunde abspielen, reicht es aus, wenn die Dekodierung weniger als 1/24 Sekunde multipliziert mit der Anzahl von Bildern in der Gruppe von Bildern, also z. B. 4/24 Sekunden, braucht. Da diese Kernel-Funktion (die EBCOT Tier-1 Entropiedecodierung 304) den größten Zeitaufwand benötigt, wird die GPU für ein Großteil dieser Periode beansprucht. Gleichzeitig musste aber jede 1/24 Sekunde die GPU benutzt werden, um ein zuvor dekodiertes Bild anzuzeigen. Im Gegenteil zu CPUs kann eine Funktion auf einer GPU aber erst gestartet werden, nachdem eine andere Funktion komplett abgearbeitet wurde. Es kommt somit beim Abspielen zum Stocken, obwohl im Mittel eine ausreichende Dekodiergeschwindigkeit erreicht werden könnte.
Eine Lösung gemäß Ausführungsbeispielen der vorliegenden Erfindung ist es, die zeitaufwendige EBCOT Tier-1 Kernel-Funktion 304 in mehrere kleine Aufrufe zu unterteilen, die jeweils die Dauer eines Bildintervall von beispielsweise jeweils 1/24 Sekunden nicht überschreiten. Somit ist die Chance gegeben, dass der GPU Scheduler (der Aufgabenverteiler) abwechselnd Decodier- und Anzeigefunktionen Zugriff zur GPU gewährt und das Stocken minimiert oder eliminiert wird.
Dies kann beispielsweise dadurch erreicht werden, dass ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgebildet ist, um die Decodierung der Transformationskoeffizientenblöcke auf den verschiedenen Kernen einer oder mehrerer SIMD-Gruppen zu unterbrechen.
Beispielsweise kann dies dadurch erreicht werden, dass pro Aufruf nur eine begrenzte Anzahl von Pässen (nur eine begrenzte Anzahl von Codierdurchläufen) decodiert wird. Beispielsweise kann pro Aufruf immer genau eine Bitebene decodiert werden oder sogar nur ein Pass, also nur ein Codierdurchlauf. Ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann damit ausgebildet sein, um eine Decodierung von Transformationskoeffizientenblöcken zwischen zwei aufeinanderfolgenden Codierdurchläufen zu unterbrechen, um beispielsweise ein bereits decodiertes Bild zur Ausgabe zur Verfügung zu stellen.
Im Fall, dass diese Granularität nicht ausreicht, so können auch die einzelnen Pässe oder Codierdurchläufe von einem Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung unterteilt bzw. unterbrochen werden. Wie im Vorhergehenden bereits beschrieben, werden Bitebenen eines Transformationskoeffizientenblocks im JPEG2000-Standard mit maximal drei aufeinanderfolgenden Codierdurchläufen codiert
9 zeigt eine Bitebene 901 eines Transformationskoeffizientenblocks der Größe 8×8 Pixel. In dem Transformationskoeffizientenblock 901 ist mit Pfeilrichtungen die Codierreihenfolge in einem der Codierdurchläufe aufgezeigt. Es wird deutlich, dass eine Decodierung in einem Codierdurchlauf immer in Streifen 902a, 902b von vier Pixeln 903 erfolgt. Um die Granularität zu erhöhen, kann daher ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung einen einzelnen Codierdurchlauf oder Pass in diese Streifen 902a, 902b aus vier Pixel Höhe unterteilen. Oder, mit anderen Worten, kann ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung eine Decodierung eines Transformationskoeffizientenblocks oder einer Bitebene (beispielsweise der Bitebene 903) eines Transformationskoeffizientenblocks innerhalb eines Codierdurchlaufs unterbrechen, beispielsweise um ein bereits decodiertes Bild zur Ausgabe zur Verfügung zu stellen. Danach kann die Abarbeitung des Codierdurchlaufs an der Stelle fortgesetzt werden, an der sie unterbrochen wurde. So kann ein Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung beispielsweise zuerst einen ersten Streifen 902a der Bitebene 901 abarbeiten, anschließend ein bereits decodiertes Bild zur Ausgabe zur Verfügung stellen oder eine andere Funktion auszuführen und danach mit der Abarbeitung eines zweiten Streifens 902b der Bitebene 901 fortsetzen.
Gemäß einigen weiteren Ausführungsbeispielen kann diese Granularität auch in einem beliebigen weiteren Maße erhöht oder verkleinert werden, beispielsweise bis auf Pixelebene, das heißt, dass nach einer Decodierung eines Pixels 903 eine Unterbrechung in einem Codierdurchlauf vorgesehen sein kann. Diese Granularität in den Codierdurchläufen kann beispielsweise durch ein gezieltes Aufrufen einer Codierdurchlauffunktion auf Rechenkernen von SIMD-Gruppen erreicht werden, wobei diese Funktion eine Variable enthält, welche angibt, wie viele Streifen oder wie viele Pixel einer Bitebene am Stück, d. h. ohne Unterbrechung, decodiert werden sollen.
Wie viel Zeit ein einzelner Pass oder Streifen beansprucht, kann, unter Berücksichtigung des verwendeten Stream-Prozessors und der Anzahl der Codeblöcke, die an dem Pass teilnehmen (Codeblöcke, welche auf Rechenkernen ein und derselben SIMD-Gruppe zeitgliche decodiert werden), abgeschätzt und in Folge durch mitlaufende Zeitmessungen korrigiert werden.
Eine weitere Optimierung der Decodierung der Transformationskoeffizientenblöcke kann erreicht werden, wenn einige generelle Strategien eingehalten werden, um die Abarbeitung des Algorithmus auf einem Stream-Prozessor zu optimieren. So kann beispielsweise das Vorhandensein von Register ausgenutzt werden, in denen Zwischenergebnisse gespeichert und so teure Zugriffe auf langsame Speicherregionen minimiert werden. Insbesondere die 18 Kontexte eines MQ-Decodierers, welche zusammen die Wahrscheinlichkeitstabelle in Form einer Zustandsmaschine ergeben, können in einer Speicherregion untergebracht werden, die besonders schnell gelesen und geschrieben werden kann. Aufgrund ihrer Größe können die Zustandsdaten eines jeden Pixels eines Codeblocks, welche häufig gelesen und geschrieben werden, in einer zugrundeliegenden CUDA-Implementation im langsamen globalen Grafikkartenspeicher untergebracht sein. Ebenso können die rekonstruierten Blöcke, welche ebenfalls gelesen und geschrieben werden, sowie der ursprüngliche Bitstrom, welcher nur gelesen wird, im langsamen globalen Grafikkartenspeicher untergebracht werden.
Das beschriebene Beispiel der Implementierung eines JPEG2000-Decodierers unter Nutzung eines Videodecodierers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung (beispielsweise des Videodecodierers 100 gemäß 1a) ermöglicht es, den Vorgang der Decodierung von einer Sequenz von Bildern auf einem oder mehreren Stream-Prozessoren auszuführen. Die parallele Berechnung von mehreren Bildern (beispielsweise einer Gruppe von Bildern oder mehrere Gruppen von Bildern) gleichzeitig erlaubt es, auch Stream-Prozessoren mit sehr vielen Kernen auszulasten.
Dies führt im Vergleich zu einer herkömmlichen seriellen Abarbeitung zu einer deutlichen Beschleunigung der Ausführungszeit des gesamten Dekodiervorgangs sowie zu einer Entlastung der CPU. Durch die Entwicklung schnellerer Stream-Prozessoren wird sich die Ausführungszeit von Decodierern gemäß Ausführungsbeispielen der vorliegenden Erfindung auch in Zukunft, ohne Mehraufwand für einen Entwickler, weiter beschleunigen. Stream-Prozessoren in Form von Grafikkarten sind besonders preisgünstig und leicht erhältlich, insbesondere im Vergleich zu professionellen FPGA-basierten Lösungen.
Im Folgenden sollen mm nochmals einige Aspekte von Videodecodierern gemäß Ausführungsbeispielen der vorliegenden Erfindung benannt werden.
Einige Ausführungsbeispiele der vorliegenden Erfindung schaffen einen JPEG2000-Decodierer, welcher einen oder mehrere Stream-Prozessoren zur JPEG2000-Dekompression verwendet.
Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen einen JPEG2000-Decodierer, welcher Codeblöcke mehrerer Bilder (einer Gruppe von Bildern) parallel decodiert, um die Auslastung des Stream-Prozessors zu erhöhen.
Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen einen JPEG2000-Decodierer, welcher Codeblöcke so den einzelnen Threads zuordnet, dass korrespondierende Codeblöcke aufeinanderfolgender Bilder innerhalb eines SIMD-Vektors bearbeitet werden.
Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen einen JPEG2000-Decodierer, der die Abarbeitung der einzelnen Codepässe oder Codierdurchläufe so kontrolliert, dass Threads eines SIMD-Vektors stets den gleichen Passtyp bearbeiten.
Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen einen JPEG2000-Decodierer, der die Kernel-Funktionen (beispielsweise die Codierdurchläufe) so granular halten kann, dass ihre Ausführungsdauer ein Bildratenintervall nicht übersteigt und dadurch andere Funktionen zum Rendern von Bildern (wie beispielsweise OpenGL oder Direct3D-Funktionen) nicht behindert werden.
10 zeigt ein Flussdiagramm eines Verfahrens 1000 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zum Decodieren einer Sequenz von Bildern, von denen jedes in eine Mehrzahl von Transformationskoeffizientenblöcke codiert ist, bei dem Transformationskoeffizientenblöcke verschiedener Bilder zeitgleich auf verschiedenen Rechenkernen einer SIMD-Gruppe decodiert werden.
Ausführungsbeispiele der vorliegenden Erfindung können benutzt werden, um JPEG2000-Bilder schnell zu dekomprimieren. Im Kontext vom digitalen Kino bietet sich vor allem das Abspielen einer Sequenz von JPEG2000-Bitstörmen (*.j2c), Bildern im JPEG2000-Format (*.jp2) oder in anderen Container-Formaten verpackten JPEG2000-Bildsequenzen als Anwendung an. Insbesondere Digital Cinema Packages (DCP – digitale Kinopakete), die benutzt werden, um digitale Kinofilme an Kinos oder andere Empfangen zu versenden, enthalten im sogenannten MXF-Container-Format verpackte JPEG2000-Bildsequenzen und könnten direkt in Echtzeit abgespielt werden. JPEG2000-Kompression wird aber auch in anderen Anwendungsgebieten eingesetzt. So wird das Kompressionsverfahren z. B. in digitalen Filmarchiven benutzt, um Videomaterial abzuspeichern. Eine mögliche Anwendung für Ausführungsbeispiele der vorliegenden Erfindung ist eine Anwendung, die Filme aus einem Archiv liest und in andere Zielformate transcodiert.
Obwohl im Vorhergehenden der Hauptfokus auf JPEG2000-Decodierung lag und damit die Transformationskoeffizientenblöcke typischerweise JPEG2000-Transformationskoeffizientenblöcke sind, welche beispielsweise aus einer Wavelet-Analyse in einem JPEG2000-Encodierer hervorgegangen sind, so können gemäß weiteren Ausführungsbeispielen die Transformationskoeffizientenblöcke auch aus einer spektralen Dekompositionstransformation hervorgegangen sein, wie beispielsweise aus einer diskreten Kosinustransformation, wie sie beispielsweise in dem weit verbreiteten H.264-Standard verwendet wird.
Ausführungsbeispiele der vorliegenden Erfindung ermöglichen damit im ganz Allgemeinen eine Decodierung von Transformationskoeffizientenblöcken verschiedener Bilder zeitgleich (d. h. parallel) beispielsweise auf einem Stream-Prozessor, welcher für eine massiv parallele Abarbeitung von Daten optimal geeignet ist.
Zusätzlich zu der Transformationskoeffizientenblockdecodierung (beispielsweise der EBCOT Tier-1 Decodierung) können auch andere Funktionen bei der Decodierung eines Bildes oder einer Sequenz von Bildern auf Stream-Prozessoren ausgeführt werden. So wurde beispielsweise die Wavelet-Transformation bereits für Stream-Prozessoren optimiert. Bevor es GPGPU-Technologien gab, haben Wong u. a. die Wavelet-Stufe des JasPer-Codecs mittels der Shader-Sprache Cg auf die Grafikkarte ausgelagert (Wong, T. T., Leung, C. S., Heng, P. A., Wang, J. Q., Discrete Wavelet Transform an Consumer-level Graphics Hardware, IEEE Transactions an Multimedia, Band 9, Nummer 3, Seiten 668–673, April 2007). Tenllado u. a. haben basierend auf Cg-Implementationen festgestellt, dass die schnelle Wavelet-Transformation als Algorithmus dem Lifting-Schema auf modernen GPU-Architekturen vorzuziehen ist (Tenllado, C, Lario, R., Prieto, M., Tirado, F., The 2D Discrete Wavelet Transform an Programmable Graphics Hardware, Proc. of the 4^th IASTED International Conference an Visualization, Imaging, and Image Processing (VIIP '04), Seiten 808–813, Marbella, Spanien, Juni/August 2004). Zudem wurde die Wavelet-Transformation des Dirac-Codecs mit der GPGPU-Technologie CUDA-implementiert, wobei hier das Lifting-Schema verwendet wurde (van der Laan, W. J., GPU-Accelerated Dirac Video Codec, [Online] verfügbar: http://www.cs.rug.nl/~wladimir/sc-cuda/).
Studenten der Universität Stuttgart haben mit cuj2k eine CUDA-Implementation eines JPEG2000-Encodierers veröffentlicht (http://cuj2k.sourceforge.net/). Es werden Farbtransformation, Wavelet-Transformation und EBCOT Tier-1 auf die Grafikkarte ausgelagert Die Parallelität im EBCOT Tier-1 wird dabei nicht erhöht, indem mehrere Bilder gleichzeitig encodiert werden und auch wird die Ähnlichkeit aufeinanderfolgender Bild nicht ausgenutzt, wie dies bei einigen Ausführungsbeispielen der vorliegenden Erfindung der Fall ist.
Zusätzlich zeigen die Dokumente [Bruns, V., Acceleration of a JPEG2000 coder by outsourcing arithmetically intensive computations to a GPU, Master of Science Thesis, Tampere University of Technology, Mai 2008] und [Bruns, V., Sparenberg, H., Schmitt, A., Accelerating a JPEG2000 Coder with CUDA, 45^th JPEG committee meeting, Poitiers, France, Juli 2008] Verfahren zur Berechnung der Wavelet-Synthese, der Dequantisierung und der Farbtransformation auf einem Stream-Prozessor, wie diese in 4 gezeigt wurden.
Zusammenfassend lässt sich sagen, dass ein Ziel von Ausführungsbeispielen der vorliegenden Erfindung ist, die JPEG2000-Dekompression nach ISO/IEC 15444 zu beschleunigen.
Ausführungsbeispiele bieten eine Sammlung von Verfahren bzw. Konzepten zur effizienten Ausführung effizienter Decodierungsschritte auf Stream-Prozessoren. Maßgeblich für den Geschwindigkeitsgewinn bei einem hier vorgestellten JPEG2000-Decodierer, welcher einen Videodecodierer gemäß einem Ausführungsbeispiel der vorliegenden Erfindung nutzt, ist die parallele Berechnungen des Entropiedecodierungsalgorithmus EBCOT Tier-1. Hier kann durch die Verarbeitung mehrerer Bilder auf einmal zum einen die Parallelität erhöht werden und zum anderen die inhaltliche Ähnlichkeit von Codeblöcken aufeinanderfolgender Bilder ausgenutzt werden.
Ein auf GPGPU-Technologie basierender Prototyp ist mit Hilfe handelsüblicher Grafikkarten bereits in der Lage, DCI-konforme 2k-Bildsequenzen mit mehr als 24 Bildern pro Sekunde zu decodieren, was das Abspielen von digitalen Kinofilmpaketen (DCPs) in Echtzeit erlaubt.
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar.
Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein. Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahin gehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft. Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Tragen gespeichert ist.
Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahin gehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.
Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
Glossar

2K/4K

Angabe zur Bildauflüsung. 2K: bis zu 2.048 × 1.080, 4K: bis zu 4.096 × 2.160.

CUDA

Compute Unified Device Architecture. GPGPU-Technologie

DCI

Digital Cinema Initiative. Vereinigung amerikanischer Filmstudios mit dem Ziel, einen Standard für digitales Kino zu formulieren.

DCP

Digital Cinema Package. Distributionsform von digitalen Kinofilmen.

EBCOT

Embedded Block Coding with Optimized Truncation. Kontextadaptiver, binärer, arithmetischer Entropiecodierungsalgorithmus, eingesetzt in JPEG2000.

FWT

Fast Wavelet Transform. Algorithmus zur schnellen Berechnung einer Wavelet-Transformation.

GPU

Graphics Processing Unit. Prozesseinheit der Grafikkarte.

GPGPU

General Purpose Computation an GPUs. Technologie, mit der man allgemeine Aufgaben auf der GPU ausführen kann.

JPEG2000

Standard (ISO 15444) für Bildkomprimierung, herausgegeben von der Joint Photographic Experts Group.

SIMD

Single-Instruction – Multiple-Data Paradigmus.

Tile

Bild-Kachel. Im Kontext von JPEG2000 können Bilder vor der Kompression in einzelne Kacheln unterteilt werden, welche dann unabhängig voneinander encodiert werden.

Wavelet Analyse

Transformation von Zeitdarstellung in Wavelet-Darstellung.

Wavelet Synthese

Rücktransformation von Wavelet-Darstellung in Zeitdarstellung.

Claims

Videodecodierer zum Decodieren einer Sequenz von Bildern (106a–106d), von denen jedes in eine Mehrzahl von Transformationskoeffizientenblöcken (103a–103d, 108a–108d) codiert ist, wobei der Videodecodierer (100) ausgebildet ist, um Transformationskoeffizientenblöcke (103a–103d) verschiedener Bilder (106a–106d) zeitgleich auf verschiedenen Rechenkernen (104a–104d) einer ersten SIMD-Gruppe (105, 105a) zu decodieren; wobei Positionen der Transformationskoeffizientenblöcke (103a–103d) der verschiedenen Bilder (106a–106d), welche zeitgleich auf den verschiedenen Rechenkernen (104a–104d) der ersten SIMD-Gruppe (105, 105a) decodiert werden, sich räumlich (106a–106d) überlappen.
Videodecodierer gemäß einem der vorhergehenden Ansprüche, der ausgebildet ist, so dass die verschiedenen Bilder (106a–106d), deren Transformationskoeffizientenblöcke (103a–103d) zeitgleich auf den verschiedenen Rechenkernen (104a–104d) der ersten SIMD-Gruppe (105, 105a) decodiert werden, zeitlich direkt aufeinanderfolgende Bilder sind.
Videodecodierer gemäß einem der vorhergehenden Ansprüche, bei dem jedes der Bilder (106a–106d) aus der Sequenz von Bildern (106a–106d) unabhängig von einem anderen Bild (106a–106d) aus der Sequenz von Bildern (106a–106d) decodierbar ist.
Videodecodierer gemäß einem der vorhergehenden Ansprüche, der ferner eine Wavelet-Syntheseeinheit (110) aufweist, die ausgebildet ist, um die Transformationskoeffizientenblöcke (103a–103d) einer Wavelet-Synthese pro Bild (106a–106d) zu unterziehen.
Videodecodierer gemäß Anspruch 5, bei dem jeder Transformationskoeffizientenblock (103a–103d) eines Bildes (106a–106d) genau einem Frequenzband (411a–411j) der Wavelet-Synthese zugeordnet ist, wobei der Videodecodierer (100) ausgebildet ist, so dass die Transformationskoeffizientenblöcke (103a–103d) der verschiedenen Bilder (106a–106d), welche zeitgleich auf den verschiedenen Rechenkernen (104a–104d) der ersten SIMD-Gruppe (105, 105a) decodiert werden, demselben Frequenzband (411a–411j) zugeordnet sind.
Videodecodierer gemäß einem der Ansprüche 1 bis 5, bei dem ein Transformationskoeffizientenblock (103, 103a–103d) in eine Mehrzahl von Bitebenen (701–704) zerlegbar ist, wobei der Videodecodierer (100) ferner so ausgebildet ist, dass bei der zeitgleichen Decodierung der Transformationskoeffizientenblöcke (103a–103d) verschiedener Bilder (106a–106d) auf den verschiedenen Rechenkernen (104a–104d) der ersten SIMD-Gruppe (105) zeitgleich jeweils die gleiche Bitebene (701–704) der Transformationskoeffizientenblöcke (103a–103d) decodiert wird.
Videodecodierer gemäß Anspruch 6, der ausgebildet ist, um eine Bitebene (702–704) eines Transformationskoeffizientenblocks (103, 103a–103d), welche nicht eine meist signifikante Bitebene (701) des Transformationskoeffizientenblocks (103, 103a–103d) ist, unter Nutzung von drei aufeinanderfolgenden Codierdurchläufen zu decodieren; wobei der Videodecodierer (100) ferner so ausgebildet ist, dass bei der zeitgleichen Decodierung der Transformationskoeffizientenblöcke (103a–103d) auf den verschiedenen Rechenkernen (104a–104d) der ersten SIMD-Gruppe (105a) zeitgleich jeweils der gleiche Codierdurchlauf aus den drei aufeinanderfolgenden Codierdurchläufen bei der Decodierung jeweils der gleichen Bitebene (701–704) der Transformationskoeffizientenblöcke (103a–103d) benutzt wird.
Videodecodierer gemäß Anspruch 7, der ferner ausgebildet ist, um die Decodierung der Transformationskoeffizientenblöcke (103a–103d) zwischen zwei aufeinanderfolgenden Codierdurchläufen zu unterbrechen.
Videodecodierer gemäß Anspruch 7 oder 8, der ausgebildet ist, um die Decodierung der Transformationskoeffizientenblöcke (103a–103d) innerhalb eines Codierdurchlaufs zu unterbrechen.
Videodecodierer gemäß einem der Ansprüche 1 bis 9, der ausgebildet ist, um auf jedem Rechenkern (104a–104d) der verschiedenen Rechenkerne (104a–104d) der ersten SIMD-Gruppe (105, 105a) zeitgleich jeweils genau einen Transformationskoeffizientenblock (103a–103d) der verschiedenen Bilder (106a–106d) zu decodieren.
Videodecodierer gemäß einem der Ansprüche 1 bis 10, bei dem die verschiedenen Bilder (106a–106d), deren Transformationskoeffizientenblöcke (103a–103d) zeitgleich auf den verschiedenen Rechenkernen (104aa–104da) der ersten SIMD-Gruppe (105a) decodiert werden, eine erste Gruppe (107; 107a) von Bildern (106a–106d) bilden, wobei der Videodecodierer (100) ausgebildet ist, um bei der zeitgleichen Decodierung erster Transformationskoeffizientenblöcke (103a–103d) der Bilder (106a–106d) aus der ersten Gruppe (107; 107a) von Bildern (106a–106d) auf den verschiedenen Rechenkernen (104aa–104da) der ersten SIMD-Gruppe (105a) zeitgleich zweite Transformationskoeffizientenblöcke (108a–108d) der Bilder (106a–106d) aus der ersten Gruppe (107; 107a) von Bildern (106a–106d) auf verschiedenen Rechenkernen (104ab–104db) einer zweiten SIMD-Gruppe (105b) zu decodieren.
Videodecodierer gemäß Anspruch 11, der ausgebildet ist, um bei der Decodierung von Transformationskoeffizientenblöcken (103a–103d, 108a–108d) der Bilder (106a–106d) der ersten Gruppe (107a) von Bildern (106a–106d) zeitgleich Transformationskoeffizientenblöcke von Bildern (106e–106h) einer zweiten Gruppe (107b) von Bildern (106e–106h), welche disjunkt zu der ersten Gruppe (107a) von Bildern (106a–106d) ist, auf verschiedenen Rechenkernen mindestens einer weiteren SIMD-Gruppe zu decodieren.
Videodecodierer gemäß einem der Ansprüche 1 bis 12, bei dem die Sequenz von Bildern (106a–106f) in einem JPEG2000-Datenstrom codiert ist, wobei der Videodecodierer (100) ausgebildet ist, um die Transformationskoeffizientenblöcke (103a–103d) aus dem JPEG2000-Datenstrom zu extrahieren.
Verfahren zum Decodieren einer Sequenz von Bildern, von denen jedes in eine Mehrzahl von Transformationskoeffizientenblöcken codiert ist, bei dem Transformationskoeffizientenblöcke verschiedener Bilder zeitgleich auf verschiedenen Rechenkernen einer ersten SIMD-Gruppe decodiert werden; wobei Positionen der Transformationskoeffizientenblöcke der verschiedenen Bilder, welche zeitgleich auf den verschiedenen Rechenkernen der ersten SIMD-Gruppe decodiert werden, sich räumlich überlappen.
Computerprogramm mit einem Programmcode zur Durchführung des Verfahrens nach Anspruch 14, wenn das Programm auf einem Computer abläuft.