DE19756210A1

DE19756210A1 - Verfahren und Vorrichtung zum Decodieren eines codierten MPEG-Videodatenstroms

Info

Publication number: DE19756210A1
Application number: DE19756210A
Authority: DE
Inventors: Hemant Bheda; Sanjay Gongalore; Partha Srinivasan
Original assignee: National Semiconductor Corp
Current assignee: National Semiconductor Corp
Priority date: 1997-06-17
Filing date: 1997-12-17
Publication date: 1998-12-24
Anticipated expiration: 2017-12-18
Also published as: US5990958A; KR19990006296A; DE19756210C2; KR100298533B1

Description

Die Erfindung betrifft die Video-Dekompression und speziel ler eine neue Vorrichtung und ein Verfahren zum Durchführen einer MPEG-Video-Decodierung unter optimaler Ausnutzung des verfügbaren Systemspeichers und der Rechenresourcen.

Das CCITT/ISO-Komitee (CCITT = Comité Consultatif Interna tional Télégraphique et Téléphonique = Internationales Be ratungsorgan der Postgesellschaften für den Fernmeldebe reich; ISO = International Standard Organisation = Inter nationales Normungsinstitut) hat eine Gruppe von Kompres sions- und Dekompressionsalgorithmen für stillstehende und bewegte digitale Videosignale normiert. Diese Normen umfas sen die Kompressionsverfahren JPEG, MPEG und H.261. Diese Normen werden verbreitet bei Videokonferenzen, CD-ROM oder DVD-ROM-gestützten interaktiven Videos für die Erziehung und Unterhaltung, Video- oder Informationskiosks, Video auf-Anforderung-Anwendungen (VOD-Anwendungen; VOD = video on demand), Satelliten-Videoübertragungsanwendungen und für viele andere Anwendungen genutzt, welche die Übertra gung bewegter digitaler Bilder erfordern. Diese Normen ver wenden mittels Transformationscodes komprimierte Formate, einschließlich der diskreten Cosinustransformation (DCT) und eines Zwischenbild-Prädiktionscode-Formats (interframe predictive code format). Bewegungsausgleichs-Algorithmen (MC-Algorithmen; MC = motion compensation) werden in Ver bindung mit dem DCT-Format und anderen hybriden komprimier ten Formaten verwendet.

Die MPEG-Norm wurde von der Moving Picture Coding Experts Group (MPEG) entworfen, die innerhalb des Rahmenwerks des Joint ISO/IEC Technical Committee (JCCI) on Information Technology arbeitet. Der Entwurf sieht eine Norm für die kodierte Darstellung von bewegten Bildern, Ton und deren Kombination vor.

Fig. 1 zeigt ein Blockdiagramm eines üblichen Rechnersy stems des Standes der Technik, das sich für die Decodierung von MPEG-Videodaten eignet. Das Rechnersystem 10 umfaßt übliche Systemkomponenten, wie einen Systembus 11, eine CPU 12, eine Kernlogik 13, einen Systemspeicher 14 und eine Festplatte 16. Das Rechnersystem 10 umfaßt auch mehrere Elemente, die sich speziell für Videofunktionen eignen, einschließlich eines DVD-ROM-Laufwerks 15, das CD-ROM oder DVD-ROM liest, eines MPEG-Decoders 17 und seines zugehöri gen lokalen DRAM-Speichers 17A, einer 2D/3D-Graphiksteuer einrichtung und ihres zugehörigen lokalen Einzelbildpuffers DRAM 18A. Falls erwünscht, umfaßt das Rechnersystem 10 auch eine Fernsehschnittstelle 19 zum Abspielen eines Videos auf einem Fernsehgerät und einen RGB-Ausgangsbus 20 zum Vorse hen von Videoausgangssignalen für einen Monitor. Diese Vi deoausgangssignale auf dem Bus 20 sind entweder MPEG-Daten ströme von dem DVD-ROM-Laufwerk 15 oder übliche Computer graphik, die von der Graphiksteuereinrichtung 18 erzeugt wird, oder beides. Die Graphiksteuereinrichtung 18 sieht auch eine 2D/3D-Graphikfunktion sowie eine Videoskalierung und eine Farbraum-Konvertierung vor. Zusätzlich sieht die Graphiksteuereinrichtung 18 über den Bus 20 eine Schnitt stelle zu einem RGB-Monitor oder einem Fernsehgerät vor, um Videodaten von dem Rechnersystem 10 anzuzeigen.

In Fig. 1 führt der Decoder 17 eine Dekompression/Decodie rung des MPEG-Videodatenstroms vor, so daß das Rechnersy stem 10 Multimedia-Anwendungen unter Verwendung der Video kompressionsnormen MPEG 1 oder MPEG 2 abspielen kann. Die MpEG-Videodecodierungsoperation umfaßt die folgenden Auf gaben (tasks): Parsing (Syntaxanalyse) des komprimierten Videostroms mittels variabler Längendecodierung (VLD), in verse Quantisierung (IQ), inverse diskrete Cosinustransfor mation (IDCT), Bewegungskompensation (MC) und Blockrekon struktion (BR). Da die Videodecodierungsoperation rechen intensive Signalverarbeitungsoperationen mit sich bringt, ist die in dem MPEG-Decoder 17 vorhandene Hardwarelogik komplex und demzufolge teuer. Ein weiterer Nachteil des Aufbaus des Standes der Technik besteht darin, daß der MPEG-Decoder 17 Rechen- und Speicherresourcen nicht nutzt, die von den Systemkomponenten vorgesehen werden, wie der CPU 12, dem Systemspeicher 14 oder der Graphiksteuerein richtung und ihrem zugehörigen Speicher 18a. Dies führt zu einer ineffizienten Nutzung der verfügbaren Systemresour cen.

Im Hinblick auf diesen Stand der Technik ist es eine Auf gabe der vorliegenden Erfindung, eine Vorrichtung und ein Verfahren zum Ausführen einer MPEG-Videodekompression auf effiziente Weise vorzusehen. Es ist auch eine Aufgabe der vorliegenden Erfindung, eine Videodekompressionseinrichtung und ein Verfahren vorzusehen, die nicht nur eine effiziente MPEG-Videodecodierung durchführen sondern die auch in Bezug auf die Architektur einfacher und billiger sind als Video decoder des Standes der Technik. Es ist eine weitere Auf gabe der vorliegenden Erfindung, eine Vorrichtung und ein Verfahren zum Ausführen einer Videodecodierung vorzusehen, welche die Ausnutzung der Systemresourcen, einschließlich der Rechen- und Speicher-Systemresourcen, optimieren.

Die vorliegende Erfindung erreicht diese Ziele und Aufgaben mit einer neuen Einrichtung und einem Verfahren, welche die MPEG-Videodekodieraufgaben in Softwareaufgaben, die von einer CPU ausgeführt werden, und Hardwareaufgaben, die von einer hierfür vorgesehenen Videohardware ausgeführt werden, aufteilen. Die Softwareaufgaben entsprechen den Aufgaben, die keine umfassenden Speicher- oder Rechenresourcen benö tigen. Andererseits werden solche Aufgaben, die rechen- und speicherintensive Operationen mit sich bringen, als Hardwa re realisiert.

Die Softwareaufgaben verarbeiten den eingehenden kodierten MPEG-Videodatenstrom vor und schreiben die vorverarbeitete Information für jedes Einzelbild oder Vollbild (frame) in einen Symbolstrom, der im Systemspeicher gespeichert wird. Eine spezielle (dedicated) Videohardware gewinnt die Daten des Symbolstroms aus dem Systemspeicher wieder und vervoll ständigt die Verarbeitung des Videobildes. Die Synchroni sierung zwischen den von der CPU ausgeführten Softwareauf gaben und den mit der speziellen Videohardware realisierten Hardwareaufgaben wird mithilfe verschiedener Datenstruktu ren, mittels von der Software verwalteten Steuerstrukturen und mit Gerätetreibern erreicht, die der speziellen Video hardware zugeordnet sind.

Die Erfindung ist im folgenden anhand bevorzugter Ausfüh rungsformen mit Bezug auf die Zeichnungen näher erläutert. In den Figuren zeigt:

Fig. 1 ein Blockdiagramm eines üblichen Rechensy stems des Standes der Technik, das sich zum Dekodieren von MPEG-Videodaten eignet;

Fig. 2 zeigt ein Blockdiagramm einer Ausführungs form der vorliegenden Erfindung, die sich zum Dekodieren von MPEG-Videodaten eignet;

Fig. 3 zeigt ein Blockdiagramm, das die Aufgaben umreißt, die bei der Decodierung eines kom primierten MPEG-Datenstroms auftreten;

Fig. 4 gibt eine Technik zum Aufteilen der Videode kodieraufgaben zwischen der Software, die auf der CPU läuft, und der speziellen Video hardware wieder;

Fig. 5 gibt eine alternative Technik zum Aufteilen der Videodekodieraufgaben zwischen der Soft ware, die auf der CPU läuft, und der spe ziellen Videohardware wieder;

Fig. 6 zeigt eine Ausführungsform der vorliegenden Erfindung, wobei die Datenstrukturen und Software/Hardware-Komponenten abgebildet sind, die zum Koordinieren der Kommunikation zwischen der speziellen Videohardware und der Software notwendig sind, um die MPEG-Videodecodierung durchzuführen;

Fig. 7 zeigt eine Ausführungsform der vorliegenden Erfindung, bei der ein Aufgabenzeiger-FIFO von der speziellen Videohardware bedient wird;

Fig. 8a zeigt ein Flußdiagramm der verschiedenen Softwaretransaktionen, die bei der Decodie rung und Anzeige von MPEG-Videodaten auftre ten;

Fig. 8b zeigt ein Flußdiagramm der Abfolge der Ope rationen, die von der Aufgabensteuerung der speziellen Videohardware ausgeführt werden;

Fig. 9 zeigt die Struktur einer Ausführungsform des Bildpuffers zum Speichern von vier Vollbil dern für eine PAL/NTSC-Bildauflösung;

Fig. 10 zeigt eine Ausführungsform der Bildpuffer struktur zum Speichern von 3,5 Vollbildern für die PAL/NTSC-Bildauflösung gemäß der Lehre der vorliegenden Erfindung;

Fig. 11 zeigt ein Bildpuffer-Speicherschema zum De kodieren von PAL-Bildern mit nur 2 MB RAM;

Fig. 12 zeigt ein anderes Bildpuffer-Speicherschema zum Dekodieren von PAL-Bildern mit nur 2 MB RAM;

Fig. 13 zeigt eine Ausführungsform der vorliegenden Erfindung, bei der die spezielle Videohard ware ein Teil der Graphiksteuereinrichtung ist;

Fig. 14 zeigt ein Daten-Flußdiagramm für die von der Hardware ausgeführten Dekodier-Operationen;

Fig. 15 zeigt Luminanzblock-Operationen, die von einer Ausführungsform der vorliegenden Er findung ausgeführt werden;

Fig. 16 zeigt Luminanzblock-Operationen, die von einer Ausführungsform der vorliegenden Er findung ausgeführt werden; und

Fig. 17 zeigt ein alternatives Datenablauf-Diagramm der von der Hardware ausgeführten Dekodier operationen.

Die vorliegende Erfindung lehrt eine neue Video-Dekompres sions-Architektur und ein Verfahren, die eine kostengünsti ge Realisierung eines Systems zum Abspielen von komprimier ten Videos ermöglichen. Die vorliegende Erfindung sieht eine effiziente und kostengünstige Architektur und ein Ver fahren zum Abspielen von Videodatenströmen der Normen MPEG 1 und MPEG 2 in einem Multimedia-Rechnersystem vor, das DVD (digital versatile disk), DVB (digital versatile band), Video-CD und anderen Anwendungen unterstützt, welche die MPEG-Videokompressionsnorm verwenden.

Fig. 2 ist ein Blockdiagramm einer Ausführungsform eines Rechnersystems, das gemäß den Lehren der vorliegenden Er findung aufgebaut ist. Anders als das Videodekodiersystem des Standes der Technik, das in Fig. 1 gezeigt ist, und einen speziellen MPEG-Decoder 17 verwendet, wird bei der vorliegenden Erfindung die Videodekodier-Aufgabe, die bis her von dem MPEG-Decoder 17 durchgeführt wurde, in eine Softwareaufgabe 112a, die auf der CPU 112 läuft, und eine Aufgabe, die von einer neuen speziellen Videohardware 118b ausgeführt wird, aufgeteilt. Bei einer Ausführungsform ist die spezielle Videohardware 118b, wie in Fig. 2 gezeigt, in eine Graphiksteuereinrichtung 118 eingebettet.

Die neue Architektur und das Verfahren gemäß der Erfindung bieten mehrere Vorteile und Verbesserungen im Vergleich zu den Videodecodern des Standes der Technik. Da die Dekodier aufgabe teilweise durch die Software 112a realisiert wird, die auf der CPU 112 läuft, reduziert sich die Komplexität der speziellen Videohardware 118b erheblich, die zum Vollenden der Videodekodieraufgabe notwendig ist. Die redu zierte Komplexität führt zu einer kleineren physischen Grö ße der Decoderhardware, wodurch Raum und Kosten gespart werden.

Wenn gewünscht, kann die spezielle Videohardware 118b in der Graphiksteuereinrichtung 118 eingebettet werden, wie in Fig. 1 gezeigt, wodurch sich in erheblichem Umfang der Platzbedarf für die integrierte Schaltung verringert. Diese Konfiguration ermöglicht auch einen effizienten Einsatz der vorhandenen Systemressourcen, weil die Videodekodierhardwa re die Speicher-Steuereinrichtung und die PCI-Busschnitt stellen mit dem Graphiksteuerchip 118 gemeinsam benutzt. Anders als bei den Systemen des Standes der Technik, bei denen der MPEG-Decoder 17 seinen eigenen reservierten lo kalen Speicher 17A zum Dekodieren von Videobildern benö tigt, wird ferner bei der vorliegenden Erfindung kein zu sätzlicher Speicher benötigt, weil der zum Dekodieren der Videobilder notwendige Speicher zugleich der Bildpuffer 118a der Graphiksteuereinrichtung ist. Dies führt direkt zu Kosteneinsparungen und resultiert in einer effizienteren Ausnutzung der vorhandenen Speicherresourcen, wodurch sich die Komplexität und die Kosten des Gesamtsystems senken. Ferner führt die Aufteilung der Dekodieraufgabe zwischen der CPU 112 und der speziellen Videohardware 118b zu einer effizienten Nutzung vorhandener Rechenresourcen des Systems.

Aufteilung der Dekodieraufgabe zwischen Hardware und Soft ware

Fig. 3 zeigt die verschiedenen Aufgaben, die bei der Deco dierung eines komprimierten MPEG-Signaldatenstrom beteiligt sind. Der eingehende komprimierte MPEG-Datenstrom besteht aus einer Videokomponente und einer Audiokomponente. Der gemultiplexte Datenstrom wird zunächst in seine Audio- und seine Video-Datenstromkomponente zerlegt, wie durch den Block 130 in Fig. 3 gezeigt. Der Audio-Datenstrom wird dann einer Tondecodierung unterzogen (Block 132) und dann an eine Tonwiedergabe-Soundkarte (Block 134) für die Wieder gabe weitergeleitet. Mit dem Video-Datenstrom wird eine Bilddecodierung durchgeführt (Block 136), und er wird dann an eine Videowiedergabe-Anzeigevorrichtung (Block 138) für die Wiedergabe weitergeleitet. Die Videodecodierung (Block 136) umfaßt die folgenden Aufgaben: Parsing (Syntaxanalyse) des komprimierten Stromes durch variable Längendecodie rung (VLD), Ausführen einer inversen Quantisierung (IQ), Ausführen einer inversen diskreten Cosinustransformation (IDCT), Ausführen einer Bewegungskompensation (MC) und Blo ckrekonstruktion (BR).

Gemäß der vorliegenden Erfindung besteht der erste Schritt zur Aufteilung der Videodecodierung zwischen den Software aufgaben und den von der neuen speziellen Hardware 118b ausgeführten Aufgabe darin, Aufgaben zu identifizieren, welche rechenintensive und speicherintensive Operationen benötigen, sowie Aufgaben, die keine rechenintensiven oder speicherintensiven Operationen benötigen. Die Videodeko dieraufgaben, die keine intensiven Speicher- oder Rechen operationen benötigen, werden von der Software ausgeführt, die auf der CPU 112 läuft, während rechen/speicherintensive Aufgabe der speziellen Videohardware 118b zur Ausführung zugewiesen werden. Die Aufteilung der Videodecodierung in Software- und Hardwareaufgaben ist somit abhängig von der Leistungsfähigkeit der CPU 112, der Bandbreite des System speichers 14 und der verfügbaren Bandbreite auf dem System bus 11, der z. B. ein PCI- oder ein AGP-Bus ist.

Die Fig. 4 und 5 zeigen zwei mögliche Ausführungsformen für die Aufteilung, basierend auf der CPU-Leistung. Bei der in Fig. 4 abgebildeten Ausführungsform umfassen die von der CPU 112 ausgeführten Softwareaufgaben das Parsing des kom primierten Videodatenstroms mittels variabler Längendeco dierung (VLD), die Durchführung der inversen Quantisierung der dekodierten Koeffizienten (IQ) und die Durchführung der inversen diskreten Cosinustransformation (IDCT) . Die spei cherintensiven Aufgaben des Bewegungsausgleichs (MC) und der Block- oder Bildrekonstruktion (BR) werden von der spe ziellen Videohardware 118b ausgeführt.

Bei der in Fig. 5 gezeigten Ausführungsform wird jedoch die Durchführung der inversen diskreten Cosinustransformation (IDCT) als eine rechen-/speicherintensive Aufgabe klassifi ziert und daher in der speziellen Videohardware 118b ausge führt. Wie oben gesagt, hängt die Aufteilung einer speziel len Videodekodieroperation in eine Softwareaufgabe oder eine Hardwareaufgabe von verschiedenen Faktoren ab, wie der Leistungsfähigkeit der CPU 112, der Bandbreite des System speichers 14 und der verfügbaren Bandbreite auf dem System bus 11. Demzufolge kann bei einer speziellen Ausführungs form, wie in Fig. 5 gezeigt, die Ausführung der inversen diskreten Cosinustransformation (IDCT) als eine rechen-/speicher intensive Aufgabe klassifiziert werden, so daß sie von der speziellen Videohardware 118b ausgeführt wird.

Die in Fig. 4 gezeigte Ausführungsform führt zu einer stär keren Nutzung der CPU als die Ausführungsform der Fig. 5. Andererseits ist die Ausführungsform der Fig. 5 günstiger für Systeme, die eine geringere Rechenbelastung der CPU bevorzugen. Für den Fachmann sollte klar sein, daß die Auf teilung der Videodekodieraufgabe in Software- und Hardware aufgaben nach Bedarfzugeschnitten werden kann, um sie an die Rechen- und Speichervermögen eines speziellen Rechner systems anzupassen.

Bei einer Ausführungsform verarbeiten die Softwareaufgaben, die auf der CPU 112 laufen, den komprimierten Videodaten strom bildweise. Die CPU 112 verarbeitet jedes Vollbild teilweise und formatiert die teilweise verarbeiteten Ein zelbilddaten als eine Gruppe von Symbolen fester Länge, die "Symbolstrom" genannt wird. Der Symbolstrom wird in einem Puffer in dem Systemspeicher 14 (s. Fig. 2) gespeichert, wo die spezielle Videohardware 11Bb für die weitere Verarbei tung auf ihn zugreifen kann. Während die CPU 112 das näch ste vorhandene Videobild verarbeitet, greift die spezielle Videohardware 118b in einen Bus-Mastermodus (ohne Interven tion der CPU) auf den Systemspeicher 14 zu, um den für das zuvor verarbeitete Bild gespeicherten Symbolstrom abzuru fen. Die spezielle Videohardware 118b interpretiert den von der CPU 112 erzeugten Symbolstrom und berechnet das deko dierte Videobild.

Wie oben beschrieben, greift die spezielle Videohardware 118b auf den Systemspeicher 14 über den Bus 11 nur zum Wie dergewinnen der Symbolstrominformation zu, die von der CPU 112 in dem Puffer des Systemspeichers gespeichert wurde. Alle nachfolgenden Speicherzugriffe, die für die Bewegungs kompensation (MC) benötigt werden, welche von der speziel len Videohardware 118 ausgeführt werden, werden auf den Einzelbildpuffer 118a gemacht, der dezentral für die spe zielle Videohardware 118b vorhanden ist. Die Aufteilung oder Partitionierung gemäß der vorliegenden Erfindung redu ziert somit nicht nur die Rechenbelastung der CPU 112, son dern sie senkt auch in erheblichem Umfang die Bandbreite der Verwendung des Systemspeichers 14.

Die Synchronisierung zwischen den Decodieraufgaben der Hardware und der Software wird mit Hilfe einer Datenstruk tur erreicht, die von der Software zusammengestellt (assem bliert) und in den Systemspeicher 14 geschrieben wird. Nach der Verarbeitung eines Videobildes bereitet die Software, welche auf der CPU 112 läuft, eine Datenstruktur vor, die Information speichert, welche das teilweise verarbeitete Videobild betrifft. Ein Zeiger zu dieser Datenstruktur wird in ein Aufgabenzeiger-FIFO geschrieben. Das Aufgabenzeiger- FIFO, das entweder in der speziellen Videohardware 118b oder im Systemspeicher 14 liegt, bewahrt einen Überblick über die Videobilder, die von der CPU 112 teilweise verar beitet wurden und die für das Decodieren durch die speziel le Videohardware 118b bereit sind. Die auf der CPU 112 lau fende Software fährt dann mit der Verarbeitung des nächsten Videobildes fort. Die spezielle Videohardware 118b durch läuft das Aufgabenzeiger-FIFO und gewinnt den Symbolstrom für das teilweise verarbeitete Videobild wieder, ohne daß die CPU hieran irgendwie beteiligt wäre. Die spezielle Vi deohardware 118b schließt dann die Decodierung des teilwei se verarbeiteten Videobildes ab. Wenn die spezielle Video hardware 118b die Decodierung und das Anzeigen des Bildes beendet, das ein Vollbild (frame) oder ein Satz aus Halb bildern (field) sein kann, sendet sie eine Unterbrechung (Interrupt) zu der CPU 112. Die Software, welche auf der CPU 112 läuft, verwendet diese Unterbrechung zum Aktuali sieren der momentanen Aufgabeneinträge in dem Aufgabenzei ger-FIFO, und sie macht auch eine Aufzeichnung des zuletzt angezeigten Bildes. Im folgenden ist die Kommunikation zwi schen der Software und der Hardware mit weiteren Einzelhei ten beschrieben.

Kommunikation zwischen der Software und der speziellen Vi deohardware

Wie bereits kurz erläutert wurde, verarbeitet die auf der CPU 112 laufende Software den eingehenden komprimierten MPEG-Videostrom und schreibt den teilweise verarbeiteten Symbolstrom in den Systemspeicher 14. Die spezielle Video hardware 118b greift dann auf den Symbolstrom zu, um den Decodierprozeß abzuschließen. Fig. 6 zeigt eine Ausfüh rungsform der Datenstrukturen und der Software/Hardware- Komponenten, die für die Koordinierung der Kommunikation zwischen der speziellen Videohardware 118b und der auf der CPU 112 laufenden Software notwendig ist, um die MPEG-Vi deodecodierung durchzuführen. Wie bei der in Fig. 6 gezeig ten Ausführungsform, umfassen die Hauptkomponenten die auf der CPU 112 laufende Software, die Software-Client 140 ge nannt wird, die spezielle Videohardware 118b und eine Hard ware-Abstraktionsschicht (HAL = Hardware Abstraction Layer) 142, die als ein Gerätetreiber für die spezielle Videohard ware 118b dient und auf der CPU 112 läuft.

Der Software-Client 140 entspricht der auf der CPU 112 lau fenden Software und ist verantwortlich für die teilweise Decodierung des eingehenden MPEG-Videodatenstroms. Wie be reits beschrieben, führt der Software-Client 140 bei einer Ausführungsform (die in Fig. 5 gezeigt ist) das Parsing (Syntaxanalyse) des komprimierten Videobitstroms und andere Videodecodieraufgaben durch, wie die variable Längendeco dierung (VLD) und die inverse Quantisierung (IQ), während bei einer anderen Ausführungsform der Software-Client auch die inverse diskrete Cosinustransformation (IDCT) durch führt (siehe Fig. 4). Nach der teilweisen Verarbeitung des aktuellen Videobildes formatiert der Software-Client 140 die teilweise verarbeiteten Daten in der Form eines Symbol stroms 144a, 144b. Bei einer Ausführungsform weist die HAL 142 den notwendigen Pufferbereich zu, der zum Speichern des Symbolstroms im Systemspeicher 14 benötigt wird. Der Sym bolstrom wird in den zugewiesenen Pufferbereich, im System speicher 14 in die Puffer 114a, 144b geschrieben. Der Soft ware-Client 140 schreibt auch Steuerinformation für die An zeige- und Decodieraufgaben in ein Softwareaufgabendefini tions-Paket (STDP = Software Task Definition Packet). Das STDP wird in Puffern 146a, 146b gespeichert, die von der HAL 142 in dem Systemspeicher 14 zugewiesen wurden. Die spezielle Videohardware 118b verwendet den Symbolstrom zu sammen mit der in dem STDP gespeicherten Steuerinformation zum Vervollständigen der Decodierung und Anzeige des MPEG-Videobildes. Bei einer Ausführungsform spezifiziert das STDP Quell- und Zielpufferindizes, Anzeigepufferindizes, die Anzeigedauer und die VSYNC-Polarität für Zeilensprung- Anzeigeeinrichtung. Ein virtueller Adressenzeiger zu dem Symbolstrom und die Länge des Symbolstrompuffers werden ebenfalls in das STDP geschrieben. IDCT- und Bewegungsvek torinformation wird in dem Symbolstrom gespeichert. Es ist zu beachten, daß auch andere, für den Fachmann offensicht liche Umsetzungen im Bereich der Erfindung liegen.

Die HAL 142 dient als ein Gerätetreiber für die spezielle Videohardware 118b. Die HAL 142 empfängt Anzeige- und Deco dieraufgaben, die zeitlich von dem Software-Client 140 or ganisiert werden, und macht diese für die Ausführung durch die spezielle Videohardware 118b verfügbar. Die von der HAL 142 ausgeführten Aufgaben umfassen das Vorsehen eines tem porären Speicherbereichs 148 für den Software-Client 140, das Betreiben eines Aufgaben-FIFO und das Vorsehen von Sei tentabellen für die physische Adressenabbildung der Symbol strompuffer. Die HAL 142 verfolgt auch die vollständige Ausführung bzw. Fertigstellung der Aufgaben, die durch eine Unterbrechung signalisiert wird, die von der speziellen Videohardware 118b erzeugt wird. Zusätzlich konvertiert die HAL 142 das in dem Systemspeicher 14 gespeicherte STDP in ein Hardwareaufgaben-Definitionspaket (HTDP = Hardware Task Definition Packet) abhängig von der spezifischen Hardware konfiguration des speziellen Systems. Bei einer Ausfüh rungsform wird die Umwandlung von dem STDP in das HTDP wäh rend der "Freigabe" -Operation durchgeführt.

Die HAL 142 verwendet die "Erfassungs"- und "Freigabe"- Funktionsaufrufe zum Koordinieren ihrer Aktivitäten mit dem Software-Client 140. Bei einem "Erfassungs"-Funktionsaufruf weist die HAL 142 den Speicherpuffer für das STDP zu und gibt einen Zeiger (LPDataPtr) 150 zu dem STDP an den Soft ware-Client 140 zurück. Der Software-Client 140 führt eine Vorverarbeitung des komprimierten MPEG-Videodatenstroms durch und füllt das STDP-Datenpaket. Bei Beendigung der Vorverarbeitungsaufgabe wird die "Freigabe"-Funktion aufge rufen. Wenn die "Freigabe"-Funktion aufgerufen wird, über setzt die HAL 142 die STDP- in eine HTDP-Struktur und ak tualisiert den Zählwert des Aufgaben-FIFO.

Die HAL 142 weist einen Speicher für eine Warteschlange-Da tenstruktur zu und wartet die Warteschlange-Datenstruktur, die Aufgaben-FIFO 150 genannt wird. Die HAL 142 erzeugt das Aufgaben-FIFO 150 während der Initialisierungsphase. Anders als das STDP ist das Aufgaben-FIFO 150 eine statische Da tenstruktur, und bei einer Ausführungsform ist es 4 KB lang und beginnt bei einer Seitengrenze. Bei einer Ausführungs form ist das von der HAL 142 erzeugte Aufgaben-FIFO 150 wenigstens acht Einträge tief. Jeder Eintrag des Aufgaben- FIFO 150 enthält ein HDTP 154, das von der HAL 142 aufge baut wird. Wie bereits beschrieben, leitet die HAL 142 das HTDP 154 aus der Information ab, die von dem Software-Cli ent 140 in dem STDP geliefert wird. Die HAL 142 fügt Ein träge zum Aufgaben-FIFO 150 hinzu ("push"), wenn der Soft ware-Client 140 einen "Freigabe"-Funktionsaufruf ausgibt. Die HAL 142 entfernt ("pop") Einträge aus dem Aufgaben-FIFO 150, wenn die spezielle Videohardware 118b eine Aufgaben ende-Unterbrechung signalisiert. Zwischen den von dem Soft ware-Client 140 ausgeführten Aufgaben und der Anzahl der Einträge in dem Aufgaben-FIFO 150 besteht eine Eins-zu-Eins- Entsprechung. Wenn keine Eins-zu-Eins-Entsprechung beibe halten wird, ist die HAL 142 dafür verantwortlich, die Be endigung einer von dem Software-Client 140 programmierten Aufgabe präzise zu verfolgen. Die Anzahl der Einträge in dem Aufgaben-FIFO 150 gibt die Anzahl der von dem Software- Client 140 ausgegebenen Aufgaben wieder, welche von der speziellen Videohardware 118b ausgeführt werden sollen.

Wie oben gesagt, ist die HAL 142 für die Verarbeitung der STDPs verantwortlich, um HTDPs 154 zu erzeugen, welche in das Aufgaben-FIFO 150 eingegeben werden. Die HAL 142 ordnet Steuerdaten in dem HTDP 154 an, so daß sie direkt in die Register der speziellen Videohardware 118b geladen werden können. Die HAL 142 erzeugt auch Seitentabellen für die physische Abbildung des Symbolstrompuffers, und schreibt Zeiger, die zu den Seitentabellen weisen, in die HTDPs. Die HAL 142 benachrichtigt die spezielle Videohardware 118b darüber, daß eine neue Aufgabe ansteht, indem sie den Index des HTDP 154 in das Aufgabenzeiger-FIFO 156 schreibt, das von der speziellen Videohardware 118b gewartet wird oder in dem Systemspeicher 14 gespeichert ist.

Die HAL 142 bestimmt auch gestützt auf die Größe des Bild puffers 118a (siehe Fig. 2) das geeignete Decodier-Spei cherschema. Die HAL 142 ist dafür verantwortlich, gestützt auf die MPEG-Strom-Bildrate und die Anzeigeeinrichtung die richtige Bildrate und Anzeigerate zu ermitteln und die zeitliche Abfolge der Anzeigeaufgabe, einschließlich der Bildwiederholung, festzulegen, um eine gleichmäßige Anzeige bei dem zweifachen oder dreifachen der MPEG-Bildrate zu ermöglichen. Die HAL 142 überwacht auch die Aufgabenende- Unterbrechung von der speziellen Videohardware 118b, und sie empfängt den entsprechenden Eintrag aus dem Aufgaben- FIFO 150.

Die Aufgabendatenstruktur ist eine Datenstruktur umfassend das HTDP 154 und den Symbolstrom 144a, 144b. Sie repräsen tiert die Informationseinheit, die für jede auszuführende Aufgabe in die spezielle Videohardware 118b geladen wird. Das HTDP 154 ist abhängig von der Hardwarerealisierung, und bei einer Ausführungsform ist es 4 DWORDS (32 Byte) lang. Das HTDP 154 enthält Information, die für die Codier- und Anzeigeaufgaben benötigt und in die Register der speziellen Videohardware 118b geladen wird. Wie bereits beschrieben, analysiert die HAL 142 die Information in dem STDP und schreibt das HTDP 154 während des "Freigabe"-Funktionsauf ruf s in das Aufgaben-FIFO 150.

Wie bereits beschrieben, enthält der Symbolstrom 144a, 144b teilweise decodierte MPEG-Videodaten. Der Software-Client 140 schreibt in den Symbolstrompuffer, während er den ein gehenden Videodatenstrom analysiert. Ein Zeiger zu diesem Puffer und die Pufferlänge werden von dem Software-Client nach einem "Erfassungs"-Funktionsaufruf in das STDP ge schrieben. Die HAL 142 erzeugt eine Seitentabelle für den Symbolstrompuffer während des "Freigabe"-Funktionsaufrufs, um die physische Adressenabbildung vorzusehen. Die Basis adresse dieser Seitentabelle wird von der HAL 142 in das HTDP 154 geschrieben und von der speziellen Videohardware 118b geladen, wenn sie die Aufgabe verarbeitet.

Das Aufgabenzeiger-FIFO 156 liegt in der speziellen Video hardware 118b oder im Systemspeicher 14. Bei der in Fig. 7 gezeigten Ausführungsform wird das Aufgabenzeiger-FIFO 156 von der speziellen Videohardware 118b gewartet. Jeder gül tige Eintrag in dem Aufgabenzeiger-FIFO 156 ist ein Index zu einer Aufgabe in dem Aufgaben-FIFO 150, das von der HAL 142 gewartet wird. Bei einer Ausführungsform ist das Aufga benzeiger-FIFO 156 3 Bit breit und wenigstens acht Einträge tief. Die von der speziellen Videohardware 118b verarbeite ten Aufgaben umfassen Nur-Anzeige- und Decodier- und Anzei ge-Aufgaben. Diese Information wird in den Programmierpara metern gespeichert, die in dem HTDP 154 enthalten sind. Diese Programmierparameter umfassen einen Decodieraufgaben typ, einen Anzeigeaufgabentyp, einen Anzeigepufferindex, Vollbild/Halbbild-Anzeigedauer, etc. Wenn die "Decodier"-Aufgabe spezifiziert ist, liest die Hardware 118b in einem Bus-Master-Modus den Symbolstrom aus dem Systemspeicher 14, interpretiert die Befehle und rekonstruiert die decodierten Einzelbilder in dem lokalen Bildspeicher 118a. Die speziel le Videohardware 118b zeigt die Beendigung einer Bilddeco dierung und -anzeige an, indem sie eine Aufgabenende-Unter brechung erzeugt. Die HAL 142 umfaßt diese Unterbrechung und verwendet sie zum Überwachen des Bildes, das momentan angezeigt wird, und der Anzahl der anhängigen Aufgaben.

Während die spezielle Videohardware 118b die aktuelle Auf gabe verarbeitet, bereitet die CPU 112 die nächste Aufgabe vor, die ansteht, wenn ein Eintrag im Aufgaben-FIFO 150 verfügbar ist. Die spezielle Videohardware 118b wartet auch Status- und Steuerregister, um dem Benutzer eine bessere Kontrolle des Software-Hardware-Übertragungsprotokolls zu ermöglichen.

Transaktionen für Anzeige- und Decodieraufgaben

Fig. 8a gibt die verschiedenen Schritte wieder, die von dem Software-Client 140 und von der HAL 142 durchgeführt wer den, um eine Anzeige/Decodieraufgabe gemäß einer Ausfüh rungsform der vorliegenden Erfindung auszuführen. Wie in Fig. 8a gezeigt, ist der erste Schritt der Initialisie rungsschritt, der durch den Kasten 164 wiedergegeben wird. Bei der Initialisierung erzeugt die HAL 142 eine spezielle Identifikationszahl, die anzeigt, daß es sich um eine Bewe gungsausgleichs-Operation handelt. Bei einer Ausführungs form ist diese Identifikationszahl eine Codeidentifikation "MMMC". Der Software-Client 140 prüft dieses Feld, um zu ermitteln, ob in dem Rechnersystem 140 eine spezielle Vi deohardware 118b vorhanden ist. Als nächstes weist die HAL 142 einen 4KB Systemspeicherpuffer zu, um das Aufgaben-FIFO 150 zu erzeugen. Bei einer Ausführungsform beginnt das Auf gaben-FIFO 150 bei einer 4K Grenze. Die HAL 142 program miert auch reservierte Videohardwareregister mit aufgaben bezogenen Parametern, die sich zum Beispiel auf ein Deco dier-Speicherschema, die Anzeigerate für das MPEG-Bild und die Interruptsteuerung beziehen. Die Startadresse des Auf gaben-FIFO 150 und die Größe jedes Eintrags in Byte wird in das Aufgaben-FIFO-Basisadressenregister in der speziellen Videohardware 118b geschrieben. Die HAL 142 ruft auch ge eignete Betriebssystemsfunktionen 158 auf, um die Erneue rungsrate (Refresh-Rate) für die Anzeigeeinrichtung einzu stellen. Inzwischen schreibt der Software-Client 140 Infor mation bezüglich der Decodier- und Anzeigeaufgaben. Diese Information enthält die decodierte Bildrate, das Format der Zwischenblock-IDCT und der Bewegungsvektordaten und Inter ruptsteuerungsparameter.

Nach der erfolgreichen Initialisierung gibt der Software- Client 140 eine "Erfassung"-Anforderung an die HAL 142 aus (die durch den Kasten 166 in Fig. 8a dargestellt ist). Die "Erfassungs"-Anforderung gelingt, wenn das STDP-FIFO einen oder mehrere freie Einträge hat. Wenn die "Erfassung" ge lingt, erzeugt die HAL 142 einen temporären Speicherpuffer (148 in Fig. 6) für das STDP und gibt einen Zeiger "LPDataPtr" zu diesem Puffer zurück. Die HAL 142 schreibt auch in ein "FIFO-Einträge"-Feld, um die Anzahl der Aufga ben zu spezifizieren, die in dem Aufgaben-FIFO 150 anhängig sind. Wenn die "Erfassung"-Funktion erfolgreich ausgeführt wurde, schreibt der Software-Client 140 die Anzahl der Auf gaben in das "Aufgaben-Zahl"-Feld in den STDPs im temporä ren Speicherpuffer 148, auf den der "LPDataPtr" 152 zeigt. Jedes STDP hat auch einen Zeiger auf die virtuelle Start adresse des Symbolstrompuffers. Bei einer Ausführungsform wird der Symbolstrompuffer am Anfang von der HAL 142 zuge wiesen, wobei in diesem Fall der Zeiger zu dem Symbolstrom puffer in das STDP geschrieben wird.

Der Kasten 168 in Fig. 8a gibt die "Software-Client-Freiga be"-Operation wieder. Der Software-Client 140 ruft die "Freigabe"-Funktion nach der Codierung der nächsten Aufgabe in dem STDP auf und bereitet den Symbolstrom vor. Nach dem Aufruf der "Freigabe"-Funktion konvertiert die HAL 142 die STDP-Steuerinformation in ein HTDP 154, das ein geeignetes hardwarelesbares Format hat. Die HAL 142 erzeugt auch Sei tentabellen für die physische Adressenabbildung des Symbol strompuffers, wobei der virtuelle Adressenzeiger und die Pufferlängeninformation in dem STDP verwendet werden. Die HAL 142 schreibt einen Zeiger in diese Seitentabelle in dem Seitentabellenzeiger-Register in der speziellen Videohard ware 118b. Die HAL 142 benachrichtigt dann die spezielle Videohardware 118b, daß eine neue Aufgabe vorhanden ist, indem sie den Index der Aufgabe in den nächsten verfügbaren Eintrag des Aufgabenzeiger-FIFO 156 schreibt.

Der Block 170 in Fig. 8a gibt den Aufgabenende-Benachrich tigungsschritt wieder. Bei erfolgreicher Beendigung einer Decodier- und Anzeigeaufgabe gibt die spezielle Videohard ware 118b abhängig von der Einstellung für die Unterbre chungssteuerung in dem Steuerregister eine Unterbrechung aus. Die HAL 142, die als ein Interrupt-Steuerblock dient, entfernt die entsprechenden Einträge in dem Aufgaben-Hea der-FIFO 150 und aktualisiert die Anzahl der Einträge in dem Aufgaben-FIFO 150, um die richtige Anzahl der anstehen den Aufgaben wiederzugeben. Dieser Schritt repräsentiert die erfolgreiche Beendigung einer gegebenen Decodier- und Anzeigeaufgabe.

Aufgaben-Steuerung für die spezielle Videohardware

Fig. 8b zeigt den Ablauf der Operationen, die von der Auf gabensteuerung der Hardware 118b ausgeführt werden. Wie in Fig. 8b gezeigt, wartet in einem Schritt 172 die Aufgaben steuerung auf die Beendigung der momentanen Aufgabe und prüft dann, ob eine ausführbare neue Aufgabe vorhanden ist, um den nächsten VSYNC zu starten. Eine "neue Aufgabe" ist vorhanden, wenn das von der speziellen Videohardware 118b gewartete Aufgabenzeiger-FIFO 156 nicht leer ist. Wenn eine neue Aufgabe vorhanden ist, rechnet die spezielle Video hardware 118b im Schritt 174 die Startadresse des nächsten HTDP und lädt das HTDP. Die folgende Gleichung wird zum Berechnen der Startadresse des nächsten HTDP verwendet:
Nächste HTDP-Startadresse = HTDB-Basis-Adresse + (nächster Aufgabenzählerwert×HTDP-Größe).

Als nächstes, im Schritt 176, ermittelt die spezielle Vi deohardware 118b, ob die neue Aufgabe "ausführbar" ist, eine Aufgabe ist ausführbar, wenn die nächste VSYNC-Polari tät mit der Anfangs-VSYNC-Polarität der Aufgabe überein stimmt. Wenn die Aufgabe ausführbar ist, fährt die Aufga bensteuerung mit dem Schritt 180 fort, sonst geht sie zum Schritt 178 und wartet auf den nächsten VSYNC, um die Auf gabe zu starten.

Im Schritt 180 startet die Aufgabensteuerung die Anzeige- und/oder Decodieraufgaben. Die auszuführende Aufgabe wird durch Programmieren der Register der speziellen Videohard ware 118b mit Hilfe der Information von dem HTDP zeitlich organisiert. Wenn Decodieren spezifiziert ist, wird der Zeiger zu der Symbolstrompuffer-Seitentabelle in das Sei tentabellenzeiger-Register geladen. Der aktuelle Eintrag aus dem Aufgabenzeiger-FIFO wird entfernt (pop). In den Schritten 182 und 184 wartet die Aufgabensteuerung auf die Beendigung der planmäßigen Aufgabe, d. h. darauf, daß die Anzahl der VSYNC gleich der (Anzeigedauer des ersten Halb bildes + der Anzeigedauer des zweiten Halbbildes - 1) ist. Die Aufgabensteuerung geht dann zum Schritt 172 zurück.

Die spezielle Videohardware 118b wiederholt die Anzeige des letzten Vollbildes oder Halbbildes, wenn für das nächste Zeitintervall keine Anzeige definiert ist - entweder weil die letzte Decodieraufgabe nicht abgeschlossen ist oder weil die nächste Aufgabe von der Software noch nicht pro grammiert wurde.

Symbolstromsyntax

Die Symbolstromdaten geben Videodaten wieder, welche von der Software vorverarbeitet wurden, und die für die weitere Decodierung an die spezielle Videohardware 118b übergeben werden können. Die Syntax für eine Ausführungsform des Sym bolstroms ist im folgenden beschrieben (bei der beschriebe nen Ausführungsform ist jedes Datenelement ein 16-Bit- Wort):

Symbolstrom, der bereit ist für die Bewegungskompensation und Blockrekonstruktion in der speziel len Videohardware (entsprechend der in Fig. 4 gezeigten Ausführungsform)

Symbolstrom, der für die IDCT, Bewegungskompensation und Blockrekonstruktion in der speziel len Hardware bereit ist (entsprechend der in Fig. 5 gezeigten Ausführungsform)

Tabelle 1 gibt eine Beschreibung der verschiedenen Symbole an, die in dem obigen Symbolstromformat gemäß einer Ausfüh rungsform der Erfindung verwendet werden. Ein "W" in der Tabelle 2 gibt ein 16-Bit-Wort an.

Symbolbeschreibungstabelle

Um das "Packen" der quantisierten Koeffizienten in ein 16-Bit-Wort zu vereinfachen, wird eine Lauflänge von Null mit 4 Bits codiert. Da der MPEG2-Strom Lauflängen von bis zu 63 spezifizieren kann, erfordert dieser Ansatz, Lauflängen, die größer als 15 Nullen sind, in mehrere Worte aufzuteilen; manchmal führt dies dazu, daß ein Koeffizient den Wert 0 hat. Eine Folge aus 35 Nullen gefolgt von einem Koeffizient 27 wird zum Beispiel wie folgt codiert: (15 : 0), (15 : 0), (5 : 27); wobei die erste Zahl in jedem Paar die ZLEN ist, und die zweite Zahl ist COEFF. Alle Bits, die nicht spezifiziert oder als "reserviert" markiert sind, sollten als 0 gelesen und geschrieben werden. ID CT-TYPE gibt drei verschiedene Arten der Formatierungen der IDCT-Daten an. Diese umfassen: 16 Bit mit Vorzeichen; 9 Bit mit Vorzeichen und gepackt; und Daten, die zu 8 Bit mit Vorzeichen und gepackt konvertiert sind.

Synchronisierung der Audio- und Video-Decodieraufgaben

Die auf der CPU 112 laufende Software ist verantwortlich für die Aufrechterhaltung der Synchronisierung zwischen den Vi deo- und Audio-Komponenten des MPEG-Videodatenstroms. Wenn das Bild dem Ton vorausläuft, verzögert die Software die Ausgabe von Aufgaben an die spezielle Videohardware 118b; wenn das Bild dem Ton nacheilt, überspringt die Software die B-Bilddecodierung.

Die spezielle Videohardware 118b ist auf das Anzeigen nur der Bilder beschränkt, die vollständig decodiert wurden. Dieses Decodieren-vor-dem-Anzeigen-Verfahren gewährleistet, daß Unterbrechungen während der Datenübertragung auf dem Systembus 11 nicht zu einer Beeinträchtigung der Bilder füh ren, die auf dem Bildschirm angezeigt werden (abreißen).

Die Decodieren-vor-dem-Anzeigen-Beschränkung erfordert vier Bildspeicherungen im Speicher 118a, so daß die Decodierung eines B-Bildes erfolgen kann, während das vorherige B-Bild auf dem Bildschirm angezeigt wird. Normalerweise erfordert dies einen Speicher von 2,5 Megabyte für YUV 4 : 2 : 0 PAL-Bil der (576 Zeilen). Optimierungen gemäß der Lehre der vorlie genden Erfindung ermöglichen jedoch eine MPEG2-Videodekom pression mit nur 2 Megabyte RAM. Dies wird durch Speichern von zwei Referenz-Vollbildern (I/P) und drei B-Halbbildern im Bildpuffer 118a erreicht, wie unten beschrieben ist. Bei der vorliegenden Erfindung können Bilder mit NTSC-Auflösung (480 Zeilen) von der speziellen Videohardware 118b mit zwei Megabyte RAM vollständig gespeichert werden. Dies führt zu einem gewissen Verlust der Auflösung oder einer Fensterbil dung bei PAL-Bildern wegen der physischen Speicherbegren zung, die Auswirkung auf die Videobildqualität ist jedoch minimal.

Bildpuffer-Datenorganisation

Wie zuvor erwähnt, kann die vorliegende Erfindung sowohl MPEG1 als auch MPEG2 Videos decodieren. Gemäß einer Ausfüh rungsform dieser Erfindung wird die MPEG2-Videodecodierung mit 2 Megabyte RAM erreicht, anstelle der 2,5 Megabyte, wel che die üblichen Techniken benötigen, indem eine neuartige Ausnutzung des verfügbaren Speicherplatzes erfolgt. Dieser Abschnitt erläutert die Datenorganisation in dem Bildpuffer 118a für Bilder mit NTSC-und PAL-Auflösung mit 2 Megabyte oder weniger Speicherplatz.

Im Idealfall erfordert das Decodieren-vor-dem-Anzeigen-Ver fahren wenigstens vier Vollbildspeicherungen im Bildpuffer 118a. Das Speichern von vier Vollbildern erfordert ungefähr 2,5 Megabyte RAM für Bilder mit PAL-Auflösung und etwa 2 Megabyte RAM für Bilder mit NTSC-Auflösung. Zusätzliche 53 KB Speicherplatz werden benötigt, um die Sub-Bildmerkmale zu unterstützen, die in der industriell üblichen DVD-Spezifika tion beschrieben sind. Die Tabellen 2 und 3 beschreiben die Speicheranforderungen für Bilder mit NTSC- und bzw. PAL-Auf lösung, und die Datenorganisation in dem Bildpuffer 118a für vier gespeicherte Bilder ist in Fig. 9 gezeigt.

Vier Vollbild-Speicherungen - NTSC-Bilder

Vier Vollbild-Speicherungen - PAL-Bilder

Wenn der Bildpuffer 118a nicht alle vier Vollbild-Speiche rungen unterbringen kann, wird die MPEG2-Decodierung mit zwei Referenz-Bildern (I/P) und drei B-Halbbildern, d. h. 3,5 Vollbild-Speicherungen im Bildpuffer 118a durchgeführt. Von den drei B-Halbbildern wird eines der Anzeige zugeordnet, während die anderen beiden der Decodierung zugewiesen werden können, so daß sichergestellt ist, daß kein "Zerreißen" der Bilder entsteht. Dies ist in Tabelle 4, Tabelle 5 und Fig. 10 gezeigt.

3,5 Vollbild-Speicherungen - PAL-Bilder

3,5 Vollbild-Speicherungen - NTSC-Bilder

Für das PAL-Format ist die zum Speichern von 3,5 Vollbildern benötigte Speichergröße größer als die 2 Megabyte Kapazität des Bildpuffers 118a. Da viele Grafikkarten mit nur 2 Mega byte RAM in den Handel kommen, sieht die spezielle Vi deohardware 118b ein Speicherverfahren zum Decodieren von PAL-Bildern mit nur 2 Megabyte RAM wie folgt vor:
Verfahren 1: Das Speichern von B-Halbbildern mit halber ho rizontaler Auflösung (HHR = Horizontal Half Resolution) für Chrominanzkomponenten. Cb- und Cr-Komponenten werden in der horizontalen Richtung mit einem Faktor 2 unterabgetastet, wie in Fig. 11 und Tabelle 6 (unten) gezeigt.

3,5 Vollbildspeicherungen - PAL-Bilder; HHR B-Halbbilder

Verfahren 2: Wie in Fig. 12 und Tabelle 7 (unten) gezeigt, Speichern von B-Halbbild-Fenstern, wobei jedes Fenster eine Auflösung von 720×240 hat, d. h. 48 Zeilen pro Halbbild werden fallengelassen. Eine Unterabtastung der Chrominanz daten ist nicht nötig.

3,5 Vollbildspeicherungen - PAL-Bilder; Fensterbildung für B-Halbbilder

Bei allen der obigen Ausführungsformen werden die Referenz- Vollbilder (I/P) immer mit ihrer vollen Auflösung (720×576 für PAL und 720×480 für NTSC) in einem verschachtelten (interlaced) oder Zeilensprungformat gespeichert. Ferner wird bei allen Ausführungsformen eine konstante Schrittweite (Trennung zwischen vertikal benachbarten Pixeln) beibehal ten. Die oben erläuterten Verfahren 1 und 2 müssen in Ver bindung mit einem Lesen-vor-dem-Schreiben-Verriegelungsme chanismus (rbw = read before write) eingesetzt werden, weil während der Decodierung aufeinanderfolgender B-Vollbilder derselbe Speicherbereich simultan für das Anzeigen/Lesen des vorhergehenden Vollbildes und das Decodieren/Schreiben des aktuellen Vollbildes verwendet wird. Bei den HHR B-Halbbil dern (Verfahren 1) wird zum Beispiel das erste B-Vollbild B1 in HF0 (oberes Feld), HF1 (unteres Feld) geschrieben. Das folgende B-Vollbild B2 wird in HF0 (unteres Feld), HF2 (obe res Feld) geschrieben. Das Decodieren/Schreiben des unteren Teils von B2 in HF0 sollte gegenüber dem Anzeigen/Lesen des oberen Bl aus HF0 (Verfahren 2) verzögert sein.

Tabelle 8 zeigt, wie die Software das richtige Speicherver fahren gestützt auf die Größe des verfügbaren RAM auf der Grafikkarte, die Auflösung (NTSC/PAL) und andere zu unter stützende Merkmale, wie DVD-Unterbilder, auswählt.

Decodier-Speicher-Verfahren-Auawahltabelle

Zeitliche Organisation der Anzeige/Decodierung

Dieser Abschnitt erörtert, wie die Decodier- und Anzeigeauf gaben gemäß der vorliegenden Erfindung organisiert werden. Diese Information wird in dem HTDP 154 spezifiziert, das einen Teil der Aufgabendatenstruktur bildet.

HTDP-Zusammenfassung

Tabelle 9 faßt den Inhalt des HTDP 154 zusammen.

Zusammenfassung des HTDP-Inhalts

Im Fall des 3,5 Puffermodus spezifiziert das HTDP auch "Le sen-vor-dem-Schreiben" - oder "Schreiben-vor-dem-Lesen" -Ver riegelungen, falls anwendbar.

Um eine durchgängig gute Videoqualität zu gewährleisten, werden bei einer Ausführungsform die VGA-Erneuerungsraten (refresh rate) auf ein ganzzahliges Vielfaches der MPEG2- Vollbildraten beschränkt. Tabelle 10 zeigt die Anzeigeraten- Auswahltabelle.

Anzeigeraten-Auswahltabelle

Beachte: Bei der Ausführungsform der Tabelle 9 beträgt die Anzeigerate immer 2x oder 3x die MPEG-Vollbildrate für eine PC-VGA-Anzeige; 60 Hz für eine NTSC-TV-Anzeige; und 50 Hz für eine PAL-TV-Anzeige.

Beschränkungen

Dem Decodierprozeß werden folgende Beschränkungen auferlegt, um die Qualität der Videowiedergabe sicherzustellen und ein Decodierverfahren mit 2 Megabyte Speicher zu realisieren:

1. Die Decodierung eines Vollbildes muß beendet sein, bevor die Anzeige dieses Vollbildes beginnen kann. Dies stellt sicher, daß kein "Abreißen" des Videobil des entsteht.
2. Wenn ein oberes und ein unteres Halbbild ungleich lan ge angezeigt werden, sollte das zweite Halbbild länger angezeigt werden. Wenn z. B. ein oberes und ein unteres Halbbild während insgesamt 3 VSYNCs angezeigt werden sollen, wird zuerst das obere Halbbild angezeigt, und die Anzeige des oberen Halbbildes wird dann für einen VSYNC ausgelegt, die des unteren Halbbildes für 2 VSYNCs. Dies gewährleistet, daß der Speicher schneller für die nächste Decodieraufgabe freigemacht wird, wäh rend aneinander angrenzende B-Vollbilder mit einer Speicherung von 3,5 Vollbildern im Bildpuffer deco diert werden.
3. Aufgaben werden synchron für die Anzeige zusammenge stellt, d. h. eine Aufgabe wird immer bei einem VSYNC gestartet. Dies trägt dazu bei "abreißende" Gebilde während der Videoanzeige zu verhindern.
4. In der folgenden Erörterung bezeichnet ein Zeitab schnitt eine Erneuerungsperiode (Refresh-Periode), d. h. die Zeit zwischen zwei aufeinanderfolgenden VSYNCs.
5. Wenn ein Anzeigegerät oder die Hardware die gewünschte Erneuerungsrate von 72 oder 75 Hz nicht unterstützen kann, schaltet die Software die Anzeigerate auf 60 oder 50 Hz herunter und wiederholt, falls nötig, Voll bilder, um eine zweifache Anzeigerate zu erreichen. Das Abspielen eines 25 fps (frame per second) PAL-Ma terials auf einer 60 Hz-Anzeige wird z. B. durch Wie derholen von 5 Vollbildern der 25 Vollbilder während jeder Sekunde erreicht. Ähnlich wird die Darstellung eines 24 fps-Materials auf einer 60 Hz-Anzeige durch Wiederholen von 6 der 24 Vollbildern pro Sekunde er reicht, und auf einer 50 Hz-Anzeige durch Wiederholen eines der 24 Vollbilder pro Sekunde.

Aufgaben der speziellen Videohardware

Die Software programmiert die folgenden Arten von Aufgaben, die von der speziellen Videohardware 188b ausgeführt werden sollen:

1. Nur-Anzeige-Aufgabe: Zeit-Zuordnungs-Felder in dem HTDP spezifizieren die Anzahl der Zeitscheiben, wäh rend derer das Vollbild oder das obere und das untere Halbbild angezeigt werden sollten. Die nächste Aufgabe wird am Ende der spezifizierten Anzahl von Anzeige- Zeitscheiben gestartet.
2. Decodier- und Anzeige-Aufgabe: Hier wird ein neues Vollbild oder Halbbild decodiert und in die spezifi zierten Puffer geschrieben, während ein vorhergehend decodiertes Vollbild oder Halbbild angezeigt wird. Die Zeitzuweisungsfelder in dem HTDP spezifizieren die Anzahl der Zeitscheiben, während derer das Vollbild oder das obere und das untere Halbbild angezeigt wer den sollten. Die nächste Aufgabe wird bei Beendigung beider Decodier- und Anzeige-Aufgaben gestartet.

Decodieraufgaben-Typen

Decodieraufgaben können abhängig von dem verfügbaren System speicher zu einem der folgenden Typen gehören:

1. Vollbild decodieren,
2. zwei Halbbilder decodieren.

Decodier-Speicher-Schema

Die Decodieraufgaben weisen den Vollbildpufferspeicher gemäß einer der folgenden Einheiten zu:

1. 4 Vollbilder,
2. 3,5 Vollbilder,
3. 3,5 Vollbilder - HHR B-Halbbilder,
4. 3,5 Vollbilder - B-Halbbilder mit Fensterbildung

Anzeigeaufgabentypen

Anzeigeaufgaben können wie folgt definiert sein:

1. fortlaufende Vollbilder anzeigen,
2. Vollbild als 2 Halbbilder anzeigen.

Aufgaben-Zusammenstellung

Abhängig von der Vollbildspeicherorganisation, den Zeilen sprung/fortlaufenden Videovollbildern und der Anzeige/Deco dier-Rate gibt es acht Möglichkeiten zum Zusammenstellen von Aufgaben, die in Tabelle 11 zusammengefaßt sind:

Aufgabenzusammenstellungs-Schemata

Die folgenden Beispiele zeigen das Decodieren und Anzeigen einer Gruppe aus Bildern für unterschiedliche Anzeigeraten und Speicherschemata. Das unten beschriebene Beispiel ent spricht der folgenden Decodierfolge

I0 P3 B1 B2 P6 B4 B5 . . .

Wobei I, P und B Intra-, vorhergesagte (prädiktive) bzw. bidirektionale vorhergesagte Bildtypen repräsentieren. Das numerische Suffix ist die Einzelbildnummer, beginnend bei 0.

2x und 3x geben das Verhältnis der Anzeigerate zu der co dierten Vollbildrate an.

F0, F1, F2, F3 sind die Einzelbildspeicherungen im Bildpuf fer. Die Suffixe "t" und "b" entsprechen jeweils den oberen ("top") und den unteren ("bottom") Halbbildern. HF0, HF1 und HF2 sind Halbbildspeicherungen in dem Bildpuffer.

Beispiel 1 Halbbildanzeige (2x Anzeigerate) - 3,5 Vollbildspeicherungen

Beispiel 2 Halbbildanzeige (3x Anzeigerate) - 3,5 Vollbildspeicherungen

Beispiel 3 Halbbildanzeige (2x Anzeigerate) - 4 Vollbildspeicherungen

Beispiel 4 Halbbildanzeige (3x Anzeigerate) - 4 Vollbildspeicherungen

Beispiel 5 (Fortlaufende) Vollbildanzeige (2x Anzeigerate) - 4 Vollbildspeicherungen

Beispiel 6 (Fortlaufende) Vollbildanzeige (3x Anzeigerate) - 4 Vollbildspeicherungen

Beispiele für Aufgaben Decodieren eines B-Vollbildes für einen 3,5 Pufferspeicher und Halbbildanzeige

Decodier-Speicher-Schema: 3, 5 Puffer
BUF1 decodieren: HF0
BUF2 decodieren: HF1
Anzeigetyp: Anzeige als Halbbilder
Anzeigepuffer id: F0
Erste Anzeige: unteres Feld
Anzeigedauer für erstes Feld: 1
Anzeigedauer für zweites Feld: 2

Im Falle einer 3,5-Pufferorganisation können sich während der Decodierung eines B-Vollbildes Anzeige- und Decodierpuf fer überlappen. In diesem Fall muß eine Hardwarefestlegung auf ein Anzeigen-vor-dem-Decodieren- oder Decodieren-vor dem-Anzeigen für das Lesen/Schreiben des Speichers erfolgen. Diese Information wird auch als Teil der Aufgabe über mittelt.

Alternative Ausführungsformen der speziellen Videohardware

Der folgende Abschnitt beschreibt alternative Ausführungs formen der speziellen Videohardware 118b und den Datenablauf zum Ausführen der Bewegungsausgleichs- und der Blockrekon struktionsaufgaben. Fig. 13 zeigt eine Ausführungsform gemäß der vorliegenden Erfindung, bei der die spezielle Videohard ware 118b in eine Grafiksteuereinrichtung 118 eingebettet ist. Bei der in Fig. 13 gezeigten Ausführungsform führt die spezielle Videohardware 118b die Aufgaben des Bewegungsaus gleichs (MC = Motion Compensation) und der Blockrekonstruk tion (BR) aus (ähnlich wie bei der Aufteilung der Decodier aufgabe in Fig. 4). Fig. 14 zeigt das Datenablaufdiagramm für die MPEG-Decodieraufgabe, die von der in Fig. 13 gezeig ten speziellen Videohardware 118b ausgeführt wird.

Wie in Fig. 13 gezeigt, wird die in der Grafiksteuereinrich tung eingebettete spezielle Videohardware Video-Rekonstruk tions-Prozessor (VRP) 190 genannt. Der VRP 190 hat einen Speicherpuffer (IMEM) 192 auf dem Chip, um Daten zu speichern, die zu der IDCT-Operation gehören, eine Speicher puffer (RMEM) 194 zum Speichern von Daten, die zu der Bewe gungskompensations-Operation gehören, einen Halbpixel-Filter (HPF) 196 zum Durchführen einer Halbpixel-Interpolation und einen Blockrekonstruktions-Block 198 zum Ausführen einer Blockrekonstruktions-Berechnung der Videobilder. Der VRP 190 bildet eine Schnittstelle zu einer Befehlsfolgesteuerung 200 und einer Speichersteuereinrichtung 202, die den Zugriff auf den Bildpuffer der Grafiksteuereinrichtung 118 steuert.

Die Aufgabefolgesteuerung 204 liest das Aufgaben-FIFO und holt das HTDP. Die Aufgabefolgesteuerung 204 verwendet die HTDP-Werte zum Programmieren der Steuerregister in dem VRP 190. Dies umfaßt die Programmierung eines Registers mit dem Startzeiger des Symbolstrompuffers in dem Systemspeicher 14.

Die Ausführung beginnt mit der Bestätigung des VSYNC-Signals. Eine PCT-Bus-Masterlogik 206 beginnt mit dem Ein lesen des Symbol-FIFO aus dem Systemspeicher in das auf dem Chip gelegene Symbol-FIFO. Die Befehlsfolgesteuerung 200 interpretiert den Befehl fester Länge und beginnt das Parsen (Syntaxanalyse) der Symbole gemäß der zuvor beschriebenen Syntax. Die Befehlsfolgesteuerung 200 dient als ein Master und sendet Befehle und Daten zur Speichersteuereinrichtung 202 und zum VRP 190 jeweils für einen Macroblock auf einmal. Nachdem alle Macroblöcke in einem gegebenen Einzelbild ver arbeitet wurden, erzeugt die Aufgabenfolgesteuerung 204 eine Unterbrechung, um die Beendigung der Aufgabe anzuzeigen, und sie beginnt die Verarbeitung der nächsten Aufgabe.

Der VRP 190 arbeitet im Verhältnis zur Befehlsfolgesteuerung 200 in einem Slave-Modus, wobei die Befehlsfolgesteuerung 200 als ein Master einen Befehl in den VRP 190 lädt, der dann von dem VRP 190 ausgeführt wird. Nach der Ausführung des Befehls wartet der VRP 190 auf einen weiteren Befehl, der von der Befehlsfolgesteuerung 200 geladen wird. Zum Ver arbeiten eines Macroblocks gibt die Befehlsfolgesteuerung 200 drei Befehle aus - ein Befehl für die vier Luminanz blöcke (Y) und jeweils einen Befehl für die beiden Chromi nanzblöcke (Cb und Cr). Der VRP 190 holt die Bezugsmakro blöcke aus dem lokalen Speicher 194, führt (falls nötig) eine Halbpixel-Interpolation mit dem Halbpixelfilter 196 durch und kombiniert die Bezugs-Makroblöcke, um mittels Blockrekonstruktion (BR) einen Prädiktions-Makroblock zu bilden. Der VRP 190 extrahiert auch IDCT-Werte aus dem Sym bolstrom und legt die extrahierten Werte in den Speicherpuf fer IMEM 192 auf dem Chip. Der VRP 190 kombiniert dann die Ergebnisse aus diesen beiden Operationen, um mittels BR den rekonstruierten Makroblock zu erzeugen, der mit Hilfe der Speichersteuereinrichtung 202 in den gewünschten Bildpuffer geschrieben wird.

Es sei z. B. der Fall betrachtet, daß der VRP 190 einen Lumi nanzblock (Y) verarbeitet, der IDCT-Werte sowie einen Vor wärtsbewegungsvektor (A-Ref) und einen Rückwärtsbewegungs vektor (B-Ref) hat. Die Befehlsfolgesteuerung 200 extrahiert die Vorwärts- und Rückwärts-Bezugsadressen aus dem Symbol strom und schreibt sie in geeignete Register in der Speichersteuereinrichtung 202. Bei einer alternativen Aus führungsform berechnet die Befehlsfolgesteuerung 200 auch die Zieladresse des Y-Blocks. Die Befehlssteuereinrichtung 200 lädt dann ein Befehlspaket in den VRP 190, das dem VRP 190 mitteilt, wie der Block verarbeitet werden soll. Danach extrahiert die Befehlsfolgesteuerung 200 IDCT-Daten und lädt sie in den IMEM 192. Gleichzeitig beginnt der Bewegungsaus gleichs-Mechanismus, der den Vorwärts-Bezugsblock in den RMEM 194 holt. Die Halbpixelinterpolation wird, wenn nötig, "unterwegs" von dem HPF 196 durchgeführt, während der Be zugsblock aus dem Speicher abgerufen wird. Wenn der Vor wärts-Bezugsblock einmal da ist, beginnt der VRP 190, den Rückwärts-Bezugsblock aus dem Speicher abzurufen. Zu dieser Zeit mittelt der VRP 190 die Vorwärts- und Rückwärts-Bezugs pixelwerte "im Vorbeigehen", während die Rückwärts-Bezugs daten aus dem Speicher gelesen werden. Am Ende der Operation wird der Prädiktionsblock in dem RMEM 194 gespeichert (wie in Fig. 14 gezeigt).

Zu dieser Zeit müssen der TDCT-Mechanismus und der Bewe gungsausgleichs-Mechanismus in dem Sinne synchron arbeiten, daß immer der, der früher fertig wird, auf den anderen war tet. Fig. 15 zeigt den Fall, das die Bewegungsaus gleichsaufgabe vor der IDCT-Aufgabe beendet ist und somit warten muß, bis die IDCT-Werte vollständig in den IMEM 192 geladen sind. Schließlich kombiniert der VRP 190 das Ergeb nis der IDCT- und Bewegungsausgleichs-Aufgaben, um den deco dierten Y-Block "im Vorbeigehen" unter Verwendung der Block rekonstruktion (BR) zu rekonstruieren und zur Speichersteu ereinrichtung 202 zu senden, woraufhin er in das RMEM 194 zurückgeschrieben wird. Für einen "Y"-Block extrahiert der IDCT-Mechanismus bis zu vier 8×8 IDCT-Werte für jeden der vier Luminanzblöcke. Die Anzahl der 8×8 "Y"-IDCT-Blöcke, die in einem Makroblock enthalten sind, hängt von dem Symbol des Musters ab. Für die 8×8 "Y"-Blöcke, die nicht im Sym bolstrom enthalten sind, schreibt der IDCT-Mechanismus Nul len als IDCT-Werte auf. Fig. 16 zeigt den Fall, daß die IDCT-Aufgabe vor der Bewegungsausgleichsaufgabe endet.

Fig. 17 zeigt das Datenflußdiagramm für eine weitere Ausfüh rungsform der speziellen Videohardware 118b. Wie in Fig. 17 gezeigt, werden die IDCT-Werte zuerst mit dem Vorwärts-Be zugsblock (A-REF) kombiniert. Die resultierenden Daten wer den dann mit dem Rückwärts-Block (B-REF) gemittelt. Diese Realisierungsform hilft, IMEM zu sparen.

Nach der Beschreibung der Erfindung wird dem Fachmann deut lich sein, daß viele Veränderungen und Modifikationen vor genommen werden können, ohne den Bereich der folgenden An sprüche zu verlassen. Alle Publikationen und Patentanmeldun gen, die in dieser Beschreibung erwähnt wurden, werden aus drücklich in Bezug genommen. Die in der vorstehenden Be schreibung, den Ansprüchen und der Zeichnung offenbarten Merkmale können sowohl einzeln als auch in beliebiger Kom bination für die Realisierung der Erfindung in ihren ver schiedenen Ausgestaltungen von Bedeutung sein.

Claims

1. Verfahren zum Decodieren eines codierten MPEG-Video datenstroms mit folgenden Verfahrensschritten:
Aufteilen der Decodierung des codierten MPEG-Videoda tenstroms in speicher-rechenintensive Aufgaben, die umfangreiche Speicher- und Rechenresourcen benötigen, und wenig speicher-rechenintensive Aufgaben, die keine umfangreichen Speicher- oder Rechenresourcen benöti gen;
Ausführen der wenig speicher-rechenintensiven Aufgaben mittels Softwaremodulen, die auf einem Prozessor (190) laufen, um vorverarbeitete Symbolstrom-Datenstrukturen für jedes Videobild zu erzeugen;
Speichern der vorverarbeiteten Symbolstrom-Datenstruk tur in einem Speicherpuffer (192, 194);
Ausführen der speicher-rechenintensiven Aufgaben in einer speziellen Videohardware (118b), um ein deco diertes Videobild zu erzeugen;
Synchronisieren der wenig speicher-rechenintensiven Aufgaben, die von den Softwaremodulen erledigt werden, und der speicher-rechenintensiven Aufgaben, die von der speziellen Videohardware ausgeführt werden; und Anzeigen des decodierten Videobildes auf einem Anzei gegerät.

2. Verfahren nach Anspruch 1, bei dem die Ausführung der wenig speicher-rechenintensiven Aufgaben durch die Softwaremodule, die auf dem Prozessor laufen, die fol genden Schritte umfaßt:
Parsen des codierten MPEG-Videodatenstroms mittels einer variablen Längendecodierung, um einen geparsten Videodatenstrom zu erzeugen;
Ausführen einer inversen Quantisierung des geparsten Videodatenstroms, um einen quantisierten Videodaten strom zu erzeugen;
Formatieren des quantisierten Videodatenstroms als die vorverarbeitete Symbolstrom-Datenstruktur; und
Schreiben der vorverarbeiteten Symbolstrom-Datenstruk tur in den Speicherpuffer.

3. Verfahren nach Anspruch 1, bei dem die Ausführung der wenig speicherintensiven Aufgaben durch die der Soft waremodule, die auf dem Prozessor laufen, folgende Verfahrensschritte umfaßt:
Parsen des codierten MPEG-Videodatenstroms mittels einer variablen Längendecodierung, um einen geparsten Videodatenstrom zu erzeugen;
Ausführen einer inversen Quantisierung mit dem gepar sten Videodatenstrom, um einen quantisierten Videoda tenstrom zu erzeugen;
Ausführen der inversen diskreten Cosinustransformation mit dem quantisierten Videodatenstrom, um einen cosi nustransformierten Videodatenstrom zu erzeugen;
Formatieren des cosinustransformierten Videodaten stroms als die vorverarbeitete Symbolstrom-Datenstruk tur; und
Schreiben der vorverarbeiteten Symbolstrom-Datenstruk tur in den Speicherpuffer.

4. Verfahren nach einem der vorangehenden Ansprüche, bei dem die Ausführung der speicher-rechenintensiven Auf gaben in der speziellen Videohardware (118b) zum Er zeugen des decodierten Videobildes folgende Schritte umfaßt:
Zugreifen auf die vorverarbeiteten Symbolstrom- Datenstruktur, die in dem Speicherpuffer (192, 194) gespeichert ist;
Ausführen einer Bewegungsausgleichsoperation mit der vorverarbeiteten Symbolstrom-Datenstruktur, um einen ausgeglichenen Videodatenstrom zu erhalten; und
Ausführen einer Blockrekonstruktions-Operation mit dem kompensierten Videodatenstrom, um das decodierte Vi deobild zu erzeugen.

5. Verfahren nach einem der Ansprüche 1 bis 3, bei dem die Ausführung der speicher-rechenintensiven Aufgaben in der speziellen Videohardware (118b) zum Erzeugen des decodierten Videobildes folgende Schritte umfaßt:
Zugreifen auf die vorverarbeitete Symbolstrom- Datenstruktur, die in dem Speicherpuffer (192, 194) gespeichert ist;
Ausführen der inversen diskreten Cosinustransformation mit der vorverarbeiteten Symbolstrom-Datenstruktur zum Erzeugen eines cosinustransformierten Videodaten stroms;
Ausführen eines Bewegungsausgleichs mit dem cosinus transformierten Videodatenstrom, um einen ausgegliche nen Videodatenstrom zu erzeugen; und
Ausführen einer Blockrekonstruktion mit dem kompen sierten Videodatenstrom, um das decodierte Videobild zu erzeugen.

6. Verfahren nach einem der vorangehenden Ansprüche, bei dem die Synchronisierung der wenig speicher-rechen intensiven Aufgaben, die von der Software ausgeführt werden, und der speicher-rechenintensiven Aufgaben, die von der speziellen Videohardware (118b) ausgeführt werden, folgende Schritte umfaßt:
Zuordnen des Speicherpuffers zum Speichern vorverar beiteten Symbolstrom-Datenstruktur;
Warten einer Aufgabenzeiger-Warteschlange aus Soft wareaufgaben-Steuerdatenstrukturen, wobei jede der Softwareaufgaben-Steuerdatenstrukturen Steuerinforma tion speichert, welches jeweils einer der wenig spei cher-rechenintensiven Aufgaben entspricht, die von den Softwaremodulen verarbeitet wird und als die speicher rechenintensive Aufgabe vorgesehen werden kann, welche von der speziellen Videohardware ausgeführt wird;
Zählen der beendeten wenig speicher-rechenintensiven Aufgaben;
Konvertieren der Software-Steuerdatenstrukturen in Hardwareaufgaben-Steuerdatenstrukturen, wobei die Hardwareaufgaben-Steuerdatenstrukturen Information speichern, welche der speicher-rechenintensiven Auf gabe entspricht, die von der speziellen Videohardware ausgeführt werden soll;
Warten einer Aufgaben-FIFO-Warteschlange der Hardware aufgaben-Steuerdatenstrukturen in der speziellen Vi deohardware, wobei jede der Hardwareaufgaben-Steuer datenstrukturen in der Aufgaben-FIFO-Warteschlange Information in Bezug auf die rechen-speicher-intensive Aufgabe steuert, die von der speziellen Videohardware auszuführen ist; und
Ausgeben eines Unterbrechungssignals, um die Beendi gung der speicher-rechenintensiven Aufgabe durch die spezielle Videohardware anzuzeigen;
wobei die Softwaremodule die Hardwareaufgaben-Steuer datenstruktur bei Empfang des Unterbrechungssignals aus der Aufgaben-FIFO-Warteschlange entfernt, wobei die entfernte Hardwareaufgaben-Steuerdatenstruktur der speicher-rechenintensiven Aufgabe entspricht, die von der speziellen Videohardware abgeschlossen wurde.

7. Vorrichtung zum Decodieren eines codierten MPEG-Video datenstroms durch Aufteilen der Decodierung in wenig speicher-rechenintensive Aufgaben und speicher-rechen intensive Aufgaben, mit folgenden Merkmalen:

einer Busschnittstelle (11);
einen mit der Busschnittstelle verbundenen Prozessor (190);
einen mit der Busschnittstelle verbundenen Systemspei cher (14), wobei der Systemspeicher so konfiguriert ist, daß er mehrere Softwaremodule speichert, die auf dem Prozessor laufen können, wobei eines oder mehrere der Softwaremodule so konfiguriert sind, daß sie die wenig speicher-rechenintensiven Aufgaben ausführen, um eine vorverarbeitete Symbolstrom-Datenstruktur zu er zeugen;
einer speziellen Videohardware (118b), die mit der Busschnittstelle verbunden ist, wobei die spezielle Videohardware so konfiguriert ist, daß sie die spei cher-rechenintensiven Aufgaben ausführt, um decodierte Videodaten zu erzeugen, die auf einer Anzeigeeinrich tung angezeigbar sind; und
einem speziellen Speicher (150), der mit der speziel len Videohardware verbunden ist.

8. Vorrichtung nach Anspruch 7, bei welcher der Prozessor (190) so konfiguriert ist, daß er ein oder mehrere Softwaremodule der mehreren in dem Systemspeicher (14) gespeicherten Softwaremodule ausführt, um den codierten MPEG-Videodatenstrom mittels einer va riablen Längendecodierung zu parsen, um einen gepar sten Videodatenstrom zu erzeugen;
eine inverse Quantisierung mit dem geparsten Videoda tenstrom auszuführen, um einen quantisierten Videoda tenstrom zu erzeugen;
den quantisierten Videodatenstrom als die vorverarbei tete Symbolstrom-Datenstruktur zu formatieren; und die vorverarbeitete Symbolstrom-Datenstruktur in dem Systemspeicher (14) zu speichern.

9. Vorrichtung nach Anspruch 7, bei welcher der Prozessor (190) so konfiguriert ist, daß er eines oder mehrere Softwaremodule der mehreren in dem Systemspeicher (14) gespeicherten Softwaremodule ausführt, um den codier ten MPEG-Videodatenstrom mittels variabler Längendeco dierung zu parsen, um einen geparsten Videodatenstrom zu erzeugen;
eine inverse Quantisierung mit dem geparsten Videoda tenstrom durchzuführen, um einen quantisierten Video datenstrom zu erzeugen;
eine inverse diskrete Cosinustransformation mit dem quantisierten Videodatenstrom durchzuführen, um einen cosinustransformierten Videodatenstrom zu erzeugen;
den cosinustransformierten Videodatenstrom als die vorverarbeitete Symbolstrom-Datenstruktur zu formatie ren; und
die vorverarbeitete Symbolstrom-Datenstruktur in dem Systemspeicher (14) zu speichern.

10. Vorrichtung nach einem der Ansprüche 7 bis 9, bei der die spezielle Videohardware (118b) ferner dafür kon figuriert ist,
die in dem Systemspeicher (14) gespeicherte vorverar beitete Symbolstrom-Datenstruktur zu lesen;
ein Bewegungsausgleich mit der vorverarbeiteten Sym bolstrom-Datenstruktur auszuführen, um einen ausgegli chenen Videodatenstrom zu erzeugen; und
eine Blockrekonstruktion mit dem ausgeglichenen Video datenstrom auszuführen, um die decodierten Videodaten zu erzeugen.

11. Vorrichtung nach einem der Ansprüche 7 bis 9, bei dem die spezielle Videohardware ferner dazu konfiguriert ist,
die in dem Systemspeicher (14) gespeicherte vorverar beitete Symbolstrom-Datenstruktur zu lesen;
eine inverse diskrete Cosinustransformation mit der vorverarbeiteten Symbolstrom-Datenstruktur durchzufüh ren, um einen cosinustransformierten Videodatenstrom zu erzeugen;
einen Bewegungsausgleich mit dem cosinustransformier ten Videodatenstrom durchzuführen, um einen ausgegli chenen Videodatenstrom zu erzeugen; und
eine Blockrekonstruktion mit dem ausgeglichenen Video datenstrom auszuführen, um die decodierten Videodaten zu erzeugen.

12. Vorrichtung nach einem der Ansprüche 7 bis 11, bei der eines oder mehrere Softwaremodule der mehreren in dem Systemspeicher (14) gespeicherten Softwaremodule fer ner so konfiguriert sind, daß sie einen Speicherpuffer für die vorverarbeitete Symbolstrom-Datenstruktur in dem Systemspeicher (14) zuweisen;
eine Aufgabenzeiger-Warteschlange der Softwareaufga ben-Steuerdatenstrukturen verwalten, wobei jede der Softwareaufgaben-Steuerdatenstrukturen Steuerinforma tion speichert, die jeweils den wenig speicher rechenintensiven Aufgaben entsprechen, die von dem Softwaremodul verarbeitet werden, das als die speicher-rechenintensive Aufgabe eingeteilt werden kann, die von der speziellen Videohardware (118b) aus geführt wird;
die beendeten wenig speicher-rechenintensiven Aufgaben zählen; und
die Softwareaufgaben-Steuerdatenstrukturen in Hardwa reaufgaben-Steuerdatenstruktur umwandeln, wobei die Hardwareaufgaben-Steuerdatenstrukturen Information speichern, die der speicher-rechenintensiven Aufgabe entspricht, die von der speziellen Videohardware aus geführt werden soll.

13. Vorrichtung nach einem der Ansprüche 7 bis 12, bei der die spezielle Videohardware (118b) ferner so konfigu riert ist, daß sie
eine Aufgaben-FIFO-Warteschlange der Hardwareaufgaben- Steuerdatenstrukturen in dem speziellen Speicher (150) verwaltet, wobei jedes der Hardwareaufgaben-Steuerda tenpakete in der Aufgaben-FIFO-Warteschlange zum Speichern von Informationen in Bezug auf die speicher rechenintensiven Aufgaben dient, die von der speziel len Videohardware (118b) ausgeführt werden soll; und
ein Unterbrechungssignal ausgibt, welches die Beendi gung der speicher-rechenintensiven Aufgabe durch die spezielle Videohardware (118b) anzeigt, wobei das Softwaremodul so konfiguriert ist, daß es bei Empfang des Unterbrechungssignals die Hardwareaufgaben-Steuer datenstruktur auf der Aufgaben-FIFO-Warteschlange ent fernt, wobei die entfernte Hardwareaufgaben-Steuerda tenstruktur der von der speziellen Videohardware aus geführten speicher-rechenintensiven Aufgabe ent spricht.