DE4441294A1 - Decoder und Verfahren zur Decodierung von codierter Bild-, Video- und Filminformation - Google Patents

Description

Die Erfindung betrifft einen Decoder und ein Verfahren zur Decodierung von codierter Bild-, Video- und Filminformation.

Technisches Gebiet

Die Übertragung von Videosignalen verlangt im Gegensatz zur Sprach- und Musikübertragung infolge der wesentlich größeren Datenmengen auch entsprechend komplexere Algorithmen, um die zu übertragende Datenmenge auf ein sinnvolles Niveau zu senken. Die Standardisierung der entsprechenden Verfahren wird von der International Standards Organisation (ISO) durchgeführt. Der MPEG-Standard (Motion Picture Experts Group) beschreibt Algorithmen zur Kompression von Bewegtbildern. Er basiert auf Algorithmen wie Quantisation (Q), Discret-Cosinus-Transform (DCT), Motion-Compensation (MC), Variable-Length- Coding (VLC) und Run-Length-Coding (RLC). Der Standard definiert einen Datenstrom, in dem die Bildinformation entsprechend einer spezifizierten Syntax codiert wird. Dafür wird ein hierarchisches Layer-Modell verwendet, das sich folgendermaßen gliedert (siehe Fig. 1):

• - Sequence Layer: oberster Level des Videodatenstroms
• - GOP Layer: eine Sequence ist in eine oder mehrere GOPs (Group of Picture) unterteilt; eine GOP setzt sich aus einer Gruppe von Einzelbildern zusammen
• - Picture Layer: beschreibt ein Einzelbild
• - Slice Layer: ein Bild wird in ein oder mehrere Slices variabler Länge unterteilt
• - Macroblock Layer: ein Block mit 16×16 Luminanz Pels und den korrespondierenden unterabgetasteten Chrominanz Pels
• - Block Layer: ein 8×8 Pel Block

Der MPEG1 Standard wurde für Daten raten von 1,5 Mbps konzipiert. Ferner wurden Bildauflösungen von ca. 350×250 Pixel und Bildwiederholfrequenzen von 25 bis 30 Hz angenommen.

Ein MPEG1 Decoder hat die Aufgabe, entsprechend den im Standard spezifizierten Decodierungs- und Dekompressionsalgorithmen aus einem eingangsseitig ankommenden MPEG1 Datenstrom am Ausgang wieder Bilddaten in einem vorher festgelegtem Format zu erzeugen.

Der unterste Layer in der Hierarchie des MPEG Datenstroms ist der Block Layer. Er beschreibt einen Block von 8×8 Pels. Die verschiedenen Prozesse im Dekompression Flow des Standards sind blockorientiert, d. h. sie werden immer auf einen Block von 8×8 Pels angewendet. Folgende Prozesse lassen sich unterscheiden:

• - DECODING: Decodierungsprozeß; aus dem Datenstrom werden alle Parameter und die blockorientierten Bildinformationen decodiert
• - IQ: inverse Quantisierung der Pels eines Blocks
• - IDCT: Anwendung der 2D-IDCT auf die Pels eines Blocks
• - FR: Frame Reconstruction; Kompensation der Bewegungs­ schätzung
• - BRC: Block-to-Raster-Conversion; Umwandlung der Bilddaten vom blockorientierten MPEG Format zum zeilenorientierten Bildformat

Fig. 2 zeigt schematisch den Flow im MPEG1 Standard. Aus dem eingangsseitig anliegenden Datenstrom werden mit Hilfe des Decodierungsprozesses (200) die komprimierten Pel-Blöcke erzeugt, aus denen das Bild aufgebaut ist. Die Art der Weiterverarbeitung des Blockes hängt von seinem Typ ab. Der Typ gibt an, mit welchen der zur Verfügung stehenden Algorithmen dieser Block komprimiert wurde. Ist der Block bewegungskompensiert und vom Typ "skipped" oder "no coded_block_pattern" wird direkt der FR Prozeß (203) ausgeführt, da keine Differenzen übertragen wurden. Ist dies nicht der Fall, werden die Pels zunächst inverse quantisiert (201) und dann mittels der 2D-IDCT (202) wieder in den Zeitbereich transformiert. Ist der Block vom Typ "intra", d. h. nicht bewegungskompensiert, so folgt als nächstes der BRC Prozeß (204). Falls Blöcke bewegungskompensiert sind, wird der FR Prozeß ausgeführt. Je nach Bildtyp ("motion_forward", "motion_backward") benötigt der FR Prozeß einen Pel Block von den Referenz Bildern im externen RAM für die Kompensation. Der dann folgende BRC Prozeß schreibt den dekomprimierten Block zeilenorientiert in den externen Speicher.

In EP 592 351 A2 ist ein Videodecoder beschrieben, bei dem die IQ und IDCT in vier Phasen durchgeführt wird. Der Decoder besitzt den Nachteil eines erhöhten Implementierungsbedarfs, da das Rechenwerk für IQ und IDCT vierfach ausgeführt werden muß.

Aufgabe der Erfindung

Die dargestellten Prozesse für die Dekompression von Videodaten nach dem MPEG1 Standard benötigen eine hohe Rechenleistung. Aufgabe der Erfindung war es daher, einen Decoder für Videosignale anzugeben, der die Dekomprimierung in Echtzeit durchführt. Gleichzeitig sollte im Hinblick auf ökonomische Gesichtspunkte eine möglichst effiziente Hardwareimplementierung der Funktionen realisiert werden.

Erfindung

Die Aufgabe wird durch einen Decoder nach Anspruch 1 gelöst. Durch die Verbindung von Concurrent Processing und Resource Sharing Techniken wurde eine optimale Implementierung in Hinblick auf Hardwareaufwand und Performance realisiert. Erfindungsgemäß werden die IQ, IDCT, FR und optional die CSC in einem Prozessor durchgeführt. Der Prozessor enthält nur einen Multiplizierer und maximal drei Addierer. Er ist mit internem Speicher verbunden, der in mehrere Speicherbänke aufgeteilt ist. Auf die Speicherbänke kann unabhängig voneinander zugegriffen werden.

Zeichnungen

Die Erfindung ist desweiteren anhand der Zeichnungen erläutert. Es zeigen:

Fig. 1 schematische Darstellung des MPEG1 Layer Modells,

Fig. 2 schematische Darstellung des Dekompressionsablaufs bei MPEG1,

Fig. 3 Systemarchitektur des MPEG1 Decoder Core,

Fig. 4 mögliche Lage eines Referenz Blocks im Referenzbild beim FR Prozeß,

Fig. 5 Speicherorganisation zum Abspeichern eines Referenzbildes,

Fig. 6 Activity Diagram für I-Picture,

Fig. 7 Activity Diagram für P,B-Picture,

Fig. 8 Activity Diagram für P,B-Picture bei bestimmten Macroblocktypen.

Globales Blockschaltbild

In Fig. 3 ist das Blockschaltbild der Systemarchitektur des Cores (300) dargestellt. Die Einzelmodule können wie folgt beschrieben werden:

System Control (301)

Der Dekomprimierungsprozeß arbeitet blockorientiert. Entsprechend dem Concurrent Processing Schema steuert (301) den Ablauf des Dekomprimierungsprozesses. Die Prozesse werden über Start-Signale und Steuercodes in den beiden Verarbeitungsmodulen (302, 303) gestartet und nach der Verarbeitung eines Pel-Blocks wird dies über ein Ready-Signal dem System Control Modul signalisiert. Der Datenaustausch zwischen den Verarbeitungseinheiten erfolgt über interne RAMs, die als Datenpuffer dienen. Neben dem Dekomprimierungsablauf sind auch Fehlerbehandlungsroutinen integriert. Über Control-Signale erfolgt die Synchronisation mit dem externen System.

Decoding (302)

Das Decoding-Modul realisiert den Decoding Prozeß vom Sequence bis zum Block Layer. Das Modul enthält den Stream-Parser, den Variable-Length- Decoder, den Run-Length-Decoder, sowie eine Motion-Vector-Reconstruction- Unit. Alle erforderlichen Parameter werden gespeichert. Das Modul benötigt Speicherzugriffe zum externen RAM, da unter anderem VLC-Tabellen im Speicher abgelegt sind.

Central Processing Module (303)

Das Central-Processing-Module ist eine Art arithmetischer Prozessor, der die Prozesse mit hoher Rechenleistung ausführt. Dabei handelt es sich um die Prozesse IQ, IDCT, FR und optional Color-Space-Conversion (CSC). Die CSC wandelt das im MPEG Standard verwendete Pixelformat YCrCb in das RGB- Format um. Der IQ und FR Prozeß können parallel ausgeführt werden.

Die Echtzeitanforderungen können bereits mit einem Multiplizierer und drei Addierern als arithmetische Einheiten realisiert werden.

Memory Interface (307)

Das Memory Interface steuert den Zugriff auf das externe RAM.

Internal 64×12 RAM (304)

Das RAM wird von 4 verschiedenen Prozessen als Speicher genutzt. Während des Decoding Prozesses werden die decodierten Frequenzkoeffizienten eines Blocks in ZigZag-Adressierung ins RAM geschrieben. Nach dem Decoding arbeitet der IQ Prozeß auf dem RAM, und speichert das Zwischen- und Endergebnis ab. Danach liest der IDCT-Prozeß das RAM wieder aus.

Falls der CSC Prozeß ebenfalls implementiert ist, nutzt er das RAM als Input-Buffer.

Internal 64×8 RAM (305)

Dieses RAM wird vom IQ Prozeß und optional wieder vom CSC Prozeß als Input-Buffer genutzt. Für den IQ Prozeß wird in dem RAM die Q-Matrix gespeichert.

Internal 64×16 RAM (306)

Dieses RAM wird von 3 verschiedenen Prozessen als Speicher für einen Block genutzt. Während der IDCT wird das Zwischen- und Endergebnis im RAM gespeichert. Danach folgt der FR Prozeß, falls erforderlich, und nutzt das RAM in der gleichen Form. Anschließend werden die Pels mittels des BRC Prozesses ins externe RAM geschrieben.

Alle internen RAMs sind "dual port" RAMs.

Q-Matrix

Bei der Q-Matrix handelt es sich um ein Array von 8×8 Quantisierungsfaktoren der Größe 8 Bit. Damit läßt sich jeder Frequenzkomponente eines Pel-Blocks während der Quantisierung ein eigener Quantisierungsfaktor zuordnen. Während der inversen Quantisierung werden die Faktoren benötigt, um die Quantisierung wieder aufzuheben. Es werden zwei Arten von Q-Matrizen unterschieden, eine für "intra" und eine für "non intra" codierte Blöcke. Für jede der beiden Matrizen sind im Standard Default-Faktoren festgelegt. Es können aber auch neue Q-Matrizen im Sequence Layer übertragen werden.

Falls Q-Matrizen im Sequence Layer übertragen werden, werden sie im externen RAM gespeichert. Dort werden bei der Initialisierung auch die Default-Faktoren abgelegt. Werden keine Q-Matrizen übertragen, werden die Standardmatrizen genutzt.

Der Macroblock Typ gibt an, ob die Blöcke im Macroblock "intra" oder "non intra" codiert sind. In Abhängigkeit vom Typ wird daher zu Beginn der Macroblock Decodierung die entsprechende Q-Matrix in das 64×8 RAM geladen. Durch dieses dynamische Nachladen der Q-Matrix ist lediglich ein 64×8 Bit RAM für die Speicherung der Q-Matrizen erforderlich.

Externes RAM

Im externen RAM werden unter anderem die Referenz-Bilder abgelegt. Die Referenz-Bilder, wobei es sich um I- und P-Pictures handelt, werden beim FR- Prozeß für die bewegungskompensierende Interpolation benötigt. Abhängig vom Blocktyp müssen dazu 1 bis 2 Referenz-Blöcke aus dem Speicher gelesen werden.

Die Lage dieser Blöcke relativ zum interpolierten Block hängt von einem Bewegungsvektor ab. Dieser ist nur in seiner Länge durch den "motion vector range" begrenzt. Die Referenz-Blöcke sind demnach nicht an Blockgrenzen gebunden, sondern ihre Lage ist beliebig. Fig. 4 stellt diesen Zusammenhang dar. Dabei ist 400 ein Teil eines Referenz Bildes und 401 ein beliebiger Referenz Block, der zur Interpolation gelesen werden muß.

Die Referenz-Bilder müssen so im Speicher abgelegt werden, daß die freie Speicherbandbreite möglichst effektiv genutzt wird. Das bedeutet, daß beim Schreiben und Lesen des Speichers möglichst wenig Page-Breaks auftreten. Der Aufbau eines Bildes im MPEG1 Datenstrom ist Macroblock orientiert, d. h. das Bild wird von links oben nach rechts unten Macroblockzeile für Macroblockzeile decodiert. Würde man das Bild auch in dieser Form Macroblock für Macroblock im Speicher ablegen, so kann beim Lesen eines Referenz Blocks eine große Anzahl von Page-Breaks auftreten, insbesondere bei einer Lage des Referenz Blocks wie in Fig. 4 dargestellt.

Daher ist es sinnvoll, daß Referenz Bild Zeile für Zeile abzuspeichern. Das bedeutet, daß auf die Blöcke nach der Dekompression direkt der BRC Prozeß ausgeführt wird. Der BRC Prozeß sorgt dafür, daß die Zeilen des Blocks so im externen RAM gespeichert werden, daß das Bild Zeile für Zeile in einem linearen Adressraum abgelegt ist. In Fig. 5 ist die Lage eines Bildes im Speicher dargestellt. Der Speicher wird in drei Sektoren eingeteilt. Die Sektoren haben einen linearen Adreßraum. In einem Sektor werden die Luminanz Werte (500) und in den beiden anderen die Chrominanz Werte Cr (501) und Cb (502) abgespeichert. Die Grenzen der Sektoren (503 . . 506) liegen auf Page-Grenzen. Innerhalb der Sektoren werden die jeweiligen Pels Zeile für Zeile gespeichert.

Diese Speicheranordnung hat zwei Vorteile. Zum einen wird der BRC Prozeß direkt nach der Dekompression ausgeführt und die Bilder liegen zeilenorientiert im Speicher vor. Zum anderen wird die Zahl der Page-Breaks minimiert und damit die effektiv nutzbare Speicherbandbreite erhöht.

Concurrent Processing Schema

Die bei der Dekompression auf die Blöcke angewendeten Prozesse brauchen unterschiedliche Ausführungszeiten. Dabei können auch Zeitunterschiede bei gleichen Prozessen auftreten. Die Unterschiede sind bedingt durch den Aufbau und die Form des gerade decodierten MPEG Datenstroms, sowie durch unterschiedliche Speicherzugriffszeiten.

Die Variationen in den Prozeßzeiten führt zu einer asynchronen Organisation des Dekomprimierungsablaufs. Das System muß in der Lage sein, die unterschiedlichen Prozeßzeiten im Mittel wieder auszugleichen. Falls Prozesse also weniger als die mittlere Prozeßzeit benötigen muß diese Zeit dazu verwendet werden, Prozesse mit längeren Prozeßzeiten auszugleichen. Durch diese Flexibilität ist man in der Lage, eine sehr effiziente Implementierung des Decoders zu realisieren.

Durch Concurrent Processing wird ein optimaler Prozeß-Schedule implementiert. Der Prozeß-Schedule berücksichtigt dabei gleichzeitig die Möglichkeiten des Resource-Sharing von Untermodulen für die unterschiedlichen Prozesse. Dadurch wurde eine in Bezug auf Hardwareaufwand und Performance optimale Implementierung erreicht.

Für den Prozeß-Schedule gelten folgende Regeln:

• - DECODING, FR, BRC und CSC brauchen Zugriffe auf das externe RAM und können nicht zur gleichen Zeit ausgeführt werden
• - FR und IQ können parallel auf 303 laufen
• - IDCT und CSC können nur allein auf 303 ausgeführt werden
• - DECODING und IQ können nicht gemeinsam das 64×12 RAM (304) nutzen
• - DECODING und IDCT können das 64×12 RAM (304) gemeinsam nutzen wenn sichergestellt ist, das der Schreibvorgang von DECODING den Lesevorgang von IDCT nicht einholen kann; beide Zugriffe erfolgen linear und starten bei Adresse 0
• - IDCT und FR können nicht gemeinsam auf das 64×16 RAM (306) zugreifen
• - BRC und IDCT können das 64×16 RAM (304) gemeinsam nutzen wenn sichergestellt ist, das der Schreibvorgang von IDCT den Lesevorgang von BRC nicht einholen kann; beide Zugriffe erfolgen linear und starten bei Adresse 0.

Basierend auf dem Blockdiagramm von Fig. 3 wird das Concurrent Processing Schema anhand von Activity Diagrammen erläutert. Die Activity Diagrams beschreiben den Prozeß-Schedule und die Startzeiten der verschiedenen Prozesse. Der Prozeßtyp ist an der linken Seite des Diagramms aufgelistet. Jeder Prozeß hat eine Zeitachse, auf der die aktive Zeit des Prozesse anhand eines Balkens dargestellt ist. Die Zahl über den Balken gibt an, welcher Block des gerade dekomprimierten Macroblocks durch den Prozeß bearbeitet wird (siehe Fig. 1 für die Zuordnung der Blocknummern).

Der CSC Prozeß ist in die Diagramme integriert. Falls die Konvertierung nicht erforderlich ist, kann der Prozeß weggelassen werden.

I-Picture

Fig. 6 zeigt das Activity Diagram zur Dekompression von I-Pictures. Die Initphase und der normale Run sind dargestellt.

In I-Pictures werden alle Blöcke übertragen. Bei einem I-Picture ist keine Bewegungskompensation erforderlich und folglich wird der FR Prozeß nicht benötigt.

Die Dekompression eines Bildes startet mit dem DECODING Prozeß. Die verschiedenen Layer werden decodiert und die erforderlichen Parameter abgespeichert. Beim Start des Macroblock Layer Decoding signalisiert 302 dem System Control Modul (301) durch ein Ready-Signal, daß der nächste Prozeß starten kann. In diesem speziellen Fall wird der Prozeß in 302 nicht gestoppt. Er läuft weiter und versucht, alle "macroblock_stuffing" und "macroblock_escape" zu decodieren. Dies ist möglich, weil die Decodierung dieser Codewörter keinen Speicherzugriff benötigt. Wenn alle "macroblock_stuffing" und "macrnblock_escape" decodiert sind, wird ein weiteres Ready-Signal generiert. Der Grund für diese Vorgehensweise liegt darin, daß "macroblock_stuffings" redundante Informationen sind. Sie können in den Datenstrom eingesetzt werden, um eine konstante Datenrate zu sichern. Die Zahl der "macroblock_stuffings" ist dabei nicht begrenzt. Durch diese Vorgehensweise kann ein anderer Prozeß parallel zur Decodierung der beiden Codewörter gestartet werden.

Nach dem ersten Ready-Signal von 302 wird der CSC Prozeß gestartet. Der CSC Prozeß arbeitet nicht auf Block sondern auf Macroblockebene. Die Pels werden konvertiert und zum Output-Interface geschrieben. Der Prozeß wird mit 303 ausgeführt. Die Luminanz-Pels werden aus dem externen RAM in 305 eingelesen und die Chrominanz-Pels in das 304. Sie werden im Verlauf des Prozesse immer wieder dynamisch nachgeladen. Nach Beendigung des CSC Prozesses und wenn der Decoding Prozeß sein zweites Ready-Signal generiert hat, wird der Decoding Prozeß erneut gestartet und stoppt wieder sobald das "coded_block_pattern" Codewort decodiert ist. Dann startet der MATRIX_LOAD Prozeß. Dieser Prozeß lädt in Abhängigkeit vom Macroblock Typ die benötigte Q- Matrix aus dem externen RAM in 305. Danach wird wieder der Decoding Prozeß in 302 gestartet und der erste decodierte Block in das 64×12 RAM (304) geschrieben. Der Decoding Prozeß schreibt in das RAM in ZigZag-Ordnung. Dann startet der IQ Prozeß auf 303. Die Ergebnisse werden in 304 gespeichert. Als nächstes wird dann die 2D-IDCT auf 303 gestartet. Der Prozeß ist in zwei 1D- IDCTs separiert. Sie werden nacheinander gestartet. Die Ergebnisse werden in 306 gespeichert. Die erste 1D-IDCT verarbeitet die Blockspalten, die zweite die Blockzeilen. Nachdem die erste 1D-IDCT fertig ist, kann in 302 die Decodierung des zweiten Blocks des Macroblocks gestartet werden (Block Nummer 1). Die Pels werden wieder ins freie 304 geschrieben. Wenn die zweite 1D-IDCT fertig ist stehen die Ergebnisse in 306 (Marke: ).

Zu diesem Zeitpunkt ist der erste Block dekomprimiert. Als nächstes wird der BRC Prozeß gestartet, der den Block über 307 ins externe RAM schreibt. I- Pictures sind Referenzbilder und werden im externen RAM gespeichert. Wenn BRC auf Block0 gestartet wird, wird zur gleichen Zeit auch IQ auf Block1 gestartet. Der Prozeß-Schedule geht dann entsprechend dem Diagramm weiter, bis der nächste Macroblock decodiert wird. An dieser Stelle stoppt der Decoding Prozeß wieder, um danach "macroblock_stuffings" und "macroblock_escapes" zu decodieren während der CSC Prozeß läuft.

An diesem Punkt kann die aktuelle Q-Matrix in 305 vom CSC Prozeß überschrieben werden, da die Matrix in Abhängigkeit vom Macroblocktyp durch MATRIX_LOAD neu geladen wird. Desweiteren kann 304 vom CSC benutzt werden, weil die erste 1D-IDCT, die Daten aus dem RAM benötigt, beendet ist.

Dieser Prozeß-Schedule wird wiederholt, bis das Bild decodiert ist.

P.B-Picture

Fig. 7 und Fig. 8 zeigen die Activity Diagramme für P,B-Pictures. Diese Bildtypen sind bewegungskompensiert. Deshalb ist der FR Prozeß bei diesen Bildern aktiv. Die Bilder können durch eine Anzahl unterschiedlicher Macroblocktypen beschrieben werden. Für P-Pictures lassen sich folgende Typen unterscheiden:

• - intra coded
• - forward motion compensated
• - verschiedene coded_block_pattern (cbp) Kombinationen
• - skipped Macroblocks oder cbp = 0

B-Pictures können zusätzlich noch "backward motion compensated" sein. Falls ein Macroblock "forward motion compensated" und "backward motion compensated" ist, benötigt FR die doppelte Prozeßzeit, da die Interpolation mit zwei Referenzblöcken erfolgen muß. Alle unterschiedlichen Macroblocktypen benötigen unterschiedliche Prozeß-Schedules.

Fig. 7 zeigt die Initphase und den normal Run. Zu Beginn ist der Prozeß- Schedule wie bei I-Pictures (bis zu Marke siehe I-Picture Beschreibung). Ist ein Macroblock "intra coded" ist der folgende Prozeß-Schedule bis zum nächstem Macroblock identisch mit dem vom I-Picture. Ist der Macroblock bewegungskompensiert, startet der FR Prozeß von Block0 zusammen mit dem IQ Prozeß von Block1 auf 303. Die Prozeßzeit vom IQ ist fest, und die Prozeßzeit von FR ist variable.

Wenn FR früher als IQ fertig ist, kann der BRC Prozeß von Block0 gestartet werden. Die erste 1D-IDCT von Block1 kann nach Beendigung von IQ auf 303 gestartet werden. Der Decoding Prozeß von Block2 kann gestartet werden, nachdem ein spezielles Ready-Signal von der 1D-IDCT generiert wurde.

Wenn IQ früher als FR fertig ist, müssen alle Prozesse auf FR warten. Erst wenn FR beendet ist, kann BRC auf Block0 und 1D-IDCT auf Block1 gestartet werden. Wenn BRC fertig ist, kann der Decoding Prozeß von Block2 gestartet werden.

Wenn die erste 1D-IDCT fertig ist, kann die zweite gestartet werden. Wenn der Decoding Prozeß von Block2 und die 1D-IDCT von Block1 beendet sind startet der Prozeß-Schedule von neuem.

Die Activity Diagramme in Fig. 8 zeigen zwei spezielle Fälle. Das obere Diagramm zeigt den Prozeß-Schedule für einen speziellen Wert von "cbp". Wenn ein Block ohne Differenzwerte komprimiert wurde (coded_block_pattern(i) = 0), dann muß der IQ und IDCT Prozeß auf diese Blöcke nicht angewendet werden.

Das andere Diagramm zeigt den Prozeß-Schedule, wenn "cbp" gleich null ist oder ein "skipped" Macroblock vorliegt.

Bezugszeichenliste

Claims (20)

1. Decoder für codierte Bild-, Video- und Filminformation mit einer Steuerleitung, Zugriff auf externen Speicher, einem Rechenwerk zur Decodierung (302), internen Speicherbausteinen (304-306) und einem Rechenwerk zur Durchführung von digitalen Bildsignalverarbeitungsprozessen (303), dadurch gekennzeichnet, daß das Rechenwerk (303) zur Durchführung der Prozesse für die inverse Quantisierung (IQ), für die inverse diskrete Cosinustransformation (IDCT), für die Frame-Reconstruction (FR) und optional für die Color-Space- Conversion (CSC) ausgeprägt ist.

2. Decoder nach Anspruch 1, dadurch gekennzeichnet, daß das Rechenwerk (303) nur einen Multiplizierer beinhaltet, der Multiplizierer über Selektoren mit den Speicherbausteinen verbunden ist und Daten aus den Speicherbausteinen mittels Steuer- und Adressleitungen an den Selektoren und Speichern beliebig miteinander multiplizierbar sind.

3. Decoder nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das Rechenwerk (303) maximal drei Addierer beinhaltet, die Addierer über Selektoren mit Speicherbausteinen und einem Multiplizierer verbunden ist und Daten aus den Speicherbausteinen mittels Steuer- und Adressleitungen an den Selektoren und Speichern beliebig miteinander addierbar sind.

4. Decoder nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der interne Speicher durch mehrere Speicherbänke mit unabhängig voneinander durchführbaren Zugriff ausbildet ist und die Speicher mit Rechenwerken und über ein Interface (307) mit externem Speicher verbunden sind.

5. Decoder nach Anspruch 4 mit internem Speicher, dadurch gekennzeichnet, daß der Speicher in drei Speicherbänke aufgeteilt ist, eine erste Speicherbank (304) die minimale Größe von 64×12 Byte aufweist und mit dem Rechenwerk zur Decodierung (302) verbunden ist, eine zweite Speicherbank (305) die minimale Größe von 64×8 Byte aufweist und zur Speicherung von den Matrizen verwendet wird und eine dritte Speicherbank (306) die minimale Größe von 64×16 Byte aufweist.

6. Decoder nach einem der vorhergehenden Ansprüche, gekennzeichnet durch ein zentrales Steuerwerk (301) für das Rechenwerk zur Decodierung (302), für das Rechenwerk zur Durchführung digitaler Bildsignalverarbeitungsprozesse (303) und für das Interface zu externem Speicher.

7. Decoder nach Anspruch 6 mit einem zentralen Steuerwerk (301), gekennzeichnet durch eine Schnittstelle zu externen Steuer- und Kontrollsignalen.

8. Decoder nach einem der vorhergehenden Ansprüche, gekennzeichnet durch lokale Prozeßfeuerwerke für die Rechenwerke und Verbindung der Steuerwerke über Prozeßzustandsleitungen miteinander.

9. Decoder nach einem der vorhergehenden Ansprüche, gekennzeichnet durch ein Rechenwerk zur Codierung von Systemstatus und Fehlermeldungssignalen.

10. Decoder nach Anspruch 8, gekennzeichnet durch eine Verbindungsleitung für die codierten Signale zu dem umgebenden System.

11. Decoder nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß er monolithisch integriert ausgeführt ist.

12. Verfahren zur Decodierung codierter Bild-, Video- und Filminformation, dadurch gekennzeichnet, daß Prozesse für die inverse Quantisierung (IQ), für die inverse diskrete Cosinustransformation (IDCT), für die Frame- Reconstruction (FR) und optional für die Color-Space-Conversion (CSC) sequentiell in einem gemeinsamen Rechenwerk (303) durchgeführt werden und das Rechenwerk (303) zur parallelen Ausführung von Prozessen für die IQ und die FR ausgeprägt ist.

13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß interne Speicherbänke von den Prozessen wechselnd genutzt werden und die konvertierten Bilddaten über die Speicherbänke zwischen den Decoderprozessen ausgetauscht werden.

14. Verfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, daß die zu decodierenden Bildsignale aus einer externen Quelle direkt in das Rechenwerk zur Decodierung (302) geführt werden.

15. Verfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, daß die zu decodierenden Bildsignale aus externem Speicher über eine Schnittstelle (307) zu dem Rechenwerk zur Decodierung (302) geführt werden.

16. Verfahren nach Anspruch 11 bis 14 oder 15, dadurch gekennzeichnet, daß mindestens zwei vollständige Bilder und zwei Quantisierungsmatrizen und optional eine Festwertmatrix in einem externen Speicher abgelegt wird und Teile der Daten dynamisch über eine Schnittstelle in den internen Speicher geladen werden.

17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, daß jede Bildkomponente in einem separaten Sektor des Speichers abgelegt und die Bildelemente zeilenweise organisiert werden.

18. Verfahren nach Anspruch 17, dadurch gekennzeichnet, daß die Sektorgrenzen mit den Pagegrenzen des Speichers übereinstimmen.

19. Verfahren nach einem der Ansprüche 12 bis 18, dadurch gekennzeichnet, daß die Decodierung des aktuellen Blocks parallel zur Durchführung der zweiten Stufe der IDCT des vorhergehenden Blockes erfolgt, anschließend die Block-To-Raster-Conversion des vorhergehenden gleichzeitig mit der IQ des aktuellen Blocks durchgeführt wird und danach die erste Stufe der IDCT separat ausgeführt wird.

20. Verfahren nach Anspruch 19, dadurch gekennzeichnet, daß der CSC- Prozeß zu dem Zeitpunkt durchgeführt wird, an dem keine Speicher- und Rechenoperationen für die IDCT ausgeführt werden.