DE102022126701A1 - Niederfrequente nichttrennbare transformation und mehrfachtransformationsauswahl-deadlock-prävention - Google Patents

Niederfrequente nichttrennbare transformation und mehrfachtransformationsauswahl-deadlock-prävention Download PDF

Info

Publication number
DE102022126701A1
DE102022126701A1 DE102022126701.6A DE102022126701A DE102022126701A1 DE 102022126701 A1 DE102022126701 A1 DE 102022126701A1 DE 102022126701 A DE102022126701 A DE 102022126701A DE 102022126701 A1 DE102022126701 A1 DE 102022126701A1
Authority
DE
Germany
Prior art keywords
transform
decoding
type
transform coefficients
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022126701.6A
Other languages
English (en)
Inventor
Tsung-Han Yang
Felix Yohan Christian
Ken Lo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102022126701A1 publication Critical patent/DE102022126701A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/12—Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H04N19/122—Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/48—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using compressed domain processing techniques other than decoding, e.g. modification of transform coefficients, variable length coding [VLC] data or run-length data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/12—Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/18—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a set of transform coefficients
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/184—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being bits, e.g. of the compressed video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Discrete Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Diese Offenbarung beschreibt eine niederfrequente nichttrennbare Transformation und eine Mehrfachtransformationsauswahl-Deadlock-Prävention. Die Systeme und Verfahren können ermöglichen, dass Typen von Transformationen, die auf der Codierungsseite eines Videocodierungs- und -decodierungssystems durchgeführt werden, bestimmt werden, bevor die Transformationsparameter auf der Decodiererseite decodiert werden. Dies kann ermöglichen, dass die inverse Transformation mancher oder aller Transformationseinheiten (TU), die in einem Bitstrom empfangen werden, schneller durchgeführt wird, was die Belastung auf dem Bitstrompuffer reduzieren kann.

Description

  • TECHNISCHES GEBIET
  • Diese Offenbarung betrifft allgemein Systeme, Vorrichtungen und Verfahren zur Videocodierung und insbesondere eine niederfrequente nichttrennbare Transformation und eine Mehrfachtransformationsauswahl-Deadlock-Prävention.
  • HINTERGRUND
  • VVC (Versatile Video Coding) (auch als H.266 bekannt) ist ein Videokomprimierungsstandard, der im Juli 2020 vom Joint Video Experts Team (JVET) fertiggestellt wurde. Der Standard stellt Richtlinien für Videocodierung und -decodierung bereit. Typischerweise kann es auf der Decodierungsseite notwendig sein, einen Typ einer Transformation zu bestimmen, die auf der Codierungsseite verwendet wurde, um eine inverse Transformation beliebiger in einem Bitstrom empfangener Daten durchzuführen. Zwei beispielhafte Typen von Transformationen können LFNST (Low Frequency Non-Separable Transform - niederfrequente nichttrennbare Transformation) und MTS (Multiple Transform Selection - Mehrfachtransformationsauswahl) beinhalten. Um jedoch zu bestimmen, welche Art von Transformation für eine spezielle Transformationseinheit (TU: Transform Unit) verwendet wurde, müssen typischerweise zuerst mehrere Decodierungsstufen durchgeführt werden (Codierungseinheit(CU: Coding Unit)-Decodierung, TU-Decodierung und dann Transformationsparameterdecodierung). Dies kann deshalb problematisch sein, da möglicherweise alle mit einer gegebenen CU assoziierten TUs decodiert werden müssen, bevor der inverse Transformationsprozess für eine der TUs beginnen kann. Dies kann zu einem Engpass in einem Bitstrompuffer führen, der empfangene codierte Videodaten aufnimmt.
  • Figurenliste
  • Die ausführliche Beschreibung ist unter Bezugnahme auf die begleitenden Zeichnungen dargelegt. Die Verwendung der gleichen Bezugsziffern gibt ähnliche oder identische Komponenten oder Elemente an; es können jedoch auch unterschiedliche Bezugsziffern verwendet werden, um Komponenten oder Elemente anzugeben, die ähnlich oder identisch sein können. Verschiedene Ausführungsformen der Offenbarung können andere Elemente und/oder Komponenten als die in den Zeichnungen veranschaulichten nutzen, und manche Elemente und/oder Komponenten sind bei verschiedenen Ausführungsformen möglicherweise nicht vorhanden. Je nach Kontext kann die Singularterminologie, die zum Beschreiben eines Elements oder einer Komponente verwendet wird, eine Vielzahl solcher Elemente oder Komponenten einschließen, und umgekehrt.
    • 1 veranschaulicht ein beispielhaftes System gemäß einer oder mehreren Ausführungsformen der Offenbarung.
    • 2A veranschaulicht ein beispielhaftes Flussdiagramm gemäß einer oder mehreren Ausführungsformen der Offenbarung.
    • 2B veranschaulicht ein beispielhaftes Flussdiagramm gemäß einer oder mehreren Ausführungsformen der Offenbarung.
    • 3A veranschaulicht ein beispielhaftes Flussdiagramm gemäß einer oder mehreren Ausführungsformen der Offenbarung.
    • 3B veranschaulicht ein beispielhaftes Flussdiagramm gemäß einer oder mehreren Ausführungsformen der Offenbarung.
    • 4 veranschaulicht ein beispielhaftes Verfahren gemäß einer oder mehreren Ausführungsformen dieser Offenbarung.
    • 5 veranschaulicht ein Beispiel für ein Rechensystem gemäß einer oder mehreren Ausführungsformen dieser Offenbarung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Diese Offenbarung betrifft eine verbesserte Videocodierungseffizienz und insbesondere das Prädizieren des Vorhandenseins einer niederfrequenten nichttrennbaren Transformation und Mehrfachtransformationsauswahlindizes, um den inversen Transformationsprozess der Videocodierung zu verbessern. Die Prädiktion kann zum Beispiel eine Deadlock verhindern. Insbesondere können die Systeme und Verfahren ermöglichen, dass der inverse Transformationsteil des Decodierungsprozesses in manchen Situationen früher initiiert wird, als er ansonsten initiiert werden könnte, um die Decodierungsleistungsfähigkeit (zum Beispiel Durchsatz und Timing) zu verbessern. Diese erhöhte Leistungsfähigkeit kann im Gegenzug die erforderliche Menge an Pufferraum reduzieren, um die Verarbeitung von Transformationseinheit(TU)-Koeffizienten auf der Decodiererseite zu starten, und kann „Deadlock“-Szenarien in dem Puffer abschwächen oder verhindern. Deadlock kann ein Szenario beinhalten, bei dem ein Videoframe bis zu seiner Decodierung in dem Puffer gehalten wird und gleichzeitig andere Frames empfangen werden. Dies kann zu Situationen führen, bei denen der Puffer voll wird, was Engpässe bei dem Videostrom verursachen kann. Dieser Deadlock kann abgeschwächt oder eliminiert werden, indem inverse Transformationen einiger der TUs, die mit einem gegebenen Videoframe assoziiert sind, durchgeführt werden, ohne eine cabac-Engine (cabac: context-adaptive binary arithmetic coding - kontextadaptive binäre arithmetische Codierung) (Teil des Entropieabschnitts des Komprimierungsprozesses, wie unten beschrieben) zu erfordern, um eine Koeffizientendecodierung für alle für das Frame erzeugten TUs und ohne, dass eine Decodierungssyntax im Anschluss an die TU-Syntax erforderlich ist, abgeschlossen wird. Das heißt, die hierin beschriebenen Systeme und Verfahren erhöhen die Leistungsfähigkeit des Decodierungsprozesses, indem es der cabac-Engine in manchen Situationen ermöglicht wird, beliebige verbleibende TU-Koeffizienten parallel mit dem inversen Transformationsprozess an TUs, die bereits decodiert wurden, zu decodieren.
  • Ein typisches Videocodierungs- und -decodierungssystem kann eine Übertragungsvorrichtung beinhalten, die dazu ausgelegt ist, Quellvideo zu empfangen und Videodaten des Quellvideos zur Übertragung zu einer Empfangsvorrichtung zu komprimieren (z. B. zu codieren). Diese komprimierten Daten können als ein „Bitstrom“ zu der Empfangsvorrichtung übertragen werden. Die Empfangsvorrichtung kann dazu ausgelegt sein, die von der Übertragungsvorrichtung empfangenen komprimierten Videodaten zu decodieren. Beispielsweise kann die Übertragungsvorrichtung eine Quelle von Videoinhalt sein, und die Empfangsvorrichtung kann eine Vorrichtung sein, auf der ein Betrachter den Videoinhalt ansieht (und/oder die Empfangsvorrichtung kann eine dritte Vorrichtung sein, die das Video decodieren und den decodierten Videoinhalt der Vorrichtung bereitstellen kann, auf der der Betrachter den Videoinhalt ansieht). Der Videoinhalt an der Quelle kann komprimiert werden, um Videoqualität und -durchsatz zu maximieren, indem ermöglicht wird, dass ein Videoframe, das eine große Anzahl von Pixeln beinhaltet, in eine kleinere Datenmenge komprimiert wird, um eine schnellere Übertragung und Verarbeitung an der Empfangsvorrichtung bereitzustellen.
  • Auf einer hohen Ebene kann der Codierungsprozess zumindest die folgenden Operationen beinhalten. Zuerst kann ein Videoframe in Form einer Anzahl von Pixeln empfangen werden. Das Videoframe kann in verschiedene Codierungsbaumeinheiten (CTUs: Coding Tree Units) aufgeteilt sein, wobei eine jeweilige davon in einen oder mehrere Codierungsbaumblöcke (CTBs: Coding Tree Blocks) aufgeteilt sind, und ein jeweiliger CTB in eine oder mehrere Codierungseinheiten (CU: Coding Units) aufgeteilt ist, die Gruppen von Pixeln, die in dem Frame enthalten sind, und/oder Informationen, die mit den Pixeln assoziiert sind, wie Luma- und Chroma-Informationen, beinhalten können. CUs können in ein oder mehrere TUs - Blöcke von Pixeln - aufgeteilt sein. Ein prädizierter Block von Pixeln kann für eine TU erzeugt werden, was Vergleichen der Pixeldaten, die mit dem aktuellen Frame assoziiert sind, mit einem Referenzbild beinhalten kann, das ein zuvor codiertes Frame in dem Videoinhalt repräsentieren kann (z. B. Inter-Codierung), und/oder das zuvor codierte Pixeldaten desselben Frames repräsentieren kann (z. B. Intra-Codierung). Der prädizierte Block kann dann (z. B. an einem Subtrahierer) von dem aktuellen Block mit ursprünglichen Bilddaten subtrahiert werden, und die resultierenden Restpixelwerte (die z. B. die Differenz zwischen dem prädizierten Block und den ursprünglichen Bilddaten repräsentieren) können einer Vorwärtstransformationsstufe bereitgestellt werden, bei der die Restpixeldaten, die in der TU enthalten sind, in eine Domäne von Transformationskoeffizienten umgewandelt werden. Es gibt mehrere Typen von Transformationen, die verwendet werden können, um die Restpixeldaten in eine Domäne von Transformationskoeffizienten umzuwandeln, und einige der Transformationstypen werden hierin erörtert. Im Anschluss an die Anwendung einer Transformation wird die transformierte TU einer Quantisiererstufe bereitgestellt. Die Vorwärtstransformation und die Quantisiererstufen können die geteilten Restdaten zum Beispiel unter Verwendung einer diskreten Kosinustransformation (DCT: Discrete Cosine Transform) in Transformationskoeffizienten transformieren. Unter Verwendung eines Quantisierungsparameters (QP), der durch das System festgelegt wird, verwendet der Transformation-und-Quantisierer dann ein verlustbehaftetes Resampling oder eine verlustbehaftete Quantisierung an den Koeffizienten. Die Frames und Residuen zusammen mit unterstützender oder kontextueller Datenblockgröße und so weiter können durch das Codiergerät entropiecodiert und zu der Empfangsvorrichtung übertragen werden.
  • Die hierin beschriebenen Systeme und Verfahren können auf den VVC(Versatile Video Coding)-Videokomprimierungsstandard anwendbar sein (allerdings können die Systeme und Verfahren auch auf andere Standards anwendbar sein). Der VVC-Standard kann mit einer Anzahl unterschiedlicher Typen von Transformationen assoziiert sein. Diese unterschiedlichen Transformationen können unterschiedliche Mechanismen bereitstellen, durch die die Pixeldaten auf der Codierungsseite des Prozesses (zum Beispiel auf der Vorwärtstransformationsstufe des Prozesses) in eine andere Domäne transformiert werden können. Zwei beispielhafte Optionen solcher Transformationen können unter anderen Optionen LFNST (Low Frequency Non-Separable Transform - niederfrequente nichttrennbare Transformation) und MTS (Multiple Transform Selection - Mehrfachtransformationsauswahl) beinhalten. Das heißt, die LFNST und die MTS können zwei unterschiedliche Typen von Transformationen bereitstellen, die die Frequenzdaten vorgeben können, die resultieren, wenn die anfänglichen Pixeldaten als Teil des Codierungsprozesses transformiert werden. In Abhängigkeit davon, welche Transformation verwendet wird, können sich die resultierenden TU-Restkoeffizienten unterscheiden. Angesichts dessen kann, um die TU-Restkoeffizienten an der Empfangsvorrichtung zurück in die Pixeldomäne (z. B. Farbdomäne) umzuwandeln (z. B. Erzeugen rekonstruierter Restpixelwerte), es notwendig sein, dass die Empfangsvorrichtung weiß, welcher Typ von Transformation verwendet wurde, bevor eine inverse Transformation an den TU-Restkoeffizienten durchgeführt wird, um die rekonstruierten Restpixelwerte zu erzeugen.
  • An der Empfangsvorrichtung können die komprimierten Videoframes so empfangen und decodiert werden, dass der Videoinhalt einem Betrachter präsentiert werden kann. In einigen Fällen kann ein typischer Decodierungsprozess zumindest die folgenden Operationen einschließen. Zuerst kann die Empfangsvorrichtung komprimierte Daten bezüglich eines bestimmten Frames eines Videostroms empfangen. Die komprimierten Daten können in eine oder mehrere CUs decodiert werden. Sobald die CU-Decodierung durchgeführt ist, können die TU-Restkoeffizienten von der (den) decodierten CU(s) decodiert werden. Sobald alle der TU-Restkoeffizienten decodiert sind, können dann jegliche LFNST- und MTS-Daten decodiert werden. Der VVC-Standard stellt eine Technik zum Kommunizieren mit der Empfangsvorrichtung (z. B. Decodiervorrichtung) dafür bereit, ob eine LFNST oder MTS für jeweilige Videoframes eines Bitstroms verwendet wurde. Zum Beispiel können ein oder mehrere Flags (z. B. Indizes) durch den Bitstrom zu dem Decodierer übertragen werden. Ein Flag kann ein Bit beinhalten, das angibt, ob der bestimmte Typ von Transformation verwendet wurde (z. B. vorhanden ist). Falls zum Beispiel LFNST auf der Codiererseite verwendet wurde, dann kann das Flag für LFNST auf einen Wert von „1“ gesetzt werden. Sobald die LFNST- und MTS-Daten decodiert sind, kann dann eine inverse Transformation der empfangenen Videoframedaten durchgeführt werden, um die ursprünglichen Pixelinformationen für das Frame zu erzeugen. Durch das Prädizieren, ob eine LFNST oder MTS verwendet wurde, bevor die Daten tatsächlich decodiert werden, um den LFNST- oder MTS-Index zu identifizieren, kann der inverse Transformationsprozess früher stattfinden, wodurch die Decodierungseffizienz verbessert wird.
  • Typischerweise müssen, um an der Empfangsvorrichtung zu bestimmen, welcher Typ von Transformation durch den Codierungsprozess eingesetzt wurde, alle der TU-Restkoeffizienten (z. B. aller TUs eines Frames) zuerst decodiert werden, dann muss möglicherweise eine zusätzliche Syntax decodiert werden, bevor die inverse Transformation durchgeführt wird (z. B. eine zusätzliche Syntax, die angibt, welche Transformation durch den Codierer verwendet wurde). Nachdem alle der TU-Restkoeffizienten decodiert wurden, können dann zusätzliche Syntaxdaten, die die Transformationsdaten beinhalten, decodiert werden, um zu entschlüsseln, welche(r) Transformationstyp(en) eingesetzt wurde(n). Sobald dies erreicht ist, kann die inverse Transformation an den TU-Restkoeffizienten durchgeführt werden, um die Rohpixeldaten zu erhalten. Dieser Prozess des Wartens, bis alle der TU-Restkoeffizienten decodiert sind, bevor LFNST- und MST-Daten decodiert werden, kann in dem Sinne problematisch sein, dass es einen Engpass bei dem Decodierungsprozess verursachen kann. Ein anderer Nachteil des Wartens auf alle der zu decodierenden TU-Restkoeffizienten kann ein Bitstrompuffer-Deadlock-Szenario beinhalten, bei dem mindestens ein Frame im Puffer gehalten wird, während es decodiert wird, und gleichzeitig andere Frames an dem Puffer empfangen werden. Dies kann zu Situationen führen, in denen der Puffer voll wird.
  • Um diesen Typ von Deadlock in dem Bitstrompuffer abzuschwächen oder zu eliminieren, können die hierin beschriebenen Systeme und Verfahren Prädizieren des Typs der Transformation beinhalten, die auf der Codiererseite eingesetzt wurde, bevor alle der TU-Restkoeffizienten auf der Decodiererseite decodiert werden. Dies kann ermöglichen, dass eine inverse Transformation an einigen der TUs durchgeführt wird, während andere TUs decodiert werden, anstatt zu warten, bis alle der TUs und zusätzliche Syntax decodiert sind, um mit dem Durchführen einer inversen Transformation an einer beliebigen der TUs zu beginnen.
  • In manchen Ausführungsformen kann die Prädiktion auch mehrere Prädiktionsstufen beinhalten, die bei unterschiedlichen Teilen des Decodierungsprozesses durchgeführt werden können. Zum Beispiel kann eine erste Prädiktionsstufe in der CU-Decodierungsstufe stattfinden (z. B. kann die inverse Transformation einer TU vor dem Decodieren der Transformationskoeffizienten aller TUs einer CU beginnen), und eine zweite Prädiktionsstufe kann während der TU-Restkoeffizienten-Decodierungsstufe stattfinden. Das heißt, die erste Prädiktionsstufe kann stattfinden, bevor die Transformationskoeffizienten jeder TU einer CU decodiert werden, und die zweite Prädiktionsstufe kann während und/oder nach dem Decodieren der Transformationskoeffizienten jeder TU einer CU stattfinden. Auf diese Weise ermöglicht die Prädiktion das Bestimmen der Transformationskoeffizienten, die in der inversen Transformation zu verwenden sind, ohne sie decodieren zu müssen. Die Prädiktion an der CU-Decodierungsstufe kann eine frühe Identifikation ermöglichen, welche Transformation verwendet wurde, bevor der TU-Decodierungsprozess beginnt. Falls das System jedoch nicht in der Lage ist, die erforderlichen Bedingungen zum Identifizieren eines Transformationstyps während der CU-Decodierungsstufe zu identifizieren, dann kann die zweite Prädiktionsstufe als ein Backup für die erste Prädiktionsstufe dienen. Das heißt, obwohl die zweite Prädiktionsstufe an der TU-Koeffizienten-Decodierungsstufe stattfindet, stellt die zweite Prädiktionsstufe immer noch Vorteile in dem Sinne bereit, dass der inverse Transformationsprozess für manche der TUs durchgeführt werden kann, bevor alle der TUs decodiert sind. Eine Veranschaulichung dieser mehreren Prädiktionsstufen und wo sie in dem Decodierungsprozess auftreten können, ist in X bereitgestellt.
  • Mit anderen Worten werden die Prädiktionsbedingungen der ersten Stufe einmal pro TU vor dem Start des ersten TU-Prozesses (z. B. Decodierung der TU) an einer aktuellen CU geprüft und werden die Prädiktionsbedingungen der zweiten Stufe während des Prozesses der Decodierung jeder TU innerhalb einer CU geprüft. Unmittelbar nachdem die Bedingungen in der ersten Prädiktionsstufe oder der zweiten Prädiktionsstufe detektiert wurden, wird ein Bypass-Signal an die Inverstransformationseinheit gesendet, um die Verarbeitung mit einem LNFST- und MTS-idx (z. B. Flag) von 0 zu beginnen, wodurch die Wartezeit vor dem Initiieren einer Inverstransformationseinheit für die verbleibenden TU-Koeffizienten eliminiert wird.
  • Bei manchen Ausführungsformen können die erforderlichen Bedingungen zum Bestimmen, dass eine TU einer Transformation unter Verwendung von LFNST während der ersten Prädiktionsstufe unterzogen wurde, Folgendes beinhalten. Erstens ist treeType (BaumTyp) nicht DUAL_TREE_CHROMA (DUAL_BAUM_CHROMA). Zweitens ist IntraMipFlag[x0][y0] WAHR. Drittens ist entweder lfnstWidth (,lfnstBreite') oder lfnstHeight (,lfnstHöhe') kleiner als 16. In einigen Fällen müssen möglicherweise mehrere oder alle Bedingungen erfüllt werden, um diese Bestimmung vorzunehmen. Manche oder alle der Bedingungen müssen möglicherweise erfüllt werden, um zu bestimmen, dass eine TU einer Transformation unter Verwendung von LFNST und MTS (oder keines der beiden) unterzogen wurde. In einigen Fällen müssen möglicherweise alle Bedingungen erfüllt werden. Das heißt, falls eine der Bedingungen erfüllt ist, aber nicht eine zweite Bedingung, dann gibt es möglicherweise keine ausreichenden Informationen, um zu bestimmen, ob LFNST oder MTS verwendet wurde. Die Variablen für diese Bedingungen werden durch den VVC-Codierungsstandard definiert und werden hierin weiter beschrieben.
  • Bei manchen Ausführungsformen können die erforderlichen Bedingungen zum Bestimmen, dass eine TU einer Transformation unter Verwendung von MTS während der ersten Prädiktionsstufe unterzogen wurde, Folgendes beinhalten. Bei einigen Ausführungsformen können die Bedingungen zum Bestimmen, dass eine MTS-Transformation verwendet wurde, einen Teil oder alles des Folgenden beinhalten. Zuerst ist treeType (,BaumTyp') DUAL_TREE_CHROMA (,DUAL_BAUM_CHROMA'). Zweitens ist entweder cbWidth (,cbBreite`) oder cbHeight (,cbHöhe') größer als 32. Drittens ist IntraSubPartitionsSplitType (,IntraTeilPartitionenAufteilTyp') nicht ISP_NO_SPLIT („ISP_KEINE_AUFTEILUNG“). Viertens ist cu_sbt_flag WAHR. Hinsichtlich der oben erwähnten Variablen spezifiziert cu_sbt_flag gleich 1, dass für die aktuelle Codierungseinheit eine Unterblocktransformation verwendet wird. cu_sbt_flag gleich 0 spezifiziert, dass für die aktuelle Codierungseinheit keine Unterblocktransformation verwendet wird. Manche oder alle der Bedingungen müssen möglicherweise erfüllt werden, um zu bestimmen, dass eine TU einer Transformation unter Verwendung von LFNST und MTS (oder keines der beiden) unterzogen wurde. In einigen Fällen müssen möglicherweise alle Bedingungen erfüllt werden. Das heißt, falls eine der Bedingungen erfüllt ist, aber nicht eine zweite Bedingung, dann gibt es möglicherweise keine ausreichenden Informationen, um zu bestimmen, ob LFNST oder MTS verwendet wurde. Die Variablen für diese Bedingungen werden durch den VVC-Codierungsstandard definiert und werden hierin weiter beschrieben.
  • Bei manchen Ausführungsformen können die erforderlichen Bedingungen zum Bestimmen, dass eine TU einer Transformation unter Verwendung von LFNST und MTS (oder keines der beiden) während der zweiten Prädiktionsstufe unterzogen wurde, zumindest das Folgende beinhalten. Erstens kann LFNST nur im Nur-Intra-Modus angewendet werden. Zweitens muss die Größe des Codierungsblocks (CB) kleiner oder gleich 64x64 sein. Drittens muss es eine maximale Anzahl von sechs TUs geben (zum Beispiel vier Luma und zwei Chroma), und jede TU muss weniger als oder gleich 16 Koeffizienten aufweisen. Schließlich muss ein erstes Flag der TU („tu_coded_flag“ („TU_codiert-Flag“)) auf einen Wert von „1“ gesetzt werden und ein zweites Flag der TU („transform_skip_flag“ („Transformation-Überspringen-Flag“)) muss auf einen Wert von „0“ gesetzt werden. Falls alle diese Bedingungen erfüllt sind, dann kann bestimmt werden, dass LFNST für die zu decodierende TU verwendet wurde. Manche oder alle der Bedingungen müssen möglicherweise erfüllt werden, um zu bestimmen, dass eine TU einer Transformation unter Verwendung von LFNST und MTS (oder keines der beiden) unterzogen wurde. In einigen Fällen müssen möglicherweise alle Bedingungen erfüllt werden. Das heißt, falls eine der Bedingungen erfüllt ist, aber nicht eine zweite Bedingung, dann gibt es möglicherweise keine ausreichenden Informationen, um zu bestimmen, ob LFNST oder MTS verwendet wurde. Gleichermaßen müssen die folgenden Bedingungen möglicherweise erfüllt werden, um zu bestimmen, dass MTS verwendet wurde. Erstens muss die CB-Größe kleiner oder gleich 32x32 sein. Zweitens müssen höchstens drei TUs (eine Luma und zwei Chroma) vorhanden sein. Drittens kann es höchstens 16x16-Koeffizienten pro TU mit einem Maximum von insgesamt 768 Koeffizienten geben. Die Variablen für diese Bedingungen werden durch den VVC-Codierungsstandard definiert und werden hierin weiter beschrieben.
  • Zusätzliche Einzelheiten über beliebige der Bedingungen, die an der ersten und/oder zweiten Prädiktionsstufe beteiligt sind, können mit zusätzlichen Einzelheiten mit Bezug auf 3B beschrieben sein.
  • 1 ist ein beispielhaftes System 100, das Komponenten von Codierungs- und Decodierungsvorrichtungen veranschaulicht, gemäß einigen beispielhaften Ausführungsformen der vorliegenden Offenbarung.
  • Bezugnehmend auf 1 kann das System 100 Vorrichtungen 102 mit Codierer- und/oder Decodiererkomponenten beinhalten. Wie gezeigt, können die Vorrichtungen 102 eine Inhaltsquelle 103 beinhalten, die Video- und/oder Audioinhalt bereitstellt (z. B. eine Kamera oder eine andere Bildaufnahmevorrichtung, gespeicherte(s) Bilder/Video usw.). Die Inhaltsquelle 103 kann einem Partitionierer 104 Medien (z. B. Video und/oder Audio) bereitstellen, der Frames des Inhalts zur Codierung vorbereiten kann. Ein Subtrahierer 106 kann einen Restwert erzeugen, wie hierin weiter erläutert. Ein Transformation-und-Quantisierer 108 kann Transformationseinheiten erzeugen und quantisieren, um eine Codierung durch ein Codiergerät 110 (z. B. Entropiecodiergerät) zu ermöglichen. Transformationen und quantisierte Daten können durch einen Invers-Transformation-und-Quantisierer 112 invers transformiert und invers quantisiert werden. Ein Addierer 114 kann die invers transformierten und invers quantisierten Daten mit einem Prädiktionsblock vergleichen, der durch eine Prädiktionseinheit 116 erzeugt wird, was zu rekonstruierten Frames führt. Ein Filter 118 (z. B. ein In-Loop-Filter) kann die rekonstruierten Frames von dem Addierer 114 überarbeiten und kann die rekonstruierten Frames in einem Bildpuffer 120 zur Verwendung durch die Prädiktionseinheit 116 speichern. Eine Steuerung 121 kann viele Codierungsaspekte (z. B. Parameter) verwalten, einschließlich zumindest des Einstellens eines Quantisierungsparameters (QP), könnte aber auch Einstellen von Bitrate, Ratenverzerrung oder Szenencharakteristiken, Prädiktions- und/oder Transformationspartition oder Blockgrößen, verfügbarer Prädiktionsmodustypen, und beste Modusauswahlparameter, zum Beispiel zumindest teilweise basierend auf Daten von der Prädiktionseinheit 116, beinhalten. Unter Verwendung der Codierungsaspekte kann der Transformation-und-Quantisierer 108 Transformationseinheiten erzeugen und quantisieren, um eine Codierung durch das Codiergerät 110 zu ermöglichen, der codierte Daten 122 erzeugen kann, die übertragen werden können (z. B. ein codierter Bitstrom).
  • Immer noch unter Bezugnahme auf 1 können die Vorrichtungen 102 codierte Daten (z. B. die codierten Daten 122) in einem Bitstrom empfangen, und ein Decodierer 130 kann die codierten Daten decodieren, wodurch quantisierte Restkoeffizienten und Kontextdaten extrahiert werden. Ein Invers-Transformation-und-Quantisierer 132 kann Pixeldaten basierend auf den quantisierten Restkoeffizienten und Kontextdaten rekonstruieren. Ein Addierer 134 kann die Restpixeldaten zu einem prädizierten Block hinzufügen, der durch eine Prädiktionseinheit 136 erzeugt wird. Ein Filter 138 kann die resultierenden Daten von dem Addierer 134 filtern. Die gefilterten Daten können durch eine Medienausgabe 140 ausgegeben werden und können auch als rekonstruierte Frames in einem Bildpuffer 142 zur Verwendung durch die Prädiktionseinheit 136 gespeichert werden.
  • Bezugnehmend auf 1 führt das System 100 die hierin offenbarten Verfahren zur Intra-Prädiktion durch und ist dazu eingerichtet, mindestens eine oder mehrere der hierin beschriebenen Implementierungen durchzuführen, einschließlich Intra-Block-Kopieren. Bei verschiedenen Implementierungen kann das System 100 zum Durchführen von Videocodierung und/oder Implementieren von Video-Codecs gemäß einem oder mehreren Standards ausgelegt sein. Ferner kann in verschiedenen Formen das Videocodierungssystem 100 als Teil eines Bildprozessors, Videoprozessors und/oder Medienprozessors implementiert werden und führt eine Inter-Prädiktion, Intra-Prädiktion, prädiktive Codierung und Residuen-Prädiktion durch. Bei verschiedenen Implementierungen kann das System 100 eine Videokomprimierung und -dekomprimierung durchführen und/oder Video-Codecs gemäß einem oder mehreren Standards oder Spezifikationen implementieren, wie etwa beispielsweise H.264 (Advanced Video Coding oder AVC), VP8, H.265 (High Efficiency Video Coding oder HEVC) und SCC-Erweiterungen davon, VP9, Alliance Open Media Version 1 (AV1), H.266 (Versatile Video Coding oder VVC), DASH (Dynamic Adaptive Streaming over HTTP) und andere. Obwohl das System 100 und/oder andere Systeme, Schemen oder Prozesse hierin beschrieben sein können, ist die vorliegende Offenbarung nicht notwendigerweise immer auf irgendeinen bestimmten Videocodierungsstandard oder irgendeine bestimmte Videocodierungsspezifikation oder Erweiterungen davon beschränkt, außer für IBC-Prädiktionsmodusoperationen, wo sie hierin erwähnt werden.
  • Der Begriff „Codiergerät“, wie er hierin verwendet wird, kann sich auf einen Codierer und/oder einen Decodierer beziehen. Ähnlich kann sich der Begriff „Codierung“, wie er hierin verwendet wird, auf eine Codierung über einen Codierer und/oder eine Decodierung über einen Decodierer beziehen. Ein Codiergerät, Codierer oder Decodierer kann Komponenten sowohl eines Codierers als auch eines Decodierers aufweisen. Ein Codierer kann eine Decodiererschleife aufweisen, wie unten beschrieben.
  • Beispielsweise kann das System 100 ein Codierer sein, wo aktuelle Videoinformationen in Form von Daten bezüglich einer Sequenz von Videoframes zur Komprimierung erhalten werden können. In einer Form wird eine Videosequenz (z. B. von der Inhaltsquelle 103) aus Eingangsframes von synthetischem Bildschirminhalt gebildet, wie etwa von oder für Unternehmensanwendungen, wie etwa Textverarbeitungsprogramme, Powerpoints oder Tabellenkalkulationen, Computer, Videospiele, Virtuelle-Realität-Bilder und so weiter. In anderen Formen können die Bilder aus einer Kombination von synthetischem Bildschirminhalt und natürlichen, mit einer Kamera aufgenommenen Bildern gebildet sein. In noch einer anderen Form kann nur die Videosequenz ein natürliches, mit einer Kamera aufgenommenes Video sein. Der Partitionierer 104 kann jedes Frame in kleinere, leichter zu handhabende Einheiten partitionieren und dann die Frames vergleichen, um eine Prädiktion zu berechnen. Falls eine Differenz oder ein Residuum zwischen einem ursprünglichen Block und einer Prädiktion bestimmt wird, wird dieses resultierende Residuum transformiert und quantisiert und dann entropiecodiert und in einem Bitstrom zusammen mit rekonstruierten Frames zu Decodierern oder einer Speicherung übertragen. Um diese Operationen durchzuführen, kann das System 100 einen Eingangsframe von der Inhaltsquelle 103 empfangen. Die Eingangsframes können Frames sein, die zur Codierung ausreichend vorverarbeitet sind.
  • Das System 100 kann auch viele Codierungsaspekte verwalten, einschließlich zumindest des Einstellens eines Quantisierungsparameters (QP), könnte aber auch Einstellen von Bitrate, Ratenverzerrung oder Szenencharakteristiken, Prädiktions- und/oder Transformationspartition oder Blockgrößen, verfügbarer Prädiktionsmodustypen, und beste Modusauswahlparameter, um einige wenige Beispiele zu nennen, beinhalten.
  • Die Ausgabe des Transformation-und-Quantisierers 108 kann dem Invers-Transformation-und-Quantisierer 112 bereitgestellt werden, um die gleichen Referenz- oder rekonstruierten Blöcke, Frames oder anderen Einheiten zu erzeugen, wie sie bei einem Decodierer, wie etwa dem Decodierer 130, erzeugt würden. Somit kann die Prädiktionseinheit 116 den Invers-Transformation-und-Quantisierer 112, den Addierer 114 und das Filter 118 verwenden, um die Frames zu rekonstruieren.
  • Die Prädiktionseinheit 116 kann eine Inter-Prädiktion einschließlich Bewegungsschätzung und Bewegungskompensation, eine Intra-Prädiktion gemäß der Beschreibung hierin und/oder eine kombinierte Inter-Intra-Prädiktion durchführen. Die Prädiktionseinheit 116 kann den besten Prädiktionsmodus (einschließlich Intra-Modi) für einen speziellen Block auswählen, typischerweise basierend auf Bitkosten und anderen Faktoren. Die Prädiktionseinheit 116 kann einen Intra-Prädiktions- und/oder Inter-Prädiktionsmodus auswählen, wenn mehrere solche Modi von jedem verfügbar sein können. Die Prädiktionsausgabe der Prädiktionseinheit 116 in Form eines Prädiktionsblocks kann sowohl dem Subtrahierer 106 bereitgestellt werden, um ein Residuum zu erzeugen, als auch in der Decodierungsschleife dem Addierer 114 bereitgestellt werden, um die Prädiktion zu dem rekonstruierten Residuum von der inversen Transformation hinzuzufügen, um ein Frame zu rekonstruieren.
  • Der Partitionierer 104 oder andere nicht gezeigte anfängliche Einheiten können Frames platzieren, um die Frames zu codieren und ihnen Klassifizierungen zuzuweisen, wie etwa I-Frame, B-Frame, P-Frame und so weiter, wobei I-Frames intra-prädiziert werden. Andernfalls können Frames in Slices (wie etwa ein I-Slice) unterteilt werden, wobei jedes Slice unterschiedlich prädiziert werden kann. Somit wird für HEVC- oder AV1-Codierung eines gesamten I-Frames oder I-Slice eine räumliche oder Intra-Prädiktion verwendet, und in einer Form nur von Daten in dem Frame selbst.
  • Bei verschiedenen Implementierungen kann die Prädiktionseinheit 116 einen Intra-Block-Kopie(IBC)-Prädiktionsmodus durchführen, und ein Nicht-IBC-Modus betreibt einen beliebigen anderen verfügbaren Intra-Prädiktionsmodus, wie etwa einen Horizontal-, Diagonal- oder Direktcodierungs(DC)-Prädiktionsmodus, einen Palettenmodus, Richtungs- oder Winkelmodi und einen beliebigen anderen verfügbaren Intra-Prädiktionsmodus. Andere Videocodierungsstandards, wie etwa HEVC oder VP9, können unterschiedliche Unterblockdimensionen aufweisen, können aber immer noch die hierin offenbarte IBC-Suche verwenden. Es ist jedoch anzumerken, dass das Vorstehende nur beispielhafte Partitionsgrößen und -formen sind, die vorliegende Offenbarung nicht auf irgendeine bestimmte Partition und Partitionsformen und/oder -größen beschränkt ist, es sei denn, eine solche Grenze wird erwähnt oder der Kontext deutet auf eine solche Grenze hin, wie bei der optionalen maximalen Effizienzgröße, wie erwähnt. Es ist anzumerken, dass mehrere alternative Partitionen als Prädiktionskandidaten für denselben Bildbereich bereitgestellt werden können, wie unten beschrieben.
  • Die Prädiktionseinheit 116 kann zuvor decodierte Referenzblöcke auswählen. Dann können Vergleiche durchgeführt werden, um zu bestimmen, ob irgendeiner der Referenzblöcke mit einem aktuellen Block übereinstimmt, der rekonstruiert wird. Dies kann Hash-Matching, SAD-Suche oder einen anderen Vergleich von Bilddaten und so weiter beinhalten. Sobald eine Übereinstimmung mit einem Referenzblock gefunden wird, kann die Prädiktionseinheit 116 die Bilddaten des einen oder der mehreren übereinstimmenden Referenzblöcke verwenden, um einen Prädiktionsmodus auszuwählen. In einer Form werden zuvor rekonstruierte Bilddaten des Referenzblocks als die Prädiktion bereitgestellt, alternativ könnten jedoch die ursprünglichen Pixelbilddaten des Referenzblocks stattdessen als die Prädiktion bereitgestellt werden. Jede Wahl kann unabhängig vom Typ der Bilddaten, die zum Abgleichen der Blöcke verwendet wurden, verwendet werden.
  • Der prädizierte Block kann dann bei dem Subtrahierer 106 von dem aktuellen Block der ursprünglichen Bilddaten subtrahiert werden, und das resultierende Residuum kann in einen oder mehrere Transformationsblöcke (TUs) partitioniert werden, sodass der Transformation-und-Quantisierer 108 zum Beispiel die aufgeteilten Restdaten unter Verwendung einer diskreten Kosinustransformation (DCT: Discrete Cosine Transform) in Transformationskoeffizienten transformieren kann. Unter Verwendung des Quantisierungsparameters (QP), der durch das System 100 festgelegt wird, verwendet der Transformation-und-Quantisierer 108 dann ein verlustbehaftetes Resampling oder eine verlustbehaftete Quantisierung an den Koeffizienten. Die Frames und Residuen zusammen mit unterstützender oder Kontextdatenblockgröße und Intra-Verschiebungsvektoren und so weiter können durch das Codiergerät 110 entropiecodiert und zu Decodierern übertragen werden.
  • In einer oder mehreren Ausführungsformen kann ein System 100 ein Decodierer sein oder diesen aufweisen, und kann codierte Videodaten in Form eines Bitstroms empfangen, die die Bilddaten (Chroma- und Luma-Pixelwerte) sowie Kontextdaten einschließlich Residuen in Form quantisierter Transformationskoeffizienten und die Identität von Referenzblöcken, einschließlich zum Beispiel zumindest der Größe der Referenzblöcke, aufweisen. Der Kontext kann auch Prädiktionsmodi für einzelne Blöcke, andere Partitionen, wie etwa Slices, Inter-Prädiktion-Bewegungsvektoren, Partitionen, Quantisierungsparameter, Filterinformationen und so weiter beinhalten. Das System 100 kann den Bitstrom mit einem Entropiedecodierer 130 verarbeiten, um die quantisierten Restkoeffizienten sowie die Kontextdaten zu extrahieren. Das System 100 kann dann den Invers-Transformation-und-Quantisierer 132 verwenden, um die Restpixeldaten zu rekonstruieren.
  • Das System 100 kann dann einen Addierer 134 (zusammen mit nicht gezeigten Assemblern) verwenden, um das Residuum zu einem prädizierten Block hinzuzufügen. Das System 100 kann auch die resultierenden Daten unter Verwendung einer Decodierungstechnik decodieren, die in Abhängigkeit von dem Codierungsmodus, der in der Syntax des Bitstroms angegeben ist, und entweder eines ersten Pfads, der eine Prädiktionseinheit 136 beinhaltet, oder eines zweiten Pfads, der ein Filter 138 beinhaltet, eingesetzt wird. Die Prädiktionseinheit 136 führt eine Intra-Prädiktion durch, indem Referenzblockgrößen und die Intra-Verschiebungs- oder Bewegungsvektoren verwendet werden, die aus dem Bitstrom extrahiert und zuvor bei dem Codierer eingerichtet wurden. Die Prädiktionseinheit 136 kann rekonstruierte Frames sowie Inter-Prädiktion-Bewegungsvektoren aus dem Bitstrom zum Rekonstruieren eines prädizierten Blocks verwenden. Die Prädiktionseinheit 136 kann den korrekten Prädiktionsmodus für jeden Block festlegen, wobei der Prädiktionsmodus extrahiert und aus dem komprimierten Bitstrom dekomprimiert werden kann.
  • Bei einer oder mehreren Ausführungsformen können die codierten Daten 122 sowohl Video- als auch Audiodaten beinhalten. Auf diese Weise kann das System 100 sowohl Audio als auch Video codieren und decodieren.
  • 2A-2B veranschaulichen beispielhafte Flussdiagramme gemäß einer oder mehreren Ausführungsformen der Offenbarung. 2A und 2B stellen eine Darstellung hoher Ebene der Vorteile bereit, die durch die hierin beschriebenen Systeme und Verfahren bereitgestellt werden. Insbesondere veranschaulicht 2A einen ersten Ansatz, der auf der Decodiererseite durchgeführt werden kann, und 2B veranschaulicht einen zweiten Ansatz, der auf der Decodiererseite durchgeführt werden kann, wobei der zweite Ansatz für den hierin beschriebenen verbesserten Ansatz repräsentativ sein kann.
  • Beginnend mit 2A kann das Flussdiagramm 200 veranschaulichen, dass, damit eine inverse Transformation (wie zum Beispiel in Operation 202 gezeigt) für eine gegebene CU durchgeführt wird, die CU sowie alle TUs der CU und eine zusätzliche Syntax anschließend an die TU-Daten (z. B. die Transformationskoeffizienten für die TU) möglicherweise decodiert werden müssen, bevor die inverse Transformation für die TUs der CU durchgeführt wird (wie zum Beispiel in Operation 204 gezeigt). Sobald alle TUs decodiert sind, kann dann eine zusätzliche Syntax, wie etwa die Transformationsparameter, die mit diesen TUs assoziiert sind (zum Beispiel lfnst_idx und mts_idx, wie im H.266-Standard definiert), decodiert werden, um zu bestimmen, welche Transformation für einzelne TUs innerhalb der CU verwendet wurde. Sobald bestimmt ist, welche Transformation oder Transformationen für die einzelnen TUs verwendet wurde(n), kann dann die inverse Transformation an den TUs durchgeführt werden. Auf diese Weise kann die Leistungsfähigkeit der inversen Transformation ein Decodieren von CU-Daten, TU-Daten und einer zusätzlichen Syntax erfordern, um die Transformationskoeffizienten und Transformationen zu identifizieren, die im inversen Transformationsprozess zu verwenden sind. Dieser Ansatz kann jedoch Nachteile hinsichtlich „Deadlock“-Szenarien in einem Puffer aufweisen, der die Bitstromdaten enthält, die bei Operation 202 decodiert werden. Deadlock kann ein Szenario in einem Puffer beinhalten, in dem empfangene Videoframes gehalten werden, die nicht schnell genug decodiert werden, um zu ermöglichen, dass mehr eingehende Videoframes eines Bitstroms gespeichert werden. Dies kann zu Situationen führen, bei denen der Puffer voll wird und nicht in der Lage ist, zusätzliche Frames eines Bitstroms zu speichern, was Engpässe bei dem Videostream verursachen kann.
  • Jetzt mit Bezug auf 2B kann das Flussdiagramm 250 einen zweiten Ansatz repräsentieren, bei dem eine inverse Transformation an manchen der TUs einer CU durchgeführt werden kann, bevor die verbleibenden TUs der CU decodiert werden, anstatt darauf zu warten, dass alle TUs der CU plus zusätzliche Syntax decodiert werden (das heißt, bevor die Werte von lfnst_idx und mts_idx bestimmt werden), bevor die inverse Transformation durchgeführt wird. Das heißt, es kann möglich sein, den Typ der Transformation zu prädizieren, der auf der Codiererseite für eine gegebene CU oder TUs, die in der CU enthalten sind, verwendet wurde, ohne alle TUs einer CU plus die zusätzliche Syntax auf der Decodiererseite vollständig decodieren zu müssen (in der Figur dargestellt). In manchen Fällen kann die Prädiktion durchgeführt werden, nachdem eine CU-Decodierung durchgeführt wurde, bevor irgendwelche einzelnen TUs innerhalb der CU decodiert werden (die „erste Prädiktionsstufe“, wie hierin beschrieben). Selbst wenn den CU-Daten in der ersten Prädiktionsstufe jedoch ausreichend Daten fehlen, um den Typ der Transformation zu prädizieren, können Prädiktionen auch durchgeführt werden, während jede einzelne TU decodiert wird (die „zweite Prädiktionsstufe“), wie in 2B veranschaulicht. Auf diese Weise können sowohl die erste als auch die zweite Prädiktionsstufe die Notwendigkeit vermeiden, Syntax im Anschluss an die TUs zu decodieren, und können die Notwendigkeit vermeiden, die Syntax aller TUs zu decodieren. Falls zum Beispiel eine CU drei TUs umfasst, dann kann es möglich sein, dass der Typ der Transformation für die erste TU nach dem Decodieren dieser ersten TU, vor dem Decodieren der zweiten und dritten TU und vor dem Decodieren der anschließenden Syntax nach der TU-Syntax prädiziert wird. In diesem Fall kann die TU zu der inversen Transformation übergehen (Operation 256), bevor die anderen beiden TUs decodiert werden und bevor die zusätzliche Post-TU-Syntax decodiert wird. Dies ermöglicht eine schnellere Verarbeitung von TUs (einige TUs können durch die inverse Transformation fortfahren, während andere decodiert werden). Dieser in 2B veranschaulichte Ansatz ist in zusätzlichen Einzelheiten mit Bezug auf 3B beschrieben.
  • 3A-3B veranschaulichen beispielhafte Flussdiagramme gemäß einer oder mehreren Ausführungsformen der Offenbarung. 3A bis 3B können eine ausführlichere Veranschaulichung des in den 2A und 2B präsentierten Vergleichs bereitstellen.
  • Beginnend mit 3A beginnt das Flussdiagramm 300 mit Operation 302, in der eine Vorrichtung (oder z. B. ein System, wie etwa die Grafikkarte 565 von 5) eine Decodierung auf CU-Ebene empfangener Videodaten durchführen kann (z. B. Decodieren einer CU-Syntax, wie etwa einer LFNST-Breite, einer LFNST-Höhe, eines LFNST-Aktiviert-Flags, eines Intra- oder Inter-Codierungsmodus usw.). Insbesondere kann das codierte Videoframe vor dem Codieren (z. B. unter Verwendung des Partitionierers 104 von 1) in CUs partitioniert worden sein, wobei eine jegliche CU eine Anzahl von TUs beinhaltet. Außerdem geht das Flussdiagramm 300 nach Operation 302 zu Operation 304 über, bei der die Vorrichtung jegliche TUs der decodierten CU decodieren kann. Die TUs können für den Codierer durch Anwenden einer zu codierenden Transformationseinheit (z. B. einer Matrix von Restkoeffizienten) erzeugt werden. Der Decodierungsprozess kann Decodieren der codierten Daten (z. B. Codieren von Blockgröße, Anzahl von Transformationskoeffizienten, ein Transformation-Überspringen-Flag usw.) und Extrahieren quantisierter Restkoeffizienten und Kontextdaten beinhalten (beispielsweise ähnlich dem in 1 veranschaulichten Decodierer 130). Das heißt, auf der Codiererseite kann ein Entropiecodiergerät (zum Beispiel ähnlich dem Codiergerät 110) codierte Daten erzeugen, die übertragen werden können (z. B. ein codierter Bitstrom). Die Daten können auf der Codiererseite codiert werden, um die Daten zur Übertragung zu komprimieren, um die Datenmenge zu minimieren, die durch den Bitstrom übertragen wird. Angesichts dessen müssen die Daten dann decodiert werden, sobald die Daten aus dem Bitstrom empfangen werden.
  • Nach Operation 304 geht das Flussdiagramm 300 zu Operation 306 über, bei der die Vorrichtung Transformationsparameter für die decodierten TUs decodieren kann (z. B. zusätzliche Syntax im Anschluss an die Syntax auf TU-Ebene von Operation 304), wobei die Transformationsparameter Angaben darüber beinhalten, ob LFNST- oder MTS-Transformationen für jeweilige TUs verwendet wurden. Auf diese Weise können alle der TUs bei Operation 304 vor dem Decodieren der Transformationsparameter bei Operation 306 decodiert werden. Dieser Decodierungsprozess kann Decodieren von Daten beinhalten, die eine Angabe eines Transformationstyps bereitstellen können, der auf der Codiererseite des Systems verwendet wurde. Wie hierin erwähnt, setzt der VVC-Standard (H.266 oder andere) beispielsweise mehrere unterschiedliche Typen von Transformationen ein, die eingesetzt werden können. Jeder unterschiedliche Typ von Transformation kann unterschiedliche resultierende Daten erzeugen, daher ist es für die Decodiererseite wichtig, zu wissen, welche Transformation verwendet wurde, um die inverse Transformation durchzuführen, um die ursprünglichen Daten zu erzeugen. Beispiele für solche Typen von Transformationen beinhalten unter anderem LFNST und MTS. Sobald diese Daten decodiert sind, kann das System dann eine Kenntnis darüber erhalten, welche Transformation für eine gegebene TU verwendet wurde, und kann dann in der Lage sein, eine inverse Transformation an dieser TU durchzuführen. Einzelne TUs können unter Verwendung unterschiedlicher Typen von Transformationen auf der Codiererseite transformiert worden sein, sodass es nicht notwendigerweise ausreicht, nur Transformationsparameter für eine einzelne TU zu decodieren, um den Typ der Transformation zu bestimmen, der für die anderen TUs verwendet wurde. Insbesondere definiert der H.266-Standard die Variablen lfnst_idx und mts_idx. Diese Variablen, die auf bestimmte Werte festgelegt werden, können schlussendlich angeben, welcher Typ von Transformation verwendet wurde (falls entweder LFNST oder MTS verwendet wurde).
  • Nach Operation 306 geht das Flussdiagramm 300 zu Operation 308 über, bei der die Vorrichtung die inverse Transformation für alle decodierten TUs durchführt (z. B. Anwenden der Transformation und der Restkoeffizienten auf die decodierten Daten). Wie durch dieses Flussdiagramm 300 veranschaulicht, kann dieser Ansatz in dem Sinne den Nachteil haben, dass alle mit einer CU (oder mehreren CUs) assoziierten TUs und die zusätzliche TU-Transformationsparametersyntax decodiert werden müssen, bevor die lfnst_idx- und mts_idx-Werte bestimmt werden können, da die inverse Transformation nicht abgeschlossen werden kann, ohne die Koeffizienten und die anzuwendenden Transformationen zu identifizieren. Dies kann zu einem Engpass im Bitstrompuffer führen, da der gesamte CU- und TU-Decodierungsprozess für einen gegebenen Datensatz abgeschlossen werden muss, bevor eine inverse Transformation an den Daten durchgeführt werden kann und zusätzliche Daten im Puffer den Decodierungsprozess beginnen können. Der in 3B veranschaulichte Ansatz löst einige dieser Probleme mit dem in 3A genommenen Ansatz und ist nachstehend ausführlicher beschrieben.
  • Jetzt mit Bezug auf 3B beginnt das Flussdiagramm 350 mit Operation 352, bei der eine Vorrichtung (z. B. die Grafikkarte 565 von 5) den gleichen oder einen ähnlichen CU-Decodierungsprozess durchführen kann, der mit Bezug auf Operation 302 von 3A beschrieben ist. Nach Operation 352 geht das Flussdiagramm 350 zu Bedingung 354 über. Die Bedingung 354 kann die erste Prädiktionsstufe, wie hierin beschrieben, beinhalten. Das heißt, in manchen Fällen kann es für die Vorrichtung möglich sein, einen Typ einer Transformation zu prädizieren, der für ein oder mehrere in einer decodierten CU enthaltene TUs verwendet wurde, ohne die TUs innerhalb der CU decodieren zu müssen.
  • In einigen Ausführungsformen müssen, um einen Typ einer Transformation zu prädizieren, der für eine oder mehrere in einer decodierten CU enthaltene TUs verwendet wird, ohne alle TUs decodieren zu müssen, und dann die Transformationsparametersyntax decodieren zu müssen, möglicherweise eine oder mehrere Bedingungen basierend auf den decodierten CU-Daten erfüllt werden. Die Bedingungen können sich basierend auf dem Typ der Transformation unterscheiden. Das heißt, die Bedingungen für LFNST können sich von den Bedingungen für MTS unterscheiden, die sich von den Bedingungen für einen beliebigen anderen Typ von Transformation unterscheiden können. Zum Beispiel muss LFNST möglicherweise einige oder alle der folgenden allgemeinen Anforderungen erfüllen. Erstens kann LFNST nur verwendet werden, wenn der Intra-Prädiktions-Modus (anstatt Inter-Prädiktions-Modus) durch den Codierer verwendet wird. Zweitens muss eine CU-Größe kleiner oder gleich 64x64 sein. Drittens kann eine CU höchstens sechs Transformationseinheiten (zum Beispiel vier Luma und zwei Chroma) aufweisen. Viertens muss jede Transformationseinheit weniger oder gleich 16 Koeffizienten aufweisen. Das heißt, eine CU kann höchstens 96 Koeffizienten speichern. Gleichermaßen kann allgemein prädiziert werden, dass MTS verwendet wurde, da MTS möglicherweise einige oder alle der folgenden allgemeinen Anforderungen erfüllen muss. Nur Luma. Im Intra-Teilpartitionen(ISP)-Codierungsmodus nicht gültig. MTS kann im unterblockbasierten zeitlichen Modus (SBT) aktiviert sein. Viertens muss eine CU-Größe kleiner oder gleich 32x32 sein. Fünftens kann eine CU höchstens drei Transformationseinheiten (zum Beispiel eine Luma und zwei Chroma) aufweisen. Sechstens kann jede TU höchstens 16x16 Koeffizienten aufweisen. Das heißt, eine CU kann höchstens 768 Koeffizienten speichern. Spezifischere Einzelheiten darüber, wie solche Bedingungen eingesetzt werden können, um die Verwendung von LFNST und MTS zu prädizieren, sind unten beschrieben. Einige oder alle der unten erwähnten Variablen können in dem H.266-Standard definiert sein, der von der International Telecommunication Union (ITU) produziert wird.
  • Bei einigen Ausführungsformen können die Bedingungen zum Bestimmen, dass eine LFNST-Transformation verwendet wurde, eines oder mehrere des Folgenden beinhalten. Erstens ist treeType (der z. B. spezifiziert, ob ein einzelner oder dualer Baum verwendet wird, um einen Codierungsbaumknoten zu partitionieren) nicht DUAL_TREE_CHROMA (,DUAL_BAUM_CHROMA'). Zweitens ist IntraMipFlag[x0][y0] (z. B. ein Flag, das angibt, ob eine Matrix-Intra-Prädiktions-basierte Bildcodierung verwendet wird) WAHR. Drittens ist entweder lfnstWidth oder lfnstHeight (z. B. die Breite oder Höhe der LFNST-Transformation) kleiner als 16. In einigen Fällen müssen möglicherweise mehrere oder alle Bedingungen erfüllt werden, um diese Bestimmung vorzunehmen.
  • Falls manche oder alle der folgenden Bedingungen erfüllt sind, ist es gleichermaßen möglicherweise nicht möglich, in der ersten Prädiktionsstufe zu bestimmen, ob LFNST verwendet wurde. In solchen Fällen kann auch die unten beschriebene zweite Prädiktionsstufe verwendet werden, um zu versuchen, den Typ der Transformation zu bestimmen. Erstens ist ein Wert von entweder lfnstWidth oder lfnstHeight kleiner als vier (Einzelheiten darüber, wie lfnstWidth und lfnstHeight zu bestimmen sind, sind unten bereitgestellt). Zweitens ist sps_lfnst_enabled_flag (,sps_lfnst_aktiviert_Flag') FALSCH (z. B. ein Flag, das angibt, ob die LFNST_idx vorhanden sein kann, und das Flag kann in Intra-Codierungseinheitssyntax identifiziert werden). Drittens ist CuPredMode[chType][x0][y0] nicht MODE_INTRA (z. B. kein Intra-Codierungsmodus). Schließlich ist entweder lfnstWidth oder lfnstHeight größer als MaxTbSizeY. In einigen Fällen müssen möglicherweise mehrere oder alle Bedingungen erfüllt werden, um diese Bestimmung vorzunehmen. Hinsichtlich der oben erwähnten Variablen kann sps_lfnst_enabled_flag ein Flag sein, das ein Bit beinhaltet. Das Bit gleich 1 spezifiziert, dass lfnst_idx in der Intra-Codierungseinheitssyntax vorhanden sein könnte, sps_lfnst_enabled_flag gleich 0 spezifiziert, dass lfnst_idx nicht in der Intra-Codierungseinheitssyntax vorhanden ist. MODE_INTRA gibt an, ob Intra- oder Inter-Prädiktion verwendet wurde. Wie zuvor erwähnt, können diese und andere hierin beschriebene Variablen auch in dem H.266-Standard (oder anderen VVC-Standards) definiert sein.
  • Der Parameter lfnstWidth kann basierend auf Folgendem abgeleitet werden. Wenn treeType DUAL_TREE_CHROMA ist, ist lfnstWidth gleich cbWidth/SubWidthC gesetzt. Wenn IntraSubPartitionsSplitType gleich ISP_VER_SPLIT ist, ist lfnstWidth gleich cbWidth/NumIntraSubPartitions gesetzt. Andernfalls ist lfnstWidth gleich cbWidth gesetzt. Die Variable treeType kann spezifizieren, ob ein einzelner Baum (SINGLE_TREE) oder ein dualer Baum (DUAL_TREE_CHROMA) verwendet wurde, um einen Codierungsbaumknoten zu partitionieren. cbWidth kann die Breite eines gegebenen Codierungsblocks repräsentieren. SubWidthC hängt von der verwendeten Chroma-Format-Samplingstruktur ab, und ist in H.266 definiert. IntraSubPartitionsSplitType gibt an, ob der Intra-Teilpartitionen-Aufteilungstyp horizontal oder vertikal ist.
  • Zusätzlich kann der Parameter lfnstHeight basierend auf Folgendem abgeleitet werden. Wenn treeType DUAL_TREE_CHROMA ist, wird lfnstheight gleich cbHeight/SubHeightC gesetzt. Wenn IntraSubPartitionsSplitType gleich ISP_HOR_SPLIT ist, wird lfnstHeight gleich cbHeight/NumIntraSubPartitions gesetzt. Andernfalls wird lfnstHeight gleich cbHeight gesetzt.
  • Bei einigen Ausführungsformen können die Bedingungen zum Bestimmen, dass eine MTS-Transformation verwendet wurde, einen Teil oder alles des Folgenden beinhalten. Zuerst ist treeType DUAL_TREE_CHROMA. Zweitens ist entweder cbWidth oder cbHeight größer als 32. Drittens ist IntraSubPartitionsSplitType nicht ISP_NO_SPLIT. Viertens ist cu_sbt_flag WAHR Hinsichtlich der oben erwähnten Variablen spezifiziert cu_sbt_flag gleich 1, dass für die aktuelle Codierungseinheit eine Unterblocktransformation verwendet wird. cu_sbt_flag gleich 0 spezifiziert, dass für die aktuelle Codierungseinheit keine Unterblocktransformation verwendet wird.
  • Nach Bedingung 354 kann das Flussdiagramm 350 in Abhängigkeit davon, ob bestimmt wird, welcher Transformationstyp für die TUs in der CU verwendet wurde, entweder zu Operation 356 oder Operation 362 übergehen. Falls der Typ der Transformation unter Verwendung der decodierten CU-Daten prädiziert wurde, dann kann das Flussdiagramm 350 zu Operation 362 übergehen, und die inverse Transformation kann durch die Vorrichtung für die TUs der CU durchgeführt werden, was zur Erzeugung rekonstruierter Restpixelwerte führt (z. B. erzeugt durch den Transformation-und-Quantisierer 108 von 1). Falls der Typ der Transformation jedoch nicht unter Verwendung der decodierten CU-Daten prädiziert werden kann, kann das Flussdiagramm 350 zu Operation 356 übergehen. Operation 356 kann beinhalten, dass die Vorrichtung einzelne TUs decodiert, die in der CU enthalten sind, die in Operation 352 decodiert wurde. In manchen Ausführungsformen kann die Operation 356 die gleiche wie die in Assoziation mit Operation 304 von 3A durchgeführte TU-Decodierung oder dieser ähnlich sein. Das heißt, falls der Typ der Transformation nicht unter Verwendung von nur decodierten CU-Daten bestimmt werden kann, dann können einzelne TUs den Decodierungsprozess durchlaufen.
  • Nach Operation 356 geht das Flussdiagramm 350 zu Bedingung 358 über. Die Bedingung 358 kann beinhalten, dass die Vorrichtung die zweite Prädiktionsstufe durchführt, wie hierin beschrieben. Das heißt, selbst wenn der Typ der Transformation nach Operation 352 (CU-Decodierung) nicht bestimmbar war, kann es in manchen Fällen immer noch möglich sein, den Typ der Transformation zu bestimmen, die für einzelne TUs verwendet wird. Das heißt, wenn einzelne TUs decodiert werden, kann es möglich sein, den Typ einer Transformation zu prädizieren, die für diese spezielle TU verwendet wird, bevor die verbleibenden TUs decodiert werden. Dies stellt weiterhin einen zusätzlichen Vorteil gegenüber der in 3A beschriebenen Logik bereit, da die inverse Transformation (zum Beispiel Operation 362) dann für einige der TUs durchgeführt werden kann, bevor alle TUs decodiert wurden, anstatt darauf zu warten, dass alle TUs decodiert werden, bevor die Transformationsparameter (zum Beispiel lfnst_idx und mts_idx) vor der inversen Transformation decodiert werden.
  • In manchen Ausführungsformen können die Bedingungen in der zweiten Prädiktionsstufe zum Bestimmen, dass eine LFNST-Transformation verwendet wurde, manche oder alle der Folgenden beinhalten (es kann erforderlich sein, dass manche oder alle dieser Bedingungen erfüllt sind, um zu prädizieren, dass eine LFNST-Transformation für eine gegebene TU verwendet wurde). Erstens wurde möglicherweise nur eine Intra-Prädiktion verwendet. Zweitens kann eine CU höchstens eine Größe von 64x64 aufweisen. Drittens kann eine CU maximal sechs TUs (4 Luma, 2 Chroma), und jede TU mit weniger als oder gleich 16 Koeffizienten, aufweisen. Viertens ist das pro-TU-Komponente codierte Flag tu_coded_flag = 1 und transform_skip_flag = 0 für eine TU. transform_skip_flag[x0][y0][cIdx] spezifiziert, ob eine Transformation auf den assoziierten Transformationsblock angewendet wird oder nicht. Die Arrayindizes x0, y0 spezifizieren den Ort (x0, y0) des linken oberen Luma-Samples des betreffenden Transformationsblocks relativ zu dem linken oberen Luma-Sample des Bildes. Der Arrayindex cIdx spezifiziert einen Indikator für die Farbkomponente; er ist gleich 0 für Y, 1 für Cb und 2 für Cr. transform_skip_flag[x0][y0][cIdx] gleich 1 spezifiziert, dass keine Transformation auf den assoziierten Transformationsblock angewendet wird. transform_skip_flag[x0][y0][cIdx] gleich 0 spezifiziert, dass die Entscheidung, ob eine Transformation auf den assoziierten Transformationsblock angewendet wird oder nicht, von anderen Syntaxelementen abhängt.
  • In manchen Ausführungsformen können die Bedingungen in der zweiten Prädiktionsstufe zum Bestimmen, dass eine MTS-Transformation verwendet wurde, manche oder alle der Folgenden beinhalten (es kann erforderlich sein, dass manche oder alle dieser Bedingungen erfüllt sind, um zu prädizieren, dass eine MTS-Transformation für eine gegebene TU verwendet wurde). Erstens weist eine CU möglicherweise nur eine maximale Größe von 32x32 auf. Zweitens können maximal drei TUs (1 Luma und 2 Chroma) in einer CU enthalten sein. Drittens können höchstens 16x16 Koeffizient pro TU enthalten sein, was im ungünstigsten Fall insgesamt 768 Koeffizienten ergibt.
  • Falls der Transformationstyp für eine spezielle TU unter Verwendung der zweiten Prädiktionsstufe nicht bestimmbar ist, wie in Verbindung mit der Bedingung 358 beschrieben, dann müssen die Transformationsparameter anschließend an die TU-Syntax möglicherweise weiterhin decodiert werden, und das Flussdiagramm 350 kann zu Operation 360 übergehen. Das Ergebnis von Operation 360 kann die Werte von sein, um die Werte von lfnst_idx und mts_idx zu bestimmen, die bestätigen können, ob LFNST oder MTS (oder keines) verwendet wurde. Falls jedoch die zweite Prädiktionsstufe dazu in der Lage ist, einen Transformationstyp für eine gegebene TU zu bestimmen, dann kann das Flussdiagramm 350 (für diese spezielle TU) die Operation 360 umgehen und zu der inversen Transformation bei Operation 362 übergehen. Zu dieser Zeit können die LFNST- und MTS-Decodierung bei Operation 360 durchgeführt werden, und die verbleibenden TUs können dann zu Operation 362 und der inversen Transformation übergehen. Die Fähigkeit, eine inverse Transformation an einigen TUs durchzuführen, bevor alle TUs decodiert wurden, kann auch ferner in 3B (nachstehend beschrieben) veranschaulicht werden.
  • 4 veranschaulicht ein beispielhaftes Verfahren 400 gemäß einer oder mehreren Ausführungsformen dieser Offenbarung. Das Verfahren 400 kann mit Block 402 beginnen, der beinhalten kann, dass eine Vorrichtung (z. B. die Grafikkarte 565 von 5) erste codierte Videodaten eines Bitstroms empfängt. Der Block 404 des Verfahrens 400 kann beinhalten, dass die Vorrichtung eine erste Codierungseinheit (CU) eines ersten Videoframes der ersten codierten Videodaten decodiert, wobei die erste CU eine erste Transformationseinheit (TU) und eine zweite TU umfasst. Dann kann der Block 406 des Verfahrens 400 beinhalten, dass die Vorrichtung basierend auf ersten decodierten Daten, die mit dem Decodieren der ersten CU assoziiert sind, und vor dem Decodieren der ersten TU und der zweiten TU, einen ersten Typ von Transformation bestimmt, der zum Erzeugen jeweiliger Transformationskoeffizienten für die erste TU und die zweite TU verwendet wird. Block 408 des Verfahrens 400 kann beinhalten, dass die Vorrichtung die erste TU decodiert, wobei das Decodieren der ersten TU Identifizieren erster Transformationskoeffizienten umfasst. Block 410 des Verfahrens 400 kann das Decodieren der zweiten TU beinhalten, wobei das Decodieren der zweiten TU Identifizieren zweiter Transformationskoeffizienten umfasst. Block 412 des Verfahrens 400 kann ein Erzeugen, basierend auf dem ersten Typ von Transformation und den ersten Transformationskoeffizienten, erster rekonstruierter Pixelwerte der ersten TU beinhalten. Block 414 des Verfahrens 400 kann ein Erzeugen, basierend auf dem ersten Typ von Transformation und den zweiten Transformationskoeffizienten, zweiter rekonstruierter Pixelwerte der zweiten TU beinhalten.
  • 5 veranschaulicht eine Ausführungsform eines beispielhaften Systems 500 gemäß einer oder mehreren beispielhaften Ausführungsformen der vorliegenden Offenbarung.
  • In verschiedenen Ausführungsformen kann das System 500 eine elektronische Vorrichtung umfassen oder als Teil dieser implementiert sein.
  • In manchen Ausführungsformen kann das System 500 zum Beispiel ein Computersystem repräsentieren, das eine oder mehrere Komponenten von 1 implementiert.
  • Die Ausführungsformen sind in diesem Kontext nicht beschränkt. Allgemeiner ist das System 500 dazu ausgelegt, alle Logik, Systeme, Prozesse, Logikflüsse, Verfahren, Gleichungen, Einrichtungen und Funktionalität zu implementieren, die hierin und unter Bezugnahme auf die Figuren beschrieben sind.
  • Das System 500 kann ein Computersystem mit mehreren Prozessorkernen sein, wie etwa ein verteiltes Rechensystem, ein Supercomputer, ein Hochleistungsrechensystem, ein Rechencluster, ein Mainframe-Computer, ein Minicomputer, ein Client-Server-System, ein Personal Computer (PC), eine Workstation, ein Server, ein portabler Computer, ein Laptop-Computer, ein Tablet-Computer, eine Handheld-Einrichtung, wie etwa ein Personal Digital Assistant (PDA), oder andere Vorrichtungen zum Verarbeiten, Anzeigen oder Übertragen von Informationen. Ähnliche Ausführungsformen können z. B. Unterhaltungsvorrichtungen, wie etwa ein portabler Musikabspieler oder ein portabler Videoabspieler, ein Smartphone oder andere zellulare Telefone, ein Telefon, eine digitale Videokamera, eine digitale Fotokamera, eine externe Speicherungsvorrichtung oder dergleichen, umfassen. Weitere Ausführungsformen implementieren größere Serverkonfigurationen. In anderen Ausführungsformen kann das System 500 einen einzigen Prozessor mit einem Kern oder mehr als einen Prozessor aufweisen. Es ist anzumerken, dass sich der Begriff „Prozessor“ auf einen Prozessor mit einem einzelnen Kern oder ein Prozessorgehäuse mit mehreren Prozessorkernen bezieht.
  • In mindestens einer Ausführungsform repräsentiert das Rechensystem 500 eine oder mehrere Komponenten von 1. Allgemeiner ist das Rechensystem 500 dazu ausgelegt, alle Logik, Systeme, Prozesse, Logikflüsse, Verfahren, Einrichtungen und Funktionalität zu implementieren, die hierin unter Bezugnahme auf die obigen Figuren beschrieben sind.
  • Wie in dieser Anmeldung verwendet, sollen die Begriffe „System“ und „Komponente“ sowie „Modul“ auf eine computerbezogene Entität, entweder Hardware, eine Kombination von Hardware und Software, Software oder Software in Ausführung verweisen, wofür Beispiele von dem beispielhaften System 500 bereitgestellt werden. Eine Komponente kann zum Beispiel, ohne darauf beschränkt zu sein, Folgendes sein: ein Prozess, der auf einem Prozessor ausgeführt wird, ein Prozessor, ein Festplattenlaufwerk, mehrere Speicherungslaufwerke (mit optischem und/oder magnetischem Speicherungsmedium), ein Objekt, eine ausführbare Datei, ein Ausführungs-Thread, ein Programm und/oder ein Computer.
  • Zur Veranschaulichung kann sowohl eine Anwendung, die auf einem Server ausgeführt wird, als auch der Server eine Komponente sein. Eine oder mehrere Komponenten können sich innerhalb eines Prozesses und/oder Ausführungs-Threads befinden, und eine Komponente kann sich auf einem Computer befinden und/oder zwischen zwei oder mehr Computern verteilt sein. Des Weiteren können Komponenten kommunikativ miteinander durch diverse Typen von Kommunikationsmedien zum Koordinieren von Operationen gekoppelt sein. Die Koordination kann den unidirektionalen oder bidirektionalen Austausch von Informationen beinhalten. Die Komponenten können zum Beispiel Informationen in der Form von Signalen kommunizieren, die über Kommunikationsmedien kommuniziert werden. Die Informationen können als Signale, die diversen Signalleitungen zugeordnet sind, implementiert werden. Bei solchen Zuordnungen ist jede Nachricht ein Signal. Weitere Ausführungsformen können jedoch alternativ Datennachrichten einsetzen. Solche Datennachrichten können über diverse Verbindungen gesendet werden. Beispielhafte Verbindungen beinhalten parallele Schnittstellen, serielle Schnittstellen und Busschnittstellen.
  • Wie in dieser Figur gezeigt, umfasst das System 500 ein Hauptplatine 505 zum Montieren von Plattformkomponenten. Die Hauptplatine 505 ist eine Punkt-zu-Punkt(P-P)-Interconnect-Plattform, die einen Prozessor 510, einen Prozessor 530, die über P-P-Interconnects/-Schnittstellen wie etwa ein Ultra Path Interconnect (UPI) gekoppelt sind, und eine Vorrichtung 519 beinhaltet. In anderen Ausführungsformen kann das System 500 eine andere Busarchitektur aufweisen, wie etwa einen Multi-Drop-Bus. Des Weiteren kann jeder der Prozessoren 510 und 530 Prozessorgehäuse mit mehreren Prozessorkernen sein. Als ein Beispiel sind die Prozessoren 510 und 530 so gezeigt, dass sie Prozessorkern(e) 520 bzw. 540 beinhalten. Während das System 500 ein Beispiel für eine Zwei-Sockel-Plattform (2S-Plattform) ist, können andere Ausführungsformen mehr als zwei Sockel oder einen Sockel beinhalten. Zum Beispiel können einige Ausführungsformen eine Vier-Sockel-Plattform (4S-Plattform) oder eine Acht-Sockel-Plattform (8S-Plattform) beinhalten. Jeder Sockel ist eine Halterung für einen Prozessor und kann eine Sockelkennung aufweisen. Es wird angemerkt, dass der Ausdruck Plattform auf die Hauptplatine mit gewissen montierten Komponenten, wie etwa den Prozessoren 510 und dem Chipsatz 560, verweist. Einige Plattformen können zusätzliche Komponenten beinhalten, und einige Plattformen können nur Sockel zum Befestigen der Prozessoren und/oder des Chipsatzes beinhalten.
  • Die Prozessoren 510 und 530 können beliebige verschiedener kommerziell verfügbarer Prozessoren sein, einschließlich, ohne darauf beschränkt zu sein, Intel® Celeron®-, Core®-, Core (2) Duo®-, Itanium®-, Pentium®-, Xeon®- und XScaleü-Prozessoren, AMD® Athlon®-, Duron®- und Opteron®-Prozessoren; ARM®-Anwendungs-, eingebetteter und sicherer Prozessoren; IBM® und Motorola® DragonBall®- und PowerPC®-Prozessoren; IBM und Sony®-Cell-Prozessoren und ähnlicher Prozessoren. Duale Mikroprozessoren, Mehrkernprozessoren und andere Mehrprozessorarchitekturen können auch als die Prozessoren 510 und 530 eingesetzt werden.
  • Der Prozessor 510 beinhaltet eine integrierte Speichersteuerung (IMC: Integrated Memory Controller) 514 und P-P-Interconnects/-Schnittstellen 518 und 552. Gleichermaßen beinhaltet der Prozessor 530 eine IMC 534 und P-P-Interconnects/-Schnittstellen 538 und 554. Die IMCs 514 und 534 koppeln die Prozessoren 510 bzw. 530 mit jeweiligen Speichern, einem Speicher 512 und einem Speicher 532. Die Speicher 512 und 532 können Teile des Hauptspeichers (z. B. eines dynamischen Direktzugriffspeichers (DRAM)) für die Plattform sein, wie etwa Doppeldatenraten-Typ-3(DDR3)- oder -Typ-4(DDR4)-Synchron-DRAM (SDRAM). In der vorliegenden Ausführungsform werden die Speicher 512 und 532 lokal an die jeweiligen Prozessoren 510 und 530 angehängt.
  • Zusätzlich zu den Prozessoren 510 und 530 kann das System 500 eine Vorrichtung 519 beinhalten. Die Vorrichtung 519 kann mittels P-P-Interconnects/-Schnittstellen 529 und 569 mit dem Chipsatz 560 verbunden sein. Die Vorrichtung 519 kann auch mit einem Speicher 539 verbunden sein. In manchen Ausführungsformen kann die Vorrichtung 519 mit mindestens einem der Prozessoren 510 und 530 verbunden sein. In anderen Ausführungsformen können die Speicher 512, 532 und 539 mit dem Prozessor 510 und 530 und der Vorrichtung 519 über einen Bus und einen gemeinsam genutzten Speicherhub gekoppelt sein.
  • Das System 500 beinhaltet einen Chipsatz 560, der mit Prozessoren 510 und 530 gekoppelt ist. Des Weiteren kann der Chipsatz 560 zum Beispiel über eine Schnittstelle (I/F) 566 mit dem Speicherungsmedium 503 gekoppelt sein. Die I/F 566 kann zum Beispiel ein Peripheral Component Interconnect-enhanced (PCI-e) sein. Die Prozessoren 510, 530 und die Vorrichtung 519 können über den Chipsatz 560 auf das Speicherungsmedium 503 zugreifen.
  • Das Speicherungsmedium 503 kann ein beliebiges nichtflüchtiges computerlesbares Speicherungsmedium oder maschinenlesbares Speicherungsmedium, wie etwa ein optisches, magnetisches oder Halbleiterspeicherungsmedium umfassen. Bei diversen Ausführungsformen kann das Speicherungsmedium 503 einen Herstellungsartikel umfassen. In einigen Ausführungsformen kann das Speichermedium 503 computerausführbare Anweisungen speichern, wie etwa computerausführbare Anweisungen 502, um eine(n) oder mehrere der hierin beschriebenen Prozesse oder Operationen zu implementieren (z. B. Prozess XY00 von Figur XY). Das Speicherungsmedium 503 kann computerausführbare Anweisungen für beliebige oben dargestellte Gleichungen speichern. Das Speicherungsmedium 503 kann ferner computerausführbare Anweisungen für hierin beschriebene Modelle und/oder Netzwerke, wie etwa ein neuronales Netzwerk oder dergleichen, speichern. Beispiele für ein computerlesbares Speicherungsmedium oder maschinenlesbares Speicherungsmedium können beliebige greifbare Medien beinhalten, die zum Speichern elektronischer Daten fähig sind, einschließlich flüchtigem Speicher oder nichtflüchtigem Speicher, entfernbarem oder nicht entfernbarem Speicher, löschbarem oder nicht löschbarem Speicher, beschreibbarem oder wiederbeschreibbarem Speicher und so weiter. Beispiele für computerausführbare Anweisungen können beliebige zweckdienliche Arten von Code beinhalten, wie etwa Quellcode, kompilierten Code, interpretierten Code, ausführbaren Code, statischen Code, dynamischen Code, objektorientierten Code, visuellen Code und dergleichen. Es versteht sich, dass die Ausführungsformen in diesem Kontext nicht beschränkt sind.
  • Der Prozessor 510 ist über P-P-Interconnects/-Schnittstellen 552 und 562 mit einem Chipsatz 560 gekoppelt und der Prozessor 530 ist über P-P-Interconnects/-Schnittstellen 554 und 564 mit einem Chipsatz 560 gekoppelt. Direct Media Interfaces (DMIs) können mit den P-P-Interconnects/-Schnittstellen 552 und 562 bzw. den P-P-Interconnects/-Schnittstellen 554 und 564 gekoppelt sein. Die DMI kann ein Hochgeschwindigkeits-Interconnect sein, das z. B. acht Gigatransfers pro Sekunde (GT/s) ermöglicht, wie etwa DMI 3.0. In anderen Ausführungsformen können die Prozessoren 510 und 530 über einen Bus miteinander verbunden sein.
  • Der Chipsatz 560 kann ein Steuerungshub, wie ein Plattformsteuerungshub (PCH) umfassen. Der Chipsatz 560 kann einen Systemtakt zum Durchführen von Taktungsfunktionen beinhalten und Schnittstellen für einen E/A-Bus, wie etwa einen Universal Serial Bus (USB), Peripheral Component Interconnects (PCIs), Serial Peripheral Interconnects (SPIs), Integrated Interconnects (I2Cs) und dergleichen beinhalten, um eine Verbindung von Peripherievorrichtungen auf der Plattform zu ermöglichen. In anderen Ausführungsformen kann der Chipsatz 560 mehr als einen Steuerungshub umfassen, wie einen Chipsatz mit einem Speichersteuerungshub, einem Grafiksteuerungshub und einem Eingabe/Ausgabe(E/A)-Steuerungshub.
  • In der vorliegenden Ausführungsform ist der Chipsatz 560 über eine Schnittstelle (I/F) 570 mit einem TPM (Trusted Platform Module - vertrauenswürdiges Plattformmodul) 572 und der UEFI-, BIOS-, Flash-Komponente 574 gekoppelt. Das TPM 572 ist ein dedizierter Mikrocontroller, der dazu gestaltet ist, Hardware durch Integrieren kryptografischer Schlüssel in Vorrichtungen zu sichern. Die UEFI-, BIOS-, Flash-Komponente 574 kann einen Vor-Boot-Code bereitstellen.
  • Des Weiteren beinhaltet der Chipsatz 560 die I/F 566 zum Koppeln des Chipsatzes 560 mit einer Hochleistungsgrafik-Engine, Grafikkarte 565. Die Grafikkarte 565 kann eine(n) oder mehrere der hierin beschriebenen Prozesse oder Operationen (z. B. Operationen der 2-4) implementieren und kann Komponenten von 1 beinhalten (z. B. den Partitionierer 104 von 1, den Subtrahierer 106 von 1, den Transformation-und-Quantisierer 108 von 1, das Codiergerät 110 von 1, den Decodierer 130 von 1, den Invers-Transformation-und-Quantisierer 112 von 1, den Addierer 114 von 1, die Prädiktionseinheit 116 von 1, die Steuerung 121 von 1). In anderen Ausführungsformen kann das System 500 eine flexible Anzeigeschnittstelle (FDI: Flexible Display Interface) zwischen den Prozessoren 510 und 530 und dem Chipsatz 560 beinhalten. Die FDI verbindet einen Grafikprozessorkern in einem Prozessor mit dem Chipsatz 560.
  • Verschiedene E/A-Vorrichtungen 592 sind mit dem Bus 581 gekoppelt, zusammen mit einer Busbrücke 580, die den Bus 581 mit einem zweiten Bus 591 koppelt, und einer I/F 568, die den Bus 581 mit dem Chipsatz 560 verbindet. In einer Ausführungsform kann der zweite Bus 591 ein Low-Pin-Count(LPC: niedrige Stiftanzahl)-Bus sein. Verschiedene Vorrichtungen können mit dem zweiten Bus 591 gekoppelt sein, einschließlich zum Beispiel einer Tastatur 582, einer Maus 584, Kommunikationsvorrichtungen 586, eines Speicherungsmediums 501 und einer Audio-E/A 590.
  • Der Künstliche-Intelligenz(KI)-Beschleuniger 567 kann eine Schaltungsanordnung sein, die dazu eingerichtet ist, Berechnungen bezüglich KI durchzuführen. Der KI-Beschleuniger 567 kann mit dem Speicherungsmedium 501 und dem Chipsatz 560 verbunden sein. Der KI-Beschleuniger 567 kann die Verarbeitungsleistung und die Energieeffizienz liefern, die benötigt werden, um eine reichliche Datenverarbeitung zu ermöglichen. Der KI-Beschleuniger 567 ist eine Klasse spezialisierter Hardwarebeschleuniger oder Computersysteme, die dazu gestaltet sind, für Künstliche-Intelligenz- und Maschinenlern-Anwendungen, einschließlich künstlicher neuronaler Netzwerke und Maschinenvision, zu beschleunigen. Der KI-Beschleuniger 567 kann auf Algorithmen für Robotik, Internet der Dinge, andere datenintensive und/oder sensorgesteuerte Aufgaben anwendbar sein.
  • Viele der E/A-Vorrichtungen 592, der Kommunikationsvorrichtungen 586 und des Speicherungsmediums 501 können sich auf der Hauptplatine 505 befinden, während die Tastatur 582 und die Maus 584 Zusatzperipheriegeräte sein können. In anderen Ausführungsformen sind manche oder alle der E/A-Vorrichtungen 592, der Kommunikationsvorrichtungen 586 und des Speicherungsmediums 501 Zusatzperipheriegeräte und befinden sich nicht auf der Hauptplatine 505.
  • Manche Beispiele können unter Verwendung des Ausdrucks „bei einem Beispiel“ oder „ein Beispiel“ zusammen mit ihren jeweiligen Ableitungen beschrieben sein. Diese Ausdrücke bedeuten, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Charakteristik, das bzw. die in Verbindung mit dem Beispiel beschrieben wird, in mindestens einem Beispiel enthalten ist. Das Vorhandensein des Ausdrucks „bei einem Beispiel“ an verschiedenen Stellen in der Beschreibung bezieht sich nicht notwendigerweise immer auf dasselbe Beispiel.
  • Manche Beispiele können unter Verwendung des Ausdrucks „gekoppelt“ und „verbunden“ und Ableitungen davon beschrieben sein. Diese Ausdrücke sind nicht notwendigerweise als synonym zueinander zu betrachten. Beschreibungen, die die Ausdrücke „verbunden“ und/oder „gekoppelt“ verwenden, können z. B. angeben, dass sich zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander befinden. Der Begriff „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehrere Elemente nicht in direktem Kontakt miteinander stehen, jedoch immer noch miteinander zusammenwirken oder interagieren.
  • Zusätzlich sind in der obenstehenden ausführlichen Beschreibung verschiedene Merkmale in einem einzigen Beispiel zum Zweck der Straffung der Offenbarung gruppiert. Diese Offenbarungsmethode darf nicht als eine Absicht wiedergebend ausgelegt werden, dass die beanspruchten Beispiele mehr Merkmale als ausdrücklich in jedem Anspruch erwähnt erfordern. Stattdessen liegt, wie in den folgenden Ansprüchen wiedergegeben, der erfinderische Gegenstand in weniger als allen Merkmalen eines einzelnen offenbarten Beispiels. Somit werden die folgenden Ansprüche hiermit in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch alleine als ein separates Beispiel steht. In den angehängten Ansprüchen werden die Begriffe „einschließlich“ und „in welchem/welcher“ als Äquivalente in einfachem Deutsch der entsprechenden Begriffe „umfassend“ bzw. „wobei“ verwendet. Zudem sind die Begriffe „erste/r“, „zweite/r“, „dritte/r“ usw. lediglich als Bezeichnungen verwendet und sollen keine numerischen Anforderungen an ihre Objekte darstellen.
  • Wenngleich der Gegenstand in einer Sprache beschrieben wurde, die für strukturelle Merkmale und/oder verfahrensgemäße Handlungen spezifisch ist, versteht es sich, dass der in den angehängten Ansprüchen definierte Gegenstand nicht notwendigerweise auf die oben beschriebenen spezifischen Merkmale oder Handlungen beschränkt ist. Stattdessen werden die oben beschriebenen spezifischen Merkmale und Handlungen als beispielhafte Formen des Implementierens der Ansprüche offenbart.
  • Ein Datenverarbeitungssystem, das zum Speichern und/oder Ausführen von Programmcode geeignet ist, beinhaltet mindestens einen Prozessor, der über einen Systembus direkt oder indirekt mit Speicherelementen gekoppelt ist. Die Speicherelemente können lokalen Speicher, der während der tatsächlichen Ausführung des Programmcodes eingesetzt wird, Massenspeicherung und Cache-Speicher beinhalten, die eine temporäre Speicherung von zumindest einem Teil des Programmcodes bereitstellen, um die Anzahl von Malen zu reduzieren, in denen Code aus der Massenspeicherung während der Ausführung abgerufen werden muss. Der Begriff „Code“ deckt eine breite Palette von Softwarekomponenten und -konstrukten ab, einschließlich Anwendungen, Treibern, Prozessen, Routinen, Verfahren, Modulen, Firmware, Mikrocode und Unterprogrammen. Dementsprechend kann der Begriff „Code“ verwendet werden, um auf eine beliebige Sammlung von Anweisungen zu verweisen, die, wenn sie durch ein Verarbeitungssystem ausgeführt werden, eine gewünschte Operation oder gewünschte Operationen ausführen.
  • Eine Logikschaltungsanordnung, Vorrichtungen und Schnittstellen, die hierin beschrieben sind, können Funktionen durchführen, die in Hardware implementiert sind und mit Code implementiert sind, der auf einem oder mehreren Prozessoren ausgeführt wird. Logikschaltungsanordnung bezieht sich auf die Hardware oder die Hardware und den Code, die/der eine oder mehrere logische Funktionen implementiert. Eine Schaltungsanordnung ist eine Hardware und kann sich auf eine oder mehrere Schaltungen beziehen. Jede Schaltung kann eine bestimmte Funktion durchführen. Eine Schaltung der Schaltungsanordnung kann diskrete elektrische Komponenten, die mit einem oder mehreren Leitern verbunden sind, eine integrierte Schaltung, ein Chipgehäuse, einen Chipsatz, Speicher oder dergleichen umfassen. Integrierte Schaltungen schließen Schaltungen ein, die auf einem Substrat, wie etwa einem Silizium-Wafer, erzeugt werden und Komponenten umfassen können. Integrierte Schaltungen, Prozessorgehäuse, Chipgehäuse und Chipsätze können einen oder mehrere Prozessoren umfassen.
  • Prozessoren können Signale, wie etwa Anweisungen und/oder Daten, an dem (den) Eingang (Eingängen) empfangen und die Signale verarbeiten, um die mindestens eine Ausgabe zu erzeugen. Während ein Code ausgeführt wird, ändert der Code die physikalischen Zustände und Charakteristiken von Transistoren, die eine Prozessor-Pipeline darstellen. Die physikalischen Zustände der Transistoren werden in logische Bits aus Einsen und Nullen übersetzt, die in Registern innerhalb des Prozessors gespeichert werden. Der Prozessor kann die physikalischen Zustände der Transistoren in Register transferieren und die physikalischen Zustände der Transistoren in ein anderes Speicherungsmedium transferieren.
  • Ein Prozessor kann Schaltungen zum Durchführen einer oder mehrerer Unterfunktionen umfassen, die zum Durchführen der Gesamtfunktion des Prozessors implementiert werden. Ein Beispiel für einen Prozessor ist eine Zustandsmaschine oder eine anwendungsspezifische integrierte Schaltung (ASIC), die mindestens einen Eingang und mindestens einen Ausgang beinhaltet. Eine Zustandsmaschine kann die mindestens eine Eingabe manipulieren, um die mindestens eine Ausgabe zu erzeugen, indem eine vorbestimmte Reihe von seriellen und/oder parallelen Manipulationen oder Transformationen an der mindestens einen Eingabe durchgeführt wird.
  • Die wie oben beschriebene Logik kann ein Teil der Gestaltung für einen Chip mit integrierter Schaltung sein. Die Chipgestaltung wird in einer grafischen Computerprogrammiersprache erzeugt und in einem Computerspeicherungsmedium oder Datenspeicherungsmedium (wie etwa einer Platte, einem Band, einer physischen Festplatte oder einer virtuellen Festplatte, wie etwa in einem Speicherungszugangsnetzwerk) gespeichert. Falls der Designer keine Chips oder die zum Fertigen von Chips verwendeten fotolithografischen Masken fertigt, überträgt der Designer die resultierende Gestaltung, direkt oder indirekt, durch ein physisches Mittel (z. B. durch Bereitstellen einer Kopie des Speicherungsmediums, das die Gestaltung speichert) oder elektronisch (z. B. über das Internet) zu solchen Entitäten. Die gespeicherte Gestaltung wird dann in das geeignete Format (z. B. GDSII) für die Fertigung konvertiert.
  • Die resultierenden Chips mit integrierter Schaltung können durch den Hersteller in Roh-Wafer-Form (das heißt als ein einziger Wafer, der mehrere ungehäuste Chips aufweist), als ein Bare-Die oder in einer gehäusten Form vertrieben werden. Im letzteren Fall ist der Chip in einem Einzelchipgehäuse (wie einem Kunststoffträger, mit Zuleitungen, die an einer Hauptplatine oder einem anderen Träger höherer Ebene angebracht sind) oder einem Mehrfachchipgehäuse (wie einem Keramikträger, der eines oder beide von Oberflächenzwischenverbindungen oder vergrabenen Zwischenverbindungen aufweist) befestigt. In jedem Fall wird der Chip dann mit anderen Chips, diskreten Schaltungselementen und/oder Signalverarbeitungsvorrichtungen als Teil von entweder (a) einem Zwischenprodukt, wie etwa einer Prozessorplatine, einer Serverplattform oder einer Hauptplatine, oder (b) einem Endprodukt integriert.
  • Das Wort „beispielhaft“ wird hierin mit der Bedeutung „als Beispiel, Fall oder Veranschaulichung dienend“ verwendet. Jede Ausführungsform, die hierin als „beispielhaft“ beschrieben ist, ist nicht notwendigerweise als gegenüber anderen Ausführungsformen bevorzugt oder vorteilhaft auszulegen. Die Begriffe „Rechenvorrichtung“, „Benutzervorrichtung“, „Kommunikationsstation“, „Station“, „Handheld-Vorrichtung“, „Mobilvorrichtung“, „drahtlose Vorrichtung“ und „Benutzergerät“ (UE), wie hierin verwendet, beziehen sie sich auf eine drahtlose Kommunikationsvorrichtung, wie etwa ein zellulares Telefon, ein Smartphone, ein Tablet, ein Netbook, ein drahtloses Endgerät, einen Laptop-Computer, eine Femtozelle, eine HDR-Teilnehmerstation (HDR: High Data Rate - hohe Datenrate), einen Zugangspunkt, einen Drucker, eine Point-of-Sale-Vorrichtung, ein Zugangsterminal oder eine andere PCS-Vorrichtung (PCS: Personal Communication System - persönliches Kommunikationssystem). Die Vorrichtung kann entweder mobil oder stationär sein.
  • So wie in diesem Dokument verwendet, soll der Begriff „Kommunizieren“ Übertragen oder Empfangen oder sowohl Übertragen als auch Empfangen beinhalten. Dies kann insbesondere in Ansprüchen nützlich sein, wenn die Organisation von Daten beschrieben wird, die durch eine Vorrichtung übertragen und durch eine andere empfangen werden, wobei aber nur die Funktionalität einer dieser Vorrichtungen ist erforderlich, um den Anspruch zu verletzen. Auf ähnliche Weise kann der bidirektionale Austausch von Daten zwischen zwei Vorrichtungen (beide Vorrichtungen übertragen und empfangen während des Austauschs) als „Kommunizieren“ beschrieben werden, wenn nur die Funktionalität einer dieser Vorrichtungen beansprucht wird. Der wie hierin in Bezug auf ein Drahtloskommunikationssignal verwendete Begriff „Kommunizieren“ beinhaltet das Übertragen des Drahtloskommunikationssignals und/oder das Empfangen des Drahtloskommunikationssignals. Beispielsweise kann eine Drahtloskommunikationseinheit, die ein Drahtloskommunikationssignal kommunizieren kann, einen drahtlosen Sender beinhalten, um das Drahtloskommunikationssignal zu mindestens einer anderen Drahtloskommunikationseinheit zu übertragen, und/oder einen Drahtloskommunikationsempfänger, um das Drahtloskommunikationssignal von mindestens einer anderen Drahtloskommunikationseinheit zu empfangen.
  • Der wie hierin verwendete Gebrauch der Ordnungsadjektive „erster“, „zweiter“, „dritter“ usw. zum Beschreiben eines gemeinsamen Objekts gibt, sofern nicht anders ausgeführt, lediglich an, dass ein Bezug auf unterschiedliche Instanzen ähnlicher Objekte erfolgt, und dies nicht implizieren soll, dass die so beschriebenen Objekte in einer gegebenen Sequenz vorhanden sein müssen, und zwar weder zeitlich, noch räumlich, in der Reihenfolge oder auf beliebige andere Weise.
  • Einige Ausführungsformen können in Verbindung mit verschiedenen Vorrichtungen und Systemen verwendet werden, zum Beispiel einem Personal Computer (PC), einem Desktop-Computer, einem mobilen Computer, einem Laptop-Computer, einem Notebook-Computer, einem Tablet-Computer, einem Server-Computer, einem Handheld-Computer, einer Handheld-Vorrichtung, einer Personal-Digital-Assistant(PDA)-Vorrichtung, einer Handheld-PDA-Vorrichtung, einer On-Board-Vorrichtung, einer Off-Board-Vorrichtung, einer Hybridvorrichtung, einer Fahrzeugvorrichtung, einer Nicht-Fahrzeug-Vorrichtung, einer mobilen oder portablen Vorrichtung, einer Verbrauchervorrichtung, einer nicht mobilen oder nicht portablen Vorrichtung, einer drahtlosen Kommunikationsstation, einer drahtlosen Kommunikationsvorrichtung, einem drahtlosen Zugangspunkt (AP), einem drahtgebundenen oder drahtlosen Router, einem drahtgebundenen oder drahtlosen Modem, einer Videovorrichtung, einer Audiovorrichtung, einer Audio-Video(A/V)-Vorrichtung, einem drahtgebundenen oder drahtlosen Netzwerk, einem Drahtlosnetzwerk, einem Drahtlos-Video-Netzwerk (WVAN), einem Lokalnetzwerk (LAN), einem Drahtlos-LAN (WLAN), einem persönlichen Netzwerk (WPAN), einem Drahtlos-PAN (WPAN) und dergleichen.
  • Ausführungsformen gemäß der Offenbarung sind insbesondere in den angehängten Ansprüchen offenbart, die sich auf ein Verfahren, ein Speicherungsmedium, eine Vorrichtung und ein Computerprogrammprodukt beziehen, wobei ein beliebiges Merkmal, das in einer Anspruchskategorie, z. B. Verfahren, erwähnt ist, auch in einer anderen Anspruchskategorie, z. B. System, beansprucht werden kann. Die Abhängigkeiten oder Rückverweisen in den angehängten Ansprüchen werden nur aus formellen Gründen ausgewählt. Jedoch kann jeder Erfindungsgegenstand, der aus einer gezielten Bezugnahme zurück auf beliebige vorherige Ansprüche (insbesondere mehrere Abhängigkeiten) resultiert, auch beansprucht werden, sodass eine beliebige Kombination von Ansprüchen und deren Merkmalen offenbart ist und unabhängig von den in den angehängten Ansprüchen gewählten Abhängigkeiten beansprucht werden kann. Der Gegenstand, der beansprucht werden kann, umfasst nicht nur die Kombinationen von Merkmalen, wie sie in den angehängten Ansprüchen dargelegt sind, sondern auch eine beliebige andere Kombination von Merkmalen in den Ansprüchen, wobei jedes in den Ansprüchen erwähnte Merkmal mit einem beliebigen anderen Merkmal oder einer beliebigen anderen Kombination anderer Merkmale in den Ansprüchen kombiniert werden kann. Des Weiteren können beliebige der hierin beschriebenen oder dargestellten Ausführungsformen und Merkmale in einem separaten Anspruch und/oder in einer beliebigen Kombination mit einer beliebigen hierin beschriebenen oder dargestellten Ausführungsform oder einem beliebigen hierin beschriebenen oder dargestellten Merkmal oder mit beliebigen der Merkmale der angehängten Ansprüche beansprucht werden.
  • Die vorstehende Beschreibung einer oder mehrerer Implementierungen stellt eine Veranschaulichung und Beschreibung bereit, soll jedoch nicht erschöpfend sein oder den Schutzumfang der Ausführungsformen auf die genaue offenbarte Form beschränken. Modifikationen und Variationen sind angesichts der obigen Lehren möglich oder können aus der Ausübung verschiedener Ausführungsformen erhalten werden.
  • Ausführungsformen gemäß der Offenbarung sind insbesondere in den angehängten Ansprüchen offenbart, die sich auf ein Verfahren, ein Speicherungsmedium, eine Vorrichtung und ein Computerprogrammprodukt beziehen, wobei ein beliebiges Merkmal, das in einer Anspruchskategorie, z. B. Verfahren, erwähnt ist, auch in einer anderen Anspruchskategorie, z. B. System, beansprucht werden kann. Die Abhängigkeiten oder Rückverweisen in den angehängten Ansprüchen werden nur aus formellen Gründen ausgewählt. Jedoch kann jeder Erfindungsgegenstand, der aus einer gezielten Bezugnahme zurück auf beliebige vorherige Ansprüche (insbesondere mehrere Abhängigkeiten) resultiert, auch beansprucht werden, sodass eine beliebige Kombination von Ansprüchen und deren Merkmalen offenbart ist und unabhängig von den in den angehängten Ansprüchen gewählten Abhängigkeiten beansprucht werden kann. Der Gegenstand, der beansprucht werden kann, umfasst nicht nur die Kombinationen von Merkmalen, wie sie in den angehängten Ansprüchen dargelegt sind, sondern auch eine beliebige andere Kombination von Merkmalen in den Ansprüchen, wobei jedes in den Ansprüchen erwähnte Merkmal mit einem beliebigen anderen Merkmal oder einer beliebigen anderen Kombination anderer Merkmale in den Ansprüchen kombiniert werden kann. Des Weiteren können beliebige der hierin beschriebenen oder dargestellten Ausführungsformen und Merkmale in einem separaten Anspruch und/oder in einer beliebigen Kombination mit einer beliebigen hierin beschriebenen oder dargestellten Ausführungsform oder einem beliebigen hierin beschriebenen oder dargestellten Merkmal oder mit beliebigen der Merkmale der angehängten Ansprüche beansprucht werden.
  • Die vorstehende Beschreibung einer oder mehrerer Implementierungen stellt eine Veranschaulichung und Beschreibung bereit, soll jedoch nicht erschöpfend sein oder den Schutzumfang der Ausführungsformen auf die genaue offenbarte Form beschränken. Modifikationen und Variationen sind angesichts der obigen Lehren möglich oder können aus der Ausübung verschiedener Ausführungsformen erhalten werden.
  • Gewisse Aspekte der Offenbarung sind oben unter Bezugnahme auf Block- und Flussdiagramme von Systemen, Verfahren, Einrichtungen und/oder Computerprogrammprodukten gemäß verschiedenen Implementierungen beschrieben. Es versteht sich, dass ein oder mehrere Blöcke der Blockdiagramme und Flussdiagramme und Kombinationen von Blöcken in den Blockdiagrammen bzw. den Flussdiagrammen durch computerausführbare Programmanweisungen implementiert werden können. Gleichermaßen müssen manche Blöcke der Blockdiagramme und Flussdiagramme möglicherweise nicht notwendigerweise in der dargestellten Reihenfolge durchgeführt werden oder müssen möglicherweise notwendigerweise überhaupt nicht durchgeführt werden.
  • Diese computerausführbaren Programmanweisungen können auf einen Spezialcomputer oder eine andere spezielle Maschine, einen Prozessor oder eine andere programmierbare Datenverarbeitungseinrichtung geladen werden, um eine spezielle Maschine zu erzeugen, sodass die Anweisungen, die auf dem Computer, dem Prozessor oder einer anderen programmierbaren Datenverarbeitungseinrichtung ausgeführt werden, Mittel zum Implementieren einer oder mehrerer Funktionen erzeugen, die in dem/den Flussdiagrammblock oder -blöcken spezifiziert sind. Diese Computerprogrammanweisungen können auch in einem computerlesbaren Speicherungsmedium oder Speicher gespeichert sein, das/der einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung anweisen kann, auf eine spezielle Weise zu funktionieren, sodass die in dem computerlesbaren Speicherungsmedium gespeicherten Anweisungen einen Herstellungsartikel erzeugen, der Anweisungsmittel beinhaltet, die eine oder mehrere Funktionen implementieren, die in dem/den Flussdiagrammblock oder -blöcken spezifiziert sind. Als ein Beispiel können bestimmte Implementierungen ein Computerprogrammprodukt bereitstellen, das ein computerlesbares Speicherungsmedium mit einem darin implementierten computerlesbaren Programmcode oder darin implementierten Programmanweisungen aufweist, wobei der computerlesbare Programmcode dazu ausgelegt ist, ausgeführt zu werden, um eine oder mehrere Funktionen zu implementieren, die in dem/den Flussdiagrammblock oder -blöcken spezifiziert sind. Die Computerprogrammanweisungen können auch auf einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung geladen werden, um zu bewirken, dass eine Reihe von Betriebselementen oder -schritten auf dem Computer oder einer anderen programmierbaren Einrichtung durchgeführt wird, um einen computerimplementierten Prozess zu erzeugen, sodass die Anweisungen, die auf dem Computer oder einer anderen programmierbaren Einrichtung ausgeführt werden. Elemente oder Schritte zum Implementieren der Funktionen bereitstellen, die in dem/den Flussdiagrammblock oder -blöcken spezifiziert sind.
  • Dementsprechend unterstützen Blöcke der Blockdiagramme und Flussdiagramme Kombinationen von Mitteln zum Durchführen der spezifizierten Funktionen, Kombinationen von Elementen oder Schritten zum Durchführen der spezifizierten Funktionen und Programmanweisungsmittel zum Durchführen der spezifizierten Funktionen. Es versteht sich auch, dass jeder Block der Blockdiagramme und Flussdiagramme und Kombinationen von Blöcken in den Blockdiagrammen und Flussdiagrammen durch spezielle hardwarebasierte Computersysteme, die die spezifizierten Funktionen, Elemente oder Schritte durchführen, oder Kombinationen von Spezialhardware und Computeranweisungen implementiert werden können.
  • Konditionelle Formulierungen, wie etwa unter anderem „kann“, „könnte“, „dürfte“ oder „möglicherweise“, sollen, sofern nicht spezifisch anders angegeben oder in dem verwendeten Kontext anderweitig zu verstehen, im Allgemeinen vermitteln, dass bestimmte Implementierungen bestimmte Merkmale, Elemente und/oder Operationen beinhalten könnten, während andere Implementierungen diese nicht beinhalten. Somit sollen solche konditionellen Formulierungen im Allgemeinen nicht implizieren, dass Merkmale, Elemente und/oder Operationen auf irgendeine Weise für eine oder mehrere Implementierungen erforderlich sind oder dass eine oder mehrere Implementierungen notwendigerweise Logik zum Entscheiden beinhalten, mit oder ohne Benutzereingabe oder -Aufforderung, ob diese Merkmale, Elemente und/oder Operationen enthalten sind oder in irgendeiner bestimmten Implementierung durchzuführen sind.
  • Viele Modifikationen und andere Implementierungen der hierin dargelegten Offenbarung werden mit dem Nutzen der in den vorstehenden Beschreibungen und den assoziierten Zeichnungen dargelegten Lehren ersichtlich. Daher versteht es sich, dass die Offenbarung nicht auf die spezifischen offenbarten Implementierungen beschränkt sein soll und dass Modifikationen und andere Implementierungen innerhalb des Schutzumfangs der angehängten Ansprüche eingeschlossen sein sollen. Obwohl hierin spezifische Begriffe eingesetzt werden, werden sie nur in einem generischen und beschreibenden Sinn und nicht zum Zweck der Beschränkung verwendet.

Claims (20)

  1. Verfahren, das Folgendes umfasst: Empfangen erster codierter Videodaten eines Bitstroms; Decodieren einer ersten Codierungseinheit (CU) eines ersten Videoframes der ersten codierten Videodaten, wobei die erste CU eine erste Transformationseinheit (TU) und eine zweite TU umfasst; Bestimmen, basierend auf ersten decodierten Daten, die mit dem Decodieren der ersten CU assoziiert sind, und vor dem Decodieren der ersten TU und der zweiten TU, eines ersten Typs von Transformation, der zum Erzeugen jeweiliger Transformationskoeffizienten für die erste TU und die zweite TU verwendet wird; Decodieren der ersten TU, wobei das Decodieren der ersten TU Identifizieren erster Transformationskoeffizienten umfasst; Decodieren der zweiten TU, wobei das Decodieren der zweiten TU Identifizieren zweiter Transformationskoeffizienten umfasst; Erzeugen, basierend auf dem ersten Typ von Transformation und den ersten Transformationskoeffizienten, erster rekonstruierter Pixelwerte der ersten TU; und Erzeugen, basierend auf dem ersten Typ von Transformation und den zweiten Transformationskoeffizienten, zweiter rekonstruierter Pixelwerte der zweiten TU.
  2. Verfahren nach Anspruch 1, wobei der erste Typ von Transformation eine LFNST (Low Frequency Non-Separable Transform - niederfrequente nichttrennbare Transformation) ist, und wobei das Bestimmen des ersten Typs von Transformation ferner Bestimmen, basierend auf den ersten decodierten Daten, mindestens eines von Folgendem umfasst: ein Partitionierungsbaumtyp ist kein dualer Chroma-Baum, ein erstes Flag, das die Verwendung einer Matrix-Intra-Prädiktion-basierten Bildcodierung angibt, ist auf einen Wert von Wahr gesetzt, oder eine erste Breite der LFNST oder eine erste Höhe der LFNST ist kleiner als 16.
  3. Verfahren nach Anspruch 1 oder 2, wobei der erste Typ von Transformation eine MTS (Multi Transform Selection - Mehrfachtransformationsauswahl) ist, und wobei das Bestimmen des ersten Typs von Transformation ferner Bestimmen, basierend auf den ersten decodierten Daten, mindestens eines von Folgendem umfasst: ein Partitionierungsbaumtyp ist ein dualer Chroma-Baum, ein Intra-Teilpartitionen-Aufteilungstyp ist nicht auf einen Wert von No-Split (keine Aufteilung) gesetzt, ein zweites Flag, das die Verwendung einer Unterblocktransformation angibt, ist auf einen Wert von Wahr gesetzt, oder eine Breite der MTS oder eine Höhe der MTS ist größer als 32.
  4. Verfahren nach einem der Ansprüche 1 bis 3, das ferner Folgendes umfasst: Empfangen zweiter codierter Videodaten des Bitstroms; Decodieren einer zweiten CU der zweiten codierten Videodaten, wobei die zweite CU eine dritte TU und eine vierte TU umfasst; Decodieren der dritten TU, wobei das Decodieren der dritten TU Identifizieren dritter Transformationskoeffizienten umfasst; Bestimmen, basierend auf zweiten decodierten Daten, die mit dem Decodieren der dritten TU assoziiert sind, und vor dem Decodieren der vierten TU, eines zweiten Typs von Transformation, der zum Erzeugen der dritten Transformationskoeffizienten für dritte TU verwendet wird; und Erzeugen, basierend auf dem zweiten Typ von Transformation und den dritten Transformationskoeffizienten, dritter rekonstruierter Pixelwerte der dritten TU.
  5. Verfahren nach Anspruch 4, das ferner Folgendes umfasst: Bestimmen, basierend auf dem Decodieren der zweiten CU, und vor dem Decodieren der dritten TU, mindestens eines von Folgendem: eine erste Breite oder eine erste Höhe des zweiten Typs von Transformation ist kleiner als vier oder größer als ein Schwellenwert, ein drittes Flag, das ein Vorhandensein eines LFNST-Index angibt, ist auf einen Wert von Falsch gesetzt, oder ein Inter-Prädiktion-Codierungsmodus wurde verwendet, wobei das Bestimmen, basierend auf dem Decodieren der zweiten CU, angibt, dass der zweite Typ der Transformation nicht LFNST ist.
  6. Verfahren nach Anspruch 4 oder 5, wobei der erste Typ von Transformation LFNST ist, und wobei das Bestimmen des zweiten Typs von Transformation ferner Bestimmen mindestens eines von Folgendem umfasst: ein Intra-Prädiktion-Codierungsmodus wird verwendet, eine Größe der zweiten CU ist kleiner oder gleich 64 mal 64, die CU umfasst weniger als oder gleich sechs TUs, ein Wert eines vierten Flags ist gleich eins, und ein Wert eines fünften Flags, das angibt, dass der zweite Typ von Transformation LFNST ist, ist gleich Null.
  7. Verfahren nach einem der Ansprüche 4 bis 6, wobei der erste Typ von Transformation MTS ist, und wobei das Bestimmen des zweiten Typs von Transformation ferner Bestimmen mindestens eines von Folgendem umfasst: ein Intra-Prädiktion-Codierungsmodus wird verwendet, eine Größe der zweiten CU ist kleiner oder gleich 32 mal 32, die CU umfasst weniger als oder gleich drei TUs, oder die dritte TU und vierte TU umfassen beide weniger als 16 mal 16 Transformationskoeffizienten.
  8. Verfahren nach einem der Ansprüche 1-7, das ferner Folgendes umfasst: Empfangen dritter codierter Videodaten des Bitstroms; Decodieren einer dritten CU der dritten codierten Videodaten, wobei die dritte CU eine fünfte TU und eine sechste TU umfasst; Decodieren der fünften TU, wobei das Decodieren der fünften TU Identifizieren vierter Transformationskoeffizienten umfasst; Decodieren der sechsten TU, wobei das Decodieren der sechsten TU Identifizieren fünfter Transformationskoeffizienten umfasst; Bestimmen, basierend auf der Decodierungssyntax der dritten codierten Videodaten, nach dem Decodieren aller TUs der dritten CU, eines dritten Typs von Transformation, der zum Erzeugen der vierten Transformationskoeffizienten und der fünften Transformationskoeffizienten verwendet wird; Erzeugen, basierend auf dem dritten Typ von Transformation und den vierten Transformationskoeffizienten, vierter rekonstruierter Pixelwerte der fünften TU; und Erzeugen, basierend auf dem dritten Typ von Transformation und den fünften Transformationskoeffizienten, fünfter rekonstruierter Pixelwerte für die sechste TU.
  9. System, das Folgendes umfasst: einen Prozessor; und einen Speicher, der computerausführbare Anweisungen speichert, die bei Ausführung durch den Prozessor den Prozessor zu Folgendem veranlassen: Empfangen erster codierter Videodaten eines Bitstroms; Decodieren einer ersten Codierungseinheit (CU) eines ersten Videoframes der ersten codierten Videodaten, wobei die erste CU eine erste Transformationseinheit (TU) und eine zweite TU umfasst; Bestimmen, basierend auf ersten decodierten Daten, die mit dem Decodieren der ersten CU assoziiert sind, und vor dem Decodieren der ersten TU und der zweiten TU, eines ersten Typs von Transformation, der zum Erzeugen jeweiliger Transformationskoeffizienten für die erste TU und die zweite TU verwendet wird; Decodieren der ersten TU, wobei das Decodieren der ersten TU Identifizieren erster Transformationskoeffizienten umfasst; Decodieren der zweiten TU, wobei das Decodieren der zweiten TU Identifizieren zweiter Transformationskoeffizienten umfasst; Erzeugen, basierend auf dem ersten Typ von Transformation und den ersten Transformationskoeffizienten, erster rekonstruierter Pixelwerte der ersten TU; und Erzeugen, basierend auf dem ersten Typ von Transformation und den zweiten Transformationskoeffizienten, zweiter rekonstruierter Pixelwerte der zweiten TU.
  10. System nach Anspruch 9, wobei der erste Typ von Transformation eine LFNST (Low Frequency Non-Separable Transform - niederfrequente nichttrennbare Transformation) ist, und wobei das Bestimmen des ersten Typs von Transformation ferner Bestimmen, basierend auf den ersten decodierten Daten, mindestens eines von Folgendem umfasst: ein Partitionierungsbaumtyp ist kein dualer Chroma-Baum, ein erstes Flag, das die Verwendung einer Matrix-Intra-Prädiktion-basierten Bildcodierung angibt, ist auf einen Wert von Wahr gesetzt, oder eine erste Breite der LFNST oder eine erste Höhe der LFNST ist kleiner als 16.
  11. System nach Anspruch 9 oder 10, wobei der erste Typ von Transformation eine MTS (Multi Transform Selection - Mehrfachtransformationsauswahl) ist, und wobei das Bestimmen des ersten Typs von Transformation ferner Bestimmen, basierend auf den ersten decodierten Daten, mindestens eines von Folgendem umfasst: ein Partitionierungsbaumtyp ist ein dualer Chroma-Baum, ein Intra-Teilpartitionen-Aufteilungstyp ist nicht auf einen Wert von No-Split (keine Aufteilung) gesetzt, ein zweites Flag, das die Verwendung einer Unterblocktransformation angibt, ist auf einen Wert von Wahr gesetzt, oder eine Breite der MTS oder eine Höhe der MTS ist größer als 32.
  12. System nach einem der Ansprüche 9 bis 11, wobei die computerausführbaren Anweisungen den Prozessor ferner zu Folgendem veranlassen: Empfangen zweiter codierter Videodaten des Bitstroms; Decodieren einer zweiten CU der zweiten codierten Videodaten, wobei die zweite CU eine dritte TU und eine vierte TU umfasst; Decodieren der dritten TU, wobei das Decodieren der dritten TU Identifizieren dritter Transformationskoeffizienten umfasst; Bestimmen, basierend auf zweiten decodierten Daten, die mit dem Decodieren der dritten TU assoziiert sind, und vor dem Decodieren der vierten TU, eines zweiten Typs von Transformation, der zum Erzeugen der dritten Transformationskoeffizienten für dritte TU verwendet wird; und Erzeugen, basierend auf dem zweiten Typ von Transformation und den dritten Transformationskoeffizienten, dritter rekonstruierter Pixelwerte der dritten TU.
  13. System nach Anspruch 12, wobei die computerausführbaren Anweisungen den Prozessor ferner zu Folgendem veranlassen: Bestimmen, basierend auf dem Decodieren der zweiten CU, und vor dem Decodieren der dritten TU, mindestens eines von Folgendem: eine erste Breite oder eine erste Höhe des zweiten Typs von Transformation ist kleiner als vier oder größer als ein Schwellenwert, ein drittes Flag, das ein Vorhandensein eines LFNST-Index angibt, ist auf einen Wert von Falsch gesetzt, oder ein Inter-Prädiktion-Codierungsmodus wurde verwendet, wobei die Bestimmung, basierend auf dem Decodieren der zweiten CU, angibt, dass der zweite Typ der Transformation nicht LFNST ist.
  14. System nach Anspruch 12 oder 13, wobei der erste Typ von Transformation LFNST ist, und wobei das Bestimmen des zweiten Typs von Transformation ferner Bestimmen mindestens eines von Folgendem umfasst: ein Intra-Prädiktion-Codierungsmodus wird verwendet, eine Größe der zweiten CU ist kleiner oder gleich 64 mal 64, die CU umfasst weniger als oder gleich sechs TUs, ein Wert eines vierten Flags ist gleich eins, und ein Wert eines fünften Flags, das angibt, dass der zweite Typ von Transformation LFNST ist, ist gleich Null.
  15. System nach einem der Ansprüche 12 bis 14, wobei der erste Typ von Transformation MTS ist, und wobei das Bestimmen des zweiten Typs von Transformation ferner Bestimmen mindestens eines von Folgendem umfasst: ein Intra-Prädiktion-Codierungsmodus wird verwendet, eine Größe der zweiten CU ist kleiner oder gleich 32 mal 32, die CU umfasst weniger als oder gleich drei TUs, oder die dritte TU und vierte TU umfassen beide weniger als 16 mal 16 Transformationskoeffizienten.
  16. System nach einem der Ansprüche 9-15, wobei die computerausführbaren Anweisungen den Prozessor ferner zu Folgendem veranlassen: Empfangen dritter codierter Videodaten des Bitstroms; Decodieren einer dritten CU der dritten codierten Videodaten, wobei die dritte CU eine fünfte TU und eine sechste TU umfasst; Decodieren der fünften TU, wobei das Decodieren der fünften TU Identifizieren vierter Transformationskoeffizienten umfasst; Decodieren der sechsten TU, wobei das Decodieren der sechsten TU Identifizieren fünfter Transformationskoeffizienten umfasst; Bestimmen, basierend auf der Decodierungssyntax der dritten codierten Videodaten, nach dem Decodieren aller TUs der dritten CU, eines dritten Typs von Transformation, der zum Erzeugen der vierten Transformationskoeffizienten und der fünften Transformationskoeffizienten verwendet wird; Erzeugen, basierend auf dem dritten Typ von Transformation und den vierten Transformationskoeffizienten, vierter rekonstruierter Pixelwerte der fünften TU; und Erzeugen, basierend auf dem dritten Typ von Transformation und den fünften Transformationskoeffizienten, fünfter rekonstruierter Pixelwerte für die sechste TU.
  17. Computerlesbares Medium, das computerausführbare Anweisungen speichert, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, zum Durchführen folgender Operationen führen: Empfangen erster codierter Videodaten eines Bitstroms; Decodieren einer ersten Codierungseinheit (CU) eines ersten Videoframes der ersten codierten Videodaten, wobei die erste CU eine erste Transformationseinheit (TU) und eine zweite TU umfasst; Bestimmen, basierend auf ersten decodierten Daten, die mit dem Decodieren der ersten CU assoziiert sind, und vor dem Decodieren der ersten TU und der zweiten TU, eines ersten Typs von Transformation, der zum Erzeugen jeweiliger Transformationskoeffizienten für die erste TU und die zweite TU verwendet wird; Decodieren der ersten TU, wobei das Decodieren der ersten TU Identifizieren erster Transformationskoeffizienten umfasst; Decodieren der zweiten TU, wobei das Decodieren der zweiten TU Identifizieren zweiter Transformationskoeffizienten umfasst; Erzeugen, basierend auf dem ersten Typ von Transformation und den ersten Transformationskoeffizienten, erster rekonstruierter Pixelwerte der ersten TU; und Erzeugen, basierend auf dem ersten Typ von Transformation und den zweiten Transformationskoeffizienten, zweiter rekonstruierter Pixelwerte der zweiten TU.
  18. Computerlesbares Medium nach Anspruch 17, wobei der erste Typ von Transformation eine LFNST (Low Frequency Non-Separable Transform - niederfrequente nichttrennbare Transformation) ist, und wobei das Bestimmen des ersten Typs von Transformation ferner Bestimmen, basierend auf den ersten decodierten Daten, mindestens eines von Folgendem umfasst: ein Partitionierungsbaumtyp ist kein dualer Chroma-Baum, ein erstes Flag, das die Verwendung einer Matrix-Intra-Prädiktion-basierten Bildcodierung angibt, ist auf einen Wert von Wahr gesetzt, oder eine erste Breite der LFNST oder eine erste Höhe der LFNST ist kleiner als 16.
  19. Computerlesbares Medium nach Anspruch 17 oder 18, wobei der erste Typ von Transformation eine MTS (Multi Transform Selection - Mehrfachtransformationsauswahl) ist, und wobei das Bestimmen des ersten Typs von Transformation ferner Bestimmen, basierend auf den ersten decodierten Daten, mindestens eines von Folgendem umfasst: ein Partitionierungsbaumtyp ist ein dualer Chroma-Baum, ein Intra-Teilpartitionen-Aufteilungstyp ist nicht auf einen Wert von No-Split (keine Aufteilung) gesetzt, ein zweites Flag, das die Verwendung einer Unterblocktransformation angibt, ist auf einen Wert von Wahr gesetzt, oder eine Breite der MTS oder eine Höhe der MTS ist größer als 32.
  20. Computerlesbares Medium nach einem der Ansprüche 17 bis 19, wobei die computerausführbaren Anweisungen den Prozessor ferner zu Folgendem veranlassen: Empfangen zweiter codierter Videodaten des Bitstroms; Decodieren einer zweiten CU der zweiten codierten Videodaten, wobei die zweite CU eine dritte TU und eine vierte TU umfasst; Decodieren der dritten TU, wobei das Decodieren der dritten TU Identifizieren dritter Transformationskoeffizienten umfasst; Bestimmen, basierend auf zweiten decodierten Daten, die mit dem Decodieren der dritten TU assoziiert sind, und vor dem Decodieren der vierten TU, eines zweiten Typs von Transformation, der zum Erzeugen der dritten Transformationskoeffizienten für dritte TU verwendet wird; und Erzeugen, basierend auf dem zweiten Typ von Transformation und den dritten Transformationskoeffizienten, dritter rekonstruierter Pixelwerte der dritten TU. Bestimmen, basierend auf dem ersten Typ von Transformation, einer inversen Transformation der dritten TU.
DE102022126701.6A 2021-12-03 2022-10-13 Niederfrequente nichttrennbare transformation und mehrfachtransformationsauswahl-deadlock-prävention Pending DE102022126701A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/457,643 2021-12-03
US17/457,643 US20220094931A1 (en) 2021-12-03 2021-12-03 Low frequency non-separable transform and multiple transform selection deadlock prevention

Publications (1)

Publication Number Publication Date
DE102022126701A1 true DE102022126701A1 (de) 2023-06-07

Family

ID=80741027

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022126701.6A Pending DE102022126701A1 (de) 2021-12-03 2022-10-13 Niederfrequente nichttrennbare transformation und mehrfachtransformationsauswahl-deadlock-prävention

Country Status (4)

Country Link
US (1) US20220094931A1 (de)
KR (1) KR20230084025A (de)
CN (1) CN116233469A (de)
DE (1) DE102022126701A1 (de)

Also Published As

Publication number Publication date
CN116233469A (zh) 2023-06-06
KR20230084025A (ko) 2023-06-12
US20220094931A1 (en) 2022-03-24

Similar Documents

Publication Publication Date Title
DE102016125117B4 (de) Bewegungsvektorkodierung mit dynamischen Referenzbewegungsvektoren
DE102016125379B4 (de) Bewegungsvektoraufteilung des letzten Frames
DE102016225270A1 (de) Verfahren, anwendungsprozessor, und mobiles endgerät zum verarbeiten eines referenzbildes
DE112017006657T5 (de) Adaptive planare Prädiktion mit ungleichen Gewichten
DE202016008175U1 (de) Adaptive gerichtete Intra-Prädiktion mit Blockgröße
DE112017003212T5 (de) Verfahren und System zur Videocodierung mit Kontextdecodierung und Rekonstruktionsumgehung
DE112007002493T5 (de) Verfahren zum Zerlegen eines Videosequenzrahmens
DE112009004344T5 (de) Parallele Implementierung einer Rechenmaschine nach dem Pipelineverfahren auf einerintegrierten Schaltung
DE102016125094A1 (de) Auswahl des Referenz-Bewegungsvektors über Referenzeinzelbild Puffer-Nachverfolgung
CN111901596B (zh) 基于深度学习的视频混合编码与解码方法及装置、介质
CN114650419A (zh) 进行帧内预测的编码器、解码器和对应方法
DE202016008178U1 (de) Bewegungsvektorvorhersage mittels eines vorhergehenden Einzelbildresiduums
DE102016125125A1 (de) Tile-Copying für Videokompression
DE112018005899T5 (de) System und Verfahren zum Konstruieren einer Ebene für planare Prädiktion
DE202017007520U1 (de) Bewegungskompensation durch maschinelles Lernen
DE102016125591A1 (de) Hybrid-Prädiktionsmodi zur Kodierung von Videos
DE102016125604A1 (de) Intelligente Sortierung der rekursiven Blockaufteilung für die erweiterte Intra-Prädiktion bei der Videocodierung
DE102020108428A1 (de) Codieren von Video unter Verwendung zweistufiger Intra-Suche
DE102015116544A1 (de) Anwendungs-Prozessor zum Durchführen von In-Loop-Filterung, Verfahren davon und System mit demselben
EP0956539A1 (de) Verfahren und anordnung zur codierung und decodierung eines digitalisierten bildes
DE112015005159B4 (de) Kodierung im alternierenden blockbeschränkten entscheidungsmodus
DE102014115013A1 (de) Videokodierverfahren und Vorrichtung, und Videodekodierverfahren und Vorrichtung, die eine Bewegungskompensation durchführen
AU2018454766A1 (en) Decoding prediction method and apparatus, and computer storage medium
JP6899053B2 (ja) 画像復号装置、画像復号方法及びプログラム
DE102022126701A1 (de) Niederfrequente nichttrennbare transformation und mehrfachtransformationsauswahl-deadlock-prävention