ES2605530T3 - Intra-predicción de baja complejidad para codificación de vídeo - Google Patents
Intra-predicción de baja complejidad para codificación de vídeo Download PDFInfo
- Publication number
- ES2605530T3 ES2605530T3 ES15169604.4T ES15169604T ES2605530T3 ES 2605530 T3 ES2605530 T3 ES 2605530T3 ES 15169604 T ES15169604 T ES 15169604T ES 2605530 T3 ES2605530 T3 ES 2605530T3
- Authority
- ES
- Spain
- Prior art keywords
- pixels
- horizontal
- limit
- pixel
- angle
- 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
Links
- 238000000034 method Methods 0.000 claims abstract description 69
- 239000011159 matrix material Substances 0.000 claims abstract description 30
- 230000007423 decrease Effects 0.000 claims abstract description 6
- 240000007124 Brassica oleracea Species 0.000 claims description 5
- 235000003899 Brassica oleracea var acephala Nutrition 0.000 claims description 5
- 235000011301 Brassica oleracea var capitata Nutrition 0.000 claims description 5
- 235000001169 Brassica oleracea var oleracea Nutrition 0.000 claims description 5
- 230000009466 transformation Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 11
- 101100446506 Mus musculus Fgf3 gene Proteins 0.000 description 9
- 238000011002 quantification Methods 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 241000023320 Luma <angiosperm> Species 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- OSWPMRLSEDHDFF-UHFFFAOYSA-N methyl salicylate Chemical compound COC(=O)C1=CC=CC=C1O OSWPMRLSEDHDFF-UHFFFAOYSA-N 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 210000003739 neck Anatomy 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000013139 quantization Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
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/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
-
- 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/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
-
- 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/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
- H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation
- H04N19/82—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation involving filtering within a prediction loop
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
Abstract
Método de codificación de vídeo ejecutado por un procesador de un codificador de vídeo, que comprende: una etapa de recuperar al menos algunos píxeles de una matriz de píxeles de límite vertical, siendo los píxeles de límite vertical píxeles en un límite vertical que se encuentra inmediatamente a la izquierda de un bloque objetivo para codificar y en bloques verticalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente; una etapa de añadir los píxeles recuperados a una matriz de píxeles de límite horizontal, siendo los píxeles de límite píxeles horizontales en un límite horizontal que se encuentra inmediatamente por encima del bloque objetivo para codificar y en bloques horizontalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente, para extender la matriz de píxeles de límite horizontal; y una etapa de realizar intra-predicción basándose en la matriz extendida de píxeles de límite horizontal, en el que la etapa de recuperar al menos algunos píxeles de la matriz de píxeles de límite vertical incluye: obtener InvAngle de una tabla de consulta que indica valores de InvAngle en relación con valores de angle* que representan una dirección de predicción; e identificar los al menos algunos píxeles entre los píxeles de límite vertical, usando un identificador de píxeles verticales que se expresa mediante una función usando [col x InvAngle], donde col es un contador que se disminuye en 1 desde -1 hasta (size x angle*/rangelimit), donde size es un tamaño de un bloque objetivo y rangelimit define el intervalo de angle*, y en el que la etapa de añadir los píxeles recuperados a la matriz de píxeles de límite horizontal incluye: añadir un píxel identificado mediante el identificador de píxeles verticales a los píxeles de límite horizontal en una ubicación identificada mediante un identificador de píxeles horizontales [col].
Description
5
10
15
20
25
30
35
40
45
50
55
60
DESCRIPCION
Intra-prediccion de baja complejidad para codificacion de video Antecedentes de la invencion
1. Texto sobre el campo tecnico
La presente invencion se refiere a la codificacion de video y en particular a la prediccion intra-trama en la que se predice un bloque de muestra, usando pfxeles anteriormente codificados y reconstruidos de la misma trama de v^deo.
2. Informacion sobre antecedentes
El v^deo digital requiere una gran cantidad de datos para representar todas y cada una de las tramas de una secuencia de video digital (por ejemplo, serie de tramas) de una manera sin comprimir. Para la mayona de las aplicaciones no resulta viable transmitir video digital sin comprimir a traves de redes informaticas debido a limitaciones del ancho de banda. Ademas, el video digital sin comprimir requiere una gran cantidad de espacio de almacenamiento. El video digital se codifica normalmente de alguna manera para reducir los requisitos de almacenamiento y reducir los requisitos de ancho de banda.
Una tecnica para codificar video digital es la prediccion inter-trama, o inter-prediccion. La inter-prediccion aprovecha redundancias temporales entre diferentes tramas. Las tramas de video temporalmente adyacentes incluyen normalmente bloques de pfxeles, que permanecen sustancialmente iguales. Durante el procedimiento de codificacion, un vector de movimiento interrelaciona el movimiento de un bloque de pfxeles en una trama con un bloque de pfxeles similares en otra trama. Por consiguiente, no se requiere que el sistema codifique el bloque de pfxeles dos veces, sino que en vez de eso codifica el bloque de pfxeles una vez y proporciona un vector de movimiento para predecir el otro bloque de pfxeles.
Otra tecnica para codificar video digital es la prediccion intra-trama o intra-prediccion. La intra-prediccion codifica una trama o una parte de la misma sin referencia a pfxeles en otras tramas. La intra-prediccion aprovecha redundancias espaciales entre bloques de pfxeles dentro de una trama. Dado que bloques de pfxeles espacialmente adyacentes tienen generalmente atributos similares, la eficacia del procedimiento de codificacion se mejora haciendo referencia a la correlacion espacial entre bloques adyacentes. Esta correlacion puede aprovecharse mediante prediccion de un bloque objetivo basandose en modos de prediccion usados en bloques adyacentes.
Sumario de la invencion
La presente invencion proporciona en un primer aspecto un metodo de codificacion de video ejecutado por un procesador de un codificador de video tal como se define en la reivindicacion 1, en un segundo aspecto un metodo de descodificacion de video ejecutado por un procesador de un descodificador de video tal como se define en la reivindicacion 5, en un tercer aspecto un codificador de video tal como se define en la reivindicacion 9 y en un cuarto aspecto un descodificador de video tal como se define en la reivindicacion 10. En un modo de realizacion puede proporcionarse un procedimiento de intra-prediccion unico que mejora la eficacia de codificacion de video. H.264/AVC usa pfxeles de referencia en un lfmite horizontal ubicado inmediatamente por encima de un bloque objetivo que va a predecirse y pfxeles de referencia en un lfmite vertical ubicado inmediatamente a la izquierda del bloque objetivo. En la presente invencion, se recupera al menos parte de o bien una matriz de pfxeles de lfmite horizontal o bien una matriz de pfxeles de lfmite vertical. Despues, se anaden los pfxeles recuperados a los otros pfxeles de lfmite para extender la matriz de los mismos, se realiza intra-prediccion, basandose unicamente en la matriz extendida de pfxeles de lfmite. En un modo de realizacion de la presente invencion, se recuperan al menos algunos de los pfxeles de lfmite vertical y se anaden a los pfxeles de lfmite horizontal para extender la matriz de los mismos.
La presente invencion elimina el procedimiento de decision de seleccionar o bien el lfmite horizontal o bien el lfmite vertical del que se recuperan pfxeles de referencia. La presente invencion tambien elimina el procedimiento recurrente de calcular una posicion del lfmite vertical que interseca una direccion de prediccion, en el que el procedimiento de calculo recurrente incluye normalmente una operacion de division. La eliminacion de estos procedimientos permite implementar el procedimiento de intra-prediccion en arquitecturas de una instruccion, multiples datos (SIMD), mejorando asf la eficacia computacional de la codificacion de video.
En un modo de realizacion segun la presente invencion, se recuperan al menos algunos de los pfxeles entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales que se expresa mediante
5
10
15
20
25
30
35
40
45
50
55
60
donde size representa un tamano de un bloque objetivo que va a predecirse, angle representa una direccion de prediccion y col es un contador que se disminuye en 1 desde -1 hasta el angulo, Los p^xeles recuperados se anaden a los pfxeles horizontales en una ubicacion identificada mediante un identificador de pfxeles horizontales [col].
En otro modo de realizacion, al recuperar al menos algunos de los pfxeles de Kmite vertical, se calcula InvAngle a partir de
N x size angle ’
donde N es una potencia entera de 2. Despues, se recuperan al menos algunos de los pfxeles entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales que se expresa mediante [col x InvAngle » log2 N]. Los pfxeles recuperados se anaden a los pfxeles horizontales en una ubicacion identificada mediante un identificador de pfxeles horizontales [col],
En otro modo de realizacion, InvAngle se obtiene de una tabla de consulta que indica valores de InvAngle en relacion con los valores de angle.
En otro modo de realizacion, se identifica un pixel entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales [row], donde row es un contador que se aumenta en 1 desde 0 hasta size. El pixel recuperado se anade a los pfxeles de lfmite horizontal en una ubicacion identificada mediante un identificador de pfxeles horizontales [int+1], donde int es una representacion en numero entero de una posicion de un pixel que interseca una direccion de prediccion.
Los modos de realizacion de la presente invencion tambien proporcionan un codificador y un descodificador que implementan una operacion de intra-prediccion en la que se recupera al menos parte de o bien una matriz de pfxeles de lfmite horizontal o bien una matriz de pfxeles de lfmite vertical, Despues, se anaden los pfxeles recuperados a los otros pfxeles de lfmite para extender la matriz de los mismos, Se realiza intra-prediccion, basandose unicamente en la matriz extendida de pfxeles de lfmite.
Breve descripcion de los dibujos
La figura 1 es un diagrama de bloques que muestra una arquitectura de hardware a modo de ejemplo en la que puede implementarse la presente invencion,
La figura 2 es un diagrama de bloques que muestra una vista general de un codificador de video al que se le puede aplicar la presente invencion,
La figura 3 es un diagrama de bloques que muestra una vista general de un descodificador de video al que se le puede aplicar la presente invencion,
La figura 4 es un diagrama de bloques que muestra los modulos funcionales de un codificador segun un modo de realizacion de la presente invencion,
La figura 5 es un diagrama de flujo que muestra un procedimiento de intra-prediccion realizado por un modulo de intra-prediccion del modo de realizacion de la presente invencion,
La figura 6 es un diagrama de bloques que muestra los modulos funcionales de un descodificador segun un modo de realizacion de la presente invencion,
La figura 7 es un diagrama que muestra direcciones de prediccion que ilustran modos de prediccion intra_4x4 soportados en H,264/AVC,
La figura 8 es un diagrama que muestra las direcciones de prediccion propuestas en el documento n,° JCT-VC A119,
La figura 9 es un diagrama de flujo que muestra el procedimiento, propuesto en el documento JCT-VC A119, de generacion de un bloque predicho a lo largo de una de las direcciones de prediccion mostradas en la figura 7,
La figura 10 es un diagrama de flujo que muestra el procedimiento de intra-prediccion de baja complejidad realizado segun un modo de realizacion de la presente invencion,
5
10
15
20
25
30
35
40
45
50
55
60
65
La figura 11A es una vista esquematica que muestra un bloque de prediccion y matrices de p^xeles de Ifmite horizontal y vertical.
La figura 11B es una vista esquematica que muestra una matriz de pfxeles de Ifmite horizontal extendida con pfxeles de Umite vertical.
La figura 12 es un diagrama de flujo que muestra el procedimiento de extender una matriz de pfxeles de lfmite horizontal realizado segun un modo de realizacion de la presente invencion.
La figura 13 es un diagrama de flujo que muestra otro modo de realizacion de extender una matriz de pfxeles de lfmite horizontal.
La figura 14 un diagrama de flujo que muestra el procedimiento de intra-prediccion de baja complejidad realizado segun otro modo de realizacion de la presente invencion.
Descripcion detallada de los dibujos y los modos de realizacion actualmente preferidos
La figura 1 muestra una arquitectura de hardware a modo de ejemplo de un ordenador 100 en el que puede implementarse la presente invencion. Observese que la arquitectura de hardware mostrada en la figura 1 puede ser comun tanto en un codificador de video como en un descodificador de video que implementan los modos de realizacion de la presente invencion. El ordenador 100 incluye un procesador 101, memoria 102, dispositivo de almacenamiento 105 y uno o mas dispositivos de entrada y/o salida (I/O) 106 (o perifericos) que estan acoplados en comunicacion a traves de una interfaz local 107. La interfaz local 105 puede ser, por ejemplo, pero sin limitacion, uno o mas buses u otras conexiones por cable o inalambricas, tal como se conoce en la tecnica.
El procesador 101 es un dispositivo de hardware para ejecutar software, particularmente el almacenado en la memoria 102. El procesador 101 puede ser cualquier procesador fabricado a medida o comercialmente disponible, una unidad de procesamiento central (CPU), un procesador auxiliar entre varios procesadores asociados con el ordenador 100, un microprocesador basado en semiconductor (en forma de un microchip o conjunto de chips) o generalmente cualquier dispositivo para ejecutar instrucciones de software.
La memoria 102 comprende un medio legible por ordenador que puede incluir uno cualquiera o una combinacion de elementos de memoria volatil (por ejemplo, memoria de acceso aleatorio (RAM, tal como DRAM, SRAM, SDRAM, etc.)) y elementos de memoria no volatil (por ejemplo, ROM, disco duro, cinta, CD-ROM, etc.). Ademas, la memoria 102 puede incorporar medios de almacenamiento electronicos, magneticos, opticos y/o de otros tipos. Un medio legible por ordenador puede ser cualquier medio que pueda almacenar, comunicar, propagar o transportar el programa para su uso por o en conexion con el sistema, aparato o dispositivo de ejecucion de instrucciones. Observese que la memoria 102 puede tener una arquitectura distribuida, en la que diversos componentes estan situados alejados unos de otros, pero a los que puede acceder el procesador 101.
El software 103 en la memoria 102 puede incluir uno o mas programas separados, cada uno de los cuales contiene una lista ordenada de instrucciones ejecutables para implementar funciones logicas del ordenador 100, tal como se describe a continuacion. En el ejemplo de la figura 1, el software 103 en la memoria 102 define la funcionalidad de codificacion de video o descodificacion de video del ordenador 100 segun la presente invencion. Ademas, aunque no se requiere, es posible que la memoria 102 contenga un sistema operativo (O/S) 104. El sistema operativo 104 controla esencialmente la ejecucion de programas informaticos y proporciona planificacion, control de entrada-salida, gestion de archivos y datos, gestion de memoria y control de comunicacion y servicios relacionados.
El dispositivo de almacenamiento 105 del ordenador 100 puede ser uno de muchos tipos diferentes de dispositivo de almacenamiento, incluyendo un dispositivo de almacenamiento estacionario o dispositivo de almacenamiento portatil. Como ejemplo, el dispositivo de almacenamiento 105 puede ser una cinta magnetica, disco, memoria flash, memoria volatil o un dispositivo de almacenamiento diferente. Ademas, el dispositivo de almacenamiento 105 puede ser una tarjeta de memoria digital segura o cualquier otro dispositivo de almacenamiento extrafble 105.
Los dispositivos de I/O 106 pueden incluir dispositivos de entrada, por ejemplo, pero sin limitacion, una pantalla tactil, un teclado, raton, escaner, microfono u otro dispositivo de entrada. Ademas, los dispositivos de I/O 106 tambien pueden incluir dispositivos de salida, por ejemplo, pero sin limitacion, una pantalla u otros dispositivos de salida. Los dispositivos de I/O 106 pueden incluir ademas dispositivos que se comunican a traves tanto de entradas como de salidas, por ejemplo, pero sin limitacion, un modulador/desmodulador (modem; para acceder a otro dispositivo, sistema o red), un transceptor de radiofrecuencia (RF), inalambrico u otro, una interfaz telefonica, un puente, un enrutador u otros dispositivos que funcionan como entrada y como salida.
Tal como conocen bien los expertos habituales en la tecnica, la compresion de video se logra eliminando informacion redundante en una secuencia de video. Existen muchas normas diferentes de codificacion de video, ejemplos de las cuales incluyen MPEG-1, MPEG-2, MPEG-4, H.261, H.263 y H.264/AVC. Debe observarse que no
5
10
15
20
25
30
35
40
45
50
55
60
65
se pretende limitar la presente invencion en cuanto a la aplicacion de cualquier norma de codificacion de v^deo espedfica. Sin embargo, la siguiente descripcion de la presente invencion se proporciona usando el ejemplo de la norma H.264/AVC. H.264/AVC es la norma de codificacion de video mas reciente y logra una mejora de rendimiento significativa con respecto a las normas de codificacion anteriores tales como MPEG-1, MPEG-2, H.261 y H.263.
En H.264/AVC, cada trama o imagen de un video puede descomponerse en varios segmentos. Los segmentos se dividen entonces en bloques de 16x16 pfxeles denominados macrobloques, que despues pueden dividirse adicionalmente en bloques de 8x16, 16x8, 8x8, 4x8, 8x4, hasta 4x4 pfxeles. Hay cinco tipos de segmentos soportados por H.264/AVC. En los segmentos I, todos los macrobloques se codifican usando intra-prediccion. En los segmentos P, los macrobloques pueden codificarse usando intra o inter-prediccion. Los segmentos P solo permiten usar una senal de prediccion compensada por movimiento (MCP) por macrobloque. En los segmentos B, pueden codificarse macrobloques usando intra o inter-prediccion. Pueden usarse dos senales de MCP por prediccion. Los segmentos SP permiten conmutar segmentos P entre diferentes flujos de video de manera eficaz. Un segmento SI es una coincidencia exacta para un segmento SP para acceso aleatorio o recuperacion de error, mientras que solo se usa intra-prediccion.
La figura 2 muestra una vista general de un codificador de video al que se le puede aplicar la presente invencion. Los bloques mostrados en la figura representan modulos funcionales realizados por el procesador 101 que ejecuta el software 103 en la memoria 102. Se alimenta una imagen 200 de trama de video a un codificador 201 de video. El codificador de video trata la imagen 200 en unidades de macrobloques 200A. Cada macrobloque contiene varios pfxeles de imagen 200. En cada macrobloque se realiza una transformacion en coeficientes de transformacion seguida por una cuantificacion en niveles de coeficientes de transformacion. Ademas, se usa intra-prediccion o inter- prediccion, para no realizar las etapas de codificacion directamente en los datos de pixel sino en las diferencias de los mismos con respecto a valores de pixel predichos, logrando asf valores pequenos que se comprimen mas facilmente.
Para cada segmento, el codificador 201 genera varios elementos de sintaxis, que forman una version codificada de los macrobloques del segmento respectivo. Todos los elementos de datos residuales en los elementos de sintaxis, que estan relacionados con la codificacion de coeficientes de transformacion, tales como los niveles de coeficientes de transformacion o un mapa de significacion que indica niveles de coeficientes de transformacion omitidos, se denominan elementos de sintaxis de datos residuales. Ademas de estos elementos de sintaxis de datos residuales, los elementos de sintaxis generados por el codificador 201 contienen elementos de sintaxis de informacion de control que contienen informacion de control sobre como se ha codificado cada macrobloque y como tiene que descodificarse, respectivamente. En otras palabras, los elementos de sintaxis pueden dividirse en dos categonas. La primera categona, los elementos de sintaxis de informacion de control, contiene los elementos relacionados con un tipo de macrobloque, tipo de sub-macrobloque e informacion sobre modos de prediccion de tipos tanto espacial como temporal, asf como informacion de control basada en segmento y basada en macrobloque, por ejemplo. En la segunda categona, todos los elementos de datos residuales, tales como un mapa de significacion que indica las ubicaciones de todos los coeficientes significativos dentro de un bloque de coeficientes de transformacion cuantificados y los valores de los coeficientes significativos, que se indican en unidades de niveles correspondientes a las etapas de cuantificacion, se combinan y se convierten en elementos de sintaxis de datos residuales.
El codificador 201 comprende un codificador de entropfa que codifica elementos de sintaxis y genera contrasenas aritmeticas para cada segmento. Cuando se generan las contrasenas aritmeticas para un segmento, el codificador de entropfa aprovecha dependencias estadfsticas entre los valores de datos de elementos de sintaxis en el flujo de bits de la senal de video. El codificador 201 emite una senal de video codificada para un segmento de imagen 200 a un descodificador de video 301 mostrado en la figura 3.
La figura 3 muestra una vista general de un descodificador de video al que se le puede aplicar la presente invencion. Asimismo, los bloques mostrados en la figura representan modulos funcionales realizados por el procesador 101 que ejecuta el software 103 en la memoria 102. El descodificador de video 301 recibe la senal de video codificada y en primer lugar realiza la descodificacion de entropfa de la senal de vuelta a los elementos de sintaxis. El descodificador 301 usa los elementos de sintaxis para reconstruir, macrobloque por macrobloque y despues segmento por segmento, las muestras de imagen 300A de pfxeles en la imagen 300.
La figura 4 muestra los modulos funcionales del codificador de video 201. Estos modulos funcionales se realizan mediante el procesador 101 que ejecuta el software 103 en la memoria 102. Una imagen de video de entrada es una trama o un campo de una imagen de video natural (sin comprimir) definida por puntos de muestra que representan componentes de colores originales, tales como crominancia (“croma”) y luminancia (“luma”) (otras componentes son posibles, por ejemplo, tono, saturacion y valor). La imagen de video de entrada se divide en macrobloques 400 que representan cada uno un area de imagen cuadrada que consiste en 16x16 pfxeles de la componente luma del color de la imagen. La imagen de video de entrada tambien se reparte en macrobloques que representan cada uno 8x8 pfxeles de cada una de las dos componentes de croma del color de la imagen. En el funcionamiento de codificador general, los macrobloques introducidos pueden predecirse de manera temporal o espacial usando inter o intra- prediccion. Sin embargo, con el proposito de discusion, se supone que los macrobloques 400 son todos macrobloques de tipo segmento I y se someten unicamente a intra-prediccion.
5
10
15
20
25
30
35
40
45
50
55
60
65
La intra-prediccion se logra en un modulo de intra-prediccion 401, cuyo funcionamiento se analizara con detalle a continuacion. El modulo de intra-prediccion 401 genera un bloque de prediccion 402 a partir de pfxeles de lfmite horizontal y vertical de bloques adyacentes, que se han codificado, reconstruido y almacenado anteriormente en una memoria 403 de trama. Un residuo 404 del bloque de prediccion 402, que es la diferencia entre un bloque objetivo 400 y el bloque de prediccion 402, se transforma, ajusta a escala y cuantifica en un modulo de transformacion/cuantificacion 405, usando metodos y tecnicas conocidas por los expertos en el campo de la codificacion de video. Entonces se someten los coeficientes de transformacion cuantificados 406 a codificacion de entropfa en un modulo de codificacion de entropfa 407 y se transmiten (junto con otra informacion relacionada con la intra-prediccion) como una senal de video codificada 408.
El codificador de video 201 contiene funcionalidad de descodificacion para realizar la intra-prediccion en bloques objetivo. La funcionalidad de descodificacion comprende un modulo de cuantificacion/transformacion inverso 409, que realiza la cuantificacion inversa y la transformacion inversa en los coeficientes de transformacion cuantificados 406 para producir el residuo de prediccion descodificado 410, que se anade al bloque de prediccion 402. La suma del residuo 410 de prediccion descodificado y el bloque de prediccion 402 es un bloque reconstruido 411, que se almacena en la memoria de trama 403 y se leera de la misma y se usara por el modulo de intra-prediccion 401 para generar un bloque de prediccion 402 para descodificar un siguiente bloque objetivo 400.
La figura 5 es un diagrama de flujo que muestra procedimientos realizados por el modulo de intra-prediccion 401. Segun la norma H.264/AVC, la intra-prediccion implica predecir cada pixel del bloque objetivo 400 en una pluralidad de modos de prediccion, usando interpolaciones de pfxeles de lfmite (“pfxeles de referenda”) de bloques adyacentes anteriormente codificados y reconstruidos. Los modos de prediccion se identifican mediante numeros enteros positivos 0, 1, 2..., cada uno asociado con una instruccion o un algoritmo diferente para predecir pfxeles espedficos en el bloque objetivo 400. El modulo de intra-prediccion 401 ejecuta una intra-prediccion en los modos de prediccion respectivos y genera diferentes bloques de prediccion. En un algoritmo de busqueda completa (“FS”), cada uno de los bloques de prediccion generados se compara con el bloque objetivo 400 para encontrar el modo de prediccion optimo, lo cual minimiza el residuo de prediccion 404 o produce un residuo de prediccion 404 menor entre los modos de prediccion. La identificacion del modo de prediccion optimo se comprime y se envfa al descodificador 301 con otros elementos de sintaxis de informacion de control.
Cada modo de prediccion puede describirse por una direccion general de prediccion tal como se describe verbalmente (es decir, horizontal hacia arriba, vertical y diagonal hacia abajo y a la izquierda). Una direccion de prediccion puede describirse graficamente mediante una direccion angular que se expresa a traves de un diagrama con flechas tal como se muestra en la figura 7. En este tipo de diagrama, puede considerarse que cada flecha representa una direccion de prediccion o un modo de prediccion. El angulo correspondiente a un modo de prediccion tiene una relacion general con respecto a la direccion desde la ubicacion promedio ponderada de los pfxeles de referencia usados para predecir un pixel objetivo en la ubicacion de pixel objetivo. Observese que los modos de prediccion incluyen un modo de prediccion DC que no esta asociado con ninguna direccion de prediccion y, por tanto, no puede describirse graficamente en el diagrama al contrario que los demas modos de prediccion. En el modo de prediccion DC, el bloque de prediccion 402 se genera de tal manera que cada pixel en el bloque de prediccion 402 se establece uniformemente al valor medio de los pfxeles de referencia.
Volviendo a la figura 5, el modo de prediccion se inicia en la etapa 501. Entonces se determina, en la etapa 502, si el modo de prediccion indica la prediccion DC. Si es as( el flujo avanza a la etapa 503, en la que se genera un bloque de prediccion 402 DC con el valor medio de los pfxeles de referencia en la etapa 503. Si el modo de prediccion indica otra cosa, se genera un bloque de prediccion 402 segun la instruccion o el algoritmo asociado con el modo de prediccion en la etapa 504, cuyo procedimiento se analizara en detalle a continuacion. Tras la etapa 503 o 504, el flujo avanza a la etapa 505, en la que se determina si los bloques de prediccion se generan para todos los modos de prediccion. Si se ejecuta intra-prediccion en todos los modos de prediccion, el flujo avanza a la etapa 506. De lo contrario, el modo de prediccion se aumenta en la etapa 507 y el flujo vuelve a la etapa 502. En la etapa 506, se compara cada uno de los bloques de prediccion generados con el bloque objetivo 400 para determinar el modo de prediccion optimo, que minimiza el residuo de prediccion 404.
La figura 6 muestra los modulos funcionales del descodificador de video 301. Estos modulos funcionales se realizan mediante el procesador 101 que ejecuta el software 103 en la memoria 102. La senal de video codificada del codificador 201 se recibe en primer lugar por un descodificador 600 de entropfa y se somete a descodificacion de entropfa para obtener de nuevo coeficientes de transformacion cuantificados 601. Los coeficientes de transformacion cuantificados 601 se someten a cuantificacion inversa y se transforman mediante un modulo de cuantificacion/transformacion inverso 602 para generar un residuo de prediccion 603. Se notifica a un modulo de intra-prediccion 604 del modo de prediccion seleccionado por el codificador 201. Segun el modo de prediccion seleccionado, el modulo de intra-prediccion 604 realiza un procedimiento de intra-prediccion similar al realizado en las etapas 502, 503 y 504 de la figura 5 para generar un bloque de prediccion 605, usando pfxeles de lfmite de bloques adyacentes anteriormente reconstruidos y almacenados en una memoria de trama 606. El bloque de prediccion 605 se anade al residuo de prediccion 603 para reconstruir un bloque 607 de senal de video descodificada. El bloque reconstruido 607 se almacena en la memoria de trama 606 para su uso en la prediccion de
5
10
15
20
25
30
35
40
45
50
55
60
65
un bloque siguiente.
Se facilitara una descripcion detallada de la siguiente manera sobre el procedimiento de la etapa 504 realizado por los modulos de intra-prediccion 401 y 604 para generar un bloque de prediccion en uno de los modos de prediccion, excepto el modo de prediccion DC. H.264/AVC soporta prediccion intra_4x4, prediccion intra_8x8 y prediccion intra_16x16. La prediccion intra_4x4 se usa comunmente cuando hay un detalle significativo en la imagen. La prediccion intra_4x4 predice los dieciseis bloques de luma 4x4 dentro de un macrobloque de manera individual. La prediccion intra_4x4 se realiza en nueve modos de prediccion, incluyendo un modo de prediccion DC. Las direcciones de prediccion espacial a lo largo de las cuales se realiza la prediccion intra_4x4 se muestran en la figura
7. La prediccion intra_8x8 se realiza en nueve modos de prediccion, incluyendo un modo de prediccion DC. La prediccion intra_16x16 se realiza en cuatro modos de prediccion, incluyendo un modo de prediccion DC.
Estudios recientes muestran que un aumento en el numero de direcciones de prediccion o un aumento en el numero de modos de prediccion, contribuye generalmente a mejorar la eficacia de compresion en la codificacion de video. Veanse, por ejemplo, los documentos n.os JCT-VC A119 (“Angular Intra prediction”) y JCT-VC A124 (“Arbitrary Direction Intra”) presentados al Joint Collaborative Team on Video Coding (JCT-VC). Un aumento en el numero de direcciones de prediccion conduce a un aumento en el numero de intervalos angulares de direcciones de prediccion disponibles y, por tanto, a un aumento en el numero de candidatos de bloque de prediccion. El numero aumentado de candidatos de bloque de prediccion simplemente aumenta las posibilidades de tener un bloque de prediccion que sea casi el mismo que un bloque objetivo que va a codificarse. La figura 8 es un diagrama que muestra las direcciones de prediccion propuestas en el documento n.° JCT-VC A119. En la figura 8, los pfxeles de referencia consisten en diecisiete (l7) pfxeles horizontales y diecisiete (17) pfxeles verticales, en los que el pixel superior izquierdo es comun a los lfmites tanto horizontal como vertical. Por tanto, hay 33 direcciones de prediccion diferentes disponibles para generar pfxeles de prediccion en un bloque 8x8. JCT-VC A124 propone una intra-prediccion direccional arbitraria en la que el numero de direcciones de prediccion se ajusta segun el tamano de un bloque que va a predecirse.
La figura 9 es un diagrama de flujo que muestra el procedimiento, propuesto en el documento JCT-VC A119, de generar un bloque de prediccion a lo largo de una de las direcciones de prediccion mostradas en la figura 8. En la siguiente descripcion del procedimiento, algunos algoritmos se simplifican para facilitar la explicacion. Ademas, el procedimiento descrito se limita a la intra-prediccion a lo largo de una direccion de prediccion que es principalmente vertical. La intra-prediccion a lo largo de una direccion de prediccion que es principalmente horizontal, puede implementarse de manera simetrica al procedimiento mostrado en la figura 9, tal como se demuestra en el software proporcionado por el documento JCT-VC A119. Aunque la figura 8 muestra un bloque 8x8 que va a predecirse, el procedimiento mostrado en la figura 9 puede expandirse para aplicarse a diversos numeros de pfxeles en diferentes configuraciones. Por ejemplo, un bloque que va a predecirse puede comprender una matriz 4x4 de pfxeles. Un bloque de prediccion tambien puede comprender una matriz 8x8 de pfxeles, una matriz 16x16 de pfxeles o matrices mas grandes de pfxeles. Otras configuraciones de pfxeles, incluyendo matrices tanto cuadradas como rectangulares, tambien pueden constituir un bloque de prediccion.
En la etapa 900 en la figura 9, se leen pfxeles de referencia en lfmites horizontal y vertical, que se encuentran inmediatamente por encima y a la izquierda de un bloque objetivo, respectivamente, a partir de bloques adyacentes que se han codificado, reconstruido y almacenado anteriormente en una memoria de trama, tal como la memoria 403 mostrada en la figura 4. Los pfxeles del lfmite horizontal se almacenan en un area de memoria denominada “refH”. Los pfxeles del lfmite vertical se almacenan en otra area de memoria denominada “refV”. Volviendo a la figura
8, los pfxeles de referencia se identifican mediante sus coordenadas en un sistema de coordenadas que tiene el origen en la posicion de pixel superior izquierda en el bloque 8x8. Por tanto, los pfxeles de lfmite horizontal tienen coordenadas expresadas por p[x, y] con x = 0, 1...16 e y = 0. Los pfxeles de lfmite vertical tienen coordenadas expresadas por p[x, y] con x = 0, y = 0, -1, -2...-16.
Se supone que los pfxeles de lfmite horizontal almacenados en el area de memoria refH se identifican mediante una direccion logica (x) con x = 0, 1...16 y que los pfxeles de lfmite vertical almacenados en el area de memoria refV se identifican igualmente mediante una direccion logica (y) con y = 0, -1, -2...-16, donde cada pixel se almacena en la direccion que tiene el numero en la coordenada de la cual se lee. Por tanto, a medida que se representan graficamente los pfxeles horizontales y verticales en la figura 8, puede considerarse que las areas de memoria refH y refV se extienden de manera lineal y ortogonal entre sf y que tienen, cada una, una longitud de 2 x size + 1, donde “size” es un parametro que representa el tamano del bloque objetivo. Se supone que size tiene un valor igual a una potencia entera de 2, tal como 4, 8, 16... Opcionalmente puede aplicarse un filtro de paso bajo, tal como se describe en la seccion 8.3.2.2.1 en H.264/AVC, a los pfxeles en refH y refV.
En la etapa 901, se establece un contador denominado “row” a cero (“0”). El contador row adopta un valor de desde 0 hasta size e indica una posicion de fila de un pixel de prediccion en el bloque de prediccion. En la etapa 902, se calcula un parametro denominado “pos” mediante angle X (row+1). angle es un parametro que tiene un numero fraccionario en una representacion de puntos fijos. Como tal, angle esta formado por una parte entera y una parte fraccionaria, y la parte fraccionaria consiste en un numero fijado de dfgitos binarios. angle representa una de las direcciones de prediccion mostradas en la figura 8. Por ejemplo, “angle = -size" identifica la direccion de prediccion
5
10
15
20
25
30
35
40
45
50
55
60
65
que pasa a traves de las coordenadas [x = 0, y = 0] en la figura 8. Un angle que tiene un valor positivo identifica una direccion de prediccion que interseca unicamente el Ifmite horizontal, mientras que un angle que tiene un valor negativo identifica una direccion de prediccion que interseca los lfmites tanto horizontal como vertical. angle vana dentro de un intervalo determinado por el numero de direcciones de prediccion deseadas que van a usarse. Tal como se propone en el documento JCT-VC A124, el numero de direcciones de prediccion que van a usarse puede determinarse segun el tamano de un bloque que va a predecirse. En la siguiente descripcion, se supone que angle adopta un numero fraccionario que vana dentro de un intervalo desde “-size" hasta “size". Observese que los lfmites de intervalo de angle pueden definirse con otros valores.
Al igual que angle, el parametro pos consiste en una parte entera y una parte fraccionaria, y la parte fraccionaria del mismo consiste en un numero fijado de dfgitos binarios, que es igual al logaritmo en base 2 del lfmite de intervalo de angle, que puede expresarse mediante log2_size segun la suposicion anterior de que el lfmite de intervalo de angle se establece al size. pos identifica la posicion de una interseccion entre el lfmite horizontal y la direccion de prediccion representada por angle. Volviendo a la etapa 902, la operacion “pos >> log2_size" identifica un numero entero numero en pos, que se almacena en un parametro “int", y la operacion “pos & (size -1)” identifica un numero fraccionario en pos, que se almacena en un parametro “frac". El operador “>>” representa un desplazamiento aritmetico a la derecha de dfgitos binarios. El operador “&” representa la operacion “y” relacionada con los bits.
En la etapa 903, se determina si angle tiene un valor igual o superior a cero (“0”). Si angle tiene un valor igual o superior a cero, el flujo avanza a la etapa 904. De lo contrario, el flujo avanza a la etapa 913. angle igual o superior a cero sugiere que solo es posible basarse en los pfxeles de referencia ubicados en el lfmite horizontal o almacenados en refH, para derivar pfxeles de prediccion en un bloque de prediccion. Por otro lado, angle inferior a cero sugiere que se necesitan pfxeles de referencia ubicados en el lfmite vertical o almacenados en refV, para derivar pfxeles de prediccion en el bloque de prediccion.
En la etapa 904, se determina si frac es distinto de cero. Si frac es distinto de cero, el flujo avanza a la etapa 905. Si frac es cero, el flujo avanza a la etapa 906. frac igual a cero sugiere que puede copiarse un pixel de prediccion en el bloque de prediccion directamente de un pixel de referencia en el lfmite horizontal. frac distinto de cero sugiere que la direccion de prediccion interseca el lfmite horizontal en una posicion distinta de un numero entero, y se necesita una interpolacion de mas de un pixel de referencia para derivar un pixel de prediccion en el bloque de prediccion.
En la etapa 905, un contador denominado “cor se establece a cero (“0”). El contador col se usa para abordar un pixel de referencia en refH. En la etapa 907, se recuperan dos pfxeles de referencia identificados por “int + col + 1” e “int + col + 2” de refH. Se calcula el promedio ponderado de estos dos pfxeles de referencia o se interpolan con frac para derivar un pixel de prediccion v. Espedficamente, se multiplica un pixel de referencia en refH identificado por “int + col + 1” por “size - frac" y se almacena en un parametro a. Se multiplica un pixel de referencia en refH identificado por “int + col + 2” por “franc" y se almacena en un parametro b. Despues se suman los parametros a y b y se dividen entre size, es decir, (size - frac) + frac. La division entre size puede sustituirse por desplazamiento a la derecha mediante log2_size. El pixel de prediccion derivado v se almacena en una matriz de areas de memoria denominada “pred”, que representa un bloque de prediccion para el bloque objetivo en una direccion de prediccion particular. Cada area de memoria en pred se identifica mediante los parametros row y col. Despues, se aumenta col en 1 en la etapa 908 y se compara con size en la etapa 909. Siempre que col sea menor que size, se repiten las etapas 907 y 908. Cuando col se vuelve igual a size, el flujo avanza a la etapa 920.
Si se determina que frac es cero en la etapa 904, el contador col se establece a cero en la etapa 906. En la etapa 910, se copia el pixel de prediccion v directamente de refH (int + col + 1) y despues se almacena en el area de memoria correspondiente en pred. Entonces se aumenta col en 1 en la etapa 911 y se compara con size en la etapa 912. Siempre que col sea menor que size, se repiten las etapas 910 y 911. Cuando col se vuelve igual a size, el flujo avanza a la etapa 920.
Volviendo a la etapa 903, angle inferior a cero requiere pfxeles de referencia de refV para derivar pfxeles de prediccion en el bloque de prediccion. El contador col se establece a cero en la etapa 913. Entonces se determina, en la etapa 914, si “int + col + 1” es inferior a cero. “int + col + 1” igual o superior a cero sugiere que todavfa solo es posible basarse en los pfxeles de referencia almacenados en refH para derivar pfxeles de prediccion en el bloque de prediccion y el flujo avanza a la etapa 915. El procedimiento realizado en la etapa 915 es similar al de la etapa 907, y no se repetira la descripcion del mismo aqrn. Entonces se aumenta col en 1 en la etapa 916 y se compara con size en la etapa 917. Siempre que col sea menor que size, se repiten las etapas 914, 915 y 916. Cuando col se vuelve igual a size, el flujo avanza a la etapa 920.
Si se determina que “int + col + 1” es inferior a cero en la etapa 914, se necesitan pfxeles de referencia almacenados en refV para derivar pfxeles de prediccion en el bloque de prediccion. En la etapa 918, en primer lugar se determina la posicion de una interseccion entre el lfmite vertical y una direccion de prediccion. En la etapa 918, la posicion se representa mediante pos2. Observese que en la etapa 902, pos, es decir, la posicion de una interseccion entre el lfmite horizontal y una direccion de prediccion, se determina mediante “angle X (row + 1)”. Dado que angle representa una proporcion de diferencias horizontal y vertical, se calcula “angle'1 X (col + 1)”, en lugar de “angle x (row + 1)”, para determinar la posicion de una interseccion entre el lfmite vertical y una direccion de prediccion. Tal
5
10
15
20
25
30
35
40
45
50
55
como se supuso anteriormente, angle esta dentro del intervalo de -size a size (-size < angle < size). Por tanto, una proporcion a entre angle y size se define mediante:
Entonces, angle"1 se define mediante:
0 = £^(.1<a<i).
size
angle
size
----o
a
Como tal, pos2 se determina en la etapa 918 con el cuadrado de size multiplicado por col + 1 y despues dividido entre el valor absoluto de angle de la siguiente manera:
pos2 =
size2 x(co/ +1) \angle\
Al igual que pos, pos2 tiene un numero fraccionario en una representacion de puntos fijos que esta formado por una parte entera y una parte fraccionaria. La parte fraccionaria consiste en el numero de dfgitos binarios determinados por log2_size. La parte entera de pos2 se almacena en un parametro int2 y la parte fraccionaria de pos2 se almacena en un parametro frac2. En la etapa 919, se recuperan dos pfxeles de referencia identificados mediante “int2 + row + 1” e “int2 + row + 2” de refV. Se calcula el promedio ponderado de estos dos pfxeles de referencia o se interpolan con frac2 para derivar un pixel de prediccion v. Espedficamente, se multiplica un pixel de referencia de refV (int2 + row + 1) por “size - frac2" y se almacena en un parametro a. Se multiplica un pixel de referencia de refV (int2 + row + 2) por “frac2" y se almacena en un parametro b. Entonces se suman los parametros a y b y se dividen entre size o se desplazan a la derecha mediante log2_size. El pixel de prediccion derivado v se almacena en el area de memoria correspondiente de pred. Se repiten las etapas 914, 918, 919 y 916 hasta que col se vuelve igual a size en la etapa 917.
En la etapa 920, se aumenta row en 1. Entonces se determina, en la etapa 921, si row es menor que size. Siempre que row sea menor que size, se repiten las etapas desde la etapa 902 para derivar un pixel de prediccion en el bloque de prediccion. El flujo termina cuando row se vuelve igual a size en la etapa 921.
Tal como se ha mencionado anteriormente, un aumento en el numero de candidatos de bloque de prediccion contribuye a mejorar la eficacia de codificacion, mientras que un aumento en el numero de candidatos de bloque de prediccion conduce a un aumento en la carga de trabajo computacional. Por lo tanto, con el fin de aumentar el numero de candidatos de bloque de prediccion para asf mejorar la eficacia de codificacion, se necesita revisar el procedimiento de generacion de un candidato de bloque de prediccion para lograr mayor eficacia del procedimiento. Al revisar el procedimiento mostrado en la figura 9, pueden identificarse dos cuellos de botella computacionales. El primer cuello de botella computacional es la operacion de comparacion y ramificacion de la etapa 914, que se repite dentro del bucle. El segundo cuello de botella computacional es la operacion de division de la etapa 918, que tambien se repite dentro del bucle.
En la actualidad, se dispone de arquitecturas de una instruccion, multiples datos (SIMD) para un calculo eficaz. SIMD permite que ordenadores con multiples elementos de procesamiento realicen la misma operacion con multiples datos simultaneamente. Sin embargo, las arquitecturas SIMD tfpicas no soportan la implementacion de division y calculo/ramificacion en un bucle y, por lo tanto, no pueden usarse para implementar el procedimiento mostrado en la figura 9 debido a la inclusion de las etapas 914 y 918 en el bucle, aunque los bucles que comienzan en las etapas 907 y 910 son lo suficientemente robustos como para implementarse con SIMD. Por lo tanto, un objetivo de la presente invencion es eliminar los cuellos de botella computacionales del procedimiento mostrado en la figura 9 y proporcionar intra-prediccion de baja complejidad, que permite que arquitecturas SIMD tfpicas implementen procesamiento en paralelo a lo largo de todas las direcciones de prediccion mostradas en la figura 8.
La figura 10 es un diagrama de flujo que muestra el procedimiento de intra-prediccion de baja complejidad segun un modo de realizacion de la presente invencion, que esta disenado para sustituir al procedimiento de la figura 9 en la implementacion del procedimiento en la etapa 504 de la figura 5. En la figura 10, las mismas etapas de procedimiento que las realizadas en la figura 9 se identifican con los mismos numeros de etapa que los usados en la figura 9, tales como las etapas 900, 901, 902, 904, 905, 906, 907, 908, 909, 910, 911, 912, 920 y 921. La descripcion de estas etapas comunes no se repite aqrn. Las etapas 1000 y 1001 son etapas particulares del procedimiento de la figura 10. Tal como resulta evidente a partir de una comparacion con el procedimiento mostrado en la figura 9, el procedimiento de la figura 10 elimina la etapa de comparacion de la etapa 903 y todas las etapas que se ramifican hacia la izquierda desde la etapa 903, que se realizan cuando angle es inferior a cero, eliminando asf los cuellos de
5
10
15
20
25
30
35
40
45
50
55
botella computacionales de las etapas 914 y 918.
En las etapas 1000 y 1001 anadidas, se determina si angle es igual o superior a -1. Cuando angle es igual o superior a -1, los pfxeles de referencia ubicados en el lfmite horizontal son suficientes para generar un pixel de prediccion en el bloque de prediccion, y no se necesitan los pfxeles de referencia en el lfmite vertical. Por otro lado, cuando angle es inferior a -1, se necesitan pfxeles de referencia en el lfmite vertical para generar un pixel de prediccion en el bloque de prediccion. En la etapa 1001, se extienden pfxeles de referencia almacenados en refH en la direccion negativa, usando al menos algunos de los pfxeles almacenados en refV. Las figuras 11A y 11B son representaciones esquematicas que muestran la extension de refH realizada en la etapa 1001. En la figura 11A, los pfxeles de referencia 1102 almacenados en refH son del lfmite horizontal ubicado por encima del bloque objetivo 1101. Los pfxeles de referencia 1103 almacenados en refV son del lfmite vertical ubicado a la izquierda del bloque objetivo 1101. Tal como se muestra en la figura 11B, tras la etapa 1001 de la figura 10, algunos de los pfxeles de referencia en refV se copian en refH, y refH tiene una parte extendida 1104 que se extiende en la direccion negativa.
La figura 12 es un diagrama de flujo que muestra detalles del procedimiento realizado en la etapa 1001. En la etapa 1201, se establece un contador col a -1. Se usa col para identificar una direccion de la parte extendida de refH. En la etapa 1202, un pixel de referencia en refV que va a copiarse en la parte extendida de refH se identifica mediante:
size x col angle
La division en la ecuacion anterior es una division de numeros enteros y la ecuacion produce un numero entero. La ecuacion funciona de manera similar al procedimiento de la etapa 918 mostrada en la figura 9. En la etapa 918, se calcula un valor de numero entero de pos2 mediante:
Observese que el desplazamiento a la derecha mediante log2_size es equivalente a la division entre size.
En la etapa 1203, se reduce col en 1. Despues se determina, en la etapa 1204, si col es igual a angle. Si col no es igual a angle, el flujo vuelve a la etapa 1202. Se repiten las etapas 1202 y 1203 hasta que col se vuelve igual a angle. Por lo tanto, se leen pfxeles de referencia de refV en el orden ascendente, o desde la parte superior hasta la parte inferior del lfmite vertical, y se copian en refH tambien en el orden descendente, o desde la derecha hasta la izquierda del lfmite horizontal. Ademas, no todos los pfxeles de referencia en refV se copian en refH. Solo los pfxeles de referencia ubicados dentro del intervalo desde la parte superior hasta la interseccion de una direccion de prediccion se copian de refV en refH.
Volviendo a la figura 10, las etapas de procedimiento comenzando desde la etapa 902 se copian de la figura 9, e incluyen las etapas para generar pfxeles de prediccion ramificadas hacia la derecha desde la etapa de comparacion de la etapa 903 en la figura 9. Sin embargo, observese que las etapas en la figura 10 para generar pfxeles de prediccion usan refH extendido (una suma de las partes 1102 + 1104 en la figura 11B), mientras que las etapas correspondientes en la figura 9 usan refH original (parte 1102 en la figura 10A). Dado que refH se extiende en la direccion negativa, no se necesita una operacion de intra-prediccion separada disenada espedficamente para usar pfxeles de referencia almacenados en refV, tal como se ramifica hacia la izquierda desde la etapa 903 en la figura 9, independientemente del signo de angle.
La figura 13 es un diagrama de flujo que muestra otro modo de realizacion del procedimiento para extender refH, usando pfxeles de referencia en refV. El procedimiento mostrado en las figuras 11 y 12 elimina las etapas de cuello de botella de las etapas 914 y 918 mostradas en la figura 9 y, por lo tanto, se espera que mejore la eficacia del procedimiento de intra-prediccion. El procedimiento mostrado en la figura 13 elimina la operacion de division realizada en la etapa 1202 de la figura 12 del bucle para copiar pfxeles de referencia de refV en refH. Al eliminar la operacion de division del bucle, se espera que el procedimiento mostrado en la figura 13 mejore adicionalmente la eficacia del procedimiento de intra-prediccion.
El procedimiento mostrado en la figura 13 sustituye la etapa 1202 de la figura 12 por las etapas 1301 y 1302. La etapa 1302 esta dentro del bucle para copiar pfxeles de referencia de refV en refH, mientras que la etapa 1301 esta fuera del bucle. La etapa 1301 introduce un nuevo parametro denominado “InvAngle". InvAngle se define mediante:
5
10
15
20
25
30
35
40
45
50
55
60
La multiplicacion por 256 es equivalente a un desplazamiento a la izquierda mediante 8 y garantiza que cada bit resultante de la operacion de “size/angle" representa el calculo de identificar un p^xel de referencia en refV. En la etapa 1302, la direccion de un pixel de referencia en refV que va a copiarse en la parte extendida de refH se identifica mediante:
col x InvAngle » 8 .
El resultado de “col x InvAngle" se somete a desplazamiento a la derecha mediante 8 para deshacer la operacion de desplazamiento a la izquierda realizada en la etapa 1301. Observese que la operacion de desplazamiento a la derecha en la etapa 1302 funciona para redondear a la baja el resultado de “col x InvAngle". Para redondear al numero entero mas proximo, puede anadirse una compensacion de redondeo de 128 al resultado de “col x InvAngle" antes de realizar la operacion de desplazamiento a la derecha. Debe observarse que el numero “256” solo es un ejemplo, y la etapa 1301 puede adoptar otro numero de compensacion, preferiblemente una potencia entera de 2, siempre que el numero sea lo suficientemente grande como para conservar todos los bits resultantes de la operacion de “size/angle". Por ejemplo, el numero puede ser 64 en la etapa 1301, en lugar de 256, y el numero de desplazamientos a la derecha es 6 en la etapa 1302, en lugar de 8. Si se adopta 64, la compensacion de redondeo debe ser de 32.
El calculo realizado en la etapa 1301 puede sustituirse por una operacion de consulta para reducir adicionalmente la carga de trabajo computacional. En otras palabras, se prepara una tabla de consulta que almacena valores de InvAngle en relacion con los valores de angle. La tabla 1 proporcionada a continuacion es una tabla a modo de ejemplo para la consulta en la etapa 1301:
Tabla 1
- angle
- 4 5 6 7 8
- InvAngle
- 512 410 341 293 256
Se supone que, en la tabla anterior, size es 8, y angle adopta valores de numero entero de desde 4 hasta 8. Sin embargo, debe observarse que el tamano no se limita a 8 y puede adoptar otro valor, tal como 4 y 16. Ademas, angle puede ser un numero fraccionario en una representacion de puntos fijos tal como se ha definido anteriormente.
Cuando se copia un pixel de referencia de refV a refH en la etapa 1202 de la figura 12 o la etapa 1302 de la figura 13, el pixel de referencia puede pasar a traves de un filtro de paso bajo para reducir un posible solapamiento en el bloque de prediccion. La intensidad del filtro de paso bajo puede variar segun el valor de angle. Por ejemplo, cuando angle es igual a -size, puede aplicarse un filtrado de paso bajo debil y cuando angle es igual a -2, puede aplicarse un filtrado de paso bajo fuerte.
Tal como se ha explicado anteriormente, no todos los pfxeles de referencia en refV se copian en refH. Dado que no se copian todos los pfxeles de referencia en refV, se pierde algo de informacion cuando se copian los pfxeles. Para mitigar la perdida de informacion, puede duplicarse la resolucion de pfxeles de referencia en refH y refV de modo que refH y refV contienen no solo pfxeles de bloques anteriormente codificados y reconstruidos, sino tambien un pixel entre dos pfxeles reconstruidos adyacentes que se genera interpolando dos pfxeles adyacentes. Puede calcularse simplemente el promedio de dos pfxeles adyacentes para generar un pixel de interpolacion. El procedimiento de interpolacion puede realizarse cuando se leen pfxeles de referencia en la etapa 900 de la figura 9. Cuando se duplica la resolucion de pfxeles en refH y refV, se necesita ajustar a escala identificaciones de las direcciones de pfxeles de referencia almacenados en refH y refV, tal como se realiza en las etapas 907, 910, 915 y 919 en la figura 9, y la etapa 1001 en la figura 10. Por ejemplo, se necesita cambiar “int + col + 1” realizado en las etapas 907, 910 y 915 por “int + 2 x col + 2”. Se necesita cambiar “int + col + 2” realizado en las etapas 907, 910, 915 por “int + 2 x col + 3”. Se necesita cambiar “int2 + row + 1” e “int2 + row + 2” realizados en la etapa 919 por “int2 + 2 x row + 2” e “int2 + 2 x row + 3”, respectivamente.
En otro modo de realizacion, el procedimiento de la etapa 1202 en la figura 12 puede cambiarse simplemente por “refH [co/]wefV [-col]" para simplificar adicionalmente el procedimiento de copiado. Aunque se degrada la exactitud de prediccion, este modo de realizacion proporciona la menor complejidad a la operacion de intra-prediccion.
La figura 11B muestra la parte extendida 1104 anadida a refH. No se necesita que la parte extendida 1104 este formada con pfxeles de referencia de refV. La parte extendida 1104 puede formarse con pfxeles de un area de bloque anteriormente reconstruido, que corresponde espacialmente a la ubicacion de la parte extendida 1104. En la figura 11B, dado que se extiende en la direccion negativa, refH extendido (partes 1102 y 1104) oscila entre -size + 1 y 2xsize. El intervalo de refH extendido puede volver a ajustarse a escala para oscilar entre 0 y 3xsize -1 anadiendo una compensacion apropiada cuando se abordan pfxeles de referencia en refH extendido. Lo mismo es cierto para volver a ajustar a escala el intervalo de refV.
En otro modo de realizacion, el lfmite de intervalo de angle puede elegirse libremente. En los modos de realizacion
5
10
15
20
25
30
35
40
45
50
55
60
anteriores, se supone que angle adopta un valor dentro de un intervalo de desde -size hasta size (-size < angle < size). En otras palabras, en los modos de realizacion anteriores, los Kmites de intervalo de angle estan definidos con el tamano del bloque objetivo. Observese que los lfmites de intervalo de angle pueden definirse independientemente del tamano del bloque objetivo, aunque todavfa es preferible que el lfmite de intervalo se defina con una potencia entera de 2, de manera que log2_rangelimit sea un numero entero positivo y la ecuacion “rangelimit = 1 << log2_rangelimit" siga siendo cierta. Al elegir un numero grande adecuado para rangelimit, puede establecerse un gran numero de direcciones de prediccion y representarse mediante valores de angle a intervalos angulares lo suficientemente amplios.
Si el lfmite de intervalo de angle se define independientemente del tamano del bloque objetivo, se necesita sustituir size que aparece en las figuras 9 y 10 por rangelimit y se necesita sustituir log2_size por log2_rangelimit, excepto para las etapas 909, 912, 917 y 92l. Tambien se necesita sustituir la comparacion de “angle > -1” realizada en la etapa 1000 de la figura 10 por “angle x sizel/rangelimit> -1” o “angle x size > -rangelimit”. Ademas, se necesita sustituir size que aparece en las etapas 1202 y 1301 en las figuras 12 y 13 por rangelimit y se necesita sustituir la comparacion de col = angle?" realizada en la etapa 1204 por “^col = angle x size/rangelimit?”.
Si se introduce rangelimit como lfmite de intervalo de angle, la tabla 1 (proporcionada anteriormente) puede cambiarse de la siguiente forma:
Tabla 2
- angle*
- 13 17 21 26 32
- InvAngle
- 630 482 390 315 256
En la tabla 2, se establece rangelimit a 32. Angle* es igual a una aproximacion de numero entero de “rangelimit x tan (nl4 x angle/8)", donde angle = 4, 5, 6, 7 y 8. InvAngle es igual a 256 x rangelimit/angle*. Los valores en la tabla 2 son todos numeros enteros que se derivan mediante redondeo al alza. En lugar de redondearse al alza, los numeros pueden redondearse a la baja. En la tabla 3 proporcionada a continuacion, InvAngle es igual a 32 x rangelimitlangle*. Dado que se usa “32” en lugar de “256”, la exactitud de prediccion es necesariamente inferior a la de la tabla 2.
Tabla 3
- angle*
- 13 17 21 26 32
- InvAngle
- 78 60 48 39 32
La figura 14 es un diagrama de flujo que muestra otro modo de realizacion que simplifica adicionalmente el procedimiento mostrado en la figura 10. El procedimiento mostrado en la figura 10 de copiar pfxeles de referencia de refV en refH se realiza antes de que el flujo entre en el bucle de prediccion principal, mientras que el procedimiento de copiado mostrado en la figura 14 se realiza dentro del bucle de prediccion principal. Ademas, el procedimiento mostrado en la figura 14 elimina la variable InvAngle. Las etapas 900, 902 y 921 mostradas en la figura 14 son de las etapas correspondientes en la figura 10.
En la etapa 1401, se inicia un contador lastInt a -1. lastInt representa el mdice del ultimo pixel que se anadio a refH. En la etapa 902, se calcula pos mediante angle x (row + 1). Tal como se ha explicado anteriormente, pos identifica la posicion de una interseccion entre los lfmites y la direccion de prediccion representada por angle. En el contexto de la figura 9, la etapa 902 produce pos, que identifica la posicion de una interseccion entre el lfmite horizontal y la direccion de prediccion representada por angle. Ademas, en la etapa 902, una parte entera en pos se almacena en int y una parte fraccionaria en pos se almacena en un parametro “frac". En la etapa 1402, se determina si int es inferior a lastInt. Si int es inferior a lastInt, un pixel de referencia en refV identificado mediante row se copia en refH en una direccion identificada mediante “int + 1”. La etapa 1404 consiste en las etapas 904, 905, 906, 907, 908, 909, 910, 911 y 912 mostradas en las figuras 9 y 10, cuya descripcion no se repite aqrn. En la etapa 1405, int se copia en lastInt. La operacion de copiar int en lastInt puede realizarse en la etapa 1403, en lugar de la etapa 1405.
La operacion de copiado en la etapa 1403 da como resultado copiar el mismo pixel que se copio en las etapas 1202 y 1302, en las que se usa redondeo a la baja en esas etapas. La etapa 1403 puede modificarse para redondear al numero entero mas proximo usando de manera condicional “row + 1”, en lugar de “row”, en la etapa 1403 cuando la posicion fraccionaria frac calculada en la etapa 902 es mayor que offset, lo cual se identifica mediante rangelimit + (angle >> 1). Observese que angle es negativo y frac es positivo. El uso de “row + 1” da como resultado redondeo al alza. Para realizar el incremento condicional de row en 1, se cambia el procedimiento realizado en la etapa 1403 por refH[int +1] ^ refV[row - ((offset - frac) » 31)], suponiendo que en una aritmetica de 32 bits, el desplazamiento a la derecha de “offset - frac” da como resultado -1 cuando frac es mayor que offset y da como resultado 0 en caso contrario. Por lo tanto, el identificador de direccion “row - ((offset - frac) >> 31)” se convierte en “row + 1” cuando frac es mayor que offset y se convierte en “row” en caso contrario. Si se establece offset a rangelimit, “offset-frac" sera siempre positivo y, por lo tanto, no se producira ningun redondeo.
A continuacion se enumera el codigo fuente desarrollado en el lenguaje de programacion C++, que implementa el
5
10
15
20
25
30
35
40
45
50
55
60
65
procedimiento mostrado en la figura 14. El codigo fuente se modifica de la funcion TComPredictiopn::xPredIntraAng encontrada en el archivo TComPrediction.cpp que es parte del software TMuC 0.7 desarrollado por JCT-VC, que esta disponible en
http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7.
http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7.
// Funcion para derivar las intra-predicciones angulares simplificadas
Void TComPrediction::xPredIntraAng (Int* pSrc, Int iSrcStride, Pel*& rpDst, Int iDstStride, UInt iWidth, UInt iHeight, UInt uiDirMode, Bool bAbove, Bool bLeft) {
Int k, l;
Int deltaInt, deltaFract, refMainIndex;
Int intraPredAngle = 0;
Int absAng = 0;
Int signAng = 0;
Int blkSize = iWidth;
Bool modeDC = false;
Bool modeVer = false;
Bool modeHor = false;
Pel* pDst = rpDst;
// Mapear el mdice de modo a la direccion de prediccion principal y el angulo if (uiDirMode == 0) modeDC = true; else if (uiDirMode < 18) modeVer = true; else
modeHor = true;
intraPredAngle = modeVer ? uiDirMode - 9 : modeHor ? uiDirMode - 25 : 0; absAng = abs(intrapredAngle); signAng = intraPredAngle < 0 ? -1 : 1;
// Establecer desplazamientos de bits y ajustar a escala el parametro de angulo a size2 Int iAngTable[9] = { 0, 2, 5, 9, 13, 17, 21, 26, 32}; absAng = iAngTable[absAng]; intraPredAngle = signAng * absAng;
// Realizar la prediccion DC if (modeDC) {
Pel dcval = predIntraGetPredValDC(pSrc, iSrcStride, iWidth, iHeight, bAbove, bLeft); for (k=0;k<blkSize;k++) { for (1=0;1<blkSize;1++) {
5
10
15
20
25
30
35
40
45
50
55
60
65
pDst(k*iDstStride+1] = dcval;
}
}
}
// Realizar predicciones angulares else {
Pel tmp;
Int *pSrcTL = pSrc - iSrcStride -1;
Int iStepMain = (modeVer) ? 1 : iSrcStride; if (intraPredAngle == 0) { for (k=0;k<blkSize;k++) { for (1=0;1<blkSize;1++) { pDst [k*iDstStride+1] = pSrcTL[(1 + 1) * iStepMain];
}
}
}
else {
Int iStepSide = (modeVer) ? iSrcStride 1; int lastDeltaInt = -1;
Int Offset = 32 + (intraPredAngle >> 1); // permite redondear a la referencia lateral mas proxima // Int iOffset = 32; // sin redondeo.
Pel ref [2*MAX_CU_SIZE];
Pel* refMain = ref + ((intraPredAngle < 0) ? blkSize : 0); if (intraPredAngle > 0) { for (k = 0; k < 2*blkSize; k++) refMain[k] = pSrcTL[(k+1) * iStepMain];
}
else {
for (k = -1; k < blkSize; k++) // el resto se copia mas tarde en la etapa 1403, segun y cuando se requiera refMain[k] = pSrcTL[(k+1) * iStepMain];
}
for (k = 0; k < blkSize; k++) {
Int deltaPos = (k+1) * intraPredAngle;
5
10
15
20
25
30
35
40
45
50
55
60
65
deltaInt = deltaPos >> 5; deltaFract = deltaPos & (32 -1); if (deltaInt < lastDeltaInt) { // etapa 1402 lastDeltaInt = deltaInt;
refMain[deltaInt] = pSrcTL[(k-((iOffset-deltaFract)>>31))*iStepSide]; // etapa 1403
}
// etapa 1404 if (deltaFract) {
// Realizar filtrado lineal for (1=0;1<blkSize;1++) { refMainIndex = 1+deltaInt;
pDst[k*iDstStride+1] = (Pel) (((32-deltaFract) * refMain[refMainIndex] + deltaFract * refMain[refMainlndex+1] + 16) >> 5 );
}
}
else {
// Simplemente copiar las muestras de numeros enteros for (1=0;1<<blkSize;l++) { pDst[k*iDstStride+1] = refMain[1+deltaInt];
}
}
}
}
// Dar la vuelta al bloque si esto es el modo horizontal if (modeHor) { for (k=0;k<blkSize-1;k++) { for (1=k+1;1<blkSize;1++) { tmp = pDst[k*iDstStride+1]; pDst(k*iDstStride+1] = pDst(1*iDstStride+k]; pDst[1*iDstStride+k] = tmp;
}
}
}
}
Aunque sin duda se le ocurriran muchas alteraciones y modificaciones de la presente invencion a un experto habitual en la tecnica, tras haber ^do la descripcion anterior debe entenderse que no se pretende de ninguna 5 manera que ningun modo de realizacion particular mostrado y descrito a modo de ilustracion se considere limitativo. Por tanto, no se pretende que referencias a detalles de diversos modos de realizacion limiten el alcance de las reivindicaciones, que en sf mismas solo mencionan aquellas caractensticas que se consideran esenciales para la invencion.
Claims (6)
1.
5
10
15
20
25
30
2.
3. 35
4.
40 5.
45
50
55
60
REIVINDICACIONES
Metodo de codificacion de v^deo ejecutado por un procesador de un codificador de v^deo, que comprende:
una etapa de recuperar al menos algunos pfxeles de una matriz de pfxeles de Kmite vertical, siendo los pfxeles de Umite vertical pfxeles en un Kmite vertical que se encuentra inmediatamente a la izquierda de un bloque objetivo para codificar y en bloques verticalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente;
una etapa de anadir los p^xeles recuperados a una matriz de pfxeles de lfmite horizontal, siendo los p^xeles de lfmite p^xeles horizontales en un lfmite horizontal que se encuentra inmediatamente por encima del bloque objetivo para codificar y en bloques horizontalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente, para extender la matriz de pfxeles de lfmite horizontal; y
una etapa de realizar intra-prediccion basandose en la matriz extendida de pfxeles de lfmite horizontal,
en el que la etapa de recuperar al menos algunos pfxeles de la matriz de pfxeles de lfmite vertical incluye:
obtener InvAngle de una tabla de consulta que indica valores de InvAngle en relacion con valores de angle* que representan una direccion de prediccion; e
identificar los al menos algunos pfxeles entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales que se expresa mediante una funcion usando [col x InvAngle], donde col es un contador que se disminuye en 1 desde -1 hasta (size x angle*/rangelimit), donde size es un tamano de un bloque objetivo y rangelimit define el intervalo de angle*, y
en el que la etapa de anadir los pfxeles recuperados a la matriz de pfxeles de lfmite horizontal incluye: anadir un pixel identificado mediante el identificador de pfxeles verticales a los pfxeles de lfmite horizontal en una ubicacion identificada mediante un identificador de pfxeles horizontales [col].
Metodo de codificacion de video segun la reivindicacion 1, en el que rangelimit es una potencia entera de 2.
Metodo de codificacion de video segun la reivindicacion 1, en el que rangelimit es 32 y el (size x angle*/rangelimit) se implementa como size x angle* >>5.
Metodo de codificacion de video segun una de las reivindicaciones 1 a 3, en el que la magnitud de InvAngle se obtiene a partir de la siguiente tabla de consulta:
- angle*
- 13 17 21 26 32
- InvAngle
- 630 482 390 315 256
Metodo de descodificacion de video ejecutado por un procesador de un descodificador de video, que comprende:
una etapa de recuperar al menos algunos pfxeles de una matriz de pfxeles de lfmite vertical, siendo los pfxeles de lfmite vertical pfxeles en un lfmite vertical que se encuentra inmediatamente a la izquierda de un bloque objetivo para codificar y en bloques verticalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente;
una etapa de anadir los pfxeles recuperados a una matriz de pfxeles de lfmite horizontal, para extender la matriz de pfxeles de lfmite horizontal, siendo los pfxeles de lfmite pfxeles horizontales en un lfmite horizontal que se encuentra inmediatamente por encima del bloque objetivo para codificar y en bloques horizontalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente; y
una etapa de realizar intra-prediccion basandose en la matriz extendida de pfxeles de lfmite horizontal,
en el que la etapa de recuperar al menos algunos pfxeles de la matriz de pfxeles de lfmite vertical incluye:
obtener InvAngle de una tabla de consulta que indica valores de InvAngle en relacion con valores de angle* que representan una direccion de prediccion; e
identificar los al menos algunos pfxeles entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales que se expresa mediante una funcion usando [col x InvAngle], donde col es un contador que se disminuye en 1 desde -1 hasta (size x angle*/rangelimit), donde size es un tamano de un bloque objetivo y rangelimit define el intervalo de angle*, y
5 6.
7.
10
8.
15 9.
20
25
30
35
40 10.
45
50
55
60
en el que la etapa de anadir los pfxeles recuperados a la matriz de p^xeles de Kmite horizontal incluye: anadir un pixel identificado mediante el identificador de p^xeles verticales a los pfxeles de Kmite horizontal en una ubicacion identificada mediante un identificador de pfxeles horizontales [col].
Metodo de descodificacion de video segun la reivindicacion 5, en el que rangelimit es una potencia entera de 2.
Metodo de descodificacion de video segun la reivindicacion 5, en el que rangelimit es 32 y el (size x angle*/rangelimit) se implementa como size x angle* >> 5.
Metodo de descodificacion de video segun una de las reivindicaciones 5 a 7, en el que la magnitud de InvAngle se obtiene a partir de la siguiente tabla de consulta:
- angle*
- 13 17 21 26 32
- InvAngle
- 630 482 390 315 256
Codificador de video que comprende:
medios para recuperar al menos algunos pfxeles de una matriz de pfxeles de lfmite vertical, siendo los pfxeles de lfmite vertical pfxeles en un lfmite vertical que se encuentra inmediatamente a la izquierda de un bloque objetivo para codificar y en bloques verticalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente;
medios para anadir los pfxeles recuperados a una matriz de pfxeles de lfmite horizontal, para extender la matriz de pfxeles de lfmite horizontal, siendo los pfxeles de lfmite pfxeles horizontales en un lfmite horizontal que se encuentra inmediatamente por encima del bloque objetivo para codificar y en bloques horizontalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente; y
medios para realizar intra-prediccion basandose en la matriz extendida de pfxeles de lfmite horizontal,
en el que los medios para recuperar obtienen InvAngle de una tabla de consulta que indica valores de InvAngle en relacion con valores de angle* que representan una direccion de prediccion; e identifican los al menos algunos pfxeles entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales que se expresa mediante una funcion usando [col x InvAngle], donde col es un contador que se disminuye en 1 desde -1 hasta (size x angle*/rangelimit), donde size es un tamano de un bloque objetivo y rangelimit define el intervalo de angle*, y
en el que los medios para anadir anaden un pixel identificado mediante el identificador de pfxeles verticales a los pfxeles de lfmite horizontal en una ubicacion identificada mediante un identificador de pfxeles horizontales [col].
Descodificador de video que comprende:
medios para recuperar al menos algunos pfxeles de una matriz de pfxeles de lfmite vertical, siendo los pfxeles de lfmite vertical pfxeles en un lfmite vertical que se encuentra inmediatamente a la izquierda de un bloque objetivo para codificar y en bloques verticalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente;
medios para anadir los pfxeles recuperados a una matriz de pfxeles de lfmite horizontal, para extender la matriz de pfxeles de lfmite horizontal, siendo los pfxeles de lfmite pfxeles horizontales en un lfmite horizontal que se encuentra inmediatamente por encima del bloque objetivo para codificar y en bloques horizontalmente adyacentes que se han codificado, reconstruido y almacenado anteriormente; y
medios para realizar intra-prediccion basandose en la matriz extendida de pfxeles de lfmite horizontal,
en el que los medios para recuperar obtienen InvAngle de una tabla de consulta que indica valores de InvAngle en relacion con valores de angle* que representan una direccion de prediccion; e identifican los al menos algunos pfxeles entre los pfxeles de lfmite vertical, usando un identificador de pfxeles verticales que se expresa mediante una funcion usando [col x InvAngle], donde col es un contador que se disminuye en 1 desde -1 hasta (size x angle*/rangelimit), donde size es un tamano de un bloque objetivo y rangelimit define el intervalo de angle*, y
en el que los medios para anadir anaden un pixel identificado mediante el identificador de pfxeles verticales a los pfxeles de lfmite horizontal en una ubicacion identificada mediante un identificador de pfxeles horizontales [col].
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US36432210P | 2010-07-14 | 2010-07-14 | |
US364322P | 2010-07-14 | ||
US38854110P | 2010-09-30 | 2010-09-30 | |
US388541P | 2010-09-30 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2605530T3 true ES2605530T3 (es) | 2017-03-14 |
Family
ID=45469801
Family Applications (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES17170581T Active ES2748100T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES19183613T Active ES2873847T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES15169604.4T Active ES2605530T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES17170595T Active ES2729031T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES15169606.9T Active ES2637446T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES11807512.6T Active ES2621902T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES19163444T Active ES2864048T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES17170581T Active ES2748100T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES19183613T Active ES2873847T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
Family Applications After (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES17170595T Active ES2729031T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES15169606.9T Active ES2637446T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES11807512.6T Active ES2621902T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
ES19163444T Active ES2864048T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
Country Status (16)
Country | Link |
---|---|
US (6) | US9225986B2 (es) |
EP (7) | EP3522535B1 (es) |
JP (8) | JP5687341B2 (es) |
KR (7) | KR101924885B1 (es) |
CN (4) | CN105120264B (es) |
AU (1) | AU2011279139B2 (es) |
BR (1) | BR112013000963B1 (es) |
CA (7) | CA3014131C (es) |
ES (7) | ES2748100T3 (es) |
HU (2) | HUE054630T2 (es) |
MX (5) | MX2013000372A (es) |
PL (7) | PL3522535T3 (es) |
PT (7) | PT2594076T (es) |
RU (8) | RU2579947C2 (es) |
SG (1) | SG187065A1 (es) |
WO (1) | WO2012009540A1 (es) |
Families Citing this family (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101924885B1 (ko) | 2010-07-14 | 2018-12-04 | 가부시키가이샤 엔.티.티.도코모 | 비디오 코딩을 위한 저 복잡성 인트라 예측 |
KR101530284B1 (ko) | 2010-07-16 | 2015-06-19 | 삼성전자주식회사 | 영상의 인트라 예측 부호화, 복호화 방법 및 장치 |
US9008175B2 (en) | 2010-10-01 | 2015-04-14 | Qualcomm Incorporated | Intra smoothing filter for video coding |
KR20120140181A (ko) * | 2011-06-20 | 2012-12-28 | 한국전자통신연구원 | 화면내 예측 블록 경계 필터링을 이용한 부호화/복호화 방법 및 그 장치 |
US10645398B2 (en) | 2011-10-25 | 2020-05-05 | Texas Instruments Incorporated | Sample-based angular intra-prediction in video coding |
US8811760B2 (en) * | 2011-10-25 | 2014-08-19 | Mitsubishi Electric Research Laboratories, Inc. | Coding images using intra prediction modes |
WO2013070629A1 (en) * | 2011-11-07 | 2013-05-16 | Huawei Technologies Co., Ltd. | New angular table for improving intra prediction |
WO2013181821A1 (en) * | 2012-06-07 | 2013-12-12 | Mediatek Singapore Pte. Ltd. | Improved intra transform skip mode |
KR101307257B1 (ko) * | 2012-06-28 | 2013-09-12 | 숭실대학교산학협력단 | 영상의 인트라 예측 장치 |
TWI535222B (zh) * | 2012-06-29 | 2016-05-21 | Sony Corp | Image processing apparatus and method |
US9729875B2 (en) * | 2013-07-08 | 2017-08-08 | Sony Corporation | Palette coding mode |
US20150016516A1 (en) * | 2013-07-15 | 2015-01-15 | Samsung Electronics Co., Ltd. | Method for intra prediction improvements for oblique modes in video coding |
EP3058736B1 (en) | 2013-10-14 | 2019-02-27 | Microsoft Technology Licensing, LLC | Encoder-side options for intra block copy prediction mode for video and image coding |
RU2654129C2 (ru) | 2013-10-14 | 2018-05-16 | МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи | Функциональные возможности режима внутреннего предсказания с блочным копированием для кодирования и декодирования видео и изображений |
JP6336058B2 (ja) | 2013-10-14 | 2018-06-06 | マイクロソフト テクノロジー ライセンシング,エルエルシー | ビデオ及び画像符号化及び復号のためのベースカラーインデックスマップモードの機能 |
US10390034B2 (en) | 2014-01-03 | 2019-08-20 | Microsoft Technology Licensing, Llc | Innovations in block vector prediction and estimation of reconstructed sample values within an overlap area |
RU2669005C2 (ru) | 2014-01-03 | 2018-10-05 | МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи | Предсказание вектора блока в кодировании/декодировании видео и изображений |
US11284103B2 (en) | 2014-01-17 | 2022-03-22 | Microsoft Technology Licensing, Llc | Intra block copy prediction with asymmetric partitions and encoder-side search patterns, search ranges and approaches to partitioning |
US10542274B2 (en) | 2014-02-21 | 2020-01-21 | Microsoft Technology Licensing, Llc | Dictionary encoding and decoding of screen content |
CA2939431C (en) | 2014-03-04 | 2020-09-22 | Microsoft Techology Licensing, Llc | Block flipping and skip mode in intra block copy prediction |
KR102413529B1 (ko) | 2014-06-19 | 2022-06-24 | 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 | 통합된 인트라 블록 카피 및 인터 예측 모드 |
WO2016049839A1 (en) | 2014-09-30 | 2016-04-07 | Microsoft Technology Licensing, Llc | Rules for intra-picture prediction modes when wavefront parallel processing is enabled |
US9591325B2 (en) | 2015-01-27 | 2017-03-07 | Microsoft Technology Licensing, Llc | Special case handling for merged chroma blocks in intra block copy prediction mode |
JP6122516B2 (ja) | 2015-01-28 | 2017-04-26 | 財團法人工業技術研究院Industrial Technology Research Institute | エンコーディング方法及びエンコーダ |
JP6492847B2 (ja) * | 2015-03-24 | 2019-04-03 | 日本電気株式会社 | 映像符号化システム、映像符号化回路および映像符号化方法 |
US20180255304A1 (en) * | 2015-03-29 | 2018-09-06 | Lg Electronics Inc. | Method and device for encoding/decoding video signal |
CN106664405B (zh) | 2015-06-09 | 2020-06-09 | 微软技术许可有限责任公司 | 用调色板模式对经逸出编码的像素的稳健编码/解码 |
US10602138B2 (en) | 2015-08-27 | 2020-03-24 | Lg Electronics Inc. | Method and device for chroma sample intra prediction in video coding system |
CN106231340B (zh) * | 2016-09-23 | 2019-08-27 | 优酷网络技术(北京)有限公司 | 一种基于hevc的帧内预测解码方法及装置 |
CN116962687A (zh) * | 2016-11-29 | 2023-10-27 | 成均馆大学校产学协力团 | 影像编码/解码方法、装置以及对比特流进行存储的记录介质 |
EP3535972B1 (en) * | 2016-12-23 | 2020-11-18 | Huawei Technologies Co., Ltd. | An intra-prediction apparatus for extending a set of predetermined directional intra-prediction modes |
US10225578B2 (en) | 2017-05-09 | 2019-03-05 | Google Llc | Intra-prediction edge filtering |
US10992939B2 (en) | 2017-10-23 | 2021-04-27 | Google Llc | Directional intra-prediction coding |
CN118337990A (zh) * | 2017-06-26 | 2024-07-12 | 交互数字麦迪逊专利控股公司 | 利用多个加权参考进行帧内预测的方法和装置 |
JP2019041165A (ja) * | 2017-08-23 | 2019-03-14 | 富士通株式会社 | 画像符号化装置、画像復号装置、画像処理方法、及び画像処理プログラム |
WO2019059107A1 (ja) * | 2017-09-20 | 2019-03-28 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | 符号化装置、復号装置、符号化方法及び復号方法 |
CN109587491B (zh) * | 2017-09-28 | 2022-09-23 | 腾讯科技(深圳)有限公司 | 一种帧内预测方法、装置及存储介质 |
JP2021505336A (ja) | 2017-12-04 | 2021-02-18 | サイメディカ オーソペディックス インコーポレイテッド | 患者治療システム及び方法 |
WO2019124205A1 (ja) * | 2017-12-18 | 2019-06-27 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | 符号化装置、復号装置、符号化方法及び復号方法 |
US10986349B2 (en) | 2017-12-29 | 2021-04-20 | Microsoft Technology Licensing, Llc | Constraints on locations of reference blocks for intra block copy prediction |
WO2019185884A1 (en) * | 2018-03-29 | 2019-10-03 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Apparatus for selecting an intra-prediction mode for padding |
WO2021034231A2 (en) * | 2019-12-19 | 2021-02-25 | Huawei Technologies Co., Ltd. | Method and apparatus of position dependent prediction combination for oblique directional intra prediction |
EP4074048A4 (en) * | 2019-12-31 | 2023-03-08 | Huawei Technologies Co., Ltd. | METHOD AND DEVICE FOR INTRAPREDICTION |
CN116071242B (zh) * | 2023-03-17 | 2023-07-14 | 山东云海国创云计算装备产业创新中心有限公司 | 一种图像处理方法、***、设备以及存储介质 |
Family Cites Families (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6212663B1 (en) | 1997-10-23 | 2001-04-03 | Sony Corporation | Apparatus and method for recovery of quantization codes in a lossy transmission environment |
AU2003208086B2 (en) * | 2002-02-01 | 2007-11-15 | Godo Kaisha Ip Bridge 1 | Moving picture coding method and moving picture decoding method |
CN100574450C (zh) * | 2002-02-01 | 2009-12-23 | 松下电器产业株式会社 | 动画图象编码方法和动画图象编码装置 |
US7170937B2 (en) * | 2002-05-01 | 2007-01-30 | Texas Instruments Incorporated | Complexity-scalable intra-frame prediction technique |
US7539714B2 (en) * | 2003-06-30 | 2009-05-26 | Intel Corporation | Method, apparatus, and instruction for performing a sign operation that multiplies |
AU2004301091B2 (en) | 2003-08-19 | 2008-09-11 | Panasonic Corporation | Method for encoding moving image and method for decoding moving image |
EP1558039A1 (en) * | 2004-01-21 | 2005-07-27 | Deutsche Thomson-Brandt Gmbh | Method and apparatus for generating/evaluating prediction information in picture signal encoding/decoding |
KR101000926B1 (ko) * | 2004-03-11 | 2010-12-13 | 삼성전자주식회사 | 영상의 불연속성을 제거하기 위한 필터 및 필터링 방법 |
JP4542447B2 (ja) * | 2005-02-18 | 2010-09-15 | 株式会社日立製作所 | 画像の符号化/復号化装置、符号化/復号化プログラム及び符号化/復号化方法 |
KR101204788B1 (ko) * | 2004-06-03 | 2012-11-26 | 삼성전자주식회사 | 영상의 공간 예측 부호화 방법, 부호화 장치, 복호화 방법및 복호화 장치 |
CN1306824C (zh) * | 2004-07-29 | 2007-03-21 | 联合信源数字音视频技术(北京)有限公司 | 图像边界像素扩展***及其实现方法 |
US7778480B2 (en) * | 2004-11-23 | 2010-08-17 | Stmicroelectronics Asia Pacific Pte. Ltd. | Block filtering system for reducing artifacts and method |
KR100657919B1 (ko) * | 2004-12-13 | 2006-12-14 | 삼성전자주식회사 | 화상 데이터의 공간상 예측 장치 및 방법과 그를 이용한부호화 장치 및 방법, 화상 데이터의 공간상 예측 보상장치 및 방법과 그를 이용한 복호화 장치 및 방법 |
JP2007214641A (ja) | 2006-02-07 | 2007-08-23 | Seiko Epson Corp | 符号化装置、復号化装置、画像処理装置及び画像処理方法をコンピュータに実行させるためのプログラム |
US20070274398A1 (en) * | 2006-05-23 | 2007-11-29 | Metta Technology, Inc. | Parallelization of Video Decoding on Single-Instruction, Multiple-Data Processors |
JP2010505343A (ja) * | 2006-09-29 | 2010-02-18 | トムソン ライセンシング | 幾何学的なイントラ予測 |
US7991236B2 (en) * | 2006-10-16 | 2011-08-02 | Nokia Corporation | Discardable lower layer adaptations in scalable video coding |
WO2008140656A2 (en) * | 2007-04-03 | 2008-11-20 | Gary Demos | Flowfield motion compensation for video compression |
WO2009037828A1 (ja) * | 2007-09-21 | 2009-03-26 | Panasonic Corporation | 画像符号化装置および画像復号化装置 |
EP2046053A1 (en) * | 2007-10-05 | 2009-04-08 | Thomson Licensing | Method and device for adaptively quantizing parameters for image coding |
JP4948435B2 (ja) * | 2008-01-28 | 2012-06-06 | キヤノン株式会社 | 映像符号化装置及び映像符号化方法 |
KR20090095316A (ko) | 2008-03-05 | 2009-09-09 | 삼성전자주식회사 | 영상 인트라 예측 방법 및 장치 |
CN101247525B (zh) * | 2008-03-24 | 2010-06-02 | 北京邮电大学 | 一种提高图像帧内编码速率的方法 |
US8681875B2 (en) * | 2008-11-25 | 2014-03-25 | Stmicroelectronics Asia Pacific Pte., Ltd. | Apparatus and method for coding block boundary detection using interpolated autocorrelation |
JP5238523B2 (ja) * | 2009-01-13 | 2013-07-17 | 株式会社日立国際電気 | 動画像符号化装置、動画像復号化装置、および、動画像復号化方法 |
JP2010251953A (ja) * | 2009-04-14 | 2010-11-04 | Sony Corp | 画像符号化装置と画像符号化方法およびコンピュータ・プログラム |
KR101510108B1 (ko) * | 2009-08-17 | 2015-04-10 | 삼성전자주식회사 | 영상의 부호화 방법 및 장치, 그 복호화 방법 및 장치 |
KR101924885B1 (ko) | 2010-07-14 | 2018-12-04 | 가부시키가이샤 엔.티.티.도코모 | 비디오 코딩을 위한 저 복잡성 인트라 예측 |
HUE056673T2 (hu) | 2013-03-29 | 2022-02-28 | Jvckenwood Corp | Képdekódoló készülék, képdekódoló eljárás és képdekódoló program |
-
2011
- 2011-07-14 KR KR1020187018015A patent/KR101924885B1/ko active IP Right Grant
- 2011-07-14 CA CA3014131A patent/CA3014131C/en active Active
- 2011-07-14 PL PL19163444T patent/PL3522535T3/pl unknown
- 2011-07-14 RU RU2013106296/08A patent/RU2579947C2/ru active
- 2011-07-14 ES ES17170581T patent/ES2748100T3/es active Active
- 2011-07-14 PL PL17170595T patent/PL3232666T3/pl unknown
- 2011-07-14 CA CA3014042A patent/CA3014042C/en active Active
- 2011-07-14 RU RU2015141145A patent/RU2613725C1/ru active
- 2011-07-14 PL PL15169604T patent/PL2934008T3/pl unknown
- 2011-07-14 MX MX2013000372A patent/MX2013000372A/es active IP Right Grant
- 2011-07-14 ES ES19183613T patent/ES2873847T3/es active Active
- 2011-07-14 ES ES15169604.4T patent/ES2605530T3/es active Active
- 2011-07-14 MX MX2015002858A patent/MX344987B/es unknown
- 2011-07-14 ES ES17170595T patent/ES2729031T3/es active Active
- 2011-07-14 EP EP19163444.3A patent/EP3522535B1/en active Active
- 2011-07-14 EP EP15169606.9A patent/EP2934009B1/en active Active
- 2011-07-14 MX MX2018014741A patent/MX367865B/es unknown
- 2011-07-14 EP EP17170581.7A patent/EP3226560B1/en active Active
- 2011-07-14 HU HUE19183613A patent/HUE054630T2/hu unknown
- 2011-07-14 KR KR1020137000687A patent/KR101745928B1/ko active IP Right Grant
- 2011-07-14 CA CA3096445A patent/CA3096445C/en active Active
- 2011-07-14 KR KR1020167020283A patent/KR101811360B1/ko active IP Right Grant
- 2011-07-14 PT PT118075126T patent/PT2594076T/pt unknown
- 2011-07-14 PL PL15169606T patent/PL2934009T3/pl unknown
- 2011-07-14 EP EP17170595.7A patent/EP3232666B1/en active Active
- 2011-07-14 CN CN201510548062.0A patent/CN105120264B/zh active Active
- 2011-07-14 BR BR112013000963A patent/BR112013000963B1/pt active IP Right Grant
- 2011-07-14 EP EP19183613.9A patent/EP3570545B1/en active Active
- 2011-07-14 AU AU2011279139A patent/AU2011279139B2/en active Active
- 2011-07-14 SG SG2013002811A patent/SG187065A1/en unknown
- 2011-07-14 CN CN201510546896.8A patent/CN105120263B/zh active Active
- 2011-07-14 EP EP15169604.4A patent/EP2934008B1/en active Active
- 2011-07-14 PT PT151696069T patent/PT2934009T/pt unknown
- 2011-07-14 WO PCT/US2011/044014 patent/WO2012009540A1/en active Application Filing
- 2011-07-14 JP JP2013519828A patent/JP5687341B2/ja active Active
- 2011-07-14 US US13/809,511 patent/US9225986B2/en active Active
- 2011-07-14 MX MX2017000542A patent/MX361484B/es unknown
- 2011-07-14 KR KR1020177035940A patent/KR101878293B1/ko active IP Right Grant
- 2011-07-14 KR KR1020167020284A patent/KR101835460B1/ko active IP Right Grant
- 2011-07-14 CA CA3014052A patent/CA3014052C/en active Active
- 2011-07-14 EP EP11807512.6A patent/EP2594076B1/en active Active
- 2011-07-14 PT PT17170595T patent/PT3232666T/pt unknown
- 2011-07-14 ES ES15169606.9T patent/ES2637446T3/es active Active
- 2011-07-14 PT PT191634443T patent/PT3522535T/pt unknown
- 2011-07-14 PL PL11807512T patent/PL2594076T3/pl unknown
- 2011-07-14 PT PT151696044T patent/PT2934008T/pt unknown
- 2011-07-14 RU RU2015141279A patent/RU2613722C1/ru active
- 2011-07-14 ES ES11807512.6T patent/ES2621902T3/es active Active
- 2011-07-14 CN CN201180034682.2A patent/CN103004210B/zh active Active
- 2011-07-14 KR KR1020187005732A patent/KR101927281B1/ko active IP Right Grant
- 2011-07-14 PT PT171705817T patent/PT3226560T/pt unknown
- 2011-07-14 CN CN201510547113.8A patent/CN105227960B/zh active Active
- 2011-07-14 CA CA3098217A patent/CA3098217C/en active Active
- 2011-07-14 ES ES19163444T patent/ES2864048T3/es active Active
- 2011-07-14 PL PL17170581T patent/PL3226560T3/pl unknown
- 2011-07-14 PL PL19183613T patent/PL3570545T3/pl unknown
- 2011-07-14 CA CA2804762A patent/CA2804762C/en active Active
- 2011-07-14 HU HUE19163444A patent/HUE053802T2/hu unknown
- 2011-07-14 CA CA2934184A patent/CA2934184C/en active Active
- 2011-07-14 PT PT191836139T patent/PT3570545T/pt unknown
- 2011-07-14 KR KR1020187018014A patent/KR101927283B1/ko active IP Right Grant
-
2013
- 2013-01-10 MX MX2019010417A patent/MX2019010417A/es unknown
-
2014
- 2014-05-23 JP JP2014107274A patent/JP5808839B2/ja active Active
- 2014-11-13 JP JP2014231022A patent/JP6169554B2/ja active Active
-
2015
- 2015-09-30 US US14/871,274 patent/US9942565B2/en active Active
- 2015-09-30 US US14/871,144 patent/US10116960B2/en active Active
-
2016
- 2016-07-11 JP JP2016136703A patent/JP6321091B2/ja active Active
-
2017
- 2017-03-07 RU RU2017107462A patent/RU2658880C1/ru active
-
2018
- 2018-02-23 US US15/903,390 patent/US10397608B2/en active Active
- 2018-04-04 JP JP2018072261A patent/JP6484740B2/ja active Active
- 2018-04-04 JP JP2018072262A patent/JP6479237B2/ja active Active
- 2018-05-31 RU RU2018120140A patent/RU2687031C1/ru active
-
2019
- 2019-02-18 JP JP2019026729A patent/JP6663520B2/ja active Active
- 2019-04-23 RU RU2019112301A patent/RU2710946C1/ru active
- 2019-04-23 RU RU2019112302A patent/RU2710947C1/ru active
- 2019-04-23 RU RU2019112303A patent/RU2738786C2/ru active
- 2019-07-12 US US16/510,217 patent/US10841614B2/en active Active
- 2019-07-12 US US16/510,188 patent/US10841613B2/en active Active
-
2020
- 2020-02-14 JP JP2020023595A patent/JP6828199B2/ja active Active
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2605530T3 (es) | Intra-predicción de baja complejidad para codificación de vídeo | |
AU2015264787B2 (en) | Low-complexity intra prediction for video coding |