-
Die
vorliegende Erfindung betrifft die Videodatenverarbeitung.
-
Home-Entertainment-Systeme,
die PC- und Fernsehfunktionen kombinieren (PC/TV-Systeme), werden
zunehmend zu generischen benutzeraktiven Kommunikationseinrichtungen
mit mehreren Quellen und mehreren Zielen. Solche Multimedia-Systeme müssen in
verschiedenen Datenformaten zwischen mehreren Orten für vielfältige Anwendungen
als Antwort auf Benutzeranforderungen kommunizieren können. Zum
Beispiel kann ein PC/TV-System Daten von Satelliten- oder terrestrischen
Quellen empfangen, darunter HDTV-Ausstrahlungen
(hochauflösendes
Fernsehen), Ausstrahlungen des Mehrpunkt-Mikrowellenverteilungssystems
(MMDS) und DVB (Digital Video Broadcasts). Ein PC/TV-System kann auch
Daten über
Telefon (z.B. das Internet) und Koaxialleitungen (z.B. Kabel-TV)
sowie von abgesetzten und auch lokalen Quellen wie etwa Abspielgeräte für DVD (Digital
Video Disk), CDROM, VHS und Digital-VHS (DVHSTM)
und PCs empfangen und senden.
-
Ein
solches generisches PC/TV-Unterhaltungssystem erfordert vielfältige verschiedene
Bildschirmanzeigen (OSDs) zur Verwendung mit Videoprogramminhalt
von verschiedenen Quellen oder für verschiedene
Anwendungen. Die Verarbeitung mehrerer verschiedener OSDs in Fernseh-
und Multimedia-Systemen
unterliegt zeitlichen, Speichergrößen- und anderen praktischen
Begrenzungen. Ein erfindungsgemäßes System
stellt ein OSD-Verwaltungs- und Steuersystem bereit, das die Datenverarbeitungsbegrenzungen
effizient berücksichtigt. WO-A-98
17058 beschreibt die Steuerung des Aussehens einer Pixmap durch
einen OSD-Header.
-
Die
Erfindung wird in den angefügten
Ansprüchen
definiert.
-
Ein
Datenformat, das verschiedene Header verwendet, die mit entsprechendem
OSD-Inhalt assoziiert sind, ermöglicht
die Implementierung eines effizienten und flexiblen OSD- Verwaltungs- und
Steuersystems. Jeder Header enthält
ein eindeutiges Anzeigecharakteristikum oder Menge von Anzeigecharakteristiken
zur Interpretation und Präsentation
einer assoziierten OSD-Pixelmap. Bei der Verwendung dieses Systems
umfaßt
die Präsentation
oder Modifikation einer OSD die Auswahl des mit der OSD assoziierten
Headers, der die gewünschten
Anzeigecharakteristika zur Verwendung bei der Präsentation oder Modifikation
der OSD aufweist.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Es
zeigen:
-
1 ein
beispielhaftes Home-Entertainment-System zum Verarbeiten von OSD-Header
und Inhaltsdaten gemäß der vorliegenden
Erfindung;
-
2 ferner
den MPEG-Decoder und Videospeicher des in 1 gezeigten
beispielhaften Home-Entertainment-Decodersystems;
-
3 eine
herkömmliche
Anordnung von MPEG-Decoder und Videospeicher;
-
4 ein
Flußdiagramm
eines herkömmlichen
OSD-Abrufprozesses;
-
5 herkömmliche
OSD-Datenformate;
-
6 eine
Anordnung von MPEG-Decoder und Videospeicher der vorliegenden Erfindung;
-
7 ein
Flußdiagramm
des OSD-Abrufprozesses der vorliegenden Erfindung; und
-
8 das
OSD-Datenformat der vorliegenden Erfindung.
-
Die
Merkmale und Vorteile der vorliegenden Erfindung werden aus der
folgenden Beschreibung, die als Beispiel angegeben wird, deutlicher.
-
Nunmehr
mit Bezug auf 1 ist ein Blockschaltbild eines
beispielhaften digitalen Videoempfangssystems gezeigt, das gemäß den Prinzipien
der Erfindung arbeitet. Das Videoempfängersystem enthält eine
Antenne 10 und einen Eingangsprozessor 15 zum
Empfangen und Digitalisieren eines ausgestrahlten Trägers, der
mit Signalen moduliert ist, die Audio-, Video- und assoziierte Daten
tragen, einen Demodulator 20 zum Empfangen und Demodulieren des
digitalen Ausgangssignals des Eingangsprozessors 15 und
einen Decoder 30, der ein Signal ausgibt, das trelliscodiert,
auf Datensegmente mit Bytelänge abgebildet,
entschachtelt und Reed-Solomon-fehlerkorrigiert wird. Die korregierten
Ausgangsdaten aus der Decodereinheit 30 liegen in Form
eines MPEG-kompatiblen Transportdatenstroms vor, der programmrepräsentative
gemultiplexte Audio-, Video- und Datenkomponenten enthält.
-
Das
Videoempfängersystem
enthält
ferner ein Modem 80, das über Telefonleitungen mit einem Server 83 oder
Verbindungsdienst 87 verbunden sein kann, so daß Daten
in verschiedenen Formaten (z.B. MPEG, HTML und/oder JAVA) über die
Telefonleitungen von dem Videoempfängersystem empfangen werden
können.
-
Ein
Prozessor 25 verarbeitet die aus dem Decoder 30 und/oder
Modem 80 ausgegebenen Daten, so daß die verarbeiteten Daten abhängig von durch
einen Benutzer über
eine Fernbedienungseinheit 125 eingegebenen Anforderungen
auf einer Display-Einheit 75 angezeigt oder auf einem Speichermedium 105 gespeichert
werden können.
Genauer gesagt enthält
der Prozessor 25 eine Steuerung 115, die aus der
Fernbedienungseinheit 125 über die Fernbedienungsschnittstelle 120 empfangene
Anforderungen interpretiert und die Elemente des Prozessors 25 entsprechend
konfiguriert, um Benutzeranforderungen (z.B. Kanal, Website und/oder
OSD-Anzeige) auszuführen.
Bei einer beispielhaften Betriebsart konfiguriert die Steuerung 115 die
Elemente des Prozessors 25 so, daß MPEG-decodierte Daten und
eine OSD zur Anzeige auf der Display-Einheit 75 bereitgestellt
werden. Bei einer anderen beispielhaften Betriebsart konfiguriert
die Steuerung 115 die Elemente des Prozessors 25 so,
daß ein MPEG-kompatibler
Datenstrom zur Speicherung auf dem Speichermedium 105 über die
Speicherungseinrichtung 90 und die Speicherschnittstelle 95 bereitgestellt
wird. Bei einer weiteren beispielhaften Betriebsart konfiguriert
die Steuerung 115 die Elemente des Prozessors 25 für andere
Kommunikationsbetriebsarten, wie zum Beispiel für den Empfang einer bidirektionalen
Kommunikation (z.B. Internet) über den
Server 83 oder den Verbindungsdienst 87.
-
Der
Prozessor 25 enthält
eine Decodier-PID-Auswahleinheit 45, die gewählte Pakete
in dem Transportstrom aus dem Decoder 30 identifiziert und
zu dem Transportdecoder 55 routet. Der Transportstrom aus
dem Decoder 30 wird durch den Transportdecoder 55 zu
Audio-, Video- und Datenkomponenten gedemultiplext und wird durch
die anderen Elemente des Prozessors 25 wie weiter unten
beschrieben wird, weiter verarbeitet.
-
Der
dem Prozessor 25 zugeführte
Transportstrom umfaßt
Datenpakete, die Programmkanaldaten, Hilfs-Systemzeitsteuerungsinformationen
und programmspezifische Informationen, wie zum Beispiel Programminhalteinstufung
und Programmanleitungsinformationen, enthalten. Der Transportdecoder 55 leitet
die Hilfsinformationspakete zu der Steuerung 115, die die
Hilfsinformationen analysiert, kollationiert und zu hierarchisch
angeordneten Tabellen zusammenstellt. Einzelne Datenpakete, die
den vom Benutzer gewählten
Programmkanal bilden, werden unter Verwendung der zusammengestellten
programmspezifischen Informationen identifiziert und zusammengestellt.
Die Systemzeit steuerungsinformationen umfassen einen Zeitreferenzanzeiger
und assoziierte Korrekturdaten (z.B. einen Sommerzeitanzeiger und
Offsetinformationen zur Kompensation von Zeitdrift, Schaltjahren
usw.) Diese Zeitsteuerungsinformationen reichen für einen
Decoder aus, um den Zeitreferenzanzeiger in einen Zeittakt (z.B. Ostküstenzeit
und -datum in den Vereinigten Staaten) umzuwandeln, um eine Tageszeit
und ein Datum der zukünftigen Übertragung
eines Programms durch den Aussender des Programms herzustellen.
Der Zeittakt ist für
die Einleitung geplanter Programmverarbeitungsfunktionen verwendbar,
wie zum Beispiel Programmwiedergabe, Programmaufzeichnung und Programmabspielen.
Ferner umfassen die programmspezifischen Informationen Daten für bedingten
Zugang, Netzwerkinformationen und Identifikation und Verknüpfung, wodurch
das System von 1 sich auf einen gewünschten
Kanal abstimmen und Datenpakete zusammenstellen kann, um vollständige Programme
zu bilden. Die programmspezifischen Informationen umfassen außerdem Hilfsprogramminhaltseinstufungsinformationen
(z.B. eine Geeignetheitseinstufung auf der Basis von Alter), Programmanleitungsinformationen
(z.B. eine elektronische Programmanleitung – EPG) und deskriptiven Text
in bezug auf die ausgestrahlten Programme sowie Daten, die die Identifikation
und Zusammenstellung dieser Hilfsinformationen unterstützen.
-
Der
Transportdecoder 55 führt
dem MPEG-Decoder 65 MPEG-kompatible Video-, Audio- und Subbildströme zu. Die
Video- und Audioströme enthalten
komprimierte Video- und Audiodaten, die den Programminhalt des gewählten Kanals
repräsentieren.
Die Subbilddaten enthalten Informationen, die mit Kanalprogramminhalt
assoziiert sind, wie zum Beispiel Einstufungsinformationen, Programmbeschreibungsinformationen
und dergleichen.
-
Der
MPEG-Decoder 65 arbeitet mit einem Direktzugriffsspeicher
(RAM) 67 zusammen, um die MPEG- kompatiblen paketierten Audio- und Videodaten
aus der Einheit 55 zu decodieren und zu dekomprimieren
und führt
die dekomprimierten programmrepräsentativen
Pixeldaten dem Display-Prozessor 70 zu. Der Decoder 65 stellt
außerdem
die Subbilddaten aus der Einheit 55 zusammen und kollationiert und
interpretiert sie, um formatierte Programmanleitungsdaten zur Ausgabe
an ein internes OSD-Modul (siehe 2, 3 und 7)
zu erzeugen. Das OSD-Modul arbeitet mit dem RAM 67 zusammen,
um die Subbilddaten und andere Informationen zu verarbeiten, um
pixelabgebildete Daten zu erzeugen, die Untertitel, Steuer- und
Informationsmenüanzeigen einschließlich wählbarer
Menüoptionen
und anderer Elemente zur Präsentation
auf der Display-Einrichtung 75 gemäß der vorliegenden Erfindung
repräsentieren.
Die Steuer- und Informationsmenüs,
die angezeigt werden, ermöglichen
es einem Benutzer, ein zu betrachtendes Programm auszuwählen und
zukünftige
Programmverarbeitungsfunktionen einzuplanen, wie zum Beispiel Abstimmung
zum Empfang eines gewählten
Programms zur Betrachtung, Aufzeichnung eines Programms auf dem
Speichermedium 105 und Wiedergabe eines Programms aus dem
Medium 105.
-
Die
Steuer- und Informationsanzeigen, einschließlich Text und Graphiken, die
von dem OSD-Modul erzeugt werden, werden in Form von Überlagerungspixelmapdaten
unter der Anleitung der Steuerung 115 erzeugt. Die Überlagerungspixelmapdaten
aus dem OSD-Modul werden kombiniert und mit den dekomprimierten
pixelrepräsentativen
Daten aus dem MPEG-Decoder 65 unter
der Anleitung der Steuerung 115 synchronisiert. Kombinierte
Pixelmapdaten, die ein Videoprogramm auf dem gewählten Kanal repräsentieren,
werden zusammen mit assoziierten Subbilddaten durch den Display-Prozessor 70 codiert
und zur Anzeige an die Einrichtung 75 ausgegeben.
-
Die
Prinzipien der Erfindung können
auf terrestrische, Kabel-, Satelliten-, Internet- oder Computernetzwerk- Ausstrahlungssysteme
angewandt werden, bei denen der Codierungstyp oder das Modulationsformat
variiert werden können.
Solche Systeme sind zum Beispiel nicht-MPEG-kompatible Systeme, die andere Arten
von codierten Datenströmen
und andere Verfahren zum Übermitteln
programmspezifischer Informationen benutzen. Obwohl das offengelegte
System als ausgestrahlte Programme verarbeitend beschrieben wird,
ist dies des weiteren nur beispielhaft. Der Begriff "Programm" soll eine beliebige Form
paketierter Daten repräsentieren,
wie zum Beispiel Audiodaten, Telefonnachrichten, Computerprogramme,
Internetdaten oder andere Übermittlungen.
-
Die
Architektur von 1 ist nicht exklusiv. Es können andere
Architekturen gemäß den Prinzipien
der Erfindung abgeleitet werden, um dieselben Ziele zu erreichen.
Außerdem
können
die Funktionen der Elemente des Prozessors 25 von 1 vollständig oder
teilweise innerhalb der programmierten Anweisungen eines Mikroprozessors
implementiert werden. Außerdem
gelten die Prinzipien der Erfindung für jede beliebige Form von MPEG-
oder nicht-MPEG-kompatiblem
elektronischem Programmführer.
-
Nunmehr
mit Bezug auf 2 werden der MPEG-Decoder 65 und
der Video-RAM 67 ausführlicher
dargestellt. Der Decoder 65 enthält einen FIFO-Pufferspeicher 130,
der Videodatenpakete bei Bedarf in kleinen Segmenten aus dem Transportdecoder 55 empfängt und
diese über
eine Speichersteuerung 132 in relativ größere Segmente
in einen Teil 134 des RAM 67 einkoppelt, der für Decodierung und
Dekomprimierung reserviert ist. Der Video-RAM 67 wird unter
der Kontrolle der Speichersteuerung 132 adressiert. Der
Teil 134 des RAM 67 enthält einen Ratenpufferteil zum
Speichern der empfangenen Videodatenpakete und einen Bildspeicherteil
zum Speichern von Bildern von Videoinformationen während des
Decodierungs- und Dekomprimierungsbetriebs. Eine Video-Display-Einheit 140 decodiert
und dekomprimiert die gespeicherten Videodatenpakete, um eine Sequenz
von Videobildkomponenten zu bilden. Zu diesem Zweck fordert die
Videoanzeigeeinheit 140 Daten aus dem Decodierungs- und
Dekomprimierungsteil des Teils 134 nach Bedarf über die Speichersteuerung 132 an.
Die Sequenz von Videobildkomponenten wird mit Teilbild, Zeilen-
und Pixelratensignalen synchronisiert, die der Display-Prozessor 70 erzeugt.
Von der Steuerung 115 erzeugte Steuerdaten werden durch
die Steuerungschnittstelleneinheit 142 empfangen und über einen
internen Steuerbus an verschiedene Elemente des MPEG-Decoders 65 angekoppelt.
-
Der
OSD-Teil des MPEG-Decoders 65 enthält eine OSD-Display-Einheit 144,
die über
die Speichersteuerung 132 mit einem OSD-Headerspeicherblock 136 und
einem OSD-Pixelmap- oder – Bitmapspeicherblock 138 des
RAM 67 kommuniziert, wie später ausführlicher besprochen wird. Nach
Initialisierung des Videoempfängers
erzeugt die Steuerung 115 mehrere Pixelmaps und assoziierte
Pixelmapheader und speichert diese in OSD-Pixelmap- und OSD-Headerblöcken des
Speichers 138 und 136 über die Steuerschnittstelle 142 und
die Speichersteuerung 132.
-
Unter
der Kontrolle der OSD-Display-Einheit 144 kombiniert ein
Ausgangsmultiplexer 146 die Ausgabe der Video-Display-Einheit 140 (Videobildkomponenten)
und die Ausgabe der OSD-Display-Einheit 144 (graphische
Bildkomponenten) und leitet die Video- und Graphik-Kombination zur
Anzeige auf der Display-Einheit 75 zu dem Display-Prozessor 70.
-
Nunmehr
mit Bezug auf 3 ist eine herkömmliche
OSD-Verwaltungs-
und Steueranordnung gezeigt. Die Speichersteuerung 132 enthält u.a.
ein Register für
den OSD-Headerzeiger (OHP) 148 und ein Register des Speicherzugriffsfile
(MAF) 150 zur Ermöglichung
des Speicherns und Abrufens von OSD-Daten in dem OSD-Headerblock 136 und
dem OSD-Pixelmapblock 138 des Speichers 67. Die
Speichersteuerung 132 verwaltet das Speichern und Abrufen
von OSD-Daten in dem Speicher 67 als Reaktion auf Anforderungen
von der OSD-Display-Einheit 144. Nach Initialisierung des
Videoempfängers
werden mehrere OSD-Datenstrukturen
in dem Speicher 67 gespeichert. Jede OSD-Datenstruktur enthält einen
OSD-Header (z.B. Header "OSD
1", "OSD 2" und "OSD 3"), der in dem Headerblock 136 des
Speichers 67 gespeichert wird, und eine OSD-Pixelmap (z.B.
Pixelmaps "OSD 1", "OSD 2" und "OSD 3"), die in dem Pixelmapblock 138 des
Speichers 67 gespeichert wird. Gemäß der herkömmlichen OSD-Pufferungstechnik
wird in dem Headerblock 136 für jede in dem Pixelmapblock 138 gespeicherte
OSD-Pixelmap ein einziger OSD-Header gespeichert. Jeder OSD-Header
enthält
die Speicherstelle der assoziierten Pixelmap in dem Pixelmapblock 138 sowie
eine Menge von Anzeigecharakteristiken, die definieren, wie die
assoziierte Pixelmap durch den Display-Prozessor 70 verarbeitet
und auf der Display-Einheit 75 angezeigt werden soll. Zum
Beispiel enthält
der Header "OSD
1" die Speicherstelle
der Pixelmap "OSD
1" sowie eine Menge
von Anzeigecharakteristiken, die definieren, wie die Pixelmap "OSD 1" verarbeitet und angezeigt
werden soll. Zu den Anzeigecharakteristiken gehören u.a. die Anwesenheit oder
Abwesenheit von OSD-Seitenteilen, die Verwendung von Pixelkomprimierung,
die Anzahl der Bit pro Pixel, YUV- oder YIQ-Kolorimetrie, Transparenzgrad,
OSD-Größe, OSD-Format
(z.B. verschachtelt oder progressiv), OSD-Farbschema, OSD-Mischverhältnis, OSD-Auflösung, Seitenverhältnis, Horizontal-Pixelduplikation,
Vertikal-Pixelduplikation, OSD-Bildschirmort. Einige beispielhafte
OSD-Header- und OSD-Pixelmap-Datenstrukturen sind in 5 dargestellt. Wie
oben besprochen, ist jeder OSD-Header 167 mit einer verschiedenen
OSD-Pixelmap 168 assoziiert.
-
Nunmehr
mit Bezug auf 4 ist in Verbindung mit 3 ein
herkömmlicher
OSD-Abrufprozeß 151 gezeigt.
Zu Anfang empfängt
die OSD-Display-Einheit 144 im Schritt 152 eine
OSD-Rnzeigeanforderung von der Steuerung 115 zur Anzeige
einer OSD (z.B. eines graphischen Bildes, wie in 5 gezeigt)
auf der Display-Einheit 75. Als Reaktion auf die Anforderung
der Steuerung sendet die OSD-Display-Einheit 144 im Schritt 154 eine
Speicherzugriffsanforderung zu dem OHP-Register 148. Das OHP-Register 148 versorgt
die Anforderung im Schritt 156 durch Schreiben des OSD-Headers,
der der gewünschten
OSD-Pixelmap entspricht, in das MAF-Register 150. Die OSD-Display-Einheit 144 liest
im Schritt 158 den OSD-Header, um die Speicherstelle der
OSD-Pixelmap in dem Pixelmapblock 138 zu bestimmen. Nachdem
die Pixelmapspeicherstelle bestimmt wurde, setzt die OSD-Display-Einheit 144 die
OSD-Adresse in der Speichersteuerung 132 und fordert an,
daß die
Speichersteuerung 132 das Bild an der gesetzten Adresse
in das MAF-Register 150 einliest. Danach bestimmt die OSD-Anzeigeeinheit 144 im
Schritt 160, ob die Anzeigecharakteristika in dem abgerufenen
OSD-Header den Anzeigecharakteristiken der OSD-Anzeigeanforderung
genügen. Zum
Beispiel können
die Anzeigecharakteristiken des abgerufenen Headers anzeigen, daß die assoziierte
Pixelmap als blaues Bild in einem oberen Teil des Display 75 angezeigt
werden soll, während
die angeforderten Anzeigecharakteristiken bestimmen, daß die assoziierte
Pixelmap als ein grünes
Bild in einem unteren Teil des Display 75 angezeigt wird. Wenn
die Anzeigecharakteristiken des OSD-Headers den angeforderten OSD-Anzeigecharakteristiken
genügen,
leitet die OSD-Display-Einheit 144 im Schritt 162 die
OSD-Pixelmap und die assoziierten Anzeigecharakteristika (die in
dem OSD-Header angegeben werden) zu dem Display-Prozessor 70. Wenn
die Anzeigecharakteristika des OSD-Headers nicht den angeforderten
OSD- Anzeigecharakteristiken genügen,
schreibt die OSD-Display-Einheit 144 im Schritt 164 die
Anzeigecharakteristika in dem abgerufenen OSD-Header um und/oder
zeichnet die OSD-Pixelmap neu, damit sie die angeforderten Anzeigecharakteristika
enthält,
bevor im Schritt 166 die (neu gezeichnete) OSD-Pixelmap
und der (umgeschriebene) assoziierte Header zu dem Display-Prozessor 70 weitergeleitet
werden. Das Umschreiben des OSD-Headers und/oder das Neuzeichnen
der OSD-Pixelmap führt zu
einer Verzögerung
zwischen der OSD-Anforderung von der Steuerung 115 und der
Anzeige der OSD mit den gewünschten
Anzeigecharakteristiken. Anders ausgedrückt können die zum Modifizieren des
OSD-Heaqders und der assoziierten OSD-Pixelmap erforderlichen mehreren Speicheranweisungen
zu einer Verzögerung
bei der Anzeige der OSD führen.
Es ist zu beachten, daß, wenn
die OSD-Anzeigeanforderung auftritt, wenn der Videoempfänger an
einem zeitkritischen Prozeß (z.B. der
Anzeige eines Videoprogramms) beteiligt ist, eine Verzögerung bei
der Anzeige der OSD dazu führen kann,
daß eine
Unterbrechung oder Verzerrung des Video (Einführung von Videoanomalien) einem
Benutzer angezeigt werden.
-
Nunmehr
mit Bezug auf 6 ist eine verbesserte OSD-Verwaltungs- und
Steueranordnung der vorliegenden Erfindung dargestellt. Die verbesserte
OSD-Verwaltungs- und Steueranordnung der vorliegenden Erfindung
verringert die Verzögerung, die
ansonsten bei Verwendung der herkömmlichen OSD-Verwaltungs- und
Steueranordnung von 3 auftreten würde, beträchtlich.
Gemäß der Anordnung der
vorliegenden Erfindung werden bei Initialisierung des Videoempfängers mehrere
OSD-Datenstrukturen in dem Speicher 67 gespeichert. Genauer
gesagt enthält
jede OSD-Datenstruktur der vorliegenden Erfindung eine in dem Pixelmap-Block 138 des
Speichers 67 gespeicherte OSD-Pixelmap und mehrere in dem
Header-Block 136 des Speichers 67 gespeicherte
assoziierte OSD-Header. Gemäß der OSD-Pufferungstechnik
der vorliegenden Erfindung werden also mehrere OSD-Header (z.B.
die Header "OSD
1a", "OSD 1b" und "OSD 1c") für jede OSD-Pixelmap (z.B. die
Pixelmap "OSD 1"), die in dem Pixelmap-Block 138 gespeichert
ist, in dem Header-Block 136 gespeichert. Jeder OSD-Header
enthält
die Speicherstelle der assoziierten OSD-Pixelmap und ein eindeutiges
Anzeigecharakteristikum oder eine Menge von Anzeigecharakteristika,
die definieren, wie die OSD-Pixelmap
auf der Anzeigeeinheit 75 angezeigt werden soll. 8 zeigt
eine beispielhafte Datenstruktur 190 mit mehrfachem OSD-Header 192 und
einzelner OSD-Pixelmap 194.
-
Nunmehr
mit Bezug auf 7 ist in Verbindung mit 6 ein
OSD-Abrufprozeß 170 der
vorliegenden Erfindung gezeigt. Zu Anfang empfängt die OSD-Anzeigeeinheit 144 im
Schritt 172 eine OSD-Anzeigeanforderung von der Steuerung 115. Als
Reaktion auf die Anforderung der Steuerung sendet die OSD-Anzeigeeinheit 144 im
Schritt 174 eine Speicherzugriffsanforderung zu dem OHP-Register 148.
Das OHP-Register 148 versorgt die Anforderung im Schritt 176 durch
Schreiben des OSD-Headers, der der gewünschten OSD-Bitmap entspricht und den angefordeten
Anzeigecharakteristika genügt,
in das MAF-Register 150. Im Schritt 158 liest die
OSD-Anzeigeeinheit 178 den OSD-Header, um die Speicherstelle der OSD-Pixelmap
in dem Pixelmap-Block 138 zu bestimmen. Nachdem die Pixelmap-Speicherstelle bestimmt
wurde, setzt die OSD-Anzeigeeinheit 144 die OSD-Adresse
in der Speichersteuerung 132 und fordert an, daß die Speichersteuerung 132 das
Bild an der gesetzten Adresse in das MAF-Register 150 einliest.
Danach leitet die OSD-Anzeigeeinheit 144 im Schritt 180 die
OSD-Pixelmap und
die assoziierten Anzeigecharakteristika (die in dem OSD-Header angegeben
werden) zu dem Anzeigeprozessor 70. Es sollte beachtet
werden, daß kein
Umschreiben des OSD-Headers oder Neuzeichnen der OSD-Pixelmap erfolgt,
da für
jede Pixelmap mehrere Header bereitgestellt werden. Vorzugsweise
gibt es soviele Header wie es Kombinationen von Anzeigecharakteristika
für die
assoziierte Pixelmap gibt. Somit kann eine OSD mit einer einzigen
Speicheranweisung aus der OSD-Anzeigeeinheit 144 aus dem
Speicher 76 abgerufen werden (anstelle der mehreren Anweisungen,
die ansonsten für das
Abrufen und Umschreiben eines OSD-Headers mit falschen Anzeigecharakteristika
erforderlich wären).
Das Bereitstellen mehrerer Header (wobei jeder Header ein eindeutiges
Anzeigecharakteristikum oder eine Menge von Anzeigecharakteristika
aufweist) für
jede Pixelmap ermöglicht
darüber
hinaus effiziente OSD-Auswahl,
OSD-Modifikation und OSD-Anzeige ohne Umschreibe- und/oder Neuzeichnungsverzögerung.
-
Obwohl
die vorliegende Erfindung mit Bezug auf die bevorzugten Ausführungsformen
beschrieben wurde, ist offensichtlich, daß verschiedene Änderungen
an den Ausführungsformen
vorgenommen werden können,
ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen,
der durch die angefügten
Ansprüche
definiert wird.