DE102008059270B4 - Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit - Google Patents

Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit Download PDF

Info

Publication number
DE102008059270B4
DE102008059270B4 DE200810059270 DE102008059270A DE102008059270B4 DE 102008059270 B4 DE102008059270 B4 DE 102008059270B4 DE 200810059270 DE200810059270 DE 200810059270 DE 102008059270 A DE102008059270 A DE 102008059270A DE 102008059270 B4 DE102008059270 B4 DE 102008059270B4
Authority
DE
Germany
Prior art keywords
video
data block
data
picture lines
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE200810059270
Other languages
English (en)
Other versions
DE102008059270A1 (de
Inventor
Juergen Haas
Manfred Meindl
Johannes Stoegmueller
Andreas Wasserbauer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Priority to DE200810059270 priority Critical patent/DE102008059270B4/de
Publication of DE102008059270A1 publication Critical patent/DE102008059270A1/de
Application granted granted Critical
Publication of DE102008059270B4 publication Critical patent/DE102008059270B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/24Systems for the transmission of television signals using pulse code modulation

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, aufweisend:
– Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock;
– Senden des Datenblocks;
– Empfangen des gesendeten Datenblocks; und
– Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen;
wobei die Verfahrensschritte Verbinden, Senden, Empfangen und Trennen vielfach durchgeführt werden mit zeitlichen Pausen zwischen dem jeweiligen Senden des jeweiligen Datenblocks bei aufeinanderfolgenden Durchführungen der Verfahrensschritte, um den Videodatenstrom aufgeteilt in eine Vielzahl von zeitlich voneinander getrennten Datenblöcken zu übertragen.

Description

  • Die Erfindung betrifft ein Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, betrifft ein Verfahren, eine Vorrichtung und ein Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und betrifft ein Verfahren, eine Vorrichtung und ein Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit.
  • Videodaten werden häufig unter Echtzeitbedingungen zwischen verschiedenen elektronischen Geräten oder zwischen verschiedenen Verarbeitungseinheiten innerhalb eines Geräts übertragen. Beispielsweise wird ein Videodatenstrom von einer Videokamera in Aufnahmebetrieb zu einer Steuerungseinheit (z. B. einem Prozessor oder Rechner) oder von einer solchen Steuerungseinheit zu einer Anzeigeeinheit in Wiedergabebetrieb (Display, Bildschirm) übertragen. Die beteiligten Geräte sind dabei als Sender bzw. Empfänger des Videodatenstroms aktiv, solange die Übertragung in Echtzeit andauert.
  • Es ist generell wünschenswert, eine Datenübertragung unter möglichst geringem Energieverbrauch der beteiligten Geräte bzw. Verarbeitungseinheiten zu ermöglichen. Beispielsweise ist bei einem mobilen elektronischen Gerät, das mit Batterie oder Akku betrieben wird, eine Energieeinsparung erwünscht, um die Laufzeit der Batterie bzw. des Akkus zu verlängern.
  • Aus dem Dokument DE 40 28 927 A1 ist ein Verfahren für die Codierung und Übertragung von Information bekannt, das beispielsweise für Telefax und Fernsehen vorgesehen ist.
  • Um eine Verkürzung der Übertragungszeit beziehungsweise eine Verringerung der benötigten Bandbreite zu erreichen, wird in dem Dokument DE 40 28 927 A1 eine Codierung der zu übertragenden Information mit einem Lauflängenzifferncode in Verbindung mit einer code-multiplexen Zusammenfassung von Zeilen vorgeschlagen.
  • Aus dem Dokument DE 29 39 230 C2 ist ein Verfahren zur Übertragung digitaler Daten im Zeitmultiplexbetrieb in einem für Fernsehbildübertragung geeigneten Kanal bekannt. Dabei wird eine Zuordnung von Datenkanälen zu Zeilen des Fernsehhalbbildes vorgenommen, welche eine effiziente und flexible Aufteilung der Bandbreite des Fernsehkanals in rückwärtskompatible Videotextkanäle und standardisierte Kabeltextkanäle ermöglichen soll.
  • Der Erfindung liegt die Aufgabe zugrunde, eine Gestaltung der Übertragung von Videodaten bereitzustellen, die unter Echtzeitbedingungen eine Verringerung des Energieverbrauchs der beteiligten Geräte ermöglicht.
  • Die Aufgabe wird durch die Verfahren und die Vorrichtungen gemäß den jeweiligen unabhängigen Patentansprüchen gelöst.
  • Ein Verfahren zum Übertragen eines Videodatenstroms in Echtzeit weist auf: Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock, Senden des Datenblocks, Empfangen des gesendeten Datenblocks und Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen.
  • Ein Verfahren zum Senden eines Videodatenstroms in Echtzeit weist auf: Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock und Senden des Datenblocks.
  • Eine Vorrichtung zum Senden eines Videodatenstroms in Echtzeit weist eine Kombiniereinheit auf, die eingerichtet ist zum Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock, und weist eine Sendeeinheit auf, die eingerichtet ist zum Senden des Datenblocks.
  • Ein Verfahren zum Empfangen eines Videodatenstroms in Echtzeit weist auf: Empfangen eines Datenblocks, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, die zu dem Datenblock verbunden sind, und Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen.
  • Eine Vorrichtung zum Empfangen eines Videodatenstroms in Echtzeit weist eine Empfangseinheit auf, die eingerichtet ist zum Empfangen eines Datenblocks, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, die zu dem Datenblock verbunden sind, und weist eine Separiereinheit auf, die eingerichtet ist zum Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen.
  • Anschaulich ausgedrückt, besteht ein Aspekt der Erfindung darin, daß mehrere Zeilen (Bildzeilen) eines Videodatenstroms zusammengefasst werden. Die Daten der betreffenden Zeilen verschmelzen zu einem einzigen großen Datenblock und die Zeiten dazwischen verschmelzen zu einem großen Intervall, das als Ganzes für Stromsparmodi zur Verfügung steht. Man kann es anschaulich auch so ausdrücken, daß mehrere physische Zeilen (physische Bildzeilen) einer Videoübertragung, die zu verschiedenen Zeitpunkten zur Übertragung fällig sind, zusammengefasst werden und gemeinsam übertragen werden, und dadurch günstigere Voraussetzungen geschaffen werden, eine Energieeinsparung zu ermöglichen.
  • Weitere Ausführungsbeispiele der Erfindung sind den abhängigen Patentansprüchen und der nachfolgenden Beschreibung zu entnehmen. Dabei gelten, wo anwendbar, die Erläuterungen zu den Verfahren auch sinngemäß für die Vorrichtungen und umgekehrt.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Senden ein Senden des Datenblocks ohne zeitliche Lücken zwischen den zwei oder mehr Bildzeilen.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Senden ein Senden des Datenblocks als ein einziger Datenburst.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Senden ein Senden des Datenblocks als eine virtuelle Bildzeile des Videodatenstroms. Anschaulich ausgedrückt, besteht ein Aspekt des Ausführungsbeispiels darin, daß mehrere physische Zeilen (physische Bildzeilen) eines Videodatenstroms zu einer virtuellen Zeile (virtuellen Bildzeile) zusammengefasst werden und diese virtuelle Zeile wie eine physische Zeile des Videodatenstroms gesendet wird.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Senden ein Beginnen des Sendens des Datenblocks zu einem Zeitpunkt, an dem eine im Videodatenstrom früheste Bildzeile der zwei oder mehr Bildzeilen zum Senden zeitlich fällig ist.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Senden ein Beenden des Sendens des Datenblocks vor einem Zeitpunkt, an dem eine im Videodatenstrom späteste Bildzeile der zwei oder mehr Bildzeilen zum Senden zeitlich fällig ist.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Verbinden ein Anordnen der zwei oder mehr Bildzeilen in dem Datenblock entsprechend einer gegebenen Reihenfolge der zwei oder mehr Bildzeilen in dem Videodatenstrom.
  • Gemäß einem Ausführungsbeispiel weist ein Verfahren weiterhin auf, dass vor dem Verbinden zu dem Datenblock die zwei oder mehr Bildzeilen mittels einer Echtzeit-Videoquelle erzeugt werden.
  • Gemäß einem Ausführungsbeispiel weist ein Verfahren weiterhin auf, dass es vielfach durchgeführt wird mit zeitlichen Pausen zwischen dem jeweiligen Senden des jeweiligen Datenblocks bei aufeinanderfolgenden Durchführungen des Verfahrens.
  • Gemäß einem Ausführungsbeispiel weist ein Verfahren weiterhin auf, dass ein zum Senden des Datenblocks benutzter Sendekanal während der zeitlichen Pausen in einen Energiesparmodus umgeschaltet wird.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Empfangen ein Empfangen des Datenblocks ohne zeitliche Lücken zwischen den zwei oder mehr Bildzeilen.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Empfangen ein Empfangen des Datenblocks als ein einziger Datenburst.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Empfangen ein Empfangen des Datenblocks als eine virtuelle Bildzeile des Videodatenstroms.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Empfangen ein Beginnen des Empfangens des Datenblocks zu einem Zeitpunkt, an dem eine im Videodatenstrom früheste Bildzeile der zwei oder mehr Bildzeilen zum Empfangen zeitlich fällig ist.
  • Gemäß einem Ausführungsbeispiel beinhaltet das Empfangen ein Beenden des Empfangens des Datenblocks vor einem Zeitpunkt, an dem eine im Videodatenstrom späteste Bildzeile der zwei oder mehr Bildzeilen zum Empfangen zeitlich fällig ist.
  • Gemäß einem Ausführungsbeispiel weist ein Verfahren weiterhin auf, dass nach dem Trennen des empfangenen Datenblocks die zwei oder mehr Bildzeilen mittels einer Echtzeit-Videosenke entgegengenommen werden.
  • Gemäß einem Ausführungsbeispiel weist ein Verfahren weiterhin auf, dass es vielfach durchgeführt wird mit zeitlichen Pausen zwischen dem jeweiligen Empfangen des jeweiligen Datenblocks bei aufeinanderfolgenden Durchführungen des Verfahrens.
  • Gemäß einem Ausführungsbeispiel weist ein Verfahren weiterhin auf, dass ein zum Empfangen des Datenblocks benutzter Empfangskanal während der zeitlichen Pausen in einen Energiesparmodus umgeschaltet wird.
  • Gemäß einem Ausführungsbeispiel folgen die zwei oder mehr Bildzeilen in dem Videodatenstrom unmittelbar aufeinander.
  • Gemäß einem Ausführungsbeispiel bestehen die zwei oder mehr Bildzeilen aus einer Anzahl von Bildzeilen, die eine ganze Zahl ist.
  • Gemäß einem Ausführungsbeispiel bestehen die zwei oder mehr Bildzeilen aus einer Anzahl von Bildzeilen, die eine Bruchzahl ist.
  • Gemäß einem Ausführungsbeispiel bestehen die zwei oder mehr Bildzeilen aus einer Anzahl von Bildzeilen, die eine Zahl aus dem Bereich von 2 bis 120 ist.
  • Gemäß einem Ausführungsbeispiel beinhalten die zwei oder mehr Bildzeilen alle Bildzeilen eines Bildes des Videodatenstroms.
  • Gemäß einem Ausführungsbeispiel weist eine Vorrichtung weiterhin eine Echtzeit-Videoquelle auf, die eingerichtet ist zum Erzeugen, vor dem Verbinden zu dem Datenblock, der zwei oder mehr Bildzeilen.
  • Gemäß einem Ausführungsbeispiel weist eine Vorrichtung weiterhin eine Echtzeit-Videosenke auf, das eingerichtet ist zum Entgegennehmen, nach dem Trennen des empfangenen Datenblocks, der zwei oder mehr Bildzeilen.
  • Gemäß einem Ausführungsbeispiel der Erfindung ist ein Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit vorgesehen, wobei, wenn das Computerprogrammprodukt von einem Prozessor ausgeführt wird, ein Verfahren gemäß einem der in dieser Anmeldung beschriebenen Ausführungsbeispiele des Verfahren zum Senden eines Videodatenstroms in Echtzeit durchgeführt wird. Das Computerprogrammprodukt kann einen auf einem maschinenlesbaren Träger gespeicherten Programmcode beinhalten. Gemäß einem weiteren Ausführungsbeispiel der Erfindung ist ein maschinenlesbarer Träger vorgesehen, auf dem ein Programmcode gespeichert ist, wobei, wenn der Programmcode von einem Prozessor ausgeführt wird, ein Verfahren gemäß einem der in dieser Anmeldung beschriebenen Ausführungsbeispiele des Verfahren zum Senden eines Videodatenstroms in Echtzeit durchgeführt wird.
  • Gemäß einem Ausführungsbeispiel der Erfindung ist ein Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit vorgesehen, wobei, wenn das Computerprogrammprodukt von einem Prozessor ausgeführt wird, ein Verfahren gemäß einem der in dieser Anmeldung beschriebenen Ausführungsbeispiele des Verfahren zum Empfangen eines Videodatenstroms in Echtzeit durchgeführt wird. Das Computerprogrammprodukt kann einen auf einem maschinenlesbaren Träger gespeicherten Programmcode beinhalten. Gemäß einem weiteren Ausführungsbeispiel der Erfindung ist ein maschinenlesbarer Träger vorgesehen, auf dem ein Programmcode gespeichert ist, wobei, wenn der Programmcode von einem Prozessor ausgeführt wird, ein Verfahren gemäß einem der in dieser Anmeldung beschriebenen Ausführungsbeispiele des Verfahren zum Empfangen eines Videodatenstroms in Echtzeit durchgeführt wird.
  • Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert.
  • Es zeigen
  • 1 Ablaufdiagramme verschiedener Verfahren gemäß Ausführungsbeispielen der Erfindung in einer gemeinsamen Darstellung;
  • 2 Blockdiagramme verschiedener Vorrichtungen gemäß Ausführungsbeispielen der Erfindung in einer gemeinsamen Darstellung; und
  • 3 den zeitlichen Verlauf bei der Übertragung eines Videodatenstroms gemäß einem Ausführungsbeispiel der Erfindung.
  • Im Rahmen dieser Beschreibung werden die Begriffe „verbunden”, „angeschlossen” sowie „gekoppelt” verwendet zum Beschreiben sowohl einer direkten als auch einer indirekten Verbindung, eines direkten oder indirekten Anschlusses sowie einer direkten oder indirekten Kopplung. In den Figuren sind identische oder ähnliche Elemente mit identischen Bezugszeichen versehen, soweit dies zweckmäßig ist.
  • 1 zeigt Ablaufdiagramme verschiedener Verfahren gemäß Ausführungsbeispielen der Erfindung in einer gemeinsamen Darstellung.
  • Das Ablaufdiagramm 100 illustriert in seiner Gesamtheit (Vorgänge 101, 102, 103, 104) ein Verfahren zum Übertragen eines Videodatenstroms in Echtzeit.
  • Anhand von 101 und 102 ist in 1 auch ein Ablaufdiagramm eines Verfahren zum Senden eines Videodatenstroms in Echtzeit dargestellt.
  • In 101 werden zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock verbunden.
  • In 102 wird der Datenblock gesendet.
  • Anhand von 103 und 104 ist in 1 auch ein Ablaufdiagramm eines Verfahren zum Empfangen eines Videodatenstroms in Echtzeit dargestellt.
  • In 103 wird im Fall des Verfahrens zum Übertragen eines Videodatenstroms der in 102 gesendete Datenblock empfangen. Im Fall des Verfahrens zum Empfangen eines Videodatenstroms wird in 103 ein Datenblock empfangen, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, die zu dem Datenblock verbunden sind.
  • In 104 wird der empfangene Datenblock in die jeweiligen zwei oder mehr Bildzeilen getrennt.
  • 2 zeigt Blockdiagramme verschiedener Vorrichtungen gemäß Ausführungsbeispielen der Erfindung in einer gemeinsamen Darstellung.
  • Ein Kameramodul 200 stellt ein Beispiel für eine Vorrichtung zum Senden eines Videodatenstroms in Echtzeit dar. Es weist eine Kombiniereinheit 205 auf, die eingerichtet ist zum Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock, und weist eine Sendeeinheit 210 auf, die eingerichtet ist zum Senden des Datenblocks. Die Kombiniereinheit 205 und die Sendeeinheit 210 können jeweils in Hardware (Elektronik) oder in einer Mischung aus Hard- und Software realisiert sein.
  • Das Kameramodul 200 enthält auch eine Videokamera 215, die eine optische Abbildung einer Szenerie als Videosignale (Videodaten) aufnehmen kann, was durch den Blockpfeil 220 symbolisiert wird. Die Videokamera 215 ist ein Beispiel für eine Echtzeit-Videoquelle, die eingerichtet ist zum Erzeugen, vor dem Verbinden zu dem Datenblock, der zwei oder mehr Bildzeilen. Ein anderes Beispiel für eine solche Echtzeit-Videoquelle ist ein Videomischer, der Videosignale in Echtzeit an einem seiner Ausgänge ausgibt.
  • Ein Bildschirmmodul 225 stellt ein Beispiel für eine Vorrichtung zum Empfangen eines Videodatenstroms in Echtzeit dar. Es weist eine Empfangseinheit 230 auf, die eingerichtet ist zum Empfangen eines Datenblocks, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, die zu dem Datenblock verbunden sind, und weist eine Separiereinheit 235 auf, die eingerichtet ist zum Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen. Die Empfangseinheit 230 und die Separiereinheit 235 können jeweils in Hardware (Elektronik) oder in einer Mischung aus Hard- und Software realisiert sein.
  • Das Bildschirmmodul 225 enthält auch ein Display (Bildschirm, Anzeigeeinheit) 240, das Videosignale (Videodaten) als optische Signale einem Betrachter darstellen kann, was durch den Blockpfeil 245 symbolisiert wird. Das Display 240 ist ein Beispiel für eine Echtzeit-Videosenke, die eingerichtet ist zum Entgegennehmen, nach dem Trennen des empfangenen Datenblocks, der zwei oder mehr Bildzeilen. Ein anderes Beispiel für eine solche Echtzeit-Videosenke ist ein Videomischer, der Videosignale in Echtzeit an einem seiner Eingänge entgegennimmt.
  • Der innere Aufbau des Bildschirmmoduls 225 ist beispielsweise derart ausgestaltet, daß die Videodaten mit einer weitgehend konstanten Datenrate zu dem Display 240 angeliefert werden müssen (harte Echtzeit). Die Empfangseinheit 230 und die Separiereinheit 235 können beispielsweise beide als Teile einer „display-frontend-hardware” 250 (eines in Hardware, d. h. als elektrische Schaltung, ausgeführten Dateneingangs für ein Display) aufgefaßt werden.
  • Die display-frontend-hardware 250 akzeptiert an der betreffenden Schnittstelle, mit welcher der Videodatenstrom durch das Bildschirmmodul 225 empfangen wird, die virtuelle Bildzeile mit der vollen Geschwindigkeit der Datenübertragung (weichere Echtzeit). Die display-frontend-hardware 250 stellt die Videodaten dann wie intern benötigt dem Display 240 zur Verfügung, d. h. sie liefert die nunmehr aus dem empfangenen Datenblock herausgetrennten einzelnen Bildzeilen mit der korrekten Datenrate (harte Echtzeit) an das Display 240.
  • Die display-frontend-hardware 250 kann beispielsweise aufgefaßt werden als ein (Daten-)Puffer mit Speicherplatz für ca. eine virtuelle Zeile sowie mit der für das Empfangen der virtuellen Zeile und das Trennen in die physischen Zeilen nötigen Logikschaltung. Bisherige Dateneingangsschaltungen für Displays, die als „display-Treiber-IC” (integrierte Schaltung zur Display-Ansteuerung) ausgeführt sind, sind häufig in ihrer Miniaturisierung durch die benötigte Anzahl an Bondpads (Anschlußkontaktflächen) begrenzt, d. h. das IC muß an seiner Peripherie eine gegebene Anzahl an Bondpads aufnehmen können und hat eine entsprechende Größe, während Halbleiterfläche im Inneren ungenutzt ist. In diesem Fall steht die bisher ungenutzte Halbleiterfläche zur Verfügung, um ohne Mehrkosten einen Puffer und eine Logikschaltung unterzubringen, die geeignet sind, die Dateneingangsschaltung als display-frontend-hardware 250 auszugestalten.
  • Ein Prozessor 255 stellt ein Beispiel für eine Vorrichtung dar, die sowohl zum Senden eines Videodatenstroms in Echtzeit eingerichtet ist als auch zum Empfangen eines Videodatenstroms in Echtzeit eingerichtet ist. Der Prozessor 255 enthält eine Kombiniereinheit 260, eine Sendeeinheit 265, eine Empfangseinheit 270 und eine Separiereinheit 275. Jede dieser Einheiten 260, 265, 270, 275 ist analog zu der ihr entsprechenden Einheit 205, 210, 230, 235 in dem Kameramodul 200 bzw. dem Bildschirmmodul 225 eingerichtet. Die Einheiten 260, 265, 270, 275 sind in diesem Ausführungsbeispiel kombiniert in Hard- und Software realisiert. Dazu wirken Softwareprogramme, die von dem Prozessor ausgeführt werden, beispielsweise mit den Eingabe- bzw. Ausgabekanälen der Datenbusse des Prozessors und/oder mit dedizierten Hardwareeinheiten zusammen.
  • Beispielhaft ist in 2 weiter gezeigt, daß der Prozessor 255 durch eine Datenleitung 280 (Videoschnittstelle) mit dem Kameramodul 200 gekoppelt ist und durch eine Datenleitung 285 (Videoschnittstelle) mit dem Bildschirmmodul 225 gekoppelt ist. Über die Datenleitung 280 empfängt der Prozessor 255 einen von dem Kameramodul 200 gesendeten Videodatenstrom. Über die Datenleitung 285 empfängt das Bildschirmmodul 225 einen von dem Prozessor 255 gesendeten Videodatenstrom. Weiter ist hier der Prozessor 255 durch eine Datenleitung 290 mit einem Speicher 295 zur Speicherung von Daten gekoppelt.
  • Beispielsweise kann der Prozessor 255 einen Videodatenstrom, der von der Videokamera 215 in Echtzeit erzeugt wird, von dem Kameramodul 200 entgegennehmen und unverzüglich (in Echtzeit) an das Bildschirmmodul 225 weitersenden, wo der Videodatenstrom von dem Display 240 in Echtzeit einem Betrachter dargestellt wird. Mit dem Begriff Echtzeit ist dabei nicht eine völlig verzögerungslose Übertragung gemeint, sondern es soll damit die Tatsache ausgedrückt werden, daß die Videodaten, beispielsweise die einzelnen Videozeilen, zu bestimmten Zeitpunkten zur Übertragung fällig sind. Unverzüglich bedeutet hier, daß die Videodaten ohne weitere Verzögerung gegenüber ihrem jeweiligen Fälligkeitszeitpunkt übertragen werden. Dadurch wird es ermöglicht, einen zusammenhängenden Videodatenstrom entgegenzunehmen bzw. weiterzusenden.
  • Beispielsweise kann der Prozessor 255 auch einen von der Videokamera 215 erzeugten und von dem Kameramodul 200 ausgesendeten Echtzeit-Videodatenstrom zunächst in dem Speicher 295 speichern. Der Prozessor kann dann zu einem späteren Zeitpunkt die gespeicherten Videodaten aus dem Speicher 295 abrufen und als Echtzeit-Videodatenstrom an das Bildschirmmodul 225 senden, wo der Videodatenstrom von dem Display 240 in Echtzeit, aber gegenüber der Aufnahme durch die Videokamera 215 zeitversetzt, einem Betrachter dargestellt wird.
  • Der Prozessor 255 ist beispielsweise ein Mikroprozessor, der in ein Mobilfunktelefon eingebaut ist, beispielsweise ein in einem Basisband-IC (IC = integrated circuit, integrierter Schaltkreis) integrierter Mikroprozessor. Das Kameramodul 200 und das Bildschirmmodul 225 sind beispielsweise in ein Mobilfunktelefon eingebaut.
  • 3 zeigt den zeitlichen Verlauf bei der Übertragung eines Videodatenstroms gemäß einem Ausführungsbeispiel der Erfindung.
  • Videodaten (z. B. von einer Kamera zum Prozessor oder vom Prozessor zur Anzeige) sind üblicherweise in eine Aufeinanderfolge von Bildern und diese wiederum in Zeilen und Spalten (matrixartig) organisiert. Beispielsweise besteht bei dem Videoformat des Typs „VGA” ein Bild aus 480 Zeilen zu je 640 Spalten. Eine Bildzeile enthält die Daten aller Bildspalten an den der Position der Zeile entsprechenden Stellen des Bildes. Die Bildzeilen zusammen ergeben ein Einzelbild (Vollbild oder Halbbild), die aufeinanderfolgenden Einzelbilder ergeben eine Videosequenz.
  • Im oberen Teil von 3 ist ein derartig organisierter Videodatenstrom 310 gezeigt. Dargestellt sind verschiedene zeitliche Abschnitte bei einer Echtzeit-Übertragung des Datenstroms entlang einer Zeitachse, die man sich als entlang der horizontalen Richtung der Zeichnungsebene nach rechts verlaufend vorstellen muß.
  • Der Beginn einer neuen Bildzeile ist jeweils durch kurze Header (Kopffelder) markiert, die als „Linestart” („Zeilenbeginn”) 320 bezeichnet sind. Die Daten der Bildzeilen sind jeweils als „Daten” 330 bezeichnet, sie folgen zeitlich unmittelbar auf den jeweils zugehörigen „Linestart” 320, sind also in der Zeichnung unmittelbar rechts von dem zugehörigen „Linestart” 320 dargestellt. Die „Daten” 330 beinhalten die Daten aller Bildspalten in der betreffenden Bildzeile.
  • Bei der Übertragung von Videodatenströmen müssen oftmals Echtzeitbedingungen eingehalten werden. Beispielsweise muß alle 20 bis 22 Mikrosekunden eine Zeile übertragen werden, d. h. in solchen Zeitabständen wird die jeweils nächste Zeile zur Übertragung fällig. Die „Härte” von Echtzeitanforderungen kann systemabhängig schwanken. Durch die „Härte” wird ausgedrückt, wie kritisch eine eventuelle Verzögerung (oder Vorauseilung) von zur Übertragung fälligen Daten ist. Bei einer „harten” Echtzeitanforderung können schon geringe zeitliche Verschiebungen zu Störungen, z. B. zu einer ruckelnden Bildwiedergabe, führen. In dem genannten Beispiel könnte man das auch so ausdrücken, daß generell alle 21 Mikrosekunden eine Zeile zur Übertragung fällig ist, wobei eine Vorauseilung und eine Verzögerung von je 1 Mikrosekunde toleriert werden können.
  • Durch Echtzeitanforderungen muss der Übertragungskanal in einem engen Zeitraster immer wieder aktiv sein (im Beispiel eben ca. alle 21 Mikrosekunden). Es ist nur während der zwischen den einzelnen Übertragungsvorgängen liegenden Phasen möglich, den Kanal (z. B. die Sende- und Empfangsschnittstellen) und die beim Senden und Empfangen beteiligten Einheiten (z. B. einen Prozessor oder einen Datenpufferspeicher) in energiesparende Betriebsarten zu schalten. Die mögliche Zeitdauer für Energiesparmodi ist in dem genannten Beispiel stets unter 22 Mikrosekunden und kann je nach Kanalbandbreite zwischen nahezu Null (Bandbreite reicht gerade aus, wobei eine kleine Sicherheitsmarge immer vorgehalten werden muß) und knapp 22 Mikrosekunden (Bandbreite ist vielfach überdimensioniert) liegen.
  • Bei dem Videodatenstrom 310 ist angenommen, daß die Kanalbandbreite rund doppelt so groß wie der für die Videodaten mindestens erforderliche Wert gewählt ist. Die hier für Energiesparmodi zur Verfügung stehenden Zeitphasen sind als „Stromsparmode” 340 dargestellt. Sie machen insgesamt etwas mehr als die Hälfte des zeitlichen Verlaufs bei der Echtzeit-Übertragung des Videodatenstroms 310 aus. Die Bereiche „Stromsparmode” 340 sind typisch nur ca. 10 Mikrosekunden lang und damit zu kurz, um etwa einen Taktgeber, beispielsweise einen Phasenregelkreis (PLL), des Senders, beispielsweise eines Mobilfunk-Basisband-ICs, abzuschalten und neu zu starten oder andere energiesparende Maßnahmen effektiv umzusetzen.
  • Im unteren Teil von 3 ist ein Videodatenstrom 350 gezeigt, der dieselben Videodaten („Daten” 330) wie der Videodatenstrom 310 und diese ebenfalls in Echtzeit überträgt, jedoch eine andere Aufteilung der einzelnen zeitlichen Abschnitte bei der Echtzeit-Übertragung aufweist.
  • In dem Videodatenstrom 350 sind jeweils vier Zeilen, die in dem Videodatenstrom 310 zeitlich getrennt übertragen werden, zu einer größeren „virtuellen Zeile” zusammengefasst. Der Beginn der virtuellen Zeilen ist jeweils der „Linestart” („Zeilenbeginn”) 360. Die Daten der virtuellen Zeilen sind in den jeweiligen Datenblöcken 370 enthalten, die aus den Daten von jeweils vier Zeilen des Videodatenstroms 310 gebildet sind. Durch das Zusammenfassen von jeweils vier physischen Zeilen wird z. B. aus einem physischen Bild vom Typ „VGA” mit 480 Zeilen zu je 640 Spalten ein virtuelles Bild mit 120 Zeilen zu je 2560 Spalten.
  • Die durchschnittliche Datenrate sowie die Datenrate während der übertragenen Datenbursts (zusammenhängenden Datensequenzen) sind bei beiden dargestellten Videodatenströmen 310 und 350 gleich groß. Die jeweils vier physischen Bildzeilen zugeordnete Gesamtzeit 380 ist in beiden Videodatenströmen 310 und 350 gleich groß. Die Bereiche „Stromsparmode” 390 des Videodatenstroms 350 umfassen jedoch ca. die vierfache Zeit gegenüber den entsprechenden Bereichen „Stromsparmode” 340 des Videodatenstroms 310.
  • Diese längere Zeit fördert ein zur Energieeinsparung führendes effektives Leistungsmanagement. Es wird eine Verringerung des Energieverbrauchs der beteiligten Geräte ermöglicht. Im Vergleich zu kurzen für Energiesparmodi zur Verfügung stehenden Phasen „Stromsparmode” 340, bei denen es aufgrund technischer Einschränkungen (Einschwingzeit eines Taktgebers, beispielsweise eines Phasenregelkreises (PLL), erforderliche Schaltzeiten für Stromversorgungen, usw.) nicht gelingt, das volle Potenzial an Leistungseinsparung auszuschöpfen, werden Energiesparpotenziale durch die längeren Zeitphasen „Stromsparmode” 390 besser nutzbar.
  • Je nach verwendeter (Halbleiter-)Technologie und (Schaltungs-)Architektur sind beim Stromverbrauch der beteiligten Geräte systemweit mittlere Einsparungen im Bereich von einigen mA zu erwarten. Dies kann sich zu beträchtlichen Einsparungen summieren, falls beispielsweise ein Display (Bildschirm) eines Geräts über eine längere Zeit mit einem Videodatenstrom in Echtzeit versorgt wird.
  • In dem Videodatenstroms 350 wurden die pro virtueller Zeile jeweils drei „Linestart” 320, welche aufgrund der dort nunmehr verbundenen „Daten” 330 bei eingehaltener Reihenfolge des Datenstroms im Innneren der Datenblöcke 370 angeodnet wären, entfernt. Sie sind sozusagen überflüssig, falls der Empfänger des Datenstroms in Kenntnis über die Anzahl der zu einer virtuellen Zeile zusammengefaßten physischen Zeilen ist, beispielsweise indem in den neuen „Linestart” 360 diese Information enthalten ist. Dadurch können die Zeitphasen „Stromsparmode” 380 noch etwas länger werden. Die virtuellen Zeilen können dabei standardkonform übertragen werden.
  • Es wäre jedoch alternativ auch möglich, alle zu verbindenden physischen Zeilen jeweils komplett mit „Linestart” 320 und „Daten” 330 zu den Datenblöcken 370 zu verbinden. Der „Linestart” 360 der virtuellen Zeile könnte dann die so quasi verpackten „Linestart” 320 als Nutzdaten kennzeichnen, d. h. für die Übertragung maskieren. Dadurch kann die virtuelle Zeile standardkonform übertragen werden und gleichzeitig wird das spätere Trennen in die physischen Zeilen erleichtert.
  • Ein zusätzlicher Nutzen hinsichtlich der Energieeinsparung ergibt sich bei den heute zunehmend anzutreffenden Übertragungskanälen, welche differenzielle serielle Hochgeschwindigkeitsleitungen verwenden. Im Gegensatz zu Schnittstellen, welche breite Busse von Leitungen in CMOS aufweisen, und bei denen aufgrund der Eigenschaften von CMOS (Leistungsverbrauch findet nur beim Schaltvorgang statt, kann quasi in Joule pro bit ausgedrückt werden) die Verteilung der übertragenen bits (Daten) über die Zeit kaum eine Rolle spielt, verbraucht ein differenzielles terminiertes Signal prinzipbedingt eine zeitlich konstante Leistung, die weitgehend unabhängig von der Datenrate ist (Leistungsverbrauch kann quasi in Joule pro Sekunde definiert werden). Wenn man bei differenziellen seriellen Leitungen die Daten in möglichst kurzen Datenbursts überträgt und dazwischen in energiesparende Betriebsmodi wechselt, kann man ein Einsparpotential nicht nur durch ein Abschalten, z. B. einen Schlafmodus, der beteiligten Geräte bzw. Verarbeitungseinheiten (z. B. eines Prozessors oder eines Datenpufferspeichers) realisieren, sondern bereits durch das zwischenzeitliche Abschalten der Datenübertragungsleitungen (z. B. der Sende- und Empfangsschnittstellen, Taktgeber usw.) ist eine Energieeinsparung möglich.
  • Ein weiterer Nutzen ergibt sich daraus, daß ein Datenblock, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, ohne aufwendige Anpassungen standardkonform übertragen (d. h. gesendet und empfangen) werden kann. Die Hersteller von Geräten, die Videodaten senden bzw. empfangen, könnten zwar bilateral beliebige Formate für Videodaten vereinbaren, jedoch werden solche Schnittstellen meist weitgehend standardisiert und setzen sich dann im Markt besser durch. Am traditionellen Ansatz mit Zeilen und Spalten in Echtzeit wird dabei stets festgehalten. Lösungen gemäß Ausführungsbeispielen der Erfindung können nun, bildlich gesprochen, quasi über bestehende Schnittstellen-Standards „gestülpt” werden, ohne diese zu verletzen. Definitionen von Standards, welche Formate, timing (Zeitablauf), usw. betreffen, können eingehalten werden. Nur das Bildformat wird nun eventuell ungewöhnlich breit. Die Bildbreite kann aber bei den Schnittstellen-Standards für Videoübertragung praktisch immer frei gewählt werden.
  • Eine weiterer Nutzen von Lösungen gemäß Ausführungsbeispielen der Erfindung ist, daß diese Lösungen in weiten Bereichen skalierbar sind. Es kann im Prinzip jede beliebige Anzahl N von Zeilen zusammengefasst werden. Typischerweise werden ganze Zahlen von N = 2 bis etwa N = 120 sinnvoll sein. Beispielsweise erhält man für N = 120 aus einem physischen Bild vonm Typ „VGA” mit 480 Zeilen zu je 640 Spalten ein virtuelles Bild mit 4 Zeilen zu je 76800 Spalten. Aber auch Bruchzahlen für N (z. B. könnte N = 3,75 sinnvoll sein, wenn ein vorhandener Zeilenpuffer für N = 4 zu klein ist, aber eine gewünschte Energiesparmaßnahme mit N = 3 noch nicht befriedigend realisiert werden kann) oder ein ganzes Bild (N = physische Zeilenzahl des Bilds, für Vollbild oder Halbbild) sind möglich. Daher kann abhängig von der verwendeten (Halbleiter-)Technologie (was z. B. die Kosten für zusätzlich erforderliche Datenpuffer beeinflußt) und der angestrebten Energieeinsparung eine wirtschaftlich optimale Lösung gefunden werden. Für N = 1 besteht sogar eine volle Rückwärts-Kompatibilität. Wenn N programmierbar gestaltet wird, ist also immer ein Zusammenspiel mit allen am Markt verfügbaren standardkonformen Geräten bzw. Video-Schnittstellen und praktisch beliebigen Ausgestaltungen der Übertragung von Videodaten in Echtzeit gewährleistet.

Claims (29)

  1. Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, aufweisend: – Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock; – Senden des Datenblocks; – Empfangen des gesendeten Datenblocks; und – Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen; wobei die Verfahrensschritte Verbinden, Senden, Empfangen und Trennen vielfach durchgeführt werden mit zeitlichen Pausen zwischen dem jeweiligen Senden des jeweiligen Datenblocks bei aufeinanderfolgenden Durchführungen der Verfahrensschritte, um den Videodatenstrom aufgeteilt in eine Vielzahl von zeitlich voneinander getrennten Datenblöcken zu übertragen.
  2. Verfahren zum Senden eines Videodatenstroms in Echtzeit, aufweisend: – Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem Datenblock; und – Senden des Datenblocks; wobei die Verfahrensschritte Verbinden und Senden vielfach durchgeführt werden mit zeitlichen Pausen zwischen dem jeweiligen Senden des jeweiligen Datenblocks bei aufeinanderfolgenden Durchführungen der Verfahrensschritte, um den Videodatenstrom aufgeteilt in eine Vielzahl von zeitlich voneinander getrennten Datenblöcken zu senden.
  3. Verfahren nach einem der Ansprüche 1 bis 2, wobei das Senden ein Senden des Datenblocks ohne zeitliche Lücken zwischen den zwei oder mehr Bildzeilen beinhaltet.
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das Senden ein Senden des Datenblocks als ein einziger Datenburst beinhaltet.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Senden ein Senden des Datenblocks als eine virtuelle Bildzeile des Videodatenstroms beinhaltet.
  6. Verfahren nach einem der Ansprüche 1 bis 5, wobei das Senden ein Beginnen des Sendens des Datenblocks zu einem Zeitpunkt, an dem eine im Videodatenstrom früheste Bildzeile der zwei oder mehr Bildzeilen zum Senden zeitlich fällig ist, beinhaltet.
  7. Verfahren nach einem der Ansprüche 1 bis 6, wobei das Senden ein Beenden des Sendens des Datenblocks vor einem Zeitpunkt, an dem eine im Videodatenstrom späteste Bildzeile der zwei oder mehr Bildzeilen zum Senden zeitlich fällig ist, beinhaltet.
  8. Verfahren nach einem der Ansprüche 1 bis 7, wobei das Verbinden ein Anordnen der zwei oder mehr Bildzeilen in dem Datenblock entsprechend einer gegebenen Reihenfolge der zwei oder mehr Bildzeilen in dem Videodatenstrom beinhaltet.
  9. Verfahren nach einem der Ansprüche 1 bis 8, weiterhin aufweisend: – Erzeugen, vor dem Verbinden zu dem Datenblock, der zwei oder mehr Bildzeilen mittels einer Echtzeit-Videoquelle.
  10. Verfahren nach einem der Ansprüche 1 bis 9, weiterhin aufweisend: – Umschalten eines zum Senden des Datenblocks benutzten Sendekanals in einen Energiesparmodus während der zeitlichen Pausen.
  11. Verfahren zum Empfangen eines Videodatenstroms in Echtzeit, aufweisend: – Empfangen eines Datenblocks, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, die zu dem Datenblock verbunden sind; und – Trennen des empfangenen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen; wobei die Verfahrensschritte Empfangen und Trennen vielfach durchgeführt werden mit zeitlichen Pausen zwischen dem jeweiligen Empfangen des jeweiligen Datenblocks bei aufeinanderfolgenden Durchführungen der Verfahrensschritte, um den Videodatenstrom aufgeteilt in eine Vielzahl von zeitlich voneinander getrennten Datenblöcken zu empfangen.
  12. Verfahren nach Anspruch 1 oder Anspruch 11, wobei das Empfangen ein Empfangen des Datenblocks ohne zeitliche Lücken zwischen den zwei oder mehr Bildzeilen beinhaltet.
  13. Verfahren nach Anspruch 1 oder einem der Ansprüche 11 bis 12, wobei das Empfangen ein Empfangen des Datenblocks als ein einziger Datenburst beinhaltet.
  14. Verfahren nach Anspruch 1 oder einem der Ansprüche 11 bis 13, wobei das Empfangen ein Empfangen des Datenblocks als eine virtuelle Bildzeile des Videodatenstroms beinhaltet.
  15. Verfahren nach Anspruch 1 oder einem der Ansprüche 11 bis 14, wobei das Empfangen ein Beginnen des Empfangens des Datenblocks zu einem Zeitpunkt, an dem eine im Videodatenstrom früheste Bildzeile der zwei oder mehr Bildzeilen zum Empfangen zeitlich fällig ist, beinhaltet.
  16. Verfahren nach Anspruch 1 oder einem der Ansprüche 11 bis 15, wobei das Empfangen ein Beenden des Empfangens des Datenblocks vor einem Zeitpunkt, an dem eine im Videodatenstrom späteste Bildzeile der zwei oder mehr Bildzeilen zum Empfangen zeitlich fällig ist, beinhaltet.
  17. Verfahren nach Anspruch 1 oder einem der Ansprüche 11 bis 16, weiterhin aufweisend: – Entgegennehmen, nach dem Trennen des empfangenen Datenblocks, der zwei oder mehr Bildzeilen mittels einer Echtzeit-Videosenke.
  18. Verfahren nach einem der Ansprüche 11 bis 17, weiterhin aufweisend: – Umschalten eines zum Empfangen des Datenblocks benutzten Empfangskanals in einen Energiesparmodus während der zeitlichen Pausen.
  19. Verfahren nach einem der Ansprüche 1 bis 18, wobei die zwei oder mehr Bildzeilen in dem Videodatenstrom unmittelbar aufeinander folgen.
  20. Verfahren nach einem der Ansprüche 1 bis 19, wobei die zwei oder mehr Bildzeilen aus einer Anzahl von Bildzeilen, die eine ganze Zahl ist, bestehen.
  21. Verfahren nach einem der Ansprüche 1 bis 19, wobei die zwei oder mehr Bildzeilen aus einer Anzahl von Bildzeilen, die eine Bruchzahl ist, bestehen.
  22. Verfahren nach einem der Ansprüche 1 bis 21, wobei die zwei oder mehr Bildzeilen aus einer Anzahl von Bildzeilen, die eine Zahl aus dem Bereich von 2 bis 120 ist, bestehen.
  23. Verfahren nach einem der Ansprüche 1 bis 21, wobei die zwei oder mehr Bildzeilen alle Bildzeilen eines Bildes des Videodatenstroms beinhalten.
  24. Vorrichtung zum Senden eines Videodatenstroms in Echtzeit, aufweisend: – eine Kombiniereinheit eingerichtet zum Verbinden von zwei oder mehr Bildzeilen eines Videodatenstroms zu einem jeweiligen Datenblock; und – eine Sendeeinheit eingerichtet zum Senden des jeweiligen Datenblocks; wobei die Sendeeinheit weiterhin eingerichtet ist zum Senden aufeinanderfolgender derartiger Datenblöcke mit zeitlichen Pausen zwischen den aufeinanderfolgenden Datenblöcken.
  25. Vorrichtung nach Anspruch 24, weiterhin aufweisend: – eine Echtzeit-Videoquelle eingerichtet zum Erzeugen, vor dem Verbinden zu dem Datenblock, der zwei oder mehr Bildzeilen.
  26. Vorrichtung zum Empfangen eines Videodatenstroms in Echtzeit, aufweisend: – eine Empfangseinheit eingerichtet zum Empfangen eines jeweiligen Datenblocks, der zwei oder mehr Bildzeilen eines Videodatenstroms enthält, die zu dem Datenblock verbunden sind; und – eine Separiereinheit eingerichtet zum Trennen des empfangenen jeweiligen Datenblocks in die jeweiligen zwei oder mehr Bildzeilen; wobei die Empfangseinheit weiterhin eingerichtet ist zum Empfangen aufeinanderfolgender derartiger Datenblöcke mit zeitlichen Pausen zwischen den aufeinanderfolgenden Datenblöcken.
  27. Vorrichtung nach Anspruch 26, weiterhin aufweisend: – eine Echtzeit-Videosenke eingerichtet zum Entgegennehmen, nach dem Trennen des empfangenen Datenblocks, der zwei oder mehr Bildzeilen.
  28. Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit, wobei, wenn das Computerprogrammprodukt von einem Prozessor ausgeführt wird, das Verfahren zum Senden eines Videodatenstroms in Echtzeit gemäß einem der Ansprüche 2 bis 10 oder einem der Ansprüche 19 bis 23 durchgeführt wird.
  29. Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit, wobei, wenn das Computerprogrammprodukt von einem Prozessor ausgeführt wird, das Verfahren zum Empfangen eines Videodatenstroms in Echtzeit gemäß einem der Ansprüche 11 bis 23 durchgeführt wird.
DE200810059270 2008-11-27 2008-11-27 Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit Active DE102008059270B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE200810059270 DE102008059270B4 (de) 2008-11-27 2008-11-27 Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE200810059270 DE102008059270B4 (de) 2008-11-27 2008-11-27 Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit

Publications (2)

Publication Number Publication Date
DE102008059270A1 DE102008059270A1 (de) 2010-06-10
DE102008059270B4 true DE102008059270B4 (de) 2011-02-10

Family

ID=42145356

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200810059270 Active DE102008059270B4 (de) 2008-11-27 2008-11-27 Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit

Country Status (1)

Country Link
DE (1) DE102008059270B4 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2939230C2 (de) * 1979-09-27 1982-08-12 Siemens AG, 1000 Berlin und 8000 München Verfahren zur Übertragung von Daten
DE4028927A1 (de) * 1990-08-07 1992-02-13 Dirr Josef Verfahren fuer die codierung und uebertragung von information, insbesondere von vorlagen und bildern und fuer das fernsehen

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2939230C2 (de) * 1979-09-27 1982-08-12 Siemens AG, 1000 Berlin und 8000 München Verfahren zur Übertragung von Daten
DE4028927A1 (de) * 1990-08-07 1992-02-13 Dirr Josef Verfahren fuer die codierung und uebertragung von information, insbesondere von vorlagen und bildern und fuer das fernsehen

Also Published As

Publication number Publication date
DE102008059270A1 (de) 2010-06-10

Similar Documents

Publication Publication Date Title
DE60312749T2 (de) Gerät zur Steuerung der DVI-Verbindung zwischen einer Hostvorrichtung und einem Monitor
DE112012002422B4 (de) System und Verfahren zum dynamischen Konfigurieren eines Serial-Daten-Links in einem Anzeigegerät
DE102007033471B4 (de) Schaltungsanordnung und Verfahren zur Ansteuerung segmentierter LED-Hintergrundbeleuchtungen
DE102015108057A1 (de) Aktualisierungsabhängiges adaptives Dithering für ein Display mit variabler Aktualisierungsrate
DE102012203916A1 (de) Verfahren und Apparat zum Steuern einer spärlichen Aktualisierung eines selbstaktualisierenden Anzeigegeräts, welches mit einer Grafiksteuerung gekoppelt ist
DE10336236A1 (de) Anzeigevorrichtung, Anzeigesystem und Kabel
DE19915020A1 (de) Steuerschaltung für ein Videoanzeigesystem und Verfahren zum Übertragen von Videodaten in einem Videoanzeigesystem
DE112015001145T5 (de) Komprimierter Videotransfer über eine Multimediaverbindung
DE102015115998A1 (de) Segmentierter Videocodec für Video mit hoher Auflösung und hoher Framerate
WO2018108666A1 (de) Teilnehmerstation für ein bussystem und verfahren zur datenübertragung in einem bussystem
DE112011105865T5 (de) Vorrichtung, System und Verfahren für das Bereitstellen von unabhängigem Multi Screen Viewing
DE102008059270B4 (de) Verfahren zum Übertragen eines Videodatenstroms in Echtzeit, Verfahren, Vorrichtung und Computerprogrammprodukt zum Senden eines Videodatenstroms in Echtzeit und Verfahren, Vorrichtung und Computerprogrammprodukt zum Empfangen eines Videodatenstroms in Echtzeit
DE102018121086A1 (de) Vorrichtungen, systeme und verfahren zum augenblicklichen videoschalten in einer erweiterungsumgebung
DE112010005619T5 (de) Dreidimensionale Bilderzeugung
DE112015002124T5 (de) Medienstromdaten und Kontrollparametersynchronisation
DE102018203969A1 (de) Automobile Kamera mit Rohbildsignalschnittstelle
DE102020110848B4 (de) Virtueller Kanal zum Verbinden von Vorrichtungen
DE60128257T2 (de) Serielle komprimierte busschnittstelle mit einer reduzierten pinanzahl
DE60208399T2 (de) Leistungsmanagement für den rückkanalverstärker eines kabelmodems
DE102013219140B4 (de) Paketsende- und Empfangsvorrichtung und Entwürfelungssystem
CN104394416A (zh) 一种实现mipi csi-2多通道低频传输的方法
CN105096799A (zh) 将多路画面中的各路画面进行独立调节的显示方法及系统
CN204559747U (zh) 一种高清led显示屏视频数据收发装置
DE102013201749A1 (de) Verfahren zum schnellen Umschalten zwischen alternativen Übertragungswegen
CN212302462U (zh) 多媒体控制设备

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R020 Patent grant now final

Effective date: 20110619

R081 Change of applicant/patentee

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS GMBH, 85579 NEUBIBERG, DE

Effective date: 20130315

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 85579 NEUBIBERG, DE

Effective date: 20130315

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 85579 NEUBIBERG, DE

Effective date: 20130314

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS TECHNOLOGY GMBH, 85579 NEUBIBERG, DE

Effective date: 20130326

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 85579 NEUBIBERG, DE

Effective date: 20130315

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS GMBH, 85579 NEUBIBERG, DE

Effective date: 20130315

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 85579 NEUBIBERG, DE

Effective date: 20130314

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS TECHNOLOGY GMBH, 85579 NEUBIBERG, DE

Effective date: 20130326

R081 Change of applicant/patentee

Owner name: INTEL DEUTSCHLAND GMBH, DE

Free format text: FORMER OWNER: INTEL MOBILE COMMUNICATIONS GMBH, 85579 NEUBIBERG, DE

R081 Change of applicant/patentee

Owner name: APPLE INC., CUPERTINO, US

Free format text: FORMER OWNER: INTEL DEUTSCHLAND GMBH, 85579 NEUBIBERG, DE