DE112019000271T5

DE112019000271T5 - Verfahren und vorrichtung zur verarbeitung und verteilung von live-virtual-reality-inhalten

Info

Publication number: DE112019000271T5
Application number: DE112019000271.6T
Authority: DE
Inventors: Wayne Cochran; Fai Yeung; Durga Raj Mathur; Gilson Goncalves de Lima; Patrick Youngung Shon; John A. Harrison; Ok Joon KIM; Harleen Gill; Kyle Siehl; Uma Jayaram; Sankar Jayaram; Archie Sharma; Gockcen Clingir; Stanley J. Baran; Mayuresh Varerkar; Barnan Das; Narayan Biswal; Nilesh V. Shah; Ritesh Kale; Greg L. Weinstein
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-02-07
Filing date: 2019-01-24
Publication date: 2020-09-10
Also published as: US11282169B2; CN111542862A; WO2019156819A1; US20200349672A1

Abstract

Eine Vorrichtung, ein System und ein Verfahren zum Erfassen, Verarbeiten und Verteilen von Panorama-Virtual-Reality-Inhalten (VR-Inhalten) sind beschrieben. Beispielsweise umfasst eine Ausführungsform eines Grafikprozessors eine Videoschnittstelle zum Empfangen einer ersten Mehrzahl Bilder von einer entsprechenden ersten Mehrzahl Kameras; einen Bildgleichrichter zum Durchführen einer perspektivischen Reprojektion von mindestens einigen aus der ersten Mehrzahl Bilder auf eine gemeinsame Bildebene zum Erzeugen einer gleichgerichteten ersten Mehrzahl Bilder; einen Stitcher zum Analysieren überlappender Regionen nebeneinanderliegender Bilder in der gleichgerichteten ersten Mehrzahl und zum Identifizieren entsprechender Pixel in den überlappenden Regionen und zum Zusammensetzen der nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines Panoramabilds, das eine zusammengesetzte Kombination der gleichgerichteten ersten Mehrzahl Bilder umfasst; und einen zylindrischen Projektor zum Projizieren des Panoramabilds auf eine zylindrische Fläche zum Erzeugen eines endgültigen Panoramavideobilds zur Verwendung bei der Umsetzung einer Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung.

Description

HINTERGRUND
Gebiet der Erfindung
Diese Offenbarung bezieht sich auf Videographie, Bilderfassung und Wiedergabe. Genauer bezieht sich diese Offenbarung auf Systeme und Verfahren für die Verarbeitung und von Live-Virtual-Reality-Inhalten.
Beschreibung des Stands der Technik
Es sind Techniken zum Erfassen und Ansehen von Panoramabildern bekannt. Die meisten Techniken umfassen ein Erfassungssystem, das eine Reihe von Bildern erfasst und verarbeitet, um Panoramabilder zu bilden. Sequenzen dieser Bilder bilden Panoramavideos. Techniken zum Anzeigen von Panoramabildern umfassen üblicherweise ein Benutzereingabeverfahren zum Anzeigen eines Abschnitts des Panoramabilds auf einer Anzeige, wodurch der Benutzer das Gefühl erhält, in der Lage zu sein, sich in dem Panoramabild umzuschauen. Weiterhin sind Techniken für Transportkontrollen unter Verwendung eines Puffers eines Live-Videofeeds bekannt. Diese Steuerungen erlauben einem Betrachter das Puffern eines Live-Feeds auf einer örtlichen Vorrichtung und das Vorspulen, Zurückspulen, Anhalten und Bild-für-Bild-Abspielen des gepufferten Videos.
Die obigen bekannten Techniken sind jedoch nicht ausreichend, und eine Vorrichtung und ein Verfahren werden benötigt, um einen Benutzer in die Lage zu versetzen, beide der oben genannten Fähigkeiten zu verwenden, um ein einmaliges Betrachtungserlebnis mit mehreren Panoramavideos zu ermöglichen.
Aktuelle Virtual-Reality-Ausstrahlungssysteme (VR-Ausstrahlungssysteme) existieren, sehen sich jedoch einer Vielzahl von Herausforderungen in Zusammenhang mit live Panorama-Virtual-Reality-Ausstrahlung (VR-Ausstrahlung) bezüglich der Verarbeitung von mehreren Videostreams unter strengen Zeitbeschränkungen gegenüber. Zum Erzeugen eines Panoramavideostreams, der für VR notwendig ist, müssen mehrere Sequenzen nebeneinanderliegender Videobilder, die durch entsprechende mehrere Videokameras erfasst sind, korrekt und effizient zusammengesetzt werden. In Hinblick auf die strengen Zeitbeschränkungen in einem Live-Ausstrahlungs-VR-System muss der Zusammensetzalgorithmus mehrere Zusammensetzungen nebeneinanderliegender Videostreams der gewünschten Bildwiederholrate entsprechend ausführen. Ist etwa die gewünschte Bildwiederholrate 60 fps, so müssen alle Zusammensetzungen für einen Satz Rahmen innerhalb von 0,017 Sekunden ausgeführt werden.
Eine andere Herausforderung ist die Bandbreitenmenge, die durch die mehreren High-Definition-Virtual-Reality-Streams über die VR Ausstrahlungsinfrastruktur (z. B. Server, Netzwerkverbindungen) hinweg verbraucht wird.
Figurenliste
Ein besseres Verständnis dieser Erfindung ist aus folgender ausführlicher Beschreibung in Verbindung mit den folgenden Zeichnungen zu entnehmen, wobei:

1 ist ein schematisches Diagramm, das einzigartige Ausführungsformen von Zeitcodesynchronisierungsmechanismen aufweist, die verwendet werden können, Rahmen, die vor der Verarbeitung und Verteilung durch Erfassungsstationen von mehreren Panoramakameraköpfen erfasst werden, zu synchronisieren.
2 ist ein schematisches Diagramm, das zeigt, wie mehrere Empfänger oder Empfangsmodule an einer Betrachtermaschine zeitgestempelte Rahmen von den Panoramavideofeeds empfangen, und soll die Benutzeroberfläche als die Zwischenanwendung für das Verwalten der Handhabung von Benutzereingabeanfragen und der Manipulation von Clients zum Ausführen der Benutzeranfrage zeigen.
3 ist ein schematisches Diagramm, das zeigt, wie mehrere Panoramavideofeeds an einem Client durch einen Empfänger empfangen werden können, und eine Benutzeroberfläche zeigt, die ebenfalls eine eingebaute Controllerfunktion aufweist.
4 ist ein Ablaufdiagramm, das die Schritte zeigt, die beteiligt sind, damit die Betrachtermaschine mehrere Panoramavideostreams empfängt, um die Rahmen von jedem Feed zu puffern und den Rahmen von dem Puffer, der dem Endbenutzer angezeigt werden soll, auf der sichtbaren Kamera und dem durch den Benutzer gewünschten Zeitstempel basierend zu bestimmen.
5 ist ein Ablaufdiagramm, das die Schritte zeigt, die an der Handhabung eines Kameraänderungsereignisses beteiligt sind, das durch den Benutzer ausgelöst wird.
6 ist ein Ablaufdiagramm, das die Schritte zeigt, die an der Handhabung eines Videowiedergabezustandsänderungsereignisses beteiligt sind, das durch den Benutzer ausgelöst wird.
7 ist ein Ablaufdiagramm, das die Schritte zeigt, die an der Handhabung eines Viewportänderungsereignisses beteiligt sind, das durch den Benutzer ausgelöst wird.
8-a und 8-b sind zwei Abschnitte eines Ablaufdiagramms, das zeigt, wie die Transportsteuerungsereignisse durch das System gehandhabt werden, und wie der Zeitstempel für den Rahmen, der dem Benutzer angezeigt werden soll, auf Grundlage des Videowiedergabezustands der Betrachteranwendung bestimmt wird.
9 zeigt, wie mehrere Panoramakameras strategisch an dem Ereignisort platziert sind und wie sie mit den Erfassungsstationen, Verarbeitungsstationen und dem Verteilerkanal verbunden sind.
10 illustriert eine Ausführungsform einer Architektur zur Erfassung und zum Streaming von Echtzeitvideo eines Ereignisses;
11 illustriert eine Ausführungsform, die Zusammensetzen unter Verwendung von Gleichrichtung gefolgt von zylindrischer Projektion ausführt;
12A bis D illustrieren eine Draufsicht von Operationen, die ausgeführt werden, um einen Panorama-Virtual-Reality-Videostream zu erzeugen;
13 illustriert eine Vorderansicht eines Untersatzes der Operationen, die ausgeführt werden, um einen Panorama-Virtual-Reality-Videostream zu erzeugen;
14 illustriert ein Verfahren nach einer Ausführungsform der Erfindung;
15 illustriert eine Ausführungsform, die Zusammensetzungsoperationen unter Verwendung von Annahmenpropagation ausführt;
16 illustriert eine Zusammensetzungsarchitektur, die Zusammensetzungsparameter von einem oder mehreren Rahmen verwendet, um einen aktuellen Rahmen zusammenzusetzen;
17 illustriert eine Ausführungsform, die Koordinatentransformationen ausführt, um Bandbreite und/oder Speicherung zu verringern;
18 illustriert ein Verfahren nach einer Ausführungsform der Erfindung;
19 illustriert eine Architektur für das Ausführen von Betrachtungstransformationen auf anzupassenden Virtual-Reality-Videostreams;
20 illustriert eine Ausführungsform, in der Schlüssel- und Füllersignale verwendet werden, um Inhalte in einen erfassten Videostream einzufügen;
21 illustriert einen Vergleich zwischen einer Mikroservices-Architektur und anderen Architekturen;
22 illustriert Mikroservices, die in die Architektur zur Erfassung und zum Streaming von Echtzeitvideo eines Ereignisses integriert sind;
23 illustriert eine spezifische Ausführungsform, in der Überwachungsmikroserviceabfrage Überwachungsanfragen an Sonden unter Verwendung von RPC vornehmen;
24 illustriert eine andere spezifische Ausführungsform, in der eine Abschlusswarteschlange die Kommunikation zwischen einem RPC-Server und einem RPC-Client unterstützt;
25 illustriert Sequenzen von Lesen-/Schreiben zwischen einem RPC-Server und einem RPC-Client;
26 illustriert eine Ausführungsform, in der ein Datenfeed eines Ausstrahlers durch einen Datenaggregator integriert wird; und
27 bis 29 illustrieren Beispiele einer grafischen Scoreboard-Benutzeroberfläche, die in Ausführungsformen der Erfindung umgesetzt ist.

AUSFÜHRLICHE BESCHREIBUNG
Diese Offenbarung wird zur Unterstützung der verfassungsmäßigen Zwecke der US-Patentgesetze vorgelegt „um den Fortschritt der Wissenschaft und der nützlichen Künste zu fördern“ (Artikel 1, Abschnitt 8).
Ausführungsformen dieser Erfindung offenbaren eine Vorrichtung und ein Verfahren zum Empfangen eines Videostreams von mehreren Panoramavideokameraköpfen oder von einer örtlichen Speicherfestplatte, Speichern der Videodaten in einem örtlichen Speicherpuffer und Betrachten von Regionen von Interesse innerhalb eines der Panoramavideos unter Verwendung von Benutzeroberflächenvorrichtungen, während die Videozeit, Wiedergabegeschwindigkeit und Wiedergaberichtung global über alle Panoramavideodaten hinweg synchron gesteuert werden. Nach einer Konstruktion sind mehrere Panoramavideokameraköpfe und durch einen Zeitcodegenerator synchronisiert, der die Bilderfassung über alle Kameraköpfe synchron auslöst. Nach einer anderen Konstruktion sind mehrere Kameraköpfe durch einen „Master“-Kamerakopf synchronisiert, der Auslösersignale an alle Kameraköpfe sendet. Ferner ist nach noch einer anderen Konstruktion jeder Kamerakopf auf „Freilauf“ mit einer vorgegebenen Bildwiederholrate eingestellt und die verarbeitenden Computer erfassen alle die den neuesten Rahmen von jeder dieser Kameras und versehen sie mit Zeitstempeln mit einem Zeitcode aus einem Zeitcodegenerator.
Verschiedene Ausführungsformen hierin sind mit Verweis auf die Figuren beschrieben. Bestimmte Ausführungsformen können jedoch ohne ein oder mehrere dieser spezifischen Details ausgeführt werden, oder in Kombination mit anderen bekannten Verfahren und Konfigurationen. In der folgenden Beschreibung sind zahlreiche spezifische Details dargelegt, wie etwa spezifische Konfigurationen und Verfahren usw., um ein eingehendes Verständnis dieser Offenbarung bereitzustellen. In anderen Instanzen wurden bekannte Konstruktionstechniken und Verfahren nicht ausführlich beschrieben, um diese Offenbarung nicht unnötig zu verschleiern. Ein Verweis in dieser Vorgabe auf „eine Ausführungsform“ bedeutet, dass ein bestimmtes Merkmal, eine Konfiguration, Komposition oder eine Eigenschaft, die in Verbindung mit der Ausführungsform beschrieben ist, in mindestens einer Ausführungsform umfasst ist. So verweist die Bezeichnung „in einer Ausführungsform“ an verschiedenen Stellen in dieser Vorgabe nicht notwendigerweise auf dieselbe Ausführungsform. Weiterhin können die bestimmten Merkmale, Konfigurationen, Kompositionen oder Eigenschaften in jeder geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert werden.
Wie hierin verwendet, wird der Begriff „Transportsteuerung“ als eine Benutzeroberfläche bedeutend verwendet, die einem Betrachter erlaubt, die Videowiedergabe zu steuern, wie etwa durch Wählen zwischen Abspielen, Pausieren, Zurückspulen und Vorspulen, und die Geschwindigkeit des Zurück- oder Vorspulens.
1 zeigt die Konstruktion des Zeitcodesynchronisierungsmechanismus 10, der sich über mehrere Panoramakameraköpfe 12, 14 und 18 und Erfassungsstationen 22, 24 und 25 erstreckt. Ein Zeitcodegenerator 20 wird verwendet, um einen konsistenten Zeitstempel basierend auf der gewünschten Rate zu erhalten, mit der Rahmen 50, 52 und 54 von den Panoramakameras 12, 14 und 18 erfasst werden müssen. Derselbe Zeitcode von Zeitcodegenerator 20 wird durch jede der Erfassungsstationen 22, 24 und 26 empfangen, und in einer der Ausführungsformen dieses Mechanismus wird der Zeitcode für trigger.sup.1 44, 46 und 48 der Panoramakameras 12, 14 und 18 verwendet. Dies wird auch als ein „Softwareauslöser“ 44, 46 und 48 der Panoramakameras 12, 14 und 18 bezeichnet. Die Panoramakameras 12, 14 und 18 erfassen bei Auslösen durch den Auslöser 44, 46 bzw. 48 einen Rahmen 50, 52 und 54 und geben den Rahmen 50, 52 und 54 an die entsprechenden Erfassungsstationen 22, 24 und 26 zurück, die den Auslöser 44, 46 und 48 erzeugt haben. Die Erfassungsstationen 22, 24 und 26 hängen die Zeitstempelinformationen aus dem Zeitcode an die Rahmen an, wodurch „Rahmen mit Zeitstempeln“ 56, 58 und 60 gebildet werden. Weil der Zeitcode zwischen den Erfassungsstationen 22, 24 und 26 geteilt wird, werden die Rahmen 56, 58 und 60, die von jeder der Erfassungsstationen 22, 24 und 26 für einen bestimmten Zeitcode erzeugt werden, synchronisiert, da sie denselben Zeitstempel aufweisen. Diese Rahmen 56, 58 und 60 werden dann an die Verarbeitungsstation 28, 30 bzw. 32 übertragen, wo sie für die Übertragung über das Netzwerk komprimiert und an einen Verteilerkanal 34 gesendet werden. Die Zeitstempelinformationen zu den Rahmen 56, 58 und 60 bleiben während dieses gesamten Verarbeitungs-, Kompressions- und Verteilungsprozesses erhalten. Die Verteilungsvorrichtung oder der Kanal (Switch) 34 ist konfiguriert, die verarbeiteten Bilder oder den komprimierten Videostream an Clientprozessoren in Clients 36, 38 und 40. Clients 36, 38 und 40 umfassen auch den Speicher.
Eine andere Ausführungsform des Zeitcodesynchronisierungsmechanismus 10 von 1 umfasst das Auslösen der Panoramakameraköpfe 12, 14 und 18 unter Verwendung eines „Hardware Sync-trigger.sup.2“ 42. Der Hardwareauslöser 42 wird zu bestimmen Zeitintervallen basierend auf der gewünschten Bildwiederholrate erzeugt. Diese Rate des Hardwareauslösens muss der Rate der Zeitcodes entsprechen, die durch den Zeitcodegenerator 20 erzeugt werden. Einer der Panoramakameraköpfe 12, 14 und 18 wirkt als ein „Master“ und alle anderen Panoramakameraköpfe 12, 14 und 18 wirken als „Slaves“. Die „Master“-Panoramakamera löst sich selbst und alle „Slave“-Panoramakameras synchron aus. Wenn ein Auslöser erzeugt wird, wird ein Rahmen an der Panoramakamera 50, 52 oder 54 erfasst. Wenn der Rahmen 50, 52 oder 54 erfasst wird, wird ein Ereignis an der Erfassungsstation 22, 24 oder 26 aufgerufen und dies ist der Zeitpunkt, zu dem die Erfassungsstation 22, 24 oder 26 den Rahmen von der Kamera 12, 14 oder 18 „greift“, und assoziiert den Zeitstempel, der dem neuesten Zeitcode entspricht, der von dem Zeitcodegenerator 20 erzeugt wird, mit dem Rahmen 50, 52 oder 54.
Eine dritte Ausführungsform des Zeitcodesynchronisierungsmechanismus 10 von 1 umfasst, die Panoramakameras 12, 14 und 18 Rahmen in einem „Freilauf“-Modus erfassen zu lassen, wobei jede der Panoramakameras 12, 14 und 18 so schnell wie möglich auslöst. Die Erfassungsstation 22, 24 und 26 verwendet das Zeitcodesignal zum „greifen“ der neuesten Rahmen 50, 52 oder 54, die durch die Panoramakamera 12, 14 oder 18 erfasst sind, und assoziiert den Zeitstempel, der dem Zeitcode entspricht, mit dem Rahmen.
2 zeigt mehrere Empfänger 64, 66 und 68 auf einer Clientmaschine 36, die zeitgestempelte Scheiben 78, 80 bzw. 82 von den Panoramavideofeeds über den Verteilerkanal 34 empfangen. Eine Benutzeroberfläche 70 auf der Clientmaschine 36 bestimmt, welcher Empfänger der aktive Empfänger 64, 66 oder 68 ist, der dem Benutzer dargestellt wird. Die Benutzerschnittstelle 70 verwaltet die Benutzerinteraktionseingabe von Vorrichtungen 62 wie einem Joystick 75, einer Tastatur 76 und einer oder mehreren Touch- oder Gestenbasierten Vorrichtung(en) 77. Die Benutzerschnittstelle 70 verwendet diese Eingabe, um zu bestimmen, welcher Clientstream der aktive Stream sein soll (Umschalten zwischen Videos 74), und welcher Abschnitt des Panoramavideos für den Endbenutzer angezeigt (Zoom/Tilt/Pan 73) werden soll. Eine andere Eingabe von den Benutzerinteraktionsvorrichtungen ist die Eingabe mit Transportsteuerung 72 verbunden. Die Benutzerschnittstelle 70 verwendet diese Eingabe und gibt sie an alle Empfänger weiter. Dies ermöglicht es allen Empfängern, dieselben Transportsteuerungsoperationen an ihren jeweiligen Panoramavideostreams auszuführen und stellt sicher, dass alle Panoramavideostreams synchronisiert sind.
3 zeigt eine andere Ausführungsform der Clientanwendung auf der Betrachtermaschine. In dieser Ausführungsform dient eine einzige Anwendung als die Empfänger und Benutzeroberfläche 84. Der Empfänger empfängt zeitgestempelte Rahmen für alle Panoramavideostreams über Verteilerkanal 34 und verwaltet jeden dieser Streams und seinen eigenen Anwendungsspeicher. Der Empfänger umfasst auch Verarbeitungsschaltungsanordnungen. Die Benutzerschnittstellenfunktionalität, die in 2 beschrieben ist, ist ebenfalls in diese Anwendung integriert. Wie in 2 beschrieben, verwaltet die Benutzeroberfläche die Eingabe von den Benutzerinteraktionsvorrichtungen 86 und führt die Aktionen durch, um zwischen Videos 89 umzuschalten, welcher Abschnitt des Panoramavideos dem Endbenutzer angezeigt werden soll (Zoom/Pan/Tilt 88) und wie die Transportsteuerung 87 auf alle Streams im Speicher angewendet werden soll.
Folgende Variablen sind mit dem Controllermodul für Empfänger und Benutzeroberfläche 84 gespeichert, die den Ansichtszustand bestimmen, der dem Endbenutzer angezeigt wird: a. Aktuelle Kamera für die Anzeige b. Aktueller Zeitstempel des anzuzeigenden Rahmens c. Aktueller Videowiedergabezustand--Mögliche Werte sind Play, Pause, Fast Forward, Rewind, Live d. Aktueller Viewport--Der Viewport wird durch die aktuellen Zoom-, Pan- und Tilt-Werte bestimmt.
Die Benutzerinteraktionsvorrichtungen 86 könnten die folgenden Arten von Ereignissen erzeugen, die durch den Empfänger und die Benutzeroberfläche 84 gehandhabt werden: a. Kameraänderungsereignis b. Ereignis Videowiedergabezustand geändert c. Ereignis Viewport geändert d. Ereignis Transportsteuerung
4 zeigt die Schritte, die an einer Betrachtermaschine beteiligt sind, um mehrere Panoramavideostreams zu empfangen und den Rahmen zu bestimmen, der dem Endbenutzer angezeigt wird. Die Rahmen von jedem Panoramavideostream, der von der Betrachtermaschine 102 empfangen werden, werden in Speicher (Festplattenlaufwerk, Anwendungsspeicher oder einer anderen Form von Speichervorrichtung) 104 gepuffert. Jeder Rahmen, der durch die Betrachtermaschine empfangen wurde, weist einen damit assoziierten Zeitstempel auf, der als der Schlüssel dient, um Rahmen über mehrere Panoramastreams hinweg zu synchronisieren. Wenn die Rahmen mit dem Puffern begonnen haben, tritt die Betrachteranwendung in eine Aktualisierungszyklusschleife ein, die mit einem „Warte-auf-Aktualisieren-Zyklus“ 106 beginnt. Der Aktualisierungszyklus ist ein periodischer Satz von Operationen, der durch die Anwendung bei jedem Aktualisierungsintervall der Anzeige ausgeführt wird. Die Anzeigeanwendung speichert die Information über die angezeigte Panoramakamera 108 und die Informationen zu dem Zeitstempel, der Drainregion auf dem Wiedergabezustand der Anwendung und Benutzereingaben die Transportsteuerung betreffend angezeigt werden soll. Für jeden der Aktualisierungszyklen prüft die Anwendung die aktuelle Panoramakamera, die angezeigt werden soll, und prüft dann auf den anzuzeigenden Zeitstempel 110. Unter Verwendung dieser beiden Informationen wird der korrekte anzuzeigende Rahmen aus dem Puffer im Speicher 112 gefunden. Dieser Rahmen wird dann an die Anwendung zur Anzeige 114 in dem Aktualisierungszyklus weitergegeben.
5 zeigt die Schritte, die an der Handhabung eines Kameraänderungsereignisses beteiligt sind, das durch den Benutzer ausgelöst wird. Eine erste Kamera wird standardmäßig verwendet oder definiert 202, nachdem ein Start 200 eingeleitet wird. Dann schaltet die Anwendung in einem ‚Horch‘-Modus 204, in dem sie auf Kameraänderungsereignisse 206 wartet, die durch die Benutzerinteraktionsvorrichtungen ausgelöst wurden. Wenn eine Anfrage für die Änderung der gewählten Kamera empfangen wird, wird die örtliche Variable in der Anwendung, die aktuelle Kamerainformationen speichert, aktualisiert 208, und die Anwendung schaltet zurück in den ‚Horch‘-Modus und wartet auf das nächste Kameraänderungsereignis.
6 zeigt die Schritte, die an der Handhabung des Videowiedergabezustandänderungsereignis beteiligt sind, das durch den Benutzer vom Start 300 aus ausgelöst wird. Ein erster Videowiedergabezustand 302 wird als Standard für den Start verwendet. Dann geht die Anwendung in einen ‚Horch‘-Modus 304, in dem sie auf Videowiedergabezustandsänderungsereignisse 306 wartet, die durch die Benutzerinteraktionsvorrichtungen ausgelöst wird. Wenn eine Anfrage für die Änderung des Videowiedergabezustands empfangen wird, wird die örtliche Variable in der Anwendung, die den aktuellen Videowiedergabezustand speichert, aktualisiert 308 und die Anwendung schaltet in den ‚Horch‘-Modus und wartet auf das nächste Videowiedergabezustandänderungsereignis.
7 zeigt die Schritte, die an der Handhabung des Viewportänderungsereignis beteiligt sind, die durch den Benutzer vom Start 400 ausgelöst wird. Der Viewport konnte durch Änderung des Zooms, Tilt oder Pan geändert werden. Ein erster Zoom, Tilt und Pan wird zu Beginn als Standard 402 verwendet. Dann geht die Anwendung in einen ‚Horch‘-Modus 404, in dem sie auf Viewportänderungsereignisse wartet, die durch die Benutzerinteraktionsvorrichtungen ausgelöst werden. Wenn eine Anforderung zum Ändern des Viewports empfangen wird, prüft die Anwendung, um zu sehen, ob der Wert für Zoom 410, Pan 406 oder Tilt 408 geändert wurde, und aktualisiert die örtlichen Variablen 416, 412 bzw. 414 in der Anwendung, die den Zoom, Pan und Tilt speichern. Die Anwendung geht dann wieder in den ‚Horch‘-Modus und wartet auf das nächste Viewportänderungsereignis.
8a und 8b zeigen, wie die Transportsteuerungsereignisse durch die Anzeigeanwendung gehandhabt werden, die am Start 500 eingeleitet wird. Die Anwendung horcht auf Transportsteuerungsänderungsereignisse 502. Die Anwendung prüft, um zu sehen, ob die Geschwindigkeit der Transportsteuerung geändert 504 wurde. Wenn die Geschwindigkeit geändert wurde, wird der Wert der Geschwindigkeit, der in der Anwendung gespeichert ist, aktualisiert 518, und die Anwendung schaltet wieder auf Horchen nach Transportsteuerungsänderungsereignissen. Wenn sich die Geschwindigkeit nicht geändert hat, prüft die Anwendung, um zu sehen, ob der Benutzer „Transport zu Start“ 506 angefordert hat, sodass sie den Start des gepufferten Videostreams im Speicher anzeigen. Wenn „Transport zu Start“ angefordert wurde, wird der Wert des aktuellen Zeitstempels zur Anzeige geändert, sodass er gleich ist wie der Zeitstempel des Rahmens am Start des Puffers im Speicher 520, und die Anwendung schaltet wieder auf Horchen auf Transportsteuerungsänderungsereignisse. Wenn „Transport zu Start“ nicht angefordert wurde, bestimmt die Anwendung den aktuellen Zeitstempel zur Verwendung für die Anzeige basierend auf dem Abspielzustand, in dem sich die Anwendung befindet. Wenn die Anwendung im Zustand „Play“ 508 ist, wird der aktuelle Zeitstempel auf den nächsten Zeitstempel 522 inkrementiert. Wenn sich die Anwendung im Zustand „Pause“ 520 befindet, wird der aktuelle Zeitstempel nicht geändert 524. Wenn sich die Anwendung im Zustand „Fast Forward“ 512 oder „Rewind“ 514 befindet, wird der aktuelle Zeitstempel inkrementiert 526 oder dekrementiert 528, wobei die Bildwiederholrate und Geschwindigkeit des Transports in Betracht gezogen wird. Wenn sich die Anwendung im Zustand „Live“ 516 befindet, wird der aktuelle Zeitstempel auf den Zeitstempel des Rahmens am Ende der gepufferten Rahmen im Speicher 530 gesetzt.
9 zeigt ein Footballfeld 90 als Ereignisort, wo mehrere Panoramakameras 12, 14, 16 und 18 an strategischen Stellen platziert sind, sodass sie unterschiedliche Blickwinkel eines Sportereignisses von bereitstellen und einem oder mehreren Endbenutzern erlauben, den Winkel zu wählen, der sich (für sie) am besten eignet, um das Ereignis zu jedem gegebenen Zeitpunkt zu betrachten. Jede der Panoramavideokameras 12, 14,16 und 18 ist mit einer Erfassungsstation 22, 24, 25 bzw. 26 verbunden. Jede Erfassungsstation 22, 24, 25 und 26 empfängt einen Zeitcode von einem Zeitcodegenerator und der Zeitstempel von dem Zeitcode wird an dem Rahmen befestigt, der von der Panoramavideokamera empfangen wird. Die Rahmen werden dann an die Verarbeitungsstationen 28, 30, 31 und 32 übertragen, wo sie verarbeitet und zum Verteilerkanal 34 ausgestreamt werden. Der Verteilerkanal 34 empfängt die Rahmen und kommuniziert die Rahmen über ein Netzwerk an mehrere Clients, die mit dem Verteilerkanal verbunden sind.
Eine Panoramavideoerfassungsvorrichtung wie hierin verwendet umfasst mehrere Sensoren, die in einem runden Array platziert sind, sodass sich ein Abschnitt des Bilds, das durch jeden Sensor erfasst wird, mit einem Abschnitt des Bilds überlappt, das durch angrenzende Sensoren erfasst wird. Die überlappenden Bilder von den verschiedenen Sensoren werden synchron basierend auf einem Auslösemechanismus erfasst, und diese überlappenden Bilder bilden die Grundlage für das Erstellen eines einzelnen nahtlosen Panoramabilds.
Wie hierin verwendet, ist ein Prozessor eine Hochleistungsmaschine von Serverqualität, die mehrere Grafikprozessoreinheiten (GPUs) enthält. Eine GPU ist in der Lage, eine große Anzahl von Operationen parallel auszuführen. Die Verwendung mehrerer GPUs in dem Prozessor erlaubt stark parallelisierte Berechnungen auf mehreren Bildrahmen, die durch die Panoramavideoerfassungsvorrichtung kommuniziert werden. Der Speicher kann auch vor Ort sein.
Ein Prozessor umfasst folgende Module. Erstens ist ein Erfassungsmodul zuständig für das Auslösen der Panoramavideoerfassungsvorrichtung und das Abrufen der Bildrahmen, sobald die Exposition des Rahmens vollständig ist. In bestimmten Ausführungsformen des Erfassungsmoduls erfolgt das Auslösen der Sensoren nicht durch dieses Modul. Es gibt einen separaten Auslösemechanismus für die Sensoren, und das Erfassungsmodul wird jedes Mal über das Ereignis informiert, wenn ein neuer Bildrahmen auf der Panoramavideoerfassungsvorrichtung verfügbar ist. Wenn diese Mitteilung durch das Erfassungsmodul empfangen wird, ruft es den Bildrahmen von der Panoramavideoerfassungsvorrichtung ab.
Wie hierin verwendet, ist ein Prozessormodul operativ, um den rohen Rahmen von dem Erfassungsmodul zu empfangen, und wendet die folgenden Filter auf den rohen Rahmen an: Entmosaiken-Filter: In diesem Filter wird ein Vollfarbbild unter Verwendung der unvollständigen Proben von den rohen Bildrahmen rekonstruiert. Farbfilter: Das Vollfarbbild, das von dem Entmosaiken-Filter ausgegeben wird, wird dann in einen geeigneten Farbraum (beispielsweise RGB) zur Verwendung in nachgelagerten Modulen konvertiert. Nahtverschmelzungsfilter: Farbige Bilder, die von dem Farbfilter ausgegeben werden, werden zum Verschmelzen der Naht unter Anwendung von Zusammensetzungsalgorithmen auf die Überlappung zwischen nebeneinanderliegenden Bildern verwendet.
Wie hierin verwendet, ist ein Splicing-Modul zuständig für die Verwendung der Bilder, die von dem Verarbeitungsmodul ausgegeben werden, und deren Zusammensetzung mit den Enden aneinander ausgerichtet, sodass die Gesamtheit dieser einzelnen Bilder ein Panoramabild schafft.
Und wie hierin verwendet, nimmt ein Slicingmodul das nahtverschmolzene Panoramabild und teilt das Bild in mehrere Scheiben. Dies erfolgt, sodass jede Scheibe des Panoramabilds in optimierter Weise über das Netzwerk verteilt werden kann. Dies überwindet die bestehenden Einschränkungen bestimmter Netzwerkprotokolle, die Panoramabilder über einer bestimmten Bildgröße kommunizieren können.
Wie hierin verwendet horcht ein Zeitstempelmodul auf einen Zeitcode von dem Zeitcodegenerator. Dieser Zeitstempel wird dann an jeder Scheibe der Bildabschnitte befestigt, die von dem Slicingmodul ausgegeben werden.
Wie hierin verwendet nimmt ein Kompressionsmodul die Bildrahmenausgabe durch das Zeitstempelmodul und komprimiert sie unter Verwendung bestimmter Bildkompressionstechniken (JPEG, H.264, etc.) zur Übertragung von über das Netzwerk.
Wie hierin verwendet ist eine Verteilungsvorrichtung eine Art von Router oder Switch, der zum Übertragen der komprimierten Rahmen über das Netzwerk verwendet wird. Mehrere Clients konnten sich mit der Verteilungsvorrichtung verbinden und die übertragenen Bildrahmen empfangen. Weiterhin könnten aufeinanderfolgende Verteilungsvorrichtungen selbst mit einer Verteilungsvorrichtung verbunden sein, die die Bilder zum Weiterleiten der Bilder über ein weites Netzwerk verteilt.
Wie hierin verwendet, verarbeitet ein Clientprozess die Kombination aus Unterprozessen und Modulen auf der Maschine eines Betrachters zum Empfangen von Bildrahmen von einer Verteilungsvorrichtung, Speichern derselben im Puffer, Verwalten der Benutzereingabe von den Benutzerinteraktionsvorrichtungen und Anzeigen der Videobilder für den Endbenutzer.
Die Clientprozess ist in die folgenden Module unterteilt:
Ein Empfängermodul, das sich über die Verteilungsvorrichtung mit der Quelle der Videobilder verbindet, empfängt die Bilder über das Netzwerk und speichert sie in einem Puffer auf der Maschine des Betrachters.
Ein Benutzeroberflächenmodul wird verwendet, um die Benutzereingaben von den Benutzerinteraktionsvorrichtungen zu verwalten. In einer der Umsetzungen des Benutzeroberflächenmoduls wird der, Joystickcontroller verwendet, um die Benutzereingaben zu erfassen. Die Benutzereingabe konnte unter Verwendung von Buttons auf dem Joystick oder unter Verwendung der mehreren Daumenpadsteuerungen am Joystick bereitgestellt werden. Verschiedene Buttons werden verwendet, um die Videowiedergabezustandsänderungseingabe zum Abspielen, Pausieren, Vorspulen, Zurückspulen oder Live-Moduls zu verfolgen. Eine Daumenpadsteuerung wird verwendet, um die Viewportänderungseingaben für Zoom, Pan, Tilt der Ansicht zu verfolgen. Eine andere Daumenpadsteuerung wird verwendet, um die Transportsteuerungseingabe für das schrittweise vor- oder zurückspulen basierend auf der Geschwindigkeit der schrittweisen Bewegung zu steuern, die dadurch bestimmt wird, wie weit die Daumenpadsteuerung gedrückt wurde.
Ein Anzeigemodul wird verwendet, um einen Abschnitt der Panoramavideorahmen für den Benutzer anzuzeigen. Der Abschnitt des Videorahmens, der angezeigt werden soll, wird basierend auf den Eingaben von dem Benutzeroberflächenmodul bestimmt. Ein Bildrahmen von dem Puffer wird abgerufen und basierend auf den anderen Benutzereingaben wird der anzuzeigende Abschnitt des Panoramabilds bestimmt. Dieser Abschnitt wird dann für den Endbenutzer zur Betrachtung angezeigt.
Unter Einhaltung des Gesetzes wurden Ausführungsformen der Erfindung in einer Sprache beschrieben, die mehr oder weniger spezifisch ist, was die strukturellen und methodischen Merkmale betrifft. Es versteht sich jedoch, dass die gesamt Erfindung nicht auf die spezifischen dargestellten und/oder beschriebenen Merkmale und/oder Ausführungsformen beschränkt ist, da die offenbarten Ausführungsformen Formen der Umsetzung der Erfindung umfassen. Die Erfindung wird daher in jeder ihrer Formen oder Modifikationen innerhalb des ordentlichen Umfangs der beiliegenden Ansprüche beansprucht, ordnungsgemäß ausgelegt nach der Äquivalenzdoktrin.
PANORAMAAUSSTRAHLUNGS-VIRTUAL-REALITY-ARCHITEKTUR (VR-ARCHITEKTUR)
10 illustriert ein Beispiel eines Panoramaausstrahlungs-Virtual-Reality-Systems (VR-System). Wie erwähnt, erfassen in einer Ausführungsform mehrere Stereoskopkameras 1001 ein Video eines Ereignisses aus verschiedenen Perspektiven (z. B. kein Sportereignis, eine Musikaufführung, eine Theateraufführung usw.) und die Stereoaudioerfassungseinheit 1002 erfasst und codiert zeitgleich Ton 1003 des Ereignisses. In einer Umsetzung sind die sechs Paare Stereoskopkameras auf einer Videoerfassungsvorrichtung 1001 (hierin bezeichnet als eine Erfassungs-POD) integriert, und eine beliebige Anzahl solcher Videoerfassungsvorrichtungen 1001 wird an verschiedenen Ereignisorten verteilt, um Video aus verschiedenen Perspektiven zu erfassen. Wie hierin verwendet ist eine Stereoskopkamera typischerweise als zwei Kameras umgesetzt: eine zum Reproduzieren der Perspektive des linken Auges und eine zum Reproduzieren der Perspektive des rechten Auges. Wie nachfolgend erklärt, kann jedoch in bestimmten Ausführungsformen (z. B. wenn eine Bandbreitenverringerung erforderlich ist) nur das Video des linken (rechten) Auges erfasst werden und der rechte (linke) Stream kann durch eine Ausführen einer Transformation auf den linken (rechten) Videostream reproduziert werden (d. h. unter Verwendung der Koordinatenbeziehung zwischen den linken und rechten Augen eines Benutzers sowie der Koordinaten des Ereignisses).
Während bestimmte hierin beschriebene Ausführungsformen sechs Stereoskopkameras in jeder Vorrichtungs-POD verwenden, kann eine beliebige Anzahl von Paaren Stereoskopkameras verwendet werden, während die zugrundeliegenden Grundsätze der Erfindung eingehalten werden (z. B. 10 Paar/POD, 12 Paar/POD usw.).
In einer Ausführungsform umfasst der durch jede Erfassungs-POD erzeugte Videostream unabhängig davon, wie die Kameras 1001 konfiguriert sind, ein 8-bit-Bayer-Mosaik an mit 12 Splits (d. h. 12 verschiedene Bildstreams von den 6 Kamerapaaren). Eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1005 verarbeiten dann den Videostream in Echtzeit wie hierin beschrieben, um einen Panorama-VR-Stream zu erzeugen. In der illustrierten Ausführungsform führt die GPU 1005 verschiedene Bildverarbeitungsfunktionen aus, einschließlich, aber nicht beschränkt auf, Mosaikentfernungsoperationen, Zuschneiden zum Entfernen redundanter Abschnitte nebeneinanderliegender Videostreams, Linsenverzerrungsverringerung, Farbanpassungen und Bildrotationen.
Nach der Bildverarbeitung führt die GPU 1005 eine Zusammensetzungsverarbeitung 1006 auf nebeneinanderliegende Bildrahmen aus, um ein zusammengesetztes Panoramabild zu erzeugen. Ein Beispiel der Zusammensetzungsverarbeitung 1006, das in 11 illustriert ist, umfasst Gleichrichtungsoperationen 1102, Zusammensetzungsoperationen 1104 und zylindrische Projektionsoperationen 1106. Insbesondere illustriert 11 eine spezifische Umsetzung des Zusammensetzens unter Verwendung von 5 Bildstreams zum Erzeugen des Panoramabildstreams. Es wird angenommen, dass die 5 illustrierten Streams für ein Auge (z. B. das linke Auge) verarbeitet werden, und dass derselbe Satz Operationen gleichzeitig für das andere Auge (z. B. das rechte Auge) ausgeführt wird.
Die markierten Regionen 1101A bis B von zwei der Bilder in der oberen Bildreihe 1101 zeigt die überlappenden Abschnitte jedes Bilds an, die verwendet werden, um die Zusammensetzung zu identifizieren. In einer Ausführungsform ist die Breite dieser Regionen auf einen Bruchteil der Gesamtbreite jedes Bilds eingestellt (z. B. 1/4, 1/3, 1/2). Die ausgewählten Regionen umfassen überlappenden Videoinhalt aus nebeneinanderliegenden Bildern. In einer Ausführungsform richtet die GPU das linke Bild an dem rechten Bild aus, indem es diesen Inhalt analysiert und abgleicht. Beispielsweise führt eine Umsetzung einen 2D-Vergleich der Pixelinhalte in jeder Pixelzeile aus. Ein oder mehrere Merkmalspunkte aus einer ersten Bildregion (z. B. 1101A) kann identifiziert und verwendet werden, um entsprechende Merkmalspunkte in der zweiten Bildregion (z. B. 1101B) zu identifizieren. In anderen Umsetzungen (von denen einigen nachfolgend beschrieben sind) kann ein komplexeres Abgleichsmodell wie Annahmenpropagation verwendet werden.
Bildgleichrichtung 1102 erfolgt, wobei die Bilder 1103 auf eine gemeinsame Bildebene projiziert werden. Nach der Gleichrichtung verwendet ein Stitcher 1104, der durch die GPU umgesetzt ist, die genannten Regionen nebeneinanderliegender gleichgerichteter Bilder 1103 zum Abgleichen von Pixeln (nach einem vorgegebenen Abgleichsalgorithmus) und Identifizieren der korrekten Ausrichtung und Überlappung zwischen den gleichgerichteten Bildern 1103. Wenn die Bildüberlappung/-ausrichtung identifiziert ist, kombiniert der Stitcher 1104 jedes nebeneinanderliegende Bild zum Bilden mehrerer zusammengesetzter, gleichgerichteter Bilder 1105. Wie illustriert gibt es in dieser bestimmten Umsetzung zwei 1/2-Bildabschnitte 1105A bis B, die an jedem Ende des Panoramavideos zurückbleiben.
Ein zylindrischer Projektor 1106 projiziert dann die zusammengesetzten Bilder 1105 auf eine virtuelle zylindrische Fläche, um eine glatte, konsistente Ansicht für den Endbenutzer in dem letzten Panoramavideobild 1107 zu bilden.
Die oben beschriebene Ausführungsformen kann in Software, die auf der/den GPU(s) 1005 ausgeführt wird, durch eine Festfunktionsschaltungsanordnung und/oder eine Kombination aus Software und Festfunktionsschaltungsanordnung (wo z. B. einige Stufen in Hardware und andere in Software umgesetzt sind) umgesetzt werden. Wenn auch in den Figuren nicht illustriert, können die Daten für jedes Bild in einem Systemspeicher, einem Cachinguntersystem auf der/den GPU(s) 1005, einem örtlichen GPU-Speicher und/oder einer GPU-Registerdatei gespeichert werden.
12A-E illustrieren die Wirkungen dieser Operationssequenz auf die Videobilder von einer erhöhten Perspektive (d. h. mit Blick nach unten in einer Richtung parallel zu den Bildebenen). Insbesondere illustriert 12A sechs Eingabebilder {L_i}⁵ _i=0. In einer Ausführungsform erfolgt eine Korrektur der Linsenverzerrung an den Eingabebildern in dieser Stufe.
In 12B, ist jedes Bild vertikal in halbiert (ai, bi) = split(Li) und in 12C, ist jedes Paar (b_i, a_i+1)⁴ _i=0 durch eine „virtuelle Drehung“ um die x-Achse jeder Ansicht gleichgerichtet (was einer Homographieoperation entspricht). Die beiden Endabschnitte A₀ und B₀ werden ebenfalls gedreht, sind jedoch nicht an dem Zusammensetzen beteiligt. Folgender Code gibt die Operationen einer Ausführungsform an:

for i= 0 ...4
B_i = rectify (b_i, α, left) (α wird empirisch bestimmt)
A_i+1 = rectify(a_i+1, α, right)
A₀ = rectify(a₀, α, right)
B₅ = rectify (bs, α, left)

12D zeigt das Zusammensetzen gleichgerichteter Paare S_i+1 = Stitch(B_i, A_i+1)⁴ _i=0 nach einer Ausführungsform. Es ist zu beachten, dass dies eine „Falte“ an den ursprünglichen Bildmitten verursacht, aber numerisch ausreichend genau ist, um keine „Naht“ zu verursachen. In einer Ausführungsform werden diese Falten durch die zylindrische Projektion in der nächsten Operation entfernt (12E). Im Gegensatz erzeugten frühere Zusammensetzungspipelines falten an der Zusammensetzung, was zu unerwünschter Verzerrung und einer geringeren Qualität der Zusammensetzung führte.
Wie in 12E illustriert, erfolgt eine volle zylindrische Projektion auf die fünf zusammengesetzten Bilder und „halbe“ Zylinderprojektionen für die beiden Endbilder. Dies dadurch dargestellt, dass Bildrahmen S₁ bis S₅ um den virtuellen Zylinder gebogen ist, um C₁ bis C₅ zu bilden, und der Endbildrahmen A₀ und B₅ ähnlich gebogen sind, um C₀ bzw. C₆ zu bilden. Die sieben entstehenden Bilder sind miteinander verkettet, um das endgültige Panoramabild zu bilden, das dann durch die verbleibenden Stufen der Pipeline verarbeitet wird.
13 illustriert eine andere Perspektive unter Verwendung eines vereinfachten Satzes Bilder 1301 bis 1306 (d. h. mit drei Kameras erfasst). Bild 1301 zeigt die Anordnung von Kameras, die verwendet sind, den Videorahmen zu erfassen, der in Bild 1302 gezeigt ist (Überlappung nicht dargestellt). Jedes Bild ist in Bild 1303 vertikal geteilt. In Bild 1304 wird jedes Bild unter Verwendung einer Homographietransformation transformiert, die eine perspektivische Reprojektion ist, die benachbarte Bildebenen effektiv dreht, sodass sie parallel sind (siehe z. B. 12C). Dies richtet die Bilder gleich, die dem Stitcher zugeführt werden, sodass gemeinsame Merkmale entlang derselben Bildzeilen ausgerichtet sind, was eine wichtige Operation für schnelle und genaue Zusammensetzung ist.
In Bild 1305 sind benachbarte Bilder entlang ihrer überlappenden Regionen zusammengesetzt. Es ist zu beachten, dass die Homographie in „Falten“ entlang der ursprünglichen Bildmittellinien erzeugt. Schließlich zeigt Bild 1306 eine zylindrische Projektion, die verwendet wird, um das abschließende Panorama zu erzeugen
Zurück zur allgemeinen Architektur, die in 10 dargestellt ist, führt dir GPU 1005 nach der Gleichrichtung, Zusammensetzen und zylindrischen Projektion RGB-in-YUV-Konvertierung durch, um 6 Splits (siehe z. B. 1107 in 11 durch). In einer Ausführungsform wird ein NV12-Format verwendet, wobei jedoch die zugrundeliegenden Grundsätze der Erfindung nicht auf ein bestimmtes Format eingeschränkt sind. In der illustrierten Umsetzung codiert ein Bewegungs-JPEG-Encoder 1007 die Bildrahmen 1107 unter Verwendung von Motion-JPEG (d. h. unabhängiges Codieren jedes Bildrahmens ohne Zwischenrahmendaten wie durch andere Videokompressionsalgorithmen wie MPEG-2) verwendet.
Die codierten/komprimierten Videorahmen, die durch den MJPEG-Encoder 1007 erzeugt werden, werden durch den Real-Time-Transport-Protocol-Paketisierer (RTP-Paketisierer) 1008 paketisiert und in einem Puffer 1009 gespeichert, bevor sie über eine Netzwerk-/Kommunikationsverbindung an den RTP-Entpaketisierer 1010 übermittelt werden. Während RTP verwendet wird, die codierten/komprimierten Videorahmen in dieser Ausführungsform zu kommunizieren, sind die zugrundeliegenden Grundsätze der Erfindung nicht auf ein bestimmtes Kommunikationsprotokoll beschränkt.
Die entpaketisierten Videorahmen werden einzeln durch den MJPEG-Decoder 1011 decodiert und basierend auf gewünschten Skalierungsvorgaben skaliert 1012 (z. B. in einer Ausführungsform auf eine Höhe von 800 Pixeln). Die skalierten Ergebnisse werden temporär in einem Synchronisationspuffer 1013 gespeichert. Ein Aggregator 1014 kombiniert mehrere Videostreams, potenziell aus verschiedenen Erfassungs-PODs 1001, und speichert die kombinierten Streams in einem temporären Speicher 1015 (z. B. wie etwa den hierin beschriebenen Overlaypuffer).
In einer Ausführungsform codiert ein H.264-Encoder 1016 die Videostreams zur Übertragung an Endbenutzer und ein Muxer- & Dateischreiber 1017 erzeugt Videodateien 1018 (z. B. in einem MP4-Dateiformat) bei verschiedenen Kompressionsverhältnissen und/oder Bitraten. Der Muxer & Dateischreiber 1017 kombiniert das H.264-codierte Video mit dem Audio, das parallel erfasst und verarbeitet wird, wie direkt nachfolgend beschrieben.
Zur Audioverarbeitungspipeline zurückkehrend, erfasst die Stereo-Audio-Erfassungseinheit 1002 einen Audiostream 1003 gleichzeitig mit den hierin beschriebenen Videoerfassungstechniken. In einer Ausführungsform umfasst die Stereo-Audio-Erfassungseinheit 1002 ein oder mehrere Mikrofone, Analog-zu-Digital-Konverter und Audiokompressionseinheiten zum Komprimieren der Rohaudiodaten zum Erzeugen des Audiostreams 1003 (z. B. unter Verwendung AAC, MP3 oder anderer Audiokompressionstechniken). Ein Audiodecoder 1004 decodiert den Audiostream auf ein 16-bit-PCM-Format 1021, wobei jedoch verschiedene anderen Formate ebenfalls verwendet werden können. Ein RTP-Paketisierer erzeugt RTP-Pakete in einem RTP-Puffer 1023 für die Übertragung über eine Kommunikationsverbindung/ein Netzwerk. Am empfangenden Ende extrahiert ein RTP-Entpaketisierer 1024 die PCM-Audiodaten von den RTP-Paketen und ein AAC-Encoder 1024 codiert/komprimiert das PCM-Audio nach dem AAC-Audioprotokoll (wobei jedoch andere Codierungsformate verwendet werden können).
Ein Mediensegmentierer 1019 unterteilt temporär die verschiedenen Audio-/Videodateien in Segmente einer vorgegebenen Dauer (z. B. 5 Sekunden, 10 Sekunden, 15 Sekunden usw.) und erzeugt Indexwerte für jeden der Segmente. In der illustrierten Ausführungsform wird ein getrennter Satz Mediensegmente 1020 für jede Audio-/Videodatei 1018 erzeugt. Nach dem Erzeugen können die Indexwerte verwendet werden, um auf die Mediensegmente mit Clients zuzugreifen. Beispielsweise kann ein Benutzer den Echtzeit-VR-Streamingservice verbinden und auf eine bestimmte URL umgeleitet, die auf einen bestimmten Satz Mediensegmente 1020 umgeleitet werden. In einer Ausführungsform können die Netzwerkeigenschaften der Kundennetzwerkverbindung anfänglich bewertet werden, um einen geeigneten Satz der Mediensegmente zu bestimmen, die mit einer geeigneten Bitrate codiert werden.
Wie illustriert fügen/injizieren ein oder mehrere Metadateninjektoren 1030, 1040 verschiedene Formen von Metadaten in die Mediensegmente 1020 ein. Beispielhaft und ohne Einschränkung können die Metadaten die aktuelle Punktzahl und andere relevante Daten umfassen, die mit dem Sportereignis assoziiert sind (z. B. Spielerstatistiken, Rangordnungen, aktuelle Punktzahl, verbleibende Zeit usw.), Informationen bezüglich der Musikdarstellung (z. B. Liedtitel, Liedtexte, Autoren usw.) und alle anderen Informationen, die mit dem Ereignis. In einer Sportumsetzung können beispielsweise die Punktdaten und andere relevante Daten innerhalb einer grafischen Benutzeroberfläche des VR-Client dargestellt und/oder direkt innerhalb des Panoramavideostreams integriert werden (z. B. über das aktuelle Scoreboard an dem Ereignis angezeigt werden). Weiterhin können verschiedene Arten von Metadaten injiziert werden, einschließlich HTTP-Live-Streaming-Metadaten (HLS-Metadaten), die durch einen HLS-Metadateninjektor 1030 injiziert werden, und ID3-Metadaten, die durch den ID3-Metadateninjektor 1040 injiziert werden.
In einer Ausführungsform schiebt eine Push-Einheit 1025 dynamisch die verschiedenen Mediensegmente 1020 an einen oder mehrere Cloudservices 1026 heraus, von denen sie durch die VR-Clients gestreamt werden können. Beispielhaft und ohne Einschränkung können die CloudServices 1026 die CloudFront-Web-Distribution-Plattform von Amazon Web Services (AWS) umfassen. Das Pushen von Mediensegmenten kann neben oder statt dem Bereitstellen der Mediensegmente 1020 direkt an die VR-Clients über das Netzwerk des VR-Serviceproviders erfolgen.
Ein Verfahren zur effizienten und genauen Zusammensetzung von Videobildern nach einer Ausführungsform der Erfindung ist in 14 illustriert. Das Verfahren kann im Zusammenhang der oben beschriebenen Systemarchitekturen umgesetzt sein, ist jedoch nicht auf eine bestimmte Systemarchitektur beschränkt. In 1401 werden N rohe Kamerastreams empfangen (z. B. jeweils für das linke und rechte Auge). In 1402 erfolgt das Entmosaiken zum Rekonstruieren eines Vollfarbbilds von potenziell unvollständigen Farbproben, die von den Kameras empfangen werden. Verschiedene andere Bildverbesserungstechniken können ebenfalls eingesetzt werden, wie etwa Verzerrungskompensation und Farbkompensation.
In 1403 erfolgt die Bildgleichrichtung auf die N Streams und in 1404 werden N-1 überlappende Regionen nebeneinanderliegender Bilder durch den Zusammensetzalgorithmus verarbeitet, um N-1 zusammengesetzte Bilder und 2 Randbilder zu verarbeiten. In 1405 werden zylindrische Projektion und Verkettung auf die N-1 zusammengesetzten Bilder und die beiden Randbilder ausgeführt, um das Panoramabild zu bilden.
ZUSAMMENSETZEN UNTER VERWENDUNG VON ANNAHMENPROPAGATION
Wie erwähnt, nutzt eine Ausführungsform der Erfindung Annahmenpropagationstechniken zum Durchführen des Zusammensetzens nebeneinanderliegender Bilder. Annahmenpropagation (BP) (oder „Summenproduktmeldungsweitergabe“) ist eine Technik, bei der Schlüsse aus grafischen Modellen gezogen werden, die Bayesische Netze und Markov-Zufallsfelder umfassen. Die Annahmenpropagations-Engine berechnet eine marginale Verteilung für jeden unbeobachteten Knoten basierend auf beobachteten Knoten.
In zum Zusammenhang des Bildzusammensetzens wird Annahmenpropagation verwendet, um ein am Wahrscheinlichsten passendes Pixel in einem zweiten Rahmen für jedes Pixel in einem ersten Rahmen zu identifizieren. Annahmenpropagation hat ihre eigenen internen Parameter, die vorgeben, wie verschiedene Variablen gewichtet werden sollen, um passende Pixel zu identifizieren. Die Ergebnisse unter Verwendung von internen Standardparametern sind jedoch nicht ideal.
Um diese Einschränkungen zu behandeln, führt eine Ausführungsform der Erfindung Modifikationen auf die grundlegenden Annahmenpropagationsparameter durch, um wesentlich verbesserte Ergebnisse zu erzeugen. Allgemein gibt es eine Spannung zwischen der Genauigkeit der Pixelübereinstimmung und der Glätte/Kontinuität der Naht. Das Wählen von Parametern, die zur Genauigkeit hin gewichtet sind, führt zu einer verringerten Kontinuität und umgekehrt. Eine Ausführungsform der Erfindung wählt einen Satz „idealer“ Parameter basierend auf den Anforderungen der Anwendung.
15 illustriert die Sequenz der Operationen 1501 bis 1505, die durch eine Ausführungsform der Annahmenpropagation-Engine ausgeführt wird. Diese Operationen umfassen das anfängliche Ausführen einer Datenkostenbewertung 1501, wobei für jedes Pixel in der wx H überlappenden Region zwischen dem linken und rechten Eingabebild 1500 ein Kostenvektor der Länge L berechnet wird, der die Anfangskosten des Abgleichens von L verschiedenen Kandidatenpixeln zwischen den linken und rechten Bildern schätzt.
Jeder Kostenwert ist eine echte Zahl (z. B. gespeichert als eine Fließkommazahl). Es gibt viele Wege zur Berechnung dieser Kosten, wie etwa als Summe absoluter Differenzen (SAD) oder „Sub of Squared Differences“ (SSD). In einer Ausführungsform ist das Ergebnis dieser Berechnung ein w × H × L „Kostenvolumen“ realer Zahlen.
Eine Ausführungsform findet den Index mit den niedrigsten Kosten (d. h. argmin_i L_i), aber das Ergebnis auf dieser Stufe rauscht zu stark. Ein „Konsens“ wird zwischen benachbarten Pixeln dahingehend entwickelt, was die Kosten sein sollten. Das Schaffen von Kostenwerten, die kohärenter oder „kostenglättender“ sind, ist eine der Hauptfunktionen der Annahmenpropagation.
Die Kosten L_i werden in eine Wahrscheinlichkeit 1/e^Li konvertiert und normalisiert. Das Ziel ist das Minimieren der Kosten (Energieminimierung) oder das Maximieren der Wahrscheinlichkeit. Verschiedene Varianten der Annahmenpropagation. Eine Ausführungsform wird bezüglich Energieminimierung beschrieben, die manchmal als der „negative Logwahrscheinlichkeitsraum“ bezeichnet werden. Eine Umsetzung normalisiert auch die Farben zum Anpassen der Helligkeit und Belichtungen zwischen Kameras.
Weiterhin wird in einer Ausführungsform die Anzahl der Zeilen der Bilder, die zusammengesetzt werden, um einen Faktor (z. B. 2, 3, 4, etc.) abgesampelt, um den Prozess zu beschleunigen, wodurch der Speicherfußabdruck verringert und die Toleranz für falsch ausgerichtete Rahmen erhöht wird. Es wird angenommen, dass die Bilder gleichgerichtet wurden, sodass gemeinsame Merkmale auf denselben Scanlinien liegen (d. h. epipolare Linien stimmen überein und sind parallel). Weitere Bildverarbeitung kann in dieser Stufe ebenso erfolgen, wie etwa durch Umsetzen eines High-Pass-Filters zum Verringern von Rauschen von Kameras (z. B. Rauschen einer ladungsgekoppelten Vorrichtung (CCD)).
Nach der Datenkostenanalyse 1501 wird in 1502 eine Datenkostenpyramide aufgebaut. In einer Ausführungsform wird beginnend mit dem anfänglichen Datenkostenvolumen eine Reihe von kleineren Volumen 1502A in Größe {w/2ⁱ × H/2ⁱ × L | i = 0...} aufgebaut, die die Datenkostenpyramide durch Durchschnittsbildung/Downsampling von Kostenwerten aufbauen. Es ist zu beachten, dass die Kostenvektoren noch immer für alle Volumen in der Pyramide die Länge L aufweisen.
Beginnend mit dem kleinsten Volumen in der Datenkostenpyramide werden mehrere Iterationen der Annahmenpropagationsmeldungsweitergabe 1503A ausgeführt. Die Ergebnisse werden dann in 1503 auf das nächstgrößere Volumen aufgesampelt und die Annahmenpropagationsmeldungsweitergabe 1503A wird erneut unter Verwendung der aufgesampelten Werte als Startpunkt ausgeführt. Für jeden Schritt werden vier weitere Volumen erzeugt, um die Nachrichten zu halten, die nach oben, unten, links und rechts zwischen benachbarten Kostenvektoren weitergegeben werden. Wenn die Iterationen abgeschlossen sind, werden die Endkosten aus dem Originalkostenvolumen und den Meldungsvolumen berechnet. Diese werden verwendet, um die Iteration auf der nächsthöheren Ebene zu starten.
Wenn die Endergebnisse erzeugt werden, wird eine Zusammensetzungskarte in 1504 konstruiert. In einer Ausführungsform wird das optimale Label i für jedes Pixel durch Berechnung der „Endannahmen“ über i= argmin_i L_i bestimmt. Diese Indizes i identifizieren, welche beiden Pixel die beste Übereinstimmung zwischen den ursprünglichen linken und rechten Bildern in der überlappenden Region bilden. Um die Dinge zu beschleunigen, stellt eine Ausführungsform einen Kurzschluss in dem Multi-Scale-Annahmenpropagationsprozess her, indem sie den iterativen Prozess anhält und die Zusammensetzungskarte aus einem kleineren Volumen bildet. Dies führt zu einer kleineren Zusammensetzungskarte, aus der beim Zusammensetzen bilinear gesampelt werden kann. In einer Ausführungsform wird die Zusammensetzungskarte in einer Hardwaretexturkarte sortiert, die durch die GPU(s) 1005 verwaltet wird.
Das Endbild wird dann durch Ausführen von Verzerren und Verschmelzen nach der Zusammensetzungskarte 1504 ausgeführt, um den endgültigen zusammengesetzten Bildrahmen 1506 zu erzeugen. Insbesondere wird für jedes Pixel in der überlappenden Region die Zusammensetzungskarte verwendet, um zu bestimmen, welche beiden Pixel verschmolzen werden sollen. Eine Ausführungsform verschmilzt unter Verwendung einer konvex linearen Kombination von Pixeln aus jedem Bild: $E r g e b n i s p i x e l = (1 - t) * l i n k e s P i x e l + t * r e c h t e s P i x e l,$
wobei t bei der Bewegung von links nach rechts über die Überlappungsregion von 0 bis 1 variiert. Diese Verschmelzung führt eine Vorbeaufschlagung in Richtung linker Pixel am linken Rand und in Richtung rechter Pixel am rechten Rand durch. Pixel in der Mitte werden mit einem gewichteten Durchschnitt gebildet. Laplace-Verschmelzung wird in einer Ausführungsform verwendet, um Verschwimmungsartefakte zu verringern.
In einer Umsetzung wird eine vollkommen neue Zusammensetzung für jeden Rahmen ausgeführt. Mit Blick auf die wesentlichen Verarbeitungsressourcen, die verwendet werden, um die Zusammensetzung zu identifizieren, führt eine Ausführungsform der Erfindung zurück zu den vorherigen Zusammensetzungsparametern für einen oder eine Kombination aus vorherigen Rahmen, die verwendet werden sollen um den aktuellen Rahmen zusammenzusetzen.
16 illustriert eine Ausführungsform einer Architektur, die eine Gleichrichtungsschaltungsanordnung/-logik 1602 zum Ausführen von Gleichrichtung von Bildstreams von den Kameras 1601 (z. B. einer oder mehreren Erfassungs-PODs) ausführt, und eine Stitcherschaltungsanordnung/-logik 1603, die Zusammensetzungsparameter von vorherigen Rahmen speichert, die als Ausgangspunkt verwendet werden sollen, umfasst. Insbesondere wird ein Lookahead-Puffer 1606 oder eine andere Art durch den Stitcher 1603 verwendet, um Parameter aus vorherigen Zusammensetzungen zu speichern und diese Parameter einzulesen, wenn der aktuelle Satz Bildrahmen verarbeitet wird. Beispielsweise kann der spezifische Ort eines Satzes vorheriger Merkmalspunkte gespeichert und verwendet werden, um die Zusammensetzung für den aktuellen Bildrahmen (oder zumindest als einen Startpunkt für den aktuellen Bildrahmen) zu identifizieren.
In einer Ausführungsform können die Parameter von vorherigen Zusammensetzungen einfach die Parameter aus der letzten Zusammensetzung sein. In einer anderen Ausführungsform wird ein laufender Durchschnitt dieser Parameter gehalten (z. B. für die letzten N Zusammensetzungen). Weiterhin können in einer Umsetzung, die Annahmenpropagation verwendet, die vorher bestimmte Tiefenkartenpyramiden aus 15 wiederverwendet werden.
In einer Ausführungsform wird eine Verschmelzung zwischen nebeneinanderliegenden Bildern verwendet, wenn eine Zusammensetzung fehlschlägt. Eine fehlgeschlagene Zusammensetzung kann beispielsweise aufgrund von unzureichenden Informationen, abweichender Beleuchtung (die temporär sein kann) und anderen Umständen auftreten, in denen Ähnlichkeiten zwischen Pixeln nicht bestimmt werden können.
In Reaktion auf einen Fehler analysiert eine Ausführungsform der Erfindung die vorherigen und nächsten Scanlinien und verschmilzt sie. Verschiedene Arten von Verschmelzung können auf Grundlage von Eigenschaften der beiden Rahmen gewählt werden. Die Verschmelzung kann lineare Verschmelzung, Laplace-Verschmelzung und Gauss'sche Verschmelzung umfassen (ist jedoch nicht darauf beschränkt). Alternativ oder weiterhin können, wenn Pixel nicht differenziert werden können, die Zusammensetzungsparameter von einer oder mehreren Zusammensetzungen verwendet werden (wie oben beschrieben).
In einer Ausführungsform wird die Luminanzebene (Y) verwendet, um Zusammensetzungsoperationen auszuführen, ausschließlich der U- und V-Ebenen, um die Menge der Daten zu verringern, die für das Zusammensetzen notwendig sind. Farbe stellt keinen wesentlichen Wert für das Zusammensetzen bereit, sofern nicht bestimmte Arten von Operationen wie Hintergrundsubtrahierung verwendet werden. So ist die Zusammensetzungspipeline mit YUV optimiert, was weniger Speicher und weniger Zeit für Umwandlungen benötigt.
In einer Umsetzung können, wenn zwei Y-Werte von den beiden Rahmen identisch sind oder innerhalb eines vorgegebenen Grenzwerts liegen, die U- und die V-Werte dann bewertet werden, um eine weitere Differenzierung zwischen den Pixeln bereitzustellen (z. B. um zu bestimmen, ob sie ähnliche/gleiche Farben aufweisen), wodurch ein effizienterer Verwerfungsmechanismus (d. h. zum Verwerfen von Kandidaten, die außerhalb der Grenzwerte liegen) bereitgestellt wird.
Eine Ausführungsform der Erfindung quantifiziert die Zusammensetzungsgenauigkeit und bewertet potenziell jede Naht bis auf eine einzelne Zahl hinunter. Wenn die Zusammensetzung geändert wird, sucht die Ausführungsform nach Mustern, bewertet die assoziierten Zahlen und identifiziert die mit der höchsten Menge als die Zusammensetzung. Dies kann für jede Scanlinie ausgeführt werden, bei der der Annahmenpropagationsalgorithmus das Ausmaß feststellt, zu dem es sich um eine gute Zusammensetzung handelt (d. h. die Zusammensetzungsgenauigkeit quantifiziert).
Verschiedene Arten von Variablen können bewertet werden, um die Zahl zu erreichen, einschließlich Datenkosten (wie gut das linke Pixel dem rechten Pixel entspricht) und Glätte (wie gut zwei benachbarte Pixel übereinstimmen).
BANDBREITENVERRINGERUNG UND FEHLERWIEDERHERSTELLUNG
Unter Umständen, in denen die Netzwerkbandbreite stark eingeschränkt ist und/oder in Fällen, in denen eine der Kamerastreams nichtfunktional oder verdeckt ist, reproduziert eine Ausführungsform einen Stream (der z. B. verdeckt ist) unter Verwendung von Videostreams von einer oder mehreren nebeneinanderliegenden Kameras. Beispielsweise führt in einer Ausführungsform in Antwort auf die Erkennung, dass ein Stream von Kamera N erkannt wird (z. B. der Stream des linken Auges in einem stereoskopischen Links/Rechts-Kamerapaars) eine Ausführungsform der Erfindung eine Bildtransformation des Streams von nebeneinanderliegenden Kameras N+1 und/oder N-1 durch, um den Kamera-N-Stream zu reproduzieren.
17 illustriert eine beispielhafte Anordnung, in der mehrere Links-/Rechts-Kameras 1701 bis 1704 ein Ereignis aus verschiedenen Blickwinkeln aufzeichnen. Ein Bild eines Strichmännchens wird relativ zu einem grauen Rechteck erfasst. Diese beiden Objekte werden verwendet, um die Art zu illustrieren, in der sich die Perspektive zwischen Kamera N-1 und Kamera N+1 ändert. Beispielsweise gibt es in dem Videostream von Kamera N-1 eine größere Trennung zwischen den beiden Objekten, während von Kamera N + 1 keine Trennung vorhanden ist (d. h. der Benutzer verdeckt einen Abschnitt des Rechtecks).
Aus dieser Anordnung ist zu sehen, dass es eine wesentliche Überlappung der Bilddaten gibt, die durch die Kameras N, N+1 und N-1 erfasst werden. Die Ausführungsformen der Erfindung nutzen diese Überlappung zum Verringern der Bandbreite und/oder zum Kompensieren des Ausfalls oder Kamera N. Beispielsweise können Transformationsmatrizen vor einem Ereignis basierend auf den Ausrichtungsunterschieden zwischen einer ersten Kamera (z. B. Kamera N) und einer oder mehreren nebeneinanderliegenden Kameras (z. B. Kamera N+1) pro Kamera berechnet werden. Wenn die Unterschiede der Ausrichtung der beiden Kameras bekannt sind, (z. B. Definition der Richtung 3D-Blickrichtung jeder Kamera durch den X-, Y-, Z-Vektor, der Distanz von den Kameras zu den Ereignisobjekten usw.), dann können diese Differenzen verwendet werden, um eine Transformationsmatrix für Kamera N zu erzeugen, die verwendet werden kann, ihren Videostream zu rekonstruieren.
In einer Ausführungsform werden zwei Transformationsmatrizen für Kamera N erzeugt: eine für Kamera N + 1 und eine für Kamera N-1. Die Verwendung von zwei Kameras stellt sicher, dass alle notwendigen Videodaten zur Verfügung stehen, den Videostream von Kamera N zu rekonstruieren. In anderen Ausführungsformen wird jedoch nur ein Videostream von einer angrenzenden Kamera verwendet. In diesem Fall sollte die Kamera, die für die Rekonstruktion verwendet wird, die entsprechende linke/rechte Kamera sein. Wenn beispielsweise Kamera N ein eine Kamera für das linke Auge ist, so sollte Kamera N+1 (verwendet für die Transformation) die entsprechende Kamera für das rechte Auge sein. Das Wählen der Kamera für das andere Auge gibt Sinn, wenn man die wesentliche Korrelation in der Ausrichtung zwischen der linken/rechten Kamera betrachtet. Wenn Abschnitte des Bilds vorliegen, die nicht rekonstruiert werden können, können diese Abschnitte in dem Videostream von Kamera N-1 rekonstruiert werden (z. B. der rechten Kamera des nebeneinanderliegenden Kamerapaars). Die Kamera-N-Matrix, die mit Kamera N-1 assoziiert ist, kann verwendet werden, um Löcher in der Transformation zu füllen, die auf den Videostream von Kamera N+1 ausgeübt wird.
Ein Verfahren nach einer Ausführungsform der Erfindung ist in 18 illustriert. In 1801 werden Transformationsmatrizen für jede Kamera basierend auf räumlichen Beziehungen und unterschiedlichen Ausrichtungen zwischen Kameras berechnet. In 1802 wird eine Verschlechterung eines Videostreams von Kamera N erkannt. Beispielsweise kann Kamera N ausgefallen sein oder es kann Bandbreitenprobleme mit der Netzwerkverbindung geben.
In 1803 werden die Transformationsmatrizen, die mit den nebeneinanderliegenden Kameras N+1 und N-1 assoziiert sind, abgerufen; in 1804 wird eine Transformation auf einen oder beide Videostreams von Kamera N+1 und Kamera N-1 ausgeführt. Beispielsweise kann die Kamera-N-Matrix, die mit Kamera N+1 assoziiert ist, verwendet werden, um den Videostream von Kamera N+1 unter Verwendung der Transformationsmatrix zu transformieren, um den Videostream von der Perspektive von Kamera N zu rekonstruieren. In einer Ausführungsform ist die Kamera, die für die Rekonstruktion gewählt ist, eine aus dem Links-/Rechts-Paar. Wenn beispielsweise Kamera N ein eine Kamera für das linke Auge ist, ist Kamera N+1 (verwendet für die Transformation) die entsprechende Kamera für das rechte Auge. Das Wählen der Kamera für das andere Auge gibt Sinn, wenn man die wesentliche Korrelation in der Ausrichtung zwischen der linken/rechten Kamera betrachtet.
Wenn Abschnitte des Bilds vorliegen, die nicht rekonstruiert werden können, können diese Abschnitte in dem Videostream von Kamera N-1 rekonstruiert werden (z. B. der rechten Kamera des nebeneinanderliegenden Kamerapaars). Die Kamera-N-Matrix, die mit Kamera N-1 assoziiert ist, kann verwendet werden, um Löcher in der Transformation zu füllen, die auf den Videostream von Kamera N+1 ausgeübt wird.
19 illustriert eine beispielhafte Architektur, die eine Matrixberechnungseinheit 1907 pro Kamera für die Berechnung der verschiedenen Transformationsmatrizen 1908 umfasst, die hierin beschrieben sind, basierend auf den Kameraausrichtungen und den relativen räumlichen Beziehungen der Kameras 1906 (wie oben beschrieben). In einer Ausführungsform werden die Transformationsmatrizen 1908 für die spätere Verwendung gespeichert.
In Reaktion auf die Erkennung eines Ausfalls von Kamera N durch eine Ausfallserkennungseinheit 1903 (z. B. ein Mikroservices-basiertes Überwachungssystem) rekonstruiert eine Videostreamtransformationseinheit 1904 den Videostream von Kamera N basierend auf den Videostreams von Kamera N+1 und Kamera N-1. Wie oben erwähnt, kann die Kamera-N-Matrix, die mit Kamera N+1 assoziiert ist, verwendet werden, um den Videostream von Kamera N+1 unter Verwendung der Transformationsmatrix zu transformieren, um den Videostream von der Perspektive von Kamera N zu rekonstruieren. Wenn Abschnitte des Bilds vorhanden sind, die nicht rekonstruiert werden können, können diese Abschnitte in dem Videostream von Kamera N-1 ausgewählt werden. Die Kamera-N-Matrix, die mit Kamera N-1 assoziiert ist, kann verwendet werden, um Löcher in der Transformation zu füllen, die auf den Videostream von Kamera N+1 ausgeübt wird.
Die hier beschriebenen Techniken können für eine Vielzahl von Umständen verwendet werden, einschließlich unter anderem unzureichender Bandbreite, Verdeckung durch Objekte und/oder Ausrüstungsausfälle. Während sich die oben beschriebenen Ausführungsformen auf einen Kameraausfall konzentrieren, führt eine Ausführungsform die hierin beschriebenen Techniken zu dem alleinigen Zweck durch, die Bandbreite zu verringern.
Weiterhin werden in einer Ausführungsform die oben beschriebenen Techniken für die effiziente Speicherung von Videostreams eines Ereignisses für spätere Wiedergabe verwendet (z. B. nach dem Ende eines Ereignisses). Die Menge des Massespeicherplatzes, der durch 6 bis 12 5k Videostreams verbraucht wird, ist wesentlich. Weiterhin erfassen in einer Umsetzung Erfassungs-PODs Video unter Verwendung von Bewegungs-JPEG (siehe z. B. 10 und MJPEG-Encoder 1007), was wesentliche Bandbreite und Speicherplatz verbraucht.
Um die Bandbreite zu verringern, wird nur ein Untersatz der Kameravideostreams für nachfolgende Wiedergabe aufgezeichnet. Wählt ein Benutzer, das aufgezeichnete Ereignis anzusehen, werden die Transformationsmatrizen verwendet, um die Videostreams zu rekonstruieren, die nicht aufgezeichnet wurden. Beispielsweise kann können nur die Kameras für das linke Auge aufgezeichnet werden und die Transformationsmatrizen können verwendet werden, um alle Videostreams für das rechte Auge zu rekonstruieren.
In einer Ausführungsform kann unter Annahme, dass jeder linke/rechte Stream erfasst wurde, eine Differenzberechnungseinheit Differenzen zwischen den linken und rechten Streams bestimmen. Diese Differenzen können dann zusammen mit einem der beiden Streams gespeichert werden. Beispielsweise kann eine Abweichung zwischen nebeneinanderliegenden Streams (potenziell aus unterschiedlichen Pods) berechnet werden und nur ein vollständiger Motion-Jpeg-Stream kann gespeichert und übertragen werden. Der andere Stream kann unter Verwendung von Differenzen zwischen dem Motion-Jpeg-Stream gespeichert und dann am Decoder rekonstruiert werden, wodurch eine wesentliche Menge an Redundanz entfernt wird.
Tiefenkarten können ebenfalls erzeugt und durch den Algorithmus verwendet werden, die Rekonstruktion des/der Originalstreams auszuführen. Beispielsweise kann ein monoskopisches Feed und eine Tiefenkarte verwendet werden, um ein Stereofeed zu rekonstruieren. Die Auflösung dieser Tiefenkarte kann sehr gering sein. Eine Abweichung jedes Inch ist beispielsweise nicht erforderlich. Bei einer geringen Granularität kann die Tiefenkarte mit insgesamt 8 Bits codiert sein (z. B. Granularität von 5 bis 10 Fuß). Spezielle Verarbeitungstypen können für verdeckte Objekte ausgeführt werden (z. B. Umschalten auf Datenredundanz).
SCHLÜSSEL- UND FÜLLZUSAMMENSETZUNG
Mit Verweis auf 20 umfasst eine Ausführungsform der Erfindung mehrere Transcoder 2004, 2012 für Kompositvideo oder -grafik von einer anderen Quelle als Schlüssel- und Fülloperation für die synchronisierten Multi-Kamera-VR-Feeds, die hierin beschrieben sind. In einer Ausführungsform ist der Schlüssel als ein Alpha-Kanal umgesetzt und das Füllen wird als der Farbkanal umgesetzt. Eine erste Videoquelle 2000 empfängt Schlüssel und Fülleingaben 2002 von einer oder mehreren Quellen. Videoverarbeitungsschaltungsanordnungen/Software 2003, die mit einer seriellen digitalen Schnittstelle (SDI) ausgestattet ist (potenziell auf einer SDI-Karte), führt eine Interlaced-to-Progressive-Umwandlung aus. In einer Ausführungsform wird dies durch einen oder mehrere Teranex-Standard-Konverter erreicht, wobei jedoch die zugrundeliegenden Grundsätze der Erfindung nicht auf bestimmte digitale Videoformate oder - konverter beschränkt sind.
Nach der Umwandlung werden die progressiven Videostreams über eine oder mehrere SDI-Ausgaben an einen ersten Transcoder 2004 gesendet, der Schlüssel- und Fülldatenaggregation auf die Eingaben ausführt. Der entstehende Stream wird paketisiert und an einen zweiten Transcoder 2012 übermittelt. In einer Ausführungsform wird das Echtzeittransportprotkoll (RTP) für die Paketisierung und das Streaming verwendet, wobei jedoch die zugrundeliegenden Grundsätze der Erfindung nicht auf ein bestimmtes Übertragungsprotokoll beschränkt ist. Der zweite Transcoder 2012 empfängt auch einen „Hintergrund“-Videostream von einer zweiten Videoquelle 2010, die in einer Umsetzung durch einen oder mehrere Erfassungs-PODs 1001 als Video aufgenommen wird. Der zweite Transcoder 2010 überlagert dann den Schlüssel- und Füll-Stream auf den Hintergrund-Videostream und erlaubt effektiv die Anzeige unterschiedlicher Arten von Grafiken und grafischen Effekten innerhalb des Panorama-Virtual-Reality-Bilds. In einer Ausführungsform sind die Überlagerung und das Hintergrundvideo synchronisiert.
Eine Parallaxe kann auf die Überlagerung angewendet werden, sodass die Ansicht Tiefenwirkungen innerhalb des Panorama-Virtual-Reality-Videos aufweisen kann. Das zusammengesetzte Video oder die Grafik kann verwendet werden zu, um ereignisbezogene Echtzeitdaten zu zeigen (wie etwa eine Uhr in einem Spiel, eine Punktzahl, Statistiken oder andere relevante Daten) oder kann als virtuelles Jumbotron und/oder ein virtuelles Anzeigebrett verwendet werden.
In einer Ausführungsform wird das Hintergrundvideo in einem Stereoformat empfangen, das eine Ansicht eines linken Auges und eine Ansicht eines rechten Auges aufweist. Das Überlagerungsvideo, das von der Videoquelle 2000 empfangen wird, kann zwei Kanäle aufweisen, von denen einer für Farbe und einer für Transparenz dient. Die beiden Videos erhalten durch einen einzigen Synchronisierer einen Zeitstempel und werden über RTP transportiert. Der Transcoder 2012, der ein Zusammensetzungsvideoserver sein kann, empfängt und aggregiert (puffert) Videorahmen mit Zeitstempeln von beiden Quellen 2000, 2010 und findet passende Rahmen basierend auf den Zeitstempeln, um das Überlagerungsvideo über das Hintergrundvideo zu setzen. Wenn die Überlagerung zusammengesetzt ist, wendet eine Ausführungsform des Transcoders 2012 eine Parallaxe auf die Überlagerung (z. B. durch Platzieren der Überlagerung an etwas unterschiedlichen Positionen für das linke und rechte Auge) an, um dem Betrachter ein Tiefengefühl in der Virtual-Reality-Szene zu geben.
Die oben beschriebenen Ausführungsformen stellen die Fähigkeit beriet, Video oder Grafiken aus einer anderen Quelle als Schlüssel und Füller, wobei jeweils der Alphakanal und der Farbkanal verwendet werden, auf die synchronisierten Multi-Kamera-Virtual-Reality-Feeds (Videoquelle 2010) zu setzen.
MICROSERVICES-UMSETZUNG
Einige hierin beschriebene Ausführungsformen setzen eine verteilte Architektur ein, in der auf Dienstkomponenten extern durch ein Remote-Access-Protokoll zugegriffen wird, sodass diese Komponenten über verschiedene Prozesse, Server und Netzwerke kommunizieren können. Ähnlich wie Object-Oriented Design (OOD) in der Softwarearchitektur eignen sich verteilte Architekturen für lockerer gekoppelte, verkapselte und modulare Anwendungen. Dies wiederum fördert verbesserte Skalierbarkeit, Modularität und Kontrolle über die Entwicklung, Prüfung und den Einsatz von Backend-Servicemodulen.
In dem Zusammenhang einer dienstbasierten Architektur für ein verteiltes VR-Ausstrahlungssystem wie hierin beschrieben, können Abschnitte der allgemeinen Architektur in unabhängige Dienste verkapselt sein. Beispielsweise wird ein erster Mikroservice für Herzschlaginjektion verwendet, ein zweiter Mikroservice für Erfassungssteuerungen, ein dritter Mikroservice für Metadateninjektion und ein vierter Mikroservice für Echtzeitbetriebsüberwachung. Alle Dienste können unabhängig voneinander entwickelt und erhalten bleiben, sind jedoch dafür vorgesehen, mit dem allgemeinen System zu funktionieren.
Dieser dienstorientierte Ansatz ist aus einer Vielzahl von Gründen vorteilhaft. Zuerst können unterschiedliche Programmiersprachen für unterschiedliche Dienste (z. B. C++, C#, Swift usw.) verwendet werden. Dies funktioniert besonders gut in Umgebungen, in denen unterschiedliche Teammitglieder Erfahrung in unterschiedlichen Gebieten haben. Während einige Entwickler mehr Merkmale z einem Mikroservice hinzufügen, können andere gleichzeitig an anderen Microservices arbeiten. Dies hilft bei der Parallelisierung der Entwicklungsanstrengung für unterschiedliche Ergebnisse.
Eine der Differenzen zwischen Mikroservices und dienstorientierter Architektur (SOA) ist die Dienstgranularität. Der Grundsatz für Mikroservices ist es, die Modularität der dienstorientierten Architektur weiter in kleinere und besser zu verwaltende Funktionseinheiten zu führen. Das Konzept von Mikroservices im Vergleich mit der monolithischen Anwendung 2101 und der intern komponentisierten Anwendung 2102 ist in 21 illustriert. Die illustrierte Mikroservice-Anwendung 2103 umfasst mehrere verbundene Mikroservicekomponenten 2104 bis 2105, die unabhängig voneinander ausgeführt und aktualisiert werden können.
In einer Ausführungsform werden Mikroservices verwendet, um Komponenten der hierin beschriebenen Virtual-Reality-Architektur umzusetzen. 22 illustriert eine solche Ausführungsform, in der Mikroservices 2211 bis 2214 ausgeführt werden, um Konfiguration, Überwachung und Management verschiedener Abschnitte des Panorama-Virtual-Reality-Systems auszuführen. In dieser Ausführungsform ist das VR-System logisch in Komponenten unterteilt, auf die Konfiguration, Management und Überwachung ausgeführt werden können. Das spezielle Beispiel, das in 22 illustriert ist, umfasst eine Bildverarbeitungspipeline 2201, eine Transportpipeline 2202, eine Videocodierungspipeline 2203 und eine Streaming-/Decodierungs-/Renderingpipeline 2204.
Eine oder mehrere Sonden 2251 bis 2254 sind konfiguriert, die Operation jeder der jeweiligen Verarbeitungskomponenten 2201 bis 2204 zu überwachen. In einer Ausführungsform wird jede Sonde 2251 bis 2254 auf einem oder mehreren Servern in der Verarbeitungskomponente 2201 bis 2204 ausgeführt, für die sie die Überwachung durchführt. Der Server kann derselbe Server sein, der zum Ausführen von Pipeline-Verarbeitungsfunktionen verwendet wird, oder kann als ein dedizierter Überwachungs-/Management-/Konfigurationsserver umgesetzt sein. Ähnlich können ein oder mehrere Server eingesetzt sein, die verschiedenen Mikroservices 2211 bis 2213 zu unterstützen.
In einer Ausführungsform laufen die Sonden 2251 bis 2254 kontinuierlich und überwachen verschiedene Qualitätsmetriken für jede jeweilige Verarbeitungskomponente 2201 bis 2204, einschließlich, aber nicht beschränkt auf Latenzmetriken, Last-/Ressourcenallokationsmetriken und/oder Bandbreitenmetriken. Die Sonden 2251 bis 2254 melden diese Qualitätsmetriken zurück an jeden jeweiligen Mikroservice 2211 bis 2213, der eine vorgegeben Reaktion umsetzen kann (z. B. Neuzuordnung von Verarbeitungsressourcen, Abladearbeit von überlasteten Servern oder GPUs usw.). Alternativ oder zusätzlich dazu können die Mikroservices 2211 bis 2213 Mitteilungen an einen überwachenden Mikroservice 2230 erzeugen, der in der Lage ist, systemweite Allokationsentscheidungen zu treffen (z. B. Verschiebung von Verarbeitungsressourcen von einer Verarbeitungskomponente zu einer anderen). Die Kommunikation zwischen den Mikroservices 2211 bis 2213 und dem überwachenden Mikroservice kann direkt oder über ein Mikroservice-API-Gateway 2220 erfolgen. Ein oder mehrere Clients 2231, wie etwa Managementkonsolen und/oder GUIbasierte Clients können Benutzerzugriff auf die Daten bereitstellen, die durch die Mikroservices 2211 bis 2214, 2230 kompiliert sind, und für den Benutzer, um die Mikroservices zur Umsetzung korrigierender Antworten zu konfigurierten.
In 22 werden die korrigierenden Antworten durch die gepunkteten Pfeile angezeigt, die in den Mikroservices 2211 bis 2213 beginnen und auf jede jeweilige Verarbeitungskomponente 2201 bis 2204 zeigen. Um der Einfachheit Willen ist nur ein Mikroservice 2211 bis 2214 ist für jede Verarbeitungskomponente 2201 bis 2204 illustriert. In einer Ausführungsform kann jedoch ein erster Satz Mikroservices die Daten sammeln und erfassen, die durch die Sonden 2251 bis 2254 bereitgestellt sind, während ein zweiter Satz Mikroservices, in Kommunikation mit dem ersten Satz korrigierende Aktionen umsetzen kann. Beispielhaft und nicht einschränkend kann, wenn die Qualitätsmetriken anzeigen, dass die Videocodierungspipeline 2203 oder ein Abschnitt davon überladen wurde (z. B. Qualitätsverschlechterung erfährt), ein Lastausgleichs-Mikroservice weitere Verarbeitungsressourcen zu der Videocodierungspipeline 2203 (z. B. Zuweisen eines neuen Servers oder Satzes von Videocodierungsressourcen zum Handhaben der Last mit akzeptabler Qualität) hinzufügen.
In einer Ausführungsform können die Mikroservices 2211 bis 2213, Sonden 2251 bis 2254 und anderen Konfigurations-/Überwachungs-/Managementkomponenten externe Verfahrensaufrufe (RPCs) umsetzen, um die verschiedenen Operationen auszuführen, die hierin beschrieben sind. Die zugrundeliegenden Grundsätze der Erfindung sind jedoch nicht auf bestimmte Techniken für verteilte Datenerfassung und -steuerung beschränkt.
Jeder Mikroservice 2211 bis 2213, 2230 kann mit einem DockerContainer eingesetzt sein, was es für andere Scripts oder ausführbare Dateien leicht macht, die Mikroservices zu starten. Jeder physische Server kann nur einen Mikroservicecontainer oder bis zu N Container hosten. Orchestrierungstools wie Swarm und Kubernetes können bei der Verwaltung der Konfiguration und des Einsatzes dieser Mikroservicecontainer vorteilhaft sein.
23 illustriert eine spezifische Ausführungsform, in der Überwachungsmikroservices 2301 bis 2303, die innerhalb der Dockercontainer 1 bis 3 auf einem Überwachungsserver 2300 ausgeführt werden, jeweils die Überwachung verschiedener Sätze von Verarbeitungsressourcen 2311 bis 2313 ausführen. In diesem Beispiel wird eine Überwachungsanfrage durch einen RPC-Client auf den ÜberwachungsMikroservices 2301 bis 2303 erzeugt und durch einen RPC-Server auf die Verarbeitungsressourcen 2311 bis 2313 (z. B. eine als RPC-Server umgesetzte Sonde) ausgeführt.
Mit Verweis auf 24 ist eine Ausführungsform der bidirektionalen und asynchronen Kommunikation zwischen SMS (Supervisor Mikroservice, RPC-Client) und MP4FD (MP4 Stream Fault Detector, RPC-Server) unter Verwendung eines Completion Queue (CQ) umgesetzt. Zu jeder Zeitinstanz unterstützt CQ gleichzeitig gleichzeitige Lese- und Schreiboperationen. Das heißt, der RPC-Server und Client können jeweils ein Befehlstoken in CQ legen. Als Ergebnis davon wird diese Umsetzung von SMS, die Antwort in dem ersten Lese-/Schreibzyklus ignoriert und die Reaktion wird in dem nächsten Zyklus gehandhabt, wenn eine neue Anfrage erfolgt. Vor dem Abbau des RPC-Clients sendet SMS eine „Dummy“-Anfrage zum Löschen der Reaktion der letzten Anfrage. Der Mechanismus für simultane Lese-/Schreiboperationen wird in 25 illustriert.
Eine endliche Wartezeit zwischen jedem Lese-/Schreibzyklus-RPC ist in einer Ausführungsform umgesetzt. Jeder RPC-Aufruf ist nicht sofortig, weil es eine Overhead-Kommunikation über die Grenzen der physischen Rechenmaschinen vorliegt. In der Tat führen zwei sukzessive Lese-/Schreiboperationen ohne Wartezeit dazwischen wahrscheinlich zu einem RPC-Ausfall. In einer Umsetzung werden 500 Millisekunden als die Standardwartezeit verwendet.
SPORTEREIGNIS-SCOREBOARD-UMSETZUNGEN
Eine Ausführungsform der Erfindung ist speziell auf eine große Reihe von Sportereignissen wie die olympischen Spiele zugeschnitten. 16 illustriert eine spezifische Umsetzung, die nach folgender Operationssequenz läuft:

1. Das Sport-Broadcast-Data-Feed (BDF) 2601 pusht Daten durch ein HTTP POST an einen registrierten Endpunkt.
2. Der Scorecardempfänger, ein Datenaggregator 2602, empfängt die Anfrage von BDF und speichert die Daten in einer Datenbank 2603 in einer S3-Instanz.
3. Wenn die Datei in die S3-Instanz geladen ist, löst sie ein Ereignis aus, um den Parser Lambda aufzurufen.
4. Der Datenparser läuft die entsprechende Datei von S3 herunter, verarbeitet die Datei und speichert die erforderlichen Informationen in der Datenbank 2603.
5. Scorecard-API-Server (EC2s-Teil einer Auto-Skalierungsgruppe) bedienen APIs, die durch mobile Clients 2604 (durch das Inhaltsverteilungsnetzwerk (CDN)) aufgerufen werden.
6. Der Scoreboardclient 2604 ruft die Boxpunktzahl ab und injiziert sie in den Videostream als einen Abschnitt der Metadaten.

Folgendes sind mehrere Beispiele für Scoreboard-Datenformate und Benutzerschnittstellen:

Eishockey

Probendaten
R\V1.1\IHO\WOG\1\SLO\AUT\1\2\0\0\1\2\99\05:00\0\00:00\10\04:00\0\00:00\1\2017-04-20T16:50:10
Beschreibung

Das Antwortpaket umfasst 23 Felder, die durch Backslash-Zeichen getrennt sind. Nachfolgend sind die erwarteten Werte der einzelnen Felder:

FELD	Beschreibung	OPTISCHE ANZEIGE / UX / UI
Feld 1: Antwortpakettyp	immer ‚R‘	k.A.
Feld 2: Versionsnummer	Die Versionsnummer für das aktuelle Datenformat	Nein
Feld 3: Sportkennung	‚IHO‘ stellt die Eishockeyspiele dar	Nein
Feld 4: Ligakennung	‚WOG‘ steht für Winterolympiade	Nein
Feld 5: Match-ID	Spiel- ID	Nein
Feld 6: Auswärtsteam- ID	Kennung für das Auswärtsteam	Ja
Feld 7: Heimteam-ID	Kennung für das Heimteam	Ja
Feld 8: Punktzahl Auswärtsteam	Punktzahl des Spiels für das Auswärtsteam	Ja
Feld 9: Punktzahl Heimteam	Punktzahl des Spiels für das Heimteam	Ja
Feld 10: Strafe Auswärtsteam	Strafpunktezahl für das Auswärtsteam	Ja
Feld 11: Strafe Heimteam	Strafpunktezahl für das Heimteam	Ja
Feld 12: Auswärtsteam-SOG	# SOG (Shots On Goal; Zielschüsse) für das Auswärtsteam	Ja
Feld 13: Heimteam-SOG	# SOG (Shots On Goal; Zielschüsse) für das Heimteam	Ja
Feld 14: Spielerzahl Auswärtsteam	Rückenzahl des ersten Spielers aus dem Auswärtsteam, der eine Strafe erhält	Ja
Feld 15: Strafminute Auswärtsteam	Strafminuten des ersten Spielers aus dem Auswärtsteam, der eine Strafe erhält	Ja
Feld 16: Spielerzahl Auswärtsteam	Rückenzahl des zweiten Spielers aus dem Auswärtsteam, der eine Strafe erhält	Ja
Feld 17: Strafminute Auswärtsteam	Strafminuten des zweiten Spielers aus dem Auswärtsteam, der eine Strafe erhält	Ja
Feld 18: Spielerzahl Heimteam	Rückenzahl des ersten Spielers aus dem Heimteam, der eine Strafe erhält	Ja
Feld 19: Strafminute Heimteam	Strafminuten des ersten Spielers aus dem Heimteam, der eine Strafe erhält	Ja
Feld 20: Spielerzahl Heimteam	Rückenzahl des zweiten Spielers aus dem Heimteam, der eine Strafe erhält	Ja
Feld 21: Strafminute Heimteam	Strafminuten des zweiten Spielers aus dem Heimteam, der eine Strafe erhält	Ja
Feld 22: Periode	Quartal (1-4), OT	Ja
Feld 23: UTC-Zeitstempel	UTC-Zeitstempel	k.A.

Ein Beispiel für eine Scoreboard-Benutzeroberfläche ist in 27 illustriert.
Curling
Probendaten
R\V1.2\CUR\WOG\1\CAN\HUN\1\11\0\0\0\1\0\0\0\0\0\2\2\0\2\1\4\0\0\0\7\2017-04-20T16:47:33
Beschreibung

Das Antwortpaket umfasst 29 Felder, die durch Backslash-Zeichen getrennt sind. Nachfolgend sind die erwarteten Werte der einzelnen Felder:

FELD	Beschreibung	OPTISCHE ANZEIGE / UX / UI
Feld 1: Antwortpakettyp	immer ‚R‘	k.A.
Feld 2: Versionsnummer	Die Versionsnummer für das aktuelle Datenformat	Nein
Feld 3: Sportkennung	‚CUR‘ stellt die Curlingspiele dar	Nein
Feld 4: Ligakennung	‚WOG‘ steht für Winterolympiade	Nein
Feld 5: Match-ID	Spiel- ID	Nein
Feld 6: Auswärtsteam-ID	Kennung für das Auswärtsteam	Ja
Feld 7: Heimteam-ID	Kennung für das Heimteam	Ja
Feld 8: Punktzahl Auswärtsteam	Punktzahl des Spiels für das Auswärtsteam	Ja
Feld 9: Punktzahl Heimteam	Punktzahl des Spiels für das Heimteam	Ja
Feld 10 ~ 18: Auswärtsteam-Punktzahl für Inning 1 ~ 9 oder 10 ~ 18	Inningpunktzahl für das Auswärtsteam. Wenn das aktuelle Inning weniger oder gleich 9 ist, enthalten die Felder Punktzahlen von dem 1. bis zum 9. Inning.	Ja
	Andernfalls stellen sie die Zahlen vom 10. bis 18. Inning dar.	Ja
Feld 19 ~ 27: Heimteam -Punktzahl für Inning 1 ~ 9 oder 10 ~ 18	Inningpunktzahl für das Heimteam. Wenn das aktuelle Inning weniger oder gleich 9 ist, enthalten die Felder Punktzahlen von dem 1. bis zum 9. Inning.	Ja
	Andernfalls stellen sie die Zahlen vom 10. bis 18. Inning dar.	Ja
Feld 28: Aktuelles Inning	Aktuelles Inning	Nein
Feld 29: UTC-Zeitstempel	UTC-Zeitstempel	k.A.

Eine Beispielbenutzeroberfläche ist in 28 illustriert.
Andere Sportarten
Probendaten

R\V1.1\STK\WOG\1\4\1840083\ITA\1\43.461\1840012\CAN\2\43.525\1840029\CHN\3\43. 660\

1840044\FRA\4\44.096\2017-04-20T16:47:33

Beschreibung
Das Antwortpaket umfasst Variantenzahlen der Felder der Spieleranzahl entsprechend. Jedes Feld ist durch ein Backslash-Zeichen getrennt und es sollten maximal 4 Spieler sein.

Nachfolgend finden Sie Beispielswerte für jedes Feld:

FELD	Beschreibung	OPTISCHE ANZEIGE / UX / UI
Feld 1: Antwortpakettyp	immer ‚R‘	k.A.
Feld 2: Versionsnummer	Die Versionsnummer für das aktuelle Datenformat	NEIN
Feld 3: Sportkennung	Die verfügbare ID wird nachfolgend erklärt.	NEIN
Feld 4: Ligakennung	‚WOG‘ steht für Winterolympiade	NEIN
Feld 5: Match-ID	Spiel- ID	NEIN
Feld 6: Spieleranzahl	Die Anzahl der Spieler aus den Metadaten	NEIN
Feld 7: Spieler-ID	Die Kennung des ersten Spielers	JA
Feld 8: Spieler-Landescode	Der Landescode des ersten Spielers	JA
Feld 9: Spielerrang	Der Rang des ersten Spielers	JA
Feld 10: Spielerpunktzahl	Die Punktzahl des ersten Spielers	JA
Feld 11: Spieler-ID	Die Kennung des zweiten Spielers	JA
Feld 12: Spieler-Landescode	Der Landescode des zweiten Spielers	JA
Feld 13: Spielerrang	Der Rang des zweiten Spielers	JA
Feld 14: Spielerpunktzahl	Die Punktzahl des zweiten Spielers	JA
Feld 15: Spieler-ID	Die Kennung des dritten Spielers	JA
Feld 16: Spieler-Landescode	Der Landescode des dritten Spielers	JA
Feld 17: Spielerrang	Der Rang des dritten Spielers	JA
Feld 18: Spielerpunktzahl	Die Punktzahl des dritten Spielers	JA
Feld 19: Spieler-ID	Die Kennung des vierten Spielers	JA
Feld 20: Spieler-Landescode	Der Landescode des vierten Spielers	JA
Feld 21: Spielerrang	Der Rang des vierten Spielers	JA
Feld 22: Spielerpunktzahl	Die Punktzahl des vierten Spielers	JA
Feld 23: UTC-Zeitstempel	UTC-Zeitstempel	k.A.

Eine Beispielbenutzeroberfläche ist in 29 illustriert.
STREAMING- UND FORMATIERUNGSUMSETZUNGEN
Verschiedene unterschiedliche Streamingprotokolle können verwendet werden, um Videos zu streamen, die durch Verarbeitungskomponenten und/oder Client-Vorrichtungen auf Ereignissystemebene verarbeitet werden. In einer Ausführungsform wird das Echtzeitstreamingprotokoll (RTMP) oder eine modifizierte Version des RTMP verwendet. Insbesondere eine Ausführungsform der Erfindung nimmt einen 180°x60°- oder 180°×90°-Videostream und formatiert ihn für eine 360°-Ansicht. In einer Ausführungsform erfolgt dies durch Füllen des Raums um den Videorahmen mit entweder statischem oder dynamischem Inhalt. Dies kann beispielsweise unter Verwendung einer statischen Überlagerung bzw. einer dynamischen Überlagerung erfolgen.
Traditionelle Videoquellen für RTMP-Endpunkte wie die, die in Social-Media-Plattformen gefunden werden, erfassen Videos mit einer sphärischen Linsenkamera und erlauben das Rendern von Szenen in einer 360°-Ansicht. Solche Videodaten können an 360°-Betrachter ohne Anpassung, Änderung oder Ergänzung der Videodaten geliefert werden. Es werden jedoch nicht notwendigerweise alle Videostreams oder Live-VR-Inhalte mit 360°-Blickfeldkameras (360°-FOV-Kameras) erfasst. Eine Ausführungsform der verwendeten Kameras etwa erfassen Videostreams mit Kameras, die ein horizontales FOV von 180° aufweisen. Um diesen Inhalt an Standard-RTMP-Clients mit einem 360°-Betrachter zu liefern transcodiert eine Ausführunasform der Frfindung nicht nur Videndaten, auf geeignete Auflösungen und Bitraten, sondern stellt auch korrektes Rendern in Betrachtern durch Einbetten statischer oder dynamischer Inhalte sicher, um eine 360°-Ansicht auszuführen. Traditionelle VR-Apps haben die 360°-Umgebungsansicht statisch in die Anwendung eingebaut und verlangen nicht notwendigerweise den Source-Stream, um diese zu dem Stream hinzuzufügen.
In einer Ausführungsform erfasst die Videoerfassungs-Engine (z. B. TrueVR) den Videoinhalt, bettet statische oder dynamische Inhalte ein, um eine 360°-Ansicht fertigzustellen, transcodiert die Daten auf die korrekte Auflösung, Rate, das Format und setzt einen Verteilungsserver ein (z. B. einen Live-Streaming-Server wie Wowza), um den RTMP-Stream an die Medienendpunkte weiterzuleiten.
In einer anderen Ausführungsform erfasst die Videoerfassungs-Engine den Videoinhalt, bettet statische oder dynamische Inhalte ein, um eine 360°-Ansicht fertigzustellen, transcodiert die Daten auf die korrekte Auflösung, Rate, das Format und liefert die RTMP-Streams direkt an die Medienendpunkte.
Zum Einbetten von statischen Inhalten - wie etwa 360°-Hintergrundüberlagerungen - in ein Live-Medium-Streamingsystem mit minimalem Eindringen in den Rest des Systems nutzt die eine Ausführungsform des Systems eine „Konstantfunktions“-Definition statischer Medien, wobei die statischen Medien als eine Art von Pseudovideo definiert sind, das denselben Rahmen wiederholt erzeugt. Dies erlaubt dem System die Verwendung statischer Medien in jedem Zusammenhang, in dem Standardvideo erlaubt wäre - vornehmlich als Hintergrund, auf dem Videos überlagert werden sollen, egal ob für RTMP, HLS oder ein anderes Streamingprotokoll, zu verwenden. Eine Ausführungsform des Systems verwendet auch einen Cachingmechanismus zum Minimieren der Leistungsauswirkung dieses Pseudovideos, sodass es denselben Speicher für jeden Rahmen des Pseudovideos wiederverwenden kann.
ASYNCHRONE BATCHVERARBEITUNG
Die Operation des oben genannten MP4FD lässt sich am besten als Batchverarbeitung beschreiben. Für typische Videotranscodierungssessions in Panoptes sammelt MP4FD ca. 90 Rahmen (= 60 fps * 500 ms * 3 Ausgaben) pro COM.INTEL.TRUEVR.SM.FD_GET_FRAME_INFO-Anfrage. In allen 500 ms sendet MP4FD einen Batch von 90 Rahmeninfoproben asynchron unter Verwendung von gRPC an SMS.

(A.2) Eine Ausführungsform von Befehlen für den Supervisor in Kommunikation mit Panoptes (MP4 Streaminstanz):

Anfrage	Name	Beschreibung
CMD1	COM.SM.FD_GET_DESTINATION	Abrufen des S3-Bucketuploadorts von dem aktuellen Panoptes-Prozess.
CMD2	COM.SM.FD_START	Anweisen des MP4Stream-Fehlermelders (der auf einem Arbeiterthread in einem aktiven Panoptes-Prozess läuft), um mit dem Erfassen von Rahmeninformation en zu beginnen.
CMD3	COM.SM.FD_STOP	Sofern der Backupstream nicht auf einen anderen S3-Ort schreibt als der Hauptstream, müssen wir dem Hauptstream sagen, dass er das Schreiben einstellen muss, um Überschreiben von Dateien zu vermeiden. Dies ist notwendig, wenn der Hauptstream unvollständige Ausfälle aufweist.
CMD4	COM.SM.FD_RESTART	Ein Stopp-/Startkombinations befehl
CMD5	COM.SM.FD_GET_FRAME_INFO	Bei jedem Polling liest der Supervisor weiter von der Abschlusswarteschl ange, bis keine READ-Tags mehr zurückbleiben. Die Frequenz für das Polling kann sich auf die Gesamtleistung auswirken. Der Supervisor sollte konfiguriert sein, für Rahmendatenchunk s in einem Zeitintervall zu pollen, das für Leistungs- und Latenzausgleiche optimiert ist.

Antwort	Name	Beschreibung
REPLY1	COM.SM.FD_FR AME_INFO:xxx x:xxxxx\|xxxxx x:xxxxx	Antwort mit einer Sequenz von Rahmendaten. Format: Die Rahmenquelle ist durch „\|“ begrenzt und die Rahmendaten sind durch „:“ begrenzt.
		Das erste Element ist immer der Name der Rahmenquelle, zum Beispiel:
		COM.SM.FD_FRAME_INFO:SRC1:99:100:101: 105\|SRC2:88:89:91\|SRC3:100:101:103
REPLY2	COM.SM.FD_DE STINATION:xxx .xxx.xxxx.xxx: xxxxx	Antwort mit dem S3-URI-Ort
REPLY2	COM.SM.FD_DE STINATION:xxx .xxx.xxxx.xxx: xxxxx	Format: URI begrenzt durch „:“
REPLY3	COM.SM.FD_O K	Anfrage wird erfolgreich ausgeführt.
REPLY4	COM.SM.FD_IN VALID	Anfrage wird wegen ungültigem Parameter oder Anfrage nicht ausgeführt.
REPLY5	COM.SM.FD_ER ROR	Anfrage ist gültig, aber es liegt ein Fehler vor.

Ausführungsbedingungen für Ausfallrückgriff

In einer Ausführungsform wird ein WasserTank-Algorithmus umgesetzt, um die verzögerten oder fehlenden Rahmeninformationen zu erkennen. Der Wassertank leert sich weiter mit einer konstanten Leerungsrate, während neu ankommende Rahmeninfoproben von dem Mp4-Fehlermelder den Wassertank füllen. Wenn der Tank ganz entleert ist, wird SupervisorMicroservice::runFailureFallback() ausgelöst, um den Backupserver zu starten.
Nachfolgend finden Sie eine Liste konfigurierbarer Parameter für den Algorithmus:

Parameter	Beschreibung
waterLevel	Der anfängliche Ausgangswasserpegel. Keine Einheit ist vorgegeben. Der Algorithmus funktioniert, solange dieselbe Einheit konsistent verwendet wird.
drain Rate	Die Wassermenge, die periodisch abgelassen werden soll. Wasserableitung wird jedes Mal ausgelöst, wenn DF_GET_FRAME_INFO aufgerufen wird.

Die folgende Programmausgabe zeigt, dass ein Ausfall erkannt wird, wenn der Wasserpegel unter die Nullmarke gefallen ist:

******* Verbrauchte Rahmen: 16
Verarbeitung des TAG_TYPE...
Eine neue Meldung lesen.
** Anfrage senden: : COM.SM.FD_GET_FRAME_INFO:8
water level =30.62
drain = 28.62
water level =2
-----> Wasserpegel: 2
Verarbeitung des TAG_TYPE...
Meldung asynchron senden...
Empfangene Antwort:
- COM.SM.FD_FRAME_INFO:src1:100:101:102:103:104|src2:99:100:101:102 :103:104|src3:88:87:89:90:91
- Token: CMD_SM_FD_FRANE_INFO
- Empfangene Rahmen gesamt: 16
******* Verbrauchte Rahmen: 16
Verarbeitung des TAG_TYPE...
Eine neue Meldung lesen.
water level =18
drain = 25.2
water level =-7.2
** Anfrage senden: : COM.SM.FD_GET_FRAME_INFO:9
water level =-7.2
drain=15.24
water level =-7.2
* * * * * Ausfall erkannt. Rückgriff auf Backupserver.
Verarbeitung des TAG_TYPE...
Meldung asynchron senden...
Empfangene Antwort:
- COM.SM.FD_FRAME_INFO:src1:100:101:102:103:104|src2:99:100:101:102 :103:104|src3:88:87:89:90:91
- Token: CMD_SM_FD_FRANE_INFO
- Empfangene Rahmen gesamt: 16
******* Verbrauchte Rahmen: 16
Verarbeitung des TAG_TYPE...
Eine neue Meldung lesen.
SupervisorMS empfangen: : COM.SM.BU_OK
SupervisorMS empfangen: : COM.SM.BU_OK

Hinweis: Die Auslösebedingungen und Umsetzung des Rückschaltens liegt hier nicht im Umfang.
Befehle für den Supervisor in Kommunikation mit dem Backupserver (Streamredundanz)
• Modus: synchron, Einzelanfrage, Einzelantwort

Anfrage	Name	Beschreibung
CMD1	COM.SM.BU_ SET_DESTINATION :xxx.xxx.xxx.xxx :50052	S3-Bucketuploadort für den Backupstreamser ver einstellen
CMD2	COM.SM.BU_START	s3_upload-Script auf dem Backupstreamser ver mit bereitgestelltem S3-Upload-URI betreiben
CMD3	COM.SM.BU_STOP	s3_upload-Script explizit stoppen.

Antwort	Name	Beschreibung
REPLY1	COM.SM.BU_OK	Anfrage wird erfolgreich ausgeführt.
REPLY2	COM.SM.BU_INVALID	Anfrage wird wegen ungültigem Parameter oder Anfrage nicht ausgeführt.
REPLY3	COM.SM.BU_ERROR	Anfrage ist gültig, aber es liegt ein Fehler vor.

Hinweis: für das N+1-Backupschema muss der Supervisor-Mikroservice neue Anfragen blockieren, wenn eine bestehende Session vorliegt.
Konfiguration des Supervisor Mikroservice (SMS)

Konfiguration	Bedingung	Beschreibung
SupervisorConfigure.h	statisch, Compilier ungszeit	hartcodierte Standardwerte für konfigurierbare Parameter; vorgesehen, als Rückgriff z dienen, wenn Parameter nicht korrekt eingestellt wurden.
SMS.config	statisch, Laufzeit	zugewiesene Werte für konfigurierbare Parameter, einmal bei der Objektinstanziierung geladen; geeignet für Scripting und Einmalinitialisierung.
RPC-Befehle	variabel, Laufzeit	Befehle zum Zuweisen neuer konfigurierbarer Parameter über RPC; Vorgesehen zum Modifizieren des Verhaltens eines konfigurierbaren Objekts.

Einsatz von Supervisor Mikroservice (SMS)
Für Fehlertoleranz und Streamredundanz wird eine SM-Instanz unabhängig von dem Panoteps-Prozess ausgeführt. Es kann eine oder mehrere Instanzen von SM auf einem physischen Server geben. Alternativ dazu kann jede SM-Instanz auf einer Lambda-Instanz in der Cloud laufen, wie etwa im Fall von Amazon Web Services (AWS). Wenn AWS übernehmen wollen, funktioniert nur lambdabasierte Umsetzung über Backend-Architektur nahtlos mit dem AWS-Gateway, S3-Speicher und EC2-Instanzen.
Ein empfohlenes Verfahren ist jedoch der Einsatz einer SM-Instanz in einem Dockercontainer. In einer virtualisierten Umgebung könnte es zahlreiche Container in einem physischen Server geben, während die Logiken und E/A jeder SM-Instanz unabhängig enthalten sind. Die physische Maschine kann einfach ein weiterer Server sein, der neben den bestehenden Transcoderservern läuft. Dieser Ansatz, der auf dem Dockercontainer basiert, gibt uns die größte Flexibilität beim Entwurf unserer backendserverbasierten oder serverfreien Architektur.
Eine Ausführungsform der Erfindung verwendet ein Unicast-IP-Protokoll wie RTMP, das das verbindungsbasierte TCP-Protokoll für die Übertragung von Medienvolumen von Medien mit geringer Latenz überträgt und garantiert, dass Pakete in der Reihenfolge ankommen, was bedeutet, dass die Fehlerbehandlung auf der Clientseite minimal ist.
Ausführungsformen der Erfindung können verschiedene Schritte umfassen, die oben beschrieben wurden. Die Schritte können in maschinenausführbaren Anweisungen enthalten sein, die verwendet werden können, um einen Allgemeinzweck- oder einen Spezialzweckprozessor zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, die eine fest verkabelte Logik zum Ausführen der Schritte enthalten, oder durch eine Kombination programmierter Computerbestandteile und angepasster Hardwarekomponenten ausgeführt werden.
Wie hierin beschrieben, können sich Anweisungen auf spezifische Konfigurationen von Hardware beziehen, wie etwa auf anwendungsspezifisch integrierte Schaltungen (ASICs), die konfiguriert sind, bestimmte Operationen auszuführen und eine vorgegeben Funktion aufweisen, oder Softwareanweisungen, die im Speicher gespeichert sind, der in einem nichttransitorischen computerlesbaren Medium verkörpert ist. So können die in den Figuren dargestellten Techniken unter Verwendung von Code und Daten, die auf einer oder mehreren elektronischen Vorrichtungen gespeichert und ausgeführt werden, umgesetzt werden (z. B. einer Endstation, einem Netzwerkelement usw.). Solche elektronischen Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über einem Netzwerk) Code und Daten unter Verwendung von computermaschinenlesbaren Medien, wie etwa nichttransitorischen computermaschinenlesbaren Speichermedien (z. B. Magnetscheiben; optischer Scheiben; Direktzugriffsspeicher; Speicher mit reinem Lesezugriff; Flashspeichervorrichtungen; Phasenwechselspeicher) und transitorischen computermaschinenlesbaren Kommunikationsmedien (z. B. elektrisch, optisch, akustisch oder eine andere Form weitergeleiteter Signale - wie etwa Trägerwellen, Infrarotsignale, digitale Signale usw.).
Weiterhin umfassen solche elektronische Vorrichtungen üblicherweise einen Satz von einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten gekoppelt sind, wie etwa eine oder mehrere Speichervorrichtungen (nichttransitorische maschinenlesbare Speichermedien), Benutzerein-/-ausgabevorrichtungen (z. B. eine Tastatur, ein Touchscreen und/oder eine Anzeige), und Netzwerkverbindungen. Die Koppelung des Satzes Prozessoren und anderer Komponenten erfolgt üblicherweise durch einen oder mehrere Busse und Bridges (auch als Buscontroller bezeichnet). Die Speichervorrichtung und Signale, die den Netzwerktraffic tragen, stellen jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar. So speichert die Speichervorrichtung einer bestimmten elektronischen Vorrichtung üblicherweise Code und/oder Daten zur Ausführung des Satzes einer oder mehrerer der elektronischen Vorrichtung. Natürlich können ein oder mehrere Abschnitte einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen aus Software, Firmware und/oder Hardware umgesetzt werden. In der gesamten ausführlichen Beschreibung wurden zum Zweck der Erklärung zahlreiche spezifische Details dargelegt, um ein eingehendes Verständnis dieser Erfindung zu ermöglichen. Es wird jedoch für einen Fachmann offensichtlich, dass die Erfindung ohne einige dieser spezifischen Details praktiziert werden kann. In bestimmten Instanzen wurden bekannte Strukturen und Funktionen nicht ausführlich im Detail beschrieben, um den Inhalt dieser Erfindung nicht zu verschleiern. Dementsprechend sollten der Umfang und Geist der Erfindung bezüglich der folgenden Ansprüche beurteilt werden.

Claims

Grafikprozessor, umfassend: eine Videoschnittstelle zum Empfangen einer ersten Mehrzahl Bilder von einer entsprechenden ersten Mehrzahl Kameras; einen Bildgleichrichter zum Ausführen einer perspektivischen Reprojektion von mindestens einigen der ersten Mehrzahl Bilder auf eine gemeinsame Bildebene zum Erzeugen einer gleichgerichteten ersten Mehrzahl Bilder; einen Stitcher zum Analysieren überlappender Regionen nebeneinanderliegender Bilder in der gleichgerichteten ersten Mehrzahl und zum Identifizieren entsprechender Pixel in den überlappenden Regionen und zum Zusammensetzen der nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines Panoramabilds, das eine zusammengesetzte Kombination der gleichgerichteten ersten Mehrzahl Bilder umfasst; und einen zylindrischen Projektor zum Projizieren des Panoramabilds auf eine zylindrische Fläche zum Erzeugen eines endgültigen Panoramavideobilds, das verwendet werden soll, eine Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung umzusetzen.
Grafikprozessor nach Anspruch 1, wobei der Stitcher die überlappenden Regionen durch Ausführen einer Sequenz von Annahmenpropagationsoperationen analysieren soll.
Grafikprozessor nach Anspruch 2, wobei die Sequenz von Annahmenpropagationsoperationen umfasst: Konstruktion eines anfänglichen Datenkostenvolumens unter Verwendung von Pixeldaten in den überlappenden Regionen; Konstruktion einer Datenkostenpyramide basierend auf dem anfänglichen Datenkostenvolumen, das eine Reihe kleinerer Volumen umfasst; Iteration durch die Reihe kleinerer Volumen und das Anfangsvolumen unter Verwendung von Annahmenpropagationsmeldungsweitergabe zum Erzeugen eines endgültigen Kostensatzes; und Konstruktion einer Zusammensetzungskarte aus dem endgültigen Kostensatz.
Grafikprozessor nach Anspruch 3, wobei der Stitcher die nebeneinanderliegenden Bilder dem endgültigen Kostensatz entsprechend zusammensetzen soll.
Grafikprozessor nach Anspruch 4, wobei der Stitcher für jedes Pixel in der überlappenden Region die Zusammensetzungskarte verwenden soll, um zu bestimmen, welche Pixel verschmolzen werden sollen.
Grafikprozessor nach Anspruch 5, wobei der Stitcher eine konvexe lineare Kombination aus Pixeln aus jedem Bild zum Verschmelzen verwenden soll.
Grafikprozessor nach Anspruch 1, ferner umfassend: einen Lookahead-Puffer zum Speichern von Zusammensetzungsparametern, die von einem oder mehreren vorherigen Bildern bestimmt sind, wobei der Stitcher mindestens einen Abschnitt der Zusammensetzungsparameter verwenden soll, die in dem Lookahead-Puffer gespeichert sind, um die nebeneinanderliegenden Bilder in der gleichgerichteten ersten Mehrzahl Bilder zusammenzusetzen.
Grafikprozessor nach Anspruch 1, wobei die perspektivische Reprojektion eine Homographietransformation umfasst.
Grafikprozessor nach Anspruch 1, wobei die erste Mehrzahl Bilder linke Bilder umfasst, die angezeigt werden sollen, nach der Verarbeitung in einer linken Anzeige der VR-Vorrichtung.
Grafikprozessor nach Anspruch 9, wobei die Videoschnittstelle eine rechte Mehrzahl Bilder von einer entsprechenden zweiten Mehrzahl Kameras empfangen soll, wobei der Bildgleichrichter eine perspektivischen Reprojektion von mindestens einigen der rechten Mehrzahl Bilder auf eine gemeinsame Bildebene ausführen soll, wobei der Stitcher überlappende Regionen nebeneinanderliegender Bilder in der rechten Mehrzahl analysieren und entsprechende Pixel in den überlappenden Regionen identifizieren und die nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines rechten Augen-Panoramabilds, das eine zusammengesetzte Kombination der rechten Mehrzahl Bilder umfasst, zusammensetzen soll; und wobei der zylindrische Projektor das rechte Augen-Panoramabild auf eine zylindrische Fläche projizieren soll, um ein endgültiges rechtes Augen-Panoramabild zu erzeugen, das mit dem endgültigen linken Augen-Panoramabild kombiniert werden soll, um eine Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung umzusetzen.
Grafikprozessor nach Anspruch 1, wobei der Bildgleichrichter, Stitcher und der zylindrische Projektor Schaltungsanordnungen und/oder ausführbare Software umfassen, die durch eine Ausführungseinheit des Grafikprozessors ausgeführt wird.
Verfahren, umfassend: Empfangen einer ersten Mehrzahl Bilder von einer entsprechenden ersten Mehrzahl Kameras; Ausführen einer perspektivischen Reprojektion von mindestens einigen der ersten Mehrzahl Bilder auf eine gemeinsame Bildebene zum Erzeugen einer gleichgerichteten ersten Mehrzahl Bilder; Analysieren überlappender Regionen nebeneinanderliegender Bilder in der gleichgerichteten ersten Mehrzahl, und in Reaktion darauf Identifizieren entsprechender Pixel in den überlappenden Regionen; Zusammensetzen der nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines Panoramabilds, das eine zusammengesetzte Kombination der gleichgerichteten ersten Mehrzahl gleichgerichteter Bilder umfasst; und Projizieren des Panoramabilds auf eine zylindrische Fläche zum Erzeugen eines endgültigen Panoramavideobilds, das verwendet werden soll, eine Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung umzusetzen.
Verfahren nach Anspruch 12, wobei die überlappenden Regionen durch Ausführen einer Sequenz von Annahmenpropagationsoperationen analysiert werden.
Verfahren nach Anspruch 13, wobei die Sequenz von Annahmenpropagationsoperationen umfasst: Konstruieren eines anfänglichen Datenkostenvolumens unter Verwendung von Pixeldaten in den überlappenden Regionen; Konstruieren einer Datenkostenpyramide basierend auf dem anfänglichen Datenkostenvolumen, das eine Reihe kleinerer Volumen umfasst; Iterieren durch die Reihe kleinerer Volumen und das Anfangsvolumen unter Verwendung von Annahmenpropagationsmeldungsweitergabe zum Erzeugen eines endgültigen Kostensatzes; und Konstruieren einer Zusammensetzungskarte aus dem endgültigen Kostensatz.
Verfahren nach Anspruch 14, wobei das Zusammensetzen das Zusammensetzen der nebeneinanderliegenden Bilder dem endgültigen Kostensatz entsprechend umfasst.
Verfahren nach Anspruch 15, wobei für jedes Pixel in der überlappenden Region die Zusammensetzungskarte verwendet wird, um zu bestimmen, welche Pixel verschmolzen werden sollen.
Verfahren nach Anspruch 16, wobei eine konvexe lineare Kombination von Pixeln aus jedem Bild zum Verschmelzen gewählt wird.
Verfahren nach Anspruch 12, ferner umfassend: Speichern von Zusammensetzungsparametern, die aus einem oder mehreren vorherigen Bildern bestimmt sind, und Zusammensetzen der nebeneinanderliegenden Bilder in der gleichgerichteten ersten Mehrzahl Bilder unter Verwendung von mindestens einem Abschnitt der Zusammensetzungsparameter.
Verfahren nach Anspruch 12, wobei die perspektivische Reprojektion eine Homographietransformation umfasst.
Verfahren nach Anspruch 12, wobei die erste Mehrzahl Bilder linke Bilder umfasst, die angezeigt werden sollen, nach der Verarbeitung in einer linken Anzeige der VR-Vorrichtung.
Verfahren nach Anspruch 20, wobei die Videoschnittstelle eine rechte Mehrzahl Bilder von einer entsprechenden zweiten Mehrzahl Kameras empfangen soll, das Verfahren ferner umfassend: Ausführen einer perspektivischen Reprojektion von mindestens einigen der rechten Mehrzahl Bilder auf eine gemeinsame Bildebene zum Erzeugen der gleichgerichteten rechten Mehrzahl Bilder; Analysieren überlappender Regionen nebeneinanderliegender Bilder in der gleichgerichteten rechten Mehrzahl und Identifizieren entsprechender Pixel in den überlappenden Regionen; und Zusammensetzen der nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines rechten Augen-Panoramabilds, das eine zusammengesetzte Kombination der gleichgerichteten rechten Mehrzahl Bilder umfasst; und Projizieren des rechten Augen-Panoramabilds auf eine zylindrische Fläche, um ein endgültiges rechtes Augen-Panoramabild zu erzeugen, das mit dem endgültigen linken Augen-Panoramabild kombiniert werden soll, um eine Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung umzusetzen.
Maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der bei Ausführung durch eine Maschine die Maschine veranlasst, die folgenden Operationen auszuführen: Empfangen einer ersten Mehrzahl Bilder von einer entsprechenden ersten Mehrzahl Kameras; Ausführen einer perspektivischen Reprojektion von mindestens einigen der ersten Mehrzahl Bilder auf eine gemeinsame Bildebene zum Erzeugen einer gleichgerichteten ersten Mehrzahl Bilder; Analysieren überlappender Regionen nebeneinanderliegender Bilder in der gleichgerichteten ersten Mehrzahl und in Reaktion darauf Identifizieren entsprechender Pixel in den überlappenden Regionen; Zusammensetzen der nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines Panoramabilds, das eine zusammengesetzte Kombination der gleichgerichteten ersten Mehrzahl gleichgerichteter Bilder umfasst; und Projizieren des Panoramabilds auf eine zylindrische Fläche zum Erzeugen eines endgültigen Panoramavideobilds, das verwendet werden soll, eine Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung umzusetzen.
Maschinenlesbares Medium nach Anspruch 22, wobei die überlappenden Regionen durch Ausführen einer Sequenz von Annahmenpropagationsoperationen analysiert werden.
Maschinenlesbares Medium nach Anspruch 23, wobei die Sequenz der Annahmenpropagationsoperationen umfasst: Konstruktion eines anfänglichen Datenkostenvolumens unter Verwendung von Pixeldaten in den überlappenden Regionen; Konstruktion einer Datenkostenpyramide basierend auf dem anfänglichen Datenkostenvolumen, das eine Reihe kleinerer Volumen umfasst; Iteration durch die Reihe kleinerer Volumen und das Anfangsvolumen unter Verwendung von Annahmenpropagationsmeldungsweitergabe zum Erzeugen eines endgültigen Kostensatzes; und Konstruieren einer Zusammensetzungskarte aus dem endgültigen Kostensatz.
Maschinenlesbares Medium nach Anspruch 24, wobei das Zusammensetzen das Zusammensetzen der nebeneinanderliegenden Bilder dem endgültigen Kostensatz entsprechend umfasst.
Maschinenlesbares Medium nach Anspruch 25, wobei für jedes Pixel in der überlappenden Region die Zusammensetzungskarte verwendet wird, um zu bestimmen, welche Pixel verschmolzen werden sollen.
Maschinenlesbares Medium nach Anspruch 26, wobei eine konvexe lineare Kombination von Pixeln aus jedem Bild zum Verschmelzen gewählt wird.
Maschinenlesbares Medium nach Anspruch 24, ferner umfassend: Speichern von Zusammensetzungsparametern, die aus einem oder mehreren vorherigen Bildern bestimmt sind, und Zusammensetzen der nebeneinanderliegenden Bilder in der gleichgerichteten ersten Mehrzahl Bilder unter Verwendung von mindestens einem Abschnitt der Zusammensetzungsparameter.
Maschinenlesbares Medium nach Anspruch 24, wobei die perspektivische Reprojektion eine Homographietransformation umfasst.
Maschinenlesbares Medium nach Anspruch 24, wobei die erste Mehrzahl Bilder linke Bilder umfasst, die angezeigt werden sollen, nach der Verarbeitung in einer linken Anzeige der VR-Vorrichtung.
Maschinenlesbares Medium nach Anspruch 24, wobei die Videoschnittstelle eine rechte Mehrzahl Bilder von einer entsprechenden zweiten Mehrzahl Kameras empfangen soll, das maschinenlesbare Medium ferner umfassend: Ausführen einer perspektivischen Reprojektion von mindestens einigen der rechten Mehrzahl Bilder auf eine gemeinsame Bildebene zum Erzeugen der gleichgerichteten rechten Mehrzahl Bilder; Analysieren überlappender Regionen nebeneinanderliegender Bilder in der gleichgerichteten rechten Mehrzahl und Identifizieren entsprechender Pixel in den überlappenden Regionen; und Zusammensetzen der nebeneinanderliegenden Bilder nach den entsprechenden Pixeln zum Erzeugen eines rechten Augen-Panoramabilds, das eine zusammengesetzte Kombination der gleichgerichteten rechten Mehrzahl Bilder umfasst; und Projizieren des rechten Augen-Panoramabilds auf eine zylindrische Fläche, um ein endgültiges rechtes Augen-Panoramabild zu erzeugen, das mit dem endgültigen linken Augen-Panoramabild kombiniert werden soll, um eine Virtual-Reality-Umgebung (VR-Umgebung) auf einer VR-Vorrichtung umzusetzen.