ES2997974T3 - Sub-block temporal motion vector prediction for video coding - Google Patents

Sub-block temporal motion vector prediction for video coding Download PDF

Info

Publication number
ES2997974T3
ES2997974T3 ES20818170T ES20818170T ES2997974T3 ES 2997974 T3 ES2997974 T3 ES 2997974T3 ES 20818170 T ES20818170 T ES 20818170T ES 20818170 T ES20818170 T ES 20818170T ES 2997974 T3 ES2997974 T3 ES 2997974T3
Authority
ES
Spain
Prior art keywords
block
sub
motion
reference picture
picture
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.)
Active
Application number
ES20818170T
Other languages
English (en)
Inventor
Yi-Wen Chen
Xiaoyu Xiu
Tsung-Chuan Ma
Hong-Jheng Jhu
Shuiming Ye
Xianglin Wang
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.)
Beijing Dajia Internet Informationtechnology Co Ltd
Beijing Dajia Internet Information Technology Co Ltd
Original Assignee
Beijing Dajia Internet Informationtechnology Co Ltd
Beijing Dajia Internet Information Technology Co Ltd
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 Beijing Dajia Internet Informationtechnology Co Ltd, Beijing Dajia Internet Information Technology Co Ltd filed Critical Beijing Dajia Internet Informationtechnology Co Ltd
Application granted granted Critical
Publication of ES2997974T3 publication Critical patent/ES2997974T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • H04N19/513—Processing of motion vectors
    • H04N19/517—Processing of motion vectors by encoding
    • H04N19/52—Processing of motion vectors by encoding by predictive encoding
    • 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/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/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • 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/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • 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/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/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

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

Abstract

Un dispositivo informático ejecuta un método de decodificación de datos de vídeo determinando una imagen co/ubicada de la unidad de codificación actual; ubicando un bloque vecino espacial de la unidad de codificación actual que corresponde a la imagen co-ubicada; determinando un vector de desplazamiento de movimiento para la unidad de codificación actual a partir de uno o más vectores de movimiento asociados con el bloque vecino espacial de acuerdo con un orden fijo predefinido; y reconstruyendo un vector de movimiento temporal basado en subbloques para un subbloque respectivo de una pluralidad de subbloques en la unidad de codificación actual a partir de un subbloque correspondiente en la imagen co-ubicada basándose en el vector de desplazamiento de movimiento. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Predicción de vector de movimiento temporal de subbloque para codificación de vídeo
Campo técnico
La presente solicitud se refiere en general a la codificación y decodificación de datos de vídeo y, en particular, al procedimiento y sistema de predicción de vectores de movimiento de subbloques durante la codificación y decodificación de datos de vídeo.
Antecedentes
El vídeo digital es soportado por una variedad de dispositivos electrónicos, tales como televisiones digitales, ordenadores portátiles o de escritorio, ordenadores de tableta, cámaras digitales, dispositivos de grabación digital, reproductores de medios digitales, consolas de videojuegos, teléfonos inteligentes, dispositivos de videoteleconferencia, dispositivos de transmisión continua de vídeo, etc. Los dispositivos electrónicos transmiten, reciben, codifican, decodifican y/o almacenan datos de vídeo digitales implementando estándares de compresión/descompresión de vídeo como se define por MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Parte 10, Codificación de Vídeo Avanzada (AVC), Codificación de Vídeo de Alta Eficiencia (HEVC) y estándar de Codificación de Vídeo Versátil (VVC). La compresión de vídeo incluye típicamente realizar predicción espacial (intrafotograma) y/o predicción temporal (interfotograma) para reducir o eliminar la redundancia inherente a los datos de vídeo. Para la codificación de vídeo basada en bloques, un fotograma de vídeo se particiona en uno o más segmentos, teniendo cada segmento múltiples bloques de vídeo, que también pueden denominarse unidades de árbol de codificación (CTU). Cada CTU puede contener una unidad de codificación (CU) o dividirse recursivamente en CU más pequeñas hasta que se alcanza el tamaño mínimo predefinido de la CU. Cada CU (también denominada CU hoja) contiene una o múltiples unidades de transformación (TU) y cada CU también contiene una o múltiples unidades de predicción (PU). Cada CU puede codificarse en modos intra, inter o IBC. Los bloques de vídeo en un segmento intracodificado (I) de un fotograma de vídeo se codifican utilizando predicción espacial con respecto a muestras de referencia en bloques vecinos dentro del mismo fotograma de vídeo. Los bloques de vídeo en un segmento intercodificado (P o B) de un fotograma de vídeo pueden utilizar predicción espacial con respecto a muestras de referencia en bloques vecinos dentro del mismo fotograma de vídeo o predicción temporal con respecto a muestras de referencia en otros fotogramas de vídeo de referencia anteriores y/o futuros.
La predicción espacial o temporal basada en un bloque de referencia que ha sido codificado previamente, por ejemplo, un bloque vecino, da como resultado un bloque predictivo para un bloque de vídeo actual que ha de ser codificado. El proceso de encontrar el bloque de referencia puede ser realizado por el algoritmo de coincidencia de bloques. Los datos residuales que representan diferencias de píxel entre el bloque actual a codificar y el bloque predictivo se denominan bloque residual o errores de predicción. Un bloque intercodificado se codifica de acuerdo con un vector de movimiento que apunta a un bloque de referencia en un fotograma de referencia que forma el bloque predictivo, y el bloque residual. El proceso de determinación del vector de movimiento se denomina típicamente estimación de movimiento. Un bloque intracodificado se codifica de acuerdo con un modo de intrapredicción y el bloque residual. Para una compresión adicional, el bloque residual se transforma desde el dominio de píxeles a un dominio de transformada, por ejemplo, dominio de frecuencia, lo que da como resultado coeficientes de transformada residuales, que luego pueden cuantificarse. Los coeficientes de transformada cuantificados, dispuestos inicialmente en una matriz bidimensional, pueden escanearse para producir un vector unidimensional de coeficientes de transformada, y luego codificarse por entropía en un flujo de bits de video para lograr incluso más compresión.
El flujo de bits de vídeo codificado se guarda entonces en un medio de almacenamiento legible por ordenador (por ejemplo, memoria flash) al que acceder otro dispositivo electrónico con capacidad de vídeo digital o se transmite directamente al dispositivo electrónico por cable o de forma inalámbrica. El dispositivo electrónico realiza entonces descompresión de vídeo (que es un proceso opuesto a la compresión de vídeo descrita anteriormente) mediante, por ejemplo, el análisis del flujo de bits de vídeo codificado para obtener elementos de sintaxis del flujo de bits y reconstruir los datos de vídeo digitales a su formato original a partir del flujo de bits de vídeo codificado en base, al menos en parte, a los elementos de sintaxis obtenidos del flujo de bits, y renderiza los datos de vídeo digitales reconstruidos en una pantalla del dispositivo electrónico.
Con la calidad de vídeo digital que va desde una definición alta a 4Kx2K o incluso 8Kx4K, la cantidad de datos de vídeo que se van a codificar/decodificar crece exponencialmente. Es un reto constante en términos de cómo los datos de vídeo pueden codificarse/decodificarse de manera más eficiente mientras se mantiene la calidad de imagen de los datos de vídeo decodificados.
El documento US 2019/158860 A1 divulga un dispositivo de decodificación de vídeo que se refiere a una imagen de predicción obtenida mediante compensación de movimiento utilizando un vector de movimiento para generar una imagen decodificada, una primera unidad de derivación deriva, como vector de origen de movimiento inicial, un vector de movimiento en un bloque o subbloque con una cantidad de características que satisface una condición prescrita, entre múltiples bloques o subbloques vecinos a un bloque objetivo que incluye un subbloque objetivo. En caso de predicción temporal bipredictiva, el vector de origen de movimiento inicial se deriva de los bloques o subbloques vecinos seleccionando adaptativamente el orden de escaneo de las dos listas de imágenes de referencia utilizadas para derivar el vector de origen de movimiento inicial.
Sumario
La presente solicitud describe implementaciones relacionadas con la decodificación de datos de vídeo y, más particularmente, con el sistema y el procedimiento de decodificación de una unidad de codificación actual en una imagen actual.
De acuerdo con un primer aspecto de la presente solicitud, un procedimiento de decodificación de una unidad de codificación actual en una imagen actual comprende las etapas expuestas en la reivindicación 1.
De acuerdo con un segundo aspecto de la presente solicitud, un dispositivo informático comprende las características de la reivindicación 9.
De acuerdo con un tercer aspecto de la presente solicitud, un medio de almacenamiento legible por ordenador no transitorio almacena una pluralidad de programas para su ejecución por un dispositivo informático que tiene uno o más procesadores. Los programas, cuando son ejecutados por uno o más procesadores, hacen que el dispositivo informático realice operaciones como se describió anteriormente.
De acuerdo con un cuarto aspecto de la presente solicitud, un producto de programa informático comprende instrucciones almacenadas en el mismo, en el que, cuando las instrucciones son ejecutadas por un procesador, las instrucciones hacen que el procesador realice un procedimiento de decodificación de la unidad de codificación actual en la imagen actual como se describió anteriormente.
Breve descripción de los dibujos
Los dibujos adjuntos, que se incluyen para proporcionar un mayor entendimiento de las implementaciones y se incorporan en el presente documento y constituyen una parte de la memoria descriptiva, ilustran las implementaciones descritas y junto con la descripción sirven para explicar los principios subyacentes. Los números de referencia similares se refieren a partes correspondientes.
La FIG. 1 es un diagrama de bloques que ilustra un sistema de codificación y decodificación de vídeo ejemplar de acuerdo con algunas implementaciones de la presente divulgación.
La FIG. 2 es un diagrama de bloques que ilustra un codificador de vídeo ejemplar de acuerdo con algunas implementaciones de la presente divulgación.
La FIG. 3 es un diagrama de bloques que ilustra un decodificador de vídeo ejemplar de acuerdo con algunas implementaciones de la presente divulgación.
Las FIG. 4A a 4E son diagramas de bloques que ilustran cómo un fotograma se particiona recursivamente en múltiples bloques de vídeo de diferentes tamaños y formas de acuerdo con algunas implementaciones de la presente divulgación.
La FIG. 5 es un diagrama de bloques que ilustra posiciones espacialmente vecinas y posiciones de bloque coubicadas temporalmente de una C<u>actual que se va a codificar de acuerdo con algunas implementaciones de la presente divulgación.
Las FIG. 6A-6D son diagramas de bloques que ilustran etapas para derivar predictores de vector de movimiento temporal de un bloque actual o predictores de vector de movimiento temporal de subbloque de un subbloque en el bloque actual de acuerdo con algunas implementaciones de la presente divulgación.
La FIG. 7 ilustra un diagrama de bloques para determinar un área válida para derivar predictores de vector de movimiento temporal y predictores de vector de movimiento temporal de subbloque de acuerdo con algunas implementaciones de la presente divulgación.
Las FIG. 8A-8B ilustran un diagrama de flujo que ilustra un proceso ejemplar mediante el cual un codificador de vídeo implementa las técnicas de derivar predictores de vector de movimiento temporal de subbloque de acuerdo con algunas implementaciones de la presente divulgación.
Descripción detallada
A continuación se hará referencia en detalle a implementaciones específicas, ejemplos de las cuales se ilustran en los dibujos adjuntos. En la siguiente descripción detallada, se exponen numerosos detalles específicos no limitantes para ayudar a entender la materia objeto presentada en el presente documento. Pero será evidente para un experto en la técnica que pueden utilizarse diversas alternativas sin apartarse del alcance de las reivindicaciones y la materia objeto puede ponerse en práctica sin estos detalles específicos. Por ejemplo, será evidente para un experto en la técnica que la materia objeto presentada en el presente documento puede implementarse en muchos tipos de dispositivos electrónicos con capacidades de vídeo digital. Las realizaciones no cubiertas por las reivindicaciones se proporcionan simplemente para facilitar la comprensión de las reivindicaciones.
La FIG. 1 es un diagrama de bloques que ilustra un sistema ejemplar 10 para codificar y decodificar bloques de vídeo en paralelo de acuerdo con algunas implementaciones de la presente divulgación. Como se muestra en la FIG. 1, el sistema 10 incluye un dispositivo de origen 12 que genera y codifica datos de vídeo para ser decodificados en un momento posterior por un dispositivo de destino 14. El dispositivo de origen 12 y el dispositivo de destino 14 pueden comprender cualquiera de una amplia variedad de dispositivos electrónicos, incluyendo ordenadores de escritorio o portátiles, ordenadores de tableta, teléfonos inteligentes, decodificadores, televisiones digitales, cámaras, dispositivos de visualización, reproductores de medios digitales, consolas de videojuegos, dispositivos de transmisión continua de vídeo o similares. En algunas implementaciones, el dispositivo de origen 12 y el dispositivo de destino 14 están equipados con capacidades de comunicación inalámbrica.
En algunas implementaciones, el dispositivo de destino 14 puede recibir los datos de vídeo codificados que se decodificarán a través de un enlace 16. El enlace 16 puede comprender cualquier tipo de medio o dispositivo de comunicación capaz de mover los datos de vídeo codificados desde el dispositivo de origen 12 al dispositivo de destino 14. En un ejemplo, el enlace 16 puede comprender un medio de comunicación para permitir que el dispositivo de origen 12 transmita los datos de vídeo codificados directamente al dispositivo de destino 14 en tiempo real. Los datos de vídeo codificados pueden modularse de acuerdo con un estándar de comunicación, tal como un protocolo de comunicación inalámbrica, y transmitirse al dispositivo de destino 14. El medio de comunicación puede comprender cualquier medio de comunicación inalámbrica o cableada, tal como un espectro de radiofrecuencia (RF) o una o más líneas de transmisión física. El medio de comunicación puede formar parte de una red basada en paquetes, tal como una red de área local, una red de área amplia o una red global tal como Internet. El medio de comunicación puede incluir enrutadores, conmutadores, estaciones base o cualquier otro equipo que pueda ser útil para facilitar la comunicación desde el dispositivo de origen 12 al dispositivo de destino 14.
En algunas otras implementaciones, los datos de vídeo codificados pueden transmitirse desde la interfaz de salida 22 a un dispositivo de almacenamiento 32. Posteriormente, el dispositivo de destino 14 puede acceder a los datos de vídeo codificados en el dispositivo de almacenamiento 32 a través de la interfaz de entrada 28. El dispositivo de almacenamiento 32 puede incluir cualquiera de una variedad de medios de almacenamiento de datos distribuidos o accedidos localmente tales como un disco duro, discos Blu-ray, DVD, CD-ROM, memoria flash, memoria volátil o no volátil, o cualquier otro medio de almacenamiento digital adecuado para almacenar datos de vídeo codificados. En un ejemplo adicional, el dispositivo de almacenamiento 32 puede corresponder a un servidor de archivos u otro dispositivo de almacenamiento intermedio que puede contener los datos de vídeo codificados generados por el dispositivo de origen 12. El dispositivo de destino 14 puede acceder a los datos de vídeo almacenados desde el dispositivo de almacenamiento 32 mediante transmisión continua o descarga. El servidor de archivos puede ser cualquier tipo de ordenador capaz de almacenar datos de vídeo codificados y transmitir los datos de vídeo codificados al dispositivo de destino 14. Los servidores de archivos ejemplares incluyen un servidor web (por ejemplo, para un sitio web), un servidor FTP, dispositivos de almacenamiento conectados a red (NAS) o una unidad de disco local. El dispositivo de destino 14 puede acceder a los datos de vídeo codificados a través de cualquier conexión de datos estándar, incluyendo un canal inalámbrico (por ejemplo, una conexión Wi-Fi), una conexión cableada (por ejemplo, DSL, módem de cable, etc.), o una combinación de ambos que sea adecuada para acceder a datos de vídeo codificados almacenados en un servidor de archivos. La transmisión de datos de vídeo codificados desde el dispositivo de almacenamiento 32 puede ser una transmisión de flujo continuo, una transmisión de descarga o una combinación de ambas.
Como se muestra en la FIG. 1, el dispositivo de origen 12 incluye una fuente de vídeo 18, un codificador de vídeo 20 y una interfaz de salida 22. La fuente de vídeo 18 puede incluir una fuente tal como un dispositivo de captura de vídeo, por ejemplo, una cámara de vídeo, un archivo de vídeo que contiene vídeo capturado previamente, una interfaz de alimentación de vídeo para recibir vídeo de un proveedor de contenido de vídeo, y/o un sistema de gráficos por ordenador para generar datos de gráficos por ordenador como el vídeo de origen, o una combinación de tales fuentes. Como ejemplo, si la fuente de vídeo 18 es una cámara de vídeo de un sistema de vigilancia de seguridad, el dispositivo de origen 12 y el dispositivo de destino 14 pueden formar teléfonos con cámara o videoteléfonos. Sin embargo, las implementaciones descritas en la presente solicitud pueden ser aplicables a la codificación de vídeo en general, y pueden aplicarse a aplicaciones inalámbricas y/o cableadas.
El vídeo capturado, precapturado o generado por ordenador puede ser codificado por el codificador de vídeo 20. Los datos de vídeo codificados pueden transmitirse directamente al dispositivo de destino 14 a través de la interfaz de salida 22 del dispositivo de origen 12. Los datos de vídeo codificados también (o alternativamente) pueden almacenarse en el dispositivo de almacenamiento 32 para un acceso posterior por el dispositivo de destino 14 u otros dispositivos, para su decodificación y/o reproducción. La interfaz de salida 22 puede incluir además un módem y/o un transmisor.
El dispositivo de destino 14 incluye una interfaz de entrada 28, un decodificador de vídeo 30 y un dispositivo de visualización 34. La interfaz de entrada 28 puede incluir un receptor y/o un módem y recibir los datos de vídeo codificados a través del enlace 16. Los datos de vídeo codificados comunicados a través del enlace 16, o proporcionados en el dispositivo de almacenamiento 32, pueden incluir una variedad de elementos de sintaxis generados por el codificador de vídeo 20 para su uso por el decodificador de vídeo 30 en la decodificación de los datos de vídeo. Tales elementos de sintaxis pueden incluirse dentro de los datos de video codificados transmitidos en un medio de comunicación, almacenarse en un medio de almacenamiento o almacenarse en un servidor de archivos.
En algunas implementaciones, el dispositivo de destino 14 puede incluir un dispositivo de visualización 34, que puede ser un dispositivo de visualización integrado y un dispositivo de visualización externo que está configurado para comunicarse con el dispositivo de destino 14. El dispositivo de visualización 34 muestra los datos de vídeo decodificados a un usuario, y puede comprender cualquiera de una variedad de dispositivos de visualización tales como una pantalla de cristal líquido (LCD), una pantalla de plasma, una pantalla de diodo orgánico emisor de luz (OLED) u otro tipo de dispositivo de visualización.
El codificador de vídeo 20 y el decodificador de vídeo 30 pueden funcionar de acuerdo con estándares propietarios o industriales, tales como v Vc , HEVC, MPEG-4, Parte 10, Codificación de Vídeo Avanzada (AVC) o ampliaciones de dichos estándares. Debe entenderse que la presente solicitud no se limita a un estándar de codificación/decodificación de vídeo específico y puede ser aplicable a otros estándares de codificación/decodificación de vídeo. Se contempla en general que el codificador de vídeo 20 del dispositivo de origen 12 pueda configurarse para codificar datos de vídeo de acuerdo con cualquiera de estos estándares actuales o futuros. De manera similar, también se contempla en general que el decodificador de vídeo 30 del dispositivo de destino 14 pueda configurarse para decodificar datos de vídeo de acuerdo con cualquiera de estos estándares actuales o futuros.
El codificador de vídeo 20 y el decodificador de vídeo 30 pueden implementarse cada uno como cualquiera de una variedad de circuitos codificadores adecuados, tales como uno o más microprocesadores, procesadores de señales digitales (DSP), circuitos integrados de aplicación específica (ASIC), matrices de puertas programables en campo (FPGA), lógica discreta, software, hardware, firmware o cualquier combinación de los mismos. Cuando se implementa parcialmente en software, un dispositivo electrónico puede almacenar instrucciones para el software en un medio legible por ordenador no transitorio adecuado y ejecutar las instrucciones en hardware utilizando uno o más procesadores para realizar las operaciones de codificación/decodificación de vídeo divulgadas en la presente divulgación. Cada uno del codificador de vídeo 20 y el decodificador de vídeo 30 puede estar incluido en uno o más codificadores o decodificadores, cualquiera de los cuales puede estar integrado como parte de un codificador/decodificador combinado (CÓDEC) en un dispositivo respectivo.
La FIG. 2 es un diagrama de bloques que ilustra un codificador de vídeo ejemplar 20 de acuerdo con algunas implementaciones descritas en la presente solicitud. El codificador de vídeo 20 puede realizar una codificación intra e interpredictiva de bloques de vídeo dentro de fotogramas de vídeo. La codificación intrapredictiva se basa en la predicción espacial para reducir o eliminar la redundancia espacial en datos de vídeo dentro de un fotograma o imagen de vídeo dada. La codificación interpredictiva se basa en la predicción temporal para reducir o eliminar la redundancia temporal en los datos de vídeo dentro de los fotogramas o imágenes de vídeo adyacentes de una secuencia de vídeo.
Como se muestra en la FIG. 2, el codificador de vídeo 20 incluye una memoria de datos de vídeo 40, una unidad de procesamiento de predicción 41, una memoria intermedia de imágenes decodificadas (DPB) 64, un sumador 50, una unidad de procesamiento de transformada 52, una unidad de cuantificación 54 y una unidad de codificación por entropía 56. La unidad de procesamiento de predicción 41 incluye además la unidad de estimación de movimiento 42, la unidad de compensación de movimiento 44, la unidad de partición 45, la unidad de procesamiento de intrapredicción 46 y la unidad de copia intrabloque (BC) 48. En algunas implementaciones, el codificador de vídeo 20 también incluye una unidad de cuantificación inversa 58, una unidad de procesamiento de transformada inversa 60 y un sumador 62 para la reconstrucción de bloques de vídeo. Un filtro de desbloqueo (no mostrado) puede colocarse entre el sumador 62 y el DPB 64 para filtrar los límites de bloque para eliminar artefactos de efecto de bloque del vídeo reconstruido. También se puede utilizar un filtro en bucle (no mostrado) además del filtro de desbloqueo para filtrar la salida del sumador 62. El codificador de vídeo 20 puede tomar la forma de una unidad de hardware fija o programable o puede dividirse entre una o más de las unidades de hardware fijas o programables ilustradas.
La memoria de datos de vídeo 40 puede almacenar datos de vídeo que van a codificarse por los componentes del codificador de vídeo 20. Los datos de vídeo en la memoria 40 de datos de vídeo pueden obtenerse, por ejemplo, de la fuente de vídeo 18. La DPB 64 es una memoria intermedia que almacena datos de vídeo de referencia para su uso en la codificación de datos de vídeo mediante el codificador de vídeo 20 (por ejemplo, en modos de codificación intra o interpredictiva). La memoria de datos de vídeo 40 y el DPB 64 pueden estar formados por cualquiera de una variedad de dispositivos de memoria. En diversos ejemplos, la memoria de datos de vídeo 40 puede estar en chip con otros componentes del codificador de vídeo 20, o fuera de chip con respecto a esos componentes.
Como se muestra en la FIG. 2, después de recibir datos de vídeo, la unidad de partición 45 dentro de la unidad de procesamiento de predicción 41 particiona los datos de vídeo en bloques de vídeo. Esta partición también puede incluir la partición de un fotograma de vídeo en segmentos, mosaicos u otras unidades de codificación (CU) más grandes de acuerdo con estructuras de división predefinidas tales como la estructura de árbol cuádruple asociada con los datos de vídeo. El fotograma de vídeo puede dividirse en múltiples bloques de vídeo (o conjuntos de bloques de vídeo denominados mosaicos). La unidad de procesamiento de predicción 41 puede seleccionar uno de una pluralidad de posibles modos de codificación predictiva, tal como uno de una pluralidad de modos de codificación intrapredictiva o uno de una pluralidad de modos de codificación interpredictiva, para el bloque de vídeo actual en base a resultados de error (por ejemplo, tasa de codificación y el nivel de distorsión). La unidad de procesamiento de predicción 41 puede proporcionar el bloque codificado de intra o interpredicción resultante al sumador 50 para generar un bloque residual y al sumador 62 para reconstruir el bloque codificado para su uso como parte de un fotograma de referencia posteriormente. La unidad de procesamiento de predicción 41 también proporciona elementos de sintaxis, tales como vectores de movimiento, indicadores intramodo, información de partición y otra información de sintaxis de este tipo, a la unidad de codificación por entropía 56.
Para seleccionar un modo de codificación intrapredictiva apropiado para el bloque de vídeo actual, la unidad de procesamiento de intrapredicción 46 dentro de la unidad de procesamiento de predicción 41 puede realizar la codificación intrapredictiva del bloque de vídeo actual con respecto a uno o más bloques vecinos en el mismo fotograma que el bloque actual que va a codificarse para proporcionar predicción espacial. La unidad de estimación de movimiento 42 y la unidad de compensación de movimiento 44 dentro de la unidad de procesamiento de predicción 41 realizan la codificación interpredictiva del bloque de vídeo actual con respecto a uno o más bloques predictivos en una o más fotogramas de referencia para proporcionar predicción temporal. El codificador de vídeo 20 puede realizar múltiples pases de codificación, por ejemplo, para seleccionar un modo de codificación apropiado para cada bloque de datos de vídeo.
En algunas implementaciones, la unidad de estimación de movimiento 42 determina el modo de interpredicción para un fotograma de vídeo actual generando un vector de movimiento, que indica el desplazamiento de una unidad de predicción (PU) de un bloque de vídeo dentro del fotograma de vídeo actual con respecto a un bloque predictivo dentro de un fotograma de vídeo de referencia, de acuerdo con un patrón predeterminado dentro de una secuencia de fotogramas de vídeo. La estimación de movimiento, realizada por la unidad de estimación de movimiento 42, es el proceso de generar vectores de movimiento, que estiman el movimiento para bloques de vídeo. Un vector de movimiento, por ejemplo, puede indicar el desplazamiento de una PU de un bloque de vídeo dentro de un fotograma o imagen de vídeo actual con respecto a un bloque predictivo dentro de un fotograma de referencia (u otra unidad codificada) con respecto al bloque actual que se está codificando dentro del fotograma actual (u otra unidad codificada). El patrón predeterminado puede designar fotogramas de vídeo en la secuencia como fotogramas P o fotogramas B. La unidad intra BC 48 puede determinar vectores, por ejemplo, vectores de bloque, para la codificación intra BC de una manera similar a la determinación de vectores de movimiento por la unidad de estimación de movimiento 42 para la interpredicción, o puede utilizar la unidad de estimación de movimiento 42 para determinar el vector de bloque.
Un bloque predictivo es un bloque de un fotograma de referencia que se considera que coincide estrechamente con la PU del bloque de vídeo que se va a codificar en términos de diferencia de píxeles, que se puede determinar mediante la suma de la diferencia absoluta (SAD), la suma de la diferencia cuadrática (SSD) u otras métricas de diferencia. En algunas implementaciones, el codificador de vídeo 20 puede calcular valores para posiciones de píxeles subenteros de fotogramas de referencia almacenados en la DPB 64. Por ejemplo, el codificador de vídeo 20 puede interpolar valores de posiciones de un cuarto de píxel, posiciones de un octavo de píxel u otras posiciones fraccionales de píxel del fotograma de referencia. Por lo tanto, la unidad de estimación de movimiento 42 puede realizar una búsqueda de movimiento con respecto a las posiciones de píxeles completos y las posiciones de píxeles fraccionarios y emitir un vector de movimiento con precisión de píxeles fraccionarios.
La unidad de estimación de movimiento 42 calcula un vector de movimiento para una PU de un bloque de video en un fotograma codificado de interpredición comparando la posición de la PU con la posición de un bloque predictivo de un fotograma de referencia seleccionado de una primera lista de fotogramas de referencia (Lista 0) o una segunda lista de fotogramas de referencia (Lista 1), cada una de las cuales identifica uno o más fotogramas de referencia almacenados en la DPB 64. La unidad de estimación de movimiento 42 envía el vector de movimiento calculado a la unidad de compensación de movimiento 44 y luego a la unidad de codificación por entropía 56.
La compensación de movimiento, realizada por la unidad de compensación de movimiento 44, puede implicar extraer o generar el bloque predictivo en base al vector de movimiento determinado por la unidad de estimación de movimiento 42. Tras recibir el vector de movimiento para la PU del bloque de vídeo actual, la unidad de compensación de movimiento 44 puede ubicar un bloque predictivo al que apunta el vector de movimiento en una de las listas de fotogramas de referencia, recuperar el bloque predictivo de la DPB 64 y reenviar el bloque predictivo al sumador 50. El sumador 50 forma entonces un bloque de vídeo residual de valores de diferencia de píxeles restando valores de píxeles del bloque predictivo proporcionado por la unidad 44 de compensación de movimiento de los valores de píxeles del bloque de vídeo actual que está siendo codificado. Los valores de diferencia de píxeles que forman el bloque de video residual pueden incluir componentes de diferencia de luma o croma o ambos. La unidad de compensación de movimiento 44 también puede generar elementos de sintaxis asociados con los bloques de vídeo de un fotograma de vídeo para su uso por el decodificador de vídeo 30 en la decodificación de los bloques de vídeo del fotograma de vídeo. Los elementos de sintaxis pueden incluir, por ejemplo, elementos de sintaxis que definen el vector de movimiento utilizado para identificar el bloque predictivo, cualquier indicador que indique el modo de predicción, o cualquier otra información de sintaxis descrita en el presente documento. Obsérvese que la unidad de estimación de movimiento 42 y la unidad de compensación de movimiento 44 pueden estar altamente integradas, pero se ilustran por separado con fines conceptuales.
En algunas implementaciones, la unidad intra BC 48 puede generar vectores y recuperar bloques predictivos de una manera similar a la descrita anteriormente en relación con la unidad de estimación de movimiento 42 y la unidad de compensación de movimiento 44, pero estando los bloques predictivos en el mismo fotograma que el bloque actual que se está codificando y con los vectores denominados vectores de bloque en oposición a los vectores de movimiento. En particular, la unidad intra BC 48 puede determinar un modo de intrapredicción a utilizar para codificar un bloque actual. En algunos ejemplos, la unidad intra BC 48 puede codificar un bloque actual utilizando diversos modos de intrapredicción, por ejemplo, durante pases de codificación separados, y probar su rendimiento a través del análisis de distorsión de tasa. A continuación, la unidad intra BC 48 puede seleccionar, entre los diversos modos de intrapredicción probados, un modo de intrapredicción apropiado para utilizar y generar un indicador de intramodo en consecuencia. Por ejemplo, la unidad intra BC 48 puede calcular valores de tasa-distorsión utilizando un análisis de tasa-distorsión para los diversos modos de intrapredicción probados, y seleccionar el modo de intrapredicción que tenga las mejores características de tasa-distorsión entre los modos probados como el modo de intrapredicción apropiado para utilizar. El análisis de tasa-distorsión determina generalmente una cantidad de distorsión (o error) entre un bloque codificado y un bloque original no codificado que se codificó para producir el bloque codificado, así como una tasa de bits (es decir, varios bits) utilizada para producir el bloque codificado. La unidad intra BC 48 puede calcular relaciones a partir de las distorsiones y tasas para los diversos bloques codificados para determinar qué modo de intrapredicción exhibe el mejor valor de tasa-distorsión para el bloque.
En otros ejemplos, la unidad intra BC 48 puede utilizar la unidad de estimación de movimiento 42 y la unidad de compensación de movimiento 44, en su totalidad o en parte, para realizar tales funciones para la predicción intra BC de acuerdo con las implementaciones descritas en el presente documento. En cualquier caso, para la copia intrabloque, un bloque predictivo puede ser un bloque que se considera que coincide estrechamente con el bloque que se va a codificar, en términos de diferencia de píxeles, que se puede determinar por la suma de la diferencia absoluta (SAD), la suma de la diferencia al cuadrado (SSD) u otras métricas de diferencia, y la identificación del bloque predictivo puede incluir el cálculo de valores para posiciones de píxeles sub enteros.
Tanto si el bloque predictivo es del mismo fotograma de acuerdo con la intrapredicción, como si es de un fotograma diferente de acuerdo con la interpredicción, el codificador de vídeo 20 puede formar un bloque de vídeo residual restando los valores de píxel del bloque predictivo de los valores de píxel del bloque de vídeo actual que se está codificando, formando valores de diferencia de píxel. Los valores de diferencia de píxeles que forman el bloque de vídeo residual pueden incluir diferencias de componentes de luma y croma.
La unidad de procesamiento de intrapredicción 46 puede intrapredecir un bloque de vídeo actual, como alternativa a la interpredicción realizada por la unidad de estimación de movimiento 42 y la unidad de compensación de movimiento 44, o la predicción de copia intrabloque realizada por la unidad intra-BC 48, como se ha descrito anteriormente. En particular, la unidad de procesamiento de intrapredicción 46 puede determinar un modo de intrapredicción a utilizar para codificar un bloque actual. Para hacerlo, la unidad de procesamiento de intrapredicción 46 puede codificar un bloque actual utilizando diversos modos de intrapredicción, por ejemplo, durante pases de codificación separados, y la unidad de procesamiento de intrapredicción 46 (o una unidad de selección de modo, en algunos ejemplos) puede seleccionar un modo de intrapredicción apropiado para utilizar de los modos de intrapredicción probados. La unidad de procesamiento de intrapredicción 46 puede proporcionar información indicativa del modo de intrapredicción seleccionado para el bloque a la unidad de codificación por entropía 56. La unidad de codificación por entropía 56 puede codificar la información que indica el modo de intrapredicción seleccionado en el flujo de bits.
Después de que la unidad de procesamiento de predicción 41 determine el bloque predictivo para el bloque de vídeo actual a través de interpredicción o bien intrapredicción, el sumador 50 forma un bloque de vídeo residual restando el bloque predictivo del bloque de vídeo actual. Los datos de vídeo residuales en el bloque residual pueden incluirse en una o más unidades de transformación (TU) y se proporcionan a la unidad de procesamiento de transformación 52. La unidad de procesamiento de transformada 52 transforma los datos de vídeo residuales en coeficientes de transformada residuales utilizando una transformada, tal como una transformada de coseno discreta (DCT) o una transformada conceptualmente similar.
La unidad de procesamiento de transformada 52 puede enviar los coeficientes de transformada resultantes a la unidad de cuantificación 54. La unidad de cuantificación 54 cuantifica los coeficientes de transformada para reducir aún más la tasa de bits. El proceso de cuantificación también puede reducir la profundidad de bits asociada con algunos o todos los coeficientes. El grado de cuantificación puede modificarse ajustando un parámetro de cuantificación. En algunos ejemplos, la unidad de cuantificación 54 puede realizar entonces un escaneo de una matriz que incluye los coeficientes de transformada cuantificados. Alternativamente, la unidad de codificación por entropía 56 puede realizar el escaneo.
Después de la cuantificación, la unidad de codificación por entropía 56 codifica por entropía los coeficientes de transformada cuantificados en un flujo de bits de vídeo utilizando, por ejemplo, codificación de longitud variable adaptativa al contexto (CAVLC), codificación aritmética binaria adaptativa al contexto (CABAC), codificación aritmética binaria adaptativa al contexto basada en sintaxis (SBAC), codificación por entropía por partición de intervalos de probabilidad (PIPE) u otra metodología o técnica de codificación por entropía. El flujo de bits codificado puede transmitirse entonces al decodificador de vídeo 30, o archivarse en el dispositivo de almacenamiento 32 para su posterior transmisión o recuperación por el decodificador de vídeo 30. La unidad de codificación por entropía 56 también puede codificar por entropía los vectores de movimiento y los otros elementos de sintaxis para el fotograma de vídeo actual que se está codificando.
La unidad de cuantificación inversa 58 y la unidad de procesamiento de transformada inversa 60 aplican la cuantificación inversa y la transformación inversa, respectivamente, para reconstruir el bloque de vídeo residual en el dominio de píxeles para generar un bloque de referencia para la predicción de otros bloques de vídeo. Como se ha indicado anteriormente, la unidad de compensación de movimiento 44 puede generar un bloque predictivo compensado en movimiento a partir de uno o más bloques de referencia de los fotogramas almacenados en la DPB 64. La unidad de compensación de movimiento 44 también puede aplicar uno o más filtros de interpolación al bloque predictivo para calcular valores de píxeles sub enteros para su uso en la estimación de movimiento.
El sumador 62 añade el bloque residual reconstruido al bloque predictivo compensado por movimiento producido por la unidad 44 de compensación de movimiento para producir un bloque de referencia para almacenamiento en la DPB 64. El bloque de referencia puede ser utilizado entonces por la unidad intra BC 48, la unidad de estimación de movimiento 42 y la unidad de compensación de movimiento 44 como un bloque predictivo para interpredecir otro bloque de vídeo en un fotograma de vídeo subsiguiente.
La FIG. 3 es un diagrama de bloques que ilustra un decodificador de vídeo ejemplar 30 de acuerdo con algunas implementaciones de la presente solicitud. El decodificador de vídeo 30 incluye una memoria de datos de vídeo 79, una unidad de decodificación por entropía 80, una unidad de procesamiento de predicción 81, una unidad de cuantificación inversa 86, una unidad de procesamiento de transformada inversa 88, un sumador 90 y un DPB 92. La unidad de procesamiento de predicción 81 incluye además la unidad de compensación de movimiento 82, la unidad de intrapredicción 84 y la unidad de intra BC 85. El decodificador de vídeo 30 puede realizar un proceso de decodificación generalmente recíproco al proceso de codificación descrito anteriormente con respecto al codificador de vídeo 20 en relación con la FIG. 2. Por ejemplo, la unidad de compensación de movimiento 82 puede generar datos de predicción en base a vectores de movimiento recibidos desde la unidad de decodificación por entropía 80, mientras que la unidad de intrapredicción 84 puede generar datos de predicción en base a indicadores de modo de intrapredicción recibidos desde la unidad de decodificación por entropía 80.
En algunos ejemplos, una unidad de decodificador de vídeo 30 puede ser encargada de realizar las implementaciones de la presente solicitud. Además, en algunos ejemplos, las implementaciones de la presente divulgación pueden dividirse entre una o más de las unidades del decodificador de vídeo 30. Por ejemplo, la unidad intra BC 85 puede realizar las implementaciones de la presente solicitud, solas o en combinación con otras unidades del decodificador de vídeo 30, tales como la unidad de compensación de movimiento 82, la unidad de intrapredicción 84 y la unidad de decodificación por entropía 80. En algunos ejemplos, el decodificador de vídeo 30 puede no incluir la unidad intra BC 85 y la funcionalidad de la unidad intra BC 85 puede ser realizada por otros componentes de la unidad de procesamiento de predicción 81, tal como la unidad de compensación de movimiento 82.
La memoria 79 de datos de vídeo puede almacenar datos de vídeo, tales como un flujo de bits de vídeo codificado, para ser decodificados por los otros componentes del decodificador 30 de vídeo. Los datos de vídeo almacenados en la memoria 79 de datos de vídeo pueden obtenerse, por ejemplo, desde el dispositivo 32 de almacenamiento, desde una fuente de vídeo local, tal como una cámara, a través de comunicación de datos de vídeo por red cableada o inalámbrica, o accediendo a medios de almacenamiento de datos físicos (por ejemplo, una unidad flash o disco duro). La memoria 79 de datos de vídeo puede incluir una memoria intermedia de imágenes codificadas (CPB) que almacena datos de vídeo codificados de un flujo de bits de vídeo codificado. La memoria intermedia de imágenes decodificadas (DPB) 92 del decodificador de vídeo 30 almacena datos de vídeo de referencia para su uso en la decodificación de datos de vídeo por el decodificador de vídeo 30 (por ejemplo, en modos de codificación intra o interpredictiva). La memoria 79 de datos de vídeo y la DPB 92 pueden estar formadas por cualquiera de una variedad de dispositivos de memoria, tales como memoria dinámica de acceso aleatorio (DRAM), incluyendo DRAM síncrona (SDRAM), RAM magnetorresistiva (MRAM), RAM resistiva (RRAM) u otros tipos de dispositivos de memoria. Con fines ilustrativos, la memoria 79 de datos de vídeo y la DPB 92 se representan como dos componentes distintos del decodificador 30 de vídeo en la FIG. 3. Pero será evidente para un experto en la técnica que la memoria 79 de datos de vídeo y el DPB 92 pueden ser proporcionados por el mismo dispositivo de memoria o dispositivos de memoria separados. En algunos ejemplos, la memoria 79 de datos de vídeo puede estar en chip con otros componentes del decodificador 30 de vídeo, o fuera de chip con respecto a esos componentes.
Durante el proceso de decodificación, el decodificador de vídeo 30 recibe un flujo de bits de vídeo codificado que representa bloques de vídeo de un fotograma de vídeo codificada y elementos de sintaxis asociados. El decodificador de vídeo 30 puede recibir los elementos de sintaxis a nivel de fotograma de vídeo y/o a nivel de bloque de vídeo. La unidad de decodificación por entropía 80 del decodificador de vídeo 30 decodifica por entropía el flujo de bits para generar coeficientes cuantificados, vectores de movimiento o indicadores de modo de intrapredicción y otros elementos de sintaxis. La unidad de decodificación por entropía 80 reenvía entonces los vectores de movimiento y otros elementos de sintaxis a la unidad de procesamiento de predicción 81.
Cuando el fotograma de vídeo se codifica como un fotograma codificado intrapredictivo (I) o para bloques predictivos intracodificados en otros tipos de fotogramas, la unidad de intrapredicción 84 de la unidad de procesamiento de predicción 81 puede generar datos de predicción para un bloque de vídeo del fotograma de vídeo actual en base a un modo de intrapredicción señalizado y datos de referencia de bloques previamente decodificados del fotograma actual. Cuando el fotograma de vídeo se codifica como un fotograma codificado interpredictivo (es decir, B o P), la unidad de compensación de movimiento 82 de la unidad de procesamiento de predicción 81 produce uno o más bloques predictivos para un bloque de vídeo del fotograma de vídeo actual en base a los vectores de movimiento y otros elementos de sintaxis recibidos de la unidad de decodificación por entropía 80. Cada uno de los bloques predictivos puede producirse a partir de un fotograma de referencia dentro de una de las listas de fotogramas de referencia. El decodificador de vídeo 30 puede construir las listas de fotogramas de referencia, la Lista 0 y la Lista 1, utilizando técnicas de construcción predeterminadas basadas en fotogramas de referencia almacenadas en la DPB 92.
En algunos ejemplos, cuando el bloque de vídeo se codifica de acuerdo con el modo intra BC descrito en el presente documento, la unidad intra BC 85 de la unidad de procesamiento de predicción 81 produce bloques predictivos para el bloque de vídeo actual en base a vectores de bloque y otros elementos de sintaxis recibidos de la unidad de decodificación por entropía 80. Los bloques predictivos pueden estar dentro de una región reconstruida de la misma imagen que el bloque de vídeo actual definido por el codificador de vídeo 20.
La unidad de compensación de movimiento 82 y/o la unidad intra BC 85 determinan la información de predicción para un bloque de vídeo del fotograma de vídeo actual analizando los vectores de movimiento y otros elementos de sintaxis, y a continuación utiliza la información de predicción para producir los bloques predictivos para el bloque de vídeo actual que se está decodificando. Por ejemplo, la unidad de compensación de movimiento 82 utiliza algunos de los elementos de sintaxis recibidos para determinar un modo de predicción (por ejemplo, intra o inter predicción) utilizado para codificar bloques de vídeo del fotograma de vídeo, un tipo de fotograma de inter predicción (por ejemplo, B o P), información de construcción para una o más de las listas de fotogramas de referencia para el fotograma, vectores de movimiento para cada bloque de vídeo codificado interpredictivo del fotograma, estado de interpredicción para cada bloque de vídeo codificado interpredictivo del fotograma y otra información para decodificar los bloques de vídeo en el fotograma de vídeo actual.
De manera similar, la unidad intra BC 85 puede utilizar algunos de los elementos de sintaxis recibidos, por ejemplo, un indicador, para determinar que el bloque de vídeo actual se predijo utilizando el modo intra BC, información de construcción de qué bloques de vídeo del fotograma están dentro de la región reconstruida y debe almacenarse en el DPB 92, vectores de bloque para cada bloque de vídeo predicho intra BC del fotograma, estado de predicción intra BC para cada bloque de vídeo predicho intra BC del fotograma y otra información para decodificar los bloques de vídeo en el fotograma de vídeo actual.
La unidad de compensación de movimiento 82 también puede realizar interpolación utilizando los filtros de interpolación como se utilizan por el codificador de vídeo 20 durante la codificación de los bloques de vídeo para calcular valores interpolados para píxeles subenteros de bloques de referencia. En este caso, la unidad de compensación de movimiento 82 puede determinar los filtros de interpolación utilizados por el codificador de vídeo 20 a partir de los elementos de sintaxis recibidos y utilizar los filtros de interpolación para producir bloques predictivos.
La unidad de cuantificación inversa 86 cuantifica inversamente los coeficientes de transformación cuantificados proporcionados en el flujo de bits y decodificados por entropía por la unidad de decodificación por entropía 80 utilizando el mismo parámetro de cuantificación calculado por el codificador de video 20 para cada bloque de video en el fotograma de video para determinar un grado de cuantificación. La unidad de procesamiento de transformada inversa 88 aplica una transformada inversa, por ejemplo, una DCT inversa, una transformada entera inversa o un proceso de transformada inversa conceptualmente similar, a los coeficientes de transformada para reconstruir los bloques residuales en el dominio de píxel.
Después de que la unidad de compensación de movimiento 82 o la unidad intra BC 85 genera el bloque predictivo para el bloque de vídeo actual en base a los vectores y otros elementos de sintaxis, el sumador 90 reconstruye el bloque de vídeo decodificado para el bloque de vídeo actual sumando el bloque residual de la unidad de procesamiento de transformada inversa 88 y un bloque predictivo correspondiente generado por la unidad de compensación de movimiento 82 y la unidad intra BC 85. Un filtro en bucle (no representado) puede colocarse entre el sumador 90 y el DPB 92 para procesar adicionalmente el bloque de vídeo decodificado. Los bloques de vídeo decodificados en un fotograma dado se almacenan entonces en el DPB 92, que almacena fotogramas de referencia utilizados para la compensación de movimiento subsiguiente de los siguientes bloques de vídeo. El DPB 92, o un dispositivo de memoria separado del DPB 92, también puede almacenar vídeo decodificado para su presentación posterior en un dispositivo de visualización, tal como el dispositivo de visualización 34 de la FIG. 1.
En un proceso típico de codificación de vídeo, una secuencia de vídeo incluye típicamente un conjunto ordenado de fotogramas o imágenes. Cada fotograma puede incluir tres matrices de muestras, indicadas como SL, SCb y SCr. SL es una matriz bidimensional de muestras de luma. SCb es una matriz bidimensional de muestras de croma Cb. El SCr es una matriz bidimensional de muestras de croma de Cr. En otros casos, un fotograma puede ser monocromo y, por lo tanto, incluye solo una matriz bidimensional de muestras de luma.
Como se muestra en la FIG. 4A, el codificador de vídeo 20 (o más específicamente la unidad de partición 45) genera una representación codificada de un fotograma particionando primero el fotograma en un conjunto de unidades de árbol de codificación (CTU). Un fotograma de vídeo puede incluir un número entero de CTU ordenadas consecutivamente en un orden de escaneo de fotograma de izquierda a derecha y de arriba a abajo. Cada CTU es una unidad de codificación lógica más grande y la anchura y la altura de la CTU se señalizan por el codificador de vídeo 20 en un conjunto de parámetros de secuencia, de modo que todas las CTU en una secuencia de vídeo tienen el mismo tamaño que es uno de 128x128, 64x64, 32x32 y 16x16. Pero debe observarse que la presente solicitud no está necesariamente limitada a un tamaño particular. Como se muestra en la FIG. 4B, cada CTU puede comprender un bloque de árbol de codificación (CTB) de muestras de luma, dos bloques de árbol de codificación correspondientes de muestras de croma y elementos de sintaxis utilizados para codificar las muestras de los bloques de árbol de codificación. Los elementos de sintaxis describen propiedades de diferentes tipos de unidades de un bloque codificado de píxeles y como la secuencia de video puede reconstruirse en el decodificador de video 30, incluyendo inter o predicción intra, modo de predicción intra, vectores de movimiento y otros parámetros. En imágenes monocromas o imágenes que tienen tres planos de color separados, una CTU puede comprender un único bloque de árbol de codificación y elementos de sintaxis utilizados para codificar las muestras del bloque de árbol de codificación. Un bloque de árbol de codificación puede ser un bloque NxN de muestras.
Para lograr un mejor rendimiento, el codificador de vídeo 20 puede realizar de forma recursiva una partición de árbol, tal como una partición de árbol binario, una partición de árbol ternario, una partición de árbol cuádruple o una combinación de ambas en los bloques de árbol de codificación de la CTU y dividir la CTU en unidades de codificación (CU) más pequeñas. Como se representa en la FIG. 4C, la CTU 400 de 64x64 se divide primero en cuatro CU más pequeñas, teniendo cada una un tamaño de bloque de 32x32. Entre las cuatro CU más pequeñas, la CU 410 y la CU 420 se dividen cada una en cuatro CU de 16x16 por tamaño de bloque. Las dos CU de 16x16430 y 440 se dividen cada una adicionalmente en cuatro CU de 8x8 por tamaño de bloque. La FIG. 4D representa una estructura de datos de árbol cuádruple que ilustra el resultado final del proceso de partición de la CTU 400 como se representa en la FIG. 4C, correspondiendo cada nodo hoja del árbol cuádruple a una CU de un tamaño respectivo que varía de 32x32 a 8x8. Al igual que la CTU representada en la FIG. 4B, cada CU puede comprender un bloque de codificación (CB) de muestras de luma y dos bloques de codificación correspondientes de muestras de croma de un fotograma del mismo tamaño, y elementos de sintaxis utilizados para codificar las muestras de los bloques de codificación. En imágenes monocromas o imágenes que tienen tres planos de color separados, una CU puede comprender un único bloque de codificación y estructuras de sintaxis utilizadas para codificar las muestras del bloque de codificación. Debe observarse que la partición de árbol cuádruple representada en las FIG. 4C y 4D es solo para fines ilustrativos y una CTU puede dividirse en CU para adaptarse a características locales variables en base a particiones de árbol cuádruple/ternario/binario. En la estructura de árbol de múltiples tipos, una CTU se particiona por una estructura de árbol cuádruple y cada CU de hoja de árbol cuádruple puede particionarse adicionalmente por una estructura de árbol binario y ternario. Como se muestra en la FIG.4E, hay cinco tipos de partición posibles de un bloque de codificación que tiene una anchura W y una altura H, es decir, partición cuaternaria, partición binaria horizontal, partición binaria vertical, partición ternaria horizontal y partición ternaria vertical.
En algunas implementaciones, el codificador de vídeo 20 puede particionar además un bloque de codificación de una CU en uno o más bloques de predicción MxN (PB). Un bloque de predicción es un bloque rectangular (cuadrado o no cuadrado) de muestras en el que se aplica la misma predicción, inter o intra. Una unidad de predicción (PU) de una CU puede comprender un bloque de predicción de muestras de luma, dos bloques de predicción correspondientes de muestras de croma y elementos de sintaxis utilizados para predecir los bloques de predicción. En imágenes monocromas o imágenes que tienen tres planos de color separados, una PU puede comprender un único bloque de predicción y estructuras de sintaxis utilizadas para predecir el bloque de predicción. El codificador de vídeo 20 puede generar bloques predictivos de luma, Cb y Cr para bloques de predicción de luma, Cb y Cr de cada PU de la CU.
El codificador de vídeo 20 puede utilizar intrapredicción o interpredicción para generar los bloques predictivos para una PU. Si el codificador de vídeo 20 utiliza la intrapredicción para generar los bloques predictivos de una PU, el codificador de vídeo 20 puede generar los bloques predictivos de la PU en base a muestras decodificadas del fotograma asociado con la PU. Si el codificador de vídeo 20 utiliza interpredicción para generar los bloques predictivos de una PU, el codificador de vídeo 20 puede generar los bloques predictivos de la PU en base a muestras decodificadas de una o más fotogramas distintos del fotograma asociado con la PU.
Después de que el codificador de vídeo 20 genere bloques predictivos de luma, Cb y Cr para una o más PU de una CU, el codificador de vídeo 20 puede generar un bloque residual de luma para la CU restando los bloques predictivos de luma de la CU de su bloque de codificación de luma original de manera que cada muestra en el bloque residual de luma de la CU indica una diferencia entre una muestra de luma en uno de los bloques predictivos de luma de la CU y una muestra correspondiente en el bloque de codificación de luma original de la CU. De manera similar, el codificador de vídeo 20 puede generar un bloque residual de Cb y un bloque residual de Cr para la CU, respectivamente, de manera que cada muestra en el bloque residual de Cb de la CU indica una diferencia entre una muestra de Cb en uno de los bloques de Cb predictivos de la CU y una muestra correspondiente en el bloque de codificación de Cb original de la CU y cada muestra en el bloque residual de Cr de la CU puede indicar una diferencia entre una muestra de Cr en uno de los bloques de Cr predictivos de la CU y una muestra correspondiente en el bloque de codificación de Cr original de la CU.
Además, como se ilustra en la FIG. 4C, el codificador de vídeo 20 puede utilizar partición de árbol cuádruple para descomponer los bloques residuales de luma, Cb y Cr de una CU en uno o más bloques de transformada de luma, Cb y Cr. Un bloque de transformada es un bloque rectangular (cuadrado o no cuadrado) de muestras en las que se aplica la misma transformada. Una unidad de transformada (TU) de una CU puede comprender un bloque de transformada de muestras de luma, dos bloques de transformada correspondientes de muestras de croma y elementos de sintaxis utilizados para transformar las muestras de bloque de transformada. Por lo tanto, cada TU de una CU puede estar asociada con un bloque de transformada de luma, un bloque de transformada de Cb y un bloque de transformada de Cr. En algunos ejemplos, el bloque de transformada de luma asociado con la TU puede ser un subbloque del bloque residual de luma de la CU. El bloque de transformada de Cb puede ser un subbloque del bloque residual de Cb de la CU. El bloque de transformada de Cr puede ser un subbloque del bloque residual de Cr de la CU. En imágenes monocromas o imágenes que tienen tres planos de color separados, una TU puede comprender un único bloque de transformada y estructuras de sintaxis utilizadas para transformar las muestras del bloque de transformada.
El codificador de vídeo 20 puede aplicar una o más transformadas a un bloque de transformada de luma de una TU para generar un bloque de coeficiente de luma para la TU. Un bloque de coeficientes puede ser una matriz bidimensional de coeficientes de transformada. Un coeficiente de transformada puede ser una cantidad escalar. El codificador de vídeo 20 puede aplicar una o más transformadas a un bloque de transformada de Cb de una TU para generar un bloque de coeficiente de Cb para la TU. El codificador de vídeo 20 puede aplicar una o más transformadas a un bloque de transformada de Cr de una TU para generar un bloque de coeficiente de Cr para la TU.
Después de generar un bloque de coeficientes (por ejemplo, un bloque de coeficientes de luma, un bloque de coeficientes de Cb o un bloque de coeficientes de Cr), el codificador de vídeo 20 puede cuantificar el bloque de coeficientes. La cuantificación se refiere generalmente a un proceso en el que los coeficientes de transformada se cuantifican para reducir posiblemente la cantidad de datos utilizados para representar los coeficientes de transformada, proporcionando compresión adicional. Después de que el codificador de vídeo 20 cuantice un bloque de coeficientes, el codificador de vídeo 20 puede codificar por entropía elementos de sintaxis que indican los coeficientes de transformada cuantizados. Por ejemplo, el codificador de vídeo 20 puede realizar codificación aritmética binaria adaptativa al contexto (CABAC) en los elementos de sintaxis que indican los coeficientes de transformada cuantificados. Finalmente, el codificador de vídeo 20 puede emitir un flujo de bits que incluye una secuencia de bits que forma una representación de fotogramas codificadas y datos asociados, que o bien se memoriza en el dispositivo de memorización 32 o bien se transmite al dispositivo de destino 14.
Después de recibir un flujo de bits generado por el codificador de vídeo 20, el decodificador de vídeo 30 puede analizar el flujo de bits para obtener elementos de sintaxis del flujo de bits. El decodificador de vídeo 30 puede reconstruir los fotogramas de los datos de vídeo en base, al menos en parte, a los elementos de sintaxis obtenidos a partir del flujo de bits. El proceso de reconstrucción de los datos de vídeo es generalmente recíproco al proceso de codificación realizado por el codificador de vídeo 20. Por ejemplo, el decodificador de vídeo 30 puede realizar transformadas inversas en los bloques de coeficientes asociados con las TU de una CU actual para reconstruir bloques residuales asociados con las TU de la CU actual. El decodificador de vídeo 30 también reconstruye los bloques de codificación de la CU actual añadiendo las muestras de los bloques predictivos para las PU de la CU actual a muestras correspondientes de los bloques de transformada de las TU de la CU actual. Después de reconstruir los bloques de codificación para cada CU de un fotograma, el decodificador de vídeo 30 puede reconstruir el fotograma.
Como se ha indicado anteriormente, la codificación de vídeo logra la compresión de vídeo utilizando principalmente dos modos, es decir, predicción intrafotograma (o intrapredicción) y predicción interfotograma (o interpredicción). Se observa que el IBC podría considerarse como predicción intrafotograma o como un tercer modo. Entre los dos modos, la predicción interfotograma contribuye más a la eficiencia de codificación que la predicción intrafotograma debido al uso de vectores de movimiento para predecir un bloque de vídeo actual a partir de un bloque de vídeo de referencia.
Pero con la tecnología de captura de datos de vídeo cada vez mejorada y el tamaño de bloque de vídeo más refinado para conservar detalles en los datos de vídeo, la cantidad de datos requeridos para representar vectores de movimiento para un fotograma actual también aumenta sustancialmente. Una forma de superar este desafío es beneficiarse del hecho de que no solo un grupo de CU vecinas en los dominios tanto espacial como temporal tienen datos de vídeo similares para fines de predicción, sino que los vectores de movimiento entre estas CU vecinas también son similares. Por lo tanto, es posible utilizar la información de movimiento de las CU espacialmente vecinas y/o las CU temporalmente coubicadas como una aproximación de la información de movimiento (por ejemplo, vector de movimiento) de una CU actual explorando su correlación espacial y temporal, que también se denomina ''predictor de vector de movimiento" (MVP) de la CU actual.
En lugar de codificar, en el flujo de bits de vídeo, un vector de movimiento real de la CU actual determinado por la unidad de estimación de movimiento 42 como se describió anteriormente en relación con la FIG. 2, el predictor de vector de movimiento de la CU actual se resta del vector de movimiento real de la CU actual para producir una diferencia de vector de movimiento (MVD) para la CU actual. Al hacerlo, no hay necesidad de codificar el vector de movimiento determinado por la unidad de estimación de movimiento 42 para cada CU de un fotograma en el flujo de bits de vídeo y la cantidad de datos utilizados para representar información de movimiento en el flujo de bits de vídeo puede reducirse significativamente.
Al igual que el proceso de elección de un bloque predictivo en un fotograma de referencia durante la predicción inter fotograma de un bloque de código, es necesario adoptar un conjunto de reglas tanto por el codificador de vídeo 20 como por el decodificador de vídeo 30 para construir una lista de candidatos de vector de movimiento (también conocida como "lista de fusión") para una CU actual utilizando esos posibles vectores de movimiento candidatos asociados con CU espacialmente vecinas y/o CU coubicadas temporalmente de la CU actual y luego seleccionando un miembro de la lista de candidatos de vector de movimiento como un predictor de vector de movimiento para la CU actual. Al hacerlo, no hay necesidad de transmitir la lista de candidatos de vector de movimiento en sí misma entre el codificador de vídeo 20 y el decodificador de vídeo 30 y un índice del predictor de vector de movimiento seleccionado dentro de la lista de candidatos de vector de movimiento es suficiente para que el codificador de vídeo 20 y el decodificador de vídeo 30 usen el mismo predictor de vector de movimiento dentro de la lista de candidatos de vector de movimiento para codificar y decodificar la CU actual.
En algunas implementaciones, cada CU de interpredicción tiene tres modos de predicción de vector de movimiento que incluyen inter (que también se denomina "predicción de vector de movimiento avanzada" (AMVP)), saltar y fusionar para construir la lista de candidatos de vector de movimiento. Bajo cada modo, uno o más candidatos de vector de movimiento pueden añadirse a la lista de candidatos de vector de movimiento según los algoritmos descritos a continuación. Finalmente, uno de ellos en la lista de candidatos se utiliza como el mejor predictor de vector de movimiento de la CU de interpredicción que va a codificarse en el flujo de bits de vídeo mediante el codificador 20 de vídeo o decodificarse a partir del flujo de bits de vídeo mediante el decodificador 30 de vídeo. Para encontrar el mejor predictor de vector de movimiento de la lista de candidatos, se introduce un esquema de competición de vector de movimiento (MVC) para seleccionar un vector de movimiento de un conjunto candidato dado de vectores de movimiento, es decir, la lista de candidatos de vector de movimiento, que incluye candidatos de vector de movimiento espacial y temporal.
Además de derivar candidatos de predictor de vector de movimiento de CU espacialmente vecinas o coubicadas temporalmente, los candidatos de predictor de vector de movimiento también pueden derivarse de la denominada tabla de "predicción de vector de movimiento basada en historial" (HMVP). La tabla HMVP aloja un número predefinido de predictores de vector de movimiento, cada uno de los cuales se ha utilizado para codificar/decodificar una CU particular de la misma fila de CTU (o a veces la misma CTU). Debido a la proximidad espacial/temporal de estas CU, existe una alta probabilidad de que uno de los predictores de vector de movimiento en la tabla de HMVP pueda reutilizarse para codificar/decodificar diferentes CU dentro de la misma fila de CTU. Por lo tanto, es posible lograr una mayor eficiencia de código incluyendo la tabla HMVP en el proceso de construcción de la lista de candidatos de vector de movimiento.
En algunas implementaciones, la tabla HMVP tiene una longitud fija (por ejemplo, 5) y se gestiona de una manera cuasi-Primero en Entrar-Primero en Salir (FIFO). Por ejemplo, se reconstruye un vector de movimiento para una CU cuando se decodifica un bloque intercodificado de la CU. La tabla HMVP se actualiza sobre la marcha con el vector de movimiento reconstruido porque tal vector de movimiento podría ser el predictor de vector de movimiento de una CU subsiguiente. Cuando se actualiza la tabla de HMVP, hay dos escenarios: (i) el vector de movimiento reconstruido es diferente de otros vectores de movimiento existentes en la tabla de HMVP o (ii) el vector de movimiento reconstruido es el mismo que uno de los vectores de movimiento existentes en la tabla de HMVP. Para el primer escenario, el vector de movimiento reconstruido se añade a la tabla de HMVP como la más reciente si la tabla de HMVP no está llena. Si la tabla HMVP ya está llena, el vector de movimiento más antiguo en la tabla HMVP necesita eliminarse de la tabla HMVP primero antes de que el vector de movimiento reconstruido se añada como el más reciente. En otras palabras, la tabla HMVP en este caso es similar a una memoria intermedia FIFO de manera que la información de movimiento ubicada en el encabezado de la memoria intermedia FIFO y asociada con otro bloque intercodificado previamente se desplaza fuera de la memoria intermedia de manera que el vector de movimiento reconstruido se adjunta a la cola de la memoria intermedia FIFO como el miembro más reciente en la tabla HMVP. Para el segundo escenario, el vector de movimiento existente en la tabla de HMVP que es sustancialmente idéntico al vector de movimiento reconstruido se elimina de la tabla de HMVP antes de que el vector de movimiento reconstruido se añada a la tabla de HMVP como la más reciente. Si la tabla HMVP también se mantiene en forma de una memoria intermedia FIFO, los predictores de vector de movimiento después del vector de movimiento idéntico en la tabla HMVP se desplazan hacia delante en un elemento para ocupar el espacio dejado por el vector de movimiento eliminado y el vector de movimiento reconstruido se agrega entonces a la cola de la memoria intermedia FIFO como el miembro más reciente en la tabla HMVP.
Los vectores de movimiento en la tabla HMVP podrían añadirse a las listas de candidatos de vectores de movimiento en diferentes modos de predicción tales como AMVP, fusión, salto, etc. Se ha encontrado que la información de movimiento de bloques intercodificados previamente almacenados en la tabla HMVP incluso no adyacentes al bloque actual puede utilizarse para una predicción de vectores de movimiento más eficiente.
Después de seleccionar un candidato de MVP dentro del conjunto candidato dado de vectores de movimiento para una CU actual, el codificador de vídeo 20 puede generar uno o más elementos de sintaxis para el candidato de MVP correspondiente y codificarlos en el flujo de bits de vídeo de manera que el decodificador de vídeo 30 pueda recuperar el candidato de MVP del flujo de bits de vídeo utilizando los elementos de sintaxis. Dependiendo del modo específico utilizado para construir el conjunto de candidatos de vectores de movimiento, diferentes modos (por ejemplo, AMVP, fusión, salto, etc.) tienen diferentes conjuntos de elementos de sintaxis. Para el modo AMVP, los elementos de sintaxis incluyen indicadores de interpredicción (Lista 0, Lista 1 o predicción bidireccional), índices de referencia, índices candidatos de vector de movimiento, señal residual de predicción de vector de movimiento, etc. Para el modo de salto y el modo de fusión, solo se codifican índices de fusión en el flujo de bits porque la CU actual hereda los otros elementos de sintaxis que incluyen los indicadores de interpredicción, índices de referencia y vectores de movimiento de una CU vecina a la que se hace referencia por el índice de fusión codificado. En el caso de una CU codificada por salto, la señal residual de predicción de vector de movimiento también se omite.
La FIG. 5 es un diagrama de bloques que ilustra posiciones de bloque espacialmente vecinas y coubicadas temporalmente de una CU actual a codificar/decodificar de acuerdo con algunas implementaciones de la presente divulgación. Para un modo dado, se construye una lista de candidatos de predicción de vectores de movimiento (MVP) comprobando en primer lugar la disponibilidad de vectores de movimiento asociados con las posiciones de bloque vecinas espacialmente izquierda y por encima, y la disponibilidad de vectores de movimiento asociados con posiciones de bloque coubicadas temporalmente y luego los vectores de movimiento en la tabla de HMVP. Durante el proceso de construcción de la lista de candidatos de MVP, algunos candidatos de MVP redundantes se eliminan de la lista de candidatos y, si es necesario, se añade vector de movimiento de valor cero para hacer que la lista de candidatos tenga una longitud fija (obsérvese que diferentes modos pueden tener diferentes longitudes fijas). Después de la construcción de la lista de candidatos de MVP, el codificador de vídeo 20 puede seleccionar el mejor predictor de vector de movimiento de la lista de candidatos y codificar el índice correspondiente que indica el candidato elegido en el flujo de bits de vídeo.
En algunas realizaciones, la lista de candidatos (también conocida como lista de candidatos de fusión) se construye incluyendo los siguientes cinco tipos de candidatos en el orden de:
1. MVP espacial (es decir, predictor de vector de movimiento) de CU espacialmente vecinas
2. MVP temporal de CU coubicadas
3. MVP basado en historial desde una tabla FIFO
4. MVP promedio por pares
5. MV cero
En algunas realizaciones, el tamaño de la lista de candidatos se señaliza en el encabezado de segmento y el tamaño máximo permitido de la lista de candidatos es seis (por ejemplo, en VVC). Para cada código de CU en modo de fusión, un índice del mejor candidato de fusión se codifica utilizando binarización unaria truncada (TU). El primer bin del índice de fusión se codifica con contexto y se utiliza codificación de derivación para otros bins. En el siguiente contexto de esta divulgación, este modo de fusión extendido también se denomina modo de fusión regular, ya que su concepto es el mismo que el modo de fusión utilizado en HEVC.
Usando la FIG. 5 como ejemplo y suponiendo que la lista de candidatos tiene una longitud fija de dos, la lista de candidatos de predictor de vector de movimiento (MVP) para la CU actual puede construirse realizando las siguientes etapas en orden bajo el modo AMVP:
1) Selección de candidatos de MVP de CU espacialmente vecinas
a) Derivar hasta un candidato de MVP no escalado de una de las dos CU vecinas espaciales izquierdas comenzando con A0 y terminando con A1;
b) Si no hay disponible ningún candidato de MVP no escalado de izquierda en la etapa anterior, derivar hasta un candidato de MVP escalado de una de las dos CU vecinas espaciales izquierdas comenzando con A0 y terminando con A1;
c) Derivar hasta un candidato de MVP no escalado de una de las tres CU vecinas espaciales anteriores comenzando con B0, luego B1, y terminando con B2;
d) Si no A0 ni A1 están disponibles o si están codificados en intramodos, derivar hasta un candidato de MVP escalado de una de las tres CU vecinas espaciales anteriores comenzando con B0, entonces B1 y terminando con B2;
2) Si se encuentran dos candidatos de MVP en las etapas anteriores y son idénticos, eliminar uno de los dos candidatos de la lista de candidatos de MVP;
3) Selección de candidatos de MVP a partir de CU coubicadas temporalmente
a) Si la lista de candidatos de MVP después de la etapa anterior no incluye dos candidatos de MVP, derivar hasta un candidato de MVP de las CU coubicadas temporales (por ejemplo, T0)
4) Selección de candidatos de MVP de la tabla de HMVP
a) Si la lista de candidatos de MVP después de la etapa anterior no incluye dos candidatos de MVP, derivar hasta dos MVP basados en historial de la tabla de HMVP; y
5) Si la lista de candidatos de MVP después de la etapa anterior no incluye dos candidatos de MVP, se suman a dos MVP de valor cero a la lista de candidatos de MVP.
Dado que solo hay dos candidatos en la lista de candidatos de MVP en modo AMVP construida anteriormente, un elemento de sintaxis asociado, como un indicador binario, se codifica en el flujo de bits para indicar cuál de los dos candidatos de MVP dentro de la lista de candidatos se utiliza para decodificar la CU actual.
En algunas implementaciones, la lista de candidatos de MVP para la CU actual en el modo de salto o fusión puede construirse realizando un conjunto similar de etapas en orden como los anteriores. Se observa que un tipo especial de candidato de fusión llamado "candidato de fusión por pares" también se incluye en la lista de candidatos de MVP para el modo de salto o fusión. El candidato de fusión por pares se genera promediando los MV de los dos candidatos de vector de movimiento de modo de fusión derivados previamente. El tamaño de la lista de candidatos de MVP de fusión (por ejemplo, de 1 a 6) se señaliza en un encabezado de segmento de la CU actual. Para cada CU en el modo de fusión, un índice del mejor candidato de fusión se codifica utilizando binarización unaria truncada (TU). El primer bin del índice de fusión se codifica con contexto y se utiliza codificación de derivación para otros bins. Como se mencionó anteriormente, los MVP basados en historial se pueden agregar a la lista de candidatos de MVP en modo AMVP o a la lista de candidatos de MVP de fusión después del MVP espacial y el MVP temporal. La información de movimiento de una CU intercodificada previamente se almacena en la tabla de HMVP y se utiliza como un candidato de MVP para la CU actual. La tabla HMVP se mantiene durante el proceso de codificación/decodificación. Siempre que haya una CU intercodificada no subbloque, la información de vector de movimiento asociada se añade a la última entrada de la tabla HMVP como un nuevo candidato mientras que la información de vector de movimiento almacenada en la primera entrada de la tabla HMVP se elimina de la misma (si la tabla HMVP ya está llena y no hay un duplicado idéntico de la información de vector de movimiento asociada en la tabla). Alternativamente, el duplicado idéntico de la información de vector de movimiento asociado se elimina de la tabla antes de que la información de vector de movimiento asociado se añada a la última entrada de la tabla HMVP. Como se ha indicado anteriormente, la copia intrabloque (IBC) puede mejorar significativamente la eficiencia de codificación de los materiales de contenido de pantalla. Puesto que el modo IBC se implementa como un modo de codificación a nivel de bloque, la coincidencia de bloques (BM) se realiza en el codificador de vídeo 20 para encontrar un vector de bloque óptimo para cada CU. Aquí, se utiliza un vector de bloque para indicar el desplazamiento desde el bloque actual a un bloque de referencia, que ya se ha reconstruido dentro de la imagen actual. Un modo IBC se trata como el tercer modo de predicción distinto de los modos de intra- o interpredicción. En el nivel de CU, el modo de IBC puede señalizarse como modo de AMVP de IBC o modo de salto/fusión de IBC de la siguiente manera:
- Modo AMVP de IBC: una diferencia de vector de bloque (BVD) entre el vector de bloque real de una CU y un predictor de vector de bloque de la CU seleccionado de candidatos de vector de bloque de la CU se codifica de la misma manera que se codifica una diferencia de vector de movimiento bajo el modo AMVP descrito anteriormente. El procedimiento de predicción de vectores de bloques utiliza dos candidatos de vectores de bloques como predictores, uno del vecino izquierdo y el otro del vecino superior (si se codifica con IBC). Cuando cualquiera de los vecinos no está disponible, se utilizará un vector de bloques predeterminado como predictor de vector de bloques. Se señaliza un indicador binario para indicar el índice predictor de vector de bloque. La lista de candidatos de AMVP de IBC consiste en candidatos de HMVP y espaciales.
- Modo de salto/fusión de IBC: se utiliza un índice de candidatos de fusión para indicar cuál de los candidatos de vector de bloque en la lista de candidatos de fusión (también conocida como “lista de fusión” o “lista de candidatos”) de bloques codificados de IBC vecinos se utiliza para predecir el vector de bloque para el bloque actual. La lista de candidatos de fusión de IBC consiste en candidatos espaciales, HMVP y por pares.
Las FIG. 6A-6D son diagramas de bloques que ilustran etapas para derivar predictores de vectores de movimiento temporales (TMVP) de un bloque actual o predictores de vectores de movimiento temporales de subbloque (SbTMVPS) de un subbloque de acuerdo con algunas implementaciones de la presente divulgación.
En algunas realizaciones, solo se añade un candidato de predictor de vector de movimiento temporal (TMVP) a la lista de candidatos de fusión como se describe con respecto a la FIG. 5. Un primer indicador(sps_temporal_mvp_enabled_flag)se señaliza en el conjunto de parámetros de secuencia (SPS) de la imagen y un segundo indicador(slice_temporal_mvp_enabled_flag)se señaliza en el encabezado de segmento para indicar si este candidato de TMVP está habilitado o deshabilitado. Particularmente, en la derivación de este candidato de fusión temporal, se deriva un vector de movimiento escalado a partir de MV de la imagen coubicada, que es una imagen codificada previamente en una lista de imágenes de referencia. En la derivación del candidato de movimiento temporal, un indicador explícito en el encabezado de segmento(co-located_from_10_flag)se envía en primer lugar al decodificador para indicar si la imagen coubicada se selecciona de la primera lista de fotogramas de referencia (Lista 0) o la segunda lista de fotogramas de referencia (Lista 1). Un índice de referencia coubicado(colocated_ref_idx)se envía además para indicar qué imagen en la lista utilizada se selecciona como la imagen coubicada para derivar el candidato de movimiento temporal. Los MV de la Lista 0 (también conocida como L0) y de la Lista 1 (también conocida como L1) del candidato de movimiento temporal se obtienen independientemente de acuerdo con un orden predefinido para los MV de diferentes listas en los bloques coubicados de las imágenes coubicadas de acuerdo con el pseudocódigo siguiente:
Tabla 1: Pseudocódigo para derivar MV temporal del bloque coubicado para TMVP
El vector de movimiento escalado 602 para el candidato de fusión temporal se obtiene como se ilustra por la línea de puntos en la Figura 6A, que se escala a partir del vector de movimiento seleccionado del bloque coubicado utilizando la distancia de POC tb 604 y la distancia de POC td 606, donde tb se define como la diferencia de POC entre la imagen de referencia de la imagen actual (por ejemplo, la referencia actual 608) y la imagen actual (por ejemplo, la imagen actual 610) y td se define como la diferencia de POC entre la imagen de referencia de la imagen coubicada (referencia coubicada 614) y la imagen coubicada (imagen coubicada 612). El índice de imagen de referencia del candidato de fusión temporal se establece igual a cero. Una realización práctica del proceso de escalado se describe en la especificación HEVC. Para un segmento B, se obtienen dos vectores de movimiento, uno es para la Lista de imágenes de referencia 0 y el otro es para la Lista de imágenes de referencia 1, y se combinan para hacer el candidato de fusión bipredictiva.
En el bloque coubicado (por ejemplo, el bloque coubicado 620) que pertenece al fotograma de referencia, la posición para el candidato temporal se selecciona entre los candidatos C<0>y C<1>como se representa en la Figura 6B. Si el bloque en la posición C<0>no está disponible, está intracodificada o está fuera de la CTU actual, posición C<1>se utiliza. De lo contrario, la posición C<0>se utiliza en la derivación del candidato de fusión temporal.
Algunos estándares de codificación (por ejemplo, el modelo de prueba de VVC 1) soportan el procedimiento de predicción de vectores de movimiento temporal (SbTMVP) basado en subbloques. De manera similar a la predicción de vector de movimiento temporal (TMVP) en HEVC, SbTMVP utiliza el campo de movimiento en la imagen coubicada para mejorar la predicción de vector de movimiento y el modo de fusión para las CU en la imagen actual. La misma imagen coubicada utilizada por TMVP se utiliza para SbTMVP. SbTMVP difiere de TMVP en los dos aspectos principales siguientes:
1. TMVP predice movimiento a nivel de CU pero SbTMVP predice movimiento a nivel de sub-CU;
2. Mientras que TMVP selecciona los vectores de movimiento temporales del bloque coubicado en la imagen coubicada (el bloque coubicado es el bloque inferior derecho o central en relación con la CU actual), SbTMVP aplica un desplazamiento de movimiento a la información de movimiento temporal seleccionada de la imagen coubicada, donde el desplazamiento de movimiento se obtiene del vector de movimiento de uno de los bloques vecinos espaciales de la CU actual.
El proceso de SbTMVP se ilustra en las FIG. 6C-6D. SbTMVP (SbTMVP 632 de la FIG. 6D) predice los vectores de movimiento de las sub-CU (por ejemplo, sub-CU 634) dentro de la CU actual (CU actual 636 de la FIG. 6D) en dos etapas. En la primera etapa, se examina el vecino espacial A1 (por ejemplo, vecino espacial 638) en la FIG. 6C. Si A1 tiene un vector de movimiento que usa la imagen coubicada (por ejemplo, la imagen coubicada 612 de la FIG.
6A) como su imagen de referencia, este vector de movimiento se selecciona para ser el desplazamiento de movimiento a aplicar (por ejemplo, el desplazamiento de movimiento 630 de la FIG. 6D). Si no se identifica tal vector de movimiento, entonces el desplazamiento de movimiento se establece en el vector de valor cero (0, 0). El primer vector de movimiento disponible entre los MV de la Lista 0 y la Lista 1 del bloque A1 se establece para que sea el desplazamiento de movimiento. De esta manera, en SbTMVP, el bloque correspondiente puede identificarse con mayor precisión, en comparación con TMVP, en el que el bloque correspondiente (a veces denominado bloque coubicado) siempre está en una posición inferior derecha o central con respecto a la CU actual. El pseudocódigo para determinar el desplazamiento de movimiento está más abajo.
Las variables y funciones utilizadas en la tabla anterior se ilustran como sigue.
ColFromLOFlag:la sintaxis para indicar si la imagen coubicada es de la lista de imágenes de referencia de la Lista 0
LDC:para indicar si todas las imágenes de referencia tienen valores de POC más pequeños que la imagen actual
CurrentSliceType:el tipo de segmento actual (imagen)
count:el número disponible de candidatos de fusión ya derivados
interDirA1:- interDir (1 :L0, 2:L1 o 3:Bi) del candidato de fusión N-ésimo
refIdxA1[0]:la información de movimiento L0 (por ejemplo, MV, índice ref.) del candidato de fusión N-ésimorefIdxA1[1]:la información de movimiento de L1 (por ejemplo, MV, índice ref.) del candidato de fusión N-ésimogetRefPic(M,I): una función para obtener una imagen de referencia de la Lista M de imágenes de referencia con un índice de referencia igual a I.
En la segunda etapa, se aplica el desplazamiento de movimiento identificado en la etapa 1 (es decir, se añade a las coordenadas del bloque actual) para obtener información de movimiento de nivel sub-CU (vectores de movimiento e índices de referencia) a partir de la imagen coubicada tal como se muestra en la FIG. 6D. El ejemplo en la Figura 6D supone que el desplazamiento de movimiento se establece en el movimiento del bloque A1. En la implementación real, el desplazamiento de movimiento puede establecerse en cualquiera de los bloques A1, A2, B1 o el movimiento de B2. En primer lugar, se selecciona una sub-CU representativa y la información de movimiento del bloque correspondiente de esta sub-CU representativa se utiliza como información de movimiento por defecto. En el esquema existente de SbTMVP, la sub-CU ubicada en la parte inferior derecha de la posición central de la CU actual se selecciona como la sub-CU representativa. Cuando no se podría obtener información de movimiento válida como la información de movimiento por defecto del bloque correspondiente de la sub-CU representativa, el candidato de SbTMVP se considera como no disponible. Cuando la información de movimiento por defecto está disponible, va a la siguiente etapa para derivar la información de movimiento para cada sub-CU dentro de la CU actual. Siempre que no esté disponible información de movimiento para el bloque correspondiente de ninguna sub-CU, la información de movimiento por defecto se utilizará como su movimiento temporal derivado para esa sub-CU.
A continuación, para cada sub-CU, la información de movimiento de su bloque correspondiente (la cuadrícula de movimiento más pequeña que cubre la muestra central) en la imagen coubicada se usa para derivar la información de movimiento para la sub-CU. Después de identificar la información de movimiento de la sub-CU coubicada, se convierte en los vectores de movimiento y los índices de referencia de la sub-CU actual de una manera similar al proceso TMVP de HEVC, donde se aplica un escalado de movimiento temporal para alinear las imágenes de referencia de los vectores de movimiento temporal con las de la CU actual.
Se observa que, en el diseño actual, solo el campo de movimiento dentro de una CTU coubicada más una columna en el lado derecho de la CTU coubicada en la imagen coubicada podría usarse para la derivación de SbTMVP y TMVP para cada CU. Como se muestra en la Figura 7, solo la información de movimiento dentro de la CTU coubicada más una columna de información de movimiento a la derecha de la CTU coubicada (la CTU2 es la CTU coubicada de la CU actual en este ejemplo) podría usarse para la derivación de mv temporal para SbTMVP y TMVP. En lo sucesivo, por conveniencia de ilustración, se denominará esta CTU coubicada más una columna como "área válida" para la derivación de SbTMVP/TMVP. En este contexto, siempre que un bloque NxN correspondiente en la imagen coubicada de una sub-CU se ubica fuera del área válida, el bloque NxN correspondiente se reemplaza por uno alternativo ubicado dentro de la CTU coubicada. La posición del bloque NxN alternativo se obtiene recortando la posición original del bloque NxN correspondiente que se va a ubicar dentro del área válida utilizando la ecuación siguiente. En la ecuación siguiente (proceso de recorte de posición para cada sub-CU), CurPicWidthInSamplesY y CurPicHeightInSamplesY son la anchura y altura de la imagen codificada, CTUWidthInSamplesX y CTUWidthInSamplesY son la anchura y altura de la CTU, xCtb e yCtb son la posición horizontal y vertical de la muestra superior izquierda de la CTU coubicada. xColCtrCb e yColCtrCb son la posición horizontal y vertical de la muestra representativa de la sub-CU, MotionShiftX y MotionShiftY son los componentes x e y del desplazamiento de movimiento, respectivamente. La función Clip3(x,y,z) y Min(x,y) se definen como se indica a continuación.
; z < X
;
Min( x, y ) = J *<x <= y>x > y; de otra manera
En VVC, se utiliza una lista de fusión basada en subbloques combinada que contiene tanto candidato de SbTMVP como candidatos de fusión afines para la señalización del modo de fusión basado en subbloques. El modo SbTMVP se habilita/deshabilita mediante un indicador de conjunto de parámetros de secuencia (SPS). Si el modo SbTMVP está habilitado, el predictor de SbTMVP se añade como la primera entrada de la lista de candidatos de fusión basados en subbloques, y seguido por los candidatos de fusión afines. El tamaño de la lista de fusión basada en subbloques se señaliza en SPS y el tamaño máximo permitido de la lista de fusión basada en subbloques es 5 en VVC.
El tamaño de sub-CU utilizado en SbTMVP se fija para que sea 8x8, y como se hace para el modo de fusión afín, el modo SbTMVP solo es aplicable a la CU con tanto anchura como altura que son mayores que o iguales a 8. Además, en el VVC actual, para el almacenamiento de campo de movimiento temporal utilizado por TMVP y SbTMVP, la compresión de campo de movimiento se realiza con granularidad de 8x8 en contraste con la granularidad de 16x16 en HEVC.
En algunas realizaciones, el desplazamiento de movimiento siempre se deriva de la Lista 0 mv del bloque vecino; si la Lista 0 mv no está disponible, la Lista 1 mv del bloque vecino se utiliza entonces para derivar el desplazamiento de movimiento para SbTMVP. El pseudocódigo se describe a continuación:
Pseudocódigo para determinar el desplazamiento de movimiento para SbTMVP
En algunas implementaciones que no forman parte de la invención, el desplazamiento de movimiento siempre se deriva de la Lista 1 mv del bloque vecino; si la Lista 1 mv no está disponible, la Lista 0 mv del bloque vecino se utiliza entonces para derivar el desplazamiento de movimiento para SbTMVP. El pseudocódigo se describe a continuación:
Pseudocódigo para determinar el desplazamiento de movimiento para SbTMVP
En algunas realizaciones, siempre que haya cualquier bloque correspondiente de una sub-CU ubicada fuera del área válida, el vector cero se utiliza como el vector de desplazamiento de movimiento para derivar el SbTMVP. Al hacerlo, se garantiza que los bloques correspondientes de todas las sub-CU de la CU actual se ubican dentro del área válida. Por lo tanto, no se requiere ningún proceso de recorte de posición para cada sub-CU. Hay muchas maneras de determinar si hay algún bloque correspondiente de una sub-CU en la CU actual que está ubicado fuera del área válida. En un ejemplo, el bloque correspondiente de la sub-CU de NxN superior izquierda y el bloque correspondiente de la sub-CU de NxN inferior derecha se comprueban para ver si los dos bloques correspondientes están dentro del área válida. Si uno cualquiera está ubicado fuera del área válida, se utiliza vector cero como vector de desplazamiento de movimiento; de lo contrario (ambos bloques correspondientes están ubicados dentro del área válida), el desplazamiento de movimiento derivado se utiliza para SbTMVP.
En algunas realizaciones, siempre que haya cualquier bloque correspondiente de una sub-CU ubicada fuera del área válida, el SbTMVP se considera como no disponible para la CU actual.
En algunas realizaciones, siempre que haya cualquier bloque correspondiente de una sub-CU ubicada fuera del área válida, el desplazamiento de movimiento se modifica para garantizar que los bloques correspondientes de todas las sub-CU estén ubicados dentro del área válida. Por lo tanto, no se requiere ningún proceso de recorte de posición para cada sub-CU.
En algunas implementaciones que no forman parte de la invención, el vector cero siempre se utiliza como el desplazamiento de movimiento para la derivación de SbTMVP.
En algunas realizaciones, se propone utilizar el MV por defecto derivado de la sub-CU representativa como el MV de la sub-CU que tiene un bloque correspondiente ubicado fuera del área válida.
La FIG. 7 ilustra un diagrama de bloques para determinar el área válida para derivar el TMVP y el SbTMVP para un bloque de codificación (por ejemplo, la CU 702 actual) en una imagen actual (por ejemplo, la imagen 704 actual) de acuerdo con algunas implementaciones de la presente divulgación. El área válida es un área en la imagen coubicada (por ejemplo, la imagen coubicada 704') en la que se está buscando una CU correspondiente (por ejemplo, la C<u>correspondiente 702') a una CU actual (por ejemplo, la CU actual 702) para el TMVP o SbTMVP. En algunas implementaciones, el área válida se determina por la CTU (por ejemplo, CTU2') más una columna (por ejemplo, una memoria intermedia 706 de TMV de columna) para derivar el TMVP y el SbTMVP. La restricción de área válida es un diseño para la reducción del uso de memoria. Al restringir el área válida como la CTU coubicada más una columna, solo la información de movimiento dentro del área válida necesita almacenarse en la memoria interna (por ejemplo, caché) para reducir el coste promedio (tiempo o energía) de acceso a los datos de movimiento temporal desde la memoria exterior. Actualmente, el tamaño máximo de CTU es 128x128 en VVC (el tamaño máximo de CTU puede determinarse en la última etapa para perfiles de VVC), y el tamaño de CTU podría establecerse como menor que 128x128 (por ejemplo, 64x64 o 32x32). En un ejemplo, cuando el tamaño de la CTU se establece en 64x64, el área válida se restringe como el bloque 64x64 coubicado más una columna. Dado que el diseño de la memoria intermedia de MV temporal para la CTU máxima ya existe, puede ser poco recomendable utilizar un área válida más pequeña que el tamaño de la CTU máxima desde la perspectiva de eficiencia de codificación. En algunas realizaciones, el área válida siempre se fija como el tamaño de CTU máximo permisible más una columna sin importar qué tamaño de CTU esté en uso.
En algunas realizaciones, el área válida se modifica para ser solo la CTU coubicada.
En algunas realizaciones, el área válida es la CTU coubicada más una columna cuando el tamaño de CTU es igual al tamaño máximo de CTU. Cuando el tamaño de la CTU es menor que el tamaño máximo de la CTU, el área válida se modifica para ser la CTU coubicada más una columna a la derecha de la CTU coubicada y una fila debajo de la CTU coubicada.
Las FIG. 8A-8B ilustran un diagrama de flujo que ilustra un proceso 800 ejemplar mediante el cual un codificador de vídeo implementa las técnicas de derivar predictores de vector de movimiento temporal de subbloque de acuerdo con algunas implementaciones de la presente divulgación. Aunque el proceso 800 puede ser un proceso de decodificación o un proceso de codificación, por conveniencia, el proceso 800 se describirá como un proceso de decodificación, realizado por un decodificador de vídeo (por ejemplo, el decodificador de vídeo 30 de la FIG. 3). Como la primera etapa, el decodificador determina una imagen coubicada de la unidad de codificación actual (805) (por ejemplo, recibir un primer elemento de sintaxis del flujo de bits que indica si una imagen coubicada del fotograma actual procede de una primera lista o una segunda lista; luego recibir un segundo elemento de sintaxis del flujo de bits que indica qué fotograma de la lista seleccionada se utiliza como el fotograma coubicado). Por ejemplo, con referencia a la FIG. 6A, la CU actual 601 en la imagen actual 610 corresponde a una Cu coubicada 601' en la imagen coubicada 612.
A continuación, el decodificador localiza un bloque vecino espacial de la unidad de codificación actual (810). Por ejemplo, consúltese la FIG. 6D, la unidad de codificación actual (por ejemplo, la CU actual 636) tiene un vecino espacial 638 (bloque A1). En algunas realizaciones, el bloque vecino espacial es una unidad de codificación o un subbloque. Después de localizar el bloque vecino espacial, el decodificador determina entonces un vector de desplazamiento de movimiento para la unidad de codificación actual (815). El vector de desplazamiento de movimiento indica un desplazamiento en la posición espacial entre la unidad de codificación actual (por ejemplo, la CU actual 636 en la FIG. 6D) en la imagen actual (por ejemplo, la imagen actual 610 en la FIG. 6D) y un bloque coubicado correspondiente (por ejemplo, vecino espacial 638' (bloque A1') en la FIG. 6D) en la imagen coubicada (por ejemplo, la imagen coubicada 612 en la FIG. 6D).
Para determinar el vector de desplazamiento de movimiento, el decodificador examina secuencialmente cada uno de los vectores de movimiento incluidos en la Lista 0 del bloque vecino espacial (820). De acuerdo con una determinación de que un vector de movimiento respectivo en la Lista 0 utiliza la imagen coubicada como la imagen de referencia del vector de movimiento respectivo (825): el decodificador establece el vector de movimiento respectivo en la Lista 0 como el vector de desplazamiento de movimiento (830) (por ejemplo, el vector de desplazamiento de movimiento 630), y evita examinar los vectores de movimiento subsiguientes en la Lista 0 y los vectores de movimiento en la Lista 1 del bloque vecino espacial (835). Como resultado, la búsqueda del vector de movimiento concluye y el primer vector de movimiento coincidente en la Lista 0 se utilizará como el vector de desplazamiento de movimiento. En otras palabras, el decodificador siempre comprueba primero los vectores de movimiento incluidos en la Lista 0 del bloque vecino espacial antes de comprobar la Lista 1.
Por otro lado, de acuerdo con una determinación de que ningún vector de movimiento respectivo en la Lista 0 utiliza la imagen coubicada como la imagen de referencia (840), el decodificador examina secuencialmente cada uno de los vectores de movimiento incluidos en la Lista 1 del bloque vecino espacial (845). Es decir, el decodificador solamente comprueba la Lista 1 del bloque vecino espacial de vectores de movimiento si y solamente si la búsqueda de vectores de movimiento en la Lista 0 devuelve resultados negativos.
Mientras se buscan vectores de movimiento en la Lista 1 del bloque vecino espacial, de acuerdo con una determinación de que un vector de movimiento respectivo en la Lista 1 utiliza la imagen coubicada como la imagen de referencia del vector de movimiento respectivo (850): el decodificador establece el vector de movimiento respectivo en la Lista 1 como el vector de desplazamiento de movimiento (855), y evita examinar vectores de movimiento subsiguientes en la Lista 1 (860). Es decir, el primer vector de movimiento coincidente en la Lista 1 se utilizará como el vector de desplazamiento de movimiento. De acuerdo con una determinación de que ningún vector de movimiento respectivo en la Lista 1 utiliza la imagen coubicada como la imagen de referencia del vector de movimiento respectivo (865), el decodificador establece el vector de desplazamiento de movimiento para que sea un vector de valor cero (870). Como resultado, la unidad de codificación correspondiente y la unidad de codificación actual están en la misma posición relativa con respecto a la imagen coubicada y la imagen actual (por ejemplo, sin desplazamiento en movimiento entre la unidad de codificación actual y la unidad de codificación correspondiente).
Finalmente, el decodificador reconstruye un vector de movimiento temporal basado en subbloques para un subbloque respectivo de una pluralidad de subbloques en la unidad de codificación actual a partir de un subbloque correspondiente en la imagen coubicada basado en el vector de desplazamiento de movimiento (875). Por ejemplo, con referencia a la FIG. 6D, el predictor de vector de movimiento temporal de subbloque 632 se construye utilizando el vector de desplazamiento de movimiento 630 para localizar el vector de movimiento temporal de subbloque 631 correspondiente después del escalado (por ejemplo, el proceso de escalado descrito con respecto a la FIG. 6A y la descripción relacionada). En algunas realizaciones, un subbloque incluye uno o dos vectores de movimiento temporal, de la Lista 0 y la Lista 1.
En algunas realizaciones, la reconstrucción del vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual a partir del subbloque correspondiente en la imagen coubicada basado en el vector de desplazamiento de movimiento incluye predecir vectores de movimiento temporal basados en subbloques para un subbloque respectivo de una pluralidad de subbloques en la unidad de codificación actual, que incluye: buscar, dentro de un área predefinida (por ejemplo, área válida) en la imagen coubicada, un subbloque coubicado correspondiente al subbloque respectivo basado en el vector de desplazamiento de movimiento; de acuerdo con una determinación de que el subbloque coubicado existe dentro del área predefinida en la imagen coubicada: identificar uno o dos vectores de movimiento del subbloque coubicado; y establecer los vectores de movimiento temporales basados en subbloque para el subbloque respectivo como el uno o dos vectores de movimiento escalados en base a una primera distancia de recuento de orden de imagen (POC) (por ejemplo, distancia de POC tb en la FIG. 6A) entre la imagen actual y una imagen de referencia de la imagen actual, y una segunda distancia de POC (por ejemplo, distancia de POD td en la FIG. 6A) entre la imagen coubicada y una imagen de referencia de la imagen coubicada. En algunas realizaciones, de acuerdo con una determinación de que el subbloque coubicado no existe dentro del área predefinida en la imagen coubicada, los vectores de movimiento temporales basados en subbloques para el subbloque correspondiente se establecen para que sean vectores de movimiento de valor cero. En algunas otras realizaciones, de acuerdo con una determinación de que el subbloque coubicado no existe dentro del área predefinida en la imagen coubicada, un subbloque alternativo dentro del área predefinida en la imagen coubicada se establece como el subbloque correspondiente. Por ejemplo, el subbloque alternativo es el subbloque límite dentro del área predefinida que está más cerca del subbloque coubicado.
En algunas realizaciones, el área predefinida tiene un tamaño igual al tamaño de CTU máximo permisible más una columna, independientemente del tamaño de la CTU que incluye la unidad de codificación coubicada.
En algunas implementaciones que no forman parte de la invención, el decodificador comprueba los vectores de movimiento en la Lista 1 del bloque vecino espacial primero antes de comprobar la Lista 0.
En uno o más ejemplos, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones pueden almacenarse en o transmitirse a través de, como una o más instrucciones o código, un medio legible por ordenador y ejecutarse por una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador, que corresponden a un medio tangible, tal como medios de almacenamiento de datos, o medios de comunicación, incluyendo cualquier medio que facilite la transferencia de un programa informático de un lugar a otro, por ejemplo, de acuerdo con un protocolo de comunicación. De esta manera, los medios legibles por ordenador pueden corresponder generalmente a (1) medios de almacenamiento legibles por ordenador tangibles que no son transitorios o (2) un medio de comunicación tal como una señal u onda portadora. Los medios de almacenamiento de datos pueden ser cualquier medio disponible al que pueda accederse mediante uno o más ordenadores o uno o más procesadores para recuperar instrucciones, código y/o estructuras de datos para la implementación de las implementaciones descritas en la presente solicitud. Un producto de programa informático puede incluir un medio legible por ordenador.
La terminología utilizada en la descripción de las implementaciones en el presente documento tiene el propósito de describir implementaciones particulares solamente y no pretende limitar el alcance de las reivindicaciones. Tal como se utiliza en la descripción de las implementaciones y las reivindicaciones adjuntas, las formas singulares "un", "una" y "el" pretenden incluir también las formas plurales, a menos que el contexto indique claramente lo contrario. También se entenderá que el término "y/o" como se utiliza en el presente documento se refiere a y engloba cualquiera y todas las combinaciones posibles de uno o más de los elementos enumerados asociados. Se entenderá además que los términos "comprende" y/o "que comprende", cuando se utilizan en esta memoria descriptiva, especifican la presencia de características, elementos y/o componentes indicados, pero no excluyen la presencia o adición de una o más características, elementos, componentes y/o grupos de los mismos.
También se entenderá que, aunque los términos primero, segundo, etc. se pueden utilizar en el presente documento para describir diversos elementos, estos elementos no deben estar limitados por estos términos. Estos términos se utilizan únicamente para distinguir un elemento de otro. Por ejemplo, un primer electrodo podría denominarse segundo electrodo y, de manera similar, un segundo electrodo podría denominarse primer electrodo, sin apartarse del alcance de las implementaciones. El primer electrodo y el segundo electrodo son ambos electrodos, pero no son el mismo electrodo.
La descripción de la presente solicitud se ha presentado con fines ilustrativos y descriptivos, y no pretende ser exhaustiva o estar limitada a la invención en la forma divulgada. Muchas modificaciones, variaciones e implementaciones alternativas serán evidentes para los expertos en la técnica que tienen el beneficio de las enseñanzas presentadas en las descripciones anteriores y los dibujos asociados. La realización se eligió y describió con el fin de explicar mejor los principios de la invención, la aplicación práctica, y para permitir que otros expertos en la técnica entiendan la invención para diversas implementaciones y utilicen mejor los principios subyacentes y diversas implementaciones con diversas modificaciones según sean adecuadas para el uso particular contemplado. Por lo tanto, debe entenderse que el alcance de las reivindicaciones no debe limitarse a los ejemplos específicos de las implementaciones divulgadas y que se pretende que se incluyan modificaciones si están en el alcance de las reivindicaciones adjuntas.

Claims (13)

REIVINDICACIONES
1. Un procedimiento de decodificación de una unidad de codificación actual (601) en una imagen actual (610), comprendiendo el procedimiento:
determinar una imagen (612) coubicada para la imagen (610) actual;
determinar un vector de desplazamiento de movimiento (630) para la unidad de codificación actual (601) de acuerdo con un vector de movimiento de un bloque vecino espacial de la unidad de codificación actual (601), en el que el vector de desplazamiento de movimiento (630) indica un desplazamiento en la posición espacial entre un subbloque respectivo de una pluralidad de subbloques en la unidad de codificación actual (601) en la imagen actual (610) y un subbloque correspondiente en la imagen coubicada (612); y
reconstruir un vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630);
en donde determinar el vector de desplazamiento de movimiento (630) para la unidad de codificación actual (601) de acuerdo con el vector de movimiento del bloque vecino espacial de la unidad de codificación actual (601) comprende:
de acuerdo con una determinación de que un vector de movimiento relacionado con una primera lista de imágenes de referencia usa la imagen (612) coubicada como una imagen de referencia para el vector de movimiento relacionado con la primera lista de imágenes de referencia independientemente de (1) los recuentos de orden de imagen de la imagen actual y la imagen de referencia y (2) si la imagen (612) coubicada se deriva de la primera lista de imágenes de referencia, establecer el vector de movimiento relacionado con la primera lista de imágenes de referencia como el vector (630) de desplazamiento de movimiento; y
de acuerdo con una determinación de que el vector de movimiento relacionado con la primera lista de imágenes de referencia para el bloque vecino espacial no usa la imagen (612) coubicada como la imagen de referencia para el vector de movimiento relacionado con la primera lista de imágenes de referencia:
de acuerdo con una determinación de que un vector de movimiento relacionado con una segunda lista de imágenes de referencia para el bloque vecino espacial usa la imagen (612) coubicada como una imagen de referencia para el vector de movimiento relacionado con la segunda lista de imágenes de referencia independientemente de (1) los recuentos de orden de imagen de la imagen actual y la imagen de referencia y (2) si la imagen (612) coubicada se deriva de la primera lista de imágenes de referencia, ajustando el vector de movimiento relacionado con la segunda lista de imágenes de referencia como el vector (630) de desplazamiento de movimiento;
en donde de acuerdo con una determinación de que el vector de movimiento relacionado con la segunda lista de imágenes de referencia para el bloque vecino espacial no usa la imagen (612) coubicada como una imagen de referencia para el vector de movimiento relacionado con la segunda lista de imágenes de referencia, el vector (630) de desplazamiento de movimiento es un vector de valor cero;
en donde la primera lista de imágenes de referencia es la Lista 0 de listas de imágenes de referencia para el bloque vecino espacial, y la segunda lista de imágenes de referencia es la Lista 1 de las listas de imágenes de referencia para el bloque vecino espacial, independientemente de si la imagen (612) coubicada se deriva de la primera lista de imágenes de referencia.
2. El procedimiento de la reivindicación 1, en donde reconstruir el vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630) comprende:
determinar, dentro de un área predefinida en la imagen (612) coubicada, un subbloque coubicado correspondiente al subbloque respectivo en base al vector (630) de desplazamiento de movimiento; y establecer el vector de movimiento temporal basado en subbloques para el subbloque respectivo como uno o dos vectores de movimiento escalados derivados en base a uno o dos vectores de movimiento del subbloque coubicado, una primera distancia de recuento de orden de imagen, POC, entre la imagen actual (610) y una imagen de referencia de la imagen actual (610), y una segunda distancia de POC entre la imagen coubicada (612) y una imagen de referencia de la imagen coubicada (612).
3. El procedimiento de la reivindicación 1 o 2, en donde reconstruir el vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) en base al vector de desplazamiento de movimiento (630) comprende: determinar si un subbloque coubicado está dentro de un área predefinida en la imagen coubicada (612).
4. El procedimiento de la reivindicación 3, en donde reconstruir el vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630) comprende:
de acuerdo con una determinación de que el subbloque coubicado no existe dentro del área predefinida en la imagen coubicada (612):
establecer los vectores de movimiento temporales basados en subbloques para que el subbloque correspondiente sea vectores de movimiento de valor cero.
5. El procedimiento de la reivindicación 3, en donde reconstruir el vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630) comprende:
de acuerdo con una determinación de que el subbloque coubicado no existe dentro del área predefinida en la imagen coubicada (612):
establecer un subbloque alternativo dentro del área predefinida en la imagen colocada como el subbloque correspondiente, en donde el subbloque alternativo es el subbloque límite dentro del área predefinida que está más cerca del subbloque colocado conjuntamente.
6. El procedimiento de una cualquiera de las reivindicaciones 1 a 5, en donde el bloque vecino espacial de la unidad de codificación actual (601) es una unidad de codificación o un subbloque de una unidad de codificación.
7. El procedimiento de la reivindicación 2 o 3, en donde el área predefinida tiene un tamaño igual al tamaño máximo permisible de la CTU más una columna, independientemente del tamaño de una CTU que incluye el subbloque coubicado.
8. El procedimiento de la reivindicación 7, en donde el tamaño máximo permisible de la CTU es 128x128.
9. Dispositivo informático que comprende:
uno o más procesadores;
memoria acoplada al uno o más procesadores; y
una pluralidad de programas almacenados en la memoria que, cuando son ejecutados por uno o más procesadores, hacen que el dispositivo informático realice operaciones
que comprende:
determinar una imagen (612) coubicada para la imagen (610) actual;
determinar un vector de desplazamiento de movimiento (630) para la unidad de codificación actual (601) de acuerdo con un vector de movimiento de un bloque vecino espacial de la unidad de codificación actual (601), en el que el vector de desplazamiento de movimiento (630) indica un desplazamiento en la posición espacial entre un subbloque respectivo de una pluralidad de subbloques en la unidad de codificación actual (601) en la imagen actual (610) y un subbloque correspondiente en la imagen coubicada (612); y
reconstruir un vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630);
en donde la determinación del vector de desplazamiento de movimiento (630) para la unidad de codificación actual (601) de acuerdo con el vector de movimiento del bloque vecino espacial de la unidad de codificación actual (601) comprende:
de acuerdo con una determinación de que un vector de movimiento relacionado con una primera lista de imágenes de referencia usa la imagen (612) coubicada como una imagen de referencia para el vector de movimiento relacionado con la primera lista de imágenes de referencia independientemente de (1) los recuentos de orden de imagen de la imagen actual y la imagen de referencia y (2) si la imagen (612) coubicada se deriva de la primera lista de imágenes de referencia, establecer el vector de movimiento relacionado con la primera lista de imágenes de referencia como el vector (630) de desplazamiento de movimiento; y
de acuerdo con una determinación de que el vector de movimiento relacionado con la primera lista de imágenes de referencia para el bloque vecino espacial no usa la imagen (612) coubicada como la imagen de referencia para el vector de movimiento relacionado con la primera lista de imágenes de referencia: de acuerdo con una determinación de que un vector de movimiento relacionado con una segunda lista de imágenes de referencia para el bloque vecino espacial usa la imagen (612) coubicada como una imagen de referencia para el vector de movimiento relacionado con la segunda lista de imágenes de referencia independientemente de (1) los recuentos de orden de imagen de la imagen actual y la imagen de referencia y (2) si la imagen (612) coubicada se deriva de la primera lista de imágenes de referencia, ajustando el vector de movimiento relacionado con la segunda lista de imágenes de referencia como el vector (630) de desplazamiento de movimiento;
en donde de acuerdo con una determinación de que el vector de movimiento relacionado con la segunda lista de imágenes de referencia para el bloque vecino espacial no usa la imagen (612) coubicada como una imagen de referencia para el vector de movimiento relacionado con la segunda lista de imágenes de referencia, el vector (630) de desplazamiento de movimiento es un vector de valor cero;
en donde la primera lista de imágenes de referencia es la Lista 0 de listas de imágenes de referencia para el bloque vecino espacial, y la segunda lista de imágenes de referencia es la Lista 1 de las listas de imágenes de referencia para el bloque vecino espacial, independientemente de si la imagen (612) coubicada se deriva de la primera lista de imágenes de referencia.
10. El dispositivo informático de la reivindicación 9, en el que la reconstrucción del vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630) comprende:
determinar, dentro de un área predefinida en la imagen (612) coubicada, un subbloque coubicado correspondiente al subbloque respectivo en base al vector (630) de desplazamiento de movimiento; y establecer el vector de movimiento temporal basado en subbloques para el subbloque respectivo como uno o dos vectores de movimiento escalados derivados en base a uno o dos vectores de movimiento del subbloque coubicado, una primera distancia de recuento de orden de imagen (POC) entre la imagen actual (610) y una imagen de referencia de la imagen actual (610), y una segunda distancia de POC entre la imagen coubicada (612) y una imagen de referencia de la imagen coubicada (612).
11. El dispositivo informático de la reivindicación 9 o 10, en donde la reconstrucción del vector de movimiento temporal basado en subbloques para el subbloque respectivo de la pluralidad de subbloques en la unidad de codificación actual (601) a partir del subbloque correspondiente en la imagen coubicada (612) basado en el vector de desplazamiento de movimiento (630) comprende:
determinar si el subbloque coubicado está dentro de un área predefinida en la imagen coubicada (612).
12. Un medio de almacenamiento legible por ordenador no transitorio que almacena una pluralidad de programas para su ejecución por un dispositivo informático que tiene uno o más procesadores, en donde la pluralidad de programas, cuando se ejecutan por el uno o más procesadores, hacen que el dispositivo informático realice el procedimiento de decodificación de la unidad de codificación actual (601) en la imagen actual (610) de una cualquiera de las reivindicaciones 1-8.
13. Un producto de programa informático, que comprende instrucciones almacenadas en el mismo, en el que, cuando las instrucciones son ejecutadas por un procesador, las instrucciones hacen que el procesador realice el procedimiento de decodificación de la unidad de codificación actual (601) en la imagen actual (610) de una cualquiera de las reivindicaciones 1-8.
ES20818170T 2019-06-07 2020-06-05 Sub-block temporal motion vector prediction for video coding Active ES2997974T3 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962858916P 2019-06-07 2019-06-07
PCT/US2020/036339 WO2020247761A1 (en) 2019-06-07 2020-06-05 Sub-block temporal motion vector prediction for video coding

Publications (1)

Publication Number Publication Date
ES2997974T3 true ES2997974T3 (en) 2025-02-18

Family

ID=73652328

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20818170T Active ES2997974T3 (en) 2019-06-07 2020-06-05 Sub-block temporal motion vector prediction for video coding

Country Status (8)

Country Link
US (4) US12108047B2 (es)
EP (2) EP4429247A3 (es)
JP (3) JP7200404B2 (es)
KR (4) KR102449889B1 (es)
CN (6) CN118433411B (es)
ES (1) ES2997974T3 (es)
MX (3) MX2021015068A (es)
WO (1) WO2020247761A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7200404B2 (ja) 2019-06-07 2023-01-06 ベイジン ダージャー インターネット インフォメーション テクノロジー カンパニー リミテッド ビデオ符号化復号化のためのサブブロックの時間的動きベクトル予測
US20230227942A1 (en) * 2020-04-02 2023-07-20 Shine Technologies, Llc Separation of rare earth elements
US12493993B2 (en) * 2022-01-10 2025-12-09 Tencent America LLC Mesh compression with deduced texture coordinates
US12238294B2 (en) * 2022-04-18 2025-02-25 Tencent America LLC Sub-block based temporal motion vector predictor with an motion vector offset
WO2024011076A1 (en) * 2022-07-06 2024-01-11 Bytedance Inc. Method, apparatus, and medium for video processing
US12418659B2 (en) * 2022-07-21 2025-09-16 Tencent America LLC Motion vector prediction fusion for subblock-based temporal motion vector prediction (SbTMVP) and temporal motion vector prediction (TMVP)
WO2024156268A1 (en) * 2023-01-24 2024-08-02 Douyin Vision Co., Ltd. Method, apparatus, and medium for video processing
WO2025071364A1 (ko) * 2023-09-27 2025-04-03 주식회사 윌러스표준기술연구소 움직임 시프트를 이용한 비디오 신호 처리 방법 및 이를 위한 장치

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1668111A (zh) * 1997-12-01 2005-09-14 三星电子株式会社 运动向量预测方法
US8976873B2 (en) * 2010-11-24 2015-03-10 Stmicroelectronics S.R.L. Apparatus and method for performing error concealment of inter-coded video frames
GB2493755B (en) * 2011-08-17 2016-10-19 Canon Kk Method and device for encoding a sequence of images and method and device for decoding a sequence of images
US9674523B2 (en) * 2012-11-14 2017-06-06 Advanced Micro Devices, Inc. Methods and apparatus for transcoding digital video
GB2512829B (en) * 2013-04-05 2015-05-27 Canon Kk Method and apparatus for encoding or decoding an image with inter layer motion information prediction according to motion information compression scheme
US9930363B2 (en) * 2013-04-12 2018-03-27 Nokia Technologies Oy Harmonized inter-view and view synthesis prediction for 3D video coding
US9918098B2 (en) * 2014-01-23 2018-03-13 Nvidia Corporation Memory management of motion vectors in high efficiency video coding motion vector prediction
US11477477B2 (en) * 2015-01-26 2022-10-18 Qualcomm Incorporated Sub-prediction unit based advanced temporal motion vector prediction
WO2016165069A1 (en) * 2015-04-14 2016-10-20 Mediatek Singapore Pte. Ltd. Advanced temporal motion vector prediction in video coding
US10999595B2 (en) * 2015-11-20 2021-05-04 Mediatek Inc. Method and apparatus of motion vector prediction or merge candidate derivation for video coding
CN107071481A (zh) * 2015-12-14 2017-08-18 联发科技股份有限公司 一种视频编码解码方法及装置
US10124730B2 (en) * 2016-03-17 2018-11-13 Ford Global Technologies, Llc Vehicle lane boundary position
WO2017195608A1 (ja) * 2016-05-13 2017-11-16 シャープ株式会社 動画像復号装置
EP3264769A1 (en) * 2016-06-30 2018-01-03 Thomson Licensing Method and apparatus for video coding with automatic motion information refinement
CN116708781A (zh) * 2016-07-12 2023-09-05 韩国电子通信研究院 图像编码/解码方法以及用于该方法的记录介质
US10477238B2 (en) * 2016-09-07 2019-11-12 Qualcomm Incorporated Sub-PU based bi-directional motion compensation in video coding
WO2018066867A1 (ko) * 2016-10-04 2018-04-12 한국전자통신연구원 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체
US20180199057A1 (en) * 2017-01-12 2018-07-12 Mediatek Inc. Method and Apparatus of Candidate Skipping for Predictor Refinement in Video Coding
US10298951B2 (en) * 2017-04-06 2019-05-21 Mediatek Inc. Method and apparatus of motion vector prediction
US10602180B2 (en) * 2017-06-13 2020-03-24 Qualcomm Incorporated Motion vector prediction
US10970564B2 (en) * 2017-09-30 2021-04-06 Tusimple, Inc. System and method for instance-level lane detection for autonomous vehicle control
KR20190062273A (ko) * 2017-11-28 2019-06-05 한국전자통신연구원 영상 변환 신경망 및 영상 역변환 신경망을 이용한 영상 처리 방법 및 장치
RU2757209C1 (ru) 2018-08-29 2021-10-12 Бейджинг Дацзя Интернет Информейшн Текнолоджи Ко., Лтд. Способы и устройства для кодирования видео с использованием вектора движения временного предсказания на основе субблоков
CN109472308A (zh) * 2018-11-08 2019-03-15 华南理工大学 一种基于人工智能的免标记仪器设备特征锚点检测方法
JP2022530172A (ja) 2019-03-11 2022-06-28 アリババ・グループ・ホールディング・リミテッド 適応解像度ビデオ符号化のためのインター符号化
JP7200404B2 (ja) 2019-06-07 2023-01-06 ベイジン ダージャー インターネット インフォメーション テクノロジー カンパニー リミテッド ビデオ符号化復号化のためのサブブロックの時間的動きベクトル予測

Also Published As

Publication number Publication date
EP3967039A1 (en) 2022-03-16
CN118433410B (zh) 2025-05-13
EP3967039A4 (en) 2022-07-06
WO2020247761A1 (en) 2020-12-10
US20240430436A1 (en) 2024-12-26
EP4429247A3 (en) 2024-11-27
KR20230098705A (ko) 2023-07-04
CN118433410A (zh) 2024-08-02
CN118433411A (zh) 2024-08-02
JP2022528581A (ja) 2022-06-14
CN114363611A (zh) 2022-04-15
MX2025005142A (es) 2025-06-02
CN118433411B (zh) 2025-10-17
US20220094942A1 (en) 2022-03-24
KR20220136502A (ko) 2022-10-07
JP2025000616A (ja) 2025-01-07
CN116156199B (zh) 2023-10-03
CN118433412B (zh) 2025-04-08
EP3967039C0 (en) 2024-10-30
US20240430435A1 (en) 2024-12-26
KR20220005550A (ko) 2022-01-13
CN116156199A (zh) 2023-05-23
KR102449889B1 (ko) 2022-09-30
JP7200404B2 (ja) 2023-01-06
US20240430437A1 (en) 2024-12-26
JP7548986B2 (ja) 2024-09-10
US12108047B2 (en) 2024-10-01
KR102548345B1 (ko) 2023-06-28
MX2025005141A (es) 2025-06-02
EP4429247A2 (en) 2024-09-11
EP3967039B1 (en) 2024-10-30
CN118433412A (zh) 2024-08-02
CN114363611B (zh) 2023-03-24
KR20230098704A (ko) 2023-07-04
CN114026852A (zh) 2022-02-08
MX2021015068A (es) 2022-01-18
JP2023040048A (ja) 2023-03-22

Similar Documents

Publication Publication Date Title
ES2995045T3 (en) Methods and apparatus of video coding using history-based motion vector prediction
ES2997974T3 (en) Sub-block temporal motion vector prediction for video coding
ES3048621T3 (en) Simplifications of cross-component linear model
ES2988476T3 (es) Codificación de información de movimiento de predicción afín para codificación de vídeo
CN113242432B (zh) 视频解码的方法、计算设备和存储介质
ES3025798T3 (en) Methods and apparatus of video coding for triangle prediction
CN115514971B (zh) 对视频数据进行编码的方法和装置