DE102020127627A1 - Verfahren und System zum Videocodieren mit Intra-Block-Kopieren - Google Patents

Verfahren und System zum Videocodieren mit Intra-Block-Kopieren Download PDF

Info

Publication number
DE102020127627A1
DE102020127627A1 DE102020127627.3A DE102020127627A DE102020127627A1 DE 102020127627 A1 DE102020127627 A1 DE 102020127627A1 DE 102020127627 A DE102020127627 A DE 102020127627A DE 102020127627 A1 DE102020127627 A1 DE 102020127627A1
Authority
DE
Germany
Prior art keywords
block
hash codes
prediction
frame
blocks
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
DE102020127627.3A
Other languages
English (en)
Inventor
Jason Tanner
Zhijun Lei
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 DE102020127627A1 publication Critical patent/DE102020127627A1/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/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/103—Selection of coding mode or of prediction mode
    • H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • 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/97—Matching pursuit 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/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/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/103—Selection of coding mode or of prediction mode
    • 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/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • 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/142—Detection of scene cut or scene change
    • 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/172—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 picture, frame or field
    • 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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H04N19/426—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements using memory downsizing methods
    • H04N19/427—Display on the fly, e.g. simultaneous writing to and reading from decoding memory
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques

Landscapes

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

Abstract

Verfahren, Artikel und Systeme zum Videocodieren verwenden Intra-Block-Kopieren mit hashbasierten Suchen.

Description

  • Hintergrund
  • Eine Reihe von Videocodierungsstandards verwendet spezielle Techniken, um synthetischen Video oder synthetischen Bildschirminhalt, das/der sich von dem von einer Kamera aufgenommenen Video unterscheidet, zu codieren. Solcher Bildschirminhalt kann in typischen bürobasierten Anwendungen wie Textverarbeitungsprogrammen, Präsentationsprogrammen, Tabellenkalkulationen usw. Text enthalten. Anderer Bildschirminhalt mit großen flachen oder einheitlichen Bereichen, der sich häufig von mit der Kamera aufgenommenen Videos unterscheidet, kann Animationen, Spiele usw. umfassen. Außerdem ist es häufig wünschenswert, den Bildschirm mit solchem Inhalt für Videokonferenzen oder die Projektion auf größere Bildschirmfernseher oder Monitore zu teilen, beispielsweise mit Personenbereichsnetzen (PANs). Da solcher synthetischer Bildschirminhalt große Mengen wiederholter flacher (oder einheitlicher) Bilddaten aufweist, die sich von Bild zu Bild im Vergleich zu dem von einer Kamera aufgenommenen Video in relativ großen Segmenten und in relativ großen Abständen bewegen, wurde festgestellt, dass Videocodierung von solchem synthetischen Bildschirminhalt anders ausgeführt werden kann als bei aufgenommenen Videos, um die Leistungsfähigkeit und/oder Qualität zu verbessern. Ein Beispiel für einen solchen Codec ist die Bildschirminhaltscodierungserweiterung (SCC-Erweiterung) der hocheffizienten Videocodierung (HEVC). Die bekannten SCC-Videocodierungstechniken beinhalten jedoch häufig zu große Rechenlasten, die die Leistungsfähigkeit verringern und zu viel Leistung aufnehmen können. Herkömmliche Techniken zur Reduzierung der Rechenlast erhöhen häufig die Leistungsfähigkeit, indem sie zu viel Qualität opfern, insbesondere bei SCC-Intra-Vorhersage-Videocodierungstechniken wie etwa der hashbasierten Suche für Intra-Block-Kopieren (IBC).
  • Figurenliste
  • Das hierin beschriebene Material ist beispielhaft und nicht einschränkend in den begleitenden Figuren dargestellt. Zur Vereinfachung und Verdeutlichung der Darstellung sind die in den Figuren dargestellten Elemente nicht unbedingt maßstabsgetreu gezeichnet. Beispielsweise können die Abmessungen einiger Elemente aus Gründen der Klarheit relativ zu anderen Elementen übertrieben sein. Darüber hinaus wurden gegebenenfalls Bezugszeichen in den Figuren wiederholt, um entsprechende oder analoge Elemente anzugeben; es zeigen:
    • 1 ein schematisches Diagramm eines Bereichs eines Bildes, das alternative Vorhersageblockgrößen zum Codieren der Vorhersage zeigt;
    • 2 ein schematisches Diagramm eines Codierers gemäß mindestens einer der Implementierungen hierin;
    • 3 ein schematisches Diagramm eines Decodierers gemäß mindestens einer der Implementierungen hierin;
    • 4 ein Ablaufdiagramm eines Verfahrens zum Videocodieren mit Intra-Block-Kopieren gemäß mindestens einer der Implementierungen hierin;
    • 5A-5C ein detailliertes Ablaufdiagramm eines Verfahrens zum Videocodieren mit Intra-Block-Kopieren gemäß mindestens einer der Implementierungen hierin;
    • 6 ein schematisches Diagramm von Ankerpixelorten für Referenzbasisblöcke auf einem Bild gemäß mindestens einer der Implementierungen hierin;
    • 7A ein schematisches Diagramm eines Bildes, das Referenzbasisblöcke eines flachen, gleichmäßigen Bereichs zeigt, gemäß mindestens einer der Implementierungen hierin;
    • 7B ein schematisches Diagramm eines Referenz-Frames, das einen mit dem Hash-Code übereinstimmenden Block zeigt, gemäß mindestens einer der hierin implementierten Implementierungen;
    • 8 ein schematisches Diagramm eines Bildes, das Quellbasisblöcke mit übereinstimmenden Basis-Hash-Codes zeigt, gemäß mindestens einer der Implementierungen hierin;
    • 9A ein schematisches Diagramm eines Hash-Codes gemäß mindestens einer der Implementierungen hierin;
    • 9B ein schematisches Diagramm zum Erläutern von Hash-Code-Verkettung und Blockkorrespondenz gemäß mindestens einer der Implementierungen hierin;
    • 10 ein veranschaulichendes Diagramm eines Beispielsystems;
    • 11 ein veranschaulichendes Diagramm eines weiteren Beispielsystems; und
    • 12 eine weitere beispielhafte Vorrichtung, die ganz gemäß mindestens einigen Implementierungen der vorliegenden Offenbarung angeordnet ist.
  • Genaue Beschreibung
  • Eine oder mehrere Implementierungen werden nun unter Bezugnahme auf die begleitenden Figuren beschrieben. Obwohl spezifische Konfigurationen und Anordnungen diskutiert werden, sollte verstanden werden, dass dies nur zur Veranschaulichung erfolgt. Fachleute auf dem Gebiet werden erkennen, dass andere Konfigurationen und Anordnungen verwendet werden können, ohne vom Gedanken und Umfang der Beschreibung abzuweichen. Fachleuten wird klar sein, dass hierin beschriebene Techniken und/oder Anordnungen auch in einer Vielzahl anderer Systeme und Anwendungen als den hier beschriebenen eingesetzt werden können.
  • Obwohl die folgende Beschreibung verschiedene Implementierungen darlegt, die sich in Architekturen wie beispielsweise Ein-Chip-System-Architekturen (SoC-Architekturen) manifestieren können, ist die Implementierung der hier beschriebenen Techniken und/oder Anordnungen nicht auf bestimmte Architekturen und/oder Rechensysteme beschränkt und kann von jeder Architektur und/oder jedem Rechensystem für ähnliche Zwecke implementiert werden, sofern dies hierin nicht ausdrücklich angegeben ist. Beispielsweise können verschiedene Architekturen, die beispielsweise mehrere Chips und/oder Baugruppen mit integrierten Schaltungen (IC) und/oder verschiedene Rechenvorrichtungen, kommerzielle elektronische Vorrichtungen wie Server und/oder Unterhaltungselektronik-Vorrichtungen (CE-Vorrichtungen) verwenden, wie etwa Computer, Beistellkästen, Smartphones, Fernseher usw. die hier beschriebenen Techniken und/oder Anordnungen implementieren. Obwohl die folgende Beschreibung zahlreiche spezifische Einzelheiten wie logische Implementierungen, Typen und Wechselbeziehungen von Systemkomponenten, logische Partitionierungs-/Integrationsentscheidungen usw. enthalten kann, kann der beanspruchte Gegenstand ohne solche spezifischen Einzelheiten praktiziert werden. In anderen Fällen kann einiges an Material, wie beispielsweise Steuerstrukturen und vollständige Software-Befehlssequenzen, möglicherweise nicht im Einzelnen gezeigt sein, um das hierin offenbarte Material nicht zu verunklaren.
  • Das hierin offenbarte Material kann in Hardware, Firmware, Software oder einer beliebigen Kombination davon implementiert werden. Das hier offenbarte Material kann auch als Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind und von einem oder mehreren Prozessoren gelesen und ausgeführt werden können. Ein maschinenlesbares Medium kann ein beliebiges Medium und/oder einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer von einer Maschine (z. B. einer Rechenvorrichtung) lesbaren Form umfassen. Beispielsweise kann ein maschinenlesbares Medium Nur-Lese-Speicher (ROM); Direktzugriffsspeicher (RAM); Magnetplattenspeichermedien; optische Speichermedien; Flash-Speichervorrichtungen; elektrische, optische, akustische oder andere Formen von sich ausbreitenden Signalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.) und andere umfassen. In einer weiteren Form kann ein nichttransitorischer Artikel wie beispielsweise ein nicht nichttransitorisches computerlesbares Medium mit einem der oben genannten Beispiele oder anderen Beispielen verwendet werden, nur dass an sich kein transitorisches Signal enthalten ist. Diejenigen Elemente außer Signalen an sich, die Daten vorübergehend auf „transitorischer“ Weise halten können, wie z. B. RAM und so weiter.
  • Verweise in der Beschreibung auf „eine Implementierung“, „eine beispielhafte Implementierung“ usw. geben an, dass die beschriebene Implementierung ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft aufweisen kann, aber nicht unbedingt jede Implementierung enthalten das bestimmte Merkmal, die bestimmte Struktur oder die bestimmte Eigenschaft aufweisen muss. Darüber hinaus beziehen sich solche Ausdrücke nicht unbedingt auf dieselbe Implementierung. Wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft im Zusammenhang mit einer Implementierung beschrieben wird, wird ferner angenommen, dass es innerhalb der Kenntnisse von Fachleuten liegt, ein solches Merkmal, eine solche Struktur oder eine solche Eigenschaft in Verbindung mit anderen Implementierungen zu beeinflussen, unabhängig davon, ob dies hier explizit beschrieben ist oder nicht.
  • Systeme, Artikel und Verfahren werden nachstehend im Zusammenhang mit dem Videocodieren mit Intra-Block-Kopieren gemäß mindestens einer der hierin implementierten Implementierungen beschrieben.
  • Wie erwähnt haben eine Reihe von Videocodierungsstandards wie beispielsweise hocheffiziente Videocodierung (HEVC) spezielle Operationen, um die Bildschirminhaltscodierung (SCC) anstelle von oder zusätzlich zu aufgezeichnetem Video zu handhaben. Insbesondere bietet eine HEVC-SCC-Erweiterung zusätzliche Intra-Vorhersagemodi in Form einer Intra-Block-Kopiertechnik (IBC-Technik), die eine hashbasierte Intra-Suche verwendet, um zuvor codierte Blöcke in einem Frame mit einem aktuellen Block abzugleichen, der in demselben Frame rekonstruiert wird.
  • Insbesondere kopiert ein IBC-Modus zuvor rekonstruierte ganze Blöcke auf einem Frame an andere Orte in demselben Frame. Es wurde festgestellt, dass dieses Blockkopieren aufgrund der typischerweise flacheren oder gleichmäßigeren Natur des synthetischen Bildschirminhalts ausreichend ist. Die Auswahl des Blocks zum Kopieren ähnelt der Video-Inter-Vorhersage, außer dass hier eine Suche nach einem übereinstimmenden Block und dem resultierenden Blockbewegungsvektor auf demselben Frame bestimmt wird. Außerdem sollte die Übereinstimmung genauer sein als die mit der Video-Inter-Vorhersage gelieferte, bei der Blöcke verglichen werden können, indem der kleinste Durchschnitt oder die Summe der Betragsdifferenzen (SADs) zwischen den Pixeldaten auf einem Block eines Referenzframes und den ursprünglichen Pixeldaten eines aktuellen Blocks, der rekonstruiert wird, bestimmt wird. Eine solche Gruppierung von Pixelwerten zur Darstellung eines einzelnen Blocks ist für synthetische Bilder häufig unzureichend, da sie zu ungenau ist, wenn viele synthetische Objekte in dem Bildschirminhalt, z. B. ein kleiner Teil eines einzelnen Buchstabens, wenn Text auf dem Bild angezeigt wird, kleiner sein können als ein einzelner Block.
  • Um dieses Ungenauigkeitsproblem zu überwinden, führt IBC eine hashbasierte Suche durch, bei der jeder Block eines Bildes mit einem Hash versehen wird, da sich ein Hash in Abhängigkeit von kleinen Änderungen der Pixelbilddaten in einem Block ändern kann. Der Hash oder insbesondere ein Hash-Code oder -wert ist eine übliche Methode, um eine Folge von Daten in einen Wert fester Größe zu konvertieren. Es gibt verschiedene Möglichkeiten, einen Hash-Code zu berechnen, z. B. mithilfe eines Rechners für zyklische Redundanzprüfung (CRC-Rechners) oder einer XOR-Operation an einzelnen Doppelwörtern (DWORDs) einer Eingabedatenfolge, um nur einige Beispiele zu nennen. Es können auch kompliziertere Algorithmen wie MD5 verwendet werden.
  • Da ein Pixelblock verwendet werden kann, um einen Hash-Code zu erzeugen, der für diese Folge von Pixeln in dem Block eindeutig ist, garantiert der Hash-Algorithmus, dass unterschiedliche Eingabedaten unterschiedliche Hash-Codes erzeugen, so dass ein Vergleich zwischen zwei aus zwei Datenfolgen erzeugten Hash-Codes angibt, ob die beiden Datenfolgen genau gleich sind oder nicht. Sobald die Hashes erzeugt sind, wird ein Referenz-Hash eines zuvor codierten Referenzblocks auf dem Frame mit einem aktuellen Quellblock-Hash eines aktuellen Blocks verglichen, der auf demselben Frame rekonstruiert wird, um zu bestimmen, ob die beiden Blöcke genau übereinstimmen. Wenn die Hashes gleich sind, werden die Bilddaten des Referenzblocks als rekonstruierte Daten des aktuellen Quellblocks verwendet.
  • Unter Bezugnahme auf 1 treten mehr Schwierigkeiten beim Ausgleich zwischen Leistungsfähigkeit und Qualität auf, da häufig große Rechenlasten erforderlich sind, um die hashbasierte Suche zu implementieren. Insbesondere werden Video-Frames häufig in mehrere alternative quadratische oder rechteckige Vorhersageblöcke mit unterschiedlichen Größen für denselben Bereich eines Frames und während der Inter- und Intra-Vorhersagecodierung unterteilt. Jeder Block unterschiedlicher Größe ist ein alternativer Vorhersagekandidat, der mit anderen Vorhersagekandidaten mit unterschiedlichen Blockgrößen desselben Pixelbereichs auf einem Bild verglichen wird. Beispielsweise, und für einen Bereich 100 von Pixeln 102 auf einem Bild 104, kann der Pixelbereich 100 in 4×4-Pixelblöcke unterteilt werden, einschließlich eines 4×4-Pixelblocks 106, der sich von einem Ankerpixelort [0,0] 108, der der Pixelort in der oberen linken Ecke von Block 106 ist, nach unten und rechts erstreckt. Ein Hash-Code H4x4(0,0) 110 kann basierend auf den sechzehn Pixelwerten in dem 4x4-Block 106 berechnet werden. Ebenso kann ein Hash-Code H4×4(1,0) 112 basierend auf den sechzehn Pixelwerten in einem 4×4-Block 114 berechnet werden, der sich aus dem Ankerpixelort [1,0] 115 erstreckt, wobei der Block 114 gegenüber Block 106 um eine Pixelspalte nach rechts verschoben ist. Dies wird wiederholt, so dass jeder Pixelort 102 als Blockankerpixelort zum Erzeugen eines Hash-Codes für die 4×4-Pixel, die sich von dem Ankerpixelort nach rechts und unten erstrecken, fungiert. Diese Anordnung liefert einen Hash-Code für alle möglichen überlappenden 4x4-Blockorte innerhalb eines Bildbereichs oder für das gesamte Bild. Dies wird häufig sowohl für den Referenz-Frame (die Referenz-Frames) als auch für den aktuellen Quell-Frame, der gerade rekonstruiert wird, wiederholt. Es ist zu beachten, dass die Begriffe Bild, Frame und Abbildung hierin austauschbar verwendet werden können, sofern der Kontext nichts anderes angibt.
  • Dann kann als weitere Option, die häufig von Codierervorhersageschemata verwendet wird, dieselbe Hash-Berechnung für jede der verschiedenen Blockgrößen durchgeführt werden, die zum Bilden von Intra-Vorhersagekandidaten betrachtet werden. So kann beispielsweise als weiterer Intra-Mode-Kandidat der Pixelbereich 100 in 4×8-Vorhersageblöcke unterteilt werden und für einen 4×8-Pixelblock 116, der ab dem Ankerpixelort in der oberen linken Ecke [0,0] 108 beginnt, kann wiederum ein Hash-Code H4×8(0,0) 118 basierend auf den 32 Pixelwerten in dem 4×8-Block 116 berechnet werden. Ebenso kann ein Hash-Code H4×8(0,1) 122 auch basierend auf den 32 Pixelwerten in einem 4×8-Block 120 berechnet werden, der sich aus einem Ankerpixelort [0,1] (124), der eine Zeile von dem Ankerpixelort 108 des Blocks 116 entfernt ist, erstreckt. Als weiteres Beispiel können auch 8×4-Blöcke 126 wie die anderen Blöcke bereitgestellt werden. Dies kann auch wiederholt werden, wobei jedes Pixel 102 als Ankerpixel fungiert, um einen Pixelblock zu definieren, der zum Berechnen eines einzelnen Hash-Codes verwendet werden soll. Dies könnte für alle möglichen verfügbaren Intra-Vorhersage-Blockgrößen wie 4x4, 4x8, 8x4, 8x8, 8x16, 16x8, 16x16 usw. wiederholt werden, normalerweise in Schritten von 4 oder 8 Pixeln in Blockdimensionen und bis zu 64x64 Codierungsbaumeinheiten (CTUs), beispielsweise für HEVC. Um die Hash-Suchen für all diese Alternativen bereitzustellen, werden häufig mehrere Puffer verwendet, um alle verfügbaren Blockgrößen und -formen zu unterstützen. Somit kann jede Kombination aus Blockgröße und -form (auch als Vorhersageeinheitsgröße (PU-Größe) bezeichnet) einen eigenen Puffer (oder Speicherort) haben und jeder Puffer kann einen berechneten Hash-Code für jeden Ankerpixelort für diese bestimmte Kombination aus Blockgröße und -form speichern. Wie erwähnt wird dieser Prozess häufig für jeden Frame ausgeführt, der alternative Intra-Vorhersagekandidaten sowohl für die Referenz-Frames als auch für den aktuellen Frame, der rekonstruiert wird, haben soll.
  • Nachdem die Frames in Blöcke unterteilt und die Hashes erhalten wurden und damit der Codierer den besten alternativen Codierungsmodus aus den verschiedenen Kandidaten für Blockform und -größe auswählen kann, unterstützt der Codierer häufig sowohl die hashbasierte Intra-Block-Kopier-Suche als auch alternativ eine normale Bewegungssuche. Eine Bewegungssuche kann beispielsweise einen SAD-Vergleich ähnlich der Inter-Vorhersage anstelle eines Vergleich von Hashes verwenden. Der Hash-Wert für verschiedene Kandidaten für Blockform und -größe und jeder Suchpunkt werden häufig vor dem IBC-Suchprozess zum Finden übereinstimmender Blöcke erzeugt. Das Ausführen all dieser Operationen erfordert eine sehr große Menge an Speicherkapazität, Speichertransaktionen und Zeit, um die Speicherung aller Blockalternativen durchzuführen.
  • Bei einer herkömmliche Form kann eine separate Hash-Tabelle für jede unterschiedliche Blockgröße bereitgestellt werden. Für jeden aktuellen Quellblock des aktuellen Frames, der vorhergesagt werden soll, werden die unterschiedlichen alternativen Vorhersageeinheits-Hash-Werte (PU-Hash-Werte) des aktuellen Blocks berechnet und geprüft, um abhängig von der Blockgröße einen entsprechenden Eintrag in ihren jeweiligen Hash-Tabellen zu finden. Wenn es eine Übereinstimmung gibt, wird die Intra-Block-Kopie häufig als Intra-Modus-Kandidat für den aktuellen Block verwendet. Wenn keine Übereinstimmung vorliegt, werden andere Codierungsmodi verwendet. Dieser Ansatz erfordert zusätzlich zu der großen Menge an Speicherpuffern und der Bandbreite, die zum Speichern und Zugreifen auf die Hash-Codes erforderlich sind, einen großen Verarbeitungsaufwand und damit eine hohe Leistungsaufnahme, um alternative Hash-Codes für verschiedene Blockgrößen zu berechnen.
  • Obwohl diese herkömmliche Softwaretechnik tendenziell gründlicher ist, da sie alle Vorhersageblockgrößen separat prüft, findet das herkömmliche IBC keinen angemessenen Ausgleich zwischen der Leistungsfähigkeit und der Qualität, da nicht mehrere Blöcke verfolgt und identifiziert werden, die flache, einheitliche Bereiche bilden, in denen Hashes in den Hash-Tabellen dupliziert werden können, und andere Einstellungen könnten verfeinert werden, wenn ein flacher, einheitlicher Bereich in dem Bild erkannt wird. Solche flachen, einheitlichen Bereiche haben im Wesentlichen die gleichen Bilddatenwerte, beispielsweise die gleichen Farb- und Helligkeitswerte, oder zumindest werden sowohl die Farb- als auch die Luminanzwerte als ausreichend ähnlich angesehen, dass das menschliche Auge keinen signifikanten Unterschied bemerkt und lediglich eine einzige Farbe und/oder Helligkeit sieht. Im Folgenden wird dies als einheitlicher Bereich bezeichnet.
  • Schließlich kann das herkömmliche IBC nicht effektiv für ein von einer natürlichen Kamera aufgenommenes Video verwendet werden, da das Rauschen und die kleinen, auf Pixelniveau abweichenden Gradienten, die für das menschliche Auge oft unbedeutend und nicht wahrnehmbar sind, Übereinstimmungen in Hash-Vergleichen verhindern können, wenn Quell- und Referenzblöcke Bilddaten aufweisen, die für die Intra-Vorhersage ausreichend ähnlich sind. Daher kann ein Codierer die Effizienz nicht nutzen, die durch Hash-Vergleiche erzielt wird, wenn natürliches Video codiert wird.
  • Um diese Probleme zu lösen, berechnen das offenbarte Verfahren und System Referenz-Hash-Codes für Basisblöcke mit einer Basisblockgröße und eines aktuellen Frames, der rekonstruiert wird. Die Basisblockgröße kann die kleinste Blockgröße oder eine andere ausgewählte Größe sein, die für Vorhersagemodus-Kandidaten während der Codierung verfügbar ist, z. B. 4×4- oder 8x8-Blöcke, anstatt Hash-Codes für alle alternativen Blockgrößen berechnen zu lassen. Die Basisblockgröße kann nicht die größte für den Codierer verfügbare Vorhersageblockgröße sein. Die Berechnung von Hash-Codes wird sowohl für Referenzbasisblöcke, die einen Referenz-Frame von Originalbilddaten auf dem aktuellen Frame bilden, als auch für Quellbasisblöcke zum Vergleich durchgeführt.
  • Insbesondere bestimmt das Verfahren, welche Quellbasisblöcke einen aktuellen Quellblock, der auf dem aktuellen Frame rekonstruiert wird, bilden oder in diesen passen. Die Quellbasis-Hash-Codes, die den Quellbasisblöcken zugeordnet sind, die den aktuellen Block bilden, werden mit den Referenzbasis-Hash-Codes verglichen, um zu bestimmen, eine Übereinstimmung vorliegt. Dieser Basisblock-Hash-Code-Abgleich kann auf verschiedene Arten durchgeführt werden. Bei einer Form können die Referenzbasis-Hash-Codes in einer Liste, Tabelle oder Bibliothek gespeichert werden, während die Quellbasis-Hash-Codes nach Bedarf im laufenden Betrieb berechnet werden. Bei einem Ansatz werden die Quellbasis-Hash-Codes, die den Quellbasisblöcken zugeordnet sind, von denen erkannt wird, dass sie in einen aktuellen Block passen, der rekonstruiert wird, in der Referenztabelle oder -liste nachgeschlagen, um übereinstimmende Hash-Codes und damit übereinstimmende Referenzbasisblöcke zu finden. Dies wird hier als Suchoption mit direktem Nachschlagen bezeichnet. Stattdessen werden bei einem alternativen Verkettungsansatz die Quellbasis-Hash-Codes zu einem einzelnen aktuellen Hash-Code oder Quell-Hash-Code für den aktuellen Block verkettet und mit einem Referenz-Hash-Code abgeglichen, der durch Verketten der Referenzbasis-Hash-Codes aus Referenzbasisblöcken gebildet wird, die zusammen die Größe des aktuellen Blocks bilden. In diesem Fall schlägt das System die Referenzbasisblockorte der Basisblöcke, die in den aktuellen Block passen, in der Referenztabelle nach, um die Referenz-Hash-Codes dieser Referenzbasisblöcke zu finden. Die verketteten Quell- und Referenz-Hashes werden dann zum Abgleichen verglichen. Das Verfahren kann auch Vorhersagen für Vorhersageblöcke innerhalb des aktuellen Blocks entweder durch die Suchoption mit direktem Nachschlagen oder durch Verketten der Quell- und Referenzbasis-Hash-Codes erzeugen, um die Vorhersageblöcke wie bei dem gesamten aktuellen Block zu bilden oder einzupassen.
  • Mit dieser Anordnung kann das Hash-Suchverfahren entweder bestimmen, ob die Bilddaten des gesamten aktuellen Blocks mit Bilddaten der Referenzbasisblöcke abgeglichen werden können, oder ob die Bilddaten irgendwelcher kleinerer verfügbarer Vorhersageblockgrößen innerhalb des aktuellen Block mit den Bilddaten eines oder mehrerer Basisreferenzblöcke übereinstimmen. Dies vermeidet die zahlreichen Hash-Code-Berechnungen für alle alternativen Blockgrößen, wodurch die Rechenlast und die Leistungsaufnahme für die hashbasierte Suche verringert werden sowie die für die hashbasierten Suchen erforderliche(n) Speicherkapazität und Speichertransaktionen verringert werden. Die Bilddaten des einen oder der mehreren Referenzblöcke mit Hash-Übereinstimmung können dann zu Bilddaten eines Intra-Modus-Vorhersagekandidaten (oder nur einer Vorhersage) oder eines der Intra-Modus-Kandidaten für den aktuellen Block oder Vorhersageblock innerhalb des aktuellen Blocks, der rekonstruiert wird, werden. Bei alternativen Formen könnten der eine oder die mehreren übereinstimmenden Referenzblöcke als Startpunkt für eine IBC-Normalbewegungssuche verwendet werden. Die Reduzierung redundanter Hash-Bereiche durch die Verwendung von Hashes auf Basisblockgrößenebene und alternativ der hierarchische Blockabgleich ohne Hash bei Bedarf reduzieren die Speicherbandbreite und den Speicherbedarf um mindestens 25 %. Es werden auch die Hardware-Anforderungen zum Erzeugen der Hashes reduziert bilden oder in diesen passen, da ein Hash-Generator, sei es durch dedizierte Hardware oder CPUs, für eine einzelne Hash-Größe verglichen mit einem Generator für mehrere Hash-Größen, der den Prozess aufgrund zusätzlicher Berechnungen zum Bilden von Hashes für größere Blöcke verlangsamen würde, sehr effizient sein kann. Andernfalls würden parallele Generatoren für unterschiedliche Größen benötigt, um Verzögerungen zu vermeiden.
  • Zudem kann das offenbarte Verfahren eine Zählung von Nachbarbasisblöcken pflegen, die den gleichen Hash-Code wie ein aktueller Block, der den Nachbarn benachbart ist, haben, und daher das Ausmaß einheitlicher Bereiche auf dem zu rekonstruierenden Bild angeben. Wenn festgestellt wird, dass die Hash-Codes gleich sind, kann eine Bereichs-ID-Zählung inkrementiert werden. Die Bereichs-ID und die Zählung des gleichen Hash-Codes können in einer separaten Tabelle oder in der Referenz-Hash-Tabelle gepflegt werden. Die Codierung kann dann die Kenntnis eines solchen einheitlichen Bereichs nutzen, um wie folgt die Qualität zu erhöhen und Berechnungen und Verzögerungen auf viele Arten zu reduzieren.
  • Erstens kann solchen einheitlichen Quellblöcken mit demselben Hash-Code ein niedrigerer QP zugewiesen werden, wenn der Codierer feststellt, dass der Quellblock Teil eines gemeinsamen flachen Bereichs mit benachbarten Basisblöcken auf dem aktuellen Frame ist und/oder Teil eines gemeinsamen einheitlichen Bereichs aus einem vorherigen Frame ist. Durch Verringern des QP wird die Qualität (oder die Verzerrung) der Quellblöcke erhöht, obwohl die Anzahl der Bits steigt (die Bitrate sinkt) und die Berechnungen für jeden dieser einheitlichen Blöcke steigen. Der Codierer kann jedoch solche zusätzlichen Bits aufgrund einer erhöhten Kompression durch Kopieren derselben Bilddaten aus den Quellblöcken, die den einheitlichen Bereich bilden, sowie Blöcken in zukünftigen Frames, die sich auf den flachen einheitlichen Bereich beziehen, zur Rekonstruktion kompensieren.
  • Zweitens kann der Codierer mit Kenntnis der einheitlichen Bereiche die Typen von Vorhersagemodus-Kandidaten ändern, die für die Intra-Vorhersage verwendet werden sollen, indem er in einen Modus wechselt, der zu einer höheren Ratenverzerrung führt, da das Erhöhen der Verzerrung auf einer einheitlichen Bereich eines Bildes nicht bemerkbar sein sollte. Andernfalls könnten ineffiziente, langsame Vorhersagemodi bei einem einheitlichen Bereich vollständig deaktiviert werden, um die Leistungsfähigkeit zu erhöhen.
  • Drittens können die Nachbarpixelbilddaten der Nachbarbasisblöcke in einem Vorhersageblock oder aktuellen Block verwendet werden, um eine Vorhersage zu bilden, und wenn Intra-Block-Kopieren an einem Block durchgeführt wird, kann eine Intra-Vorhersagepipeline stocken, während die Nachbarpixel werden abgerufen, um die Rekonstruktion des Quellblocks tatsächlich durchzuführen und einen Rest für den Quellblock bereitzustellen. In diesem Fall können dann, wenn der Codierer weiß, dass Daten eines Blocks eines solchen einheitlichen Bereichs mehrmals kopiert werden, die Nachbarpixelwerte für einen schnelleren Zugriff gespeichert werden, um eine Verlangsamung der Pipeline zu vermeiden. Andernfalls können die Nachbarpixel auch vorab abgerufen werden, sobald ein Hash in einen einheitlichen Bereich kopiert wird, wenn klar ist, dass die auf Hash-Code basierende Suche in einheitlichen Bereichen verwendet wird. Dies ist eine Leistungsverbesserung, die den Prozess beschleunigt, da normalerweise eine endgültige Modusentscheidung getroffen würde, bevor die Nachbarpixel abgerufen werden, um den Quellblock zu rekonstruieren, um beispielsweise einen Rest bereitzustellen.
  • Viertens kann eine schnelle Änderung von Bilddaten in dem detektierten flachen, einheitlichen Bereich eine Szenenänderung angeben und der Codierer kann dazu ausgelegt sein, entsprechend zu agieren.
  • Als weiterer Aspekt kann das vorliegend offenbarte Verfahren und System anpassbar sein, um auch auf natürliches (oder von der Kamera aufgenommenes) Video angewendet zu werden. Dies wird erreicht, indem die Bilddaten, die zum Erzeugen der Hash-Codes verwendet werden, entrauscht, heruntergetastet und verkleinert werden. Das Entrauschen der Bilddaten kann zusätzlich zu dem Entrauschen erfolgen, das während der Videocodierungsvorverarbeitung durchgeführt wird. Das Heruntertasten der Bilddaten der Blöcke umfasst hier, ähnlich wie bei einer Rundungsoperation, ein Beschneiden der Bilddaten durch Verwerfen von niedrigstwertigen Bits (LSBs), wodurch Rauschen und kleine unbedeutende Gradienten in den Blöcken des Bildes weiter entfernt werden. Das Verkleinern bezieht sich auf die Verwendung einer Verkleinerungstechnik (z. B. Pixel in Intervallen) oder einer Kombinationstechnik (z. B. Mittelwertbildung) in einem Pixelblock, anstatt die Bilddaten aller Pixel in einem Block zu verwenden. Alle drei dieser Techniken erhöhen die Wahrscheinlichkeit, Hashes von Referenz- und Quellblöcken zu finden, die genau übereinstimmen, erheblich, wodurch mehr Übereinstimmungen für die Intra-Vorhersage gefunden werden, die mit dem sichtbaren Bildinhalt konsistent sind, wobei die Bilddaten für das menschliche Auge gleich erscheinen. Bei einem Ansatz können diese Techniken nur für die Hash-Suche angewendet werden und werden beim Erzeugen der Daten der Vorhersage selbst ignoriert werden, um einen Rest für den aktuellen Block oder Vorhersageblock zu bestimmen.
  • Die Anwendung der hashbasierten IBC-Suche auf natürliches Video bietet eine Reihe der oben genannten Vorteile, beispielsweise die Steigerung der Leistungsfähigkeit und Qualität und die Verringerung der Leistungsfähigkeit, aufgrund der Möglichkeit, bestimmte Suchen zu eliminieren und die Verwendung von Vorhersagemodi mit größeren Bitkosten zu vermeiden. Die Anwendung dieses IBC-Verfahrens auf natürliche Videos bietet auch die Möglichkeit, die Qualität zu erhöhen, indem beispielsweise der QP für einheitliche Blöcke verringert wird, und die Qualität kann verbessert werden, indem eine genauere Übereinstimmung als bei den anderen herkömmlichen natürlichen Vorhersagemodus-Suchen geliefert wird. Andernfalls kann ein Quellblock mit einem übereinstimmenden Hash-Code als Startpunkt für eine IBC-Bewegungssuche festgelegt werden.
  • Schließlich weisen das offenbarte System und die offenbarten Verfahren Leistungsverbesserungen auf, die in Abhängigkeit von der Hardware-Implementierung variieren. Beispielsweise können Hardware mit fester Funktion oder CPUs, die eine einzelne Hash-Größe erzeugen, im Vergleich zu den herkömmlichen Hash-Größenvariationen, die aufgrund des reduzierten Rechenaufwands verwendet werden, mit reduzierten Verzögerungen ausgeführt werden oder die Menge solcher Hardware kann aufgrund des Anstiegs der Suffizienz reduziert werden.
  • Unter Bezugnahme auf 2 führt ein beispielhaftes Videocodiersystem (oder Bildverarbeitungssystem oder Codierer) 200 die hierin offenbarten Verfahren zum Codieren von Bildschirminhalt durch und ist dazu ausgelegt, mindestens eine oder mehrere der hier beschriebenen Implementierungen einschließlich des Intra-Block-Kopierens durchzuführen. In verschiedenen Implementierungen kann das Videocodiersystem 200 dazu ausgelegt sein, eine Videocodierung durchzuführen und/oder Videocodecs gemäß einem oder mehreren Standards zu implementieren. Ferner kann das Videocodierungssystem 200 in verschiedenen Formen als Teil eines Bildprozessors, Videoprozessors und/oder Medienprozessors implementiert sein und eine Inter-Vorhersage, Intra-Vorhersage, Vorhersagecodierung und Restvorhersage durchführen. In verschiedenen Implementierungen kann das System 200 eine Videokomprimierung und -dekomprimierung durchführen und/oder Videocodecs gemäß einem oder mehreren Standards oder Spezifikationen implementieren, wie beispielsweise H.264 (MPEG-4), fortgeschrittene Videocodierung (AVC), VP8, H.265 (hocheffiziente Videocodierung oder HEVC), VP9, Allianz für offene Medien Version 1 (AV1) und andere. Obwohl das System 200 und/oder andere Systeme, Schemata oder Prozesse hierin beschrieben werden können, ist die vorliegende Offenbarung bei Erwähnung hierin nicht unbedingt immer auf einen bestimmten Videocodierungsstandard oder eine Spezifikation oder Erweiterungen davon beschränkt, mit Ausnahme der Bildschirminhaltscodierung.
  • Wie er hierin verwendet wird, kann sich der Begriff „Codierer“ auf einen Codierer und/oder einen Decodierer beziehen. In ähnlicher Weise kann sich der Begriff „Codierung“, wie er hierin verwendet wird, auf die Codierung über einen Codierer und/oder die Decodierung über einen Decodierer beziehen. Ein Codierer oder Decodierer kann Komponenten sowohl eines Codierers als auch eines Decodierers aufweisen. Ein Codierer kann eine Decodierschleife aufweisen, wie sie nachstehend beschrieben ist.
  • Beispielsweise kann das Videocodierungssystem 200 ein Codierer sein, bei dem aktuelle Videoinformationen in Form von Daten, die sich auf eine Folge von Video-Frames beziehen, zur Komprimierung empfangen werden können. Bei einer Form wird die Videosequenz aus Eingabe-Frames 202 aus synthetischem Bildschirminhalt wie etwa von oder für Geschäftsanwendungen wie Textverarbeitungsprogramme, Präsentationsprogramme oder Tabellenkalkulationen, Computer, Videospiele, Bilder der virtuellen Realität usw. gebildet. Bei anderen Formen können die Bilder aus einer Kombination von synthetischem Bildschirminhalt und von der natürlichen Kamera aufgenommenen Bildern gebildet werden. Bei noch einer anderen Form kann die Videosequenz nur ein von einer natürlichen Kamera aufgenommenes Video sein. Das System 200 kann jeden Frame in kleinere, besser handhabbare Einheiten unterteilen und dann die Frames vergleichen, um eine Vorhersage zu berechnen. Wenn eine Differenz oder ein Rest zwischen einem ursprünglichen Block und einer Vorhersage bestimmt wird, wird dieser resultierende Rest transformiert und quantisiert und dann entropiecodiert und in einem Bitstrom zusammen mit rekonstruierten Frames an Decodierer oder Speicher übertragen. Um diese Operationen auszuführen, kann das System 200 einen Eingabe-Frame 202 empfangen, der wie erwähnt aus anderen Computeranwendungen empfangen werden kann oder aus einer Kamera empfangen werden kann oder eine Mischung aus beiden. Die Eingabe-Frames können Frames sein, die zum Codieren ausreichend vorverarbeitet sind.
  • Das System 200 kann auch eine Vorhersage-Partitionseinheit 204, eine Subtraktionseinheit 206, eine Transformations-und-Quantisierereinheit 208, eine Steuerung 209 und einen Entropiecodierer 210 aufweisen. Die Steuerung 209 kann viele Codierungsaspekte verwalten, einschließlich zumindest des Einstellens des Quantisierungsparameters (QP), könnte aber auch ein Einstellen der Bitrate, der Ratenverzerrung oder der Szeneneigenschaften, der/des Vorhersage- und/oder Transformations-Partition oder -Blocks, der verfügbaren Vorhersagemodustypen und der besten Modusauswahlparameter umfassen, um nur einige Beispiele zu nennen.
  • Die Ausgabe des Quantisierers 208 kann an eine Decodierungs- oder Vorhersageschleife 216 geliefert werden, um die gleichen Referenzblöcke oder rekonstruierten Blöcke, Frames oder andere Einheiten zu erzeugen, die bei einem Decodierer wie dem Decodierer 300 erzeugt würden (3). Somit kann die Decodierungsschleife 216 eine Einheit für inverse Quantisierung und inverse Transformation 212, einen Addierer 214 und Rest- und Vorhersage-Assembler-Einheiten (nicht gezeigt) verwenden, um die Frames zu rekonstruieren. Qualitätsverbessernde schleifeninterne Filter 218 können dann verwendet werden, um die Frames zu überarbeiten. Ein rekonstruierter Schleifenbildpuffer 219 kann die rekonstruierten Frames halten, die als Inter-Vorhersage-Referenzframes verwendet werden sollen.
  • Der Codierer 200 weist auch ein Vorhersagemodul 220 auf, das eine Inter-Prädiktoreinheit 222 zum Durchführen einer Inter-Vorhersage einschließlich Bewegungsschätzung und Bewegungskompensation, eine Intra-Prädiktoreinheit 224 zum Durchführen der Intra-Vorhersage und eine Vorhersagemodus-Auswahleinheit 226 aufweist. Die Inter-Vorhersageeinheit 222 kann Bewegungsvorhersagemodi verwenden, die Bewegungsvektoren erzeugen, wie beispielsweise eine blockabgleichende hierarchische Bewegungsschätzung (HME), eine ganzzahlige Bewegungsschätzung (IME), eine bruchzahlige Bewegungsschätzung (FME), Nullbewegungsvektoren (ZMVs), räumliche Nachbarblockabhängigkeiten zum Erhalten oder Erzeugen von Bewegungsvektoren und so weiter.
  • Die Intra-Prädiktoreinheit 224 hat eine Intra-Block-Kopiereinheit (IBC-Einheit) 230 und eine Nicht-IBC-Einheit 228, die die nachstehend genauer beschriebene Intra-Vorhersage-Fähigkeit bereitstellt. Sowohl die Inter-Vorhersageeinheit 222 als auch die Intra-Vorhersageeinheit 224 liefern Vorhersagen für den Vorhersagemodus-Wähler 226, der den besten Vorhersagemodus (einschließlich Intra-Modi) für einen bestimmten Block typischerweise basierend auf Bitkosten und anderen Faktoren auswählt. Der Vorhersagemodus-Wähler 226 kann einen Intra-Vorhersage- und/oder Inter-Vorhersage-Modus auswählen, wenn vielleicht jeweils mehrere solcher Modi verfügbar sind. Die Vorhersageausgabe des Wählers 226 in Form eines Vorhersageblocks wird dann sowohl an die Subtraktionseinheit 206 zum Erzeugen eines Rests als auch in der Decodierungsschleife an den Addierer 214 geliefert, um die Vorhersage zu dem Rest aus der inversen Transformation zu addieren, um einen Frame zu rekonstruieren.
  • Insbesondere können jetzt die Partitionseinheit 204 oder andere nicht gezeigte Anfangseinheiten Frames platzieren, um die Frames zu codieren und ihnen Klassifikationen zuzuweisen, wie z. B. I-Frame, B-Frame, P-Frame usw., wobei für I-Frames Intra-Vorhersage erfolgt. Andernfalls können Frames in Slices (z. B. ein I-Slice) unterteilt werden, wobei jedes Slice anders vorhergesagt werden kann. Daher wird für die HEVC-Codierung eines gesamten I-Frames oder I-Slices eine räumliche Vorhersage oder Intra-Vorhersage verwendet, in einer Form nur aus Daten in dem Frame selbst.
  • In verschiedenen Implementierungen empfängt die IBC-Einheit 230 entweder Partitionen aus der Partitionseinheit 204 oder kann Operationen zum Bilden oder Empfangen ihrer eigenen Partitionsdefinitionen zum Ausführen des IBC haben. Insbesondere dann, wenn ein HEVC-Standard verwendet wird, kann die Vorhersagepartitionseinheit 204 die Frames in Vorhersageeinheiten sowohl für die Intra-Vorhersage, IBC oder nicht, als auch für die Inter-Vorhersage unterteilen. Dies kann die Verwendung von Codiereinheiten (CU) oder großen Codiereinheiten (LCU) umfassen. Für diesen Standard kann ein aktueller Frame zur Kompression durch einen Codierungspartitionierer durch Unterteilen in ein oder mehrere Slices von Codierungsbaumblöcken (z. B. 64×64 Luma-Abtastwerte mit entsprechenden Chroma-Abtastwerten) partitioniert werden. Jeder Codierungsbaumblock kann auch in Codierungseinheiten (CU) in einem Quad-Baum-Aufteilungs-Schema unterteilt werden. Ferner kann jede Blatt-CU auf dem Quad-Baum entweder erneut in vier CUs aufgeteilt oder zur bewegungskompensierten Vorhersage in Partitionseinheiten (PUs) unterteilt werden. In verschiedenen Implementierungen gemäß der vorliegenden Offenbarung können CUs verschiedene Größen aufweisen, einschließlich, aber nicht beschränkt auf 64×64, 32×32, 26×26 und 8×8, während für eine 2N×2N-CU auch die entsprechenden PUs verschiedene Größen haben können, einschließlich, aber nicht beschränkt auf 2Nx2N, 2NxN, Nx2N, NxN, 2Nx0,5N, 2Nx1,5N, 0,5Nx2N und 2,5Nx2N. In einigen Formen ist der kleinste verfügbare Vorhersageblock ein 4×4- oder 8×8-Block, was hier als Basisblockgröße bezeichnet wird. Es sollte jedoch beachtet werden, dass das Vorstehende nur beispielhafte Formen und Größen von CU-Partitionen und PU-Partitionen sind, wobei die vorliegende Offenbarung nicht auf bestimmte Formen und/oder Größen von CU-Partitionen und PU-Partitionen beschränkt ist. Es ist zu beachten, dass wie unten beschrieben mehrere alternative Partitionen für denselben Bildbereich bereitgestellt werden können.
  • Für die VP9-Codierung kann ein Frame in Kacheln unterteilt werden, die große Abschnitte des Frames sind, die dann in 64×64-Pixel-Superblöcke unterteilt werden. Die Superblöcke können in kleinere Blöcke unterteilt werden, typischerweise 24×24 oder 8×8 für Vorhersageblockgrößen, können jedoch so klein wie 4×4 sein.
  • Der kleinste Block wird, wenn er als Basisblock verwendet wird, als die kleinste Partition oder Unterteilung zum Bilden eines Blocks angesehen, die als Option für einen bestimmten Codierer oder eine Intra-Vorhersageeinheit des Codierers verfügbar ist und durch den Codierer für das Intra-Block-Kopieren nicht weiter unterteilt wird. In der Regel sind dies 4x4-Pixel- oder 8x8-Pixel-Blöcke. Der Basisblock kann jedoch eine andere Größe als die kleinste sein, solange er nicht die größte Vorhersageblockgröße ist. So könnten Basisblöcke beispielsweise 16×16-Makroblöcke (16×16-MBs) oder andere rechteckige Größen sein, wenn größere Vorhersageblockgrößen existieren.
  • Um eine Intra-Vorhersage durchzuführen, kann die NON-IBC-Einheit 228 eine benachbarte horizontale, diagonale und/oder DC-Intra-Vorhersage liefern, um einige Beispiele zu nennen, und wird hier als „normale“ Intra-Vorhersage bezeichnet. Andererseits kann die IBC-Einheit 230 sowohl eine Bewegungssucheinheit 232 zum Liefern einer Bewegungssuche (oder einer normalen Suche) als auch Einheiten zum zusätzlichen oder alternativen Durchführen einer hashbasierten Suche aufweisen. Die IBC-Bewegungssuche kann Blockabgleichssuchen umfassen, die den für die Inter-Vorhersage durchgeführten ähnlich sind.
  • Um die hashbasierte Suche durchzuführen, kann die IBC-Einheit 230 eine Hash- (oder Hash-Code-) Erzeugungseinheit 234 aufweisen, um sowohl Referenz-Hash-Codes auf zuvor konstruierten Blöcken eines aktuellen Frames als auch Quell-Hash-Codes desselben aktuellen Frames zum Bereitstellen von Quell-Hash-Codes für einen aktuellen Block, der rekonstruiert wird, zu erzeugen. Die Hash-Erzeugungseinheit 234 kann auch Operationen zum Zählen und Verfolgen der Referenzblöcke mit denselben Bilddaten und damit demselben Hash-Code ausführen, um einheitliche Bereiche eines Bildes zu detektieren, wie es nachstehend beschrieben ist. Eine Tabellenerzeugungseinheit 236 kann eine Hash-Tabelle 242 erstellen, um die Referenz-Hash-Codes zu speichern. Eine Hash-Abgleichseinheit 238 vergleicht die Referenz-Hash-Codes in der Tabelle 242 mit den Quell-Hash-Codes. Eine Version der Originalbilddaten oder rekonstruierte Referenzblöcke können in einem Intra-Rekonstruktionspuffer 244 gespeichert werden, um als Referenz-Frame verwendet zu werden, um Hash-Codes davon mit einem aktuellen Block zu vergleichen, der rekonstruiert wird. Bei einer Form haben nur die Blöcke des aktuellen Frames, die bereits mit den rekonstruierten Bilddaten decodiert wurden, eine Version ihrer Originalbilddaten, die stattdessen in dem Puffer gespeichert sind, um einen Referenz-Frame für IBC zu bilden. Andernfalls könnten stattdessen die Originaldaten aller Blöcke des Frames gespeichert werden, um den Referenz-Frame zu bilden.
  • Optional kann auch eine Entrauschungs-, Heruntertaktungs-, Verkleinerungs-Einheit (DDD-Einheit) 240 bereitgestellt sein, um die hashbasierten Suchen auf natürliches (von der Kamera aufgenommenes) Video anzuwenden, wenn dies gewünscht ist. Diese Operationen können vor allen anderen IBC-Operationen angewendet werden und können als Intra-Vorverarbeitungsoperation angewendet werden. Einzelheiten zu den Operationen sind nachstehend angegeben.
  • Sobald festgestellt wird, dass die Hash-Codes übereinstimmen, liefert der Intra-Prädiktor 224 die Bilddaten des einen oder der mehreren Referenzblöcke mit den übereinstimmenden Hash-Codes als Vorhersagekandidaten der IBC-hashbasierten Suche an den Vorhersagemodus-Wähler 226. Bei einer Form werden zuvor rekonstruierte Bilddaten des Referenzblocks als Vorhersage bereitgestellt, aber alternativ könnten stattdessen die ursprünglichen Pixelbilddaten des Referenzblocks als Vorhersage bereitgestellt werden. Jede Auswahl kann unabhängig von der Art der Bilddaten, die zum Abgleichen der Hashes verwendet wurden, verwendet werden.
  • Wenn die IBC-Intra-Vorhersage als der korrekte Modus für einen Vorhersageblock ausgewählt wird, kann der vorhergesagte Block dann an dem Subtrahierer 206 von dem aktuellen Block der Originalbilddaten subtrahiert werden und der resultierende Rest kann in einen oder mehrere Transformationsblöcke (TUs) aufgeteilt werden, so dass die Transformations-/Quantisierereinheit 208 die unterteilten Restdaten beispielsweise unter Verwendung einer diskreten Cosinustransformation (DCT) in Transformationskoeffizienten transformieren kann. Unter Verwendung des von dem Controller 209 festgelegten Quantisierungsparameters (QP) verwendet der Quantisierer 208 dann eine verlustbehaftete Neuabtastung oder Quantisierung der Koeffizienten. Die Frames und Reste können zusammen mit Unterstützungs- oder Kontextdaten wie IBC-Intra-Blockgröße und Intra-Bewegungsvektoren usw. von der Einheit 210 entropiecodiert und an Decodierer übertragen werden.
  • In einigen Beispielen kann das Videocodiersystem 200 zusätzliche Elemente aufweisen, die in 2 der Klarheit halber nicht gezeigt wurden. Beispielsweise kann das Videocodiersystem 200 einen Prozessor, einen Hochfrequenz-Sendeempfänger (HF-Sendeempfänger), einen Splitter und/oder Multiplexer, eine Anzeige und/oder Antenne aufweisen. Ferner kann das Videocodiersystem 200 zusätzliche Elemente wie etwa einen Lautsprecher, ein Mikrofon, einen Beschleunigungsmesser, einen Speicher, einen Router, eine Netzschnittstellenlogik usw. aufweisen. Einige dieser Komponenten sind in anderen hier beschriebenen Implementierungen gezeigt.
  • Unter Bezugnahme auf 3 kann ein System 300 einen Decodierer aufweisen oder dieser sein und kann codierte Videodaten in Form eines Bitstroms empfangen, der in einem Beispiel Bilddaten (Chroma- und Luma-Pixelwerte) sowie Kontextdaten einschließlich Reste in der Form von quantisierten Transformationskoeffizienten und die Identität von Referenzblöcken einschließlich mindestens der Größe der Referenzblöcke sowie Intra-Bewegungsvektoren für die Referenzblöcke der IBC-hashbasierten Suche aufweist. Der Kontext kann auch Vorhersagemodi für einzelne Blöcke anderer Partitionen wie Slices, Inter-Vorhersage-Bewegungsvektoren, Partitionen, Quantisierungsparameter, Filterinformationen usw. umfassen. Das System 300 kann den Bitstrom mit einem Entropiedecodiermodul 302 verarbeiten, um die quantisierten Restkoeffizienten sowie die Kontextdaten zu extrahieren. Das System 300 kann dann ein Umkehr-Quantisierermodul 304 und ein Umkehr-Transformationsmodul 306 verwenden, um die verbleibenden Pixeldaten zu rekonstruieren.
  • Das System 300 kann dann einen Addierer 308 (zusammen mit nicht gezeigten Assemblern) verwenden, um den Rest zu einem vorhergesagten Block zu addieren. Das System 300 kann die resultierenden Daten auch unter Verwendung einer Decodiertechnik decodieren, die in Abhängigkeit von dem in der Syntax des Bitstroms angegebenen Codierungsmodus und entweder eines ersten Pfads, der ein Intra-Prädiktormodul 316 einer Vorhersageeinheit 312 umfasst, oder eines zweiten Pfads, der ein Inter-Vorhersage-Decodierpfad mit einem oder mehreren schleifeninternen Filtern 310 ist, verwendet wird. Das Intra-Prädiktormodul 316 führt eine Intra-Vorhersage einschließlich des IBC durch, indem Referenzblockgrößen und die aus dem Bitstrom extrahierten und zuvor an dem Codierer erstellten Intra-Bewegungsvektoren verwendet werden. Bei einem Ansatz werden Hash-Codes nicht an dem Decodierer empfangen oder erzeugt, da sie nicht benötigt werden. Ein bewegungskompensierter Prädiktor 314 verwendet rekonstruierte Frames sowie Inter-Vorhersage-Bewegungsvektoren aus dem Bitstrom, um einen vorhergesagten Block zu rekonstruieren.
  • Der Vorhersagemodus-Wähler 318 legt den richtigen Vorhersagemodus für jeden Block wie erwähnt fest, wobei der Vorhersagemodus aus dem komprimierten Bitstrom extrahiert und dekomprimiert werden kann. Ein PU-Assembler (nicht gezeigt) kann an dem Ausgang des Wählers 318 bereitgestellt sein, bevor die Blöcke an den Addierer 308 geliefert werden.
  • Die Funktionalität der hier beschriebenen Module für die Systeme 200 und 300, mit Ausnahme der Einheiten, die sich beispielsweise auf die hashbasierten Suchen 234 bis 244 beziehen und hier ausführlich beschrieben sind, ist im Stand der Technik wohlbekannt und wird hier nicht genauer beschrieben.
  • Unter Bezugnahme auf 4 ist ein beispielhafter Prozess 400 gemäß mindestens einigen Implementierungen der vorliegenden Offenbarung angeordnet. Im Allgemeinen kann der Prozess 400 ein computerimplementiertes Verfahren zur Videocodierung mit Intra-Block-Kopieren gemäß mindestens einer der hierin implementierten Implementierungen bereitstellen. In der dargestellten Implementierung kann der Prozess 400 eine oder mehrere Operationen, Funktionen oder Aktionen umfassen, wie sie durch eine oder mehrere der Operationen 402 bis 410 dargestellt sind, die geradzahlig nummeriert sind. Als nichteinschränkendes Beispiel kann der Prozess 400 hier unter Bezugnahme auf Operationen beschrieben werden, die in Bezug auf 2 oder 10 hierin diskutiert sind, und kann in Bezug auf die beispielhaften Systeme 200 oder 1000 diskutiert sein.
  • Der Prozess 400 kann ein „Erhalten von Bilddaten aus mindestens einem Bild einer Videosequenz“ 402 umfassen. Die Bilddaten der Bilder können synthetischen Inhalt oder Bildschirminhalt repräsentieren, könnten aber alternativ natürlicher, von der Kamera aufgenommener Inhalt oder eine Kombination von beiden sein. Bei einer Form umfasst diese Operation ein Erhalten der Originalbilddaten oder einer Version der Originalbilddaten anstelle von rekonstruierten Bilddaten, beispielsweise aus der Decodierschleife des Codierers. Die Originalbilddaten können verwendet werden, um sowohl Referenz- als auch Quell-Hash-Codes (oder aktuelle Hash-Codes) zu erzeugen. Außerdem können die Bilder für die Codierung ausreichend vorverarbeitet werden, einschließlich zusätzlicher Operationen, um IBC bei Bedarf und falls verfügbar auf natürlichen Videoinhalt anzuwenden.
  • Der Prozess 400 kann ein „Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame ist“ 404 umfassen. Hier umfasst diese Operation ein Berechnen eines Referenzbasis-Hash-Codes für einen einzelnen oder jeden Basisblock, der beispielsweise ein 4×4- oder 8×8-Block sein kann und der kleinste verfügbare Vorhersageblock sein kann, jedoch nicht immer der kleinste sein muss, solange er nicht die größte verfügbare Vorhersageblockgröße ist. Die Referenzbasis-Hash-Codes können für jeden Pixelort auf dem Frame berechnet werden, so dass sich die Referenzbasisblöcke überlappen und jeder oder einzelne Pixelort(e) ein Ankerpixelort für den Basisblock ist/sind, beispielsweise an der oberen linken Ecke des Basisblocks. Die Referenzbasis-Hash-Codes können in einer Tabelle angeordnet werden, in der der Ankerpixelort und der Referenzbasis-Hash-Code aufgeführt sind.
  • Der Prozess 400 kann ein „Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame ist“ 406 aufweisen. Diese Operation kann ein Unterteilen des Frames in nichtüberlappende Basisblöcke, die die gleiche Basisblockgröße wie die Referenzbasisblöcke haben, und ein Berechnen eines Quellbasis-Hash-Codes für jeden der Basisblöcke umfassen. Die Quellbasis-Hash-Codes können nach Bedarf im laufenden Betrieb berechnet werden.
  • Der Prozess 400 kann ein „Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstruierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist“ 408 umfassen. Diese Operation kann beinhalten, dass zuerst die größte verfügbare Vorhersageblockgröße als der aktuelle Block, der auf dem Frame rekonstruiert werden soll, und für einen Ankerpixelort ausgewählt wird. In einigen Beispielen kann der aktuelle Block ein 16x16-Makroblock, ein 32x32-Block oder ein 64x64-Block sein. Sobald die Position des aktuellen Blocks erhalten ist, bestimmt das System, welche Quellbasisblöcke sich innerhalb des aktuellen Blocks befinden oder diesen bilden. Sobald die Position der Quellbasisblöcke innerhalb des aktuellen Blocks bestimmt ist, kann der Quellbasis-Hash-Code jedes der Quellbasisblöcke berechnet werden, wenn er nicht bereits berechnet wurde.
  • Der Prozess 400 kann ein „Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht“ 410 umfassen. Diese Operation kann ein Nachschlagen der Quellbasis-Hash-Codes jedes der Quellbasisblöcke innerhalb des aktuellen Blocks in der Referenz-Hash-Tabelle umfassen. Dies kann Hash für Hash durchgeführt werden. Dies kann zudem für jeden Referenzblock wiederholt werden, der der Größe des aktuellen Blocks auf dem Referenz-Frame entspricht. Bei einer Form kann der aktuelle Block an jedem Referenzblockort, der an jedem Pixelort dargestellt ist, auf dem Referenz-Frame positioniert werden (oder mit diesem verglichen).
  • Bei einem weiteren Ansatz werden die Quellbasis-Hash-Codes des aktuellen Frames miteinander verkettet, um einen einzelnen Quell-Hash-Code oder aktuellen Hash-Code für den aktuellen Block zu bilden. Jeder Quellbasis-Hash-Code bildet einen bestimmten Teil oder Abschnitt des verketteten Quell-Hash-Codes und repräsentiert daher einen bestimmten Quellbasisblock in dem aktuellen Block. In diesem Fall können auch Referenzbasis-Hash-Codes verkettet werden und Referenzbasisblöcke umfassen, die zusammen dieselbe Größe wie der aktuelle Block bilden. Die verketteten Referenz- und Quell-Hash-Codes können dann voneinander subtrahiert werden und jeder Abschnitt des verketteten Hash-Codes, der Null ist, gibt sofort an, welche entsprechenden Referenz- und Quell-Basis-Hash-Codes übereinstimmen und welche Referenz- und Quell-Basisblöcke übereinstimmen. Auf diese Weise stimmt der gesamte aktuelle Block-Hash-Code mit dem Referenz-Hash-Code überein, wenn alle entsprechenden Quell- und Referenz-Basisblöcke übereinstimmen. In diesem Fall bilden die Bilddaten des gesamten Referenzblocks, die dem aktuellen Block entsprechen, die Vorhersage. Wenn Teile für Basisblöcke übereinstimmen, die einen Vorhersageblock innerhalb des aktuellen Blocks füllen, kann dieser Vorhersageblock auch als Vorhersage verwendet werden. Die Referenzdaten, die die Vorhersage selbst bilden, nachdem Originalbilddaten verwendet wurden, um Hashes abzugleichen, können die Originalbilddaten oder rekonstruierte Bilddaten sein. Die Vorhersage kann eine Kandidaten-Intra-Vorhersage sein, die zusammen mit anderen Vorhersagekandidaten für die endgültige Auswahl berücksichtigt werden soll, oder kann ohne eine Auswahloperation unter den Kandidaten als endgültige Vorhersage betrachtet werden.
  • Unter Bezugnahme auf einen weiteren Aspekt kann das System dann, wenn nur einige der Quellbasis-Hash-Codes übereinstimmen, bestimmen, ob alle Quellbasis-Hash-Codes für einen Vorhersageblock innerhalb des aktuellen Blocks übereinstimmen, indem erneut eine Verkettung verwendet wird. Dies kann beispielsweise ein einzelner Basisvorhersageblock oder Vorhersageblöcke wie 4×8 oder 8×4 usw. innerhalb eines größeren aktuellen Blocks sein. In diesem Beispiel können die Quell- und Referenzbasis-Hash-Codes zuerst verkettet werden, um jede der gewünschten Vorhersageblockgrößen zu bilden, bevor die Referenz- und Quellbasis-Hash-Codes, die jetzt in verketteten Vorhersageblock-Hash-Codes vorliegen, miteinander verglichen werden. Die Vorhersage für jeden Vorhersageblock kann dann als Kandidaten-Intra-Vorhersage zur Auswahl unter einer Anzahl anderer Kandidaten bereitgestellt werden. Unabhängig davon, ob eine Verkettung verwendet wird oder nicht, vermeiden diese Anordnungen die Notwendigkeit, mehrere Referenz-Hash-Tabellen für jeweils andere Vorhersageblockgrößen einzurichten, wodurch die erforderliche Speicherkapazität und Verzögerung verringert werden. Weitere Einzelheiten werden weiter unten gegeben.
  • Wie es erwähnt wurde, können das IBC-System und -Verfahren auch einheitliche Bereiche des Frames detektieren, indem Bereichs-IDs verwendet werden, die angeben, wann Referenzbasisblöcke als in einem solchen einheitlichen Bereich befindlich angesehen werden. Dies kann erreicht werden, indem zuerst bestimmt wird, ob der Hash-Code eines aktuellen Basisblocks bereits in der Referenz-Hash-Liste oder -Tabelle enthalten ist. Wenn ja, wird bestimmt, ob ein oder mehrere benachbarte Basisblöcke relativ zu dem aktuellen Basisblock den gleichen Basis-Hash-Code haben, der bereits in der Referenz-Hash-Tabelle enthalten ist. Bei einem Ansatz wird der linke und obere Nachbarbasisblock des aktuellen Basisblocks untersucht, um festzustellen, ob er den gleichen Hash-Code hat. Wenn dies der Fall ist, wird die Bereichs-ID des benachbarten Basisblocks für den aktuellen Basisblock in der Referenz-Hash-Tabelle oder der separaten Tabelle verwendet und die Bereichs-ID wird für den aktuellen Basisblock um eins erhöht. Wenn kein Nachbar einen übereinstimmenden Hash-Code hat, wird eine neue Bereichs-ID für den aktuellen Basisblock gestartet. Das System kann mindestens eine Zählung von Basisblöcken und in einer Form auch den Ort von Basisblöcken, die denselben Basis-Hash-Code haben, pflegen, um die Position und Ausdehnung der einheitlichen Bereiche zu verfolgen.
  • Das System kann zudem angeben, dass sich ein aktueller Basisblock auf dem aktuellen Frame innerhalb eines einheitlichen Bereichs befindet, wenn bestimmt wurde, dass sich ein gleicher Basisblockort auf einem vorherigen Frame relativ zu dem aktuellen Frame in einem einheitlichen Bereich befindet und den gleichen Basis-Hash-Code eines vorherigen Basisblocks an demselben Basisblockort in dem vorherigen Frame aufweist. Wenn festgestellt wird, dass sich der aktuelle Block oder Vorhersageblock in einem einheitlichen Bereich befindet, kann das System (a) einen Quantisierungsparameter des aktuellen Blocks oder Vorhersageblocks senken, um die Qualität des Blocks zu erhöhen, (b) ändern, welche Vorhersagemodi für den aktuellen Block oder Vorhersageblock in Betracht gezogen werden, und (c) einen Szenenwechsel detektieren, wenn eine ausreichende Anzahl von Basisblöcken in einem einheitlichen Bereich einen anderen Hash-Code als der gleiche Basisblockpixelort in einem vorherigen Frame aufweist. Weitere Einzelheiten werden nachstehend gegeben.
  • Wie es ebenfalls bereits erwähnt wurde, könnte das hierin offenbarte hashbasierte IBC auch auf ein von einer natürlichen Kamera aufgenommenes Video angewendet werden. Dies ist möglich, indem Bilddaten modifiziert werden, die zum Erzeugen der Referenz- und Quellbasis-Hash-Codes verwendet werden, um die Wahrscheinlichkeit zu erhöhen, übereinstimmende Referenz- und Quellbasis-Hash-Codes zu finden. Beispielsweise können die Originalbilddaten erneut entrauscht werden, wenn dies bereits in der Vorverarbeitung für den Codierer ausgeführt wurde, durch Abschneiden von LSBs aus den Bilddaten heruntergetastet und durch Abtasten eines Intervalls von Pixelorten, die die Blöcke bilden, verkleinert werden. Weitere Einzelheiten werden nachstehend gegeben.
  • Unter Bezugnahme auf 5A-5C ist ein beispielhafter Prozess 500 gemäß mindestens einigen Implementierungen der vorliegenden Offenbarung bereitgestellt. Im Allgemeinen kann der Prozess 500 ein computerimplementiertes Verfahren zum Videocodieren mit Intra-Block-Kopieren bereitstellen, wie es oben erwähnt wurde. In der dargestellten Implementierung kann der Prozess 500 eine oder mehrere Operationen, Funktionen oder Aktionen umfassen, wie sie durch eine oder mehrere der Operationen 502 bis 580 dargestellt sind, die im Allgemeinen geradzahlig nummeriert sind. Als nicht einschränkendes Beispiel kann der Prozess 500 hier unter Bezugnahme auf Operationen beschrieben werden, die in Bezug auf die 2 oder 10 und in Bezug auf die hier diskutierten beispielhaften Systeme 200 oder 1000 diskutierte sind.
  • Der Prozess 500 kann ein „Erhalten von Bilddaten eines Frames einer Videosequenz“ 502 umfassen und dies ist so, wie es oben mit dem System 200 und dem Prozess 400 beschrieben ist.
  • Der Prozess 500 kann einen „Vorverarbeitungs-Frame“ 504 umfassen und dies kann eine Vorverarbeitung der Bilddaten umfassen, die für eine allgemeine Codierung ausreichend ist. Dies kann daher ein Entrauschen usw. umfassen. Bei einer Alternative kann die Vorverarbeitung speziell für IBC ein Formatieren der Originalbilddaten umfassen, so dass das hashbasierte Such-IBC auch auf von der Kamera aufgenommene natürliche Bilder angewendet werden kann. Dies kann ein Durchführen eines zusätzlichen Entrauschens sowie ein Heruntertasten und Verkleinern der Bilddaten umfassen. Einzelheiten davon sind unten nach der Beschreibung des Prozesses 500 angegeben.
  • Der Prozess 500 kann ein „Erzeugen von Referenz-Hash-Codes von Referenzbasisblöcken zum Bilden eines Referenz-Frames“ 506 umfassen. Insbesondere wird anstelle des Hash-Codes für verschiedene Blockformen und - großen nur der Hash-Code für einen Basisblock, wie z. B. den kleinsten verfügbaren Vorhersageblock, zum Beispiel 4x4-Blöcke oder 8x8-Blöcke, berechnet. Alternativ können die Basisblöcke eine feste Größe haben, die nicht der kleinste Block ist, aber nicht so groß wie der hier beschriebene aktuelle Block ist, der häufig die größte verfügbare Vorhersageblockgröße ist. Diese Referenzbasis-Hash-Codes werden beispielsweise wie folgt berechnet und in einem einzelnen Puffer oder einer einzelnen Tabelle gespeichert.
  • Der Prozess 500 kann ein „Erstellen einer Referenz-Hash-Tabelle“ 508 umfassen und dies kann das automatische Bilden der Tabelle oder das Bilden der Tabelle nur dann, wenn Frames so festgelegt sind, dass eine hashbasierte Suche verfügbar ist, umfassen. Die Tabelle kann mit einem Hash-Eintrag und einem Blockort (oder einem Ankerpixelort), insbesondere für jeden Eintrag, eingerichtet sein. Jeder Eintrag kann auch ein Bereichs-ID-Feld aufweisen, wie es nachstehend beschrieben ist. Die Tabelle kann so eingerichtet sein, dass sie 32-Bit-DWORD-Referenz-Basis-Hash-Codes von Basisblöcken und einen Ankerpixelort jedes entsprechenden Basisblocks aufnimmt. In einem Beispiel kann die Tabelle die Einträge nach Ankerpixelort in Rasterabtastreihenfolge ordnen, wenn die Verkettung wie nachstehend erläutert verwendet werden soll. Die Referenztabelle kann nach Hash-Code sortiert sein, wenn direktes Hash-Code-Nachschlagen durchgeführt wird. Bei einem weiteren Aspekt ist die Referenz-Hash-Tabelle so ausgelegt, dass nur die Hash-Codes zuvor decodierter Referenzbasisblöcke gespeichert werden, bei anderen Formen werden jedoch Referenz-Hash-Codes für alle Basisblöcke aller Ankerpixel auf dem Frame gespeichert. Andere wünschenswerte Partitionen zum Speichern von Teilen eines Referenz-Frames, wie z. B. Slices, können stattdessen verwendet werden, unabhängig davon, welche Basisblöcke bereits decodiert wurden, da die Hash-Codes auf Originalbilddaten statt auf den rekonstruierten Bilddaten basieren können. Wie bereits erwähnt wurde, muss nur eine Hash-Tabelle erzeugt werden, da nur eine Blockgröße zum Berechnen von Hash-Werten verwendet wird. Dies senkt auch die Leistungsaufnahme und verringert Speicher und Verzögerung gegenüber der Bildung mehrerer Tabellen.
  • Unter Bezugnahme auf 6 kann der Prozess 500 ein „Erstellen von Referenz-Hash-Einträgen“ 510 umfassen und dies kann ein „Berechnen von Referenzbasis-Hash-Code für einzelne Basisblöcke“ 512 umfassen. Dies kann ein Lesen der Pixelorte für den Block von Pixel 0 bis Pixel N in einer festen Reihenfolge umfassen. Jedes Pixel wird an eine Hash-Funktion übergeben, die einen Zufallswert (32-Bit-DWORD reicht aus) basierend auf dem Pixelwert und dem vorherigen Status erzeugt. Es wird also mit einem festen Zustand begonnen und jedes nachfolgende Pixel passt den erstellten Hash-Wert an, wodurch ein eindeutiger Hash-Code erstellt wird, der eine geringe mathematische Wahrscheinlichkeit aufweist, eine falsch positive Übereinstimmung für die gegebenen Pixelwerte zu erzeugen. Die Hash-Tabelle speichert das 32-Bit-DWORD für den Hash und die Liste der entsprechenden Pixelorte, die diesem Hash-Wert entsprechen.
  • Bei einer Form werden die Originalbilddaten für einen Basisblock erhalten, der an jedem Pixelort in einem Frame verankert ist, wobei der Ankerpixelort die obere linke Ecke des Basisblocks ist. Dies bildet überlappende Basisblöcke für jeden möglichen Basisblockort auf dem Frame. Beispielsweise wird ein 4×4-Basisblock für jeden Pixelort 601 in einem Referenz-Frame 604 auf einem Bild 600 bereitgestellt. Ein 4×4-Basisblock 602 ist mit einem Ankerpixelort (0,0) 604 und 16 Pixeln von (0,0) bis (3,3) gezeigt. Die Bezeichnung H4x4(0,0) gibt an, dass der Pixelort (0,0) einen Basis-Hash-Code für den Basisblock 602 aufweist, und zum Indizieren in der Referenz-Hash-Tabelle berücksichtigt das Verfahren, dass sich der Hash-Code an dem Ankerpixelort befindet. Der nächste 4×4-Basisblock auf der rechten Seite hat seinen Anker an dem Ankerpixelort H4×4(1,0) 606 und enthält die Pixel (1,0) bis (4,3), und so weiter beispielsweise in Rasterabtastreihenfolge, obwohl andere Reihenfolgen als diese verwendet werden können. Das Ergebnis ist, dass sich die 4x4-Basisblöcke wie in Bild 600 gezeigt überlappen. Abhängig von der Spezifikation des Videocodierstandards können diejenigen Basisblöcke, die auf der rechten Seite und an dem unteren Rand des Frames 600 abgeschnitten sind, mit Bilddaten, die die gleichen sind wie die der Pixel am unteren Rand oder am rechten Rand oder beide, oder durch andere Techniken aufgefüllt werden, um die Randpixel bei Bedarf aus einem vollständigen Basisblock von Bilddaten zu bilden. Bei einer anderen Form werden die Pixel, die nicht in einen vollen einzelnen Basisblock passen, einfach übersprungen.
  • In diesem Beispiel kann der Prozess 500 zudem ein „Erhalten von Bilddaten von Basisblöcken Basisblock für Basisblock“ 514 umfassen, so dass die Referenz-Hash-Codes in dem vorliegenden Beispiel aus den Originalbilddaten berechnet werden können.
  • Bei einer Alternative kann der Prozess 500 ein „Bilden von Basisblöcken und Referenzbasis-Hash-Codes für einen zuvor codierten Referenz-Frame-Abschnitt“ 516 umfassen. Mit anderen Worten und in diesem Fall kann die Referenz-Hash-Tabelle nur die Referenz-Hash-Codes der Basisblöcke enthalten, die bereits von der Decodierschleife des Codierers decodiert wurden. Die Erzeugung von Vorhersagen für einen aktuellen Block kann dann nur durch die Daten dieser zuvor rekonstruierten Referenzblöcke durchgeführt werden. Somit ist der Referenz-Frame für Zwecke der Intra-Codierung typischerweise der Abschnitt des aktuellen Frames, der zuvor bereits codiert wurde.
  • Bei einer weiteren Alternative könnten stattdessen die Referenz-Hash-Codes der Blöcke des gesamten Frames erzeugt und in der Referenz-Hash-Tabelle gespeichert werden. Dies ist möglich, da die Hash-Codes unter Verwendung von Originalbilddaten anstelle der rekonstruierten Bilddaten berechnet werden. Es sollte jedoch beachtet werden, dass die Vorhersage selbst aus den rekonstruierten Bilddaten gebildet werden kann, obwohl die Auswahl eines Referenzblocks auf einem Hash-Abgleich unter Verwendung der Originalbilddaten beruhte.
  • In Bezug auf die Berechnung des Hash-Codes selbst kann der Hash-Wert eines Blocks basierend auf den Eigenschaften des Blocks wie horizontalen und/oder vertikalen Gradienten, Gleichstrominformationen (DC-Informationen) (wie einem mittleren Signalwert), einem Wert der zyklischen Redundanzprüfung (CRC-Wert) eines Pixels, ursprünglichen Pixelbilddaten, die in den hierin enthaltenen Beispielen verwendet werden, oder alternativ rekonstruierten Pixeldaten erzeugt werden. Hier kann ein Hashwert H für einen Block von 4×4 oder 8×8 Pixeln unter Verwendung bekannter Algorithmen berechnet werden. Eine Eingabedatenfolge sind die Bilddaten des Blocks, typischerweise in Rasterabtastreihenfolge innerhalb des Blocks. Die Ausgabe des Hash-Algorithmus ist hier ein 32-Bit-Doppelwort (DWORD). Ein Hash H wird für jeden Pixelort in einem Frame oder Teilen eines Frames geliefert, wie es in Bild 600 (das Referenz-Frame 603 ist) gezeigt ist und oben erwähnt wurde.
  • Wie es auch beim Berechnen der Referenzbasis-Hash-Codes erwähnt wurde, kann der Prozess 500 ein „Vergleichen von Hash-Code mit Nachbarn, um einheitliche Bereiche zu finden“ 518 umfassen. Insbesondere erzeugt diese Operation eine Zählung von aufeinanderfolgenden Nachbarorten mit demselben Hash-Wert, während die Referenz-Hash-Tabelle durch Einträge gefüllt wird, um einen einheitlichen Bereich oder Abschnitt des Bildinhalts auf dem aktuellen Frame anzugeben. Wie es erwähnt wurde, berechnet das System Referenz-Hashes für Basisblöcke auf eine sequentielle Weise, die eine Rasterabtastreihenfolge sein kann oder nicht. Sobald ein Referenzbasis-Hash-Code für einen aktuellen Basisblock berechnet wurde, wird dieser Referenzbasis-Hash-Code in der Referenztabelle gespeichert, es sei denn, der gleiche Hash-Code befindet sich bereits in der Tabelle. Wenn ja, werden Nachbarblöcke neben dem aktuellen Basisblock geprüft, um zu bestimmen, ob die Nachbarbasisblöcke bereits ihre Hash-Codes haben und ob diese Hash-Codes auch gleich dem Hash-Code des aktuellen Basisblocks sind. Dies gibt an, dass Basisblöcke die gleichen oder im Wesentlichen gleichen Bilddaten haben und daher wahrscheinlich ein einheitlicher Bereich des Bildes mit einer einzelnen Farbe und Helligkeit sind. Die Nachbarblöcke können der obere und der linke Block sein, können jedoch mehr oder weniger Nachbarblöcke oder andere Nachbarblöcke sein.
  • Unter Bezugnahme auf 7A kann für ein spezifisches Beispiel ein Bild oder ein Referenz-Frame 700 einen einheitlichen Bereich oder Bereich 702 mit Basisblöcken aufweisen, die durch Ankerpixelorte 704 bis 722 repräsentiert sind, die jeweils einen Basisblock in dem einheitlichen Bereich 702 darstellen. Ein aktueller Ankerpixelort 716 hat einen 4×4-Basisblock 730, während der linke Nachbarankerpixelort 714 einen 4×4-Basisblock 732 repräsentiert und der obere Nachbarankerpixelort 710 einen 4×4-Basisblock 734 hat, wie es in gestrichelter Linie gezeigt ist. Als der Bereich 702 eingerichtet und der Ankerpixelort (10, 23) 716 geprüft wurde, wurde festgestellt, dass sich sein Hash-Wert 0xBEEF bereits in einem Eintrag in der Referenz-Hash-Tabelle befand. In diesem Fall prüft das System die Nachbarpixelorte neben dem aktuellen Basisblockort 716 einschließlich des linken Nachbarn (9, 23) 714 und des oberen Nachbarn (10, 22) 710, um festzustellen, ob sie den gleichen Hash-Code haben. Wenn keiner der Nachbarorte 714 und 710 bereits den gleichen Hash-Code-Eintrag hat, wird eine neue Bereichs-ID für den einheitlichen Bereich erstellt, so dass der Hash-Code 0xBEEF jetzt auch als Bereichsbezeichnung betrachtet werden kann und mit einer Zählung von eins für den Ankerpixelort 716 gestartet wird. Wenn jedoch einer der Nachbarn 714 oder 710 den gleichen Hash-Code hat, wird die Bereichs-ID dieses Hash-Codes, der einem der Nachbarn zugeordnet ist, und jetzt der aktuelle Ankerpixelort um eins erhöht.
  • Der Prozess 500 kann dann ein „Pflegen mindestens der Zählung von Bereichsgröße(n)“ 520 umfassen, wobei ein Zähler der Bereichs-ID desselben oder duplizierten Ortes inkrementiert wird, um anzugeben, wie viele Blöcke Teil dieses Bereichs sind. Beispielsweise hat der einheitliche Bereich 702 auf dem Bild 700 10 Ankerpixel und damit 10 Basisblöcke. Der Ort der Blöcke für einen Bereich oder die Angabe der Zugehörigkeit zu dem Bereich kann auch für jede Zählung gespeichert werden. Je größer die Anzahl, desto größer der einheitliche Bereich.
  • Obwohl bestimmte große flache Bereiche wie nur weißen oder nur schwarze Pixel für einige Anwendungen ziemlich häufig sind, wird unten ein Test, um sicherzustellen, dass der Bereich nicht einfach ein Muster wie ein alternierendes Muster ist, das nicht einheitlich ist, wie etwa Streifen, beschrieben. Der Zähler kann für einen gesamten Frame inkrementiert werden, bevor die Intra-Codierung durchgeführt wird (Vorindizierung), wenn Originalbilddaten zum Erzeugen der Hashes verwendet werden.
  • Die Zählung kann in einer separaten Tabelle gepflegt werden, die nur Bereiche nach Hash-Code als Bereichs-ID auflistet und dann ein Feld für einen Zählwert für jede Bereichs-ID bereitstellt. Andernfalls kann die Zählung in einer separaten Tabelle oder in der Referenz-Hash-Tabelle gepflegt werden, indem jeder Referenz-Hash-Code und der entsprechende Pixelort aufgelistet werden und dann für jeden Eintrag ein Bereichs-ID-Feld bereitgestellt wird. Unabhängig davon, ob es sich um eine separate Tabelle oder eine Referenz-Hash-Tabelle handelt, kann sich die Bereichs-ID von dem Hash-Code selbst unterscheiden, z. B. eine Binärzählung von Bereichen. Es gibt viele Variationen.
  • Alternativ könnte zur Verbesserung der Latenz auch die Zählung gleichmäßiger Bereiche des vorherigen Frames relativ zu dem aktuellen Frame, der rekonstruiert wird, gespeichert werden und wäre im Allgemeinen zuverlässig, da zeitliche Redundanz die Hauptquelle von Kompression in Videocodecs ist. Bei einem Ansatz kann eine solche vorherige Zählung anstelle der Zählung auf dem aktuellen Frame verwendet werden. Bei einer weiteren Form können die Zählung und der Ort des einheitlichen Bereichs des vorherigen Frames zusätzlich zu der Zählung auf dem aktuellen Frame gespeichert werden, um einen Test auf einen zeitlich gemeinsamen Eintrag für einheitliche Bereiche auf dem aktuellen Bild bereitzustellen, wie es nachstehend beschrieben ist. Detektierte Änderungen der zeitlichen Komplexität können auch auf eine Szenenänderung hinweisen, sodass das IBC-Verfahren deaktiviert werden kann, um das IBC darauf zu beschränken, wann Qualität und/oder Leistungsfähigkeit basierend auf den häufig wiederholten Werten von Frame zu Frame verbessert werden können.
  • Wie es nachstehend beschrieben ist (Operationen 566 und 570), kann das Verfahren den Quantisierungsparameter anpassen und/oder anpassen, welche Vorhersagemodi verwendet werden sollen, und zwar abhängig davon, ob sich ein Basisblock oder ein aktueller Block innerhalb eines flachen gleichmäßigen Bereichs befindet oder nicht. Dies kann die Qualität verbessern und die Rechenlast und Verzögerung verringern.
  • Dann kann der Prozess 500 ein „Anordnen von Referenz-Hash-Codes in Tabelle“ 522 und in der Reihenfolge und in dem Format wie oben erwähnt umfassen.
  • Unter Bezugnahme auf 8 kann der nächste Prozess 500 ein „Erzeugen von Quell-Hash-Codes von Basisblöcken des Frames“ 524 umfassen und dies kann zuerst ein „Unterteilen des Frames in nichtüberlappende Basisblöcke“ 526 umfassen, wie es auf Bild 800 gezeigt ist, das in 4x4 Basisblöcke 804 unterteilt ist. Basisblöcke derselben Größe werden für die Referenzbasisblöcke verwendet, beispielsweise 4x4 oder 8x8, die die kleinste verfügbare Vorhersageblockgröße sein können, aber es könnte sich um eine andere Größe handeln, solange es sich nicht um die größte verfügbare Vorhersageblockgröße handelt (welche die aktuelle Blockgröße sein kann), wie es oben bei den Referenzbasisblöcken erwähnt wurde. Diese Blöcke überlappen sich nicht, da sie den einzig möglichen aktuellen Blockorten entsprechen.
  • Der Prozess 500 kann ein „Erhalten von Quell-Basis-Hash-Codes von Basisblöcken“ 528 umfassen, wobei die Quell-Basis-Hash-Codes auf die gleiche oder eine ähnliche Weise wie die Referenzbasisblöcke berechnet werden. Die Quellbasis-Hash-Codes werden ebenfalls basierend auf den Originalbilddaten berechnet. Bei einem beispielhaften Ansatz können die Quellbasis-Hash-Codes aus den Referenzbasis-Hash-Codes desselben Blockpixelorts auf dem Frame erhalten werden, wenn die Referenzbasis-Hash-Codes dazu verfügbar sind. Da beide aus denselben Originalbilddaten mit demselben Algorithmus an denselben Blockpositionen berechnet werden, kann der Ankerpixelort des Quellbasisblocks in der Referenz-Hash-Tabelle nachgeschlagen werden und der Referenzbasis-Hash-Code kann für den Quellbasis-Hash-Code des gleichen Basisblockorts verwendet werden. Dies würde natürlich erfordern, dass der Referenz-Frame Hashes von Referenzblöcken, die bereits decodiert sind, für die Quellblöcke, deren Quell-Hash-Codes berechnet werden, enthält. Bei einer weiteren Form könnte der Referenz-Hash-Code aus rekonstruierten Bilddaten aus der Decodierschleife des Codierers und anstatt aus den Originaldaten gebildet werden.
  • Der Prozess 500 kann ein „Erhalten des Ortes des ersten zu rekonstruierenden aktuellen Blocks“ 530 umfassen und der Pixelankerort des aktuellen Blocks wird gemäß einem üblichen IBC-Prozess erhalten. Die Auswahl des aktuellen Blocks kann in Rasterabtastreihenfolge erfolgen oder nicht. Wie erwähnt ist der aktuelle Block nicht die kleinste Vorhersageblockgröße und sollte die größte zu rekonstruierende Vorhersageblockgröße sein. Dies kann normalerweise 64×64, 32×32 oder 16×16 sein, könnten aber auch andere Größen wie 8×8 sein.
  • Der Prozess 500 kann ein „Bestimmen, welche Quellbasisblöcke innerhalb des aktuellen Blocks angeordnet sind“ 532 umfassen. Sobald der aktuelle Block ausgewählt ist, bestimmt das System somit, welche Quellbasisblöcke sich innerhalb des aktuellen Blocks des aktuellen Frames befinden oder diesen bilden, und erhält die Ankerpixelorte jedes dieser Quellbasisblöcke. Angenommen, der aktuelle Block ist 8×8 Pixel und der Basisblock ist 4×4, dann findet das System den Ankerpixelort der vier 8×8-Quellbasisblöcke innerhalb des aktuellen Blocks auf dem aktuellen Frame, der den aktuellen Block bildet. Angenommen, es wird festgestellt, dass ein aktueller 8×8-Block 830 auf Bild 800 vier Basisblöcke 832, 834, 836 und 838 aufweist. Das System findet der Ankerpixelort, hier den Pixelort in der oberen linken Ecke, jedes der Basisblöcke 832, 834, 836 und 838.
  • Der Prozess 500 kann als Nächstes ein „Erhalten von Quellbasis-Hash-Codes der Quellbasisblöcke innerhalb des aktuellen Blocks“ 534 umfassen und erhält die Quellbasis-Hash-Codes für jeden Quellbasisblock in dem aktuellen Block, die wie oben beschrieben berechnet werden. Wie bereits erwähnt können die Quell-Hash-Codes 32-Bit-DWORDs sein, es können jedoch auch andere Längen verwendet werden. Diese Quellbasis-Hash-Codes können im laufenden Betrieb berechnet und in Speicher wie dem lokalen Cache oder in einem Puffer, der für diesen oder andere Codierungszwecke wie den Zeilenspeicher-Cache reserviert ist, und während Hash-Abgleichsoperationen gespeichert werden.
  • Bei einer Form und unter Bezugnahme auf 9A kann der Prozess 500 ein „Verketten von Quellbasis-Hash-Codes zum Bilden eines aktuellen Quell-Hash-Codes des aktuellen Blocks“ 536 umfassen, wenn die Verkettungssuchoption verwendet wird. In diesem Fall werden, sobald alle Quell-Hash-Codes des aktuellen Blocks erhalten wurden oder während die Hash-Codes erhalten werden, die Quellbasis-Hash-Codes A-D (902, 904, 906 und 908) zu einem einzigen großen Quell-Hash-Code oder aktuellen Hash-Code 900 verkettet. Wie es gezeigt ist, kann jeder Hash-Code hier N Bits 910 aufweisen, wobei beispielsweise N=32 ist. Jeder Quellbasis-Hash-Code 902, 904, 906 und 908 bleibt ein bestimmter Teil oder Abschnitt des aktuellen verketteten Hash-Codes 900, um die jeweiligen Quellbasisblöcke (die beispielsweise die Basisblöcke 832, 834, 836 und 838 von Bild 800 sein könnten) darzustellen.
  • Wie es oben erwähnt ist, kann der Codierer oder das System auch so eingestellt sein, dass geprüft wird, ob Vorhersageblöcke, die kleiner als der aktuelle Block sind, auch Vorhersagen aufweisen, die durch übereinstimmende Hashes angegeben werden, wobei jede Vorhersageblockübereinstimmung auch einen Intra-Vorhersagekandidaten bilden kann. Wenn beispielsweise der aktuelle Block 32×32 und die Basisblöcke 8×8 sind, kann ein solcher aktueller Block einen oder mehrere Codierungsbaumeinheits-Vorhersageblöcke mit Vorhersageblockgrößenoptionen 16×32, 32×16, 16×16, 8×16, 16×8 und 8×8 umfassen. In diesem Fall kann der Codierer so eingestellt sein, dass er Intra-Vorhersagen für jede Größe bestimmt, wenn eine Hash-Übereinstimmung gefunden wird.
  • Bei einem optionalen Ansatz für die Verkettungssuchoption wird nur der aktuelle Block oder Quellblock verkettet. In diesem Fall haben die kleineren Vorhersageblöcke innerhalb des aktuellen Blocks keine eigenen verketteten Hash-Codes. Wie es unten für diese Option erläutert ist, werden die übereinstimmenden Abschnitte des Quell-Hash-Codes einfach verwendet, um zu bestimmen, ob ihre zugeordneten Quellbasisblöcke eine der Vorhersageblockgrößen und -positionen füllen.
  • Unter Bezugnahme auf 9B und bei einem weiteren Ansatz für die Verkettungssuchoption kann der Prozess 500 auch ein „Verketten von Quellbasis-Hash-Codes zum Bilden von Vorhersageblock-Hash-Codes innerhalb des aktuellen Blocks“ 537 umfassen. Hier bildet das System einen verketteten Vorhersage-Hash-Code für jede Vorhersageblockgröße und -position innerhalb des aktuellen Blocks, der als Hash-Suchkandidat verfügbar ist. Die Verkettung wird ähnlich wie die aktuellen Blockverkettung 900 (9A) gebildet. Während des Betriebs und während der Suchphase kann bei einer Form ein Verkettungssystem 940 verwendet werden. Angenommen, der aktuelle Block ist hier 8x8 und die Basisblöcke sind 4x4. Die Eingabe sind die Hash-Codes 950, 952, 954 und 956 für alle 4x4-Basisblöcke innerhalb des größeren aktuellen Blocks. Für das System 940 können diese Hash-Codes miteinander verkettet werden, um einen aktuellen Hash-Code für den gesamten aktuellen Block und jeden der Vorhersageblöcke innerhalb des aktuellen Blocks zu bilden. Beispielsweise werden für einen 4x8-Block an Ort [0, 0] Hash-Codes für zwei 4x4-Basisblöcke, H4x4(0,0) 950 und H4×4(0,4) 954, miteinander verkettet, um einen neuen 4x8-Vorhersageblock-Hash-Code 958 unter Verwendung des Addierers 968 zu erstellen. Für einen 8x4-Vorhersageblock an Ort [0,4] werden Hash-Codes für zwei 4x4-Basisblöcke H4×4(0,4) 954 und H4×4(4,4) 956 miteinander verkettet, um einen neuen verketteten 8x4-Vorhersageblock-Hash-Code 964 unter Verwendung des Addierers 974 zu erstellen. Für den aktuellen 8x8-Block (oder einen größeren Vorhersageblock) an Ort [0,0] werden die Hash-Codes für alle vier 4x4-Basisblöcke H4×4(0,0) 950, H4×4(4,0) 952, H4×4(0,4) 954 und H4×4(4,4) 956 miteinander verkettet, um mit dem Addierer 972 einen neuen aktuellen Block-Hash-Code 962 zu erstellen. Dies resultiert in mehreren verketteten Hash-Codes, die den verketteten Hash-Code des aktuellen Blocks sowie jeden oder einzelne Vorhersageblöcke umfassen sollten, wie es von dem Codierer festgelegt ist. Bei anderen Formen kann die Verkettung getrennt von der Verkettung des gesamten aktuellen Blocks durchgeführt werden.
  • Der nächste Prozess 500 kann ein „Bestimmen von Referenzbasisblöcken für einzelne Ankerpixelorte auf dem Frame zum Bilden eines Referenzblocks, der der Größe des aktuellen Blocks entspricht“ 538 umfassen. Diese Operation ähnelt der Operation 532, mit der Ausnahme, dass hier der aktuelle Block keinen festen Ort in dem Referenz-Frame aufweist. Daher beinhaltet diese Operation ein Gruppieren der Referenzbasisblöcke nach relativem Ort, um die Größe (d. h. die Abmessungen und die Form) des aktuellen Blocks zu bilden. Wenn beispielsweise der aktuelle Block 8×8 ist und beispielsweise der Ankerpixelort des aktuellen Blocks (seine obere linke Ecke) zum Vergleich bei (0,0) auf dem Bild 600 (das ist der Referenz-Frame 604) platziert ist, dann sind die vier 4×4-Basisblöcke, die durch ihre vier Ankerpixelorte repräsentiert werden, und ihre Hash-Codes an diesen Orten (0,0) 604, (4,0) 608, (0,4) 612 und (4,4) 616. Die vier Basisblöcke, die den um ein Pixel nach rechts verschobenen aktuellen Block bilden, sind die vier 4×4-Basisblöcke mit Ankerpixelorten und damit Hash-Codes bei (1,0) 606, (5,0) 610, (1,4) 614 und (5,4) 618 und so weiter. Sobald der Ort der Referenzbasisblöcke für den aktuellen Block bestimmt ist, können die Referenz-Hash-Codes für diese Basisblöcke in der Referenz-Hash-Liste oder -Tabelle für die Verkettungssuchoption nachgeschlagen werden. Wie es unten erläutert ist, kann diese Vorgang Operation für die Suchoption mit direktem Nachschlagen oder für die Verkettungssuchoption verwendet werden.
  • Wenn die Basisblöcke verkettet werden sollen, um die Vorhersageblöcke auch innerhalb des aktuellen Blocks zu bilden, kann der Prozess 500 zudem ein „Bestimmen von Referenzbasisblöcken, um der Größe der Vorhersageblöcke innerhalb des aktuellen Blocks zu entsprechen“ 539 umfassen, wodurch bestimmt wird, welche Referenzbasisblöcke welche Vorhersageblöcke bilden. Bei einem Ansatz beinhaltet diese Operation einfach ein Bestimmen der Referenzbasis-Hash-Codes der Referenzbasisblöcke, die zusammen die aktuelle Blockgröße bilden und die in vorgesehene Eingänge eines Verkettungssystems wie etwa des Systems 940 mit Addierern eingegeben werden sollen, um die verketteten Vorhersageblock-Hash-Codes zu erzeugen. Dies kann auch den aktuellen Block-Hash-Code erzeugen, wenn dies gewünscht wird.
  • Der Prozess 500 kann ein „Suchen nach einem oder mehreren übereinstimmenden Referenzblöcken auf dem Referenz-Frame“ 540 umfassen. Bei einem Ansatz für diese Operation kann der Prozess 500 ein „Verwenden jedes Pixelorts eines Zielreferenzbereichs des Frames als Vergleichs-Ankerpixelposition des aktuellen Blocks“ 542 umfassen, wobei jeder überlappende Blockort in dem Referenz-Frame mit dem Quellblock oder dem aktuellen Block verglichen wird. Bei einer Form wird der Referenzblock, der aus Referenzbasisblöcken gebildet wird, die bis zu der gleichen Größe wie der des aktuellen Blocks aufgenommen wurden, an jedem Pixelort auf dem Referenz-Frame für die Vergleiche mit dem aktuellen Block platziert. Wie erwähnt kann dies nur bei dem Referenz-Frame geschehen, der bisher decodiert wurde, aber andere Bereiche oder der gesamte Frame können stattdessen wie oben beschrieben verwendet werden.
  • Wie es erwähnt wurde, gibt es eine Reihe verschiedener Möglichkeiten, den Hash-Abgleich durchzuführen. Zuerst wird die Suchoption mit direktem Nachschlagen beschrieben. Für diese Option kann der Prozess 500 ein „Suchen nach Quellbasis-Hash-Codes des aktuellen Blocks in der Liste der Referenzbasis-Hash-Codes“ 544 umfassen, und wenn die Referenzliste eine Referenz-Hash-Tabelle ist, kann der Prozess 500 ein „Suchen nach Basis-Hash-Codes auf Einträgen der Referenztabelle“ 546 umfassen. Insbesondere kann diese Operation ein Nachschlagen der Quellbasis-Hash-Codes, die den aktuellen Block bilden, in der Referenz-Hash-Tabelle umfassen. Bei einer Option kann dies einfach ein unabhängiges Nachschlagen jedes Quellbasis-Hash-Codes in dem Referenzblock und in der Referenz-Hash-Tabelle Hash für Hash beinhalten. Typischerweise müssen jedoch die relativen Positionen der Quellbasisblöcke des aktuellen Blocks noch verfolgt werden, da das Finden von Referenzbasisblöcken mit Hashes, die mit den Hashes der Quellbasisblöcke übereinstimmen, an zufälligen Orten, die auf dem Frame verteilt sind, nicht zu einer sehr genauen Vorhersage führt.
  • Unter erneuter Bezugnahme auf 6 kann das Verfahren somit den Quellbasis-Hash-Code eines ersten Quellbasisblocks in dem aktuellen Block, beispielsweise des Quellbasisblocks in der oberen linken Ecke des aktuellen Blocks, nachschlagen. In diesem Fall kann die Referenz-Hash-Tabelle zuerst nach Hash-Code sortiert werden. Das Verfahren durchsucht die Tabelle Ankerpixelort für Ankerpixelort, bis der übereinstimmende Hash-Code gefunden wird. Sobald der übereinstimmende Hash-Code gefunden wurde, wird der Referenzblock mit der gleichen Größe wie der aktuelle Block an diesem Ankerpixelort gesetzt, beispielsweise bei Pixel (0,0) 604 für einen 8x8-Referenzblock mit 4x4-Basisblöcken. Dann werden auch die Quellbasis-Hash-Codes der anderen Basisquellblöcke in dem aktuellen Block nachgeschlagen. Bei einer Form werden alle Übereinstimmungen mit Referenzbasis-Hash-Codes in der Tabelle für jeden dieser anderen Quellbasisblöcke gefunden. Es wird dann bestimmt 554, ob eine dieser Übereinstimmungen die Orte aufweist, die mit einem übereinstimmenden Referenzbasis-Hash-Code neben dem ersten Referenzbasisblock (0,0) liegen. So wird beispielsweise unter den Hash-Übereinstimmungen bestimmt oder es ist bekannt, dass sich die drei anderen Quellbasisblöcke und wiederum Referenzbasisblöcke neben dem Basisblock bei (0,0) 604 bei (4,0) 608, (0,4) 612 und (4,4) 618 befinden. Wenn für einen dieser vier Basisblöcke keine Übereinstimmung besteht, wird der 8x8-Referenzblock für den Vergleich zwischen Referenzblock und dem aktuellen Block zu dem nächsten Ankerpixelort verschoben. Wenn alle Quellbasisblöcke des aktuellen Blocks übereinstimmen, ist der 8x8-Referenzblock an diesem Ankerort (0,0) eine Übereinstimmung und kann als Vorhersage oder als eine der Kandidatenvorhersagen verwendet werden.
  • Unter Bezugnahme auf 7B kann der Prozess 500 dann, wenn nur einige der Quellbasis-Hash-Codes des aktuellen Blocks einen übereinstimmenden Referenzbasis-Hash-Code an einem bestimmten Referenzblockpixelort aufweisen, ein „Bestimmen, ob übereinstimmende Hash-Codes, die kleiner als alle Basis-Hash-Codes des aktuellen Blocks sind, in irgendwelche verfügbaren Kandidaten-Vorhersageblockgrößen passen“ 556. Somit kann bestimmt werden, ob irgendeine andere Vorhersageblockgröße, beispielsweise 4×8, 8×4 an zwei möglichen Positionen innerhalb des 8×8-Referenzblocks, mit übereinstimmenden Hashes gefüllt ist. So kann beispielsweise der Referenz-Frame 750 Referenzbasisblöcke 752 aufweisen, wobei es sich hierbei um 4×4-Pixel-Basisblöcke 754 handelt. Ein 16×16-Referenzblock 756 ist mit potenziellen 8×16- Vorhersageblöcken 858 und 760 gezeigt. In dem 8×16-Vorhersageblock 760 sind keine Übereinstimmungen aufgetreten und er wird also ignoriert. Der Vorhersageblock 858 hat jedoch Hash-Übereinstimmungen in allen seinen Referenzbasisblöcken 762 bis 776, die geradzahlig nummeriert sind. Wie es hier gezeigt ist, können die übereinstimmenden Vorhersageblöcke auch Intra-Vorhersagen sein, wenn bei einem oder mehreren dieser Vorhersageblöcke auch alle Quellbasis-Hash-Codes mit Referenzbasis-Hash-Codes übereinstimmen.
  • Das Verfahren fährt dann fort, indem der Referenzblock zu dem nächsten Ankerpixelort bewegt wird, um diese Operationen zu wiederholen und zu bestimmen, ob an diesem Ort mehr Vorhersagen vorhanden sind und so weiter, bis alle oder einzelne mögliche Referenzblockpositionen auf dem Referenz-Frame berücksichtigt wurden.
  • Bei einer weiteren Option, die zum Beispiel des Bildes 600 mit Referenzblöcken und aktuellen Blöcken mit 8×8 zurückkehrt, können die Orte der drei anderen Quellbasisblöcke (4,0), (0,4) und (4,4) neben dem ersten Quellbasisblock bei (0,0) in dem aktuellen Block stattdessen nach Ort nachgeschlagen werden. In diesem Fall kann die Referenz-Hash-Tabelle sekundär nach Ankerpixelort aufgelistet werden, so dass die Einträge derselben Hash-Codes im Allgemeinen beispielsweise in Rasterabstastpixelreihenfolge aufgelistet sind. Dieses Betriebsverfahren erhält die relativen Orte (z. B. nach Pixellänge oder Blockzählung) der anderen Quellbasisblöcke innerhalb des aktuellen Blocks und legt sie als Orte der Referenzbasisblöcke fest, die in der Referenz-Hash-Tabelle nachgeschlagen werden sollen. Sobald beispielsweise bekannt ist, dass der Pixelort (0,0) 604 (6) einen übereinstimmenden Referenzbasisblock aufweist, werden die nächsten Blöcke nach oben und unten zum Füllen des 8x8-Referenzblocks nachgeschlagen, hier (4,0) 608, (0,4) 612 und (4,4) 616. Wenn keine Übereinstimmungen gefunden werden, alle Übereinstimmungen gefunden werden oder nur einige der Übereinstimmungen gefunden werden, wird das Verfahren wie oben erwähnt auf die gleiche Weise fortgesetzt, wenn nur Hash-Codes in der Referenz-Hash-Tabelle nachgeschlagen werden.
  • Unter Bezugnahme auf die Verkettungssuchoption kann der Prozess 500 ein „Suchen nach Quellbasisblockorten in der Referenz-Hash-Tabelle zum Finden von Hash-Codes zur Verkettung“ 548 umfassen. In diesem Fall wird die Referenz-Hash-Tabelle zuerst in der Reihenfolge nach Ankerpixelort aufgelistet. Das Verfahren fährt fort, indem der Referenzblock an einem ersten Ankerpixelort auf dem Referenz-Frame platziert wird und die relativen Ankerpixelorte der Referenzbasisblöcke erhalten werden, die auf die Quellbasisblöcke in dem aktuellen Block ausgerichtet sind. So hat beispielsweise ein aktueller 8x8-Block vier Quellbasisblöcke, die an den Pixelorten (0,0), (4,0), (0,4) und (4,4) verankert sind, und die Quellbasis-Hash-Codes für jeden der vier Quellbasisblöcke sind bereits gemäß den oben beschriebenen Operationen 534 und 536 erzeugt und zu einem einzigen aktuellen Block-Hash-Code verkettet worden. Dann kann unter Bezugnahme auf 6 ein erster Referenzblock mit der gleichen Größe wie ein aktueller 8x8-Block an dem Ankerpixelort (0,0) 604 platziert werden. Somit können die vier Referenzbasisblöcke, die auf die vier Quellenbasisblöcke des aktuellen Blocks ausgerichtet sind, an den Ankerpixelorten (0,0) 604, (4,0) 608, (0,4) 612 und (4,4) 616 verankert sein. Jeder dieser vier Pixelorten wird dann in der Referenz-Hash-Tabelle nachgeschlagen. Der Hash-Code-Eintrag an jedem der Pixelorte und wiederum für jeden der an diesem Pixelort verankerten Referenzbasisblöcke wird dann erhalten.
  • Der Prozess 500 kann ein „Verketten von Referenzbasis-Hash-Codes von Basisblöcken zum Bilden eines Referenzblock- und/oder Vorhersageblock-Hash-Codes“ 550 umfassen, so dass gerade erhaltene Referenzbasis-Hash-Codes miteinander verkettet werden, wie es bei der Verkettung 900 (9A), die mit der Quellverkettung verwendet wird, erklärt ist.
  • Der Prozess 500 kann dann ein „Vergleichen von verketteten Referenzblöcken mit dem aktuellen Block und/oder Vorhersageblock“ 552 umfassen, wobei hier die Quellverkettung (oder der verkettete Quell-Hash-Code) und die Referenzverkettung (oder der verkettete Referenz-Hash-Code) verglichen werden. Dies kann ein einfaches Subtrahieren der beiden Werte oder die Verwendung einer anderen Vergleichsoperation umfassen. Bei einer Form müssen die verketteten Hash-Codes nicht in einem Puffer gespeichert werden und müssen beispielsweise nur zur Hash-Erzeugung in Logikgattern oder Flops gehalten werden. Die verketteten Hash-Codes werden dann abgerufen, um zu prüfen, ob sie übereinstimmen, so dass diese Operation im laufenden Betrieb ausgeführt werden kann. Bei einer Form kann dieser Speicher 4 Bits auf einmal ausgeben und dann kann eine 4-Bit-UND-Operation verwendet werden, um den Abgleich durchzuführen.
  • Der Prozess 500 kann ein „Bestimmen, ob irgendwelche oder alle Referenz- und Quellbasis-Hash-Codes des aktuellen Blocks übereinstimmen“ 554 umfassen. Somit werden bei einer Option die Verkettungen für den gesamten aktuellen Block und den Referenzblock verglichen, was die größtmöglichen Vorhersageblockgrößen sind. Wenn die beiden Verkettungen genau gleich sind, wird eine Übereinstimmung für den großen aktuellen Block festgestellt und diese kann als Vorhersage oder Vorhersagekandidat verwendet werden. Bei einem Ansatz kann dies der einzige Kandidat für die Referenzblockposition sein und der Referenzblock kann zu dem nächsten Ankerpixelort verschoben werden, um den neuen Ort zu testen. Dies kann für alle Pixelankerorte in dem Referenz-Frame wiederholt werden.
  • Bei einer weiteren Alternative kann der Prozess 500 ein „Bestimmen, ob übereinstimmende Hash-Codes, die weniger als alle Basis-Hash-Codes des aktuellen Blocks sind, zu verfügbaren Kandidaten-Vorhersageblockgrößen passen“ 556 umfassen. Dies wird hier typischer sein und unabhängig davon, ob der aktuelle Block und der Referenzblock genau übereinstimmen oder nicht, können die kleineren Vorhersageblöcke innerhalb des aktuellen Blocks und des Referenzblocks auch als zusätzliche Vorhersagekandidaten getestet werden, wenn Hash-Codes für die Vorhersageblöcke übereinstimmen. Dies kann auf verschiedene Arten und alles ohne weiteres Nachschlagen der Referenz-Hash-Tabelle durchgeführt werden, da alle Referenzbasis-Hash-Codes aller Referenzbasisblöcke, die den Referenzblock bilden, und damit der aktuellen Block bereits erhalten worden sind, um die Verkettung des Referenzblocks zu bilden.
  • Bei einer Option hat jede verfügbare Vorhersageblockgröße ihre eigenen Quell- und Referenzvorhersageblockverkettungen der jeweiligen Hash-Codes der Quell- und Referenzbasisblöcke, die die Vorhersageblöcke bilden. Unter erneuter Bezugnahme auf das Bild 600 von 6 wurden beispielsweise die Referenzbasis-Hash-Codes der 4x4-Referenzbasisblöcke, die bei (0,0) 604 und (0,4) 612 verankert sind, bereits für die 8x8-Referenzblockverkettung erhalten. Somit kann nun ein 4×8-Referenzvorhersageblock mit diesen beiden Referenzbasisblöcken gebildet werden und dies ist für den Quellvorhersageblock ähnlich. Somit können diese beiden Hash-Codes, die tatsächlich als H4x4(0,0) und H4×4(0,4) bezeichnet werden, für den 4x8-Vorhersageblock miteinander verkettet werden und dann können die zwei verketteten Hash-Codes der Quell- und Referenz-Vorhersageblöcke verglichen werden. Wenn die Hash-Codes genau übereinstimmen, kann dieser Vorhersageblock als Vorhersagekandidat verwendet werden. Dies kann für jede Vorhersageblockgröße wiederholt und dann für jede oder einzelne Referenzblockpositionen auf dem Referenz-Frame erneut wiederholt werden.
  • Bei noch einer weiteren Option kann, obwohl die Referenz- und Quellblöcke verkettet wurden, die Verkettungsoperation für die Vorhersageblöcke übersprungen werden. In diesem Fall verfolgt das Verfahren, welcher Teil des Verkettungs-Hash-Codes des Referenzblocks übereinstimmt und welcher nicht. Wie des oben bei der Verkettung 900 (9A) erwähnt wurde, ist jeder einzelne Teil der Verkettung ein Basis-Hash-Code, so dass beim Vergleich der beiden großen Verkettungs-Hash-Codes die Quell- und Referenzbasis-Hash-Codes für die gleichen relativen Basisblockpositionen innerhalb des aktuellen Blocks und Referenzblocks aufeinander ausgerichtet werden. Somit ist sofort bekannt, welche Basis-Hash-Codes übereinstimmten und welche nicht. Mit diesem Wissen und durch Gruppieren der relativen Orte der Basisblöcke der übereinstimmenden Hash-Codes kann bestimmt werden, welche Vorhersageblöcke übereinstimmende Hash-Codes haben und Vorhersagen sein sollten. Dies wird auch für jede Referenzblockposition auf dem Referenz-Frame wiederholt.
  • Der Prozess 500 kann ein „Festlegen eines übereinstimmenden Blockortes mit mindestens Größe und Bewegungsvektor als hashbasierten Intra-Vorhersagekandidaten“ 558 umfassen. Bei einer Option können die Blöcke tatsächlich durch Bewegungsvektor verfolgt werden. Insbesondere wird vor oder nach dem Bestimmen einer Übereinstimmung ein potentieller Bewegungsvektor von dem Ankerpixelort des aktuellen Blocks (oder Quellvorhersageblocks) zu dem Ankerpixelort des Referenzblocks (oder Referenzvorhersageblocks) festgelegt. Bei einer Form können die zu verglichenen Blockpositionen durch potentielle Bewegungsvektoren ausgewählt werden, die die Orte definieren. Bei einer weiteren Option können die Bewegungsvektoren bestimmt werden, sobald eine Hash-Code-Übereinstimmung bestimmt worden ist, und der Bewegungsvektor gibt die Position der übereinstimmenden Blöcke als einen Kandidaten-Bewegungsvektor an. Mit diesen Operationen können dann, sobald eine Hash-Übereinstimmung bestimmt ist, der Bewegungsvektor und die Größe des Blocks als Kandidateninformationen gespeichert werden. Andernfalls können der Bewegungsvektor und die Blockgröße verwendet werden, um einen Rest zu bilden, wenn die Vorhersagemodusauswahl automatisch weggelassen wird, wenn Hash-Übereinstimmungen vorhanden sind. In jedem Fall und bei einer Form können die Vorhersageinformationen wie der Bewegungsvektor und die Blockgröße in einen Bitstrom gepackt und an Decodierer übertragen werden, ohne dass andere Hash-Informationen der Vorhersage erforderlich sind.
  • Solche Anordnungen resultieren in einem hashbasierten Suchverfahren, das die Leistungsaufnahme reduziert, da das Verfahren nur einmal eine Referenztabellenerstellung für den Frame durchführen muss, und dann muss das Verfahren nur eine einzelne Referenzbasis-Hash-Code-Suchoperation für jeden der Quellbasisblöcke und an jedem Referenzblockort anstatt für jede unterschiedliche Vorhersageblockgröße und -position ausführen.
  • Abhängig von den Übereinstimmungen des Basisblock-Hash-Codes können auch andere Codiererparameter angepasst werden. Somit kann der Prozess 500 die Anfrage „Hash-Übereinstimmung?“ 560 umfassen und dieser Test kann auf jeden aktuellen Block angewendet werden, nachdem alle oder bestimmte einzelne Referenzblockpositionen auf dem Referenz-Frame mit dem aktuellen Block verglichen wurden. Wenn für den aktuellen Block keine hashbasierte Übereinstimmung vorhanden ist, wird der aktuelle Block ohne hashbasiertes IBC 562 codiert. In diesem Fall können normales Bewegungssuch-IBC, Nicht-IBC-Intra-Vorhersage und/oder Inter-Vorhersage für den aktuellen Block angewendet werden, wie es durch die Codiererparameter und -steuerungen festgelegt ist.
  • Bei einer Alternative kann der Prozess 500 dann, wenn Hash-Codes übereinstimmen, die Anfrage „Hash flacher Bereich?“ 564 umfassen, und dies kann für jeden Vorhersageblock und/oder aktuellen Block mit übereinstimmenden Hash-Codes angewendet werden, wie es durch die oben beschriebene Bereichs-ID-Zählung (Operation 520) verfolgt wird. Somit kann dies zuerst ein Nachschlagen der Referenzbasis-Hash-Codes oder Referenzbasisblockorte eines aktuellen Blocks oder Vorhersageblocks mit übereinstimmenden Hash-Codes umfassen. Das Nachschlagen wird in der Referenz-Hash-Tabelle oder einer separaten Tabelle durchgeführt, um festzustellen, ob die Zählung der einheitlichen Bereiche ungleich null ist. Wenn ja, kann diese Operation einen Test umfassen, um zu bestimmen, ob sich der zu analysierende Block tatsächlich in einem sich wiederholenden Muster des Bildinhalts befindet und nicht in einem einheitlichen Bereich. Dies kann erreicht werden, indem eine gradientenbasierte Mustererkennungstechnik auf Pixelwerte über mehrere Basisblöcke hinweg angewendet wird, beispielsweise mit einer Sobel-Kantendetektion, die Kanten über einem bestimmten Mindestschwellenbereich detektieren kann. Dann können diese Bereiche mit anderen Bereichen verglichen werden, um ein Muster zu detektieren. Wenn kein Muster vorhanden ist und ein einheitlicher Bereich bestätigt wird, kann der Prozess 500 die Codiererparameter anpassen, um die Qualität und/oder Leistungsfähigkeit ab Operation 568 zu erhöhen.
  • Wie es oben erwähnt ist, kann ein Basisblock auch als innerhalb eines einheitlichen Bereichs liegend bezeichnet werden, wenn ein vorheriger Frame einen einheitlichen Bereich für denselben Basisblockort aufweist, obwohl der aktuelle Frame nicht angibt, dass sich der Basisblock in einem einheitlichen Bereich befindet. Bei einem Ansatz wird dies bestimmt, wenn die Bereichszählungen erzeugt werden, und diese Betrachtung des vorherigen Frames bereits in die Bereichszählung einbezogen ist, die in den oben beschriebenen Tabellen gespeichert ist. Bei einem weiteren Ansatz wird der vorherige Frame jedoch später und separat betrachtet. In diesem Fall kann der Prozess 500 dann, wenn bestimmt wird, dass sich ein oder mehrere Basisblöcke innerhalb des aktuellen Blocks oder Vorhersageblocks mit übereinstimmenden Hash-Codes aufgrund der gespeicherten Zählung nicht in einem einheitlichen Bereich befinden, „Hash zeitlich gemeinsamer Eintrag?“ 566 umfassen. An diesem Punkt wird der vorherige Frame an den zu analysierenden Basisblöcken auf einen einheitlichen Bereich (oder zeitlichen gemeinsamen Eintrag) überprüft, indem die Bereichszählungen des vorherigen Frames betrachtet werden. Wenn ein solcher Bereich oder eine solche Gemeinsamkeit existiert, werden die Hash-Codes geprüft. Wenn einer oder mehrere der Basis-Hash-Codes des einen oder der mehreren Basisblocks in dem aktuellen Frame gleich einem oder mehreren der Hash-Codes der entsprechend positionierten Basisblöcke des Bereichs des vorherigen Frames sind, dann können die Referenzbasisblöcke und damit die Basisblöcke des aktuellen Blocks oder des Vorhersageblocks auf dem aktuellen Frame immer noch als innerhalb eines einheitlichen Bereichs liegend betrachtet werden und der Vorhersageblock oder der aktuelle Block wird als in dem einheitlichen Bereich befindlich behandelt. Wenn kein flacher Bereich und kein gemeinsamer Eintrag vorhanden sind, fährt der Prozess mit der nachstehenden Operation 570 fort, um die Vorhersagemodi anzupassen, wenn dies gewünscht wird.
  • Wenn ein einheitlicher Bereich oder ein zeitlich gemeinsamer Eintrag für einen zu analysierenden aktuellen Block oder Vorhersageblock detektiert wird, kann der Prozess 500 ein „Anpassen des Block-QP“ 568 umfassen. Für diese Operation können die vorindizierten Informationen, welche Bereiche einheitlich sind und dominant sind, verwendet werden, um die Qualität zu verbessern und die Codierungsaufgaben zu beschleunigen. Wenn das Verfahren den Hash-Code des Quellblocks oder des aktuellen Blocks überprüft und seinen Hash-Wert überprüft, kann dem aktuellen Block oder Vorhersageblock ein niedrigerer Quantisierungsparameterwert (QP) zugewiesen werden, wenn bestimmt wird, dass er mit einem Bereich übereinstimmt, der häufig in dem Bild gefunden wird, um die Qualität des Blocks zu erhöhen. Da sich der Block innerhalb eines Bereichs mit häufig wiederholten Bilddaten befindet, kann der Block hoher Qualität sehr gut in andere Bereiche kopiert werden, wodurch auch die Qualität dieser Bereiche erhöht wird. Es ist zu beachten, dass der Codierer die Erhöhung der Bits, die durch Erhöhen der Qualität der Blöcke erzeugt wird, kompensieren kann. Insbesondere führen die zusätzlichen Bits, die durch Reduzieren des QP erzeugt werden, um die Qualität für den ersten Block zu verbessern, dazu, dass aufgrund der Detektion der einheitlichen Bereiche weniger Bits für die zukünftigen IBC-Referenzen desselben Blocks sowie für zukünftige Frames, die sich zurück auf die einheitlichen Bereiche beziehen können, benötigt werden. In diesem Fall kann eine Codierersteuerung den QP anpassen, indem der QP relativ zu der Häufigkeit verringert wird, mit der auf den Block verwiesen wird, wenn ein einheitlicher Bereich detektiert wird. Ein Block, der eine Referenz für die Hälfte des Frames ist, könnte einen viel niedrigeren QP erhalten als ein Block, auf den nur vier oder fünf andere Blöcke verweisen.
  • Unabhängig davon, ob festgestellt wurde, dass sich ein aktueller Block oder ein Vorhersageblock in einem einheitlichen Bereich befindet oder nicht, kann der Prozess 500 mit „Ändern, welche Vorhersagemodus-Kandidatentypen für die Vorhersage in Betracht gezogen werden“ 570 fortgesetzt werden. Bei einer Option wird wie oben erwähnt der hashbasierte Suchkandidat, wenn er festgelegt ist, als Vorhersage verwendet, ohne Berücksichtigung anderer Kandidatenvorhersagen und Vorhersagemodusauswahl. Bei einem weiteren Ansatz kann jedoch eine Intra-Bewegungssuche nach IBC übereinstimmende Blöcke als Startort verwenden, um eine lokale Suche anstelle einer größeren vollständigen Suche durchzuführen, wenn Hash-Code-Übereinstimmungen in aktuellen Blöcken und Vorhersageblöcken, die nicht einheitlich sind, gefunden wurden oder die Einheitlichkeit des Bereichs nicht berücksichtigt wurde. Andernfalls kann bei einer weiteren Option die Anzahl oder Art der Vorhersagemodi, die als Kandidaten betrachtet werden, deaktiviert werden, wenn ein hashbasierter Suchkandidat vorhanden ist. So kann beispielsweise die Qualität der Blöcke verbessert werden, indem Kandidaten gefunden werden, die möglicherweise nicht durch die normalen Nicht-IBC-Intra- und -Inter-Vorhersagemodi wie räumliche Nachbarn und hierarchische Bewegungsschätzungssuche (HME-Suche) auftauchen, so dass diese Vorhersageverfahren deaktiviert werden könnten, wenn eine hashbasierte Vorhersage vorliegt.
  • Wenn sich die Vorhersage oder der aktuelle Block in einem einheitlichen Bereich befindet, können Vorhersagemodi zusätzlich zu den hashbasierten Suchmodi Kandidatenvorhersagemodi sein, die zu einer höheren Verzerrungsrate führen. Je höher die Verzerrungsrate ist, desto geringer ist die Qualität, aber auch die Anzahl der zu berechnenden Bits. Insbesondere dann, wenn ein Bereich im Wesentlichen oder vollständig einheitlich ist, kann der Kompromiss zwischen verschiedenen Vorhersagemodi durch Berücksichtigung der Einheitlichkeit bei der Auswahl der Intra-Modus-Optionen dies berücksichtigen, um einen Modus auszuwählen, der der Region mehr Einheitlichkeit verleiht und somit die Qualität des Blocks verbessert. Beispielsweise würde normalerweise ein horizontaler Intra-Vorhersagemodus eine geringere Ratenverzerrung liefern und normalerweise bei aktuellen Bitkosten ausgewählt werden. Wenn man jedoch weiß, dass ein Bereich eines Bildes einheitlich ist, könnte ein DC-Intra-Vorhersagemodus verwendet werden, auch wenn eine hohe Anzahl von Bits erforderlich ist, um einen Koeffizienten zum Korrigieren der DC-Vorspannung zu verwenden, und obwohl das Ergebnis ein höherer Ratenverzerrungswert (RD-Wert) sein kann. Zukünftige Verweise auf diesen einheitlichen Block werden dann genauer sein und mit geringerer Wahrscheinlichkeit subjektive Artefakte aufweisen.
  • Bei anderen Optionen können die verfügbaren Vorhersagemodi aufgrund der einheitlichen Bereiche ebenfalls reduziert werden. Sobald bestimmt wird, dass sich ein aktueller Block oder Vorhersageblock in einem einheitlichen Bereich befindet, können bestimmte Vorhersagemodi, die in einen solchen Bereich schlecht passen, deaktiviert werden. Dies kann Paletten- oder Intra-Subpartitions-Modi umfassen, die einen erheblichen Rechenaufwand erfordern können. Das Deaktivieren solcher Vorhersagemodi zugunsten der relativ schnell berechneten Hash-Codes und Vergleiche kann die Gesamtleistung verbessern.
  • Optional kann der Prozess 500 auch ein „Detektieren eines Szenenwechsels“ 572 umfassen. Wenn hier bestimmt wird, dass sich eine Schwellenanzahl von Basisblöcken nicht mehr in einem Bereich relativ zu den Bereichen in einem vorherigen Frame befindet, wird daraus geschlossen, dass eine neue Szene detektiert wird. Sobald eine neue Szene detektiert wird, kann der Codierer eine neue GOP starten, den Frame-Typ anpassen (z. B. einen Nicht-Referenz-B-Frame zu einem Referenz-B-Frame machen) und/oder den QP anpassen. Bei einer weiteren Option kann zudem jegliches hashbasierte IBC, der auf frühere Frames verweist, deaktiviert werden, da Bilddaten vorhanden sind, die von Frame zu Frame gleich bleiben.
  • Der Prozess 500 kann ein „Speichern von Nachbarpixeln“ 574 umfassen. Hier hat der Codierer zusätzlich zu den QP- und/oder Vorhersagemodusanpassungen bei der Detektion der einheitlichen Bereiche eine verbesserte Fähigkeit vorherzusagen, welche Nachbarpixelbilddaten bald benötigt werden, um Bilddatenblöcke in dem aktuellen Frame zu rekonstruieren, und kann diese Bilddaten für eine relativ direkte Verwendung speichern. Insbesondere muss der Codierer normalerweise warten, bis die Bilddaten der Nachbarpixel decodiert und/oder abgerufen wurden, um ein aktuelles Pixel zu decodieren. Die Nachbarn befinden sich normalerweise in der Zeile über oder links von dem aktuellen Pixel. Wenn also ein Block einem Intra-Block-Kopieren unterzogen wird, kann eine Pipeline für die Intra-Vorhersage stocken, während darauf gewartet wird, dass die Nachbarpixel abgerufen werden. Da der Codierer weiß, welche Pixelorte sich in einem einheitlichen Bereich befinden und dass diese Pixelorte mehrmals mit denselben Bilddaten kopiert werden, kann der Codierer die Nachbarpixelwerte des Bereichs vorab dort speichern, wenn sie für schnelleren Zugriff zugänglich sind, um eine Verlangsamung der Pipeline zu vermeiden, z. B. in dem bordinternen RAM oder Cache statt in externem RAM. Die Nachbarpixel können auch vorabgerufen werden, sobald ein Hash berechnet wurde, was an sich eine Leistungsverbesserung darstellt, da normalerweise eine endgültige Modusentscheidung getroffen würde, die dann eine Transformation, Quantisierung, inverse Quantisierung und inverse Transformation durchlaufen müsste, bevor die Nachbarpixel beispielsweise bereit sind, Restpixel für die Nachbarvorhersage zu erzeugen. Dies kann erfolgen, da bekannt ist, dass ein einheitlicher Bereich existiert und IBC für den einheitlichen Bereich ausgewählt wird, der dieselbe Rekonstruktion aufweist.
  • Nachdem Codiererparameter und Vorhersagemodi wie oben beschrieben verwendet worden sind, um aktuelle Blöcke oder Vorhersageblöcke zu rekonstruieren, oder währenddessen, und unabhängig davon, ob der Codierer übereinstimmende Hash-Codes und/oder einheitliche Bereiche auf dem vorherigen aktuellen Block oder Quellblock detektiert hat oder nicht, kann der Prozess 500 ferner die Anfrage „Mehr Quellblöcke?“ 576 umfassen. Der Codierer prüft dann, ob noch Quellblöcke in dem aktuellen Frame decodiert werden müssen. Wenn nicht, endet der Prozess für den aktuellen Frame und der nächste Frame kann unter Wiederholung des Prozesses 500 analysiert werden, bis alle oder einzelne Frames mit Intra-Codierung analysiert sind.
  • Wenn mehr Quellblöcke (oder aktuelle Blöcke) auf dem aktuellen Frame sind, die noch nicht decodiert wurden, kann der Prozess 500 ein „Erhalten des nächsten aktuellen Quellblockorts“ 578 umfassen, was auch ein Erhalten der Bilddaten des nächsten Quellblocks als umfassen kann. Die Quellblöcke können im Allgemeinen nach Rasterabtastreihenfolge, großen Partitionen wie Slices, Kacheln oder Segmenten oder in jeder anderen logische Reihenfolge erhalten werden.
  • Der Prozess 500 kann dann ein „Aktualisieren eines Referenz-Frames auf der Referenz-Hash-Tabelle“ 580 umfassen, wobei die Referenz-Hash-Tabelle oder -Liste mit den berechneten Referenz-Basis-Hash-Codes und bei Verwendung dem Ort dieser Basisblöcke des aktuellen Blocks, der gerade rekonstruiert wird, aktualisiert wird. Diese Operation wird ausgeführt, wenn der durch die Referenz-Hash-Tabelle oder -Liste dargestellte Referenz-Frame nur die Basis-Hash-Codes bereits rekonstruierter Quellblöcke enthält. Bei ganzen Frames befinden sich solche Hash-Codes möglicherweise bereits in der Referenz-Hash-Tabelle und in diesem Fall kann ein Indikator für einzelne Einträge auf „decodiert“ gesetzt werden, wenn eine solche Aktualisierung erforderlich ist. Der Prozess kehrt dann zu Operation 532 zurück, um den nächsten Quellblock (oder aktuellen Block) zu analysieren.
  • Unter Bezugnahme auf eine weitere Alternative kann die Vorverarbeitung 504 Operationen zum Anwenden des hier offenbarten hashbasierten Such-IBC auf von einer natürlichen Kamera aufgenommenes Video umfassen, so dass der Prozess 500 auf natürliche Bilder angewendet werden kann. Insbesondere ist das hashbasierte Suchverfahren für das Intra-Block-Kopieren normalerweise für Bildschirminhalt reserviert, da natürlicher Inhalt aufgrund kleiner Variationen bei Kamerasensoren tendenziell kleine Abweichungen (wie weißes Rauschen) aufweist. Das Rauschen macht es unwahrscheinlich, dass Hash-Code-Übereinstimmungen gefunden werden können, wenn Übereinstimmungen vorhanden sein sollten, und daher ist eine genaue Übereinstimmung von Frame zu Frame oder innerhalb eines Frames für einen gesamten Block unwahrscheinlich. Es ist jedoch wünschenswert, die hashbasierte Suche auf natürliches Video anzuwenden, um die Qualität zu erhöhen und die Leistungsfähigkeit zu verbessern, indem das hashbasierte Suchverfahren oder die Pipeline hierin umfunktioniert wird, um die Geschwindigkeit von Vorhersagemodusentscheidungen für natürlichen Inhalt zu erhöhen.
  • Um die hashbasierten Suchen auf natürlichen Inhalt anzuwenden, können Vorverarbeitungsoperationen speziell für hashbasierte Suchen durchgeführt werden, um detektierte Hash-Code-Übereinstimmungen wahrscheinlicher zu machen. Dies umfasst eine Kombination aus Entrauschen, Heruntertasten und Verkleinern, die auf Pixelbilddaten des aktuellen Frames angewendet wird, bevor Hash-Abgleichsoperationen ausgeführt werden.
  • Beispielsweise kann, nachdem die Vorverarbeitungseinheit des Codierers eine allgemeine erste Entrauschung auf das Eingabe-Frame angewendet hat, eine zweite IBC-Entrauschungsoperation auf den aktuellen Frame angewendet werden, wenn IBC auf den Frame angewendet werden soll. Andernfalls könnte die zweite Entrauschung auf alle Frames angewendet werden, falls IBC angewendet werden soll. Das IBC-Entrauschen kann Techniken wie das Detektieren von Kanten und das Zwingen von Pixeln auf einen einheitlichen Wert, der sich nicht entlang der Kante befindet, anwenden, um den IBC-Abgleich zu verbessern. Dies kann die gleiche Technik sein, wie sie beim allgemeinen ersten Entrauschen verwendet wird, oder auch nicht. Das Wiederholen derselben Entrauschungsalgorithmen wird mehr Rauschen entfernen. Bei einer Form kann auch das erste allgemeine Entrauschen ausreichend sein, so dass ein zweites IBC-Entrauschen weggelassen werden kann. In diesem Fall sollte beim ersten allgemeinen Entrauschen eine Standardtechnik zum Entfernen von weißem Rauschen verwendet werden.
  • Heruntertakten bezieht sich auf ein Entfernen einer bestimmten Anzahl von niedrigstwertigen Bits (LSBs), beispielsweise vier, um die Bitlänge der Chroma- und Luminanzbilddaten zu verringern, und in einem Beispiel von 10 bpp (Bits pro Pixel) auf 6 bpp durch Entfernen der vier rechten Ziffern der 10-Bit-Werte. Dies hat die Wirkung, dass +/-16 gerundet oder skaliert wird, indem 1024 mögliche Werte auf 64 Werte reduziert werden. Dies erhöht die Wahrscheinlichkeit erheblich, eine mögliche Übereinstimmung basierend auf übereinstimmenden Bildwerten, die zur Bildung der Hash-Codes verwendet werden, zu finden.
  • Zudem führt die durch das Heruntertakten verursachte Rundung dazu, dass subtile kleine Rauschgradienten von Pixel zu Pixel entfernt werden, wodurch lokale einheitlichere Bereiche auf dem Bild gebildet werden. Somit wirkt die Rundung als zusätzliches Entrauschen, da die Rundung von Natur aus eine Wahrscheinlichkeit berücksichtigt, dass ein Gradient gegenüber dem Rauschen Teil des Bildinhalts ist. Infolgedessen werden bei jedem Block diese subtilen kleinen Gradienten entfernt, um ein glatteres Bild mit höherer Qualität zu erzeugen und den Abgleich zu erleichtern.
  • Das Verkleinern kann sich auf ein Abtasten der Bilddaten in jedem horizontalen und/oder vertikalen Intervall in dem aktuellen Bild beziehen, wie beispielsweise in jedem zweiten Pixel. In einem Beispiel kann das Verkleinern ein Abtasten von zwei sein, bei dem die Bildgröße horizontal und vertikal um den Faktor zwei reduziert wird. Andernfalls können Kombinationstechniken wie die Mittelung verwendet werden. Insbesondere können bilineare und bikubische Techniken verwendet werden, um einige Beispiele zu nennen.
  • Die drei Operationen: Entrauschen, Heruntertakten und Verkleinern (DDD) können in jeder Reihenfolge durchgeführt werden, die sich als effizient herausstellt, und jegliche oder eine Kombination der Operationen kann auf Wunsch anstelle aller drei ausgeführt werden. Durch diesen Ansatz werden auch die modifizierten Bilddaten nur für Hash-Abgleich verwendet, während die endgültige Vorhersagemodus-Entscheidung weiterhin die vollständigen ursprünglichen oder rekonstruierten Pixelwerte verwendet, um die Vorhersagen der Blöcke mit übereinstimmenden Hash-Codes zu bilden.
  • Zusätzlich dazu, dass es dem Codierer ermöglicht wird, hashbasiertes Such-IBC auf natürliches Video anzuwenden, besteht ein weiterer Vorteil der DDD-Operationen darin, dass der Codierer Vorhersagemodi für einen aktuellen Block oder Vorhersageblock besser auswählen kann, um die Leistungsfähigkeit und Qualität der Bilder zu erhöhen. Beispielsweise kann das Heruntertakten aufgrund der oben erwähnten Rundung zu größeren einheitlichen Bereichen führen und dies kann durch die oben erwähnten Zähloperationen mit dem Prozess 500 verfolgt werden, um diese Bereiche auf dem Referenz-Frame zu verfolgen. In diesem Fall kann der Codierer die Hash-Pipeline umfunktionieren, um die Leistungsfähigkeit und Qualität zu verbessern, indem er die Ganzzahlsuche für natürliches Video und andere Kompressionssuchverfahren (z. B. Suchen nach kleineren Blockgrößen) deaktiviert, die wahrscheinlich nicht die endgültig ausgewählte Vorhersage an den einheitlichen Bereichen des Referenz-Frames sein werden. Der Codierer kann die Qualität der einheitlichen Bereiche des natürlichen Videos weiter verbessern, indem er den QP für diese einheitlichen Bereiche verringert, wenn häufig auf diese Bezug genommen wird, wie dies durch eine Schwelle festgelegt werden kann und wie es oben bei der QP-Anpassung des Bildschirminhaltsvideos erwähnt wurde.
  • Obwohl jede Implementierung der hierin enthaltenen beispielhaften Prozesse oder Systeme die Durchführung aller gezeigten Operationen in der dargestellten Reihenfolge umfassen kann, ist die vorliegende Offenbarung in dieser Hinsicht nicht beschränkt, und in verschiedenen Beispielen kann die Implementierung jeglicher der hierin enthaltenen Prozesse die Durchführung nur einer Teilmenge der gezeigten Operationen und/oder in einer anderen Reihenfolge als dargestellt umfassen.
  • In Implementierungen können hier beschriebene Merkmale als Antwort auf Befehle ausgeführt werden, die von einem oder mehreren Computerprogrammprodukten bereitgestellt werden. Solche Programmprodukte können signaltragende Medien umfassen, die Befehle bereitstellen, die, wenn sie beispielsweise von einem Prozessor ausgeführt werden, die hierin beschriebene Funktionalität bereitstellen können. Die Computerprogrammprodukte können in beliebiger Form eines oder mehrerer maschinenlesbarer Medien bereitgestellt werden. So kann beispielsweise ein Prozessor, der einen oder mehrere Prozessorkerne aufweist, ein oder mehrere hier beschriebene Merkmale als Antwort auf Programmcode und/oder Befehle oder Befehlssätze durchführen, die dem Prozessor von einem oder mehreren maschinenlesbaren Medien vermittelt werden. Im Allgemeinen kann ein maschinenlesbares Medium Software in Form von Programmcode und/oder Befehlen oder Befehlssätzen vermitteln, die jegliche der hierin beschriebenen Vorrichtungen und/oder Systeme dazu veranlassen können, zumindest Teile der hier beschriebenen Merkmale zu implementieren. Wie es zuvor erwähnt wurde, kann bei einer weiteren Form ein nichttransitorischer Artikel, wie beispielsweise ein nichttransitorisches computerlesbares Medium, mit einem der oben genannten Beispiele oder anderen Beispielen verwendet werden, außer dass an sich kein transitorisches Signal enthalten ist. Es umfasst diejenigen Elemente außer einem Signal an sich, die Daten vorübergehend auf „transitorische“ Weise halten können, wie z. B. RAM und so weiter.
  • Wie er in einer hier beschriebenen Implementierung verwendet, bezieht sich der Begriff „Modul“ auf eine beliebige Kombination von Softwarelogik, Firmwarelogik und/oder Hardwarelogik, die dazu ausgelegt ist, die hierin beschriebene Funktionalität bereitzustellen. Software kann als Softwarepaket, Code und/oder Befehlssatz oder Befehle verkörpert sein und „Hardware“, wie sie in einer hierin beschriebenen Implementierung verwendet wird, kann beispielsweise einzeln oder in beliebiger Kombination festverdrahtete Schaltungen, programmierbare Schaltungen, Zustandsmaschinenschaltungen und/oder Firmware, die Befehle speichert, die von programmierbaren Schaltungen ausgeführt werden, umfassen. Die Module können zusammen oder einzeln als Schaltungsanordnung verkörpert sein, die Teil eines größeren Systems ist, beispielsweise einer integrierten Schaltung (IC), eines Ein-Chip-Systems (SoC) und so weiter. Beispielsweise kann ein Modul in einer Logikschaltungsanordnung zur Implementierung der hier diskutierten Codierungssysteme über Software, Firmware oder Hardware enthalten sein.
  • Wie er in einer hierin beschriebenen Implementierung verwendet wird, bezieht sich der Begriff „Logikeinheit“ auf eine beliebige Kombination von Firmwarelogik und/oder Hardwarelogik, die dazu ausgelegt ist, um die hierin beschriebene Funktionalität bereitzustellen. Die „Hardware“, wie sie in einer hierin beschriebenen Implementierung verwendet wird, kann beispielsweise einzeln oder in einer beliebigen Kombination festverdrahtete Schaltungen, programmierbare Schaltungen, Zustandsmaschinenschaltungen und/oder Firmware, die Befehle speichert, die von programmierbaren Schaltungen ausgeführt werden, umfassen. Die Logikeinheiten können zusammen oder einzeln als Schaltungsanordnung verkörpert sein, die Teil eines größeren Systems ist, beispielsweise einer integrierten Schaltung (IC), eines Ein-Chip-Systems (SoC) und so weiter. Beispielsweise kann eine Logikeinheit in einer Logikschaltungsanordnung zur Implementierung der Firmware oder Hardware der hier diskutierten Codierungssysteme enthalten sein. Fachleute werden erkennen, dass Operationen, die von Hardware und/oder Firmware ausgeführt werden, alternativ über Software implementiert werden können, die als Softwarepaket, Code und/oder Befehlssatz oder Befehle verkörpert sein kann, und auch erkennen, dass die Logikeinheit schätzen auch einen Teil Software verwenden kann, um ihre Funktionalität zu implementieren.
  • Wie er in jeder hierin beschriebenen Implementierung verwendet wird, kann sich der Begriff „Komponente“ auf ein Modul oder eine Logikeinheit beziehen, so wie diese Begriffe oben beschrieben sind. Dementsprechend kann sich der Begriff „Komponente“ auf eine beliebige Kombination von Softwarelogik, Firmwarelogik und/oder Hardwarelogik beziehen, die dazu ausgelegt ist, die hierin beschriebene Funktionalität bereitzustellen. Beispielsweise werden Fachleute erkennen, dass Operationen, die von Hardware und/oder Firmware ausgeführt werden, alternativ über ein Softwaremodul implementiert werden können, das als Softwarepaket, Code und/oder Befehlssatz oder Befehle verkörpert sein kann, und auch erkennen, dass die Logikeinheit schätzen auch einen Teil Software verwenden kann, um ihre Funktionalität zu implementieren.
  • Unter Bezugnahme auf 10 kann ein beispielhaftes Bildverarbeitungssystem (oder Videocodiersystem) 1000 zum Bereitstellen einer Videocodierung mit Intra-Block-Kopieren gemäß mindestens einigen Implementierungen der vorliegenden Offenbarung vorgesehen sein. In der dargestellten Implementierung kann das System 1000 einen oder mehrere Prozessoren 1003, eine oder mehrere Verarbeitungseinheiten 1030 zum Bereitstellen des hier diskutierten Codierers und Decodierers, optional eine oder mehrere Bildgebungsvorrichtungen 1001 zum Erfassen von Bildern, eine Antenne 1002 zum Empfangen oder Senden von Bilddaten, eine Anzeigevorrichtung 1005 und einen oder mehrere Speicher 1004 umfassen. der eine oder die mehreren Prozessoren 1003, der Speicher 1004 und/oder die Anzeigevorrichtung 1005 können in der Lage sein, miteinander beispielsweise über einen Bus, Drähte oder einen anderen Zugang zu kommunizieren. In verschiedenen Implementierungen kann die Anzeigevorrichtung 1005 in das System 1000 integriert oder getrennt von dem System 1000 implementiert sein.
  • Wie es in 10 gezeigt und oben diskutiert ist, können die Verarbeitungseinheit(en) 1030 Logikmodule oder -schaltungen 1050 mit einer Vorverarbeitungseinheit 1052, die Bilddaten zum Codieren modifiziert, und einem Codierer 1054, der ein Codierer 200 sein oder diesen enthalten könnte, aufweisen. Der Codierer 1054 kann eine Decodierschleifeneinheit 1056 mit einer Rekonstruktionseinheit 1058 zum Rekonstruieren transformierter und quantisierter Bilddaten, eine Filtereinheit 1060 zum Verfeinern der rekonstruierten Bilddaten, eine Inter-Vorhersageeinheit 1062 und eine Intra-Vorhersageeinheit 1064 aufweisen. Die Intra-Vorhersageeinheit 1064, die der Intra-Prädiktoreinheit 224 (2) gleich oder ähnlich ist, kann eine Nicht-IBC-Einheit 1066, die räumliche Vorhersagekandidaten wie horizontal oder DC für Intra-Vorhersage-Modi erzeugt, und eine IBC-Einheit 1068, die sowohl eine IBC-Bewegungssuche für Intra-Vorhersage als auch einen Großteil der hier offenbarten und oben beschriebenen hashbasierten Such-IBC-Operationen durchführt, aufweisen. Eine Vorhersagemodusauswahleinheit 1078 kann den Vorhersagemodus auswählen, der zum Erzeugen eines Restes zum Modifizieren der Originaldaten und zur Kompression verwendet wird. Der Codierer 1054 kann zudem andere Codiereinheiten 1080 aufweisen, die nicht erwähnte Videocodiereinheiten umfassen können, einschließlich beispielsweise einiger oder aller der anderen Einheiten des oben beschriebenen Codierers 200. All diese erfüllen die oben ausführlich beschriebenen Aufgaben, wie es die Bezeichnung der Einheit oder des Moduls angibt.
  • Wie zu erkennen sein wird, können die in 10 dargestellten Module eine Vielzahl von Software- und/oder Hardwaremodulen und/oder Modulen, die mittels Software oder Hardware oder Kombinationen davon implementiert sein können, umfassen. Beispielsweise können die Module als Software über Verarbeitungseinheiten 1030 implementiert werden oder die Module können über einen dedizierten Hardware-Abschnitt implementiert werden. Das System 1000 kann auch auf verschiedene Arten implementiert werden. Beispielsweise kann das System 1000 (mit Ausnahme der Anzeigevorrichtung 1005) als ein einzelner Chip oder eine Vorrichtung mit einem Beschleuniger oder einer Grafikprozessoreinheit (GPU) implementiert sein, die Bildsignalprozessoren (ISPs), eine Vierkern-Zentralverarbeitungseinheit und/oder ein Speichercontroller-Eingabe/Ausgabe-Modul (Speichercontroller-E/A-Modul) aufweisen kann oder nicht. In anderen Beispielen kann das System 1000 (wiederum ohne die Anzeigevorrichtung 1005) als Chipsatz oder als Ein-Chip-System (SoC) implementiert sein. Es versteht sich, dass die Antenne 1002 auch verwendet werden könnte, um Bilddaten zum Codieren zu empfangen.
  • Ansonsten können die Prozessoren 1003 eine beliebige geeignete Implementierung aufweisen, einschließlich beispielsweise Zentralverarbeitungseinheiten (CPUs), Mikroprozessoren, Mehrkernprozessoren, anwendungsspezifische integrierte Schaltungen, Chips, Chipsätze, programmierbare Logikvorrichtungen, Grafikkarten, integrierte Grafik, Allzweck-Grafikverarbeitungseinheit(en), GPUs mit fester Funktion wie Bildsignalprozessoren (ISPs) 1006, Digitalsignalprozessoren (DSPs) usw., SoCs, andere Beschleuniger oder dergleichen.
  • Zudem können die Speicher 1004 die Hash-Tabelle(n) 1082 wie oben beschrieben speichern und können intra-rekonstruierte Puffer 1084 aufweisen, um entweder eine Version der Originalbilddaten oder rekonstruierte Bilddaten zu speichern, um falls erforderlich den Referenz-Frame und/oder Quellblöcke auf dem aktuellen Frame zu bilden, und diese können verwendet werden, um die Bildblöcke eines Frames in Abhängigkeit von den Hash-Übereinstimmungen zu rekonstruieren. Die Speicher 1004 können jede Art von Speicher wie beispielsweise ein flüchtiger Speicher (z. B. statischer Direktzugriffsspeicher (SRAM), dynamischer Direktzugriffsspeicher (DRAM) usw.) oder ein nichtflüchtiger Speicher (z. B. Flash-Speicher usw.) und so weiter sein. In einem nicht einschränkenden Beispiel können die Speicher 1004 auch mittels eines Cache-Speichers implementiert sein.
  • In verschiedenen Implementierungen kann das beispielhafte Videocodiersystem 1000 die Bildgebungsvorrichtung 1001 verwenden, um natürlich erfasste Bilddaten zu erzeugen oder zu empfangen. Das System 1000 kann Bildschirminhalt über die Kamera, die Antenne 1002 oder eine andere drahtgebundene Verbindung empfangen. Die Kamera kann auf verschiedene Arten implementiert sein. So kann in einer Form das Bildverarbeitungssystem 1000 eine oder mehrere Digitalkameras oder andere Bilderfassungsvorrichtungen sein und die Bildgebungsvorrichtung 1001 kann in diesem Fall die Kamera-Hardware und die Kamerasensor-Software, das Kameramodul oder die Kamerakomponente sein. In anderen Beispielen kann das Videocodiersystem 1000 eine Bildgebungsvorrichtung 1001 aufweisen, die eine oder mehrere Kameras aufweist oder sein kann, und Logikmodule 1050 können zur weiteren Verarbeitung der Bilddaten fern mit der Bildgebungsvorrichtung 1001 kommunizieren oder auf andere Weise mit dieser kommunikationstechnisch gekoppelt sein.
  • Somit kann das Videocodiersystem 1000 ein Smartphone, ein Tablet, ein Laptop oder eine andere mobile Vorrichtung wie eine am Körper tragbare Vorrichtung einschließlich intelligenter Brillen, intelligenter Kopfhörer, Übungsbänder und so weiter sein oder eine Teil davon sein. In jedem dieser Fälle kann eine solche Technologie eine Kamera wie etwa ein Digitalkamerasystem, eine dedizierte Kameravorrichtung oder ein abbildendes Telefon oder -Tablet umfassen, sei es eine Standbild- oder Videokamera, eine Kamera, die einen Vorschaubildschirm bereitstellt, oder eine Kombination davon. Somit kann die Bildgebungsvorrichtung 1001 in einer Form Kamera-Hardware und -Optik umfassen, die einen oder mehrere Sensoren sowie Autofokus-, Zoom-, Blenden-, ND-Filter-, Autobelichtungs-, Blitz- und Aktorsteuerungen aufweist. Die Bildgebungsvorrichtung 1001 kann auch eine Linse, einen Bildsensor mit einem RGB-Bayer-Farbfilter, einen analogen Verstärker, einen A/D-Umsetzer, andere Komponenten zum Umsetzen von einfallendem Licht in ein digitales Signal und dergleichen und/oder Kombinationen davon aufweisen. Das digitale Signal kann hier auch als Rohbilddaten bezeichnet werden.
  • Andere Formen umfassen eine Bildgebungsvorrichtung vom Kamerasensortyp oder dergleichen (z. B. eine Webcam oder einen Webcamsensor oder einen anderen Komplementär-Metall-Oxid-Halbleiter-Bildsensor (CMOS)) ohne die Verwendung einer Rot-Grün-Blau-Tiefenkamera (RGB-Tiefenkamera) und/oder eines Mikrofonarrays, um zu orten, wer spricht. In anderen Beispielen kann eine RGB-Tiefenkamera und/oder ein Mikrofonarray zusätzlich zu oder alternativ zu einem Kamerasensor verwendet werden. In einigen Beispielen kann die Bildgebungsvorrichtung 1001 mit einer Blickerfassungskamera versehen sein. Ansonsten kann die Bildgebungsvorrichtung 1001 eine beliebige andere Vorrichtung sein, die digitale Bilder aufzeichnet, anzeigt oder verarbeitet, wie etwa Videospieltafeln oder -konsolen, Beistellkästen usw.
  • Wie es dargestellt ist, kann jede dieser Komponenten in der Lage sein, miteinander und/oder mit Abschnitten der Logikmodule 1050 und/oder der Bildgebungsvorrichtung 1001 zu kommunizieren. Somit können die Prozessoren 1003 sowohl mit der Bildgebungsvorrichtung 1001 als auch mit den Logikmodulen 1050 zum Betreiben dieser Komponenten kommunikationstechnisch gekoppelt sein. Obwohl das Bildverarbeitungssystem 1000, wie es in 10 gezeigt ist, einen bestimmten Satz von Blöcken oder Aktionen aufweisen sein, die bestimmten Komponenten oder Modulen zugeordnet sind, können diese Blöcke oder Aktionen anderen Komponenten oder Modulen zugeordnet sein als der bestimmten Komponente oder dem bestimmten Modul, die hier dargestellt sind.
  • Unter Bezugnahme auf 11 kann ein beispielhaftes System 1100 gemäß der vorliegenden Offenbarung und verschiedenen Implementierungen beispielsweise das System 1000 verkörpern. Beispielsweise kann das System 1100 in einen Personalcomputer (PC), einem Laptop-Computer, einem Ultra-Laptop-Computer, einem Tablet, einem Berührungsfeld, einem tragbaren Computer, einem in der Hand getragenen Computer, einem Palmtop-Computer, einem persönlichen digitalen Assistenten (PDA), einem Mobiltelefon oder einer Kombination aus Mobiltelefon/PDA, einem Fernseher, einer intelligenten Vorrichtung (z. B. Smartphone, Smart-Tablet, intelligenter Lautsprecher oder intelligenter Fernseher), einer mobilen Internetvorrichtung (MID), einer Nachrichtenvorrichtung, einer Datenkommunikationsvorrichtung usw. integriert sein.
  • In verschiedenen Implementierungen umfasst das System 1100 eine Plattform 1102, die kommunikationstechnisch mit einer Anzeige 1120 gekoppelt ist. Die Plattform 1102 kann Inhalt von einer Inhaltsvorrichtung wie etwa einer oder mehreren Inhaltsdienstvorrichtungen 1130 oder einer oder mehreren Inhaltsliefervorrichtungen 1140 oder anderen ähnlichen Inhaltsquellen empfangen. Ein Navigationscontroller 1150, der ein oder mehrere Navigationsmerkmale aufweist, kann verwendet werden, um beispielsweise mit der Plattform 1102 und/oder der Anzeige 1120 zu interagieren. Jede dieser Komponenten wird nachstehend ausführlicher beschrieben.
  • In verschiedenen Implementierungen kann die Plattform 1102 eine beliebige Kombination eines Chipsatzes 1105, eines Prozessors 1110, eines Speichers 1112, eines Ablagespeichers 1114, eines Grafikuntersystems 1113, von Anwendungen 1116 und/oder eines Funkvorrichtung 1118 sowie einer oder mehrerer Antennen 1111 umfassen. Der Chipsatz 1105 kann Zwischenkommunikation zwischen dem Prozessor 1110, dem Speicher 1112, dem Ablagespeicher 1114, dem Grafikuntersystem 1113, den Anwendungen 1116 und/oder der Funkvorrichtung 1118 bieten. Beispielsweise kann der Chipsatz 1105 einen Speicheradapter (nicht dargestellt) aufweisen, der eine Zwischenkommunikation mit dem Ablagespeicher 1114 bereitstellen kann.
  • Der Prozessor 1110 kann als ein Prozessor eines Computers mit komplexem Befehlssatz (CISC) oder eines Computers mit reduziertem Befehlssatzcomputer (RISC); x86-Befehlssatz-kompatible Prozessoren, Mehrkern-Prozessoren oder andere Mikroprozessoren oder Zentralverarbeitungseinheiten (CPU) implementiert werden. In verschiedenen Implementierungen kann der Prozessor 1110 Zweikernprozessor(en), Zweikern-Mobilprozessor(en) usw. sein.
  • Der Speicher 1112 kann als flüchtige Speichervorrichtung implementiert sein, wie beispielsweise ein Direktzugriffsspeicher (RAM), ein dynamischer Direktzugriffsspeicher (DRAM) oder ein statischer RAM (SRAM), ohne darauf beschränkt zu sein.
  • Der Ablagespeicher 1114 kann als nichtflüchtige Speichervorrichtung implementiert sein, wie beispielsweise ein Magnetplattenlaufwerk, ein optisches Plattenlaufwerk, ein Bandlaufwerk, eine interne Speichervorrichtung, eine angebundene Speichervorrichtung, ein Flash-Speicher, ein batteriegesicherter SDRAM (synchroner DRAM) und/oder eine über das Netz zugängliche Speichervorrichtung, ohne darauf beschränkt zu sein. In verschiedenen Implementierungen kann der Ablagespeicher 1114 eine Technologie aufweisen, um die Speicherleistung zu verbessern und den Schutz für wertvolle digitale Medien zu verbessern, wenn beispielsweise mehrere Festplatten enthalten sind.
  • Das Grafikuntersystem 1113 kann eine Verarbeitung von Bildern wie Standbildern oder Videos für die Anzeige durchführen. Das Grafikuntersystem 1113 kann beispielsweise eine Grafikverarbeitungseinheit (GPU) oder eine visuelle Verarbeitungseinheit (VPU) sein. Eine analoge oder digitale Schnittstelle kann verwendet werden, um das Grafikuntersystem 1113 und die Anzeige 1120 kommunikationstechnisch zu koppeln. Beispielsweise kann die Schnittstelle eine beliebige hochauflösende Multimedia-Schnittstelle, ein Anzeigeport, drahtlose HDMI und/oder mit drahtlosem HD kompatible Techniken sein. Das Grafikuntersystem 1113 kann in den Prozessor 1110 oder den Chipsatz 1105 integriert sein. In einigen Implementierungen kann das Grafikuntersystem 1113 eine eigenständige Karte sein, die kommunikationstechnisch mit dem Chipsatz 1105 gekoppelt ist.
  • Die hier beschriebenen Grafik- und/oder Videoverarbeitungstechniken können in verschiedenen Hardware-Architekturen implementiert werden, darunter Hardware mit fester Funktion, wie z. B. Videobewegungsschätzmaschinen (VME-Maschinen) oder ähnliche Parallelverarbeitungsschaltungen. Beispielsweise können Grafik- und/oder Videofunktionen in einen Chipsatz integriert sein. Alternativ kann ein diskreter Grafik- und/oder Videoprozessor verwendet werden. Als weitere Implementierung können die Grafik- und/oder Videofunktionen von einem Allzweckprozessor bereitgestellt werden, der einen Mehrkernprozessor umfasst. In anderen Implementierungen können die Funktionen in einer Unterhaltungselektronikvorrichtung implementiert sein.
  • Die Funkvorrichtung 1118 kann eine oder mehrere Funkvorrichtungen umfassen, die Signale unter Verwendung verschiedener geeigneter drahtloser Kommunikationstechniken senden und empfangen können. Solche Techniken können Kommunikation über ein oder mehrere drahtlose Netze hinweg beinhalten. Beispielhafte drahtlose Netze umfassen (ohne darauf beschränkt zu sein) drahtlose lokale Netze (WLANs), drahtlose persönliche Bereichsnetze (WPANs), drahtlose Metropolbereichsnetze (WMANs), Mobilfunknetze und Satellitennetze. Beim Kommunizieren über solche Netze kann die Funkvorrichtung 1118 gemäß einem oder mehreren anwendbaren Standards in einer beliebigen Version arbeiten.
  • In verschiedenen Implementierungen kann die Anzeige 1120 eine(n) beliebige(n) fernsehartige(n) Monitor oder Anzeige umfassen. Die Anzeige 1120 kann beispielsweise einen Computerbildschirm, eine Berührungsschirmanzeige, einen Videomonitor, eine fernsehähnliche Vorrichtung und/oder einen Fernseher umfassen. Die Anzeige 1120 kann digital und/oder analog sein. In verschiedenen Implementierungen kann die Anzeige 1120 eine holographische Anzeige sein. Die Anzeige 1120 kann auch eine transparente Oberfläche sein, die eine visuelle Projektion empfangen kann. Solche Projektionen können verschiedene Formen von Informationen, Bildern und/oder Objekten vermitteln. Beispielsweise können solche Projektionen eine visuelle Überlagerung für eine mobile Anwendung erweiterter Realität (MAR-Anwendung) sein. Unter der Steuerung einer oder mehrerer Softwareanwendungen 1116 kann die Plattform 1102 die Anwenderschnittstelle 1122 auf der Anzeige 1120 anzeigen.
  • In verschiedenen Implementierungen können die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 von einem beliebigen nationalen, internationalen und/oder unabhängigen Dienst gehostet werden und sind somit beispielsweise über das Internet für die Plattform 1102 zugänglich. Die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 können mit der Plattform 1102 und/oder mit der Anzeige 1120 gekoppelt sein. Die Plattform 1102 und/oder die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 können mit einem Netz 1160 gekoppelt sein, um Medieninformationen an das und aus dem Netzwerk 1160 zu übermitteln (z. B. zu senden und/oder zu empfangen). Die eine oder die mehreren Inhaltsliefervorrichtungen 1140 können auch mit der Plattform 1102 und/oder der Anzeige 1120 gekoppelt sein.
  • In verschiedenen Implementierungen können die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 eine Kabelfernsehbox, einen Personalcomputer, ein Netz, ein Telefon, internetfähige Vorrichtungen oder Geräte, die digitale Informationen und/oder Inhalt liefern können, und beliebige andere ähnliche Vorrichtungen, die dazu in der Lage sind, unidirektional oder bidirektional Inhalt zwischen Inhaltsanbietern und der Plattform 1102 und/oder der Anzeige 1120 über das Netz 1160 oder direkt zu übermitteln. Es versteht sich, dass der Inhalt unidirektional und/oder bidirektional zu und von einer der Komponenten in dem System 1100 und einem Inhaltsanbieter über das Netz 1160 übertragen werden kann. Beispiele für Inhalt können beliebige Medieninformationen einschließlich beispielsweise Video, Musik, medizinische Informationen und Spielinformationen und so weiter umfassen.
  • Die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 können Inhalt wie Kabelfernsehprogramme einschließlich Medieninformationen, digitalen Informationen und/oder anderen Inhalt empfangen. Beispiele für Inhaltsanbieter können Kabel- oder Satellitenfernseh- oder Radio- oder Internetinhaltsanbieter sein. Die bereitgestellten Beispiele sollen Implementierungen gemäß der vorliegenden Offenbarung in keiner Weise einschränken.
  • In verschiedenen Implementierungen kann die Plattform 1102 Steuersignale von dem Navigationscontroller 1150 mit einem oder mehreren Navigationsmerkmalen empfangen. Die Navigationsmerkmale des Controllers 1150 können beispielsweise verwendet werden, um mit der Anwenderschnittstelle 1122 zu interagieren. In Implementierungen kann der Navigationscontroller 1150 eine Zeigevorrichtung sein, die eine Computer-Hardwarekomponente (insbesondere eine Mensch-Schnittstellenvorrichtung) sein kann, die es einem Anwender ermöglicht, räumliche (z. B. kontinuierliche und mehrdimensionale) Daten in einen Computer einzugeben. Viele Systeme wie etwa grafische Anwenderoberflächen (GUI) sowie Fernseher und Monitore ermöglichen es dem Anwender, den Computer oder Fernseher über körperliche Gesten zu steuern oder so Daten an diesen zu liefern.
  • Bewegungen der Navigationsmerkmale des Controllers 1150 können auf einer Anzeige (z. B. Anzeige 1120) durch Bewegungen eines Zeigers, Cursors, Fokusrings oder anderen visuellen Indikators, der auf der Anzeige angezeigt wird, wiedergegeben werden. Beispielsweise können unter der Steuerung von Softwareanwendungen 1116 die Navigationsmerkmale, die sich auf dem Navigationscontroller 1150 befinden, auf virtuelle Navigationsmerkmale abgebildet werden, die beispielsweise auf der Anwenderschnittstelle 1122 angezeigt werden. In Implementierungen kann der Controller 1150 keine separate Komponente sein, sondern kann in die Plattform 1102 und/oder die Anzeige 1120 integriert sein. Die vorliegende Offenbarung ist jedoch nicht auf die Elemente oder den hier gezeigten oder beschriebenen Kontext beschränkt.
  • In verschiedenen Implementierungen können Treiber (nicht gezeigt) eine Technologie aufweisen, die es Anwendern beispielsweise ermöglicht, die Plattform 1102 wie einen Fernseher mit einem Knopfdruck nach dem ersten Hochfahren sofort ein- und auszuschalten, wenn sie aktiviert ist. Programmlogik kann es der Plattform 1102 ermöglichen, Inhalt an Medienadapter oder andere Inhaltsdienstvorrichtungen 1130 oder Inhaltsliefervorrichtungen 1140 zu streamen, selbst wenn die Plattform „ausgeschaltet“ ist. Darüber hinaus kann der Chipsatz 1105 beispielsweise Hardware- und/oder Software-Unterstützung für 7.1-Surround-Sound-Audio und/oder hochauflösendes Surround-Audio (7.1) aufweisen. Treiber können einen Grafiktreiber für integrierte Grafikplattformen umfassen. In Implementierungen kann der Grafiktreiber eine Peripherkomponentenschnittstelle-Express-Grafikkarte (PCI-Express-Grafikkarte) umfassen.
  • In verschiedenen Implementierungen können eine oder mehrere der in dem System 1100 gezeigten Komponenten integriert sein. Beispielsweise können die Plattform 1102 und die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 integriert sein oder die Plattform 1102 und die die eine oder die mehreren Inhaltsliefervorrichtungen 1140 können integriert sein, oder die Plattform 1102, die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 und die eine oder die mehreren Inhaltsliefervorrichtungen 1140 können integriert sein. In verschiedenen Implementierungen können die Plattform 1102 und die Anzeige 1120 eine integrierte Einheit sein. Die Anzeige 1120 und die die eine oder die mehreren Inhaltsdienstvorrichtungen 1130 können integriert sein oder die Anzeige 1120 und die eine oder die mehreren Inhaltsliefervorrichtungen 1140 können beispielsweise integriert sein. Diese Beispiele sollen die vorliegende Offenbarung nicht einschränken.
  • In verschiedenen Implementierungen kann das System 1100 als ein drahtloses System, ein drahtgebundenes System oder eine Kombination aus beiden implementiert werden. Bei Implementierung als drahtloses System kann das System 1100 Komponenten und Schnittstellen aufweisen, die für die Kommunikation über ein drahtloses gemeinsam genutztes Medium geeignet sind, wie etwa eine oder mehrere Antennen, Sender, Empfänger, Sendeempfänger, Verstärker, Filter, Steuerlogik usw. Ein Beispiel für gemeinsam genutzte drahtlose Medien kann Abschnitte eines drahtlosen Spektrums wie etwa das HF-Spektrum usw. umfassen. Wenn das System 1100 als drahtgebundenes System implementiert ist, kann es Komponenten und Schnittstellen umfassen, die zur Kommunikation über drahtgebundene Kommunikationsmedien geeignet sind, wie z. B. Eingabe-/Ausgabeadapter (E/A-Adapter), physische Anschlüsse zum Verbinden des E/A-Adapters mit einem entsprechenden drahtgebundenen Kommunikationsmedium, eine Netzschnittstellenkarte (NIC), einen Plattencontroller, einen Videocontroller, einen Audiocontroller und dergleichen. Beispiele für drahtgebundene Kommunikationsmedien können Drähte, Kabel, Metallleitungen, Leiterplatten (PCB), Rückwandplatinen, Vermittlungs-Fabrics, Halbleitermaterial, Drähte mit verdrillten Aderpaaren, Koaxialkabel, Lichtwellenleiter usw. umfassen.
  • Die Plattform 1102 kann einen oder mehrere logische oder physische Kanäle zum Übermitteln von Informationen einrichten. Die Informationen können Medieninformationen und Steuerinformationen umfassen. Medieninformationen können sich auf alle Daten beziehen, die für einen Anwender bestimmten Inhalt repräsentieren. Beispiele für Inhalt können beispielsweise Daten aus einer Sprachkonversation, einer Videokonferenz, einem Streaming-Video, einer E-Mail-Nachricht („E-Mail“), einer Sprachnachricht, alphanumerischen Symbolen, Grafiken, Bildern, Videos, Texten usw. sein. Daten aus einer Sprachkonversation können beispielsweise Sprachinformationen, Ruheperioden, Hintergrundgeräusche, Komfortrauschen, Töne usw. sein. Steuerinformationen können sich auf Daten beziehen, die Befehle, Anweisungen oder Steuerwörter für ein automatisiertes System darstellen. Beispielsweise können Steuerinformationen verwendet werden, um Medieninformationen durch ein System zu leiten oder einen Knoten anzuweisen, die Medieninformationen auf eine vorbestimmte Weise zu verarbeiten. Die Implementierungen sind jedoch nicht auf die Elemente oder den in 11 gezeigten oder beschriebenen Kontext beschränkt.
  • Unter Bezugnahme auf 12 ist eine Vorrichtung 1200 mit kleinem Formfaktor ein Beispiel für die unterschiedlichen physischen Stile oder Formfaktoren, in denen die Systeme 1100 oder 1000 verkörpert sein können. Bei diesem Ansatz kann die Vorrichtung 1200 als eine mobile Rechenvorrichtung mit drahtlosen Fähigkeiten implementiert sein. Eine mobile Rechenvorrichtung kann sich auf jede Vorrichtung beziehen, die ein Verarbeitungssystem und eine mobile Leistungsquelle oder -versorgung aufweist, wie beispielsweise eine oder mehrere Batterien.
  • Wie es oben beschrieben ist, können Beispiele einer mobilen Rechenvorrichtung eine digitale Standbildkamera, eine digitale Videokamera, mobile Vorrichtung mit Kamera- oder Videofunktionen wie abbildende Telefone, Webcams, PCs, Laptop-Computer, Ultra-Laptop-Computer, Tablets, ein Berührungsfeld, einen tragbaren Computer, einen in der Hand getragenen Computer, einen Palmtop-Computer, einen persönlichen digitalen Assistenten (PDA), ein Mobiltelefon oder einer Kombination aus Mobiltelefon/PDA, einen Fernseher, eine intelligente Vorrichtung (z. B. Smartphone, Smart-Tablet, intelligenter Lautsprecher oder intelligenter Fernseher), eine mobile Internetvorrichtung (MID), eine Nachrichtenvorrichtung, eine Datenkommunikationsvorrichtung usw. umfassen.
  • Beispiele für eine mobile Rechenvorrichtung können auch Computer umfassen, die so angeordnet sind, dass sie von einer Person getragen werden, wie beispielsweise einen Handgelenkcomputer, einen Fingercomputer, einen Ringcomputer, einen Brillencomputer, einen Gürtelschnallencomputer, einen Armbandcomputer, einen Schuhcomputer, einen Kleidungscomputer und andere am Körper tragbare Computer. In verschiedenen Ausführungsformen kann beispielsweise eine mobile Rechenvorrichtung als ein Smartphone implementiert sein, das Computeranwendungen sowie Sprachkommunikation und/oder Datenkommunikation ausführen kann. Obwohl einige Ausführungsformen beispielhaft mit einer als Smartphone implementierten mobilen Rechenvorrichtung beschrieben sein können, ist zu erkennen, dass andere Ausführungsformen auch unter Verwendung anderer drahtloser mobiler Rechenvorrichtungen implementiert werden können. Die Implementierungen sind in diesem Zusammenhang nicht beschränkt.
  • Wie es in 12 gezeigt ist, kann die Vorrichtung 1200 ein Gehäuse mit einer Vorderseite 1201 und einer Rückseite 1202 aufweisen. Die Vorrichtung 1200 kann eine Anzeige 1204, eine Eingabe/Ausgabe-Vorrichtung (E/A-Vorrichtung) 1206 und eine integrierte Antenne 1208 umfassen. Die Vorrichtung 1200 kann zudem Navigationsmerkmale 1212 aufweisen. Die E/A-Vorrichtung 1206 kann eine beliebige geeignete E/A-Vorrichtung zum Eingeben von Informationen in eine mobile Rechenvorrichtung aufweisen. Beispiele für die E/A-Vorrichtung 1206 können eine alphanumerische Tastatur, eine numerisches Tastenfeld, ein Berührungsfeld, Eingabetasten, Tasten, Schalter, Mikrofone, Lautsprecher, Spracherkennungsvorrichtung und -software usw. umfassen. Informationen können auch über das Mikrofon 1214 in die Vorrichtung 1200 eingegeben oder durch eine Spracherkennungsvorrichtung digitalisiert werden. Wie es gezeigt ist, kann die Vorrichtung 1200 eine Kamera 1205 (z. B. mit mindestens einer Linse, einer Blende und einem Abbildungssensor) und einen Blitz 1210, der in die Rückseite 1202 der Vorrichtung 1200 (oder anderswo) integriert ist, aufweisen. Die Implementierungen sind in diesem Zusammenhang nicht beschränkt.
  • Verschiedene Formen der hier beschriebenen Vorrichtungen und Prozesse können unter Verwendung von Hardwareelementen, Softwareelementen oder einer Kombination aus beiden implementiert werden. Beispiele für Hardwareelemente können Prozessoren, Mikroprozessoren, Schaltungen, Schaltungselemente (z. B. Transistoren, Widerstände, Kondensatoren, Induktoren usw.), integrierte Schaltungen, anwendungsspezifische integrierte Schaltungen (ASIC), programmierbare Logikvorrichtungen (PLD), Digitalsignalprozessoren (DSP), feldprogrammierbare Gatteranordnungen (FPGA), Logikgatter, Register, Halbleitervorrichtungen, Chips, Mikrochips, Chipsätze usw. umfassen. Beispiele für Software können Softwarekomponenten, Programme, Anwendungen, Computerprogramme, Anwendungsprogramme, Systemprogramme, Maschinenprogramme, Betriebssystemsoftware, Middleware, Firmware, Softwaremodule, Routinen, Unterprogramme, Funktionen, Verfahren, Prozeduren, Softwareschnittstellen, Anwendungsprogrammschnittstellen (API), Befehlssätze, Rechencode, Computercode, Codesegmente, Computercodesegmente, Wörter, Werte, Symbole oder eine beliebige Kombination davon umfassen. Das Bestimmen, ob eine Ausführungsform unter Verwendung von Hardwareelementen und/oder Softwareelementen implementiert wird, kann in Abhängigkeit von einer beliebigen Anzahl von Faktoren variieren, wie beispielsweise der gewünschten Rechenrate, Leistungspegeln, Wärmetoleranzen, dem Verarbeitungszyklusbudget, Eingangsdatenraten, Ausgangsdatenraten, Speicherbetriebsmitteln, Datenbusgeschwindigkeiten und anderen Entwurfs- oder Leistungsbeschränkungen.
  • Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, und die beim Lesen durch eine Maschine veranlassen, dass die Maschine Logik herstellt, um die hierin beschriebenen Techniken auszuführen. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, können auf einem konkreten, maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Fertigungsanlagen geliefert werden, um sie in die Fertigungsmaschinen zu laden, die tatsächlich die Logik oder den Prozessor herstellen.
  • Obwohl bestimmte hierin dargelegte Merkmale unter Bezugnahme auf verschiedene Implementierungen beschrieben wurden, soll diese Beschreibung nicht in einem einschränkenden Sinne ausgelegt werden. Daher wird angenommen, dass verschiedene Abwandlungen der hierin beschriebenen Implementierungen sowie andere Implementierungen, die für Fachleute, für die die vorliegende Offenbarung gedacht ist, offensichtlich sind, im Gedanken und Umfang der vorliegenden Offenbarung liegen.
  • Die folgenden Beispiele beziehen sich auf zusätzliche Implementierungen.
  • Bei einem Beispiel einer oder mehrerer erster Implementierungen umfasst ein computerimplementiertes Verfahren zum Videocodieren: Erhalten von Bilddaten aus mindestens einem Frame einer Videosequenz; Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstruierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke des mindestens einen Frames innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist; und Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht.
  • Bei einer oder mehreren zweiten Implementierungen und zusätzlich zu der ersten Implementierung, wobei die Referenzbasis-Hash-Codes und die Quellbasis-Hash-Codes beide unter Verwendung einer Version der ursprünglichen Pixelbilddaten anstelle von codiererrekonstruierten Bilddaten gebildet werden.
  • Bei einer oder mehreren dritten Implementierungen und zusätzlich zur ersten oder zweiten Implementierung, wobei der aktuelle Block eine große Größe aufweist, die mehrere verfügbare Vorhersageblockgrößen innerhalb des aktuellen Blocks enthält; und das Verfahren ein Festlegen mindestens einer der verfügbaren Vorhersageblockgrößen als den Vorhersageblock der Vorhersage dann, wenn alle Quellbasisblöcke innerhalb des Vorhersageblocks einen übereinstimmenden Quellbasis-Hash-Code mit einem der Referenzbasis-Hash-Codes der Referenzbasisblöcke haben, umfasst.
  • Bei einer oder mehreren vierten Implementierungen und zusätzlich zu einer der ersten bis dritten Implementierungen, wobei das Verfahren umfasst: Verketten der Quellbasis-Hash-Codes der Quellbasisblöcke, die den aktuellen Block bilden; Verketten von Referenzbasis-Hash-Codes von Referenzbasisblöcken, die zusammen dieselbe Größe wie der aktuelle Block bilden; und Bestimmen, ob die gesamten verketteten Referenz- und Quell-Hash-Codes für mehrere verschiedene potenzielle verkettete Referenz-Hash-Codes übereinstimmen.
  • Bei einer oder mehreren fünften Implementierungen und zusätzlich zu einer der ersten bis dritten Implementierungen, wobei das Verfahren umfasst: Verketten der Quellbasis-Hash-Codes der Quellbasisblöcke, die den aktuellen Block bilden; Verketten von Referenzbasis-Hash-Codes von Referenzbasisblöcken, die zusammen dieselbe Größe wie der aktuelle Block bilden; Bestimmen, ob die gesamten verketteten Referenz- und Quell-Hash-Codes für mehrere verschiedene potenzielle verkettete Referenz-Hash-Codes übereinstimmen; und Bestimmen, ob Teile der verketteten Referenz- und Quell-Hash-Codes übereinstimmen, und die übereinstimmenden Referenz- und Quellbasis-Hash-Codes entsprechen, die jeweils einen Vorhersageblock füllen.
  • Bei einer oder mehreren sechsten Implementierungen und zusätzlich zu einer der ersten bis fünften Implementierungen, wobei das Verfahren umfasst: Verketten der Quellbasis-Hash-Codes der Quellbasisblöcke, die mindestens einen Vorhersageblock innerhalb des aktuellen Blocks bilden; Verketten von Referenzbasis-Hash-Codes von Referenzbasisblöcken, die zusammen den Block derselben Größe wie der Vorhersageblock bilden; und Bestimmen, ob die gesamten verketteten Referenz- und Quell-Hash-Codes für mehrere verschiedene potenzielle verkettete Referenz-Hash-Codes des Vorhersageblocks übereinstimmen.
  • Bei einer oder mehreren siebten Implementierungen und zusätzlich zu einer der ersten bis sechsten Implementierungen, wobei das Verfahren umfasst: Auflisten der Referenzbasis-Hash-Codes in einer Tabelle und Nachschlagen von Quellbasis-Hash-Codes des aktuellen Blocks in der Tabelle, um zu bestimmen, ob irgendwelche Referenzbasis-Hash-Codes gleich dem Quellbasis-Hash-Code sind, um eine Übereinstimmung zwischen dem Quellbasis-Hash-Code und einem Referenzbasis-Hash-Code festzustellen.
  • Bei einer oder mehreren achten Implementierungen und zusätzlich zu einer der ersten bis sechsten Implementierungen, wobei das Verfahren umfasst: Auflisten der Referenzbasis-Hash-Codes in einer Tabelle und Nachschlagen von Quellbasis-Hash-Codes des aktuellen Blocks in der Tabelle, um zu bestimmen, ob irgendwelche Referenzbasis-Hash-Codes gleich dem Quellbasis-Hash-Code sind, um eine Übereinstimmung zwischen dem Quellbasis-Hash-Code und einem Referenzbasis-Hash-Code festzustellen, wobei die Tabelle mindestens den Referenzbasis-Hash-Code und einen Ankerpixelort des Referenzbasisblocks des Referenzbasis-Hash-Codes auflistet.
  • Bei einer oder mehreren neunten Implementierungen und zusätzlich zu einer der ersten bis achten Implementierungen, wobei das Verfahren umfasst: Erzeugen der Quellbasis-Hash-Codes im laufenden Betrieb, um sie mit Referenzbasis-Hash-Codes abzugleichen, ohne die Quellbasis-Hash-Codes in einem Puffer zu speichern.
  • Bei einer oder mehreren zehnten Implementierungen und zusätzlich zu einer der ersten bis neunten Implementierungen, wobei das Verfahren, das das Erzeugen der Quellbasis-Hash-Codes umfasst, ein Unterteilen des Frames in nichtüberlappende Quellbasis-Blöcke umfasst, die jeweils in einer Position angeordnet sind, um potentiell ein Intra-Vorhersageblock einer Vorhersage zu sein oder einen Teil davon zu bilden.
  • Bei einer oder mehreren elften Implementierungen und zusätzlich zu einer der ersten bis zehnten Implementierungen, wobei das Verfahren umfasst: Erzeugen von Referenzbasis-Hash-Codes von Referenzbasisblöcken an einzelnen Ankerpixelorten so, dass Referenzbasisblöcke überlappende Positionen auf dem Frame aufweisen.
  • Bei einer oder mehreren zwölften Implementierungen und zusätzlich zu einer der ersten bis elften Implementierungen, wobei das Verfahren umfasst: Erzeugen der Vorhersage so, dass sie Bilddaten der Referenzbasisblöcke ist, die den aktuellen Block oder Vorhersageblock bilden, wenn der aktuelle Block oder der Vorhersageblock übereinstimmende Referenz- und Quellbasis-Hash-Codes aufweisen.
  • Bei einem Beispiel einer oder mehrerer dreizehnter Implementierungen umfasst ein computerimplementiertes System: mindestens eine Anzeige; einen Speicher zum Speichern von Bilddaten von mindestens einem Bild; mindestens einen Prozessor, der kommunikationstechnisch mit dem Speicher und der Anzeige gekoppelt ist, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Erhalten von Bilddaten aus mindestens einem Frame einer Videosequenz; Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstruierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke des mindestens einen Frames innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist; und Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht.
  • Bei einer oder mehreren vierzehnten Implementierungen und zusätzlich zu einer dreizehnten Implementierung, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Detektieren mindestens eines einheitlichen Bereichs, was ein Erzeugen von Indikatoren umfasst, dass angenommen wird, dass Referenz- oder Quellenbasisblöcke in einem einheitlichen Bereich des Frames liegen, abhängig davon, ob ein oder mehrere benachbarte Basisblöcke relativ zu einem aktuellen Basisblock den gleichen Basis-Hash-Code haben.
  • Bei einer oder mehreren fünfzehnten Implementierungen und zusätzlich zu der dreizehnten Implementierung, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Detektieren mindestens eines einheitlichen Bereichs erfasst, was ein Erzeugen von Indikatoren umfasst, dass angenommen wird, dass Referenz- oder Quellenbasisblöcke in einem einheitlichen Bereich des Frames liegen, abhängig davon, ob ein oder mehrere benachbarte Basisblöcke relativ zu einem aktuellen Basisblock den gleichen Basis-Hash-Code haben, und wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Pflegen mindestens einer Zählung einer Anzahl von Basisblöcken und eines Orts von Basisblöcken, die den gleichen Basis-Hash-Code haben, um die Position der einheitlichen Bereiche zu verfolgen.
  • Bei einer oder mehreren sechzehnten Implementierungen und zusätzlich zu der dreizehnten Implementierung, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Detektieren mindestens eines einheitlichen Bereichs erfasst, was ein Erzeugen von Indikatoren umfasst, dass angenommen wird, dass Referenz- oder Quellenbasisblöcke in einem einheitlichen Bereich des Frames liegen, abhängig davon, ob ein oder mehrere benachbarte Basisblöcke relativ zu einem aktuellen Basisblock den gleichen Basis-Hash-Code haben, und wobei der mindestens eine Frame ein aktueller Frame ist und wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Angeben, dass ein aktueller Basisblock auf dem aktuellen Frame innerhalb eines einheitlichen Bereichs liegt, wenn bestimmt wurde, dass sich der gleiche Basisblockort in einem vorherigen Frame relativ zu dem aktuellen Frame in einem einheitlichen Bereich befindet und den gleichen Basis-Hash-Code wie der aktuelle Basisblock aufweist.
  • Bei einer oder mehreren siebzehnten Implementierungen und zusätzlich zu einer der dreizehnten bis sechzehnten Implementierungen, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Detektieren mindestens eines einheitlichen Bereichs erfasst, was ein Erzeugen von Indikatoren umfasst, dass angenommen wird, dass Referenz- oder Quellenbasisblöcke in einem einheitlichen Bereich des Frames liegen, abhängig davon, ob ein oder mehrere benachbarte Basisblöcke relativ zu einem aktuellen Basisblock den gleichen Basis-Hash-Code haben, und wobei der mindestens eine Prozessor dazu ausgelegt ist, dann, wenn festgestellt wurde, dass der aktuelle Block oder der Vorhersageblock sich in einem einheitlichen Bereich befindet, folgendermaßen zu arbeiten: (a) Verringern eines Quantisierungsparameters des aktuellen Blocks oder Vorhersageblocks, und/oder (b) Ändern, welche Vorhersagemodi für den aktuellen Block oder Vorhersageblock zu berücksichtigen sind, und/oder (c) Detektieren eines Szenenwechsels, wenn eine vorbestimmte ausreichende Anzahl von Basisblöcken in einem einheitlichen Bereich einen anderen Hash-Code als der gleiche Basisblockpixelort in einem vorherigen Frame aufweist.
  • Bei einem Beispiel einer oder mehrerer achtzehnter Implementierungen kann mindestens ein nichttransitorisches computerlesbares Medium, auf dem Befehle gespeichert sind, die bei ihrer Ausführung veranlassen, dass eine Rechenvorrichtung folgendermaßen arbeitet: Erhalten von Bilddaten aus mindestens einem Frame einer Videosequenz; Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstruierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke des mindestens einen Frames innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist; und Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht.
  • Bei einer oder mehreren neunzehnten Implementierungen und zusätzlich zu der achtzehnten Implementierung werden die ursprünglichen Bilddaten von einer Kamera als Video aufgezeichnet; wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Modifizieren von Bilddaten, die zum Erzeugen der Referenz- und Quellbasis-Hash-Codes verwendet werden sollen, um die Wahrscheinlichkeit zu erhöhen, übereinstimmende Referenz- und Quellbasis-Hash-Codes zu finden.
  • Bei einer oder mehreren zwanzigsten Implementierungen und zusätzlich zu der achtzehnten Implementierung werden die ursprünglichen Bilddaten von einer Kamera als Video aufgezeichnet; wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Modifizieren von Bilddaten, die zum Erzeugen der Referenz- und Quellbasis-Hash-Codes verwendet werden sollen, um die Wahrscheinlichkeit zu erhöhen, übereinstimmende Referenz- und Quellbasis-Hash-Codes zu finden, und wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Verwenden der modifizierten Bilddaten nur zum Berechnen der Referenz- und Quell-Hash-Codes statt als die Bilddaten der Vorhersage.
  • Bei einer oder mehreren einundzwanzigsten Implementierungen und zusätzlich zu einer der achtzehnten bis zwanzigsten Implementierungen, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Entrauschen der Bilddaten des Frames vor dem Verwenden der Bilddaten zum Erzeugen der Referenz- und Quellbasis-Hash-Codes und unabhängig davon, ob irgendein anderes Entrauschen bereits als Vorverarbeitung eines Codierers durchgeführt wurde, der die Referenz- und Quellbasis-Hash-Codes erzeugt.
  • Bei einer oder mehreren zweiundzwanzigsten Implementierungen und zusätzlich zu einer der achtzehnten bis einundzwanzigsten Implementierungen, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Verkleinern der Bilddaten des Frames vor dem Erzeugen der Referenz- und Quellbasis-Hash-Codes.
  • Bei einer oder mehreren dreiundzwanzigsten Implementierungen und zusätzlich zu einer der achtzehnten bis zweiundzwanzigsten Implementierungen, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Heruntertasten der Bilddaten, die zum Erzeugen Referenz- und Quellbasis-Hash-Codes verwendet werden sollen, was ein Verwerfen eines oder mehrerer niedrigstwertiger Bits (LSBs) umfasst, um Bilddatenwerte zu runden, die die Bilddaten bilden.
  • Bei einer oder mehreren vierundzwanzigsten Implementierungen und zusätzlich zu einer der achtzehnten bis dreiundzwanzigsten Implementierungen, wobei die Vorhersage eine hashbasierte Suchvorhersage ist und wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Ändern, welche anderen Intra-Vorhersagemodi für einen aktuellen Block oder Vorhersageblock innerhalb des aktuellen Blocks berücksichtigt werden sollen, wenn übereinstimmende Hash-Codes in dem aktuellen Block oder Vorhersageblock gefunden werden.
  • Bei einer oder mehreren fünfundzwanzigsten Implementierungen und zusätzlich zu einer der achtzehnten bis vierundzwanzigsten Implementierungen, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Verwenden der Vorhersage als Startort für eine Intra-Vorhersageblockabgleichssuche.
  • In einem weiteren Beispiel kann mindestens ein maschinenlesbares Medium mehrere Befehle enthalten, die als Antwort auf die Ausführung auf einer Rechenvorrichtung veranlassen, dass die Rechenvorrichtung das Verfahren gemäß einem der obigen Beispiele ausführt.
  • In einem noch weiteren Beispiel kann eine Vorrichtung Mittel zum Durchführen der Verfahren gemäß einem der obigen Beispiele aufweisen.
  • Die obigen Beispiele können eine spezifische Kombination von Merkmalen umfassen. Die obigen Beispiele sind jedoch in dieser Hinsicht nicht beschränkt und in verschiedenen Implementierungen können die obigen Beispiele ein Durchführen nur einer Teilmenge solcher Merkmale, ein Durchführen einer anderen Reihenfolge solcher Merkmale, ein Durchführen einer anderen Kombination solcher Merkmale und/oder ein Durchführen zusätzlicher Funktionen neben den explizit aufgeführten Funktionen umfassen. Beispielsweise können alle Merkmale, die in Bezug auf irgendwelche hierin beschriebenen Beispielverfahren beschrieben sind, in Bezug auf beliebige Beispielvorrichtungen, Beispielsysteme und/oder Beispielartikel implementiert werden und umgekehrt.

Claims (25)

  1. Computerimplementiertes Verfahren zum Videocodieren, das Folgendes umfasst: Erhalten von Bilddaten aus mindestens einem Frame einer Videosequenz; Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstruierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke des mindestens einen Frames innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist; und Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht.
  2. Verfahren nach Anspruch 1, wobei die Referenzbasis-Hash-Codes und die Quellbasis-Hash-Codes beide unter Verwendung einer Version der ursprünglichen Pixelbilddaten anstelle von codiererrekonstruierten Bilddaten gebildet werden.
  3. Verfahren nach Anspruch 1 oder 2, wobei der aktuelle Block eine große Größe aufweist, die mehrere verfügbare Vorhersageblockgrößen innerhalb des aktuellen Blocks enthält; und das Verfahren ein Festlegen mindestens einer der verfügbaren Vorhersageblockgrößen als den Vorhersageblock der Vorhersage dann, wenn alle Quellbasisblöcke innerhalb des Vorhersageblocks einen übereinstimmenden Quellbasis-Hash-Code mit einem der Referenzbasis-Hash-Codes der Referenzbasisblöcke haben, umfasst.
  4. Verfahren nach einem der Ansprüche 1 bis 3, das umfasst: Verketten der Quellbasis-Hash-Codes der Quellbasisblöcke, die den aktuellen Block bilden; Verketten von Referenzbasis-Hash-Codes von Referenzbasisblöcken, die zusammen dieselbe Größe wie der aktuelle Block bilden; und Bestimmen, ob die gesamten verketteten Referenz- und Quell-Hash-Codes für mehrere verschiedene potenzielle verkettete Referenz-Hash-Codes übereinstimmen.
  5. Verfahren nach Anspruch 4, das umfasst: Bestimmen, ob Teile der verketteten Referenz- und Quell-Hash-Codes übereinstimmen, und dass sie übereinstimmenden Referenz- und Quellbasis-Hash-Codes entsprechen, die jeweils einen Vorhersageblock füllen.
  6. Verfahren nach Anspruch 1 oder 2, das umfasst: Verketten der Quellbasis-Hash-Codes der Quellbasisblöcke, die mindestens einen Vorhersageblock innerhalb des aktuellen Blocks bilden; Verketten von Referenzbasis-Hash-Codes von Referenzbasisblöcken, die zusammen den Block derselben Größe wie der Vorhersageblock bilden; und Bestimmen, ob die gesamten verketteten Referenz- und Quell-Hash-Codes für mehrere verschiedene potenzielle verkettete Referenz-Hash-Codes des Vorhersageblocks übereinstimmen.
  7. Verfahren nach einem der Ansprüche 1 bis 6, das umfasst: Auflisten der Referenzbasis-Hash-Codes in einer Tabelle und Nachschlagen von Quellbasis-Hash-Codes des aktuellen Blocks in der Tabelle, um zu bestimmen, ob irgendwelche Referenzbasis-Hash-Codes gleich dem Quellbasis-Hash-Code sind, um eine Übereinstimmung zwischen dem Quellbasis-Hash-Code und einem Referenzbasis-Hash-Code festzustellen.
  8. Verfahren nach Anspruch 7, wobei die Tabelle mindestens den Referenzbasis-Hash-Code und einen Ankerpixelort des Referenzbasisblocks des Referenzbasis-Hash-Codes auflistet.
  9. Verfahren nach einem der Ansprüche 1 bis 8, das umfasst: Erzeugen der Quellbasis-Hash-Codes im laufenden Betrieb, um sie mit Referenzbasis-Hash-Codes abzugleichen, ohne die Quellbasis-Hash-Codes in einem Puffer zu speichern.
  10. Verfahren nach einem der Ansprüche 1 bis 9, das umfasst: Erzeugen der Quellbasis-Hash-Codes, was ein Unterteilen des Frames in nichtüberlappende Quellbasis-Blöcke umfasst, die jeweils an einer Position angeordnet sind, um potentiell ein Intra-Vorhersageblock einer Vorhersage zu sein oder einen Teil davon zu bilden.
  11. Verfahren nach einem der Ansprüche 1 bis 10, das umfasst: Erzeugen von Referenzbasis-Hash-Codes von Referenzbasisblöcken an einzelnen Ankerpixelorten so, dass Referenzbasisblöcke überlappende Positionen auf dem Frame aufweisen.
  12. Verfahren nach Anspruch 1, wobei das Verfahren umfasst: Erzeugen der Vorhersage so, dass sie Bilddaten der Referenzbasisblöcke ist, die den aktuellen Block oder Vorhersageblock bilden, wenn der aktuelle Block oder der Vorhersageblock übereinstimmende Referenz- und Quellbasis-Hash-Codes aufweisen.
  13. Computerimplementiertes System, das Folgendes umfasst: mindestens eine Anzeige; einen Speicher zum Speichern von Bilddaten von mindestens einem Bild; mindestens einen Prozessor, der kommunikationstechnisch mit dem Speicher und der Anzeige gekoppelt ist, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Erhalten von Bilddaten aus mindestens einem Frame einer Videosequenz; Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstruierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke des mindestens einen Frames innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist; und Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht.
  14. System nach Anspruch 13, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Detektieren mindestens eines einheitlichen Bereichs, was ein Erzeugen von Indikatoren dafür, dass angenommen wird, dass Referenz- oder Quellenbasisblöcke in einem einheitlichen Bereich des Frames liegen, abhängig davon, ob ein oder mehrere benachbarte Basisblöcke relativ zu einem aktuellen Basisblock den gleichen Basis-Hash-Code haben, umfasst.
  15. System nach Anspruch 14, wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Pflegen mindestens einer Zählung einer Anzahl von Basisblöcken und eines Orts von Basisblöcken, die den gleichen Basis-Hash-Code haben, um die Position der einheitlichen Bereiche zu verfolgen.
  16. System nach Anspruch 14, wobei der mindestens eine Frame ein aktueller Frame ist und wobei der mindestens eine Prozessor dazu ausgelegt ist, folgendermaßen zu arbeiten: Angeben, dass ein aktueller Basisblock auf dem aktuellen Frame innerhalb eines einheitlichen Bereichs liegt, wenn bestimmt wurde, dass sich der gleiche Basisblockort in einem vorherigen Frame relativ zu dem aktuellen Frame in einem einheitlichen Bereich befindet und den gleichen Basis-Hash-Code wie der aktuelle Basisblock aufweist.
  17. System nach Anspruch 14, wobei der mindestens eine Prozessor dann, wenn festgestellt wird, dass sich der aktuelle Block oder Vorhersageblock in einem einheitlichen Bereich befindet, dazu ausgelegt ist, folgendermaßen zu arbeiten: (a) Verringern eines Quantisierungsparameters des aktuellen Blocks oder Vorhersageblocks, und/oder (b) Ändern, welche Vorhersagemodi für den aktuellen Block oder Vorhersageblock zu berücksichtigen sind, und/oder (c) Detektieren eines Szenenwechsels, wenn eine vorbestimmte ausreichende Anzahl von Basisblöcken in einem einheitlichen Bereich einen anderen Hash-Code als der gleiche Basisblockpixelort in einem vorherigen Frame aufweist.
  18. Nichttransitorisches computerlesbares Medium bzw. nichttransitorische computerlesbare Medien, auf denen Befehle gespeichert sind, die bei ihrer Ausführung veranlassen, dass eine Rechenvorrichtung folgendermaßen arbeitet: Erhalten von Bilddaten aus mindestens einem Frame einer Videosequenz; Erzeugen von Referenzbasis-Hash-Codes, die jeweils einem Referenzbasisblock zugeordnet sind, der eine Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Erzeugen von Quellbasis-Hash-Codes, die jeweils einem Quellbasisblock zugeordnet sind, der die Basisblockgröße von Bilddaten auf dem mindestens einen Frame aufweist; Bestimmen von Quellbasis-Hash-Codes eines aktuellen Blocks des mindestens einen zu rekonstituierenden Frames in Abhängigkeit davon, welche der Quellbasisblöcke des mindestens einen Frames innerhalb des aktuellen Blocks angeordnet sind, wobei der aktuelle Block größer als die Basisblockgröße ist; und Bestimmen mindestens einer Vorhersage des aktuellen Blocks oder eines Vorhersageblocks innerhalb des aktuellen Blocks in Abhängigkeit davon, ob mindestens eine Übereinstimmung zwischen einem der Referenzbasis-Hash-Codes und einem der Quellbasis-Hash-Codes des aktuellen Blocks besteht.
  19. Medium nach Anspruch 18, wobei die ursprünglichen Bilddaten von einer Kamera als Video aufgezeichnet werden; und wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Modifizieren von Bilddaten, die zum Erzeugen der Referenz- und Quellbasis-Hash-Codes verwendet werden sollen, um die Wahrscheinlichkeit zu erhöhen, übereinstimmende Referenz- und Quellbasis-Hash-Codes zu finden.
  20. Medium nach Anspruch 19, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Verwenden der modifizierten Bilddaten nur zum Berechnen der Referenz- und Quell-Hash-Codes statt als die Bilddaten der Vorhersage.
  21. Medium nach einem der Ansprüche 18 bis 20, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Entrauschen der Bilddaten des Frames vor dem Verwenden der Bilddaten zum Erzeugen der Referenz- und Quellbasis-Hash-Codes und unabhängig davon, ob irgendein anderes Entrauschen bereits als Vorverarbeitung eines Codierers durchgeführt wurde, der die Referenz- und Quellbasis-Hash-Codes erzeugt.
  22. Medium nach einem der Ansprüche 18 bis 21, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Verkleinern der Bilddaten des Frames vor dem Erzeugen der Referenz- und Quellbasis-Hash-Codes.
  23. Medium nach einem der Ansprüche 18 bis 22, wobei die Befehle dazu ausgelegt sind, die Rechenvorrichtung dazu zu veranlassen, folgendermaßen zu arbeiten: Heruntertasten der Bilddaten, die zum Erzeugen Referenz- und Quellbasis-Hash-Codes verwendet werden sollen, was ein Verwerfen eines oder mehrerer niedrigstwertiger Bits (LSBs) umfasst, um Bilddatenwerte zu runden, die die Bilddaten bilden.
  24. Maschinenlesbares Medium bzw. maschinenlesbare Medien, umfassend mehrere Befehle, die als Antwort auf die Ausführung auf einer Rechenvorrichtung veranlassen, dass die Rechenvorrichtung das Verfahren nach einem der Ansprüche 1-12 ausführt.
  25. Vorrichtung, die Mittel zum Durchführen des Verfahrens nach einem der Ansprüche 1-12 umfasst.
DE102020127627.3A 2019-11-29 2020-10-20 Verfahren und System zum Videocodieren mit Intra-Block-Kopieren Pending DE102020127627A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/699,243 US11930159B2 (en) 2019-11-29 2019-11-29 Method and system of video coding with intra block copying
US16/699,243 2019-11-29

Publications (1)

Publication Number Publication Date
DE102020127627A1 true DE102020127627A1 (de) 2021-06-02

Family

ID=69884797

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020127627.3A Pending DE102020127627A1 (de) 2019-11-29 2020-10-20 Verfahren und System zum Videocodieren mit Intra-Block-Kopieren

Country Status (3)

Country Link
US (1) US11930159B2 (de)
CN (1) CN112887724A (de)
DE (1) DE102020127627A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX2017004210A (es) 2014-09-30 2017-11-15 Microsoft Technology Licensing Llc Decisiones de codificador basadas en hash para codificar video.
US11558637B1 (en) * 2019-12-16 2023-01-17 Meta Platforms, Inc. Unified search window to support multiple video encoding standards
US11575896B2 (en) * 2019-12-16 2023-02-07 Panasonic Intellectual Property Corporation Of America Encoder, decoder, encoding method, and decoding method
US11018873B1 (en) * 2020-01-16 2021-05-25 Tyson York Winarski Collision resistant digital signatures
US11194702B2 (en) * 2020-01-27 2021-12-07 Red Hat, Inc. History based build cache for program builds
US11202085B1 (en) * 2020-06-12 2021-12-14 Microsoft Technology Licensing, Llc Low-cost hash table construction and hash-based block matching for variable-size blocks
CN112804528B (zh) * 2021-02-05 2022-10-28 北京字节跳动网络技术有限公司 屏幕内容处理方法、装置及设备
CN113542750B (zh) * 2021-05-27 2024-06-25 绍兴市北大信息技术科创中心 采用两套以上哈希表进行搜索的数据编码方法
CN113596470A (zh) * 2021-06-30 2021-11-02 深圳市朗强科技有限公司 应用中压缩算法的超高清视频无线发送、接收方法及设备
US20230059035A1 (en) * 2021-08-23 2023-02-23 Netflix, Inc. Efficient encoding of film grain noise
CN116114245A (zh) * 2021-09-02 2023-05-12 辉达公司 在视频编码过程中视频帧的并行处理
WO2023049928A1 (en) * 2021-09-27 2023-03-30 Bytedance Inc. Method, apparatus, and medium for video processing
CN114125442B (zh) * 2022-01-29 2022-05-03 腾讯科技（深圳）有限公司 屏幕视频编码模式确定方法、编码方法、装置和计算设备
US11908167B1 (en) * 2022-11-04 2024-02-20 Osom Products, Inc. Verifying that a digital image is not generated by an artificial intelligence
CN116760986B (zh) * 2023-08-23 2023-11-14 腾讯科技（深圳）有限公司 候选运动矢量生成方法、装置、计算机设备和存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105393537B (zh) * 2014-03-04 2019-08-27 微软技术许可有限责任公司 用于基于散列的块匹配的散列表构建和可用性检查
US9875552B1 (en) * 2016-07-26 2018-01-23 Teradici Corporation Content independent method of motion determination using sparse matrices

Also Published As

Publication number Publication date
US11930159B2 (en) 2024-03-12
CN112887724A (zh) 2021-06-01
US20200099926A1 (en) 2020-03-26

Similar Documents

Publication Publication Date Title
DE102020127627A1 (de) Verfahren und System zum Videocodieren mit Intra-Block-Kopieren
DE112016002026B4 (de) Verfahren und System zum adaptiven Referenz-Frame-Caching für die Videocodierung
DE112017003212T5 (de) Verfahren und System zur Videocodierung mit Kontextdecodierung und Rekonstruktionsumgehung
DE102020123396A1 (de) Verfahren und system für inhaltsadaptives entrauschen zum videocodieren
JP6055555B2 (ja) 次世代ビデオのためのビデオコーデックアーキテクチャ
DE102019209067A1 (de) Adaptive in-loop filtering for video coding
DE202016008257U1 (de) Bewegungsvektorkodierung mit dynamischen Referenzbewegungsvektoren
DE102019112578A1 (de) Bereichsbasierte Bewegungsschätzung und -modellierung zur genauen bereichsbasierten Bewegungskompensation zur effizienten Videoverarbeitung oder -codierung
KR102123958B1 (ko) 코딩 프로세스에서의 실시간 비디오 노이즈를 감소시키는 방법, 단말기, 및 컴퓨터로 판독할 수 있는 비휘발성 저장 매체
DE202016008192U1 (de) Auswahl des Referenz-Bewegungsvektors über Referenzeinzelbild Puffer-Nachverfolgung
EP1246131A2 (de) Verfahren und Vorrichtung zur Reduzierung von Störungen in dekodierten Bildern mit Nachfilterung
DE112018000280T5 (de) Entblockungsfilterung für 360-video
DE102016125125B4 (de) Tile-Copying für Videokompression
DE102020125206A1 (de) Verfahren und system zur mehrkanalvideocodierung mit frameratenänderung und kanalübergreifender referenzierung
DE202016008175U1 (de) Adaptive gerichtete Intra-Prädiktion mit Blockgröße
KR20150090178A (ko) 차세대 비디오용 코딩된/코딩되지 않은 데이터의 콘텐츠 적응적 엔트로피 코딩
DE202016008178U1 (de) Bewegungsvektorvorhersage mittels eines vorhergehenden Einzelbildresiduums
DE102019218316A1 (de) 3d-renderer-zu-videocodierer-pipeline für verbesserte visuelle qualität und geringe latenz
DE102018129344A1 (de) Bereichsadaptive, dateneffiziente Erzeugung von Partitionierungsentscheidungen und Modusentscheidungen zur Videocodierung
DE102019215911A1 (de) Adaptive inhaltsquantisierung zur videocodierung
EP3711302B1 (de) Räumlich adaptiver quantisierungsbewusster blockartefaktfilter
DE102016125604A1 (de) Intelligente Sortierung der rekursiven Blockaufteilung für die erweiterte Intra-Prädiktion bei der Videocodierung
DE102016015996B3 (de) Anpassungsfähige Kachel-Daten-Grössenkodierung für Video- und Bildkompression
DE112015004399T5 (de) Frequenzbereichsentstörung
DE112017005664T5 (de) Umwandlungspuffer zum entkoppeln von normativem und umsetzungsdatenpfadinterleaving von videokoeffizienten