Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR PLAYBACK OF A VIDEO STREAM BY A CLIENT
Document Type and Number:
WIPO Patent Application WO/2022/152452
Kind Code:
A1
Abstract:
The invention relates to a method for playback of a video stream by a client (C), wherein the video stream has frames from exactly one camera in relation to an object moving relative thereto, from different positions, the method comprising the steps of • receiving a video stream (VB) from an encoder (SRV), • decoding the received video stream (VB) using camera parameters (CP) and geometry data (GD), • playing back the processed video stream (AVB).

Inventors:
GOLESTANI HOSSEIN BAKHSHI (DE)
Application Number:
PCT/EP2021/083632
Publication Date:
July 21, 2022
Filing Date:
November 30, 2021
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
RWTH AACHEN (DE)
International Classes:
H04N19/597; H04N13/221; H04N13/261; H04N21/81
Foreign References:
US20140293016A12014-10-02
EP2541943A12013-01-02
EP2541943A12013-01-02
Other References:
GOLESTANI HOSSEIN BAKHSHI ET AL: "Reference Picture Synthesis for Video Sequences Captured with a Monocular Moving Camera", 2019 IEEE VISUAL COMMUNICATIONS AND IMAGE PROCESSING (VCIP), IEEE, 1 December 2019 (2019-12-01), pages 1 - 4, XP033693886, DOI: 10.1109/VCIP47243.2019.8965883
Attorney, Agent or Firm:
RCD-PATENT PARTG MBB (DE)
Download PDF:
Claims:
Ansprüche Verfahren zur Wiedergabe eines Videostreams durch einen Client (C), wobei der Videostream Frames von genau einer Kamera in Bezug auf ein sich relativ hierzu bewegendes Objekt aus unterschiedlichen Positionen aufweist, aufweisend die Schritte

• Erhalten eines Videostreams (VB) von einem Kodierer (SRV),

• Dekodieren des erhaltenen Videostreams (VB) unter Verwendung von Kameraparametern (CP) und Geometrie-Daten (GD),

• Wiedergabe des aufbereiteten Videostreams (AVB). Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Kameraparameter (CP) von dem Kodierer (SRV) erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Geometrie-Daten (GD) von dem Kodierer (SRV) erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass vor Erhalt des Videostreams (VB) der Client (C) dem Kodierer (SRV) seine Befähigung zur Verarbeitung signalisiert. Verfahren nach einem der der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Geometriedaten Tiefendaten aufweisen. Vorrichtung zur Durchführung eines Verfahrens gemäß einem der Ansprüche 1 bis 5. Computerprogrammprodukt zur Einrichtung einer Datenverarbeitungsanlage zur Durchführung eines Verfahrens gemäß einem der vorhergehenden Ansprüche 1 bis 5. Verfahren zur Bereitstellung eines Videostreams durch einen Kodierer (SRV) an einen Client (C), wobei der Videostream Frames von genau einer Kamera in Bezug auf ein sich relativ hierzu bewegendes Objekt aus unterschiedlichen Positionen aufweist, aufweisend die Schritte

• Erhalten von Frames von einer Kamera in Bezug auf ein Objekt aus unterschiedlichen Positionen in Form eines Videostreams (eVB)

• Encodieren des erhaltenen Videostreams (eVB) unter Verwendung von Kameraparametern (CP) und Geometrie-Daten (GD),

• Streamen des Videostreams (VB). 9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Kameraparameter (CP) von einer externen Quelle erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden.

10. Verfahren nach Anspruch 8 oder 9 dadurch gekennzeichnet, dass die Geometrie-Daten (GD) von einer externen Quelle erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden.

11. Verfahren nach einem der vorhergehenden Ansprüche 9 oder 10, dadurch gekennzeichnet, dass die externe Quelle ein Sensor und/oder die Kameras sind.

12. Verfahren nach einem der der vorhergehenden Ansprüche 8 bis 11, dadurch gekennzeichnet, dass vor dem Streamen des Videostreams (VB) der Kodierer (SRV) von dem Client (C) seine

Befähigung zur Verarbeitung signalisiert bekommt.

13. Verfahren nach einem der der vorhergehenden Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die Geometriedaten Tiefendaten aufweisen.

14. Vorrichtung zur Durchführung eines Verfahrens gemäß einem der Ansprüche 8 bis 13. 15. Computerprogrammprodukt zur Einrichtung einer Datenverarbeitungsanlage zur

Durchführung eines Verfahrens gemäß einem der vorhergehenden Ansprüche 8 bis 13.

Description:
Verfahren zur Wiedergabe eines Videostreams durch einen Client

Hintergrund

Die digitale Kodierung von Videosignalen ist in der gegenwärtigen Zeit in vielen Formen zu finden. So werden z.B. digitale Videoströme auf Datenträgern, wie z.B. DVDs, Blu-ray oder als Download bzw. Videostream (z.B. auch für Videokommunikation) zur Verfügung gestellt. Dabei ist es Ziel der Videokodierung nicht nur Repräsentanzen der zu übermittelnden Bilder zu versenden, sondern gleichzeitig auch den Datenverbrauch gering zu halten. Dies erlaubt zum einen auf speicherplatzbeschränkten Medien wie z.B. DVDs mehr Inhalt zu speichern oder aber mehreren Verwendern den gleichzeitigen Transport von (unterschiedlichen) Videostreams zu ermöglichen.

Dabei wird zwischen verlustloser und verlustbehafteter Kodierung unterschieden.

Allen Ansätzen gemein ist, dass aus zuvor übertragenen Bildern Information für nachfolgende Bilder vorherbestimmt wird.

Gegenwärtige Analysen gehen davon aus, dass der Anteil solcher kodierten Videosignale im Jahr 2022 einen Anteil von 82 % des gesamten Netzwerkverkehrs (gegenüber 75 % im Jahr 2017) ausmachen wird, siehe Cisco Visual Networking Index: Forecast and trends, 2017-2022 (white paper), Cisco, Feb. 2019.

Hieraus wird ersichtlich, dass jegliche Einsparung, die hier erreicht werden kann, zu einer großen Einsparung an Datenvolumen und damit zu einer Einsparung an elektrischer Energie für den Transport führen wird.

In aller Regel wird ein Kodierer, ein Trägermedium, z.B. ein Übertragungskanal, und ein Dekodierer benötigt. Der Kodierer verarbeitet rohe Videodaten. Dabei wird in aller Regel ein einzelnes Bild als Frame bezeichnet. Wiederum kann ein Frame als eine Ansammlung von Pixeln verstanden werden. Ein Pixel repräsentiert dabei einen Punkt im Frame und gibt seinen Farbwert und / oder seine Helligkeit an. Dabei kann z.B. die Datenmenge für einen nachfolgenden Frame reduziert werden, wenn bereits ein Großteil der Information in einem oder mehreren zuvor kodierten Frame(s) enthalten ist/sind. Dann wäre es z.B. ausreichend, wenn nur die Differenz übermittelt wird. Dabei macht man sich die Erkenntnis zu nütze, dass in aufeinanderfolgenden Frames häufig viele gleiche Inhalte zu sehen sind. Dies ist z.B. dann der Fall, wenn eine Kamera eine bestimmte Szene aus einem Blickwinkel erfasst und sich nur wenige Dinge ändern, oder wenn sich eine Kamera langsam durch die Szene bewegt oder dreht (Translation und/oder affine Bewegung der Kamera).

Dieses Konzept stößt jedoch dann an seine Grenzen, wenn sich ein hoher Anteil zwischen Frames ändert, wie es z.B. bei einer (schnellen) Bewegung der Kamera innerhalb einer Szene bzw. einer Bewegung von Objekten innerhalb der Szene auftritt. In diesem Fall könnte im schlimmsten Fall jegliches Pixel zweier Frames verschieden sein.

Aus dem Stand der Technik, beispielsweise aus der europäischen Patentanmeldung EP 2 541 943 Al, sind Verfahren für Mehrkamerasysteme bekannt. Allerdings sind diese Mehrkamerasysteme darauf ausgelegt, dass ein vorher bekanntes Setup von Kameras mit vorbekannten Parametern verwendet wird.

Wird jedoch eine Kamera, d.h. ein monokulares Aufnahmesystem, verwendet, so ergibt sich ein völlig anderes Anforderungsprofil. In vielen Bereichen, z.B. bim autonomen Fahren, bei Drohnen, bei Sozial Media Videoaufnahmen, oder auch bei Body-Cams oder Action-Cams, wird hingegen in aller Regel nur eine einzige Kamera verwendet. Aber gerade hier ist es notwendig sowohl den verwendeten Speicherplatz und/oder eine zu übertragende Datenmenge klein zu halten.

Aufgabe

Ausgehend hiervon ist es eine Aufgabe der Erfindung eine Verbesserung für Einkamera-System bereitzustellen.

Kurzdarstellung der Erfindung Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Weitere vorteilhafte Ausgestaltungen sind Gegenstand der abhängigen Ansprüche, der Beschreibung und der Figuren.

Kurdarstellung der Figuren

Fig. 1 zeigt schematische Ablaufpläne gemäß Aspekten der Erfindung,

Fig. 2 zeigt schematische Ablaufpläne gemäß weiteren Aspekten der Erfindung,

Fig. 3 zeigt schematische Ablaufpläne gemäß weiteren Aspekten der Erfindung,

Fig. 4 zeigt eine schematische Darstellung zur Erläuterung von konzeptionellen Fragen, und Fig. 5 zeigt eine beispielhafte Relation von Frames gemäß weiteren Aspekten der Erfindung.

Ausführliche Darstellung der Erfindung

Nachfolgend wird die Erfindung eingehender unter Bezugnahme auf die Figuren dargestellt werden. Dabei ist anzumerken, dass unterschiedliche Aspekte beschrieben werden, die jeweils einzeln oder in Kombination zum Einsatz kommen können. D.h. jeglicher Aspekt kann mit unterschiedlichen Ausführungsformen der Erfindung verwendet werden, soweit nicht explizit als reine Alternative dargestellt.

Weiterhin wird nachfolgend der Einfachheit halber in aller Regel immer nur auf eine Entität Bezug genommen werden. Soweit nicht explizit vermerkt, kann die Erfindung aber auch jeweils mehrere der betroffenen Entitäten aufweisen. Insofern ist die Verwendung der Wörter „ein", „eine" und „eines" nur als Hinweis darauf zu verstehen, dass in einer einfachen Ausführungsform zumindest eine Entität verwendet wird.

Soweit nachfolgend Verfahren beschrieben werden, sind die einzelnen Schritte eines Verfahrens in beliebiger Reihenfolge anordbar und/oder kombinierbar, soweit sich durch den Zusammenhang nicht explizit etwas Abweichendes ergibt. Weiterhin sind die Verfahren - soweit nicht ausdrücklich anderweitig gekennzeichnet - untereinander kombinierbar.

Nachfolgend werden wir auf verschiedene Aspekte der Erfindung im Zusammenhang mit einem vollständigen System aus Kodierer und Dekodierer eingehen. Fehler, die zwischen dem Kodieren und Dekodieren auftreten können, werden nachfolgend nicht beleuchtet, da sie für das Verständnis des (De-) Kodierens nicht relevant sind. ln den gängigen Videobereitstellungssystemen basiert der Kodierer auf Vorhersage/Prädiktion (engl. Prediction). D.h. je besser man einen zu kodierenden Frame aus einem vorher dekodierten Frame Vorhersagen kann, umso weniger Information (Bit(s)) muss übertragen werden.

In den bisherigen Ansätzen wurde der Ansatz verfolgt, Frames auf Grund von Ähnlichkeiten zwischen den Frames in einem zweidimensionalen Modell vorherzusagen.

Es ist jedoch festzustellen, dass die Aufzeichnung von Videos meistens im dreidimensionalen Raum stattfindet.

Mit nun verfügbarer Rechenleistung Ist es möglich Tiefeninformation auf Seiten des Kodierers und/oder des Dekodierers zu ermitteln/abzuschätzen.

Daher kann innerhalb der Erfindung auch ein dreidimensionales Bewegungsmodell zur Verfügung gestellt werden. Ohne Beschränkung der Allgemeinheit der Erfindung ist es dabei möglich die Erfindung auch mit allen gegenwärtigen Video(de)kodierern einzusetzen soweit sie entsprechend aufgerüstet sind. Insbesondere kann der Erfindung Versatile Video Coding ITU-T H.266/ ISO/IEC 23090- 3 hinzugefügt werden.

Dabei basiert die Erfindung auf der Idee der bewegungskompensierenden Vorhersage (engl. Motion- compensated prediction). Um dies zu motivieren verweisen wir nachfolgend auf Figur 4. Dabei wird ein Video aus (aufeinanderfolgenden) kodierten Bildern von zweidimensionalen Frames (d.h. eine Sequenz) betrachtet. Ein Frame wird dabei auch als zweidimensionale Repräsentation bezeichnet. Aufgrund der zeitlichen Redundanz zwischen aufeinanderfolgenden Frames kann ein zu (kodierender) Frame zum Zeitpunkt t aus zuvor (t-1, t-2 ... (dargestellt t-4) ohne auf vier vorhergehende Frames beschränkt zu sein) kodierten Frames vorhergesagt werden. Diese vorhergehenden Frames werden auch als Referenz (Referenzframes, Referenzbilder) bezeichnet. Es sei dabei angemerkt, dass hier die Framereihenfolge nicht notwendigerweise eine zeitliche Reihenfolge sein muss, sondern dass die dargestellte Reihenfolge und die (de)kodierte Reihenfolge unterschiedlich sein kann. D.h. für das (De- )Kodieren können nicht nur Informationen aus zeitlich vorher liegenden Frames, sondern auch Informationen aus zeitlich nachfolgenden (in der Darstellung / zeitlichen Abfolge zukünftigen) Frames verwendet werden, Falls die bewegungskompensierte Vorhersage präzise genug ist, reicht es aus nur den Unterschied zwischen der Vorhersage und dem zu kodierenden Frame, den sogenannten Vorhersagefehler (engl. prediction error) zu übertragen. Je besser die Vorhersage ist, umso weniger Vorhersagefehler müssen übermittelt werden, d.h. umso weniger Daten müssen zwischen Kodierer und Dekodierer übermittelt bzw. gespeichert werden.

D.h., aus Sicht des Kodierers steigt die Effizienz.

Die herkömmlichen Kodierer basieren auf der Ähnlichkeit von Frames in einem zweidimensionalen Modell, d.h. lediglich Translationen und/oder affine Bewegungen werden in Betracht gezogen. Es gibt jedoch eine Reihe von Bewegungen, die nicht einfach als 2D-Modell ausgedrückt werden können.

Daher verwendet diese Erfindung einen Ansatz der auf der dreidimensionalen Umgebung basiert, in dem die Sequenz erfasst ist und hieraus ein 3D-Bewegungsmodell darstellbar wird.

Praktisch gesehen ist die Videoaufnahme analog zur Projektion einer dreidimensionalen Szene in die zweidimensionale Ebene der Kamera. Da jedoch bei der Projektion die Tiefeninformation verloren geht, ermöglicht die Erfindung eine anderweitige Bereitstellung.

Im Beispiel des Ablaufplanes nach Figur 1 wird auf Seiten des Dekodierers die 3D-lnformation rekonstruiert, während im Beispiel des Ablaufplanes nach Figur 2 der Kodierer die 3D-lnformation (komprimiert) zur Verfügung stellt und der Dekodierer sie lediglich verwendet. Im Beispiel des Ablaufplanes nach Figur 3 wird eine Mischform zur Verfügung gestellt, bei der der Kodierer die (grobe) 3D-lnformation (komprimiert) zur Verfügung stellt, und der Dekodierer die 3D-lnformation weiter aufbereitet, um sie zu verbessern.

Es ist offensichtlich, dass im ersten Fall die notwendige Bandbreite / Speicherkapazität geringer sein kann als im zweiten oder dritten Fall. Andererseits sind die Anforderungen an die Rechenleistung im ersten Fall für den Kodierer und den Dekodierer hoch, während im zweiten Fall die Anforderungen an die Rechenleistung für den Dekodierer geringer und für den Kodierer am höchsten sind. D.h. auf Basis der zur Verfügung stehenden Möglichkeiten können unterschiedliche Szenarien bedient werden. Insbesondere bei einer Abfrage nach einem Videostrom kann es daher vorgesehen sein, dass z.B. ein Dekodierer seine Eigenschaften dem Kodierer bekannt macht, sodass der Kodierer unter Umständen auf die Bereitstellung von (präziser) 3D-lnformation verzichten kann, weil der Dekodierer ein Verfahren nach Figur 1 oder 3 zur Verfügung stellt.

Nachfolgend gehen wir davon aus, dass die Kamera irgendeine Kamera ist und nicht auf einen bestimmten Typ festgelegt ist.

Im Folgenden wird auf eine monokulare Kamera mit unbekannten Kameraparametern als schwierigster Anwendungsfall Bezug genommen werden, ohne jedoch hierdurch die Verwendung anderer Kameratypen, wie. z.B. Lichtfeld, Stereokamera, etc. auszuschließen.

Dabei kann auf die Kameraparameter CP und Geometrie-Daten GD geschlossen werden. Auf die Kameraparameter CP kann z.B. durch Verfahren wie Structure from Motion, Simultaneous Localization and Mapping oder Sensoren geschlossen werden.

Sind solche Daten durch bestimmte Kameratypen, z.B. Stereokameras und/oder durch zusätzliche Sensoren, wie z.B. LIDAR-Sensoren, Gyroskope, etc. bekannt, so können diese alternativ oder zusätzlich übermittelt oder verarbeitet werden und somit den Rechenaufwand vermindern oder obsolet machen. Die Kameraparameter CP können typischerweise aus Sensordaten von Gyroskopen, inertiale Messeinheit (englisch inertial measurement unit, IMU), Ortsdaten eines Global Positioning System (GPS), etc. ermittelt werden, während Geometrie-Daten GD aus Sensordaten eines LIDAR- Sensors, Stereokameras, Tiefensensoren, Lichtfeldsensoren, etc. ermittelt werden. Stehen sowohl Kameraparameter CP und Geometrie-Daten GD zur Verfügung wird die (de-)Kodierung einfacher und in der Regel qualitativ besser.

Der Kodierer SRV kann z.B. ein herkömmliches Videosignal Input Video in Schritt 301 erhalten. Vorteilhafterweise kann dieses Videosignal auf Bewegung, d.h. eine Relativbewegung der Kamera überwacht werden. Wird eine Relativbewegung der Kamera erkannt, so kann das Eingangsvideosignal Input Video einer erfindungsgemäßen Kodierung unterzogen werden, andernfalls, wenn keine Relativbewegung der Kamera erkannt wird, kann das Signal wie bisher einer üblichen Kodierung unterzogen werden und wie in Schritt 303, 403, 503 angedeutet dem Dekodierer C zur Verfügung gestellt werden. Eine Kamerabewegung kann in Ausführungsformen seitens des Kodierers z.B. durch visuelle Datenverarbeitung des Videosignals und/oder durch Sensoren, wie z.B. ein IMU (Inertial Measurement Unit), ein GPS (Global Positioning System), etc. erkannt werden.

Wird hingegen eine Bewegung erkannt, so kann ein entsprechendes Flag Flag_3D oder eine andere Signalisierung verwendet werden, um das Vorhandensein von erfindungsgemäßem Inhalt gemäß Schritt 304, 404, 504 zu signalisieren, sollte er nicht aus dem Datenstrom bereits an sich erkennbar sein.

Wird eine Kamerabewegung festgestellt, können wie in Schritt 305, 405, 505 angedeutet die (intrinsischen und extrinsischen) Kameraparameter CP in Schritt 306, 406, 506 abgeschätzt / bestimmt werden.

Hierzu können Techniken wie z.B. visuelle Datenverarbeitung, wie z.B. Structure-from-Motion (SfM), Simultaneous Localization and Mapping (SLAM), Visual Odometry (V.O.), oder jedes andere geeignete Verfahren verwendet werden.

Die Kameraparameter CP können natürlich auch durch andere Sensoren abgeschätzt / bestimmt / als bekannter Wert übernommen werden.

Ohne Beschränkung der Allgemeinheit der Erfindung können diese Kameraparameter CP in Schritt 307, 407, 507 verarbeitet und kodiert werden und getrennt oder eingebettet in den Videostream VB dem Dekodierer C zur Verfügung gestellt werden.

Die Geometrie im dreidimensionalen Raum kann in Schritt 310, 410, 510 abgeschätzt / bestimmt werden. Insbesondere kann in Schritt 310 die Geometrie im dreidimensionalen Raum aus einem oder mehreren zuvor kodierten Frames (Schritt 309) abgeschätzt werden. Hierzu können die zuvor ermittelten Kameraparameter CP in Schritt 308 einfließen. In den Ausführungsformen der Figuren 2 und 3 können die 3D Geometriedaten aus „rohen" Daten abgeschätzt / bestimmt werden. In der Ausführungsform der Figur 1 können diese Daten aus den kodierten Daten abgeschätzt / bestimmt werden. Typischerweise wird die visuelle Qualität in den Ausführungsformen der Figur 2 und 3 besser sein als in der Ausführungsform der Figur 1, sodass diese Ausführungsformen höherwertige 3D Geometriedaten bereitstellen können. Um die Geometrie im dreidimensionalen Raum abzuschätzen kann man sogenannte Multi-View Computer Vision Techniken verwenden, ohne hierdurch die Verwendung anderer Techniken, wie z.B. eventuell vorhandene Tiefensensoren, wie z.B. LiDAR, oder andere Bildsensoren, die eine Tiefenerkennung erlauben, wie z.B. Stereokameras, RGB+D Sensoren, Lichtfeldsensoren, etc. auszuschließen.

Die so ermittelte Geometrie im dreidimensionalen Raum kann durch eine geeignete Datenstruktur, z.B. ein 3D Modell, ein 3D-Netz, 2D-Tiefenkarten, Punktwolken (dünnbesetzt oder dicht), etc. repräsentiert sein.

Nunmehr kann das Videosignal VB auf Basis der ermittelten Geometrie im drei-dimensionalen Raum in Schritt 312, 412, 512 kodiert werden.

Dabei kann nun das neuartige bewegungsbasierte Modell auf die reproduzierte dreidimensionale Information angewendet werden.

Hierzu kann beispielsweise ein Referenzbild in Schritt 311 bestimmt / gewählt sein. Dies kann dann dem Standard Video Kodierer in Schritt 312 präsentiert werden.

Offensichtlich kann die nun folgende Kodierung auf einen, mehrere oder alle Frames einer vorbestimmten Menge verwendet werden. Entsprechender Weise kann natürlich auch die Kodierung sich auf einen, mehrere oder alle vorherigen Frames einer vorbestimmten Menge stützen.

Es kann auch vorgesehen sein, dass der Kodierer SRV nur einige räumliche Gebiete innerhalb eines Frames in der vorgegebenen erfindungsgemäßen Weise verarbeitet und andere in herkömmlicher Weise.

Wie bereits ausgeführt, kann ein Standard Video Kodierer verwendet werden. Dabei kann eine zusätzliche Referenz zur Liste der Referenzbilder (in Schritt 311) hinzugefügt werden oder aber ein bestehendes Referenzbild ersetzt werden. Ebenso kann wie bereits angedeutet nur ein bestimmter Raumbereich mit der neuen Referenz überschrieben sein. Hierdurch kann der Standard-Videokodierer in die Lage versetzt werden eigenständig auf Basis der vorhandenen Referenzbilder das Referenzbild auszusuchen, dass eine günstige Eigenschaft besitzt, z.B. eine hohe Kompression bei geringen Verfälschungen (rate-distortion optimization).

So kann der Standard-Videokodierer unter Verwendung der synthetisierten Referenz den Videostrom kodieren und in Schritt 313, 413, 513 dem Dekodierer C zur Verfügung stellen.

Wie in bisherigen Verfahren auch, kann der Kodierer SRV an entsprechenden Wiedereinstiegspunkte erneut mit einer Erkennung gemäß Schritt 301 beginnen und das Verfahren erneut durchlaufen.

Wiedereinstiegspunkte können zu festgesetzten Zeitintervallen, auf Basis von Kanaleigenschaften, der Bildrate des Videos, der Anwendung etc. gesetzt werden.

Dabei kann die 3D-Geometrie im dreidimensionalen Raum jeweils neu rekonstruiert werden oder eine bestehende weiterentwickeln. Die 3D-Geometrie wächst mit zunehmend neuen Frames weiter an bis sie beim nächsten Wiedereinstiegspunkt neugestartet wird.

In entsprechender Weise kann auf der Dekoderseite C agiert werden, wobei in den Figuren 1 bis 3 Kodierer SRV und Dekodierer C in ihren funktional entsprechenden Komponenten auf horizontal etwa gleicher Höhe angeordnet sind.

So kann der Dekodierer C zunächst überprüfen, ob ein entsprechendes Flag Flag_3D oder eine andere Signalisierung verwendet wurde.

Ist eine solche Signalisierung (Flag_3D ist z.B. 0) nicht vorhanden, so kann der Videostream standardmäßig behandelt in Schritt 316 behandelt werden. Andernfalls kann der Videostream in der neuen erfindungsgemäßen Art und Weise behandelt werden.

Zunächst können Kameraparameter CP in Schritt 317, 417, 517 erhalten werden. Die erhaltenen Kameraparameter CP können in optionalen Schritten 318 verarbeitet und / oder dekodiert werden. Diese Kameraparameter CP können z.B. für eine Tiefenschätzung als auch für die Erzeugung der Geometrie im dreidimensionalen Raum in Schritt 320 auf Basis von vorhergehenden Frames 319 genutzt werden.

Insgesamt kann dabei die gleiche Strategie in Bezug auf die Referenzbilder wie beim Kodierer (Schritte 309...312, 409...412, 509...512) in entsprechenden Schritten 319...332, 419...432, 519...532 Verwendung finden. Es ist z.B. möglich das synthetisierte Referenzbild in Schritt 321 zu rendern, indem man den zuvor dekodierten Frame (Schritt 319) in den zu-dekodierenden Frame umformt, unter Führung der dekodierten Kameraparameter CP (Schritt 318) und der Geometrie im dreidimensionalen Raum (Schritt 320).

Schließlich kann in Schritt 323, 423, 523 der erfindungsgemäß verarbeitete Videostream durch einen Standard-Videokodierer dekodiert werden und als dekodierter Videostream 324, 424, 524 zur Ausgabe gebracht werden.

Üblicherweise sollten dabei der Dekodierer mit dem Kodierer in Bezug auf die Einstellungen synchron sein, sodass der Dekodierer C die gleichen Einstellungen (insbesondere für die Tiefenbestimmung, Referenzerstellung, etc.) wie der Kodierer SRV verwendet.

In der Ausführungsform der Figur 2 kann im Unterschied zur Ausführungsform der Figur 1 die Geometrie im dreidimensionalen Raum aus rohen Videoframes in Schritt 405 abgeschätzt werden. Dabei kann aus den Daten ein (zusätzlicher) Bitstrom 410.1 erzeugt werden, der z.B. Gegenstand weitere Verarbeitung, z.B. Dezimierung, (verlustfreier/verlustbehafteter) Kompression und Kodierung ist, der an den Dekodierer C zur Verfügung gestellt werden kann. Dieser zur Verfügung gestellte Bitstrom 2.2 kann nun auch - wie im Dekodierer C - in Schritt 410.2 (zur Sicherstellung der Kongruenz der Daten) zurückgewandelt werden und der Verarbeitung in Schritt 411 zur Verfügung gestellt werden.

Ebenso kann die Geometrie im dreidimensionalen Raum auch über einen Wiedereinstiegspunkt hinaus erhalten bleiben. Jedoch erlaubt das Verfahren auch die ständige Verbesserung der Geometrie im dreidimensionalen Raum auf Basis vorheriger und aktueller Frames. Diese Geometrie im dreidimensionalen Raum kann geeignet Gegenstand weitere Verarbeitung, z.B. Dezimierung (z.B. Mesh Decimation), (verlustfreier/verlustbehafteter) Kompression / Kodierung sein. In entsprechender Weise kann den Dekodierer C den in Schritt 419.1 erhaltenen Bitstrom 2.2 mit den Daten betreffend die Geometrie im dreidimensionalen Raum erhalten und dekodieren. Die dekodierte Geometrie im dreidimensionalen Raum kann dann in Schritt 420 verwendet werden.

Offensichtlich kann der Dekodierer in dieser Variante schneller arbeiten, da die Dekodierung geringeren Aufwand als die Rekonstruktion der Geometrie im dreidimensionalen Raum (Figur 1) erfordert.

Während in der Ausführungsform der Figur 1 ein sehr effizientes Verfahren in Bezug auf die Bitratenreduktion vorgestellt wird, kann mit der Ausführungsform der Figure 2 eine geringere Bitratenreduktion erzielt werden, wofür aber die Komplexität auf Seiten des Dekodierers C sinkt. Die Ausführungsform der Figur 3 kombiniert Aspekte der Ausführungsformen der Figur 1 und Figur 2, verteilt die Komplexität und erlaubt ein flexibles und effizientes Verfahren.

Im Wesentlichen unterscheidet sich das Konzept der Ausführungsform der Figur 3 von der Ausführungsform der Figur 2 darin, dass die Geometrie im dreidimensionalen Raum, d.h. die 3D-Daten in Schritt 510.1 grob die ursprüngliche Geometrie im dreidimensionalen Raum repräsentieren, d.h. in abgespeckter Version, sodass die benötigte Bitrate hierfür sinkt. Hierfür kann jedes geeignete Verfahren zur Datenreduktion wie z.B. Unterabtastung (sub-sampling), grobe Quantisierung (coarse quantization), Transformationskodierung und Dimensionsreduktion, etc. verwendet werden, ohne hierauf beschränkt zu sein.

Die so minimierten 3D Daten können wie zuvor in Schritt 510.2 kodiert und an den Dekodierer C zur Verfügung gestellt werden. Der Bitstrom 510.1/510.2 kann Gegenstand weiterer Verarbeitung, z.B. Dezimierung, (verlustfreier/verlustbehafteter) Kompression und Kodierung sein, die dem Dekodierer C zur Verfügung gestellt werden kann. Dieser zur Verfügung gestellte Bitstrom 2.2 kann nun auch - wie im Dekodierer C - in Schritt 510.3 (zur Sicherstellung der Kongruenz der Daten) zurückgewandelt werden und der Verarbeitung in Schritt 511 zur Verfügung gestellt werden. Dabei können die zuvor kodierten Frames 509 und die Kameraparameter 506 zur feineren Erarbeitung der 3D-Daten verwendet werden. Entsprechender Weise kann der Dekodierer C die kodierten und minimierten 3D-Daten in Schritt 519.1 erhalten und in Schritt 519.2 dekodieren und - entsprechend zum Kodierer SRV - der Verarbeitung zur Verfügung gestellt werden. Dabei können die zuvor kodierten Frames 519.3 und Kameraparameter 518 zur feineren Erarbeitung der 3D Daten verwendet werden.

D.h. in allen Ausführungsformen des Dekodierers C wird ein Videostream VB vom Kodierer SRV, z.B. ein Streamingserver, In einem ersten Schritt 315, 415, 515 erhalten.

Der Client C dekodiert den erhaltenen Videostream VB unter Verwendung von Kameraparametern CP und Geometrie-Daten GD, und gibt diesen anschließend als aufbereiteten Videostream AVB in Schritt 324, 424, 524 wieder.

Wie in den Figuren 1 bis 3 aufgezeigt können in Ausführungsformen der Erfindung die Kameraparameter CP von dem Kodierer SRV in Schritt 317, 417, 517 (z.B. als Bitstream 2.1) erhalten werden oder aus dem erhaltenen Videostream VB bestimmt werden.

In Ausführungsformen der Erfindung können Geometriedaten GD von dem Kodierer SRV (z.B. als Bitstream 2.2) erhalten werden oder aus dem erhaltenen Videostream VB bestimmt werden.

Insbesondere kann vorgesehen sein, dass vor Erhalt des Videostreams VB der Dekodierer C dem Kodierer SRV seine Befähigung zur Verarbeitung signalisiert. Dabei kann auch ein Set an Möglichkeiten der Verarbeitung mitgeliefert sein, sodass der Kodierer das geeignete Format zur Verfügung stellen kann. Das zur Verfügung gestellte Format kann hierzu eine entsprechende Kodierung bezüglich Einstellungsdaten aufweisen.

In einer Ausführungsform der Erfindung weisen die Geometriedaten Tiefendaten auf.

Zusammenfassend sei nochmals darauf hingewiesen, dass im Falle der Figur 1 eine 3D Rekonstruktion sowohl auf der Seite des Kodierers als auch des Dekodierers zur Anwendung kommt. Im Beispiel der Figur 2 wird nur durch den Kodierer eine 3D Rekonstruktion durchgeführt und dem Dekodierer zur Verfügung gestellt. D.h. der Dekodierer muss keine 3D Rekonstruktion durchführen, sondern kann die vom Kodierer bereitgestellte 3D Geometriedaten verwenden. Die Abschätzung der 3D Geometriedaten auf Seiten des Kodierers ist dabei in aller Regel einfacher als auf Seiten des Dekodierers. Insbesondere dann, wenn die Rechenleistung auf Seiten des Dekodierers beschränkt ist, ist die Ausgestaltung gemäß Figur 2 vorteilhaft. Im Falle der Figur 3 wird wie in Figur 2 durch den Kodierer eine 3D Rekonstruktion durchgeführt und dem Dekodierer zur Verfügung gestellt. Allerdings wird hierbei nur eine Grobfassung der 3D Geometriedaten zur Verfügung gestellt. Hierdurch kann die Bitrate für die 3D Geometriedaten verringert werden. Zugleich muss aber der Dekodierer nun die 3D Geometriedaten nachvervollständigen/nachbearbeiten (Refine).

Die Wahl des Verfahrens (z.B. gemäß Figur 1, Figur 2 oder Figur 3) kann durch den Kodierer und den Dekodierer ausgehandelt werden. Dies kann z.B. auf Basis vorherigen Wissens (z.B. Rechenleistung) oder aber auch über einen Steuer- / Rückkanal (adaptiv) erfolgen, um z.B. auch Änderungen in der Übertragungskapazität zu berücksichtigen. In einem Broadcast Szenario, dass sich an mehrere Dekodierer richtet, wird in aller Regel die Ausgestaltung gemäß der Figur 2 bevorzugt sein.

Auch wenn die Erfindung in Bezug auf Verfahren beschrieben ist, so ist doch dem Fachmann verständlich, dass die Erfindung auch in Hardware, insbesondere durch Software eingerichtete Hardware zur Verfügung gestellt werden kann. Hierfür können gängige (De-)Kodiereinheiten, spezielle Recheneinheiten wie GPUs und DSPs ebenso wie ASICs oder FPGAs basierte Lösungen zum Einsatz kommen, ohne hierdurch die Anwendbarkeit allgemeiner Mikroprozessoren auszuschließen.

Insbesondere kann die Erfindung demnach auch in Computerprogrammprodukten zur Einrichtung einer Datenverarbeitungsanlage zur Durchführung eines Verfahrens verkörpert sein.

Mit der Erfindung ist es möglich signifikante Einsparungen bei der Bitrate von mehreren Prozent zu erreichen, wenn entsprechend kodierbare Szenen vorliegen.

Nachfolgend sei zunächst angenommen, dass zu einem bestimmten Zeitpunkt eine fortlaufende Videoaufnahme kodiert werden soll. Dabei sind bereits einige Frames kodiert und ein weiterer Frame, der "to-be-encoded frame", soll nun kodiert werden. Je nachdem, wo sich der Frame in der Abfolge befindet und/oder je nach verfügbarer Datenrate bzw. Vidoekodiereinetstellung, kann dieser "to-be- encoded frame" mittels Intra-prediction oder Inter-prediction Werkzeugen kodiert werden. Typischerweise würde man z.B. für jeden ersten Rahmen einer Gruppe von Bildern (engl. Group of Pictures - abgek. GOP), z.B. dem 16ten frame (d.h. frame mit OrdnunungsnummerO, 16, 32, ... ) Intra- prediction Werkzeuge verwenden, während man für die "Zwischenframes" hierzu Inter-prediction Werkzeuge verwenden würde.

Von besonderem Interesse im Rahmen der Erfindung sind die Rahmen, die mittels Inter-prediction Werkzeugen, zu kodieren sind, d.h. im Beispiel die Rahmen 1-15, 17-31, 33-47, ... , ... .

Die wesentliche Idee bei Inter-prediction Werkzeugen ist es zeitliche Ähnlichkeiten zwischen aufeinanderfolgenden Rahmen zu nutzen. Falls ein Block eines zu kodierenden Rahmens ähnlich zu irgendeinem Rahmen in dem zuvor kodierten Rahmen ist (z.B. wegen einer Relativbewegung), so kann anstatt diesen Block erneut zu kodieren einfach auf diesen bereits kodierten Block verwiesen werden. Dieser Vorgang kann als Bewegungsausgleich (engl. „motion compensation") bezeichnet werden. Hierzu wird eine für jeden Rahmen neue Auflistung zuvor kodierter Rahmen verwendet, die als Referenz für den Bewegungsausgleich verwendet werden kann. Diese Liste wird auch Referenzbilderliste bezeichnet. Im Kern kann der Kodierer dabei den zu kodierenden Rahmen in einige nicht-überlappende Blöcke teilen. Anschließend kann der so erstellte Block mit zuvor kodierten Blöcken gemäß der dazu korrespondierenden Auflistung verglichen werden, um eine hohe - bevorzugt beste Übereinstimmung- aufzufinden. Die relative 2D Position des jeweiligen aufgefunden Blocks (d.h. der Bewegungsvektor) und die Differenz zwischen dem erstellten Block und dem aufgefundenen Block (d.h. das Rest-Signal (engl. residual signal)) kann dann (zusammen mit weiteren erstellten Blöcken, deren Position und deren Differenzen) kodiert werden.

Im Rahmen der Erfindung wird mindestens ein neuartiges Referenzbild basierend auf 3D Information erstellt und zu dieser Referenzbilderliste hinzugefügt oder statt eines vorhanden Referenzbildes eingefügt werden. Hierzu wird für eine einzige (monokulare) Kamera die Kameraparameter CP und für die 3D Szenen Geometrie Geometrie-Daten GD aus einem Satz von 2D Bildern erstellt, welchen von der sich bewegenden monokularen Kamera erfasst wurden.

Hieraus wird ein neuartiges Referenzbild basierend auf 3D Information für zu kodierende Rahmen erstellt, z.B. indem der Inhalt herkömmlicher Referenzbilder auf die Position des zu kodierenden Bildes verzerrt wird. Dieser Verzerrungsvorgang wird durch die erstellten / abgeschätzten Kameraparameter CP und für die 3D Szenen Geometrie Geometrie-Daten GD geleitet. Das so synthetisierte neuartiges Referenzbild basierend auf 3D Information erstellt und zu dieser Referenzbilderliste hinzugefügt. Das so erstellte neuartiges Referenzbild erlaubte eine verbesserte Leistungsfähigkeit in Bezug auf den Bewegungsausgleich, d.h. benötigt eine geringere Bitrate als herkömmliche Referenzbilder in der Referenzbilderliste. Hierdurch kann auch die am Ende benötigte Bitrate verringert werden und der Kodiergewinn erhöht werden.

Um die Laufzeit des Dekodierers gering zu halten können verschiedene Ansätze verwendet werden.

Zum einen ist festzustellen, dass die Synthese von Referenzbildern auf Seiten des Dekoders zeitintensiv ist. Es kann jedoch ausreichend sein, den Kodierer mit dem neuartiges 3D-Referenzbild nur für eine oder mehrere Teilbereiche / Regionen in dem zu kodierenden Rahmen zu verwenden, z.B. 20 % - 30 % der Fläche / Pixel, nämlich insbesondere für jene, bei denen es eine gute Inter-Frame Vorhersage durch Optimierung gibt. Beispeilhaft sei dies wie folgt illustriert. Es sei angenommen, dass es 3 Referenzen RI, R2, R3D gibt und ein zu-kodierender Frame sei in nicht übverschneidende Blöcke unterteilt. R3D wäre dann eine der durch die Erfindung bereitgestellten Referenzen. Dann würde der Kodierer zunächst einen ersten Block wählen und überprüfen, welches der ähnlichste Block in einem der Referenzen ist; dies würde dann nach und nach für jeden Block durchgeführt. Typischerweise wird in 20 % - 30 % der Fälle R3D aufgefunden während im Rest der Fälle RI oder R2 aufegefunden wird. Diese Information, welches Referenzbild für welchen Block verwendet wird kann in den Videobitstrom eingespeist werden. Der Dekodierer kann dann diese Information einfach lesen und das neuartiges Referenzbild basierend auf 3D Information zumindest für diese Regionen, d.h. nicht für den gesamten Bereich, zu erstellen. D.h., anders als der Kodierer, reciht es für den Dokidierer unter unständen aus, wenn nur der verewndete Teil der Referenz R3D für die Inter-Prediction erstellt wird, während es nicht notwendig ist die anderen Teile der Refererenz R3D ebenfalls zu erstellen.

Zum anderen kann festgestellt werden, dass Rahmen eine unterschiedliche Anteil zur finalen Bitrate haben, basierend auf deren Reihenfolge und Position in der verwendeten Kodiererstruktur. Hierzu sei auf Figur 5 verwiesen. Die Kreise stellen Rahmen mit der Darstellungsreihenfolge dar. Die Pfeile zeigen die konventionell erstellten Referenzbilder an, die für den Bewegungsausgleich verwendet werden können. Zum Beispiel kann der Rahmen F M Fi und Fi +S als Referenz verwenden. In der hierarchischen Kodierstruktur tragen Rahmen mit einer zeitlichen Kennung 4 (TI D=4) weniger zu finalen Bitrate bei als Rahmen mit einer zeitlichen Kennung von TID<3. Dies liegt hauptsächlich daran, dass diese für den Bewegungsausgleich ihren jeweils unmittelbaren (vorhergehenden / nachfolgenden) Rahmen für den Bewegungsausgleich verwenden, die jedoch fast gleichen Inhalt aufweisen. Dagegen verwendet der Rahmen Fi +g beispielsweise Fi und F M6 als Referenzbilder, die jedoch weiter voneinander entfernt sind.

Wir nehmen für die folgende Überlegung an, dass die im Rahmen der Erfindung vorgeschlagenen Vorgehensweise die Bitrate für jeden Rahmen um 5 % gegenüber dem bisherigen Vorgehen reduziert. Da Rahmen mit TID=4 weniger zu dem finalen Kodiergewinn / der finalen Bitrate beitragen (Annahme 10 % der gesamten Bitrate entfällt auf TID=4) fällt der Anteil der durch die Erfindung hier erzielt werden könnte entsprechend gering aus (5 % von 10 %). Man könnte daher für diesen Bereich auf die Verwendung des erfindungsgemäßen Verfahrens verzichten, da der Beitrag eher gering ist. Damit kann Rechenzeit / Speicherplatz gespart werden, um die Geschwindigkeit hoch zu halten bzw. für Bereiche bereitzuhalten, in denen das erfindungsgemäße Verfahren einen größeren Beitrag zu dem finalen Kodiergewinn / der finalen Bitrate beiträgt.

Wird z.B. angenommen, dass der Gewinn durch das erfindungsgemäße Verfahren bei Anwendung auf alle Rahmen einen finalen Kodiergewinn 3 % bereitstellen würde, so würde das Auslassen der Rahmen mit TID=4 diesen finalen Kodiergewinn auf circa 2,7 % abschmelzen. Hingegen könnte der Kodierer (mehr als) doppelt so schnell sein.

Selbst wenn man das erfindungsgemäße Verfahren nur auf TID<1 anwenden würde, so würde das Auslassen der anderen Rahmen diesen finalen Kodiergewinn auf circa 1 % abschmelzen.

Sinnvollerweise wird der Dekodierer über einen solchen Umstand informiert, falls der Kodierer eine oder mehrere Rahmen mit bestimmten TIDs nur kodiert bzw. nicht kodiert. Je nach Ausgestaltung kann dies durch ein Flag (reduziert / nicht-reduziert) oder durch ein Code-Wort (z.B. 1 für nur TID=l, 2 nur für TID=2, 4 nur TID=3 bzw. 3 für TID 1 und 2, ... ) verwendet werden.

Es sei angemerkt, dass die Kameraparameter CP und für die 3D Szenen Geometrie Geometrie-Daten GD nicht nur einmalig sondern wiederkehrend einzeln oder im Verbund vom Kodierer an den Dekodierer zur Verfügung gestellt werden können. Dabei kann jeweils ein neuer Satz als auch ein Update zur Verfügung gestellt werden.