DE112018002117T5

DE112018002117T5 - Systeme und verfahren für verzögerte post-prozesse in der videocodierung

Info

Publication number: DE112018002117T5
Application number: DE112018002117.3T
Authority: DE
Inventors: Michael Kopietz
Original assignee: Zenimax Media Inc
Current assignee: Zenimax Media Inc
Priority date: 2017-04-21
Filing date: 2018-04-20
Publication date: 2020-01-02
Also published as: AU2018254570A1; EP3613210A4; JP7077396B2; GB201916964D0; GB2576286B; RU2728812C1; RU2020124345A; KR20200019853A; MX2021004096A; US20190215520A1; CA3059743A1; TW202027504A; KR102282233B1; EP3613210A1; BR112019021627A2; CN111052738B; JP2020520203A; RU2020124345A3; ZA202007052B; TW201842775A

Abstract

Es werden Systeme und Verfahren zum Verzögern von Post-Prozess-Effekten bei der Videocodierung offenbart. Die Systeme und Verfahren sind in der Lage, die Fähigkeit der Client-Hardware zu berechnen, die Last zu verschieben, und eine bekannte Last eines oder mehrerer Verzögerungskandidaten zu summieren, um zu bewerten, wie viele Verzögerungskandidaten nach dem Prozess auf die Client-Hardware aufgeschoben werden können. Die Systeme und Verfahren sind auch in der Lage, eine aktualisierte Post-Prozess-Verzögerungsliste an einen entfernten Server zu senden, der die Liste der Post-Prozess-Verzögerungskandidaten während der Nachbearbeitungsphase eines ersten Videobildes anwenden kann.

Description

VERWANDTE ANWENDUNGEN
Diese Anmeldung beansprucht den Vorteil der folgenden US-Provisionalanmeldungen Nr. 62/488,526, eingereicht am 21. April 2017, und Nr. 62/618,498 , eingereicht am 17. Januar 2018.
HINTERGRUND DER ERFINDUNG
Remote-Gaming-Anwendungen, bei denen ein serverseitiges Spiel von einem client-seitigen Spieler gesteuert wird, haben versucht, die Videoausgabe einer dreidimensionalen (3D)-Grafik-Engine in Echtzeit mit vorhandenen oder benutzerdefinierten Codierern zu codieren. Die interaktive Natur von Videospielen, insbesondere die Rückkopplungsschleife zwischen Videoausgang und Spielereingang, macht das Spiel-Video-Streaming jedoch viel empfindlicher auf Latenzzeiten als herkömmliches Video-Streaming. Bestehende Videocodierverfahren können Rechenleistung und wenig anderes für eine Verkürzung der Codierzeit in Anspruch nehmen. Neue Methoden zur Integration des Codierungsprozesses in den Videowiedergabeprozess können eine deutliche Verkürzung der Codierungszeit bei gleichzeitiger Verringerung der Rechenleistung, Verbesserung der Qualität des codierten Videos und Beibehaltung des ursprünglichen Bitstream-Datenformats ermöglichen, um die Interoperabilität bestehender Hardwaregeräte zu erhalten.
Typische Video-Rendering-Pipelines sind getrennt und unabhängig von VideoCodierungspipelines, mit wenig Überschneidungen zwischen Prozess und Know-how in den beiden Bereichen. Infolgedessen sind einige der visuellen Effekte und Post-Prozesse, die in der Videorendering-Pipeline angewendet werden, kontraproduktiv für den Videocodierungsprozess, was zu Videoartefakten, erhöhter codierter Videogröße und längeren Codierungszeiten führt. Diese visuellen Effekte sind jedoch im resultierenden decodierten Video weiterhin erwünscht.
Durch die Integration von Videorendering und Videocodierungspipelines können Post-Prozess-Effekte verschoben werden, um den Codierungsprozess zu verbessern. So führt beispielsweise ein simuliertes filmisches Korn ein zufällig auftretendes animiertes Korn ein, das für typische Codierer schwer zu verarbeiten ist, ohne dass die Videoqualität oder das Kompressionsverhältnis erheblich beeinträchtigt wird. Einige Videocodierverfahren versuchen, dieses zusätzliche visuelle Rauschen vor der Codierung zu entfernen, aber diese Verfahren sind nur offline und rechenintensiv. Durch die Deaktivierung dieses spezifischen Post-Prozesses in der Rendering-Pipeline wird das Video automatisch einfacher zu codieren. Der Post-Prozess kann dann nach der Decodierung des Videos angewendet werden. Im Falle von filmischen Korn ist das Zusammensetzen des Kornes über das decodierte Video nicht rechenintensiv, kann in Echtzeit am Decoder erfolgen und kann die subjektive Videoqualität verbessern, indem es andere Codierungsartefakte verschleiert.
Die Internationale Patentanmeldung Nr. WO2016172314 A1 („die '314-Anmeldung“) offenbart Systeme und Verfahren, die auf die künstlerisch intendierte Inhaltscodierung ausgerichtet sind. Eine Codierungs-Benutzeroberfläche ermöglicht es einem Benutzer, einen künstlerischen Satz anzugeben und die Behandlung von Pixeln und/oder Blöcken zu konfigurieren, die einem künstlerischen Satz zugeordnet sind, wie beispielsweise eine Treueverbesserung, ein QP-Anpassungswert und/oder eine Nachbearbeitung. Beispiele für künstlerische Absichten, die der Videoausgabe hinzugefügt werden können, sind, wenn ein Codierer das Filmkorn aus dem Originalsignal entfernen kann, bevor er es codiert, und das Filmkorn SEI verwenden kann, um dem Decoder zu vermitteln, wie man das Filmkorn regeneriert und es wieder dem Videosignal hinzufügt, bevor es angezeigt wird. Die vorliegende Erfindung kann von der '314-Anwendung zumindest dadurch unterschieden werden, dass die '314-Anwendung keine Deaktivierung bestimmter Post-Prozesse in der Rendering-Pipeline vor der Codierung und dann die Anwendung dieser Post-Prozesse nach der Decodierung des Videos offenbart. Infolgedessen ist die vorliegende Erfindung eine Verbesserung dieser Computertechnologie, da sie eine verbesserte Codierung und Decodierung von Videodaten ohne erhebliche Kosten für die Videoqualität oder das Kompressionsverhältnis bietet. Die vorliegende Erfindung ist auch eine Verbesserung, da sie die resultierende Bandbreite, Bitrate und Codierungszeit verbessert und in Echtzeit-Videostreaming-Anwendungen mit verbesserter Videoqualität eingesetzt werden kann.
Das US-Patent Nr. 9,609,330 („das ’330er Patent“) offenbart eine inhaltsadaptive Entropiecodierung von Modi und Referenzdaten, was bedeutet, dass ein Voranalysesubsystem des Codierers Inhalte analysiert, um verschiedene Arten von Parametern zu berechnen, die für die Verbesserung der Effizienz und Geschwindigkeit der Videocodierung nützlich sind. Diese Parameter beinhalten horizontale und vertikale Gradienteninformationen (Rs, Cs), Varianz, räumliche Komplexität pro Bild, zeitliche Komplexität pro Bild, Szenenwechselerkennung, Bewegungsreichweitenschätzung, Verstärkungserkennung, Vorhersagedistanzschätzung, Anzahl der Objekte, Bereichsgrenzen-Erkennung, räumliche Komplexitätskartenberechnung, Fokusschätzung und Filmkornschätzung. Die vom Voranalysator-Subsystem erzeugten Parameter können dann vom Codierer verbraucht oder quantisiert und an den Decoder übertragen werden. Die vorliegende Erfindung kann erneut von der im Patent 330 offenbarten Technologie unterschieden werden, zumindest weil diese Technologie bestimmte Post-Prozesse in der Rendering-Pipeline vor der Codierung nicht deaktiviert und diese Post-Prozesse dann nach der Decodierung des Videos anwendet. Die vorliegende Erfindung stellt daher eine Verbesserung der Computertechnologie des ’330er Patents dar, da sie eine verbesserte Codierung und Decodierung von Videodaten ohne nennenswerte Kosten für die Videoqualität oder das Kompressionsverhältnis bietet und weil sie in Echtzeit-Videostreaming-Anwendungen mit verbesserter Videoqualität eingesetzt werden kann.
Das US-Patent Nr. 9,762,911 („das '911-Patent“) offenbart Systeme und Verfahren für Techniken im Zusammenhang mit der inhaltsadaptiven Vorhersage und Entropiecodierung von Bewegungsvektoren. Die offenbarte Technologie ermöglicht den Empfang von ersten Videodaten und zweiten Videodaten zur Entropiecodierung an einem Entropie-Codierer-Modul. Die ersten Videodaten und die zweiten Videodaten können verschiedene Datentypen sein (z. B. Kopfdaten, Morphing-Parameter, Syntheseparameter oder Global-Maps-Daten oder Bewegungsvektoren oder Intra-Prediction-Partitionsdaten oder so weiter, wie hierin näher erläutert wird). Eine erste Entropie-Codierungstechnik kann für die ersten Videodaten basierend auf einem Parameter bestimmt werden, der den ersten Videodaten zugeordnet ist, wie beispielsweise einer Anzahl von komprimierten Bits der ersten Videodaten, einem vorbestimmten Indikator oder Flag, der den ersten Videodaten zugeordnet ist, einem vorbestimmten Schwellenwert oder einem heuristisch bestimmten Schwellenwert oder dergleichen. In einigen Beispielen kann die erste Entropiecodierungstechnik ausgewählt werden aus einer adaptiven symbolgesteuerten variablen Längencodierungstechnik oder einer adaptiven Proxy-Codierungstechnik mit variabler Länge. Die ersten Videodaten können mit der ersten Entropiecodierungstechnik entropiecodiert werden und die zweiten Videodaten können mit der ersten Entropiecodierungstechnik entropiecodiert werden. Die vorliegende Erfindung ist zumindest deshalb unterscheidbar, weil die im '911-Patent offenbarte Technologie nicht die selektive Deaktivierung von Post-Prozessen in der Rendering-Pipeline vor der Codierung beinhaltet und diese Post-Prozesse dann nach der Decodierung des Videos anwendet. Wieder einmal stellt die vorliegende Erfindung eine Verbesserung der Computertechnologie des '911-Patents dar, da sie eine verbesserte Codierung und Decodierung von Videodaten ohne erhebliche Kosten für die Videoqualität oder die Kompressionsrate bietet. Die vorliegende Erfindung ist auch eine Verbesserung, da sie die resultierende Bitrate und Codierungszeit verbessert und in Echtzeit-Videostreaming-Anwendungen mit verbesserter Videoqualität eingesetzt werden kann.
Wie aus der obigen Diskussion über den Stand der Technik in dieser Technologie hervorgeht, besteht in der Technik ein Bedarf an einer Verbesserung der derzeitigen Computertechnologie im Zusammenhang mit der Videocodierung in Spielumgebungen.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist daher eine Aufgabe der hierin offenbarten exemplarischen Ausführungsformen, Nachteile in der Technik zu beheben und Systeme und Verfahren zur Verfügung zu stellen, um Latenzzeiten und Codierungszeiten durch Techniken zu verringern, bei denen ein Server eine Anweisung an eine Client-Anwendung überträgt, um die Fähigkeit der Client-Hardware zu messen, und eine Anweisung an eine Client-Anwendung überträgt, eine bekannte Last eines oder mehrerer vorbestimmter Post-Prozess-Verzögerungskandidaten zu summieren, um zu bewerten, wie viele Post-Prozess-Verzögerungskandidaten in der Lage sind, auf die Client-Hardware verschoben zu werden. Bei der Client-Anwendung wird die Post-Prozess-Verzögerungsliste in umgekehrter Reihenfolge erstellt und aufgebaut. Der Server erhält dann die Post-Prozess-Verzögerungsliste, überspringt die Liste der verzögerten Post-Prozesse während der Post-Prozessing-Phase eines ersten Videobildes und sendet eine Anweisung an eine Client-Anwendung, ein Bild zu rendern.
Es ist ein weiteres Objekt der Erfindung, Systeme und Verfahren zur Verringerung von Latenz- und Codierungszeiten bereitzustellen, indem eine Client-Anwendung einen Rückruf oder eine Abfrage auf ein oder mehrere Betriebssystemereignisse durchführt, um festzustellen, ob die Fähigkeit der Client-Hardware neu gemessen werden soll.
Es ist noch eine weitere Aufgabe der Erfindung, Systeme und Verfahren zur Verringerung von Latenzzeiten und Codierungszeiten bereitzustellen, indem die Fähigkeit der Client-Hardware gemessen wird, indem verfügbare Befehlssätze, Speicher-, CPU- und/oder GPU-Eigenschaften erkannt werden.
Es ist noch eine weitere Aufgabe der Erfindung, Systeme und Verfahren zur Verringerung von Latenzzeiten und Codierungszeiten bereitzustellen, indem bewertet wird, wie viele Post-Prozess-Verzögerungskandidaten in der Lage sind, durch Messung der Bildrate und/oder des Ressourcenverbrauchs auf die Client-Hardware verschoben zu werden.
Figurenliste
Eine umfassendere Würdigung der Erfindung und vieler der damit verbundenen Vorteile wird leicht erlangt, da diese durch Bezugnahme auf die folgende ausführliche Beschreibung besser verstanden wird, wenn sie im Zusammenhang mit den beigefügten Zeichnungen betrachtet wird, wobei:

1 ein Blockdiagramm ist, das eine beispielhafte 3D-Grafik-Engine veranschaulicht, die ein Video zur Ansicht auf einem entfernten Client gemäß einer Ausführungsform der Erfindung wiedergibt;
2 ein Flussdiagramm ist, das die beispielhaften Schritte veranschaulicht, die zur Verbesserung der Codierungszeit oder der subjektiven Videoqualität erforderlich sind, indem die Nachbearbeitung pro Pixel gemäß einer Ausführungsform der Erfindung verschoben wird;
3 ein Diagramm ist, das eine beispielhafte minimale Implementierung der verzögerten Pro-Pixel-Qualität während der Videowiedergabe-, Codierungs- und Decodierungsphasen gemäß einer Ausführungsform der Erfindung veranschaulicht; und
4 ein Flussdiagramm ist, das die beispielhafte Kommunikation zwischen einem Server und einem Client veranschaulicht, um die Liste der verzögerten Post-Prozesse gemäß einer Ausführungsform der Erfindung zu synchronisieren.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Bei der Beschreibung der bevorzugten Ausführungsformen der in den Zeichnungen dargestellten Erfindung wird aus Gründen der Übersichtlichkeit auf eine spezifische Terminologie zurückgegriffen. Die Erfindung soll sich jedoch nicht auf die so ausgewählten spezifischen Begriffe beschränken, und es ist zu verstehen, dass jeder spezifische Begriff alle technischen Äquivalente umfasst, die ähnlich arbeiten, um einen ähnlichen Zweck zu erfüllen. Mehrere bevorzugte Ausführungsformen der Erfindung werden zur Veranschaulichung beschrieben, wobei davon ausgegangen wird, dass die Erfindung auch in anderen Formen verkörpert werden kann, die nicht ausdrücklich in den Zeichnungen dargestellt sind.
Post-Processing-Pipelines können viele komplexe Prozesse durchführen, darunter Anti-Aliasing, Bewegungsunschärfe, Tiefenschärfe, Farbkorrektur, Blüte, Filmkorn, chromatische Aberration, Vignettierung und Tonemapping. Einige dieser Effekte beeinträchtigen aktiv die Codierungsprozesse, erhöhen die Codierungszeiten und verringern die Kompressionsraten im Vergleich zu unverarbeiteten Frames. Das Warten auf die Anwendung bestimmter Post-Prozesse, bis ein Bild decodiert ist, kann die subjektive Videoqualität erhöhen und zusätzliche vorteilhafte Kompromisse mit sich bringen.
Während der Entwicklung der Client-Anwendung sollte das Gleichgewicht zwischen Codierungszeit, Bandbreite und subjektiver Qualität für jeden Post-Prozess in der Rendering-Pipeline bewertet werden, um festzustellen, welche Post-Prozesse gute Kandidaten für eine Verschiebung sind. Die Liste der Verzögerungskandidaten wird vom Client während der Laufzeit verwendet, um festzustellen, welche der Post-Prozesse auf den Client aufgeschoben werden können.
Jeder Post-Prozess sollte getestet werden, um seine Auswirkungen auf den Codierungsprozess zu messen. Zunächst sollte eine Reihe von Bezugsrahmen durch die unveränderten Rendering- und Codierleitungen geführt und die Codierzeit und die codierte Rahmengröße gemessen werden. Die Post-Prozesse sollten nacheinander in der Rendering-Pipeline abgeschaltet werden und die Codierungszeit und die codierte Framegröße sollten mit den Kontrollergebnissen verglichen werden. Diese Messungen werden dazu beitragen, festzustellen, welche Post-Prozesse gute Kandidaten für eine Verschiebung sind. Fast jeder Post-Prozess-Effekt, der die Bildentropie erhöht, gemessen an einer vergrößerten codierten Bildgröße, wäre wahrscheinlich ein guter Kandidat für eine Verschiebung. So fügt beispielsweise ein simulierter Filmkorn-Post-Prozess zufälliges Rauschen über ein Bild hinzu, was zu niedrigeren Kompressionsverhältnissen führt. In bestimmten Situationen können chromatische Aberration und Bloom die Bildentropie erhöhen und zu niedrigeren Kompressionsraten führen. Fast jeder Post-Prozess-Effekt, der Entropie oder Bilddaten reduziert, sollte nicht verschoben werden, da Entropie-Reduktionen den Aufwand für die Codierung verringern.
Post-Prozesse, die die Bildentropie nicht verändern, können als Verzögerungskandidaten ausgewählt werden, um sekundäre Ziele wie die subjektive Verbesserung der Videoqualität oder die Verringerung der Serverlast zu erreichen. So kann beispielsweise die Farbabstufung die Codierungszeit oder die Bandbreitenauslastung nicht beeinflussen, aber zu einer messbaren Verringerung der serverseitigen Rechenlast führen, wenn sie auf den Client verschoben wird. Ebenso kann Anti-Aliasing die subjektive Videoqualität verbessern und die serverseitige Belastung drastisch verringern, wenn sie verschoben wird. Es sollten zusätzliche Tests durchgeführt werden, um festzustellen, ob es sinnvoll ist, entropie-neutrale Post-Prozesse aufzuschieben. So kann beispielsweise ein ähnliches Testverfahren mit Referenzrahmen verwendet werden, um die Serverlast vor und nach der Verschiebung eines Entropie-neutralen Post-Prozesses zu vergleichen.
Die Client-Anwendung sollte in der Lage sein, die Post-Processing-Berechnungen für jeden Stundungskandidaten durchzuführen. Ein gewisses Code-Refactoring kann notwendig sein, um diese Funktionen in die Client-Anwendung zu verschieben. Post-Prozesse am Ende der Rendering-Pipeline, wie z. B. Filmkörnung, chromatische Aberration oder Vignettierung, sind im Allgemeinen einfacher in die Client-Anwendung zu überführen als diejenigen, die früher in der Rendering-Pipeline auftreten, wie z. B. Anti-Aliasing oder Tiefenschärfe. Es kann einige Fälle geben, in denen das Verschieben eines Post-Prozesses dazu führt, dass er im nichtlinearen Raum angewendet wird, wenn er typischerweise im linearen Raum angewendet wird, wie beispielsweise bei Post-Prozessen, die vor der Tonwertkorrektur angewendet werden, wie chromatische Aberration, Bloom oder Vignettierung. Der Prozess kann direkt im Gamma-Raum angewendet werden und ist möglicherweise nicht mathematisch korrekt, aber der Unterschied kann für den Betrachter unmerklich sein und die subjektive Gesamtqualität kann verbessert werden. Andernfalls kann die Client-Anwendung auf Kosten einiger client-seitiger Rechenzyklen und eines Verlustes der Bildqualität das Bild zurück in den linearen Raum konvertieren, den Post-Prozess anwenden und dann wieder in den Gamma-Raum konvertieren. Die Rückkonvertierung in den linearen Raum führt zu Qualitätseinbußen, da das Bild während der Codierung quantisiert und komprimiert wurde. Diese subjektiven Qualitätsentscheidungen sollten während der Entwicklung der Clientanwendung getroffen werden.
Alle Post-Prozesse, die die Clientbewerbung durchführen kann, bilden die Grundlage für die Kandidatenliste der Stundung. Die Liste der Verzögerungskandidaten sollte in der gleichen Reihenfolge sein, in der sie in der Rendering-Pipeline erscheinen, um Abhängigkeiten zu wahren. Jeder Verzögerungskandidat in der Liste sollte auch mit Hardware-Feature-Anforderungen wie Speicherminima oder GPU-Anforderungen gekoppelt werden.
1 veranschaulicht ein Beispielsystem, in dem Post-Prozesse in Pixelqualität während des Videorenderings verschoben werden. Dieses Beispielsystem stellt eine Echtzeit-Fernspiel-Streaming-Anwendung dar, die im Vergleich zu anderen Arten von Videosystemen am meisten von den subjektiven Qualitätsverbesserungen und verkürzten Codierungszeiten profitiert, die durch die Verschiebung von Qualitätsprozessen pro Pixel entstehen. In diesem System hostet ein Server 100 die Videospiel-Software 102 und eine Grafik-Engine 104, die die Videoausgabe übernimmt. Das Video wird in einem Codierer 106 codiert und die codierten Videodaten 108 werden an einen entfernten Client übertragen. Die Serverarchitektur 100 ist eine beliebige Kombination aus Hard- oder Software, die die Funktionen der Grafik-Engine 104 und des Codierer 106 unterstützen kann. In dem gegebenen Beispiel kann die Grafik-Engine 104 als beispielsweise eine GPU 110 implementiert werden, die Videospielsoftware 102 ausführt, die in einen computerlesbaren Speicher 112 geladen wird, während der Codierer 106 (auch als Codierer bezeichnet) als CPU 114 mit Videocodierungssoftware implementiert werden kann.
Das Remote-Client-Computersystem 116 ist in der Lage, einen clientseitigen Codierer 118 zum Decodieren der übertragenen codierten Videodaten 108 und eine Client-Anwendung 120 zum Anwenden der verzögerten pixelqualitativen Post-Prozesse auszuführen. Das Client-Computersystem 116 enthält auch eine Anzeigesteuerung 122 zum Ansteuern der Anzeigehardware 124. Die Eingaben der Client-seitigen Eingabeperipherie 126 werden von der Client-Anwendung 120 in Steuerdaten 128 umgewandelt, die an die auf dem Server 100 laufende Spielsoftware 102 zurückgesendet werden. Basierend auf der spezifischen Implementierung der verzögerten pixelgenauen Nachbearbeitung müssen möglicherweise einige zusätzliche Steuerdaten 128 von der serverseitigen Software 102 zur Client-Anwendung 120 fließen, um sicherzustellen, dass die richtigen Nachbearbeitungen für einen bestimmten Videoframe angewendet werden.
2 veranschaulicht die Schritte, die erforderlich sind, um die Nachbearbeitung in einem System, das Videos rendert, codiert und decodiert, zu verschieben. Bei Schritt 200 beginnt die Rendering-Pipeline wie gewohnt auf dem Server 100. Vor der Nachbearbeitungsphase sind keine Änderungen am Renderingprozess erforderlich.
Bei Schritt 202, in der Nachbearbeitungsphase des Videorenderings in der Grafik-Engine 104 des Servers 100, sollten alle Nachbearbeitungen, die verschoben werden, übersprungen werden. Eine beliebige Anzahl von Post-Prozessen kann übersprungen werden, wenn das Client-Computersystem 116 über die erforderliche Rechenleistung verfügt, um alle verzögerten Post-Prozesse anzuwenden. 4 beschreibt im Detail, wie der Server 100 bestimmt, welche Post-Prozesse verschoben werden. Nachdem Sie einen verzögerten Post-Prozess übersprungen haben, sollte die Rendering-Pipeline fortgesetzt werden, bis der Frame vollständig gerendert ist.
Bei Schritt 204 wird der resultierende Rahmen am Codierer 106 codiert. Basierend auf der Auswahl der verzögerten Post-Prozesse kann die Codierungszeit schneller sein und die codierten Daten können weniger Bandbreite benötigen. Wenn beispielsweise ein Nachbearbeitungsprozess für Filmkörner verschoben wird, hat der Codierer 106 eine einfachere Zeit, um das Bild ohne das eingeführte Rauschen zu codieren.
Bei Schritt 206 werden die codierten Videodaten 108 gespeichert oder bei Bedarf an das entfernte Client-Computersystem 116 übertragen. In einer Echtzeit-Videospiel-Streaming-Anwendung, wie im Beispiel aus 1, werden die Videodaten 108 sofort übertragen. In alternativen Ausführungsformen des Systems können die codierten Videodaten 108 auf einem Server 100 für On-Demand-Streaming gespeichert oder auf physischen Medien gespeichert werden.
Bei Schritt 208 wird das codierte Video am Codierer 118 des Remote-Client-Computersystems 116 decodiert. Es müssen keine Änderungen am Decodierungsprozess vorgenommen werden.
Bei Schritt 210 wendet eine Softwareanwendung alle Post-Prozesse an, die in der gleichen Reihenfolge verschoben wurden, wie sie in der Rendering-Pipeline erscheinen würden. Diese Software, die in 1 als Client-Anwendung 120 dargestellt ist, muss möglicherweise auch Steuerdaten 128 vom Server 100 empfangen, wenn sich die verzögerten Post-Prozesse von Frame zu Frame ändern. Die Client-Anwendung 120 muss möglicherweise auch Steuerdaten 128 senden, wenn das Video interaktiv ist, wie in Videospiel-Streaming-Systemen. Die Client-Anwendung 120 kann je nach den Anforderungen an die Rechenkomplexität der aufgeschobenen Post-Prozesse spärlich sein, was eine größere Bandbreite an Rechenleistung beim Client ermöglichen kann.
3 veranschaulicht die Implementierung der verzögerten Nachbearbeitung im Beispielsystem von 1. Eine typische 3D-Rendering-Pipeline, dargestellt unter „RENDERING PIPELINE“, Schritt 300, auf dem Server 100, besteht aus den Phasen „APPLICATION“, Schritt 302, „GEOMETRY“, Schritt 304 und Rasterung, dargestellt als „RASTERIZATION“, Schritt 306. Die Ausgabe der Rasterphase bei „RASTERIZATION“, Schritt 306, ist ein vollständiges Videobild, das oft durch Nachbearbeitung bei „POST-PROCESSING“, wie in Schritt 308 dargestellt, erweitert wird. Einige Post-Prozesse beeinträchtigen die Codierungszeit oder -bandbreite während des Codierungsprozesses bei „ENCODING“, Schritt 310, und diese Post-Prozesse werden in der Nachbearbeitungsphase bei „POST-PROCESSING“, Schritt 308, übersprungen, wenn der Client sie später anwenden kann. Die restlichen Post-Prozesse, die nicht auf den Client 116 verschoben werden, werden wie gewohnt während der Nachbearbeitung bei „POST-PROCESSING“, Schritt 308, angewendet. Das Ausgangsvideo wird bei „ENCODING“, Schritt 310 codiert und bei „TRANSMISSION“, Schritt 312, übertragen.
Wenn der Client 116 das codierte Videobild empfängt, wird es bei „DECODING“, Schritt 314, decodiert. An dieser Stelle werden alle verzögerten Post-Prozesse auf den decodierten Frame bei „VERZÖGERTES POST-PROCESSING“, Schritt 316, angewendet. Bei filmischen Körnungen kann beispielsweise ein animierter Effekt im Voraus zwischengespeichert und mit relativ geringem Rechenaufwand über das decodierte Bild zusammengesetzt werden. Es gibt bereits Echtzeitlösungen für Farbkorrekturen, Dithering und Schärfen von Videos, die auf der Grundlage der Rechenleistung eines Client angewendet werden können. Das resultierende Videobild wird bei „DISPLAY“, Schritt 318, angezeigt.
4 veranschaulicht einen Prozess, bei dem die Client-Anwendung 120 die Liste der zu verschiebenden Post-Prozesse erstellt und die Liste an den Server 100 übermittelt.
Bei Schritt 400 misst die Client-Anwendung 120 die Fähigkeit der Client-Hardware, zu bestimmen, welche Post-Prozesse auf den Client 116 verschoben werden können. Die Clientfähigkeit kann durch die Funktionserkennung für Hardwareinformationen wie verfügbare Befehlssätze, Speicher, CPU oder GPU gemessen werden.
Bei Schritt 402 liest die Client-Anwendung 120 die Liste der und verwirft alle Verzögerungskandidaten, für die die Hardwareanforderungen vom Client nicht erfüllt werden. Die Aufschiebung der Post-Prozesse der Kandidaten sollte mit dem Client verglichen werden, um die Leistung des Clients in Echtzeit zu messen. Die Verzögerungskandidaten werden nacheinander dem Benchmarking-Prozess hinzugefügt, bis der Client nicht mehr in der Lage ist, die gewünschte Leistung gemessen an der Bildrate, dem Ressourcenverbrauch oder einer anderen Live-Messung aufrechtzuerhalten. Das Benchmarking kann während der Installation der Client-Anwendung, während des Initialladens der Client-Anwendung 120 oder bei jedem Laden der Anwendung durchgeführt werden.
Der Client 116 sollte die Nachbearbeitung für möglichst viele Stundungskandidaten durchführen. Die Stundungsliste wird in umgekehrter Reihenfolge erstellt, um die gesamte Reihenfolge der Vorgänge in der Nähe der ursprünglichen Reihenfolge der Rendering-Pipelines zu halten. So kann beispielsweise eine mobile Vorrichtung nur die letzten Post-Prozesse ausführen, ein Laptop die drei Post-Prozesse am Ende der Rendering-Pipeline, während ein neuer Desktop-Computer alle Post-Prozesse in der Aufschub-Kandidatenliste ausführen kann.
Bei Schritt 404 sendet der Client 116 die Liste der Post-Prozesse, um sie auf den Server 100 zu verschieben.
Bei Schritt 202 verwendet der Server 100 die Liste der verzögerten Nachbearbeitungen während der Nachbearbeitungsphase des ersten Videobilds. Alle Post-Prozesse auf der Stundungsliste werden übersprungen.
Bei Schritt 206 beginnt der codierte Videodatenstrom 108 mit der Übertragung an den Client 116. Da der Client 116 die Verzögerungsliste gesendet hat, bevor irgendwelche Frames generiert wurden, müssen keine zusätzlichen Metadaten vom Server 100 an den Client 116 gesendet werden. Der Client 116 weiß automatisch, welche Post-Prozesse verschoben wurden.
Bei Schritt 210 wendet der Client 116 alle Post-Prozesse in der Stundungsliste an. Der Client 116 wird die verzögerten Post-Prozesse weiterhin auf zukünftige Frames anwenden.
Es kann Szenarien geben, in denen sich die Client-Fähigkeiten während der Laufzeit ändern, so dass die Liste der verzögerten Post-Prozesse geändert werden muss. Wenn die Client-Anwendung beispielsweise auf einem mobilen Gerät ausgeführt wird, das gerade in den Energiesparmodus gewechselt hat, kann der Client die Liste der verzögerten Post-Prozesse verkleinern. In diesem Beispiel müsste die Client-Anwendung einen Rückruf registrieren oder die Ereignisse des Betriebssystems („OS“) abfragen, um auf Änderungen des Batteriestatus zu achten. Bei Schritt 412 reagiert die Client-Anwendung 120 auf eine aktuelle Umgebungsänderung, indem sie die Client-Fähigkeit neu misst. Eine Umgebungsänderung kann jede Änderung sein, die sich auf die Hardwareleistung des Remote-Client-Computersystems 116 auswirkt. Für das obige Beispiel reduziert der Batteriesparmodus die Taktfrequenz um einen Multiplikator, der direkt abgerufen werden kann. Die Änderung des Taktmultiplikators kann eine grobe Schätzung für die Änderung der Client-Fähigkeit liefern. Andernfalls kann zu der in Schritt 402 beschriebenen Benchmarkphase ein zusätzlicher Benchmark im Batteriesparmodus hinzugefügt werden.
Wenn sich die Client-Fähigkeit geändert hat, wird die Client-Anwendung 120 neu bewerten, welche Post-Prozesse bei Schritt 414 verschoben werden können. Im Beispiel des Batteriesparmodus kann die Verzögerungsliste proportional zur Änderung des Taktmultiplikators schrumpfen. Wenn der Batteriesparmodus beispielsweise die Taktfrequenz um 50 % verringert, verkleinert sich die Verzögerungsliste um mindestens die Hälfte. Wenn der Client 116 vier Post-Prozesse verschoben hat, wird die Liste auf zwei Post-Prozesse reduziert. Andernfalls, wenn zuvor ein Benchmarking des Batteriesparmodus durchgeführt wurde, ist die Verzögerungsliste bereits bekannt.
Wenn die Stundungsliste geändert wird, sendet der Client 116 die geänderte Stundungsliste bei Schritt 416 an den Server 100. Der Client 116 wendet die Post-Prozesse aus der ursprünglichen Verzögerungsliste weiterhin an, bis er eine Nachricht vom Server 100 erhält, die vorzugsweise aus einer anderen Liste von aufgeschobenen Post-Prozessen besteht.
Bei Schritt 418 wendet der Server 100 die geänderte Verzögerungsliste auf das nächste verfügbare Frame an. Um mit dem Client 116 zu synchronisieren, werden einige Metadaten auf diesen Frame angewendet.
Bei Schritt 420 wird der Rahmen der codierten Videodaten 108 mit den entsprechenden Metadaten gesendet.
Der Client wartet, bis er das Metadaten-Flag erhält. Bei Schritt 422 beginnt der Client 116 mit der Verarbeitung von Frames gemäß der geänderten Verzögerungsliste. Der Client 116 wird die aufgeschobenen Post-Prozesse gemäß der geänderten Stundungsliste weiterhin anwenden. Wenn sich die Laufzeitumgebung wieder ändert, kann die Stundungsliste ab Schritt 412 wieder wachsen oder schrumpfen. Wenn die Stundungsliste aufgrund eines temporären Umgebungswechsels, wie z. B. des Batteriesparmodus auf einem mobilen Gerät, schrumpft, sollte die Client-Anwendung 120 die Stundungsliste so schnell wie möglich wachsen lassen, damit die maximal möglichen Nachbearbeitungen zu einem bestimmten Zeitpunkt verschoben werden.
BEISPIEL 1: Benchmark-Testergebnisse
Filmisches Korn führt zu zufällig auftretendem visuellem Rauschen, das einen erheblichen Einfluss auf das Kompressionsverhältnis des Codierers hat. Die Anwendung von Post-Prozessen wie z. B. filmische Körnung auf der Clientseite führt zu kleineren codierten Bildgrößen.

Experimentelle Bitratenwerte wurden aufgenommen, während die Grafik-Engine eine Ausgabe mit einer Auflösung von 1280x720 bei 60 Bildern pro Sekunde erzeugte und über 60 Bilder pro Sekunde gemittelt wurde, um eine durchschnittliche Bitrate zu finden. Die Messwerte vergleichen die Bitrate eines Videostroms, bei dem filmisches Korn serverseitig aufgebracht wird, mit der Bitrate eines Videostroms, bei dem das filmische Korn auf den Client verschoben wird. Diese Messungen werden für drei verschiedene Größen von Filmkörnern und für zwei Einstellwerte der Codiererqualität wiederholt. Das Filmkorn 1 stellt die kleinste Korngröße dar, während das Filmkorn 3 die größte Korngröße darstellt. Die experimentellen Ergebnisse sind in den Tabellen 1 und 2 wiedergegeben. Tabelle 1 zeigt die Ergebnisse bei einer Codiererqualität von 16, während Tabelle 2 die Ergebnisse bei einer Codiererqualität von 20 zeigt. TABELLE 1: Bitratenergebnisse bei einer Codiererqualitätseinstellung von 16

Codierer-Qualität = 16	Serverseitige filmische Körnung	Verzögerte filmische Körnung
Filmische Körnung 1	550 KByte/s	270 KByte/s
Filmische Körnung 2	1700 KByte/s	270 KByte/s
Filmische Körnung 3	1900 KByte/s	270 KByte/s

TABELLE 2: Bitratenergebnisse bei einer Codiererqualitätseinstellung von 20

Codierer-Qualität = 20	Serverseitige filmische Körnung	Verzögerte filmische Körnung
Filmische Körnung 1	150 KByte/s	140 KByte/s
Filmische Körnung 2	270 KByte/s	140 KByte/s
Filmische Körnung 3	520 KByte/s	140 KByte/s

Basierend auf experimentellen Ergebnissen ist es offensichtlich, dass Post-Prozesse wie filmische Körnung zu größeren codierten Bildgrößen führen, was unerwünscht ist. Diese negativen Effekte treten bei höheren Codiererqualitätswerten deutlicher zutage und werden mit zunehmender Anzahl der eingeführten Rauschen noch deutlicher. Durch die Verschiebung des filmischen Korns auf den Client kann jedoch eine drastische Verringerung der Bitrate erreicht werden, wie in den Tabellen 1 und 2 dargestellt, wo die Bitrate auf 270 Kbyte/s bzw. 140 Kbyte/s reduziert wird. Unabhängig von der Menge des eingeleiteten Rauschens, gemessen an der Größe des Filmkorns in diesen Experimenten, bleibt die Bitrate bei einer gegebenen Codiererqualität stabil.
Ebenso wurden, wie in Tabelle 3 unten dargestellt, experimentelle Codierungszeiten gemessen, während die Grafik-Engine eine Ausgabe mit einer Auflösung von 1280x720 bei 60 Bildern für mehrere Einstellungen der Codiererqualität erzeugte. Die Messwerte vergleichen die Codierungszeiten für einen Videostrom, bei dem filmisches Korn serverseitig angewendet wird, mit der Codierungszeit eines Videostroms, bei dem das filmische Korn auf den Client verschoben wird. Die Größe des filmischen Korns bleibt über alle Messungen hinweg konstant. Wie aus Tabelle 3 ersichtlich ist, sind die Verkürzungen der Codierungszeiten unter Anwendung der hierin beschriebenen Techniken bei höheren Einstellungen der Codiererqualität deutlicher zu erkennen. TABELLE 3: Latenzergebnisse über die Codierer-Qualitätseinstellungen hinweg

Codierer-Qualität Serverseitige filmische Körnung Verzögerte filmische Körnung

15 16 ms 10 ms

17 15 ms 10 ms

20 11 ms 9 ms

25 9 ms 7 ms

40 9 ms 7 ms
Die vorstehende Beschreibung und die Zeichnungen sind nur als Illustration der Prinzipien der Erfindung zu betrachten. Die Erfindung ist nicht dazu bestimmt, durch die bevorzugte Ausführungsform eingeschränkt zu werden, und kann auf verschiedene Weise implementiert werden, die für eine der üblichen Fertigkeiten in der Kunst klar erkennbar sind. Zahlreiche Anmeldungen der Erfindung werden den Fachleuten leicht fallen. Daher ist es nicht erwünscht, die Erfindung auf die offenbarten spezifischen Beispiele oder die genaue Konstruktion und Funktionsweise zu beschränken. Vielmehr können alle geeigneten Modifikationen und Äquivalente herangezogen werden, die in den Anwendungsbereich der Erfindung fallen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62488526 [0001]
US 62/618498 [0001]
WO 2016172314 A1 [0005]
US 9609330 [0006]
US 9762911 [0007]

Claims

Computerimplementiertes Verfahren zum Aufschieben von Post-Prozessen, umfassend die folgenden Schritte: Übertragen einer Anweisung an eine Client-Anwendung zum Messen der Client-Hardwarefähigkeit; und Übertragen einer Anweisung an eine Client-Anwendung, eine bekannte Last eines oder mehrerer vorgegebener Post-Prozess-Verzögerungskandidaten zu summieren, um zu bewerten, wie viele Post-Prozess-Verzögerungskandidaten in der Lage sind, auf Client-Hardware verschoben zu werden, wobei eine Post-Prozess-Verzögerungsliste erstellt wird, wobei die Post-Prozess-Verzögerungsliste in umgekehrter Reihenfolge aufgebaut ist, und wobei ein Server die Post-Prozess-Verzögerungsliste empfängt, die Liste der verzögerten Post-Prozesse während der Post-Prozess-Phase eines ersten Videobildes überspringt und eine Anweisung an eine Client-Anwendung sendet, ein Bild zu rendern.
Verfahren nach Anspruch 1, wobei die Post-Prozess-Verzögerungsliste zu einem Benchmarking-Prozess hinzugefügt wird.
Verfahren nach Anspruch 1, wobei die Client-Anwendung die Fähigkeit der Client-Hardware als Reaktion auf eine oder mehrere Umgebungsänderungen neu misst.
Verfahren nach Anspruch 3, wobei die Client-Anwendung einen Rückruf durchführt oder ein oder mehrere Betriebssystemereignisse abfragt, um zu bestimmen, ob die Fähigkeit der Client-Hardware neu gemessen werden soll.
Verfahren nach Anspruch 1, wobei die Client-Anwendung bewertet, wie viele Post-Prozess-Verzögerungskandidaten durch Messen der Bildrate und/oder des Ressourcenverbrauchs auf die Client-Hardware aufgeschoben werden können.
Verfahren nach Anspruch 1, wobei der Server die aktualisierte Verzögerungsliste auf ein nächstes verfügbares Videobild anwendet.
Verfahren nach Anspruch 1, ferner umfassend den Schritt des Servers, codierte Videodaten an die Client-Anwendung ohne Metadaten, die mit Post-Prozessen verbunden sind, zu übertragen.
Verfahren nach Anspruch 1, wobei die Fähigkeit der Client-Hardware durch Erfassen verfügbarer Befehlssätze, Speicher-, CPU- und/oder GPU-Eigenschaften gemessen wird.
Verfahren nach Anspruch 1, wobei die Liste der Kandidaten für die Verschiebung nach dem Prozess basierend auf Änderungen des Batteriestatus der Client-Hardware neu berechnet wird.
Verfahren nach Anspruch 1, wobei der Server das erste oder nächste verfügbare Videobild an die Clientanwendung mit einem Metadaten-Flag zurückgibt.
System zum Aufschieben von Post-Prozessen, wobei über ein Netzwerk ein Server: eine Anweisung an eine Client-Anwendung überträgt, um die Hardwarefähigkeit des Clients zu messen; und eine Anweisung an eine Client-Anwendung überträgt, eine bekannte Last eines oder mehrerer vorgegebener Post-Prozess-Verzögerungskandidaten zu summieren, um zu bewerten, wie viele Post-Prozess-Verzögerungskandidaten in der Lage sind, auf Client-Hardware verschoben zu werden, wobei eine Post-Prozess-Verzögerungsliste erstellt wird, wobei die Post-Prozess-Verzögerungsliste in umgekehrter Reihenfolge aufgebaut ist, und wobei ein Server die Post-Prozess-Verzögerungsliste empfängt, die Liste der verzögerten Post-Prozesse während der Post-Prozess-Phase eines ersten Videobildes überspringt und eine Anweisung an eine Client-Anwendung sendet, ein Bild zu rendern.
System nach Anspruch 11, wobei die Post-Prozess-Verzögerungsliste zu einem Benchmarking-Prozess hinzugefügt wird.
System nach Anspruch 11, wobei die Client-Anwendung die Fähigkeit der Client-Hardware als Reaktion auf eine oder mehrere Umgebungsänderungen neu misst.
System nach Anspruch 13, wobei die Client-Anwendung einen Rückruf durchführt oder ein oder mehrere Betriebssystemereignisse abfragt, um zu bestimmen, ob die Fähigkeit der Client-Hardware neu gemessen werden soll.
System nach Anspruch 11, wobei die Client-Anwendung auswertet, wie viele Post-Prozess-Verzögerungskandidaten durch Messen der Bildrate und/oder des Ressourcenverbrauchs auf die Client-Hardware aufgeschoben werden können.
System nach Anspruch 11, wobei der Server die aktualisierte Liste von Post-Prozess-Verzögerungskandidaten auf einen nächsten verfügbaren Videoframe anwendet.
System nach Anspruch 11, wobei der Server codierte Videodaten an die Client-Anwendung überträgt, ohne Metadaten, die mit Post-Prozessen verbunden sind.
System nach Anspruch 11, wobei die Fähigkeit der Client-Hardware durch Erfassen verfügbarer Befehlssätze, Speicher-, CPU- und/oder GPU-Eigenschaften gemessen wird.
System nach Anspruch 11, wobei die Post-Prozess-Verzögerungskandidaten für die Verschiebung nach dem Prozess basierend auf Änderungen des Batteriestatus der Client-Hardware neu berechnet wird.
System nach Anspruch 11, wobei der Server das erste oder nächste verfügbare Videobild an die Clientanwendung mit einem Metadaten-Flag zurückgibt.