-
Die
vorliegende Erfindung betrifft allgemein die Videodatenverarbeitung
und insbesondere die Videodatenverarbeitung zur Anzeige einer Bitmap über Videobilder.
-
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. In solchen Systemen dient die OSD-Funktion zur Anzeige
von Bitmap-Bildern,
die dem Videobild auf einem TV-Display überlagert werden, um Informationen
zu übermitteln
oder Menüs
auf dem TV-Display anzuzeigen. Die OSD wird auf einer "Pixmap" im Speicher wiedergegeben, die
auf das TV-Display abgebildet wird. Diese OSD-Pixmap muß an jedem
Ort über
das Videobild genauso groß wie
die aktive Videoregion auf dem TV-Display sein.
-
In
bestimmten Systemen wechselt das Videoraster zwischen den Abtastratenbetriebsarten
2H und 2.14H auf der Basis des betrachteten Kanals. Die Größe der aktiven
Videoregion ist deshalb in jeder der beiden Betriebsarten verschieden.
Dadurch wird es notwendig, daß für jede Rasterbetriebsart eine
verschieden große
OSD-Pixmap verfügbar
ist. Zum Beispiel lautet im 2H-Modus die OSD-Größenanforderung 480 Zeilen × 2096 Pixel/Zeile
und im 2.14 Modus lautet die OSD-Größenanforderung
540 Zeilen × 1920
Pixel/Zeile. Der Grund dafür
besteht darin, daß der
OSD-Pixeltakt eine Funktion des Videorastertakts ist.
-
Aus
EP-A-1069770, veröffentlicht
am 17.1.2001, ist ein Ansatz zur Lösung dieses Problems bekannt,
der darin besteht, mehrere Pixmaps für mehrere Videobilder mit verschiedenen
Rastergrößen zu führen und
auf der Basis eines gewünschten
Anzeigemodus zu einer bestimmten Pixmap zu wechseln. Eine Unzulänglichkeit
eines solchen Ansatzes besteht jedoch darin, daß Speicherplatz verschwendet
wird, weil bei dem Ansatz alle OSD-Bitmaps mehrmals (einmal für jede Pixmap) wiedergegeben
werden. Eine weitere Unzulänglichkeit
eines solchen Ansatzes besteht darin, daß er das System verlangsamt,
weil die Pixmap-Wiedergabezeit vervielfacht wird.
-
Es
wird deshalb ein verbessertes Verfahren und System benötigt, das über mehrere
Videoraster mit verschiedenen Größen hinweg
eine einzige Pixmap verwendet. Die vorliegende Erfindung liefert ein
Verfahren und ein System zur Erfüllung
dieses Bedarfs.
-
Die
vorliegende Erfindung wird in den Ansprüchen definiert und liefert
ein Verfahren und ein System, das über mehrere Videoraster mit
verschiedenen Rastergrößen hinweg
eine einzige Pixmap verwendet. Im allgemeinen verwendet die vorliegende
Erfindung mindestens zwei Header (z.B. einen ersten Header und einen
zweiten Header) zur Auswahl verschiedener Teile einer einzigen Pixmap,
die angezeigt werden soll, auf der Basis verschiedener Rastergrößen. Jeder
der beiden Header zeigt auf eine einzige Pixmap. Als Reaktion auf
verschiedene Anzeigebetriebsarten ruft die vorliegende Erfindung selektiv
den ersten oder den zweiten Header auf, einen jeweiligen anzuzeigenden
Teil in der Pixmap zu wählen.
Dadurch kann über
mehrere Videoraster mit verschiedenen Rastergrößen hinweg eine einzige Pixmap
verwendet werden.
-
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 eine
verbesserte OSD-Anordnung der vorliegenden Erfindung; und
-
8 ein
Flußdiagramm
des Pixmap-Prozesses 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 korrigierten
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 15 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 bidirektionaler
Kommunikationen (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, Hilfssystemzeitsteuerungsinformationen
und programmspezifische Informationen, wie zum Beispiel Programminhaltseinstufung
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 Systemzeitsteuerungsinformationen umfassen eine Zeitreferenzanzeige
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 einem 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 eingeteilter 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 Zugriffsspeicher (RAM) 67 zusammen,
um die MPEG-kompatiblen paketierten Audio- und Videodaten aus der
Einheit 55 zu dekodieren 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 einzuteilen, 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 zusammen mit assoziierten
Subbilddaten repräsentieren,
werden 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
codierter Datenströme
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
als Beispiele.
-
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-kompatibler
elektronischer Programmanleitung.
-
Nunmehr
mit Bezug auf 2 werden der MPEG-Decodierer 65 und
der Video-RAM 67 ausführlicher
dargestellt. Der Decoder 65 enthält einen FIFO-Pufferspeicher 130,
der Videodatenpakete auf Bedarf in kleinen Segmenten aus dem Transportdecoder 55 empfängt und
diese über
die 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 Rahmenspeicherteil zum Speichern von Rahmen 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 Steuerungsschnittstelleneinheit 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 eine einzige Pixelmap 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 Speicherzugriffsfiles
(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 ein 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 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
Anzeigemerkmalen, 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 Anzeigemerkmalen, die definieren, wie die Pixelmap "OSD 1" verarbeitet und
angezeigt werden soll. Zu den Anzeigemerkmalen 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-Anzeigeanforderung 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 Anzeigemerkmale in dem abgerufenen
OSD-Header den Anzeigemerkmalen der OSD-Anzeigeanforderung genügen. Zum Beispiel
können
die Anzeigemerkmale 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 Anzeigemerkmale bestimmen, daß die assoziierte Pixelmap
als ein grünes
Bild in einem unteren Teil des Display 75 angezeigt wird.
Wenn die Anzeigemerkmale des OSD-Headers den angeforderten OSD-Anzeigemerkmalen
genügen,
leitet die OSD-Display-Einheit 144 im Schritt 162 die
OSD-Pixelmap und die assoziierten Anzeigemerkmale (die in dem OSD-Header
angegeben werden) zu dem Display-Prozessor 70. Wenn die
Anzeigemerkmale des OSD-Headers nicht den angeforderten OSD-Anzeigemerkmalen
genügen,
schreibt die OSD-Display-Einheit 144 im Schritt 164 die
Anzeigemerkmale in dem abgerufenen OSD-Header um und/oder zeichnet
die OSD-Pixelmap neu, damit sie die angeforderten Anzeigemerkmale
enthält,
bevor im Schritt 166 die (neugezeichnete) 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
Anzeigemerkmalen. Anders ausgedrückt können die
zum Modifizieren des OSD-Headers 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 Videos (z.B. Einführung von
Videoanomalien) einem Benutzer angezeigt werden.
-
Mit
Bezug auf 6 ist ein verbessertes OSD-Pixmaplayout
der vorliegenden Erfindung dargestellt. In dem verbesserten OSD-Pixmap-Layout kann
eine einzige OSD-Pixmap über
mehrere Videorastergrößen hinweg
angezeigt werden. Wie in 6 gezeigt, umfaßt das Pixmap-Layout
eine Pixmap 190, einen ersten Header 198, einen
zweiten Header 200 und einen OHP (OSD-Headerzeiger) 202.
Die Pixmap 190 umfaßt
typischerweise eine mittlere Region 192, in der Menüs, Anleitungen
und dergleichen angezeigt werden, und einen linken und einen rechten
Seitenteil, die zusammen als Seitenteile (194 und 196)
bezeichnet werden. Die Pixel, die zur Anzeige in den Seitenteilen
ausgewählt
werden, können
abhängig
davon, ob das darunterliegende Videobild, das angezeigt wird, im
4 × 3-
oder im 16 × 9-Format
vorliegt, als graue oder transparente Pixel spezifiziert werden.
Die Pixel, die in den Seitenteilen nicht gewählt werden, können entweder
als schwarze oder transparente Pixel spezifiziert werden. Für die Pixel in
dem nichtgewählten
Teil der Seitenteile können
bestimmte andere Farben verwendet werden, solange diese Farben nicht
die Horizontalaustastung stören. Folglich
ist die Pixmap 190 so ausgelegt, daß die Seitenteile der Pixmap
manipuliert werden können,
um die Größenunterschiede
zwischen den beiden Anzeigebetriebsarten zu kompensieren, während der
mittlere Teil des OSD-Bildes unverändert erscheint.
-
Genauer
gesagt wird sowohl für
den 2H- als auch für
den 2.14H-Modus eine einzige OSD-Pixmap 190 verwendet.
Die verschiedenen Teile der OSD-Pixmap werden zur Anzeige auf der
Basis der Anzeigebetriebsart ausgewählt, in der ein Kanal betrachtet
wird. Mit zwei getrennten Headern 198 und 200 werden
Anzeigemerkmale der OSD-Pixmap für den
2H- und den 2.14H-Modus spezifiziert. Im 2.14H-Modus wird der Header 198 ausgewählt, um auf
eine Region mit 540 Pixelzeilen mit 1920 Pixeln für jede der
540 Pixelzeilen zu zeigen. Im 2H-Modus wird der Header 200 gewählt, um
auf 480 Mittenpixelzeilen der Pixmap mit 2096 Pixeln für jede der
mittleren 480 Pixelzeilen zu zeigen. Die Größen der mittleren Regionen
sind im 2H- und im 2.14-Modus identisch, während die Größen der
gewählten
Teile der Seitenteile im 2H-Modus von denen im 2.14H-Modus verschieden
sind.
-
Im
2.14H-Modus müssen,
da nur 1920 Pixel pro Zeile anzuzeigen sind, nur den mittleren 1920
Pixeln der 2096 Pixel Farbwerte gegeben werden. Die übrigen Pixel
in dem nichtgewählten
Teil der Seitenteile werden entweder auf schwarz oder transparent gezwungen,
so daß der
sichtbare Bereich des Anzeigeschirms eine Region mit 540 Zeilen × 1920 Pixeln pro
Zeile ist. Da im 2.14H-Modus 1920 aktive Pixel pro Zeile vorliegen,
fließen
die schwarzen/transparenten Pixel außerhalb der mittleren 1920-Pixel-Region in die
Horizontalaustastung über.
Da diese Pixel entweder auf schwarz oder transparent gesetzt sind, stören sie
die Horizontalaustastung nicht. Es sollte beachtet werden, daß bestimmte
andere Farben für die
nichtgewählten
Teile in den Seitenteilen Verwendet werden können, solange diese Farben
die Horizontalaustastung nicht stören.
-
Nunmehr
mit Bezug auf 7 ist eine verbesserte OSD-Verwaltungs- und
Steueranordnung der vorliegenden Erfindung dargestellt. Gemäß der Anordnung
der vorliegenden Erfindung wird bei Initialisierung des Videoempfängers eine
OSD-Datenstruktur
in dem Speicher 67 gespeichert. Genauer gesagt enthält die OSD-Datenstruktur
der vorliegenden Erfindung eine einzige OSD-Pixmap, die in dem Pixelmapblock 138 des
Speichers 67 gespeichert wird. Als eine beispielhafte Implementierung
enthält die
Pixmap 540 Pixelzeilen, wobei jede der Pixelzeilen 2096 Pixel aufweist.
Die OSD-Datenstruktur enthält
außerdem
einen ersten Header und einen zweiten Header, die in dem Headerblock 136 des
Speichers 67 gespeichert werden.
-
Nunmehr
mit Bezug auf 8 ist in Verbindung mit 7 ein
beispielhafter Pixmap-Abrufprozeß 170 der vorliegenden
Erfindung gezeigt.
-
Im
Schritt 172 empfängt
die OSD-Display-Einheit 144 eine OSD-Anzeigeanforderung
von der Steuerung 115. Die Anzeigeanforderung enthält die Informationen
bezüglich
einer Anzeigebetriebsart, in der der Kanal betrachtet wird.
-
Auf
der Basis der OSD-Anzeigeanforderung bestimmt (oder detektiert)
die OSD-Display-Einheit 144 im Schritt 174 die
Anzeigebetriebsart in der Anzeigeanforderung.
-
Im
Schritt 176 sendet die OSD-Display-Einheit 144 als
Reaktion auf die Anzeigeanforderung einen Headerzeiger in das OHP-Register 148 auf
der Basis der detektierten Anzeigebetriebsart. Genauer gesagt zeigt
der gesendete Headerzeiger, wenn die detektierte Anzeigebetriebsart
der 2H-Modus ist, auf den ersten Header 198. Wenn die detektierte
Anzeigebetriebsart der 2.14H-Modus ist, zeigt der gesendete Headerzeiger
auf den zweiten Header 200.
-
Im
Schritt 178 versorgt das OHP-Register 148 die
Anforderung durch Abrufen des Headers und Schreiben des abgerufenen
Headers in das MAF-Register 150.
-
Im
Schritt 180 analysiert die OSD-Display-Einheit 144 den
abgerufenen Header, um die Speicherstelle der in dem Pixelmapblock 138 gespeicherten
Pixelmap zu bestimmen.
-
Nachdem
die Pixmapspeicherstelle bestimmt wurde, leitet die OSD-Display-Einheit 144 im Schritt 182 den
abgerufenen Header und die Pixmap zu dem Anzeigeprozessor 70.
Bei diesem Schritt wählt,
wie in 6 gezeigt, der abgerufene Header entweder die
mittleren 480 Pixelzeilen oder 540 Pixelzeilen aus der
Pixmap, abhängig
von der Anzeigebetriebsart, in der der Kanal betrachtet wird. Es
sollte beachtet werden, daß die
Seitenteile in diesem Schritt in zwei Teile aufgeteilt sind, wobei
einer der gewählte
Teil und der andere der nichtgewählte
Teil ist.
-
Im
Schritt 184 zeigt der Display-Prozessor 70 die
abgerufene Pixmap an. Genauer gesagt werden die Pixel in der mittleren
Region der Pixmap als Farbpixel angezeigt, die Pixel in dem gewählten Teil
der Seitenteile werden entweder als graue oder als transparente
Pixel angezeigt, und die Pixel in dem nichtgewählten Teil der Seitenteile
werden entweder als schwarze oder transparente Pixel angezeigt.
-
Als
Zusammenfassung kann die vorliegende Erfindung eine einzige Pixmap über mehrere
Videorastergrößen hinweg
anzeigen. Außer
der Speicherplatzersparnis verbessert die vorliegende Erfindung auch
die Anzeigegeschwindigkeit für
ein TV-System. Gewissermaßen
ist also "eine Größe für alle" eine passende Beschreibung
der Pixmap in der vorliegenden Erfindung. Es sollte beachtet werden,
daß, obwohl
die vorliegende Erfindung in bezug auf die Verwendung einer Pixmap
in N (N = 2) anzeigenden Betriebsarten beschrieben wurde, N auch
größer als
2 sein kann (N > 2).
Zum Beispiel werden für
beliebige N N Header vorliegen. Die vorliegende Erfindung kann detektieren,
welcher der N Anzeigebetriebsarten gerade angezeigt wird, und einer
der N Header kann entsprechend einen geeigneten Teil der Pixmap wählen. Solange
eine einzige Pixmap groß genug
ist, um die größte Rastergröße der N
Anzeigebetriebsarten abzudecken, kann die vorliegende Erfindung
also beliebige der N Anzeigebetriebsarten mit einer einzigen Pixmap
versorgen.