ES2621902T3 - 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
- ES2621902T3 ES2621902T3 ES11807512.6T ES11807512T ES2621902T3 ES 2621902 T3 ES2621902 T3 ES 2621902T3 ES 11807512 T ES11807512 T ES 11807512T ES 2621902 T3 ES2621902 T3 ES 2621902T3
- Authority
- ES
- Spain
- Prior art keywords
- pixels
- pixel
- prediction
- refh
- memory area
- 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 68
- 239000011159 matrix material Substances 0.000 claims abstract description 46
- 230000007423 decrease Effects 0.000 claims description 5
- 230000003247 decreasing effect Effects 0.000 claims 2
- 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
- 240000007124 Brassica oleracea Species 0.000 description 3
- 235000003899 Brassica oleracea var acephala Nutrition 0.000 description 3
- 235000011301 Brassica oleracea var capitata Nutrition 0.000 description 3
- 235000001169 Brassica oleracea var oleracea Nutrition 0.000 description 3
- 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
- 238000003491 array Methods 0.000 description 2
- 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
- 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
- 238000013139 quantization Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000002441 reversible effect Effects 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 que comprende etapas ejecutables por ordenador ejecutado por un procesador de un codificador de vídeo para implementar: recuperar al menos algunos píxeles, según una dirección de predicción de intra-predicción en un bloque objetivo que va a predecirse, desde una primera área de memoria (refV) en la que está almacenada una matriz de píxeles de límite vertical, en el que los píxeles de límite vertical están ubicados directamente a la izquierda del bloque objetivo; añadir los píxeles recuperados a una matriz de píxeles de límite horizontal ubicados directamente por encima del bloque objetivo, en el que los píxeles recuperados se añaden directamente al extremo izquierdo de la matriz de píxeles de límite horizontal para formar una secuencia consecutiva de los píxeles de límite horizontal; almacenar los píxeles añadidos en una segunda área de memoria (refH) en la que está almacenada la matriz de píxeles de límite horizontal, para extender la matriz almacenada en la segunda área de memoria (refH) del mismo; y realizar intra-predicción del bloque objetivo usando sólo los píxeles de límite horizontal incluyendo los píxeles añadidos de la matriz extendida almacenada en la segunda área de memoria (refH) como píxeles de referencia.
Description
Intra-predicción de baja complejidad para codificación de vídeo
1. Texto sobre el campo técnico
La presente invención se refiere a la codificación de vídeo y en particular a la predicción intra-trama en la que se predice un bloque de muestra, usando píxeles anteriormente codificados y reconstruidos de la misma trama de vídeo.
15 El vídeo digital requiere una gran cantidad de datos para representar todas y cada una de las tramas de una secuencia de vídeo digital (por ejemplo, serie de tramas) de una manera sin comprimir. Para la mayoría de las aplicaciones no resulta viable transmitir vídeo digital sin comprimir a través de redes informáticas debido a limitaciones del ancho de banda. Además, el vídeo digital sin comprimir requiere una gran cantidad de espacio de almacenamiento. El vídeo digital se codifica normalmente de alguna manera para reducir los requisitos de almacenamiento y reducir los requisitos de ancho de banda.
Una técnica para codificar vídeo digital es la predicción inter-trama, o inter-predicción. La inter-predicción aprovecha redundancias temporales entre diferentes tramas. Las tramas de vídeo temporalmente adyacentes incluyen normalmente bloques de píxeles, que permanecen sustancialmente iguales. Durante el procedimiento de
25 codificación, un vector de movimiento interrelaciona el movimiento de un bloque de píxeles en una trama con un bloque de píxeles similares en otra trama. Por consiguiente, no se requiere que el sistema codifique el bloque de píxeles dos veces, sino que en vez de eso codifica el bloque de píxeles una vez y proporciona un vector de movimiento para predecir el otro bloque de píxeles.
Otra técnica para codificar vídeo digital es la predicción intra-trama o intra-predicción. La intra-predicción codifica una trama o una parte de la misma sin referencia a píxeles en otras tramas. La intra-predicción aprovecha redundancias espaciales entre bloques de píxeles dentro de una trama. Dado que bloques de píxeles espacialmente adyacentes tienen generalmente atributos similares, la eficacia del procedimiento de codificación se mejora haciendo referencia a la correlación espacial entre bloques adyacentes. Esta correlación puede aprovecharse mediante
35 predicción de un bloque objetivo basándose en modos de predicción usados en bloques adyacentes.
La presente invención proporciona un procedimiento de intra-predicción único que mejora la eficacia de codificación de vídeo. H.264/AVC usa píxeles de referencia en un límite horizontal ubicado inmediatamente por encima de un bloque objetivo que va a predecirse y píxeles de referencia en un límite vertical ubicado inmediatamente a la izquierda del bloque objetivo. En la presente invención, se recupera al menos parte de o bien una matriz de píxeles de límite horizontal o bien una matriz de píxeles de límite vertical. Después, se añaden los píxeles recuperados a los otros píxeles de límite para extender la matriz de los mismos, se realiza intra-predicción, basándose únicamente en
45 la matriz extendida de píxeles de límite. En un modo de realización de la presente invención, se recuperan al menos algunos de los píxeles de límite vertical y se añaden a los píxeles de límite horizontal para extender la matriz de los mismos.
La presente invención elimina el procedimiento de decisión de seleccionar o bien el límite horizontal o bien el límite vertical del que se recuperan píxeles de referencia. La presente invención también elimina el procedimiento recurrente de calcular una posición del límite vertical que interseca una dirección de predicción, en el que el procedimiento de cálculo recurrente incluye normalmente una operación de división. La eliminación de estos procedimientos permite implementar el procedimiento de intra-predicción en arquitecturas de una instrucción, múltiples datos (SIMD), mejorando así la eficacia computacional de la codificación de vídeo.
55 En un modo de realización según la presente invención, se recuperan al menos algunos de los píxeles entre los píxeles de límite vertical, usando un identificador de píxeles verticales que se expresa mediante
donde size representa un tamaño de un bloque objetivo que va a predecirse, angle representa una dirección de predicción y col es un contador que se disminuye en 1 desde -1 hasta el ángulo. Los píxeles recuperados se añaden a los píxeles horizontales en una ubicación identificada mediante un identificador de píxeles horizontales [col].
En otro modo de realización, al recuperar al menos algunos de los píxeles de límite vertical, se calcula InvAngle a partir de
5
donde N es una potencia entera de 2. Después, se recuperan al menos algunos de los píxeles entre los píxeles de límite vertical, usando un identificador de píxeles verticales que se expresa mediante [col x InvAngle >> log2 N]. Los píxeles recuperados se añaden a los píxeles horizontales en una ubicación identificada mediante un identificador de
10 píxeles horizontales [col].
En otro modo de realización, InvAngle se obtiene de una tabla de consulta que indica valores de InvAngle en relación con los valores de angle.
15 En otro modo de realización, se identifica un píxel entre los píxeles de límite vertical, usando un identificador de píxeles verticales [row], donde row es un contador que se aumenta en 1 desde 0 hasta size. El píxel recuperado se añade a los píxeles de límite horizontal en una ubicación identificada mediante un identificador de píxeles horizontales [int+1], donde int es una representación en número entero de una posición de un píxel que interseca una dirección de predicción.
20 La presente invención también proporcionan un codificador y un descodificador que implementan una operación de intra-predicción en la que se recupera al menos parte de o bien una matriz de píxeles de límite horizontal o bien una matriz de píxeles de límite vertical. Después, se añaden los píxeles recuperados a los otros píxeles de límite para extender la matriz de los mismos. Se realiza intra-predicción, basándose únicamente en la matriz extendida de
25 píxeles de límite.
La figura 1 es un diagrama de bloques que muestra una arquitectura de hardware a modo de ejemplo en la que 30 puede implementarse la presente invención.
La figura 2 es un diagrama de bloques que muestra una vista general de un codificador de vídeo al que se le puede aplicar la presente invención.
35 La figura 3 es un diagrama de bloques que muestra una vista general de un descodificador de vídeo al que se le puede aplicar la presente invención.
La figura 4 es un diagrama de bloques que muestra los módulos funcionales de un codificador según un modo de realización de la presente invención.
40 La figura 5 es un diagrama de flujo que muestra un procedimiento de intra-predicción realizado por un módulo de intra-predicción del modo de realización de la presente invención.
La figura 6 es un diagrama de bloques que muestra los módulos funcionales de un descodificador según un modo de 45 realización de la presente invención.
La figura 7 es un diagrama que muestra direcciones de predicción que ilustran modos de predicción intra_4x4 soportados en H.264/AVC.
50 La figura 8 es un diagrama que muestra las direcciones de predicción 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 generación de un bloque predicho a lo largo de una de las direcciones de predicción mostradas en la figura 7.
55 La figura 10 es un diagrama de flujo que muestra el procedimiento de intra-predicción de baja complejidad realizado según un modo de realización de la presente invención.
La figura 11A es una vista esquemática que muestra un bloque de predicción y matrices de píxeles de límite horizontal y vertical.
60 La figura 11B es una vista esquemática que muestra una matriz de píxeles de límite horizontal extendida con píxeles de límite vertical.
La figura 12 es un diagrama de flujo que muestra el procedimiento de extender una matriz de píxeles de límite horizontal realizado según un modo de realización de la presente invención.
La figura 13 es un diagrama de flujo que muestra otro modo de realización de extender una matriz de píxeles de 5 límite horizontal.
La figura 14 un diagrama de flujo que muestra el procedimiento de intra-predicción de baja complejidad realizado según otro modo de realización de la presente invención.
La figura 1 muestra una arquitectura de hardware a modo de ejemplo de un ordenador 100 en el que puede implementarse la presente invención. Obsérvese que la arquitectura de hardware mostrada en la figura 1 puede ser común tanto en un codificador de vídeo como en un descodificador de vídeo que implementan los modos de 15 realización de la presente invención. El ordenador 100 incluye un procesador 101, memoria 102, dispositivo de almacenamiento 105 y uno o más dispositivos de entrada y/o salida (I/O) 106 (o periféricos) que están acoplados en comunicación a través de una interfaz local 107. La interfaz local 105 puede ser, por ejemplo, pero sin limitación, uno
o más buses u otras conexiones por cable o inalámbricas, tal como se conoce en la técnica.
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.
25 La memoria 102 comprende un medio legible por ordenador que puede incluir uno cualquiera o una combinación de elementos de memoria volátil (por ejemplo, memoria de acceso aleatorio (RAM, tal como DRAM, SRAM, SDRAM, etc.)) y elementos de memoria no volátil (por ejemplo, ROM, disco duro, cinta, CD-ROM, etc.). Además, la memoria 102 puede incorporar medios de almacenamiento electrónicos, magnéticos, ópticos 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 conexión con el sistema, aparato o dispositivo de ejecución de instrucciones. Obsérvese que la memoria 102 puede tener una arquitectura distribuida, en la que diversos componentes están situados alejados unos de otros, pero a los que puede acceder el procesador 101.
35 El software 103 en la memoria 102 puede incluir uno o más programas separados, cada uno de los cuales contiene una lista ordenada de instrucciones ejecutables para implementar funciones lógicas del ordenador 100, tal como se describe a continuación. En el ejemplo de la figura 1, el software 103 en la memoria 102 define la funcionalidad de codificación de vídeo o descodificación de vídeo del ordenador 100 según la presente invención. Además, aunque no se requiere, es posible que la memoria 102 contenga un sistema operativo (O/S) 104. El sistema operativo 104 controla esencialmente la ejecución de programas informáticos y proporciona planificación, control de entrada-salida, gestión de archivos y datos, gestión de memoria y control de comunicación 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
45 portátil. Como ejemplo, el dispositivo de almacenamiento 105 puede ser una cinta magnética, disco, memoria flash, memoria volátil o un dispositivo de almacenamiento diferente. Además, el dispositivo de almacenamiento 105 puede ser una tarjeta de memoria digital segura o cualquier otro dispositivo de almacenamiento extraíble 105.
Los dispositivos de I/O 106 pueden incluir dispositivos de entrada, por ejemplo, pero sin limitación, una pantalla táctil, un teclado, ratón, escáner, micrófono u otro dispositivo de entrada. Además, los dispositivos de I/O 106 también pueden incluir dispositivos de salida, por ejemplo, pero sin limitación, una pantalla u otros dispositivos de salida. Los dispositivos de I/O 106 pueden incluir además dispositivos que se comunican a través tanto de entradas como de salidas, por ejemplo, pero sin limitación, un modulador/desmodulador (módem; para acceder a otro dispositivo, sistema o red), un transceptor de radiofrecuencia (RF), inalámbrico u otro, una interfaz telefónica, un
55 puente, un enrutador u otros dispositivos que funcionan como entrada y como salida.
Tal como conocen bien los expertos habituales en la técnica, la compresión de vídeo se logra eliminando información redundante en una secuencia de vídeo. Existen muchas normas diferentes de codificación de vídeo, ejemplos de las cuales incluyen MPEG-1, MPEG-2, MPEG-4, H.261, H.263 y H.264/AVC. Debe observarse que no se pretende limitar la presente invención en cuanto a la aplicación de cualquier norma de codificación de vídeo específica. Sin embargo, la siguiente descripción de la presente invención se proporciona usando el ejemplo de la norma H.264/AVC. H.264/AVC es la norma de codificación de vídeo más reciente y logra una mejora de rendimiento significativa con respecto a las normas de codificación anteriores tales como MPEG-1, MPEG-2, H.261 y H.263.
65 En H.264/AVC, cada trama o imagen de un vídeo puede descomponerse en varios segmentos. Los segmentos se dividen entonces en bloques de 16x16 píxeles denominados macrobloques, que después pueden dividirse adicionalmente en bloques de 8x16, 16x8, 8x8, 4x8, 8x4, hasta 4x4 píxeles. Hay cinco tipos de segmentos soportados por H.264/AVC. En los segmentos I, todos los macrobloques se codifican usando intra-predicción. En los segmentos P, los macrobloques pueden codificarse usando intra o inter-predicción. Los segmentos P sólo permiten usar una señal de predicción compensada por movimiento (MCP) por macrobloque. En los segmentos B, pueden
5 codificarse macrobloques usando intra o inter-predicción. Pueden usarse dos señales de MCP por predicción. Los segmentos SP permiten conmutar segmentos P entre diferentes flujos de vídeo de manera eficaz. Un segmento SI es una coincidencia exacta para un segmento SP para acceso aleatorio o recuperación de error, mientras que sólo se usa intra-predicción.
La figura 2 muestra una vista general de un codificador de vídeo al que se le puede aplicar la presente invención. Los bloques mostrados en la figura representan módulos funcionales realizados por el procesador 101 que ejecuta el software 103 en la memoria 102. Se alimenta una imagen 200 de trama de vídeo a un codificador 201 de vídeo. El codificador de vídeo trata la imagen 200 en unidades de macrobloques 200A. Cada macrobloque contiene varios píxeles de imagen 200. En cada macrobloque se realiza una transformación en coeficientes de transformación
15 seguida por una cuantificación en niveles de coeficientes de transformación. Además, se usa intra-predicción o interpredicción, para no realizar las etapas de codificación directamente en los datos de píxel sino en las diferencias de los mismos con respecto a valores de píxel predichos, logrando así valores pequeños que se comprimen más fácilmente.
Para cada segmento, el codificador 201 genera varios elementos de sintaxis, que forman una versión codificada de los macrobloques del segmento respectivo. Todos los elementos de datos residuales en los elementos de sintaxis, que están relacionados con la codificación de coeficientes de transformación, tales como los niveles de coeficientes de transformación o un mapa de significación que indica niveles de coeficientes de transformación omitidos, se denominan elementos de sintaxis de datos residuales. Además de estos elementos de sintaxis de datos residuales,
25 los elementos de sintaxis generados por el codificador 201 contienen elementos de sintaxis de información de control que contienen información de control sobre cómo se ha codificado cada macrobloque y cómo tiene que descodificarse, respectivamente. En otras palabras, los elementos de sintaxis pueden dividirse en dos categorías. La primera categoría, los elementos de sintaxis de información de control, contiene los elementos relacionados con un tipo de macrobloque, tipo de sub-macrobloque e información sobre modos de predicción de tipos tanto espacial como temporal, así como información de control basada en segmento y basada en macrobloque, por ejemplo. En la segunda categoría, todos los elementos de datos residuales, tales como un mapa de significación que indica las ubicaciones de todos los coeficientes significativos dentro de un bloque de coeficientes de transformación cuantificados y los valores de los coeficientes significativos, que se indican en unidades de niveles correspondientes a las etapas de cuantificación, se combinan y se convierten en elementos de sintaxis de datos residuales.
35 El codificador 201 comprende un codificador de entropía que codifica elementos de sintaxis y genera contraseñas aritméticas para cada segmento. Cuando se generan las contraseñas aritméticas para un segmento, el codificador de entropía aprovecha dependencias estadísticas entre los valores de datos de elementos de sintaxis en el flujo de bits de la señal de vídeo. El codificador 201 emite una señal de vídeo codificada para un segmento de imagen 200 a un descodificador de vídeo 301 mostrado en la figura 3.
La figura 3 muestra una vista general de un descodificador de vídeo al que se le puede aplicar la presente invención. Asimismo, los bloques mostrados en la figura representan módulos funcionales realizados por el procesador 101 que ejecuta el software 103 en la memoria 102. El descodificador de vídeo 301 recibe la señal de vídeo codificada y en
45 primer lugar realiza la descodificación de entropía de la señal de vuelta a los elementos de sintaxis. El descodificador 301 usa los elementos de sintaxis para reconstruir, macrobloque por macrobloque y después segmento por segmento, las muestras de imagen 300A de píxeles en la imagen 300.
La figura 4 muestra los módulos funcionales del codificador de vídeo 201. Estos módulos funcionales se realizan mediante el procesador 101 que ejecuta el software 103 en la memoria 102. Una imagen de vídeo de entrada es una trama o un campo de una imagen de vídeo 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, saturación y valor). La imagen de vídeo de entrada se divide en macrobloques 400 que representan cada uno un área de imagen cuadrada que consiste en 16x16 píxeles de la componente luma del color
55 de la imagen. La imagen de vídeo de entrada también se reparte en macrobloques que representan cada uno 8x8 píxeles 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 intrapredicción. Sin embargo, con el propósito de discusión, se supone que los macrobloques 400 son todos macrobloques de tipo segmento I y se someten únicamente a intra-predicción.
La intra-predicción se logra en un módulo de intra-predicción 401, cuyo funcionamiento se analizará con detalle a continuación. El módulo de intra-predicción 401 genera un bloque de predicción 402 a partir de píxeles de límite 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 predicción 402, que es la diferencia entre un bloque objetivo 65 400 y el bloque de predicción 402, se transforma, ajusta a escala y cuantifica en un módulo de transformación/cuantificación 405, usando métodos y técnicas conocidas por los expertos en el campo de la
codificación de vídeo. Entonces se someten los coeficientes de transformación cuantificados 406 a codificación de entropía en un módulo de codificación de entropía 407 y se transmiten (junto con otra información relacionada con la intra-predicción) como una señal de vídeo codificada 408.
5 El codificador de vídeo 201 contiene funcionalidad de descodificación para realizar la intra-predicción en bloques objetivo. La funcionalidad de descodificación comprende un módulo de cuantificación/transformación inverso 409, que realiza la cuantificación inversa y la transformación inversa en los coeficientes de transformación cuantificados 406 para producir el residuo de predicción descodificado 410, que se añade al bloque de predicción 402. La suma del residuo 410 de predicción descodificado y el bloque de predicción 402 es un bloque reconstruido 411, que se almacena en la memoria de trama 403 y se leerá de la misma y se usará por el módulo de intra-predicción 401 para generar un bloque de predicción 402 para descodificar un siguiente bloque objetivo 400.
La figura 5 es un diagrama de flujo que muestra procedimientos realizados por el módulo de intra-predicción 401. Según la norma H.264/AVC, la intra-predicción implica predecir cada píxel del bloque objetivo 400 en una pluralidad
15 de modos de predicción, usando interpolaciones de píxeles de límite (“píxeles de referencia”) de bloques adyacentes anteriormente codificados y reconstruidos. Los modos de predicción se identifican mediante números enteros positivos 0, 1, 2..., cada uno asociado con una instrucción o un algoritmo diferente para predecir píxeles específicos en el bloque objetivo 400. El módulo de intra-predicción 401 ejecuta una intra-predicción en los modos de predicción respectivos y genera diferentes bloques de predicción. En un algoritmo de búsqueda completa (“FS”), cada uno de los bloques de predicción generados se compara con el bloque objetivo 400 para encontrar el modo de predicción óptimo, lo cual minimiza el residuo de predicción 404 o produce un residuo de predicción 404 menor entre los modos de predicción. La identificación del modo de predicción óptimo se comprime y se envía al descodificador 301 con otros elementos de sintaxis de información de control.
25 Cada modo de predicción puede describirse por una dirección general de predicción tal como se describe verbalmente (es decir, horizontal hacia arriba, vertical y diagonal hacia abajo y a la izquierda). Una dirección de predicción puede describirse gráficamente mediante una dirección angular que se expresa a través 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 dirección de predicción o un modo de predicción. El ángulo correspondiente a un modo de predicción tiene una relación general con respecto a la dirección desde la ubicación promedio ponderada de los píxeles de referencia usados para predecir un píxel objetivo en la ubicación de píxel objetivo. Obsérvese que los modos de predicción incluyen un modo de predicción DC que no está asociado con ninguna dirección de predicción y, por tanto, no puede describirse gráficamente en el diagrama al contrario que los demás modos de predicción. En el modo de predicción DC, el bloque de predicción 402 se genera de tal manera que cada píxel en el bloque de
35 predicción 402 se establece uniformemente al valor medio de los píxeles de referencia.
Volviendo a la figura 5, el modo de predicción se inicia en la etapa 501. Entonces se determina, en la etapa 502, si el modo de predicción indica la predicción DC. Si es así, el flujo avanza a la etapa 503, en la que se genera un bloque de predicción 402 DC con el valor medio de los píxeles de referencia en la etapa 503. Si el modo de predicción indica otra cosa, se genera un bloque de predicción 402 según la instrucción o el algoritmo asociado con el modo de predicción en la etapa 504, cuyo procedimiento se analizará en detalle a continuación. Tras la etapa 503 o 504, el flujo avanza a la etapa 505, en la que se determina si los bloques de predicción se generan para todos los modos de predicción. Si se ejecuta intra-predicción en todos los modos de predicción, el flujo avanza a la etapa 506. De lo contrario, el modo de predicción se aumenta en la etapa 507 y el flujo vuelve a la etapa 502. En la etapa 506, se
45 compara cada uno de los bloques de predicción generados con el bloque objetivo 400 para determinar el modo de predicción óptimo, que minimiza el residuo de predicción 404.
La figura 6 muestra los módulos funcionales del descodificador de vídeo 301. Estos módulos funcionales se realizan mediante el procesador 101 que ejecuta el software 103 en la memoria 102. La señal de vídeo codificada del codificador 201 se recibe en primer lugar por un descodificador 600 de entropía y se somete a descodificación de entropía para obtener de nuevo coeficientes de transformación cuantificados 601. Los coeficientes de transformación cuantificados 601 se someten a cuantificación inversa y se transforman mediante un módulo de cuantificación/transformación inverso 602 para generar un residuo de predicción 603. Se notifica a un módulo de intra-predicción 604 del modo de predicción seleccionado por el codificador 201. Según el modo de predicción
55 seleccionado, el módulo de intra-predicción 604 realiza un procedimiento de intra-predicción similar al realizado en las etapas 502, 503 y 504 de la figura 5 para generar un bloque de predicción 605, usando píxeles de límite de bloques adyacentes anteriormente reconstruidos y almacenados en una memoria de trama 606. El bloque de predicción 605 se añade al residuo de predicción 603 para reconstruir un bloque 607 de señal de vídeo descodificada. El bloque reconstruido 607 se almacena en la memoria de trama 606 para su uso en la predicción de un bloque siguiente.
Se facilitará una descripción detallada de la siguiente manera sobre el procedimiento de la etapa 504 realizado por los módulos de intra-predicción 401 y 604 para generar un bloque de predicción en uno de los modos de predicción, excepto el modo de predicción DC. H.264/AVC soporta predicción intra_4x4, predicción intra_8x8 y predicción 65 intra_16x16. La predicción intra_4x4 se usa comúnmente cuando hay un detalle significativo en la imagen. La predicción intra_4x4 predice los dieciséis bloques de luma 4x4 dentro de un macrobloque de manera individual. La
predicción intra_4x4 se realiza en nueve modos de predicción, incluyendo un modo de predicción DC. Las direcciones de predicción espacial a lo largo de las cuales se realiza la predicción intra_4x4 se muestran en la figura
7. La predicción intra_8x8 se realiza en nueve modos de predicción, incluyendo un modo de predicción DC. La predicción intra_16x16 se realiza en cuatro modos de predicción, incluyendo un modo de predicción DC.
5 Estudios recientes muestran que un aumento en el número de direcciones de predicción o un aumento en el número de modos de predicción, contribuye generalmente a mejorar la eficacia de compresión en la codificación de vídeo. Véanse, 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 número de direcciones de predicción conduce a un aumento en el número de intervalos angulares de direcciones de predicción disponibles y, por tanto, a un aumento en el número de candidatos de bloque de predicción. El número aumentado de candidatos de bloque de predicción simplemente aumenta las posibilidades de tener un bloque de predicción que sea casi el mismo que un bloque objetivo que va a codificarse. La figura 8 es un diagrama que muestra las direcciones de predicción propuestas en el documento n.º JCT-VC A119. En la figura 8, los píxeles de referencia
15 consisten en diecisiete (17) píxeles horizontales y diecisiete (17) píxeles verticales, en los que el píxel superior izquierdo es común a los límites tanto horizontal como vertical. Por tanto, hay 33 direcciones de predicción diferentes disponibles para generar píxeles de predicción en un bloque 8x8. JCT-VC A124 propone una intra-predicción direccional arbitraria en la que el número de direcciones de predicción se ajusta según el tamaño 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 predicción a lo largo de una de las direcciones de predicción mostradas en la figura 8. En la siguiente descripción del procedimiento, algunos algoritmos se simplifican para facilitar la explicación. Además, el procedimiento descrito se limita a la intra-predicción a lo largo de una dirección de predicción que es principalmente
25 vertical. La intra-predicción a lo largo de una dirección de predicción que es principalmente horizontal, puede implementarse de manera simétrica 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 números de píxeles en diferentes configuraciones. Por ejemplo, un bloque que va a predecirse puede comprender una matriz 4x4 de píxeles. Un bloque de predicción también puede comprender una matriz 8x8 de píxeles, una matriz 16x16 de píxeles o matrices más grandes de píxeles. Otras configuraciones de píxeles, incluyendo matrices tanto cuadradas como rectangulares, también pueden constituir un bloque de predicción.
En la etapa 900 en la figura 9, se leen píxeles de referencia en límites horizontal y vertical, que se encuentran
35 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 píxeles del límite horizontal se almacenan en un área de memoria denominada “refH”. Los píxeles del límite vertical se almacenan en otra área de memoria denominada “refV”. Volviendo a la figura 8, los píxeles de referencia se identifican mediante sus coordenadas en un sistema de coordenadas que tiene el origen en la posición de píxel superior izquierda en el bloque 8x8. Por tanto, los píxeles de límite horizontal tienen coordenadas expresadas por p[x, y] con x = 0, 1...16 e y = 0. Los píxeles de límite vertical tienen coordenadas expresadas por p[x, y] con x = 0, y = 0, -1, -2...-16.
Se supone que los píxeles de límite horizontal almacenados en el área de memoria refH se identifican mediante una
45 dirección lógica (x) con x = 0, 1...16 y que los píxeles de límite vertical almacenados en el área de memoria refV se identifican igualmente mediante una dirección lógica (y) con y = 0, -1, -2...-16, donde cada píxel se almacena en la dirección que tiene el número en la coordenada de la cual se lee. Por tanto, a medida que se representan gráficamente los píxeles horizontales y verticales en la figura 8, puede considerarse que las áreas de memoria refH y refV se extienden de manera lineal y ortogonal entre sí y que tienen, cada una, una longitud de 2 x size + 1, donde “size” es un parámetro que representa el tamaño 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 sección 8.3.2.2.1 en H.264/AVC, a los píxeles 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
55 0 hasta size e indica una posición de fila de un píxel de predicción en el bloque de predicción. En la etapa 902, se calcula un parámetro denominado “pos” mediante angle X(row+1). angle es un parámetro que tiene un número fraccionario en una representación de puntos fijos. Como tal, angle está formado por una parte entera y una parte fraccionaria, y la parte fraccionaria consiste en un número fijado de dígitos binarios. angle representa una de las direcciones de predicción mostradas en la figura 8. Por ejemplo, “angle = -size” identifica la dirección de predicción que pasa a través de las coordenadas [x = 0, y = 0] en la figura 8. Un angle que tiene un valor positivo identifica una dirección de predicción que interseca únicamente el límite horizontal, mientras que un angle que tiene un valor negativo identifica una dirección de predicción que interseca los límites tanto horizontal como vertical. angle varía dentro de un intervalo determinado por el número de direcciones de predicción deseadas que van a usarse. Tal como se propone en el documento JCT-VC A124, el número de direcciones de predicción que van a usarse puede
65 determinarse según el tamaño de un bloque que va a predecirse. En la siguiente descripción, se supone que angle adopta un número fraccionario que varía dentro de un intervalo desde “-size” hasta “size”. Obsérvese que los límites
de intervalo de angle pueden definirse con otros valores.
Al igual que angle, el parámetro pos consiste en una parte entera y una parte fraccionaria, y la parte fraccionaria del mismo consiste en un número fijado de dígitos binarios, que es igual al logaritmo en base 2 del límite de intervalo de 5 angle, que puede expresarse mediante log2_size según la suposición anterior de que el límite de intervalo de angle se establece al size. pos identifica la posición de una intersección entre el límite horizontal y la dirección de predicción representada por angle. Volviendo a la etapa 902, la operación “pos >> log2_size” identifica un número entero número en pos, que se almacena en un parámetro “int”, y la operación “pos & (size -1)” identifica un número fraccionario en pos, que se almacena en un parámetro “frac”. El operador “>>” representa un desplazamiento
10 aritmético a la derecha de dígitos binarios. El operador “&” representa la operación “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 sólo es posible basarse en los píxeles de referencia ubicados en el límite horizontal o almacenados
15 en refH, para derivar píxeles de predicción en un bloque de predicción. Por otro lado, angle inferior a cero sugiere que se necesitan píxeles de referencia ubicados en el límite vertical o almacenados en refV, para derivar píxeles de predicción en el bloque de predicción.
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
20 frac es cero, el flujo avanza a la etapa 906. frac igual a cero sugiere que puede copiarse un píxel de predicción en el bloque de predicción directamente de un píxel de referencia en el límite horizontal. frac distinto de cero sugiere que la dirección de predicción interseca el límite horizontal en una posición distinta de un número entero, y se necesita una interpolación de más de un píxel de referencia para derivar un píxel de predicción en el bloque de predicción.
25 En la etapa 905, un contador denominado “col” se establece a cero (“0”). El contador col se usa para abordar un píxel de referencia en refH. En la etapa 907, se recuperan dos píxeles de referencia identificados por “int + col + 1” e “int + col + 2” de refH. Se calcula el promedio ponderado de estos dos píxeles de referencia o se interpolan con frac para derivar un píxel de predicción v. Específicamente, se multiplica un píxel de referencia en refH identificado por “int + col + 1” por “size -frac” y se almacena en un parámetro a. Se multiplica un píxel de referencia en refH
30 identificado por “int + col + 2” por “franc” y se almacena en un parámetro b. Después se suman los parámetros a y b y se dividen entre size, es decir, (size -frac) + frac. La división entre size puede sustituirse por desplazamiento a la derecha mediante log2_size. El píxel de predicción derivado v se almacena en una matriz de áreas de memoria denominada “pred”, que representa un bloque de predicción para el bloque objetivo en una dirección de predicción particular. Cada área de memoria en pred se identifica mediante los parámetros row y col. Después, se aumenta col
35 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 píxel de predicción v directamente de refH (int + col + 1) y después se almacena en el área de 40 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 píxeles de referencia de refV para derivar píxeles de
45 predicción en el bloque de predicción. 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 todavía sólo es posible basarse en los píxeles de referencia almacenados en refH para derivar píxeles de predicción en el bloque de predicción 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 repetirá la descripción del mismo aquí. Entonces se aumenta col en 1 en la etapa 916 y se compara con size
50 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 píxeles de referencia almacenados en refV para derivar píxeles de predicción en el bloque de predicción. En la etapa 918, en primer lugar se determina 55 la posición de una intersección entre el límite vertical y una dirección de predicción. En la etapa 918, la posición se representa mediante pos2. Obsérvese que en la etapa 902, pos, es decir, la posición de una intersección entre el límite horizontal y una dirección de predicción, se determina mediante “angle X(row + 1)”. Dado que angle representa una proporción de diferencias horizontal y vertical, se calcula “angle-1 X (col + 1)”, en lugar de “angle x (row + 1)”, para determinar la posición de una intersección entre el límite vertical y una dirección de predicción. Tal
60 como se supuso anteriormente, angle está dentro del intervalo de -size a size (-size ≤ angle ≤ size). Por tanto, una proporción entre angle y size se define mediante:
Entonces, angle-1 se define mediante:
Como tal, pos2 se determina en la etapa 918 con el cuadrado de size multiplicado por col + 1 y después dividido entre el valor absoluto de angle de la siguiente manera:
10 Al igual que pos, pos2 tiene un número fraccionario en una representación de puntos fijos que está formado por una parte entera y una parte fraccionaria. La parte fraccionaria consiste en el número de dígitos binarios determinados por log2_size. La parte entera de pos2 se almacena en un parámetro int2 y la parte fraccionaria de pos2 se almacena en un parámetro frac2. En la etapa 919, se recuperan dos píxeles de referencia identificados mediante “int2 + row + 1” e“int2 + row + 2” de refV. Se calcula el promedio ponderado de estos dos píxeles de referencia o se
15 interpolan con frac2 para derivar un píxel de predicción . Específicamente, se multiplica un píxel de referencia de refV (int2 + row + 1) por “size -frac2” y se almacena en un parámetro a. Se multiplica un píxel de referencia de refV (int2 + row + 2) por “frac2” y se almacena en un parámetro b. Entonces se suman los parámetros a y b y se dividen entre size o se desplazan a la derecha mediante log2_size. El píxel de predicción derivado se almacena en el área de memoria correspondiente de pred. Se repiten las etapas 914, 918, 919 y 916 hasta que col se vuelve igual a size
20 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 píxel de predicción en el bloque de predicción. El flujo termina cuando row se vuelve igual a size en la etapa 921.
25 Tal como se ha mencionado anteriormente, un aumento en el número de candidatos de bloque de predicción contribuye a mejorar la eficacia de codificación, mientras que un aumento en el número de candidatos de bloque de predicción conduce a un aumento en la carga de trabajo computacional. Por lo tanto, con el fin de aumentar el número de candidatos de bloque de predicción para así mejorar la eficacia de codificación, se necesita revisar el
30 procedimiento de generación de un candidato de bloque de predicción 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 operación de comparación y ramificación de la etapa 914, que se repite dentro del bucle. El segundo cuello de botella computacional es la operación de división de la etapa 918, que también se repite dentro del bucle.
35 En la actualidad, se dispone de arquitecturas de una instrucción, múltiples datos (SIMD) para un cálculo eficaz. SIMD permite que ordenadores con múltiples elementos de procesamiento realicen la misma operación con múltiples datos simultáneamente. Sin embargo, las arquitecturas SIMD típicas no soportan la implementación de división y cálculo/ramificación en un bucle y, por lo tanto, no pueden usarse para implementar el procedimiento
40 mostrado en la figura 9 debido a la inclusión 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 invención es eliminar los cuellos de botella computacionales del procedimiento mostrado en la figura 9 y proporcionar intra-predicción de baja complejidad, que permite que arquitecturas SIMD típicas implementen procesamiento en paralelo a lo largo de todas las direcciones de predicción mostradas en la figura 8.
45 La figura 10 es un diagrama de flujo que muestra el procedimiento de intra-predicción de baja complejidad según un modo de realización de la presente invención, que está diseñado para sustituir al procedimiento de la figura 9 en la implementación 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 números de etapa que los usados en la
50 figura 9, tales como las etapas 900, 901, 902, 904, 905, 906, 907, 908, 909, 910, 911, 912, 920 y 921. La descripción de estas etapas comunes no se repite aquí. Las etapas 1000 y 1001 son etapas particulares del procedimiento de la figura 10. Tal como resulta evidente a partir de una comparación con el procedimiento mostrado en la figura 9, el procedimiento de la figura 10 elimina la etapa de comparación 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 así los cuellos de
55 botella computacionales de las etapas 914 y 918.
En las etapas 1000 y 1001 añadidas, se determina si angle es igual o superior a -1. Cuando angle es igual o superior a -1, los píxeles de referencia ubicados en el límite horizontal son suficientes para generar un píxel de predicción en el bloque de predicción, y no se necesitan los píxeles de referencia en el límite vertical. Por otro lado, cuando angle
60 es inferior a -1, se necesitan píxeles de referencia en el límite vertical para generar un píxel de predicción en el bloque de predicción. En la etapa 1001, se extienden píxeles de referencia almacenados en refH en la dirección
negativa, usando al menos algunos de los píxeles almacenados en refV. Las figuras 11A y 11B son representaciones esquemáticas que muestran la extensión de refH realizada en la etapa 1001. En la figura 11A, los píxeles de referencia 1102 almacenados en refH son del límite horizontal ubicado por encima del bloque objetivo 1101. Los píxeles de referencia 1103 almacenados en refV son del límite vertical ubicado a la izquierda del bloque 5 objetivo 1101. Tal como se muestra en la figura 11B, tras la etapa 1001 de la figura 10, algunos de los píxeles de referencia en refV se copian en refH, y refH tiene una parte extendida 1104 que se extiende en la dirección 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 dirección de la parte extendida de refH. En la 10 etapa 1202, un píxel de referencia en refV que va a copiarse en la parte extendida de refH se identifica mediante:
La división en la ecuación anterior es una división de números enteros y la ecuación produce un número entero. La 15 ecuación funciona de manera similar al procedimiento de la etapa 918 mostrada en la figura 9. En la etapa 918, se calcula un valor de número entero de pos2 mediante:
20 Obsérvese que el desplazamiento a la derecha mediante log2_size es equivalente a la división entre size.
En la etapa 1203, se reduce col en 1. Después 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 píxeles de referencia de refV en el orden ascendente, o desde la parte superior hasta la
25 parte inferior del límite vertical, y se copian en refH también en el orden descendente, o desde la derecha hasta la izquierda del límite horizontal. Además, no todos los píxeles de referencia en refV se copian en refH. Sólo los píxeles de referencia ubicados dentro del intervalo desde la parte superior hasta la intersección de una dirección de predicción se copian de refV en refH.
30 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 píxeles de predicción ramificadas hacia la derecha desde la etapa de comparación de la etapa 903 en la figura 9. Sin embargo, obsérvese que las etapas en la figura 10 para generar píxeles de predicción 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
35 dirección negativa, no se necesita una operación de intra-predicción separada diseñada específicamente para usar píxeles 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 realización del procedimiento para extender refH,
40 usando píxeles 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-predicción. El procedimiento mostrado en la figura 13 elimina la operación de división realizada en la etapa 1202 de la figura 12 del bucle para copiar píxeles de referencia de refV en refH. Al eliminar la operación de división del bucle, se espera que el procedimiento mostrado en la figura 13 mejore adicionalmente la
45 eficacia del procedimiento de intra-predicción.
El procedimiento mostrado en la figura 13 sustituye la etapa 1202 de la figura 12 por las etapas 1301 y 1302. La etapa 1302 está dentro del bucle para copiar píxeles de referencia de refV en refH, mientras que la etapa 1301 está fuera del bucle. La etapa 1301 introduce un nuevo parámetro denominado “InvAngle”. InvAngle se define mediante:
50
La multiplicación por 256 es equivalente a un desplazamiento a la izquierda mediante 8 y garantiza que cada bit resultante de la operación de “size/angle” representa el cálculo de identificar un píxel de referencia en refV. En la 55 etapa 1302, la dirección de un píxel de referencia en refV que va a copiarse en la parte extendida de refH se identifica mediante:
5
15
25
35
45
55
El resultado de “col x InvAngle” se somete a desplazamiento a la derecha mediante 8 para deshacer la operación de desplazamiento a la izquierda realizada en la etapa 1301. Obsérvese que la operación de desplazamiento a la derecha en la etapa 1302 funciona para redondear a la baja el resultado de “col x InvAngle”. Para redondear al número entero más próximo, puede añadirse una compensación de redondeo de 128 al resultado de “col x InvAngle” antes de realizar la operación de desplazamiento a la derecha. Debe observarse que el número “256” sólo es un ejemplo, y la etapa 1301 puede adoptar otro número de compensación, preferiblemente una potencia entera de 2, siempre que el número sea lo suficientemente grande como para conservar todos los bits resultantes de la operación de “size/angle”. Por ejemplo, el número puede ser 64 en la etapa 1301, en lugar de 256, y el número de desplazamientos a la derecha es 6 en la etapa 1302, en lugar de 8. Si se adopta 64, la compensación de redondeo debe ser de 32.
El cálculo realizado en la etapa 1301 puede sustituirse por una operación 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 relación con los valores de angle. La tabla 1 proporcionada a continuación es una tabla a modo de ejemplo para la consulta en la etapa 1301:
Tabla 1
- angle
- 1 2 3 4 5 6 7 8
- InvAngle
- 2048 1024 683 512 410 341 293 256
Se supone que, en la tabla anterior, size es 8, y angle adopta valores de número entero de desde 1 hasta 8. Sin embargo, debe observarse que el tamaño no se limita a 8 y puede adoptar otro valor, tal como 4 y 16. Además, angle puede ser un número fraccionario en una representación de puntos fijos tal como se ha definido anteriormente.
Cuando se copia un píxel de referencia de refV a refH en la etapa 1202 de la figura 12 o la etapa 1302 de la figura 13, el píxel de referencia puede pasar a través de un filtro de paso bajo para reducir un posible solapamiento en el bloque de predicción. La intensidad del filtro de paso bajo puede variar según el valor de angle. Por ejemplo, cuando angle es igual a-size, puede aplicarse un filtrado de paso bajo débil y cuando angle es igual a -2, puede aplicarse un filtrado de paso bajo fuerte.
Tal como se ha explicado anteriormente, no todos los píxeles de referencia en refV se copian en refH. Dado que no se copian todos los píxeles de referencia en refV, se pierde algo de información cuando se copian los píxeles. Para mitigar la pérdida de información, puede duplicarse la resolución de píxeles de referencia en refH y refV de modo que refH y refV contienen no sólo píxeles de bloques anteriormente codificados y reconstruidos, sino también un píxel entre dos píxeles reconstruidos adyacentes que se genera interpolando dos píxeles adyacentes. Puede calcularse simplemente el promedio de dos píxeles adyacentes para generar un píxel de interpolación. El procedimiento de interpolación puede realizarse cuando se leen píxeles de referencia en la etapa 900 de la figura 9. Cuando se duplica la resolución de píxeles en refH y refV, se necesita ajustar a escala identificaciones de las direcciones de píxeles 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 + 2x col + 2”. Se necesita cambiar “int + col + 2” realizado en las etapas 907, 910, 915 por “int + 2x col + 3”. Se necesita cambiar “int2 + row + 1” e “int2 + row + 2” realizados en la etapa 919 por “int2
+ 2 xrow + 2” e “int2 + 2 x row + 3”, respectivamente.
En otro modo de realización, el procedimiento de la etapa 1202 en la figura 12 puede cambiarse simplemente por “refH [col]←refV [-col]” para simplificar adicionalmente el procedimiento de copiado. Aunque se degrada la exactitud de predicción, este modo de realización proporciona la menor complejidad a la operación de intra-predicción.
La figura 11B muestra la parte extendida 1104 añadida a refH. No se necesita que la parte extendida 1104 esté formada con píxeles de referencia de refV. La parte extendida 1104 puede formarse con píxeles de un área de bloque anteriormente reconstruido, que corresponde espacialmente a la ubicación de la parte extendida 1104. En la figura 11B, dado que se extiende en la dirección 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 añadiendo una compensación apropiada cuando se abordan píxeles de referencia en refH extendido. Lo mismo es cierto para volver a ajustar a escala el intervalo de refV.
En otro modo de realización, el límite de intervalo de angle puede elegirse libremente. En los modos de realización 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 realización anteriores, los límites de intervalo de angle están definidos con el tamaño del bloque objetivo. Obsérvese que los límites de intervalo de angle pueden definirse independientemente del tamaño del bloque objetivo, aunque todavía es preferible que el límite de intervalo se defina con una potencia entera de 2, de manera que log2_rangelimit sea un número entero positivo y la ecuación “rangelimit = 1 << log2_rangelimit” siga siendo cierta. Al elegir un número grande adecuado para rangelimit, puede establecerse un gran número de direcciones de predicción y representarse mediante valores de angle a intervalos angulares lo
suficientemente amplios.
Si el límite de intervalo de angle se define independientemente del tamaño 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
5 para las etapas 909, 912, 917 y 921. También se necesita sustituir la comparación de “angle ≥ -1” realizada en la etapa 1000 de la figura 10 por “angle x sizel/rangelimit≥ -1” o “angle x size ≥ -rangelimit”. Además, 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 comparación de “¿col = angle?” realizada en la etapa 1204 por “¿col = angle x size/rangelimit?”.
10 Si se introduce rangelimit como límite de intervalo de angle, la tabla 1 (proporcionada anteriormente) puede cambiarse de la siguiente forma:
Tabla 2
- angle*
- 2 5 9 13 17 21 26 32
- InvAngle
- 4096 1638 910 630 482 390 315 256
15 En la tabla 2, se establece rangelimit a 32. Angle* es igual a una aproximación de número entero de “rangelimit x tan ( x angle/8)”, donde angle =1, 2, 3, 4, 5, 6, 7 y8. InvAngle es igual a 256 x rangelimit/angle*. Los valores en la tabla 2 son todos números enteros que se derivan mediante redondeo al alza. En lugar de redondearse al alza, los números pueden redondearse a la baja. En la tabla 3 proporcionada a continuación, InvAngle es igual a32 x
20 rangelimitlangle*. Dado que se usa “32” en lugar de “256”, la exactitud de predicción es necesariamente inferior a la de la tabla 2.
Tabla 3
- angle*
- 2 5 9 13 17 21 26 32
- InvAngle
- 512 204 113 78 60 48 39 32
25 La figura 14 es un diagrama de flujo que muestra otro modo de realización que simplifica adicionalmente el procedimiento mostrado en la figura 10. El procedimiento mostrado en la figura 10 de copiar píxeles de referencia de refV en refH se realiza antes de que el flujo entre en el bucle de predicción principal, mientras que el procedimiento de copiado mostrado en la figura 14 se realiza dentro del bucle de predicción principal. Además, el procedimiento mostrado en la figura 14 elimina la variable InvAngle. Las etapas 900, 902 y 921 mostradas en la figura 14 son de
30 las etapas correspondientes en la figura 10.
En la etapa 1401, se inicia un contador lastInt a -1. lastInt representa el índice del último píxel que se añadió a refH. En la etapa 902, se calcula pos mediante angle x (row + 1). Tal como se ha explicado anteriormente, pos identifica la posición de una intersección entre los límites y la dirección de predicción representada por angle. En el contexto de 35 la figura 9, la etapa 902 produce pos, que identifica la posición de una intersección entre el límite horizontal y la dirección de predicción representada por angle. Además, en la etapa 902, una parte entera en pos se almacena en int y una parte fraccionaria en pos se almacena en un parámetro “frac”. En la etapa 1402, se determina si int es inferior a lastInt. Si int es inferior a lastInt, un píxel de referencia en refV identificado mediante row se copia en refH en una dirección identificada mediante “int + 1”. La etapa 1404 consiste en las etapas 904, 905, 906, 907, 908, 909,
40 910, 911 y 912 mostradas en las figuras 9 y 10, cuya descripción no se repite aquí. En la etapa 1405, int se copia en lastInt. La operación de copiar int en lastInt puede realizarse en la etapa 1403, en lugar de la etapa 1405.
La operación de copiado en la etapa 1403 da como resultado copiar el mismo píxel que se copió 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 45 número entero más próximo usando de manera condicional “row + 1”, en lugar de “row”, en la etapa 1403 cuando la posición fraccionaria frac calculada en la etapa 902 es mayor que offset, lo cual se identifica mediante rangelimit + (angle >> 1). Obsérvese 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 aritmética de 32 bits, el desplazamiento a la
50 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 dirección “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” será siempre positivo y, por lo tanto, no se producirá ningún redondeo.
55 A continuación se enumera el código fuente desarrollado en el lenguaje de programación C++, que implementa el procedimiento mostrado en la figura 14. El código fuente se modifica de la función TComPredictiopn::xPredIntraAng encontrada en el archivo TComPrediction.cpp que es parte del software TMuC 0.7 desarrollado por JCT-VC, que está disponible en http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7.
60 // Función para derivar las intra-predicciones angulares simplificadas
5
15
25
35
45
55
65
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 índice de modo a la dirección de predicción principal y el ángulo 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 parámetro de ángulo a size2 Int iAngTable[9] = { 0, 2, 5, 9, 13, 17, 21, 26, 32}; absAng = iAngTable[absAng]; intraPredAngle = signAng * absAng; // Realizar la predicción DC if (modeDC) { Pel dcval = predIntraGetPredValDC(pSrc, iSrcStride, iWidth, iHeight, bAbove, bLeft); for (k=0;k<blkSize;k++) { for (1=0;1<blkSize;1++) { pDst(k*iDstStride+1] = dcval; } }
} // Realizar predicciones angulares
5
else { Pel tmp; Int *pSrcTL = pSrc -iSrcStride -1; Int iStepMain = (modeVer) ? 1 : iSrcStride; if (intraPredAngle == 0) {
15
for (k=0;k<blkSize;k++) { for (1=0;1<blkSize;1++) { pDst [k*iDstStride+1] = pSrcTL[(1+1) * iStepMain]; } }
25
}
else { Int iStepSide = (modeVer) ? iSrcStride 1; int lastDeltaInt = -1; Int iOffset = 32 + (intraPredAngle >> 1); // permite redondear a la referencia lateral más próxima
35
// 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++)
45
refMain[k] = pSrcTL[(k+1) * iStepMain]; } else {
for (k = -1; k < blkSize; k++) // el resto se copia más tarde en la etapa 1403, según y cuando se requiera refMain[k] = pSrcTL[(k+1) * iStepMain];
55
} for (k = 0; k < blkSize; k++) { Int deltaPos = (k+1) * intraPredAngle; deltaInt = deltaPos >> 5; deltaFract = deltaPos & (32 -1);
65
if (deltaInt < lastDeltaInt) { // etapa 1402
lastDeltaInt = deltaInt; refMain[deltaInt] = pSrcTL[(k-((iOffset-deltaFract)>>31))*iStepSide]; 5
// etapa 1403
}
// etapa 1404
if (deltaFract) {
// Realizar filtrado lineal 15 for (1=0;1<blkSize;1++) { refMainIndex = 1+deltaInt; pDst[k*iDstStride+1] = (Pel) (((32-deltaFract) * refMain[refMainIndex] + deltaFract * refMain[refMainlndex+1] + 16) >> 5 ); } 25 } else { // Simplemente copiar las muestras de números enteros for (1=0;1<<blkSize;l++) { pDst[k*iDstStride+1] = refMain[1+deltaInt]; 35 } } } } // Dar la vuelta al bloque si esto es el modo horizontal 45 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]; 55 pDst[1*iDstStride+k] = tmp; } } } } 65 Aunque sin duda se le ocurrirán muchas alteraciones y modificaciones de la presente invención a un experto habitual en la técnica, tras haber leído la descripción anterior debe entenderse que no se pretende de ninguna
manera que ningún modo de realización particular mostrado y descrito a modo de ilustración se considere limitativo. Por tanto, no se pretende que referencias a detalles de diversos modos de realización limiten el alcance de las reivindicaciones, que en sí mismas sólo mencionan aquellas características que se consideran esenciales para la invención.
Claims (10)
-
imagen1 - REIVINDICACIONES
- 1.
- Método de codificación de vídeo que comprende etapas ejecutables por ordenador ejecutado por un
- procesador de un codificador de vídeo para implementar:
- 5
- recuperar al menos algunos píxeles, según una dirección de predicción de intra-predicción en un bloque
- objetivo que va a predecirse, desde una primera área de memoria (refV) en la que está almacenada una
- matriz de píxeles de límite vertical, en el que los píxeles de límite vertical están ubicados directamente a la
- izquierda del bloque objetivo;
- añadir los píxeles recuperados a una matriz de píxeles de límite horizontal ubicados directamente por
- encima del bloque objetivo, en el que los píxeles recuperados se añaden directamente al extremo izquierdo
- de la matriz de píxeles de límite horizontal para formar una secuencia consecutiva de los píxeles de límite
- horizontal;
- 15
- almacenar los píxeles añadidos en una segunda área de memoria (refH) en la que está almacenada la
- matriz de píxeles de límite horizontal, para extender la matriz almacenada en la segunda área de memoria
- (refH) del mismo; y
- realizar intra-predicción del bloque objetivo usando sólo los píxeles de límite horizontal incluyendo los
- píxeles añadidos de la matriz extendida almacenada en la segunda área de memoria (refH) como píxeles
- de referencia.
-
- 2.
- Método según la reivindicación 1, en el que recuperar al menos algunos píxeles de la primera área de
- 25
- memoria (refV) comprende identificar los almenas algunos píxeles entre los píxeles de límite vertical,
- usando un identificador de píxeles verticales que se expresa mediante
imagen2 donde size representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del bloque objetivo, angle tiene un valor negativo y representa una dirección de predicción que interseca tanto con la matriz de píxeles de límite horizontal como con la matriz de píxeles de límite vertical y col es un contador que se disminuye en 1 desde -1 hasta angle, yañadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación identificada mediante un identificador de píxeles horizontales [col]. - 3. Método según la reivindicación 1, en el que recuperar al menos algunos píxeles de la primera área de memoria comprende:calcular InvAngle a partir de obtener InvAngle de una tabla de consulta que indica valores de InvAngle en relación con valores de ángulo, donde InvAngle se expresa mediante
imagen3 - 45
- donde size representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del
- bloque objetivo, angle tiene un valor negativo y representa una dirección de predicción que interseca tanto
- con la matriz de píxeles de límite horizontal como con la matriz de píxeles de límite vertical y N es una
- potencia entera predeterminada de 2, e
- identificar los menos algunos píxeles entre los píxeles de límite vertical, usando un identificador de píxeles
- verticales que se expresa mediante [col x InvAngle >> log2 N], donde col es un contador que se disminuye
- en 1 desde -1 hasta angle, y
- 55
- añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado
- mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación
- identificada mediante un identificador de píxeles horizontales [col].
-
- 4.
- Método según la reivindicación 1, en el que recuperar al menos algunos píxeles de la primera área de
- memoria (refV) comprende:
imagen4 imagen3 - 5
- donde size representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del
- bloque objetivo, angle tiene un valor negativo y representa una dirección de predicción que interseca tanto
- con la matriz de píxeles de límite horizontal como con la matriz de píxeles de límite vertical y N es una
- potencia entera predeterminada de 2, e
- 10
- 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 [col x InvAngle >> log2 N], donde col es un contador que se
- disminuye en 1 desde -1 hasta angle, y
- 15
- añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado
- mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación
- identificada mediante un identificador de píxeles horizontales [col].
-
- 5.
- Método según la reivindicación 1 en el que recuperar al menos algunos píxeles de la primera área de
- 20
- memoria comprende identificar un píxel entre los píxeles de límite vertical, usando un identificador de
- píxeles verticales [row], donde row es un contador que se aumenta en 1 desde 0 hasta size, y size
- representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del bloque objetivo y
- añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado
- 25
- mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación
- identificada mediante un identificador de píxeles horizontales que se expresa mediante [int+1], donde int es
- una representación en número entero de una posición de un píxel que corresponde a una intersección entre
- la matriz de píxeles de límite horizontal y una dirección de predicción.
- 30
- 6. Método de descodificación de vídeo que comprende etapas ejecutables por ordenador ejecutado por un
- procesador de un descodificador de vídeo para implementar:
- recuperar al menos algunos píxeles, según una dirección de predicción de intra-predicción en un bloque
- objetivo que va a predecirse, desde una primera área de memoria (refV) en la que está almacenada una
- 35
- matriz de píxeles de límite vertical, en el que los píxeles de límite vertical están ubicados directamente a la
- izquierda del bloque objetivo;
- añadir los píxeles recuperados a una matriz de píxeles de límite horizontal ubicados directamente por
- encima del bloque objetivo, en el que los píxeles recuperados se añaden directamente al extremo izquierdo
- 40
- de la matriz de píxeles de límite horizontal para formar una secuencia consecutiva de los píxeles de límite
- horizontal;
- almacenar los píxeles añadidos en una segunda área de memoria (refH) en la que está almacenada la
- matriz de píxeles de límite horizontal, para extender la matriz almacenada en la segunda área de memoria
- 45
- (refH) del mismo; y
- realizar intra-predicción del bloque objetivo usando sólo los píxeles de límite horizontal incluyendo los
- píxeles añadidos, de la matriz extendida almacenada en la segunda área de memoria (refH) como píxeles
- de referencia.
- 50
-
- 7.
- Método según la reivindicación 6, en el que recuperar al menos algunos píxeles de la primera área de
- memoria (refV) comprende 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
imagen2 55donde size representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del bloque objetivo, angle tiene un valor negativo y representa una dirección de predicción que interseca tanto con la matriz de píxeles de límite horizontal como con la matriz de píxeles de límite vertical y col es un60 contador que se disminuye en 1 desde -1 hasta angle, y añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación identificada mediante un identificador de píxeles horizontales [col].imagen5 - 8. Método según la reivindicación 6, en el que recuperar al menos algunos píxeles de la primera área de memoria comprende:calcular InvAngle a partir de
imagen3 10donde size representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del bloque objetivo, angle tiene un valor negativo y representa una dirección de predicción que interseca tanto con la matriz de píxeles de límite horizontal como con la matriz de píxeles de límite vertical y N es una15 potencia entera predeterminada de 2, eidentificar 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 [col x InvAngle >> log2 N], donde col es un contador que se disminuye en 1 desde -1 hasta angle, y20 añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación identificada mediante un identificador de píxeles horizontales [col].25 9. Método según la reivindicación 6, en el que recuperar al menos algunos píxeles de la primera área de memoria (refV) comprende:obtener InvAngle de una tabla de consulta que indica valores de InvAngle en relación con valores de ángulo, donde InvAngle se expresa mediante30imagen3 - donde size representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del
- bloque objetivo, angle tiene un valor negativo y representa una dirección de predicción que interseca tanto
- 35
- con la matriz de píxeles de límite horizontal como con la matriz de píxeles de límite vertical y N es una
- potencia entera predeterminada de 2, 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 [col x InvAngle >> log2 N], donde col es un contador que se
- 40
- disminuye en 1 desde -1 hasta angle, y
- añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado
- mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación
- identificada mediante un identificador de píxeles horizontales [col].
- 45
-
- 10.
- Método según la reivindicación 6, en el que recuperar al menos algunos píxeles de la primera área de
- memoria comprende identificar un píxel entre los píxeles de límite vertical, usando un identificador de
- píxeles verticales [row], donde row es un contador que se aumenta en 1 desde 0 hasta size, y size
- representa un tamaño del bloque objetivo, el tamaño es el número de filas o columnas del bloque objetivo y
- 50
- añadir los píxeles recuperados a la segunda área de memoria (refH) comprende añadir un píxel identificado
- mediante el identificador de píxeles verticales a la segunda área de memoria (refH) en una ubicación
- identificada mediante un identificador de píxeles horizontales que se expresa mediante [int+1], donde int es
- una representación en número entero de una posición de un píxel que corresponde a una intersección entre
- 55
- la matriz de píxeles de límite horizontal y una dirección de predicción.
-
- 11.
- Codificador de vídeo que comprende un procesador de un sistema informático y una memoria que
- almacena programas ejecutables por el procesador para:
- 60
- recuperar al menos algunos píxeles, según una dirección de predicción de intra-predicción en un bloque
- objetivo que va a predecirse, desde una primera área de memoria (refV) en la que está almacenada una
imagen6 - matriz de píxeles de límite vertical, en el que los píxeles de límite vertical están ubicados directamente a la
- izquierda del bloque objetivo;
- añadir los píxeles recuperados a una matriz de píxeles de límite horizontal ubicados directamente por
- 5
- encima del bloque objetivo, en el que los píxeles recuperados se añaden directamente al extremo izquierdo
- de la matriz de píxeles de límite horizontal para formar una secuencia consecutiva de los píxeles de límite
- horizontal;
- almacenar los píxeles añadidos en una segunda área de memoria (refH) en la que está almacenada la
- 10
- matriz de píxeles de límite horizontal, para extender la matriz almacenada en la segunda área de memoria
- (refH) del mismo; y
- realizar intra-predicción del bloque objetivo usando sólo los píxeles de límite horizontal incluyendo los
- píxeles añadidos, de la matriz extendida almacenada en la segunda área de memoria (refH) como píxeles
- 15
- de referencia.
-
- 12.
- Descodificador de vídeo que comprende un procesador de un sistema informático y una memoria que
- almacena programas ejecutables por el procesador para:
- 20
- recuperar al menos algunos píxeles, según una dirección de predicción de intra-predicción en un bloque
- objetivo que va a predecirse, desde una primera área de memoria (refV) en la que está almacenada una
- matriz de píxeles de límite vertical, en el que los píxeles de límite vertical están ubicados directamente a la
- izquierda del bloque objetivo;
- 25
- añadir los píxeles recuperados a una matriz de píxeles de límite horizontal ubicados directamente por
- encima del bloque objetivo, en el que los píxeles recuperados se añaden directamente al extremo izquierdo
- de la matriz de píxeles de límite horizontal para formar una secuencia consecutiva de los píxeles de límite
- horizontal;
- 30
- almacenar los píxeles añadidos en una segunda área de memoria (refH) en la que está almacenada la
- matriz de píxeles de límite horizontal, para extender la matriz almacenada en la segunda área de memoria
- (refH) del mismo; y
- realizar intra-predicción del bloque objetivo usando sólo los píxeles de límite horizontal incluyendo los
- 35
- píxeles añadidos, de la matriz extendida almacenada en la segunda área de memoria (refH) como píxeles
- de referencia.
Applications Claiming Priority (5)
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 | ||
PCT/US2011/044014 WO2012009540A1 (en) | 2010-07-14 | 2011-07-14 | Low-complexity intra prediction for video coding |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2621902T3 true ES2621902T3 (es) | 2017-07-05 |
Family
ID=45469801
Family Applications (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES19163444T Active ES2864048T3 (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 |
ES11807512.6T Active ES2621902T3 (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 |
ES15169606.9T Active ES2637446T3 (es) | 2010-07-14 | 2011-07-14 | Intra-predicción de baja complejidad para codificación de vídeo |
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 Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES19163444T Active ES2864048T3 (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 |
Family Applications After (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES15169604.4T Active ES2605530T3 (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 |
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 |
Country Status (16)
Country | Link |
---|---|
US (6) | US9225986B2 (es) |
EP (7) | EP2934009B1 (es) |
JP (8) | JP5687341B2 (es) |
KR (7) | KR101811360B1 (es) |
CN (4) | CN105227960B (es) |
AU (1) | AU2011279139B2 (es) |
BR (1) | BR112013000963B1 (es) |
CA (7) | CA3014052C (es) |
ES (7) | ES2864048T3 (es) |
HU (2) | HUE053802T2 (es) |
MX (5) | MX367865B (es) |
PL (7) | PL3226560T3 (es) |
PT (7) | PT2594076T (es) |
RU (8) | RU2579947C2 (es) |
SG (1) | SG187065A1 (es) |
WO (1) | WO2012009540A1 (es) |
Families Citing this family (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
MX367865B (es) | 2010-07-14 | 2019-09-05 | Ntt Docomo Inc | Intrapredicción de baja complejidad para la codificación de video. |
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 | 한국전자통신연구원 | 화면내 예측 블록 경계 필터링을 이용한 부호화/복호화 방법 및 그 장치 |
US8811760B2 (en) * | 2011-10-25 | 2014-08-19 | Mitsubishi Electric Research Laboratories, Inc. | Coding images using intra prediction modes |
US10645398B2 (en) | 2011-10-25 | 2020-05-05 | Texas Instruments Incorporated | Sample-based angular intra-prediction in video coding |
US9344715B2 (en) | 2011-11-07 | 2016-05-17 | Futurewei Technologies, Inc. | 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 | 숭실대학교산학협력단 | 영상의 인트라 예측 장치 |
TWI627857B (zh) * | 2012-06-29 | 2018-06-21 | Sony Corp | Image processing device 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 |
US11109036B2 (en) | 2013-10-14 | 2021-08-31 | Microsoft Technology Licensing, Llc | Encoder-side options for intra block copy prediction mode for video and image coding |
WO2015054811A1 (en) | 2013-10-14 | 2015-04-23 | Microsoft Corporation | Features of intra block copy prediction mode for video and image coding and decoding |
CA2925183C (en) | 2013-10-14 | 2020-03-10 | Microsoft Technology Licensing, Llc | Features of base color index map mode for video and image coding and decoding |
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 |
JP6355744B2 (ja) | 2014-01-03 | 2018-07-11 | マイクロソフト テクノロジー ライセンシング,エルエルシー | ビデオ及び画像符号化/デコーディングにおけるブロックベクトル予測 |
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 |
JP2017512026A (ja) | 2014-03-04 | 2017-04-27 | マイクロソフト テクノロジー ライセンシング,エルエルシー | イントラブロックコピー予測におけるブロック反転及びスキップモード |
US10785486B2 (en) | 2014-06-19 | 2020-09-22 | Microsoft Technology Licensing, Llc | Unified intra block copy and inter prediction modes |
AU2014408228B2 (en) | 2014-09-30 | 2019-09-19 | 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 | 日本電気株式会社 | 映像符号化システム、映像符号化回路および映像符号化方法 |
KR20170131473A (ko) * | 2015-03-29 | 2017-11-29 | 엘지전자 주식회사 | 비디오 신호의 인코딩/디코딩 방법 및 장치 |
WO2016197314A1 (en) | 2015-06-09 | 2016-12-15 | Microsoft Technology Licensing, Llc | Robust encoding/decoding of escape-coded pixels in palette mode |
WO2017034331A1 (ko) * | 2015-08-27 | 2017-03-02 | 엘지전자 주식회사 | 영상 코딩 시스템에서 크로마 샘플 인트라 예측 방법 및 장치 |
CN106231340B (zh) * | 2016-09-23 | 2019-08-27 | 优酷网络技术(北京)有限公司 | 一种基于hevc的帧内预测解码方法及装置 |
US10869049B2 (en) * | 2016-11-29 | 2020-12-15 | Research & Business Foundation Sungyunwan University | Image encoding/decoding method and device, and recording medium in which bitstream is stored |
CN113784122B (zh) | 2016-12-23 | 2022-10-11 | 华为技术有限公司 | 用于扩展预定定向帧内预测模式集合的装置、方法及介质 |
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 |
CN110832864B (zh) * | 2017-06-26 | 2024-03-29 | 交互数字麦迪逊专利控股公司 | 利用多个加权参考进行帧内预测的方法和装置 |
US10764587B2 (en) * | 2017-06-30 | 2020-09-01 | Qualcomm Incorporated | Intra prediction in video coding |
JP2019041165A (ja) * | 2017-08-23 | 2019-03-14 | 富士通株式会社 | 画像符号化装置、画像復号装置、画像処理方法、及び画像処理プログラム |
WO2019059107A1 (ja) * | 2017-09-20 | 2019-03-28 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | 符号化装置、復号装置、符号化方法及び復号方法 |
CN109587491B (zh) * | 2017-09-28 | 2022-09-23 | 腾讯科技(深圳)有限公司 | 一种帧内预测方法、装置及存储介质 |
WO2019112969A1 (en) | 2017-12-04 | 2019-06-13 | CyMedica Orthopedics, Inc. | Patient therapy systems and methods |
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 |
TWI730311B (zh) * | 2018-03-29 | 2021-06-11 | 弗勞恩霍夫爾協會 | 用以選擇內預測模式以供填補之設備 |
CN110072112B (zh) * | 2019-03-12 | 2023-05-12 | 浙江大华技术股份有限公司 | 帧内预测方法、编码器及存储装置 |
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 |
WO2021045655A2 (en) * | 2019-12-31 | 2021-03-11 | Huawei Technologies Co., Ltd. | Method and apparatus for intra prediction |
JP7470382B2 (ja) * | 2020-06-08 | 2024-04-18 | 株式会社大一商会 | 遊技機 |
WO2023120410A1 (ja) | 2021-12-20 | 2023-06-29 | 株式会社グランドライン | 構造物の表面処理方法、ブラスト処理装置、粉粒状製品の製造設備における付着物除去方法および装置、並びに、粉粒状製品の製造方法および製造設備 |
CN116071242B (zh) * | 2023-03-17 | 2023-07-14 | 山东云海国创云计算装备产业创新中心有限公司 | 一种图像处理方法、系统、设备以及存储介质 |
Family Cites Families (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6332042B1 (en) * | 1997-10-23 | 2001-12-18 | Sony Corporation | Apparatus and method for encoding and decoding data in a lossy transmission environment |
ATE384404T1 (de) | 2002-02-01 | 2008-02-15 | Matsushita Electric Ind Co Ltd | Kodierungsverfahren und dekodierungsverfahren für bewegliche bilder |
CN100562119C (zh) * | 2002-02-01 | 2009-11-18 | 松下电器产业株式会社 | 动画图象译码方法和动画图象译码装置 |
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 |
KR20090074164A (ko) * | 2006-09-29 | 2009-07-06 | 톰슨 라이센싱 | 기하학적 인트라 예측 |
US7991236B2 (en) * | 2006-10-16 | 2011-08-02 | Nokia Corporation | Discardable lower layer adaptations in scalable video coding |
EP2140687A2 (en) * | 2007-04-03 | 2010-01-06 | Gary Demos | Flowfield motion compensation for video compression |
US20100034268A1 (en) * | 2007-09-21 | 2010-02-11 | Toshihiko Kusakabe | Image coding device and image decoding device |
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 | 삼성전자주식회사 | 영상의 부호화 방법 및 장치, 그 복호화 방법 및 장치 |
MX367865B (es) | 2010-07-14 | 2019-09-05 | Ntt Docomo Inc | Intrapredicción de baja complejidad para la codificación de video. |
WO2014156046A1 (ja) | 2013-03-29 | 2014-10-02 | 株式会社Jvcケンウッド | 画像符号化装置、画像符号化方法及び画像符号化プログラム、並びに画像復号装置、画像復号方法及び画像復号プログラム |
-
2011
- 2011-07-14 MX MX2018014741A patent/MX367865B/es unknown
- 2011-07-14 PT PT118075126T patent/PT2594076T/pt unknown
- 2011-07-14 ES ES19163444T patent/ES2864048T3/es active Active
- 2011-07-14 PT PT151696044T patent/PT2934008T/pt unknown
- 2011-07-14 PL PL17170581T patent/PL3226560T3/pl unknown
- 2011-07-14 MX MX2017000542A patent/MX361484B/es unknown
- 2011-07-14 KR KR1020167020283A patent/KR101811360B1/ko active IP Right Grant
- 2011-07-14 CA CA3014052A patent/CA3014052C/en active Active
- 2011-07-14 KR KR1020187005732A patent/KR101927281B1/ko active IP Right Grant
- 2011-07-14 PT PT191836139T patent/PT3570545T/pt unknown
- 2011-07-14 PT PT17170595T patent/PT3232666T/pt unknown
- 2011-07-14 RU RU2013106296/08A patent/RU2579947C2/ru active
- 2011-07-14 KR KR1020187018014A patent/KR101927283B1/ko active IP Right Grant
- 2011-07-14 AU AU2011279139A patent/AU2011279139B2/en active Active
- 2011-07-14 KR KR1020187018015A patent/KR101924885B1/ko active IP Right Grant
- 2011-07-14 EP EP15169606.9A patent/EP2934009B1/en active Active
- 2011-07-14 ES ES17170595T patent/ES2729031T3/es active Active
- 2011-07-14 BR BR112013000963A patent/BR112013000963B1/pt active IP Right Grant
- 2011-07-14 PT PT151696069T patent/PT2934009T/pt unknown
- 2011-07-14 CA CA3014042A patent/CA3014042C/en active Active
- 2011-07-14 PT PT171705817T patent/PT3226560T/pt unknown
- 2011-07-14 CN CN201510547113.8A patent/CN105227960B/zh active Active
- 2011-07-14 ES ES11807512.6T patent/ES2621902T3/es active Active
- 2011-07-14 EP EP17170581.7A patent/EP3226560B1/en active Active
- 2011-07-14 KR KR1020137000687A patent/KR101745928B1/ko active IP Right Grant
- 2011-07-14 PL PL15169604T patent/PL2934008T3/pl unknown
- 2011-07-14 CN CN201180034682.2A patent/CN103004210B/zh active Active
- 2011-07-14 MX MX2013000372A patent/MX2013000372A/es active IP Right Grant
- 2011-07-14 US US13/809,511 patent/US9225986B2/en active Active
- 2011-07-14 CA CA3014131A patent/CA3014131C/en active Active
- 2011-07-14 EP EP11807512.6A patent/EP2594076B1/en active Active
- 2011-07-14 PL PL11807512T patent/PL2594076T3/pl unknown
- 2011-07-14 CN CN201510546896.8A patent/CN105120263B/zh active Active
- 2011-07-14 HU HUE19163444A patent/HUE053802T2/hu unknown
- 2011-07-14 PL PL19183613T patent/PL3570545T3/pl unknown
- 2011-07-14 HU HUE19183613A patent/HUE054630T2/hu unknown
- 2011-07-14 CA CA3098217A patent/CA3098217C/en active Active
- 2011-07-14 EP EP19163444.3A patent/EP3522535B1/en active Active
- 2011-07-14 EP EP19183613.9A patent/EP3570545B1/en active Active
- 2011-07-14 ES ES15169604.4T patent/ES2605530T3/es active Active
- 2011-07-14 JP JP2013519828A patent/JP5687341B2/ja active Active
- 2011-07-14 PL PL15169606T patent/PL2934009T3/pl unknown
- 2011-07-14 WO PCT/US2011/044014 patent/WO2012009540A1/en active Application Filing
- 2011-07-14 RU RU2015141145A patent/RU2613725C1/ru active
- 2011-07-14 EP EP15169604.4A patent/EP2934008B1/en active Active
- 2011-07-14 EP EP17170595.7A patent/EP3232666B1/en active Active
- 2011-07-14 CA CA2934184A patent/CA2934184C/en active Active
- 2011-07-14 PL PL17170595T patent/PL3232666T3/pl unknown
- 2011-07-14 CA CA2804762A patent/CA2804762C/en active Active
- 2011-07-14 ES ES15169606.9T patent/ES2637446T3/es active Active
- 2011-07-14 ES ES17170581T patent/ES2748100T3/es active Active
- 2011-07-14 SG SG2013002811A patent/SG187065A1/en unknown
- 2011-07-14 ES ES19183613T patent/ES2873847T3/es active Active
- 2011-07-14 CN CN201510548062.0A patent/CN105120264B/zh active Active
- 2011-07-14 KR KR1020167020284A patent/KR101835460B1/ko active IP Right Grant
- 2011-07-14 MX MX2015002858A patent/MX344987B/es unknown
- 2011-07-14 CA CA3096445A patent/CA3096445C/en active Active
- 2011-07-14 RU RU2015141279A patent/RU2613722C1/ru active
- 2011-07-14 KR KR1020177035940A patent/KR101878293B1/ko active IP Right Grant
- 2011-07-14 PT PT191634443T patent/PT3522535T/pt unknown
- 2011-07-14 PL PL19163444T patent/PL3522535T3/pl unknown
-
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,144 patent/US10116960B2/en active Active
- 2015-09-30 US US14/871,274 patent/US9942565B2/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 RU2019112302A patent/RU2710947C1/ru active
- 2019-04-23 RU RU2019112301A patent/RU2710946C1/ru active
- 2019-04-23 RU RU2019112303A patent/RU2738786C2/ru active
- 2019-07-12 US US16/510,188 patent/US10841613B2/en active Active
- 2019-07-12 US US16/510,217 patent/US10841614B2/en active Active
-
2020
- 2020-02-14 JP JP2020023595A patent/JP6828199B2/ja active Active
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2621902T3 (es) | Intra-predicción de baja complejidad para codificación de vídeo | |
AU2015264787B2 (en) | Low-complexity intra prediction for video coding | |
AU2016277600A1 (en) | Low-complexity intra prediction for video coding |