ES2633651T3 - Codificación de conjuntos de parámetros y cabeceras de unidad NAL para codificación de vídeo - Google Patents

Codificación de conjuntos de parámetros y cabeceras de unidad NAL para codificación de vídeo Download PDF

Info

Publication number
ES2633651T3
ES2633651T3 ES13700835.5T ES13700835T ES2633651T3 ES 2633651 T3 ES2633651 T3 ES 2633651T3 ES 13700835 T ES13700835 T ES 13700835T ES 2633651 T3 ES2633651 T3 ES 2633651T3
Authority
ES
Spain
Prior art keywords
video
layers
vps
encoding
video data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13700835.5T
Other languages
English (en)
Inventor
Ying Chen
Ye-Kui Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2633651T3 publication Critical patent/ES2633651T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H04N19/463—Embedding additional information in the video signal during the compression process by compressing encoding parameters before transmission
    • 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/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • 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/46—Embedding additional information in the video signal during the compression process
    • 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/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

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

Abstract

Un procedimiento de codificación de datos de vídeo, comprendiendo el procedimiento: codificación (104, 122) de un conjunto de parámetros de vídeo, VPS, para una pluralidad de capas de datos de vídeo, en el que cada una de la pluralidad de capas de datos de vídeo se refiere al VPS, y en la que la codificación del VPS comprende: codificación de datos del VPS indicativos de un cierto número de tramas a reordenar en al menos una entre la pluralidad de capas de datos de vídeo, codificación de datos del VPS indicativos de un cierto número de imágenes a almacenar en una memoria intermedia de imágenes descodificadas, DPB, durante la descodificación de la pluralidad de capas de datos de vídeo, y codificación de datos del VPS indicativos de un número máximo de capas temporales en la pluralidad de capas de datos de vídeo; y codificación de (114, 130) la pluralidad de capas de datos de vídeo basándose, al menos en parte, en el VPS.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Codificacion de conjuntos de parametros y cabeceras de unidad NAL para codificacion de video CAMPO TECNICO
Esta divulgacion se refiere a la codificacion de video.
ANTECEDENTES
Las capacidades del video digital pueden incorporarse en una amplia gama de dispositivos, incluyendo televisores digitales, sistemas de difusion digital directa, sistemas de difusion inalambrica, asistentes digitales personales (PDA), ordenadores portatiles o de escritorio, ordenadores de tableta, lectores de libros electronicos, camaras digitales, dispositivos de grabacion digital, reproductores de medios digitales, dispositivos de videojuegos, consolas de videojuegos, telefonos celulares o de radio por satelite, los denominados "telefonos inteligentes", dispositivos de videoconferencia, dispositivos de transmision de video y similares. Los dispositivos de video digital implementan tecnicas de codificacion de video, tales como las descritas en las normas definidas por MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Parte 10, Codificacion Avanzada de Video (AVC), la norma de Codificacion de Video de Alta Eficiencia (HEVC), actualmente en desarrollo y las ampliaciones de tales normas. Un reciente borrador de la proxima norma HEVC esta disponible en
http://phenix.int-
evry.fr/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC-G1103-v3.zip. Los dispositivos de video pueden transmitir, recibir, codificar, descodificar y/o almacenar informacion de video digital mas eficazmente, implementando tales tecnicas de codificacion de video.
Las tecnicas de codificacion de video incluyen la prediccion espacial (intra-imagen) y/o la prediccion temporal (entre imagenes) para reducir o eliminar la redundancia intrfnseca en las secuencias de video. Para la codificacion de video basada en bloques, un fragmento de video (por ejemplo, una trama de video o una parte de una trama de video) puede dividirse en bloques de video, que tambien pueden denominarse bloques arbolados, unidades de codificacion (CU) y/o nodos de codificacion. Los bloques de video en un fragmento intracodificado (I) de una imagen son codificados usando la prediccion espacial con respecto a muestras de referencia en bloques contiguos de la misma imagen. Los bloques de video en un fragmento intercodificado (P o B) de una imagen pueden usar la prediccion espacial con respecto a muestras de referencia en bloques contiguos de la misma imagen, o la prediccion temporal con respecto a muestras de referencia en otras imagenes de referencia. Las imagenes pueden denominarse tramas y las imagenes de referencia pueden denominarse tramas de referencia.
La prediccion espacial o temporal da como resultado un bloque predictivo para un bloque a codificar. Los datos residuales representan diferencias de pfxeles entre el bloque original a codificar y el bloque predictivo. Un bloque intercodificado se codifica de acuerdo con un vector de movimiento que apunta a un bloque de muestras de referencia que forman el bloque predictivo, y los datos residuales que indican la diferencia entre el bloque codificado y el bloque predictivo. Un bloque intracodificado se codifica de acuerdo con una modalidad de intracodificacion y los datos residuales. Para una mayor compresion, los datos residuales pueden transformarse desde el dominio de pfxeles a un dominio de transformacion, dando como resultado coeficientes de transformacion residuales, los cuales pueden cuantizarse posteriormente. Los coeficientes de transformacion cuantizados, inicialmente dispuestos en una formacion bidimensional, pueden explorarse con el fin de producir un vector unidimensional de coeficientes de transformacion, y puede aplicarse la codificacion por entropfa para lograr aun mas compresion. El documento US 2005/0254575 A1 describe la produccion de una o mas capas del flujo de datos escalable. Las capas se caracterizan por una propiedad de codificacion y el procedimiento incluye senalar las capas con la propiedad de codificacion de tal manera que sean legibles por un descodificador para determinar la propiedad de codificacion sin analizar el flujo de datos escalable. Tambien describe un flujo de bits escalable, en el que al menos dos capas de escalabilidad estan presentes, y cada capa esta caracterizada por un conjunto de al menos una propiedad, como perfil, nivel y un conjunto de al menos un parametro HRD / VBV, que puede ser diferente al de la totalidad del flujo, y en el que dicho conjunto de al menos una propiedad esta senalado para al menos una capa que es diferente al flujo completo. El documento de Jill Boyce y col., "Extensible High Layer Syntax for Scalability" (Sintaxis de Capa Alta Extensible para Escalabilidad), JCTVC-E279, del 22 de marzo de 2011, divulga emplear un conjunto de parametros de dependencia DPS ademas del conjunto de parametros de secuencia SPS. En el DPS se transmiten los mismos parametros para multiples capas y en el SPS se transmiten parametros que son validos solo para una capa especffica. La invencion esta definida en la reivindicacion adjunta, a la cual se deberfa hacer referencia en este punto.
SUMARIO
En general, esta divulgacion describe tecnicas para codificar conjuntos de parametros y unidades de capa de abstraccion de red (NAL) para codificacion de video. Estas tecnicas pueden aplicarse a datos codificados de capa unica, tales como datos de video bidimensionales, asf como a datos de video de codificacion de video escalable (SVC) y datos de video de codificacion de video multivista (MVC). De este modo, los conjuntos de parametros y las unidades NAL pueden ser mutuamente compatibles entre diversos tipos de datos de video. Por ejemplo, un
5
10
15
20
25
30
35
40
45
50
55
60
65
codificador de video, tal como un codificador de video o descodificador de video, puede codificar un conjunto de parametros de video (VPS) que define parametros para una pluralidad de capas de datos de video. Las capas pueden corresponder, por ejemplo, a capas SVC (que tienen varias velocidades de trama, resoluciones espaciales y/o niveles de calidad) y/o vistas de datos MVC (por ejemplo, secuencias de imagenes de una escena capturada desde varias perspectivas de camara sobre un eje horizontal).
En un ejemplo, un procedimiento de codificacion de datos de video incluye codificar un conjunto de parametros de video (VPS) para una pluralidad de capas de datos de video, en el que cada una de la pluralidad de capas de datos de video se refiere al VPS y codificar una pluralidad de capas de datos de video basadas al menos en parte en el VPS, y en el que la codificacion del VPS comprende:
codificacion de datos del VPS indicativos de un numero maximo de capas temporales en la pluralidad de capas de datos de video.
En otros ejemplos, se proporciona un dispositivo correspondiente al procedimiento anterior y un medio de almacenamiento legible por ordenador que ha almacenado en el instrucciones que, cuando se ejecutan, realizan el procedimiento anterior.
Los detalles de uno o mas ejemplos se exponen en los dibujos adjuntos y en la siguiente descripcion. Otras caracterfsticas, objetos y ventajas resultaran evidentes a partir de la descripcion y los dibujos, y a partir de las reivindicaciones.
BREVE DESCRIPCION DE LOS DIBUJOS
La FIG. 1 es un diagrama de bloques que ilustra un sistema de codificacion y descodificacion de video de ejemplo que puede utilizar tecnicas para codificar conjuntos de parametros y unidades de capa de abstraccion de red (NAL) para una o mas capas de datos de video
La FIG. 2 es un diagrama de bloques que ilustra un ejemplo del codificador de video 20 que puede implementar las tecnicas de codificacion de conjuntos de parametros y unidades NAL para una o mas capas de datos de video.
La FIG. 3 es un diagrama de bloques que ilustra un ejemplo del descodificador de video 30 que puede implementar tecnicas para codificacion de conjuntos de parametros y unidades NAL para una o mas capas de datos de video.
La FIG. 4 es un diagrama conceptual que ilustra un patron de prediccion de MVC a modo de ejemplo.
La FIG. 5 es un diagrama conceptual que ilustra un conjunto de parametros de video (VPS) y varios conjuntos de parametros de capa (LPS).
La FIG. 6 es un diagrama conceptual que ilustra un ejemplo de un conjunto de parametros de agrupacion (GPS) y relaciones del GPS con otros conjuntos de parametros y cabeceras de fragmentos.
La FIG. 7 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video de acuerdo con las tecnicas de esta divulgacion.
La FIG. 8 es un diagrama de flujo que ilustra un ejemplo de procedimiento de descodificacion de datos de video de acuerdo con las tecnicas de esta divulgacion.
La FIG. 9 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en un cierto numero de capas temporales como se senala en un VPS.
La FIG. 10 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en un cierto numero de imagenes a reordenar en una o mas capas e imagenes a almacenar en una memoria intermedia de imagenes descodificadas.
La FIG. 11 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en parametros de descodificador de referencia hipoteticos (HRD) senalados en un VPS.
La FIG. 12 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en datos de ampliacion senalados en un VPS.
DESCRIPCION DETALLADA
En general, esta divulgacion describe la codificacion de datos de video usando un conjunto de parametros de video
5
10
15
20
25
30
35
40
45
50
55
60
65
(VPS). Los datos de video pueden clasificarse jerarquicamente como incluyendo una pluralidad de capas, una secuencia de imagenes dentro de una capa dada, una imagen dentro de una secuencia, fragmentos dentro de una imagen y bloques (por ejemplo, macrobloques o unidades de arbol de codificacion) dentro de un fragmento. Pueden usarse conjuntos de parametros de secuencia (SPS) para senalar los parametros cambiantes con poca frecuencia para una secuencia de imagenes, y se pueden usar conjuntos de parametros de imagen (PPS) para senalar los parametros cambiantes con poca frecuencia de las imagenes individuales.
De acuerdo con las tecnicas de esta divulgacion, un VPS puede senalar los parametros cambiantes con poca frecuencia para una pluralidad de secuencias a traves de las capas respectivas. Es decir, un VPS puede incluir parametros para un conjunto de secuencias temporalmente coubicadas de capas diferentes. Diferentes capas pueden incluir, por ejemplo, vistas diferentes para datos de video multivista, capas de diferentes calidades, capas de resolucion espacial diferentes, capas escalables temporalmente (es decir, capas que permiten diferentes velocidades de trama) y similares. De esta manera, se puede proporcionar un VPS para una pluralidad de capas diferentes, de manera que el VPS senale los parametros que son comunes a cada una de las capas respectivas (por ejemplo, secuencias respectivas dentro de las capas respectivas). Se puede decir que un flujo de bits incluye cada una de la pluralidad de capas, y las capas respectivas pueden formar flujos secundarios de bits respectivos. Ademas, un flujo secundario de bits puede corresponder a una combinacion de dos o mas capas.
Esta divulgacion describe varios ejemplos de datos que pueden incluirse en un VPS. Dichos datos pueden incluir, en algunos ejemplos, una indicacion de un cierto numero de subcapas (por ejemplo, un numero maximo de subcapas) dentro de las capas correspondientes. Por ejemplo, un VPS puede incluir datos que senalan un cierto numero de capas temporales y/o un numero maximo de capas temporales (por ejemplo, un identificador de capa temporal mas alto).
Para mencionar otro ejemplo, un VPS puede incluir, adicionalmente o de forma alternativa, datos sustancialmente similares a cualquier dato previamente senalado en un SPS (es decir, senalado en SPS convencionales). De esta manera, cuando las secuencias de dos o mas capas de un flujo de bits incluyen parametros sustancialmente similares o identicos, un codificador de video puede codificar un VPS para senalar parametros para las secuencias de las capas, en lugar de codificar redundantemente dichos datos en SPS respectivos para las diversas secuencias entre las diferentes capas.
Un VPS puede, adicionalmente o de forma alternativa, incluir datos que definen informacion de usabilidad de video (VUI), tales como informacion de representacion de video, parametros de descodificador de referencia hipoteticos (HRD) y/o informacion de restriccion del flujo de bits. La informacion de restriccion del flujo de bits puede incluir restricciones en el rango del vector de movimiento, el tamano de la memoria intermedia de imagenes descodificadas (DPB) (por ejemplo, en terminos de un cierto numero de imagenes que se mantendran en la DPB), el numero de tramas de reordenacion (es decir, una indicacion de un cierto numero de tramas a ser reordenadas del orden de descodificacion al orden de visualizacion), tamanos codificados de bloques (por ejemplo, macrobloques (MBs) o unidades de arbol de codificacion) y tamanos codificados de imagenes. Un VPS puede proporcionar datos adicionales para una o mas ampliaciones del VPS, de manera que el VPS pueda ampliarse mediante futuras normas o ampliaciones de la proxima norma HEVC.
La FIG. 1 es un diagrama de bloques que ilustra un sistema de codificacion y descodificacion de video de ejemplo 10 que puede utilizar tecnicas para codificar conjuntos de parametros y unidades de capa de abstraccion de red (NAL) para una o mas capas de datos de video. Como se muestra en la FIG. 1, el sistema 10 incluye un dispositivo fuente 12 que proporciona datos de video codificados, a descodificar en un momento posterior mediante un dispositivo de destino 14. En particular, el dispositivo fuente 12 proporciona los datos de video al dispositivo de destino 14 a traves de un medio legible por ordenador 16. El dispositivo fuente 12 y el dispositivo de destino 14 pueden comprender cualquiera entre una amplia gama de dispositivos, incluyendo ordenadores de sobremesa, ordenadores plegables (es decir, portatiles), ordenadores de tableta, descodificadores, equipos telefonicos de mano tales como los denominados telefonos “inteligentes”, los denominados paneles “inteligentes”, televisores, camaras, dispositivos de visualizacion, reproductores de medios digitales, consolas de videojuegos, un dispositivo de transmision de video o similares. En algunos casos, el dispositivo fuente 12 y el dispositivo de destino 14 pueden estar equipados para la comunicacion inalambrica.
El dispositivo de destino 14 puede recibir los datos de video codificados que se van a descodificar mediante el medio legible por ordenador 16. El medio legible por ordenador 16 puede comprender cualquier tipo de medio o dispositivo capaz de desplazar los datos de video codificados desde el dispositivo fuente 12 al dispositivo de destino 14. En un ejemplo, el medio legible por ordenador 16 puede comprender un medio de comunicacion para permitir al dispositivo fuente 12 transmitir datos de video codificados directamente al dispositivo de destino 14 en tiempo real. Los datos de video codificados pueden ser modulados de acuerdo con una norma de comunicacion, tal como un protocolo de comunicacion inalambrica, y transmitidos al dispositivo de destino 14. El medio de comunicacion puede comprender cualquier medio de comunicacion inalambrico o cableado, tal como un espectro de radiofrecuencia (RF) o una o mas lfneas de transmision ffsica. El medio de comunicacion puede formar parte de una red basada en paquetes, tal como una red de area local, una red de area extensa o una red global tal como Internet. El medio de comunicacion puede incluir enrutadores, conmutadores, estaciones base o cualquier otro equipo que pueda ser util para facilitar la
5
10
15
20
25
30
35
40
45
50
55
60
65
comunicacion desde el dispositivo fuente 12 al dispositivo de destino 14.
En algunos ejemplos, pueden emitirse datos codificados desde la interfaz de salida 22 hasta un dispositivo de almacenamiento. De forma similar, se puede acceder a los datos codificados del dispositivo de almacenamiento mediante una interfaz de entrada. El dispositivo de almacenamiento puede incluir cualquiera entre una diversidad de medios de almacenamiento de datos, de acceso distribuido o local, tales como una unidad de disco rfgido, discos Blu-ray, discos DVD, discos CD-ROM, memoria flash, memoria volatil o no volatil, u otros medios adecuados cualesquiera de almacenamiento digital, para almacenar datos de video codificados. En un ejemplo adicional, el dispositivo de almacenamiento puede corresponder a un servidor de ficheros o a otro dispositivo de almacenamiento intermedio que pueda almacenar los datos de video codificados, generados por el dispositivo fuente 12. El dispositivo de destino 14 puede acceder a datos de video almacenados del dispositivo de almacenamiento, mediante flujo o descarga. El servidor de ficheros puede ser cualquier tipo de servidor capaz de almacenar datos de video codificados y transmitir esos datos de video codificados al dispositivo de destino 14. Los servidores de ficheros a modo de ejemplo incluyen un servidor de Internet (por ejemplo, para una sede en la Red), un servidor del FTP, dispositivos de almacenamiento conectados a la red (NAS) o un controlador de disco local. El dispositivo de destino 14 puede acceder a los datos de video codificado a traves de cualquier conexion de datos estandar, incluyendo una conexion a Internet. Esto puede incluir un canal inalambrico (por ejemplo, una conexion de Wi-Fi), una conexion por cable (por ejemplo, DSL, modem de cable, etc.), o una combinacion de ambos que sea adecuada para acceder a datos de video codificado, almacenados en un servidor de ficheros. La transmision de datos de video codificados desde el dispositivo de almacenamiento puede ser una transmision por flujo, una transmision de descarga o una combinacion de ambas.
Las tecnicas de esta divulgacion no estan limitadas necesariamente a aplicaciones o configuraciones inalambricas. Las tecnicas pueden aplicarse a la codificacion de video, en soporte de cualquiera entre una diversidad de aplicaciones de multimedios, tales como difusiones de television por el aire, transmisiones de television por cable, transmisiones de television por satelite, transmisiones de video por flujo de Internet, tales como el flujo adaptativo dinamico sobre HTTP (DASH), video digital que se codifica en un medio de almacenamiento de datos, descodificacion de video digital almacenado en un medio de almacenamiento de datos, u otras aplicaciones. En algunos ejemplos, el sistema 10 puede configurarse para dar soporte a la transmision de video unidireccional o bidireccional, para prestar soporte a aplicaciones tales como la transmision de video, la reproduccion de video, la difusion de video y/o la videotelefonfa.
En el ejemplo de la FIG. 1, el dispositivo fuente 12 incluye una fuente de video 18, un codificador de video 20 y una interfaz de salida 22. El dispositivo de destino 14 incluye una interfaz de entrada 28, un descodificador de video 30 y un dispositivo de visualizacion 32. De acuerdo con esta divulgacion, el codificador de video 20 del dispositivo fuente 12 puede estar configurado para aplicar las tecnicas de codificacion por entropfa conjuntos de parametros y unidades NAL para una o mas capas de datos de video. En otros ejemplos, un dispositivo fuente y un dispositivo de destino pueden incluir otros componentes o disposiciones. Por ejemplo, el dispositivo fuente 12 puede recibir datos de video desde una fuente de video externa 18 como una camara externa. Asimismo, el dispositivo destino 14 puede interactuar con un dispositivo de visualizacion externo, en lugar de incluir un dispositivo de visualizacion integrado.
El sistema ilustrado 10 de la figura 1 es simplemente un ejemplo. Las tecnicas para codificar conjuntos de parametros y unidades NAL para una o mas capas de datos de video pueden ser realizadas por cualquier dispositivo de codificacion y/o descodificacion de video digital. Aunque, en general, las tecnicas de esta divulgacion se llevan a cabo mediante un dispositivo de codificacion de video, las tecnicas tambien pueden llevarse a cabo mediante un codificador/descodificador de video, denominado tfpicamente "CODEC". Ademas, las tecnicas de esta divulgacion tambien pueden llevarse a cabo mediante un preprocesador de video. El dispositivo fuente 12 y el dispositivo de destino 14 son simplemente ejemplos de tales dispositivos de codificacion, donde el dispositivo fuente 12 genera datos de video codificados para su transmision al dispositivo de destino 14. En algunos ejemplos, los dispositivos 12, 14 pueden funcionar de manera esencialmente simetrica, de modo que cada uno de los dispositivos 12, 14 incluya componentes de codificacion y de descodificacion de video. Por lo tanto, el sistema 10 puede dar soporte a una transmision de video unidireccional o bidireccional entre los dispositivos de video 12, 14, por ejemplo, para la transmision de video, la reproduccion de video, la radiodifusion de video o la videotelefonfa.
La fuente de video 18 del dispositivo fuente 12 puede incluir un dispositivo de captura de video, como una camara de video, un archivo de video que contiene video grabado previamente y/o una interfaz de alimentacion de video para recibir video de un proveedor de contenido de video. Como una alternativa adicional, la fuente de video 18 puede generar datos basados en graficos de ordenador como el video de origen, o una combinacion de video en directo, video archivado y video generado por ordenador. En algunos casos, si la fuente de video 18 es una videocamara, el dispositivo fuente 12 y el dispositivo de destino 14 pueden formar los denominados telefonos con camara o videotelefonos. Sin embargo, como se ha mencionado anteriormente, las tecnicas descritas en esta divulgacion pueden ser aplicables a la codificacion de video en general, y pueden aplicarse a aplicaciones inalambricas y/o cableadas. En cada caso, el video grabado, pregrabado o generado por ordenador puede ser codificado por el codificador de video 20. La informacion de video codificada puede ser entonces emitida por la interfaz de salida 22 en un medio legible por ordenador 16.
5
10
15
20
25
30
35
40
45
50
55
60
65
El medio legible por ordenador 16 puede incluir medios transitorios, tales como una emision inalambrica o una transmision de red cableada, o medios de almacenamiento (es decir, medios de almacenamiento no transitorio), tales como un disco duro, una unidad de memoria flash, un disco compacto, un disco de video digital, un disco Blu- ray u otro medio legible por ordenador. En algunos ejemplos, un servidor de red (no se muestra) puede recibir datos de video codificados desde el dispositivo fuente 12 y proporcionar los datos de video codificados al dispositivo de destino 14, por ejemplo, mediante transmision por red. De manera similar, un dispositivo informatico de una instalacion de produccion de un medio, como una instalacion de grabacion de discos, puede recibir datos de video codificados desde el dispositivo fuente 12 y producir un disco que contiene los datos de video codificados. Por lo tanto, puede entenderse que el medio legible por ordenador 16 incluye uno o mas medios legibles por ordenador de varias formas, en varios ejemplos.
La interfaz de entrada 28 del dispositivo de destino 14 recibe informacion desde el medio legible por ordenador 16. La informacion del medio legible por ordenador 16 puede incluir informacion sintactica definida por el codificador de video 20, que tambien es usada por el descodificador de video 30, que incluye elementos sintacticos que describen caracterfsticas y/o el procesamiento de bloques y otras unidades codificadas, por ejemplo, grupos de imagenes (GOP). El dispositivo de visualizacion 32 muestra los datos de video descodificados a un usuario y puede comprender cualquiera entre una variedad de dispositivos de visualizacion, tales como un tubo de rayos catodicos (CRT), una pantalla de cristal lfquido (LCD), una pantalla de plasma, una pantalla de diodos organicos emisores de luz (OLED) u otro tipo de dispositivo de visualizacion.
El codificador de video 20 y el descodificador de video 30 pueden funcionar de acuerdo con una norma de compresion de video, tal como la norma de codificacion de video de alta eficacia (HEVC), actualmente en fase de elaboracion, y pueden ajustarse al modelo de prueba HEVC (HM). De forma alternativa, el codificador de video 20 y el descodificador de video 30 pueden funcionar de acuerdo con otras normas privadas o industriales, tales como la norma ITU-T H.264, tambien denominada MPEG -4, Parte 10, codificacion de video avanzada (AVC) o ampliaciones de dichas normas. Sin embargo, las tecnicas de esta divulgacion no estan limitadas a ninguna norma de codificacion particular. Otros ejemplos de normas de codificacion de video incluyen MPEG-2 e ITU-T H.263. Aunque no se muestra en la FIG. 1, en algunos aspectos, el codificador de video 20 y el descodificador de video 30 pueden estar integrado, cada uno de ellos, con un codificador y descodificador de audio, y pueden incluir unidades adecuadas de multiplexado y demultiplexado, u otro hardware y software, para gestionar la codificacion, tanto de audio como de video, en un flujo de datos comun o en flujos de datos diferentes. Si procede, las unidades de multiplexado y demultiplexado pueden ajustarse al protocolo de multiplexado ITU H.223 o a otros protocolos, tales como el protocolo de datagramas de usuario (UDP).
La norma ITU-T H.264 / MPEG-4 (AVC) fue formulada por el Grupo de Expertos en Codificacion de Video de ITU-T (VCEG), junto al Grupo de Expertos en Pelfculas de ISO / IEC (MPEG), como el producto de una asociacion colectiva conocida como el Equipo de Video Conjunto (JVT). En algunos aspectos, las tecnicas descritas en esta divulgacion pueden ser aplicadas a dispositivos que se ajustan en general a la norma H.264. La norma H.264 se describe en la Recomendacion ITU-T H.264, Codificacion de Video Avanzada, para los servicios audiovisuales genericos, por el Grupo de Estudio de la ITU-T, con fecha de marzo de 2005, y que se puede denominar en el presente documento norma H.264 o memoria descriptiva H.264, o la norma o memoria descriptiva H.264/AVC. El Equipo de Video Conjunto (JVT) continua trabajando en ampliaciones para H.264/MPEG-4 AVC.
El codificador de video 20 y el descodificador de video 30 pueden implementarse como cualquiera entre una variedad de circuitos de codificadores adecuados, tales como uno o mas microprocesadores, procesadores de senales digitales (DSP), circuitos integrados de aplicacion especffica (ASIC), matrices de puertas programables in situ (FPGA), logica discreta, software, hardware, firmware o cualquier combinacion de estos. Cuando las tecnicas se implementan parcialmente en software, un dispositivo puede almacenar instrucciones para el software en unos medios legibles por ordenador no transitorios adecuados, y ejecutar las instrucciones en hardware mediante uno o mas procesadores que realizan las tecnicas de esta divulgacion. Tanto el codificador de video 20 como el descodificador de video 30 pueden estar incluidos en uno o mas codificadores o descodificadores, donde cualquiera de ambos puede estar integrado como parte de un codificador/descodificador (CODEC) combinado en un dispositivo respectivo.
El equipo JCT-VC esta trabajando en la elaboracion de la norma HEVC. Las actividades de normalizacion de la HEVC se basan en un modelo en evolucion de un dispositivo de codificacion de video denominado modelo de prueba HEVC (HM). El HM supone varias capacidades adicionales de los dispositivos de codificacion de video respecto a dispositivos existentes de acuerdo con, por ejemplo, la ITU-T H.264/AVC. Por ejemplo, mientras que la norma H.264 proporciona nueve modos de codificacion de intraprediccion, el HM puede proporcionar hasta treinta y tres modos de codificacion de intraprediccion.
En general, el modelo de funcionamiento del HM describe que una trama o imagen de video puede dividirse en una secuencia de bloques arbolados o unidades de codificacion de mayor tamano (LCU), que incluyen muestras tanto de luma como de croma. Los datos sintacticos de un flujo de bits pueden definir un tamano para la LCU, que es la mayor unidad de codificacion en lo que respecta al numero de pfxeles. Un fragmento incluye un cierto numero de
5
10
15
20
25
30
35
40
45
50
55
60
65
bloques arbolados consecutivos en orden de codificacion. Una trama o imagen de video puede dividirse en uno o mas fragmentos. Cada bloque arbolado puede separarse en unidades de codificacion (CU) de acuerdo con un arbol cuadruple. En general, una estructura de datos de arbol cuadruple incluye un nodo por CU, donde un nodo raiz corresponde al bloque arbolado. Si una CU se divide en cuatro sub-CU, el nodo correspondiente a la CU incluye cuatro nodos hoja, cada uno de los cuales corresponde a una de las sub-CU.
Cada nodo de la estructura de datos de arbol cuadruple puede proporcionar datos sintacticos para la CU correspondiente. Por ejemplo, un nodo en el arbol cuadruple puede incluir un indicador de division, que indica si la CU correspondiente al nodo esta dividida o no en varias sub-CU. Los elementos sintacticos de una CU pueden definirse de manera recursiva y pueden depender de si la CU esta dividida o no en varias sub-CU. Si una CU no esta dividida adicionalmente, se denomina Cu hoja. En esta divulgacion, cuatro sub-CU de una CU hoja tambien se denominaran CU hoja aunque no haya una division explicita de la CU hoja original. Por ejemplo, si una CU con un tamano de 16x16 no se divide adicionalmente, las cuatro sub-CU de tamano 8x8 tambien se denominaran CU hoja aunque la CU de tamano 16x16 no se haya dividido nunca.
Una CU tiene un proposito similar a un macrobloque de la norma H.264, excepto que una CU no tiene una distincion de tamano. Por ejemplo, un bloque arbolado puede dividirse en cuatro nodos secundarios (tambien denominados sub-CU) y cada nodo secundario puede a su vez ser un nodo principal y dividirse en otros cuatro nodos secundarios. Un nodo secundario final, no dividido, denominado un nodo hoja del arbol cuadruple, comprende un nodo de codificacion, tambien denominado CU hoja. Los datos sintacticos asociados a un flujo de bits codificado pueden definir un numero maximo de veces que puede dividirse un bloque arbolado, denominado profundidad de CU maxima, y tambien pueden definir un tamano minimo de los nodos de codificacion. Por consiguiente, un flujo de bits tambien puede definir una minima unidad de codificacion (SCU). Esta divulgacion utiliza el termino "bloque" para referirse a cualquiera entre una CU, PU o TU, en el contexto de HEVC, o a estructuras de datos similares en el contexto de otras normas (por ejemplo, macrobloques y subbloques de los mismos en H.264/AVC).
Una CU incluye un nodo de codificacion y unidades de prediccion (PU) y unidades de transformada (TU) asociadas al nodo de codificacion. Un tamano de la CU corresponde a un tamano del nodo de codificacion y debe ser de forma cuadrada. El tamano de la CU puede variar desde 8 x 8 pfxeles hasta el tamano del bloque arbolado, con un maximo de 64 x 64 pfxeles o mas. Cada CU puede contener una o mas PU y una o mas TU. Los datos sintacticos asociados a una CU pueden describir, por ejemplo, la division de la CU en una o mas PU. Los modos de division pueden diferir dependiendo de si la CU esta codificada en modo de salto o directo, codificada en modo de intraprediccion o codificada en modo de interprediccion. Las PU pueden dividirse para no tener forma cuadrada. Los datos sintacticos asociados a una CU tambien pueden describir, por ejemplo, la division de la CU en una o mas TU de acuerdo con un arbol cuadruple. Una TU puede tener forma cuadrada o no cuadrada (por ejemplo, rectangular).
La norma HEVC admite transformaciones de acuerdo con las TU, que pueden ser diferentes para diferentes CU. El tamano de las TU tfpicamente se basa en el tamano de las PU de una CU dada definida para una LCU dividida, aunque puede que no siempre sea asf. Las TU presentan tfpicamente el mismo tamano o un tamano mas pequeno que las PU. En algunos ejemplos, las muestras residuales correspondientes a una CU pueden subdividirse en unidades mas pequenas mediante una estructura de arbol cuadruple conocida como "arbol cuadruple residual" (RQT). Los nodos hoja del RQT pueden denominarse unidades de transformada (TU). Los valores de diferencias de pfxeles asociados a las TU pueden transformarse para generar coeficientes de transformada, que pueden cuantizarse.
Una CU hoja puede incluir una o mas unidades de prediccion (PU). En general, una PU representa una zona espacial correspondiente a la totalidad, o una parte de la CU correspondiente, y puede incluir datos para recuperar una muestra de referencia para la PU. Ademas, una PU incluye datos relacionados con la prediccion. Por ejemplo, cuando la PU esta codificada en intramodo, pueden incluirse datos para la PU en un arbol cuadruple residual (RQT), que pueden incluir datos que describen un modo de intraprediccion para una TU correspondiente a la PU. Para mencionar otro ejemplo, cuando la PU esta codificada en intermodo, la PU puede incluir datos que definen uno o mas vectores de movimiento para la PU. Los datos que definen el vector de movimiento para una PU pueden describir, por ejemplo, un componente horizontal del vector de movimiento, un componente vertical del vector de movimiento, una resolucion para el vector de movimiento (por ejemplo, precision de pfxeles de un cuarto o precision de pfxeles de un octavo), una imagen de referencia a la que apunta el vector de movimiento y/o una lista de imagenes de referencia (por ejemplo, la Lista 0, la Lista 1 o la Lista C) para el vector de movimiento.
Una CU hoja que tiene una o mas PU tambien puede incluir una o mas unidades de transformacion (TU). Las unidades de transformacion pueden especificarse usando una RQT (tambien denominada estructura de arbol cuadruple de TU), como la descrita anteriormente. Por ejemplo, un indicador de division puede indicar si una CU hoja esta dividida en cuatro unidades de transformacion. A continuacion, cada unidad de transformacion puede dividirse adicionalmente en mas sub-TU. Cuando una TU no esta dividida adicionalmente, puede denominarse como TU hoja. En general, en lo que respecta a la intracodificacion, todas las TU hoja que pertenecen a una CU hoja comparten el mismo modo de intraprediccion. Es decir, el mismo modo de intraprediccion se aplica en general para calcular valores predichos para todas las TU de una CU hoja. En lo que respecta a la intracodificacion, un codificador de video puede calcular un valor residual para cada TU hoja usando el modo de intraprediccion, como
5
10
15
20
25
30
35
40
45
50
55
60
65
una diferencia entre la parte de la CU correspondiente a la TU y el bloque original. Una TU no esta necesariamente limitada al tamano de una PU. De este modo, las TU pueden ser mayores o menores que una PU. En lo que respecta a la intracodificacion, una PU puede estar coubicada con una TU hoja correspondiente para la misma CU. En algunos ejemplos, el tamano maximo de una TU hoja puede corresponder con el tamano de la CU hoja correspondiente.
Ademas, las TU de las CU hoja tambien pueden asociarse a las estructuras de datos respectivas de arbol cuaternario, denominadas arboles cuaternarios residuales (RQTs) Es decir, una CU hoja puede incluir un arbol cuadruple que indica como la CU hoja esta dividida en varias TU. El nodo rafz de un arbol cuadruple de TU corresponde en general a una CU hoja, mientras que el nodo rafz de un arbol cuadruple de CU corresponde en general a un bloque arbolado (o LCU). Las TU del RQT que no estan divididas se denominan TU hoja. En general, esta divulgacion usa los terminos CU y TU para hacer referencia a una CU hoja y a una TU hoja, respectivamente, a no ser que se indique lo contrario.
Una secuencia de video incluye tfpicamente una serie de tramas o imagenes de video. Un grupo de imagenes (GOP) comprende en general una serie de una o mas de las imagenes de video. Un GOP puede incluir datos sintacticos en una cabecera del GOP, en una cabecera de una o mas de las imagenes o en otras ubicaciones, que describen un cierto numero de imagenes incluidas en el GOP. Cada fragmento de una imagen puede incluir datos sintacticos de fragmento que describen un modo de codificacion para el fragmento respectivo. Un codificador de video 20 actua tfpicamente sobre bloques de video de fragmentos de video individuales con el fin de codificar los datos de video. Un bloque de video puede corresponder a un nodo de codificacion de una CU. Los bloques de video pueden presentar tamanos fijos o variables y pueden diferir en tamano de acuerdo con una norma de codificacion especificada.
En un ejemplo, el HM admite la prediccion en diversos tamanos de PU. Suponiendo que el tamano de una CU particular sea 2Nx2N, el HM admite la intraprediccion en tamanos de PU de 2Nx2N o NxN y la interprediccion en tamanos de PU simetricos de 2Nx2N, 2NxN, Nx2N o NxN. El HM tambien admite la division asimetrica para la interprediccion en tamanos de PU de 2NxnU, 2NxnD, nLx2N y nRx2N. En la division asimetrica, una direccion de una CU no esta dividida, mientras que la otra direccion esta dividida en 25 % y 75 %. La parte de la CU correspondiente a la division de 25 % esta indicada por una “n” seguida de una indicacion “arriba”, “abajo”, “izquierda” o “derecha”. Asf, por ejemplo, “2NxnU” se refiere a una CU 2Nx2N que esta dividida horizontalmente con una PU 2Nx0,5N encima y una pU 2Nx1,5N debajo.
En esta divulgacion, "NxN" y "N por N" pueden usarse indistintamente para hacer referencia a las dimensiones de pfxeles de un bloque de video en terminos de dimensiones verticales y horizontales, por ejemplo, 16x16 pfxeles o 16 por 16 pfxeles. En general, un bloque de tamano 16 x 16 tendra 16 pfxeles en la direccion vertical (y = 16) y 16 pfxeles en la direccion horizontal (x = 16). Asimismo, un bloque de tamano NxN presenta en general N pfxeles en una direccion vertical y N pfxeles en una direccion horizontal, donde N representa un valor entero no negativo. Los pfxeles en un bloque pueden estar dispuestos en filas y columnas. Ademas, los bloques no necesitan presentar necesariamente el mismo numero de pfxeles en la direccion horizontal y en la direccion vertical. Por ejemplo, los bloques pueden comprender NxM pfxeles, donde M no es necesariamente igual a N.
Tras la codificacion de intraprediccion o interprediccion mediante las PU de una CU, el codificador de video 20 puede calcular datos residuales para las TU de la CU. Las PU pueden comprender datos sintacticos que describen un procedimiento o modo de generacion de datos de pfxeles predictivos en el dominio espacial (tambien denominado como el dominio de pfxeles) y las TU pueden comprender coeficientes en el dominio de transformacion, tras la aplicacion de una transformacion, por ejemplo, una transformacion de coseno discreta (DCT), una transformacion entera, una transformacion de ondfculas o una transformacion conceptualmente similar, a los datos de video residuales. Los datos residuales pueden corresponder a diferencias de pfxeles entre pfxeles de la imagen no codificada y valores de prediccion correspondientes a las PU. El codificador de video 20 puede formar las TU incluyendo los datos residuales para la CU, y a continuacion transformar las TU para generar coeficientes de transformada para la CU.
Tras cualquier transformada para generar coeficientes de transformada, el codificador de video 20 puede realizar la cuantizacion de los coeficientes de transformada. La cuantizacion se refiere en general a un proceso en el que los coeficientes de transformada se cuantizan para reducir posiblemente la cantidad de datos usados para representar los coeficientes, proporcionando una compresion adicional. El proceso de cuantizacion puede reducir la profundidad de bits asociada a algunos o la totalidad de los coeficientes. Por ejemplo, un valor de n bits puede redondearse por lo bajo a un valor de m bits durante la cuantizacion, donde n es mayor que m.
Despues de la cuantizacion, el codificador de video puede escanear los coeficientes de transformacion, produciendo un vector unidimensional a partir de la matriz bidimensional que incluye los coeficientes de transformada cuantizados. La exploracion puede estar disenada para colocar coeficientes de energfa mas alta (y por lo tanto de menor frecuencia) en la parte frontal de la matriz y para colocar coeficientes de energfa mas bajos (y por lo tanto de mayor frecuencia) en la parte posterior de la matriz. En algunos ejemplos, el codificador de video 20 puede usar un orden de exploracion predefinido para explorar los coeficientes de transformada cuantizados y generar un vector en
5
10
15
20
25
30
35
40
45
50
55
60
65
serie que pueda someterse a la codificacion por entropfa. En otros ejemplos, el codificador de video 20 puede realizar una exploracion adaptativa. Despues de explorar los coeficientes de transformada cuantizados para formar un vector unidimensional, el codificador de video 20 puede realizar la codificacion por entropfa del vector unidimensional, por ejemplo, de acuerdo con la codificacion de longitud variable adaptativa de acuerdo con el contexto (CAVLC), la codificacion aritmetica binaria adaptativa de acuerdo con el contexto (CABAC), la codificacion aritmetica binaria adaptativa de acuerdo con el contexto basada en la sintaxis (SBAC), la codificacion por entropfa por division de intervalos de probabilidad (PIPE) u otros procedimientos de codificacion por entropfa. El codificador de video 20 tambien puede realizar la codificacion por entropfa de elementos sintacticos asociados a los datos de video codificados para su uso por el descodificador de video 30 en la descodificacion de los datos de video.
Para realizar la CABAC, el codificador de video 20 puede asignar un contexto de un modelo contextual a un sfmbolo que se va a transmitir. El contexto puede referirse, por ejemplo, a si los valores contiguos del sfmbolo son distintos de cero o no. Para realizar la CAVLC, el codificador de video 20 puede seleccionar un codigo de longitud variable para un sfmbolo que se va a transmitir. Las palabras de codigo en la VLC pueden construirse de forma que los codigos relativamente mas cortos correspondan a sfmbolos mas probables, mientras que los codigos mas largos correspondan a sfmbolos menos probables. De esta manera, el uso de la VLC puede permitir un ahorro en bits con respecto, por ejemplo, al uso de palabras de codigo de igual longitud para cada sfmbolo que se va a transmitir. La determinacion de la probabilidad puede basarse en un contexto asignado al sfmbolo.
De acuerdo con las tecnicas de esta divulgacion, se puede configurar un codificador de video, como un codificador de video 20 o un descodificador de video 30, para codificar un conjunto de parametros de video (VPS) en una o mas capas de datos de video y para codificar una o mas capas de datos de video basandose, al menos en parte, en el VPS. Las tablas 2 y 5, descritas con mas detalle a continuacion, incluyen conjuntos de ejemplos de elementos sintacticos de un VPS. Cada una, o mas, de las capas de datos de video puede referirse al VPS, es decir, al mismo VPS. En otras palabras, el VPS puede aplicarse a todas las capas de un conjunto comun de datos de video, por ejemplo, todas las capas SVC y/o todas las vistas de datos de video MVC.
El VPS puede incluir diversas categorfas de informacion. Por ejemplo, el VPS puede incluir una descripcion de contador de dimension de muestra (SDCD). Es decir, para cada dimension, el codificador de video puede senalar un conjunto de indices. Las dimensiones posibles incluyen cnt_p: numero de capas prioritarias contenidas en la secuencia de video codificada; cnt_d: cuantas capas de dependencia diferentes en el flujo de bits, multiples capas con la misma resolucion espacial y profundidad de bits pueden pertenecer a diferentes capas de dependencia; cnt_t: cuantas capas temporales en el flujo de bits; cnt_q: numero maximo de capas de calidad para cualquier capa de dependencia en el flujo de bits; y cnt_v: numero maximo de vistas. Los ajustes de profundidad de bits pueden incluir 8 bits o 12 bits y pueden ser diferentes para diferentes componentes de color. Los formatos de muestreo de croma pueden incluir 4:0:0, 4:2:0 y 4:4:4.
El VPS tambien puede incluir un fndice de muestra para la asignacion de caracterfsticas. Si para cada dimension el indicador de caracterfsticas no es igual a un fndice que varfa de 0 al contador de dimensiones de muestra menos 1, se puede introducir un bucle que especifica el indicador de caracterfsticas para cada fndice de caracterfsticas. La asignacion puede incluir, para cada fndice de dependencia, una resolucion espacial especifica con un valor de profundidad de bits especifico y un formato de muestra cromatica especffico. Observese que esto puede omitirse si siempre hay una tabla fija de busqueda en el descodificador, por ejemplo, 0 puede corresponder a 4:2:0, 1 puede corresponder a 4:4:4 y 2 puede corresponder a 4:0:0. La asignacion puede incluir adicionalmente, o de forma alternativa: para cada id / fndice temporal, una velocidad de tramas especifica o velocidad de tramas media; para cada fndice de vista, un id de vista especffico; para cada fndice de profundidad de bits, un par de valores de profundidad de bits especfficos para luma y croma; y para cada formato de muestreo de croma, un indicador de formato de muestreo de croma especffico.
El VPS tambien puede incluir parametros de control e indicadores de habilitacion / deshabilitacion de herramientas, tales como los siguientes: un pcm_bit_depth_luma_minus1, un pcm_bit_depth_chroma_minus1, un loop_filter_across_slice_flag, un pcm_loop_filter_disable_flag, un temporal_id_nesting_flag, uno o mas elementos sintacticos relacionados con componentes, un chroma_pred_from_luma_enabled_flag, un sample_adaptive_offset_enabled_flag, un adaptive_loop_filter_enabled_flag , y un inter_4x4_enabled_flag.
El VPS tambien puede incluir una o mas descripciones de punto de operacion. Los puntos de operacion en general describen un subconjunto de un numero total de vistas de datos de video incluidos en un flujo de bits. Un punto de operacion puede incluir un numero particular de vistas dirigidas a la salida, asf como otras vistas que se pueden usar como referencia cuando se descodifican, se emiten o ambas cosas. Un flujo de bits puede incluir uno o mas puntos de operacion descritos por las descripciones de punto de operacion. Las descripciones de punto de operacion pueden incluir informacion que define un cierto numero de puntos de operacion maximos, dependencia entre capas o vistas diferentes, perfil y nivel para cada punto de operacion, velocidad de bits para cada punto de operacion, dependencia entre puntos de operacion, para cada punto de operacion, otras restricciones, para cada punto de operacion, informacion de usabilidad de video (VUI) o parte de VUl, y/o para cada capa o vista, VUI o parte de VUI. Ademas, o de forma alternativa, las descripciones de punto de operacion pueden incluir, para cada punto de operacion, una representacion de unidad de capa de abstraccion de red (NAL) de capa de codificacion de video
5
10
15
20
25
30
35
40
45
50
55
60
65
(VCL) de punto de operacion. En algunos ejemplos, la representacion de unidad VCL NAL de punto de operacion puede incluir, para cada dimension, tres opciones posibles: (1) un valor de fndice especffico: por ejemplo, para la resolucion espacial, para la profundidad de bits en el formato de muestreo de croma; (2) un rango del valor del fndice: por ejemplo, para capas temporales, de 0 al id de capa temporal mas alta, para capas de calidad, de 0 al id de capa de calidad mas alta; o (3) una lista de valores de fndice, por ejemplo, para vistas, una lista de valores de fndice de vista.
En algunos ejemplos, el VPS puede incluir datos indicativos de un numero maximo de capas temporales entre capas de un flujo de bits. Es decir, el codificador de video 20 y/o el descodificador de video 30 pueden configurarse para codificar un VPS que incluye datos indicativos de un numero maximo de capas temporales para un flujo de bits correspondiente. Por ejemplo, el codificador de video 20 puede determinar un numero maximo de capas temporales y codificar el VPS para incluir datos que representan el numero maximo determinado de capas temporales, mientras que el descodificador de video 30 puede descodificar el VPS para determinar el numero maximo de capas temporales. El codificador de video 20 y el descodificador de video 30 tambien pueden codificar datos de video del flujo de bits basandose en el numero maximo determinado de capas temporales. Por ejemplo, el numero maximo de capas temporales puede influir en un cierto numero de identificadores temporales que son necesarios para representar las diversas capas temporales. Para mencionar otro ejemplo, el numero maximo de capas temporales puede influir en la manera en la que el codificador de video 20 y el descodificador de video 30 codifican identificadores de una imagen de referencia, por ejemplo, usando valores de conteo de orden de imagen (POC).
Como otro ejemplo mas, el codificador de video 20 y el descodificador de video 30 pueden configurarse para codificar datos de una capa temporal particular usando solamente datos de referencia actuales e incluyendo la misma capa temporal. En otras palabras, el codificador de video 20 y el descodificador de video 30 pueden estar configurados para evitar codificar datos de una capa temporal particular usando los datos de referencia de una capa temporal superior. De esta manera, se puede asegurar que el descodificador de video 30 descodifica con exactitud datos de video de un conjunto dado de capas temporales incluso despues de la extraccion de flujo de bits secundario. Es decir, si se realiza extraccion de flujo de bits secundario, ciertas capas temporales por encima de la capa mas alta del flujo de bits secundario extrafdo no estaran disponibles como referencia. Mediante la codificacion de datos de cada capa temporal solo con referencia a datos de capas en, o por debajo, de la capa actual se pueden evitar errores que de otro modo podrfan ocurrir como consecuencia de tener datos en una capa particular dependiendo de datos de una capa superior, los cuales se perderfan como resultado de la extraccion de flujo de bits secundario.
En algunos ejemplos, el VPS, adicionalmente o de forma alternativa, incluye datos indicativos, de cualquiera o ambos, entre un cierto numero de imagenes a reordenar en una o mas capas de un flujo de bits y/o un cierto numero de imagenes a almacenar en una memoria intermedia de imagenes descodificadas (DPB). Como se ha indicado anteriormente, tales datos pueden denominarse informacion de restriccion del flujo de bits. De acuerdo con esto, el dispositivo de destino 14 puede determinar las capacidades del descodificador de video 30 y utilizar la informacion de restriccion del flujo de bits para determinar si el flujo de bits correspondiente es apropiado para ser descodificado por el descodificador de video 30, o si el dispositivo de destino 14 deberfa seleccionar contenido alternativo (por ejemplo, de un proveedor de contenido basado en red, suponiendo que estan disponibles versiones multiples del contenido).
Ademas, el codificador de video 20 y el descodificador de video 30 pueden utilizar la informacion de restriccion del flujo de bits durante la codificacion de los datos de video. Por ejemplo, el codificador de video 20 puede garantizar que no se viola la informacion de restriccion del flujo de bits. Es decir, suponiendo que la informacion de restriccion del flujo de bits indica que al menos N imagenes deben almacenarse en una DPB, el codificador de video 20 puede asegurar que no mas de N imagenes estan incluidas en cualquier combinacion de una o mas listas de imagenes de referencia en un momento dado . Para mencionar otro ejemplo, suponiendo que la informacion de reordenacion de imagen indica que una imagen debe ser desplazada por, al menos, M imagenes, el codificador de video 20 puede asegurar que ninguna imagen se desplace mas de M imagenes. El cambio de imagenes de esta manera, en general, se corresponde con la diferencia entre el orden de descodificacion y el orden de visualizacion de una imagen. El descodificador de video 30, asimismo, puede utilizar dicha informacion durante la codificacion, por ejemplo, para realizar la gestion DPB, tal como el lavado con DPB. El codificador de video 20 y el descodificador de video 30 pueden tambien utilizar informacion de restriccion del flujo de bits, tal como el numero maximo de imagenes que se van a almacenar en el DPB y/o el numero de imagenes a reordenar, al codificar los valores de identificador de la imagen de referencia.
En algunos ejemplos, el VPS, adicionalmente o de forma alternativa, incluye datos indicativos de parametros de descodificador de referencia hipoteticos (HRD). Los parametros HRD incluyen, por ejemplo, datos que describen tiempos en los que se deben eliminar datos de una memoria intermedia de imagenes codificadas (CPB). En los descodificadores, tales como el descodificador de video 30, la CPB representa una memoria intermedia en la que se almacenan datos de video codificados hasta que los datos estan listos para la descodificacion. Los descodificadores tales como el descodificador de video 30 pueden incluir tambien una memoria intermedia de imagenes descodificadas (DPB), en el que se almacenan datos de video descodificados, por ejemplo, para usarse como datos de referencia de datos interpredichos y para reordenar imagenes de un orden de descodificacion a un orden de
5
10
15
20
25
30
35
40
45
50
55
60
65
visualizacion.
Los parametros HRD pueden incluir datos que indican cuando se deben eliminar las imagenes particulares de la CPB y descodificarlas. De este modo, el codificador de video 20 puede codificar los parametros de HRD del VPS para indicar cuando las imagenes pueden ser eliminadas de la CPB y descodificadas, mientras que el descodificador de video 30 puede descodificar los parametros de HRD del VPS para determinar cuando eliminar las imagenes de la CPB. Del mismo modo, el codificador de video 20 y el descodificador de video 30 pueden codificar imagenes de acuerdo con los parametros de HRD, por ejemplo, en un orden de codificacion indicado por los parametros de HRD. De esta manera, el codificador de video 20 y/o el descodificador de video 30 pueden configurarse para codificar un VPS que incluye parametros de HRD y para codificar datos de video correspondientes a los VPS basandose, al menos en parte, en los parametros de HRD.
El VPS tambien puede incluir datos de ampliacion que indican si el VPS se ha ampliado, por ejemplo, para proporcionar datos de una o mas herramientas de codificacion adicionales. Dichas herramientas de codificacion pueden ser herramientas que son diferentes de las de una norma de codificacion de video correspondiente, tal como, por ejemplo, ITU-T H.264/AVC o la proxima norma HEVC. Ademas, tales herramientas de codificacion pueden requerir datos de configuracion. Estos datos de configuracion pueden proporcionarse en los datos de ampliacion de un VPS. De esta manera, al codificar datos de video usando tales herramientas de codificacion, el codificador de video 20 y/o descodificador de video 30 pueden codificar un VPS que indica si hay datos de ampliacion y, si es asf, datos de ampliacion del VPS. Ademas, cuando tales datos de ampliacion estan presentes, el codificador de video 20 y/o el descodificador de video 30 pueden ejecutar las herramientas de codificacion correspondientes para codificar los datos de video usando los datos de ampliacion.
Varias normas de codificacion de video definen la sintaxis, la semantica y el proceso de descodificacion correspondientes a los flujos de bits libres de errores, cualquiera de los cuales se ajustan a cierto perfil o nivel. Las normas de codificacion de video en general no especifican el codificador, pero el codificador tiene la tarea de garantizar que los flujos de bits generados sean compatibles con un descodificador. En el contexto de las normas de codificacion de video, un "perfil" corresponde a un subconjunto de algoritmos, caractensticas o herramientas y restricciones que se les aplican. Como se define en la norma H.264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits especificada por la norma H.264. Un "nivel" corresponde a las limitaciones del consumo de recursos del descodificador, tales como, por ejemplo, memoria de descodificador y calculo, que estan relacionadas con la resolucion de las imagenes, velocidad de bits y velocidad de procesamiento de bloques. Un perfil puede ser senalado con un valor profile_idc (indicador de perfil), mientras que un nivel puede ser senalado con un valor level_idc (indicador de nivel). De acuerdo con las tecnicas de esta divulgacion, la informacion de perfil y nivel se puede especificar en las descripciones de punto de operacion, tal como se ha analizado anteriormente.
En algunos ejemplos, cada capa o vista de un flujo de bits se refiere al conjunto de parametros de video (VPS), y un conjunto de parametros de secuencia de capas (LPS) puede estar activo para cada capa. Un LPS puede mantenerse lo mas ligero posible haciendo referencia al VPS en el diseno. El LPS puede incluir cualquiera o toda la informacion analizada a continuacion. El LPS puede incluir una indicacion de dimension de muestra que indica, para cada dimension, un mdice para cada dimension. Por ejemplo, si en un VPS, se asigna un mdice de resolucion espacial 0 a una caractenstica espacial de 320x240 y se asigna un mdice de resolucion espacial 1 a 640x480, y la capa actual se va a asignar con una resolucion de 640x480, el codificador de video 20 y/o el descodificador de video 30 pueden codificar un elemento sintactico con un valor de 1 para la capa actual. Es decir, el codificador de video 20 puede indicar un valor de 1 para que el elemento sintactico especifique la resolucion de 640 x 480, mientras que el descodificador de video 30 puede determinar que, una capa actual con un elemento sintactico con un valor de 1, tiene una resolucion de 640 x 480, basandose en el valor de 1 del elemento sintactico.
El LPS tambien puede incluir parametros de control e indicadores de habilitacion / deshabilitacion de herramientas. Por ejemplo, los parametros de control e indicadores de habilitacion / deshabilitacion de herramientas pueden incluir un pcm_bit_depth_luma_minus1, un pcm_bit_depth_chroma_minus1, un loop_filter_across_slice_flag, un pcm_loop_filter_disable_flag, uno o mas elementos sintacticos relacionados con componentes, un
chroma_pred_from_luma_enabled_flag, un sample_adaptive_offset_enabled_flag, un
adaptive_loop_filter_enabled_flag, y una jerarqrna de unidad de codificacion (CU).
El LPS puede incluir ademas informacion de otros tipos de conjuntos de parametros aplicables a un fragmento, un grupo de fragmentos, una imagen o varias imagenes. Cada uno de estos conjuntos de parametros puede referirse a un conjunto de parametros de imagen espedfico (PPS).
El codificador de video, tal como el codificador de video 20 y el descodificador de video 30, pueden configurarse para asegurar y/o determinar que un PPS no haga referencia a un LPS o un VPS. Por lo tanto, el codificador de video puede garantizar que cada PPS de un flujo de bits no se refiere a un LPS o un VPS. El analisis de un PPS puede ser independiente. Cuando un PPS incluye uno o mas de los mismos elementos sintacticos que los de un VPS o un LPS, los elementos sintacticos del PPS pueden sobrescribir los del VPS o LPS.
Ademas, se puede configurar un codificador de video para codificar un conjunto de parametros de agrupacion (GPS)
5
10
15
20
25
30
35
40
45
50
55
60
65
que agrupa todos los conjuntos de parametros. El codificador de video puede codificar una pluralidad de diferentes grupos dentro del GPS, cada uno de los cuales tiene identificadores (ids) de GPS individuales. Cada uno de los grupos en el GPS puede incluir una combinacion diferente de conjuntos de parametros. De esta manera, una cabecera de fragmento solo tiene que incluir una referencia a un id de GPS correspondiente y no necesita incluir una indicacion de un tipo de conjunto de parametros. La solicitud de patente provisional estadounidense numero de serie 61/590.702, presentada el 25 de enero de 2012, tambien describe tecnicas en las que se agrupan diferentes tipos de conjuntos de parametros y solo el ID del RBSP de agrupacion de conjunto de parametros se senala en la cabecera del fragmento en mayor detalle.
Como se ha analizado anteriormente, el codificador de video, tal como el codificador de video 20 o el descodificador de video 30, puede configurarse para codificar un conjunto de parametros de video y/o un conjunto de parametros de agrupacion. Los ejemplos de un conjunto de parametros de video se analizan con mayor detalle con respecto a la FIG. 5, mientras que los ejemplos de un conjunto de parametros de agrupacion se analizan con mayor detalle con respecto a la FIG. 6.
Ademas, el codificador de video 20 puede enviar datos sintacticos, tales como datos sintacticos basados en bloques, datos sintacticos basados en tramas y datos sintacticos basados en GOP, al descodificador de video 30, por ejemplo, en una cabecera de trama, una cabecera de bloque, una cabecera de fragmento o una cabecera de gOp. Los datos sintacticos de GOP pueden describir un cierto numero de tramas en el GOP respectivo, y los datos sintacticos de trama pueden indicar un modo de codificacion/prediccion usado para codificar la trama correspondiente.
El codificador de video 20 y el descodificador de video 30 pueden implementarse, cada uno, como cualquiera entre una amplia variedad de circuitos codificadores o descodificadores adecuados, segun corresponda, tales como uno o mas microprocesadores, procesadores de senales digitales (DSP), circuitos integrados especfficos de la aplicacion (ASIC), matrices de compuertas programables en el terreno (FPGA), circuitos de logica discreta, software, hardware, firmware o cualquier combinacion de los mismos. Cada uno del codificador de video 20 y el descodificador de video 30, puede estar incluido en uno o mas codificadores o descodificadores, cada uno de los cuales puede estar integrado como parte de un codificador/descodificador (CODEC) de video combinado. Un dispositivo que incluye el codificador de video 20 y/o el descodificador de video 30 puede comprender un circuito integrado, un microprocesador y/o un dispositivo de comunicacion inalambrica, tal como un telefono celular.
La FIG. 2 es un diagrama de bloques que ilustra un ejemplo del codificador de video 20 que puede implementar tecnicas para la codificacion de conjuntos de parametros y unidades NAL para una o mas capas de datos de video. El codificador de video 20 puede realizar intracodificacion e intercodificacion de bloques de video dentro de fragmentos de video. La intracodificacion se basa en la prediccion espacial para reducir o eliminar la redundancia espacial en el video dentro de una trama o imagen de video dada. La intercodificacion se basa en la prediccion temporal para reducir o eliminar la redundancia temporal en el video dentro de tramas o imagenes adyacentes de una secuencia de video. La intramodalidad (modalidad I) puede referirse a cualquiera de varias modalidades de compresion de base espacial. Los intermodos, tales como la prediccion unidireccional (modo P) o la bi-prediccion (modo B), pueden referirse a cualquiera de varios modos de codificacion de base temporal.
Como se muestra en la FIG. 2, el codificador de video 20 recibe un bloque de video actual dentro de una trama de video a codificar. En el ejemplo de la FIG. 2, el codificador de video 20 incluye una unidad de seleccion de modo 40, una memoria de imagenes de referencia 64, un sumador 50, una unidad de procesamiento de transformacion 52, una unidad de cuantizacion 54 y una unidad de codificacion por entropfa 56. A su vez, la unidad de seleccion de modo 40 incluye una unidad de compensacion de movimiento 44, una unidad de estimacion de movimiento 42, una unidad de intraprediccion 46 y una unidad de division 48. Para la reconstruccion de bloques de video, el codificador de video 20 incluye ademas una unidad de cuantizacion inversa 58, una unidad de transformacion inversa 60 y un sumador 62. Tambien puede incluirse un filtro de desbloqueo (no se muestra en la FIG. 2) para filtrar lfmites de bloque, para eliminar distorsiones de efecto pixelado del video reconstruido. Si se desea, el filtro de desbloqueo filtrara tfpicamente la salida del sumador 62. Tambien pueden usarse filtros adicionales (en bucle o pos-bucle), ademas del filtro de desbloqueo. Dichos filtros no se muestran por razones de brevedad pero, si se desea, pueden filtrar la salida del sumador 50 (tal como un filtro en bucle).
Durante el proceso de codificacion, el codificador de video 20 recibe una trama o un fragmento de video que va a codificarse. La trama o el fragmento puede estar dividido en multiples bloques de video. La unidad de estimacion de movimiento 42 y la unidad de compensacion de movimiento 44 llevan a cabo la codificacion interpredictiva del bloque de video recibido, con respecto a uno o mas bloques de una o mas tramas de referencia, para proporcionar la prediccion temporal. La unidad de intraprediccion 46, como alternativa, puede llevar a cabo la codificacion intrapredictiva del bloque de video recibido, con respecto a uno o mas bloques contiguos de la misma trama o fragmento que el bloque que va a codificarse, para proporcionar la prediccion espacial. El codificador de video 20 puede llevar a cabo multiples pasadas de codificacion, por ejemplo, para seleccionar un modo de codificacion adecuada para cada bloque de datos de video.
Ademas, la unidad de division 48 puede dividir bloques de datos de video en sub-bloques, basandose en la
5
10
15
20
25
30
35
40
45
50
55
60
65
evaluacion de los anteriores esquemas de division en las pasadas de codificacion anteriores. Por ejemplo, la unidad de division 48 puede dividir inicialmente una trama o un fragmento en varias LCU, y dividir cada una de las LCU en varias sub-CU, basandose en un analisis de distorsion de velocidad (por ejemplo, optimizacion de distorsion de velocidad). La unidad de seleccion de modo 40 puede producir ademas una estructura de datos de arbol cuadruple que indica la division de una LCU en varias sub-CU. Las CU de nodos de hojas del arbol cuadruple pueden incluir una o mas PU y una o mas TU.
La unidad de seleccion de modo 40 puede seleccionar uno de los modos de codificacion, intra o inter, por ejemplo, en funcion de los resultados de error, y proporciona el bloque intracodificado o intercodificado resultante al sumador 50 para generar datos de bloque residuales y al sumador 62 para reconstruir el bloque codificado para usarse como una trama de referencia. La unidad de seleccion de modalidad 40 proporciona ademas elementos sintacticos, tales como vectores de movimiento, indicadores de intramodalidad, informacion de division y otra informacion sintactica de este tipo, a la unidad de codificacion por entropfa 56.
La unidad de estimacion de movimiento 42 y la unidad de compensacion de movimiento 44 pueden estar sumamente integradas, pero se ilustran por separado con fines conceptuales. La estimacion de movimiento, realizada por la unidad de estimacion de movimiento 42, es el proceso de generacion de vectores de movimiento, que estiman el movimiento de los bloques de video. Un vector de movimiento, por ejemplo, puede indicar el desplazamiento de una PU de un bloque de video dentro de una trama o imagen actual de video, con respecto a un bloque predictivo dentro de una trama de referencia (u otra unidad codificada), con respecto al bloque actual que esta siendo codificado dentro de la trama actual (u otra unidad codificada). Un bloque predictivo es un bloque que se revela como estrechamente coincidente con el bloque a codificar en lo que respecta a la diferencia de pfxeles, que puede determinarse mediante la suma de una diferencia absoluta (SAD), una suma de diferencia de cuadrados (SSD) u otras metricas de diferencia. En algunos ejemplos, el codificador de video 20 puede calcular valores de posiciones de pixel subentero de las imagenes de referencia almacenadas en la memoria de imagenes de referencia 64. Por ejemplo, el codificador de video 20 puede interpolar valores de posiciones de un cuarto de pixel, posiciones de un octavo de pixel u otras posiciones de pixel fraccionarias de la imagen de referencia. Por lo tanto, la unidad de estimacion de movimiento 42 puede realizar una busqueda de movimiento con respecto a las posiciones de pixel completo y a las posiciones de pixel fraccionario, y emitir un vector de movimiento con una precision de pixel fraccionario.
La unidad de estimacion de movimiento 42 calcula un vector de movimiento para una PU de un bloque de video de un fragmento sometido a intercodificacion, comparando la posicion de la PU con la posicion de un bloque predictivo de una imagen de referencia. La imagen de referencia puede seleccionarse entre una primera lista de imagenes de referencia (lista 0) o una segunda lista de imagenes de referencia (lista 1), cada una de las cuales identifica una o mas imagenes de referencia almacenadas en la memoria de imagenes de referencia 64. La unidad de estimacion de movimiento 42 envfa el vector de movimiento calculado a la unidad de codificacion por entropfa 56 y a la unidad de compensacion de movimiento 44.
La compensacion de movimiento, llevada a cabo por la unidad de compensacion de movimiento 44, puede implicar capturar o generar el bloque predictivo basandose en el vector de movimiento determinado por la unidad de estimacion de movimiento 42. De nuevo, la unidad de estimacion de movimiento 42 y la unidad de compensacion de movimiento 44 pueden integrarse funcionalmente, en algunos ejemplos. Tras recibir el vector de movimiento para la PU del bloque de video actual, la unidad de compensacion de movimiento 44 puede localizar el bloque predictivo al que apunta el vector de movimiento en una de las listas de imagenes de referencia. El sumador 50 forma un bloque de video residual restando los valores de pixel del bloque predictivo a los valores de pixel del bloque de video actual que esta siendo codificado, generando valores de diferencia de pixel, como se analiza posteriormente. En general, la unidad de estimacion de movimiento 42 lleva a cabo la estimacion de movimiento con respecto a los componentes de luma, y la unidad de compensacion de movimiento 44 utiliza los vectores de movimiento calculados basandose en los componentes de luma, tanto para los componentes de croma como para los componentes de luma. La unidad de seleccion de modalidad 40 tambien puede generar elementos sintacticos asociados a los bloques de video y al fragmento de video para su uso por parte del descodificador de video 30 a la hora de descodificar los bloques de video del fragmento de video.
La unidad de intraprediccion 46 puede intrapredecir un bloque actual, como alternativa a la interprediccion llevada a cabo por la unidad de estimacion de movimiento 42 y la unidad de compensacion de movimiento 44, como se ha descrito anteriormente. En particular, la unidad de intraprediccion 46 puede determinar una modalidad de intraprediccion a usar para codificar un bloque actual. En algunos ejemplos, la unidad de intraprediccion 46 puede codificar un bloque actual usando varias modalidades de intraprediccion, por ejemplo, durante diferentes pasadas de codificacion, y la unidad de intraprediccion 46 (o la unidad de seleccion de modalidad 40, en algunos ejemplos) puede seleccionar una modalidad adecuada de intraprediccion a usar entre las modalidades probadas.
Por ejemplo, la unidad de intraprediccion 46 puede calcular valores de velocidad-distorsion usando un analisis de velocidad-distorsion para las diversas modalidades de intraprediccion probadas, y seleccionar la modalidad de intraprediccion que tenga las mejores caracterfsticas de velocidad-distorsion entre las modalidades probadas. El analisis de velocidad-distorsion determina en general una magnitud de distorsion (o errores) entre un bloque
5
10
15
20
25
30
35
40
45
50
55
60
65
codificado y un bloque original, no codificado, que se codifico para generar el bloque codificado, asf como una velocidad binaria (es decir, un cierto numero de bits) usada para generar el bloque codificado. La unidad de intraprediccion 46 puede calcular proporciones a partir de las distorsiones y velocidades de los diversos bloques codificados para determinar que modalidad de intraprediccion presenta el mejor valor de velocidad-distorsion para el bloque.
Despues de seleccionar una modalidad de intraprediccion para un bloque, la unidad de intraprediccion 46 puede proporcionar informacion, indicativa de la modalidad de intraprediccion seleccionada para el bloque, a la unidad de codificacion por entropfa 56. La unidad de codificacion por entropfa 56 puede codificar la informacion que indica la modalidad de intraprediccion seleccionada. El codificador de video 20 puede incluir datos de configuracion de flujo de bits transmitido, que pueden incluir una pluralidad de tablas de indices de modalidades de intraprediccion y una pluralidad de tablas de indices de modalidades de intraprediccion modificadas (tambien denominadas tablas de asignacion de palabras de codigo), definiciones de contextos de codificacion para varios bloques e indicaciones de una modalidad de intraprediccion mas probable, una tabla de indices de modalidades de intraprediccion y una tabla modificada de indices de modalidades de intraprediccion, a usar en cada uno de los contextos.
El codificador de video 20 forma un bloque de video residual restando los datos de prediccion de la unidad de seleccion de modalidad 40 a partir del bloque de video original que esta siendo codificado. El sumador 50 representa el componente o los componentes que realizan esta operacion de resta. La unidad de procesamiento de transformaciones 52 aplica una transformacion, tal como una transformacion discreta del coseno (DCT) o una transformacion conceptualmente similar al bloque residual, generando un bloque de video que comprende valores residuales de coeficientes de transformacion. La unidad de procesamiento de transformaciones 52 puede llevar a cabo otras transformaciones que son conceptualmente similares a la DCT. Tambien podrfan usarse transformaciones de ondfculas, transformaciones de enteros, transformaciones de subbandas u otros tipos de transformaciones.
En cualquier caso, la unidad de procesamiento de transformaciones 52 aplica la transformacion al bloque residual, generando un bloque de coeficientes de transformacion residuales. La transformacion puede convertir la informacion residual, desde un dominio de valores de pixel a un dominio de transformaciones, como un dominio de frecuencia. La unidad de procesamiento de transformaciones 52 puede enviar los coeficientes de transformacion resultantes a la unidad de cuantizacion 54. La unidad de cuantizacion 54 cuantiza los coeficientes de transformacion para reducir adicionalmente la velocidad de bits. El proceso de cuantizacion puede reducir la profundidad de bits asociada a algunos de, o a todos, los coeficientes. El grado de cuantizacion puede modificarse ajustando un parametro de cuantizacion. En algunos ejemplos, la unidad de cuantizacion 54 puede realizar, a continuacion, una exploracion de la matriz que incluye los coeficientes de transformada cuantizados. De forma alternativa, la unidad de codificacion por entropfa 56 puede realizar la exploracion.
Tras la cuantizacion, la unidad de codificacion por entropfa 56 codifica por entropfa los coeficientes de transformacion cuantizados. Por ejemplo, la unidad de codificacion por entropfa 56 puede llevar a cabo la codificacion de longitud variable adaptativa al contexto (CAVLC), la codificacion aritmetica binaria adaptativa al contexto (CABAC), la codificacion aritmetica binaria adaptativa al contexto y basada en sintaxis (SBAC), la codificacion por entropfa mediante la division en intervalos de probabilidades (PIPE) u otra tecnica de codificacion por entropfa. En el caso de la codificacion por entropfa basada en el contexto, el contexto puede basarse en bloques contiguos. Tras la codificacion por entropfa realizada por la unidad de codificacion por entropfa 56, el flujo de bits codificado puede transmitirse a otro dispositivo (por ejemplo, el descodificador de video 30) o archivarse para su posterior transmision o recuperacion.
La unidad de cuantizacion inversa 58 y la unidad de transformacion inversa 60 aplican la cuantizacion inversa y la transformacion inversa, respectivamente, para reconstruir el bloque residual en el dominio de pfxeles, por ejemplo, para su uso posterior como un bloque de referencia. La unidad de compensacion de movimiento 44 puede calcular un bloque de referencia anadiendo el bloque residual a un bloque predictivo de una de las tramas de la memoria de imagenes de referencia 64. La unidad de compensacion de movimiento 44 tambien puede aplicar uno o mas filtros de interpolacion al bloque residual reconstruido para calcular valores de pixel subentero y usarlos en la estimacion de movimiento. El sumador 62 anade el bloque residual reconstruido al bloque de prediccion compensado por movimiento, generado por la unidad de compensacion de movimiento 44, para generar un bloque de video reconstruido para su almacenamiento en la memoria de imagenes de referencia 64. El bloque de video reconstruido puede ser usado por la unidad de estimacion de movimiento 42 y la unidad de compensacion de movimiento 44 como un bloque de referencia para intercodificar un bloque de una trama de video posterior.
El codificador de video 20 puede configurarse adicionalmente para codificar un conjunto de parametros de video (VPS), un conjunto de parametros de capa (LPS) y/o un conjunto de parametros de agrupacion, de acuerdo con las tecnicas de esta divulgacion, asf como un conjunto de parametros de secuencia SPS), un conjunto de parametros de imagen (PPS), un conjunto de parametros de adaptacion (APS) u otras estructuras de datos de senalizacion de este tipo. Mas particularmente, la unidad de codificacion por entropfa 56 puede estar configurada para codificar cualquiera de, o todas, estas estructuras de datos. En la medida en que los parametros de estas diversas estructuras de datos pueden afectar al rendimiento de codificacion, la unidad de seleccion de modo 40 puede
5
10
15
20
25
30
35
40
45
50
55
60
65
seleccionar parametros apropiados y pasar los parametros a la unidad de codificacion por entropfa 56 para su inclusion dentro, por ejemplo, de un VPS. Un usuario, por ejemplo un administrador, puede seleccionar otros parametros, tales como un cierto numero de capas temporales, un cierto numero de imagenes a reordenar y un cierto numero de imagenes a almacenar en una memoria intermedia de imagenes descodificadas. En otros ejemplos, ciertos parametros, como los parametros HRD, pueden surgir a traves del proceso de codificacion.
La unidad de codificacion por entropfa 56 puede codificar un VPS para incluir cualquiera de, o todos, los diversos tipos de datos descritos en esta divulgacion. El codificador de video 20 tambien puede codificar datos de acuerdo con los parametros del VPS. Mas en particular, el codificador de video 20 puede codificar secuencias de imagenes entre una o mas capas de datos de video a las que corresponde el VPS de acuerdo con los parametros del VPS.
De esta manera, el codificador de video 20 de la FIG. 2 representa un ejemplo de un codificador de video configurado para codificar un conjunto de parametros de video (VPS) para una o mas capas de datos de video, en el que cada una de una o mas capas de datos de video se refiere al VPS, y codificar una o mas capas de datos de video basandose, al menos en parte, en el VPS.
Aunque en general se describe con respecto a un codificador de video, la codificacion de un VPS puede ser realizada por otros dispositivos, por ejemplo, un elemento de red de soporte de medios (MANE). Un MANE puede corresponder a un elemento de red entre un dispositivo fuente (como el dispositivo fuente 12 de la FIG. 1) y un dispositivo de destino (como el dispositivo de destino 14). El MANE puede configurarse para codificar un VPS de acuerdo con las tecnicas de esta divulgacion. El MANE puede generar el VPS utilizando datos de otras estructuras de datos recibidas por el MANE, por ejemplo, conjuntos de parametros de secuencia.
La FIG. 3 es un diagrama de bloques que ilustra un ejemplo del descodificador de video 30 que puede implementar las tecnicas de codificacion de conjuntos de parametros y unidades NAL para una o mas capas de datos de video. En el ejemplo de la FIG. 3, el descodificador de video 30 incluye una unidad de descodificacion por entropfa 70, una unidad de compensacion de movimiento 72, una unidad de intraprediccion 74, una unidad de cuantizacion inversa 76, una unidad transformada inversa 78, una memoria de imagenes de referencia 82 y un sumador 80. La memoria de imagenes de referencia 82 tambien se puede denominar "memoria intermedia de imagenes descodificadas" o DPB. En algunos ejemplos, el descodificador de video 30 puede llevar a cabo una pasada de descodificacion en general recfproca a la pasada de codificacion descrita con respecto al codificador de video 20 (FIG. 2). La unidad de compensacion de movimiento 72 puede generar datos de prediccion basados en vectores de movimiento recibidos desde la unidad de descodificacion por entropfa 70, mientras que la unidad de intraprediccion 74 puede generar datos de prediccion basados en indicadores de modalidad de intraprediccion recibidos desde la unidad de descodificacion por entropfa 70.
Durante el proceso de descodificacion, el descodificador de video 30 recibe un flujo de bits de video codificado que representa bloques de video de un fragmento de video codificado y elementos sintacticos asociados desde el codificador de video 20. La unidad de descodificacion por entropfa 70 del descodificador de video 30 descodifica por entropfa el flujo de bits para generar coeficientes cuantizados, vectores de movimiento o indicadores de modalidad de intraprediccion y otros elementos sintacticos. La unidad de descodificacion por entropfa 70 remite los vectores de movimiento y otros elementos sintacticos a la unidad de compensacion de movimiento 72. El descodificador de video 30 puede recibir los elementos sintacticos al nivel del fragmento de video y/o el nivel del bloque de video.
Cuando el fragmento de video se codifica como un fragmento intracodificado (I), la unidad de intraprediccion 74 puede generar datos de prediccion para un bloque de video del fragmento de video actual, basandose en una modalidad de intraprediccion senalada, y datos de bloques previamente descodificados de la trama o imagen actual. Cuando la trama de video se codifica como un fragmento intercodificado (es decir, B, P o GPB), la unidad de compensacion de movimiento 72 genera bloques predictivos para un bloque de video del fragmento de video actual, basandose en los vectores de movimiento y a otros elementos sintacticos recibidos desde la unidad de descodificacion por entropfa 70. Los bloques predictivos pueden ser generados a partir de una de las imagenes de referencia dentro de una de las listas de imagenes de referencia. El descodificador de video 30 puede construir las listas de tramas de referencia, la Lista 0 y la Lista 1, usando tecnicas de construccion por omision, basandose en las imagenes de referencia almacenadas en la memoria de imagenes de referencia 82.
La unidad de compensacion de movimiento 72 determina la informacion de prediccion para un bloque de video del fragmento de video actual, analizando los vectores de movimiento y otros elementos sintacticos, y usa la informacion de prediccion para generar los bloques predictivos del bloque de video actual que esta siendo descodificado. Por ejemplo, la unidad de compensacion de movimiento 72 usa algunos de los elementos sintacticos recibidos para determinar un modo de prediccion (por ejemplo, intraprediccion o interprediccion), usada para codificar los bloques de video del fragmento de video, un tipo de fragmento de interprediccion (por ejemplo, fragmento B, fragmento P o fragmento GPB), informacion de construccion para una o mas de las listas de imagenes de referencia del fragmento, vectores de movimiento para cada bloque de video intercodificado del fragmento, el estado de interprediccion para cada bloque de video intercodificado del fragmento y otra informacion para descodificar los bloques de video del fragmento de video actual.
5
10
15
20
25
30
35
40
45
50
55
60
65
La unidad de compensacion de movimiento 72 tambien puede realizar la interpolacion basandose en filtros de interpolacion. La unidad de compensacion de movimiento 72 puede usar filtros de interpolacion, como los usados por el codificador de video 20 durante la codificacion de los bloques de video, para calcular valores interpolados de pfxeles subenteros de los bloques de referencia. En este caso, la unidad de compensacion de movimiento 72 puede determinar los filtros de interpolacion usados por el codificador de video 20 a partir de los elementos sintacticos recibidos y usar los filtros de interpolacion para generar bloques predictivos.
La unidad de cuantizacion inversa 76 cuantiza de manera inversa, es decir, descuantiza, los coeficientes de transformacion cuantizados, proporcionados en el flujo de bits y descodificados por la unidad de descodificacion por entropfa 80. El proceso de cuantizacion inversa puede incluir el uso de un parametro de cuantizacion QPY, calculado por el descodificador de video 30 de cada bloque de video en el fragmento de video para determinar un grado de cuantizacion y, asimismo, un grado de cuantizacion inversa que deberfa aplicarse. La unidad de transformacion inversa 78 aplica una transformacion inversa, por ejemplo, una DCT inversa, una transformacion inversa entera o un proceso de transformacion inversa conceptualmente similar a los coeficientes de transformacion con el fin de generar bloques residuales en el dominio de pfxeles.
Despues de que la unidad de compensacion de movimiento 72 genera el bloque predictivo del bloque de video actual, basandose en los vectores de movimiento y a otros elementos sintacticos, el descodificador de video 30 forma un bloque de video descodificado sumando los bloques residuales procedentes de la unidad de transformacion inversa 78 y los correspondientes bloques predictivos generados por la unidad de compensacion de movimiento 72. El sumador 90 representa el componente o los componentes que llevan a cabo esta operacion de suma. Si se desea, tambien puede aplicarse un filtro de desbloqueo para filtrar los bloques descodificados con el fin de eliminar distorsiones de efecto pixelado. Tambien pueden utilizarse otros filtros de bucle (ya sea en el bucle de codificacion o despues del bucle de codificacion) para suavizar las transiciones de pfxeles, o mejorar de otro modo la calidad del video. Los bloques de video descodificados de una trama o imagen dada son a continuacion almacenados en la memoria de imagenes de referencia 82, que almacena imagenes de referencia usadas para la posterior compensacion de movimiento. La memoria de imagenes de referencia 82 almacena tambien video descodificado para su presentacion posterior en un dispositivo de visualizacion, tal como el dispositivo de visualizacion 32 de la FIG. 1.
De acuerdo con las tecnicas de esta divulgacion, el descodificador de video 30 puede descodificar un conjunto de parametros de video (VPS), un conjunto de parametros de capa (LPS) y/o un conjunto de parametros de agrupacion, de acuerdo con las tecnicas de esta divulgacion, asf como un conjunto de parametros de secuencia (SpS), un conjunto de parametros de imagen (PPS), un conjunto de parametros de adaptacion (APS) u otras estructuras de datos de senalizacion de este tipo. Mas particularmente, la unidad de descodificacion por entropfa 70 puede estar configurada para descodificar cualquiera de, o todas, estas estructuras de datos. Mediante la descodificacion de estas diversas estructuras de datos, la unidad 70 de descodificacion por entropfa puede determinar parametros que se utilizaran para descodificar datos de video correspondientes. Por ejemplo, el descodificador de video 30 puede descodificar secuencias correspondientes de datos de video de una o mas capas utilizando parametros de un VPS descodificado.
Aunque no se muestra en la FIG. 3, el descodificador de video 30 puede incluir adicionalmente una memoria intermedia de imagenes descodificadas (CPB). Normalmente, la CPB se proporcionarfa de forma ordinaria antes de la unidad 70 de descodificacion por entropfa. De forma alternativa, la CPB puede estar acoplada a la unidad de descodificacion por entropfa 70 para almacenamiento temporal, o a la salida de la unidad de descodificacion por entropfa 70 para almacenar datos descodificados por entropfa hasta que dichos datos se descodifiquen. En general, la CPB almacena datos de video codificados hasta que los datos de video codificados se van a descodificar, por ejemplo, como se indica mediante los parametros de HRD, que el descodificador de video 30 puede extraer de un VPS descodificado. Del mismo modo, otros elementos del descodificador de video 30 pueden estar configurados para descodificar datos de video utilizando, por ejemplo, el VPS. Por ejemplo, el descodificador de video 30 puede descodificar identificadores temporales de imagenes de varias capas temporales, datos que indican un cierto numero de imagenes a reordenar y/o almacenar en la memoria de imagenes de referencia 82 (que representa una DPB).
Ademas, el descodificador de video 30 puede incluir unidades de procesamiento adicionales para procesar datos de video de acuerdo con diversas herramientas de codificacion proporcionadas por ampliaciones de una norma de codificacion de video. De forma alternativa, los elementos existentes del descodificador de video 30 mostrado en la FIG. 3 pueden configurarse para ejecutar las herramientas de codificacion de tales ampliaciones. La unidad de descodificacion por entropfa 70 puede estar configurada para descodificar datos de ampliacion de VPS y proporcionar tales datos de ampliacion a las unidades configuradas para ejecutar las herramientas de codificacion proporcionadas por las ampliaciones.
De esta manera, el descodificador de video 30 de la FIG. 3 representa un ejemplo de un descodificador de video configurado para codificar un conjunto de parametros de video (VPS) para una o mas capas de datos de video, en el que cada una de una o mas capas de datos de video se refieren al VPS, y codificar una o mas capas de datos de video basandose al menos en parte en el VPS.
5
10
15
20
25
30
35
40
45
50
55
60
65
Aunque en general se describe con respecto a un descodificador de video, la descodificacion de un VPS puede ser realizada por otros dispositivos, por ejemplo, un elemento de red que conoce los medios (MANE). El MANE puede configurarse para descodificar un VPS de acuerdo con las tecnicas de esta divulgacion. El MANE puede generar ademas otros datos del conjunto de parametros, tales como uno o mas conjuntos de parametros de secuencia, utilizando los datos del VPS. De esta manera, el MANE puede proporcionar compatibilidad retrospectiva con las normas anteriores, tales como ITU-T H.264/AVC.
La FIG. 4 es un diagrama conceptual que ilustra un patron de prediccion de la norma MVC a modo de ejemplo. La codificacion de video multivista (MVC) es una ampliacion de ITU-T H.264/AVC. Una tecnica similar puede aplicarse a HEVC. En el ejemplo de la FIG. 4, se ilustran ocho vistas (con ID de vista "S0" a "S7") y se ilustran doce posiciones temporales ("T0" a "T11") para cada vista. Es decir, cada fila de la FIG. 4 corresponde a una vista, mientras que cada columna indica una ubicacion temporal.
Una estructura de prediccion MVC tfpica (que incluye tanto la prediccion entre imagenes dentro de cada vista como la prediccion entre vistas) para la codificacion de video multivista se muestra en la FIG. 4, donde las predicciones se indican mediante flechas, donde el objeto al que se apunta utiliza el objeto desde el que se apunta como referencia de prediccion. En MVC, la prediccion entre vistas es compatible con la compensacion de movimiento de disparidad, que puede utilizar la sintaxis de la compensacion de movimiento H.264/AVC, pero permite utilizar una imagen en una vista diferente como una imagen de referencia.
La codificacion de dos vistas tambien podrfa ser compatible con MVC, y una de las ventajas de MVC es que un codificador MVC podrfa tomar mas de dos vistas como una entrada de video 3D y un descodificador MVC puede descodificar una representacion multivista. Asf, cualquier renderizador con descodificador MVC puede estar configurado para recibir contenido de video 3D con mas de dos vistas.
Aunque MVC tiene una denominada vista de base que es descodificable mediante los descodificadores H.264/AVC y el par de vistas estereo podrfa ser compatible tambien con MVC, una ventaja de MVC es que podrfa permitir un ejemplo que usa mas de dos vistas como una entrada de video 3D y descodifica este video 3D representado por las multiples vistas. Un renderizador de un cliente que tiene un descodificador MVC puede esperar contenido de video 3D con varias vistas.
Un orden de descodificacion tfpico de MVC se denomina codificacion de primera vez. Una unidad de acceso puede incluir imagenes codificadas de todas las vistas para una instancia de tiempo de salida. Por ejemplo, cada una de las imagenes del tiempo T0 puede estar incluida en una unidad de acceso comun, cada una de las imagenes del tiempo T1 puede estar incluida en una segunda unidad de acceso comun, y asf sucesivamente. El orden de descodificacion no es necesariamente identico al orden de salida o de visualizacion.
Las tramas en la FIG. 4 se indican en la interseccion de cada fila y cada columna de la FIG. 4 usando un bloque sombreado que incluye una letra, que designa si la trama correspondiente esta intracodificada (es decir, una trama I), o intercodificada en una direccion (es decir, como una trama P) o en multiples direcciones (es decir, como una trama B). En general, las predicciones se indican mediante flechas, donde la trama a la que se apunta utiliza el objeto desde el que se apunta como referencia de prediccion. Por ejemplo, la trama P de la vista S2 en la ubicacion temporal T0 se predice a partir de la trama I de la vista S0 en la ubicacion temporal T0.
Al igual que con la codificacion de video de vista unica, las tramas de una secuencia de video de codificacion de video multivista pueden codificarse predictivamente con respecto a las tramas en diferentes ubicaciones temporales. Por ejemplo, la trama B de la vista S0 en la ubicacion temporal T1 tiene una flecha apuntando a la misma desde la trama I de la vista S0 en la ubicacion temporal T0, lo cual indica que la trama B se predice a partir de la trama I. Adicionalmente, sin embargo, en el contexto de la codificacion de video multivista, las tramas pueden predecirse entre vistas. Es decir, un componente de vista puede utilizar los componentes de vista en otras vistas como referencia. En MVC, por ejemplo, la prediccion entre vistas se realiza como si el componente de vista en otra vista es una referencia de interprediccion. Las posibles referencias entre vistas se senalan en la ampliacion de la norma MVC del conjunto de parametros de secuencia (SPS) y pueden ser modificadas por el proceso de construccion de la lista de imagenes de referencia, lo cual habilita el ordenamiento flexible de las referencias de interprediccion o de prediccion entre vistas.
En la ampliacion de MVC de H.264/AVC, por ejemplo, la prediccion entre vistas es compatible con la compensacion de movimiento de disparidad, que utiliza la sintaxis de la compensacion de movimiento H.264/AVC, pero permite que se utilice una imagen en una vista diferente como imagen de referencia. La codificacion de dos vistas puede ser compatible con MVC, lo cual se denomina en general vistas estereoscopicas. Una de las ventajas de MVC es que un codificador MVC podrfa tomar mas de dos vistas como una entrada de video 3D y un descodificador MVC puede descodificar una representacion multivista. Por lo tanto, un dispositivo de renderizado con un descodificador MVC puede esperar contenidos de video 3D con mas de dos vistas.
En MVC, se permite la prediccion entre vistas (IVP) entre imagenes en la misma unidad de acceso (es decir, con la
5
10
15
20
25
30
35
40
45
50
55
60
65
misma instancia de tiempo). Una unidad de acceso es, en general, una unidad de datos que incluye todos los componentes de vista (por ejemplo, todas las unidades NAL) para una instancia temporal comun. Por lo tanto, en MVC, se permite la prediccion entre vistas entre imagenes en la misma unidad de acceso. Cuando se codifica una imagen en una de las vistas no basicas, la imagen puede agregarse a una lista de imagenes de referencia, si esta en una vista diferente pero con la misma instancia de tiempo (por ejemplo, el mismo valor POC y, por lo tanto, en la misma unidad de acceso). Una imagen de referencia de prediccion entre vistas puede ponerse en cualquier posicion de una lista de imagenes de referencia, como es el caso con cualquier imagen de referencia de interprediccion.
En el contexto de la codificacion de video multivista hay dos tipos de vectores de movimiento. Uno son vectores de movimiento normales que apuntan a las imagenes de referencia temporales, y el correspondiente modo de interprediccion se denomina una prediccion compensada por movimiento (MCP). El otro son vectores de movimiento de disparidad que apuntan a las imagenes en una vista diferente, y el modo de prediccion entre vistas correspondiente se denomina prediccion compensada por disparidad (DCP).
En HEVC convencional, hay dos modos para la prediccion de los parametros de movimiento: uno es el modo de fusion y el otro es la prediccion avanzada del vector de movimiento (AMVP). En el modo de fusion, se construye una lista de candidatos de parametros de movimiento (imagenes de referencia y vectores de movimiento) donde el candidato puede ser de bloques contiguos espaciales o temporales. Los bloques contiguos espacialmente y temporalmente pueden formar una lista de candidatos, es decir, un conjunto de candidatos a partir de los cuales se puede seleccionar informacion de prediccion de movimiento. Por consiguiente, el codificador de video 20 puede codificar los parametros de movimiento elegidos como informacion de prediccion de movimiento codificando un indice en la lista de candidatos. Despues de que el descodificador de video 30 haya descodificado el indice, todos los parametros de movimiento del bloque correspondiente al que el indice apunta pueden ser heredados, en el modo de combinacion.
En AMVP, de acuerdo con HEVC convencional, se obtiene una lista de candidatos de predictores de vector de movimiento para cada hipotesis de movimiento basandose en el indice de referencia codificado. Esta lista incluye vectores de movimiento de bloques contiguos que estan asociados con el mismo indice de referencia, asf como un predictor de vector de movimiento temporal que se obtiene basandose en los parametros de movimiento del bloque contiguo del bloque colocalizado en una imagen de referencia temporal. Los vectores de movimiento elegidos se senalan transmitiendo un indice a la lista de candidatos. Ademas, tambien se senalan los valores del indice de referencia y las diferencias del vector de movimiento.
La FIG. 4 proporciona varios ejemplos de la prediccion entre vistas. Las tramas de la vista S1, en el ejemplo de la FIG. 4, se ilustran como predichas a partir de imagenes en diferentes ubicaciones temporales de la vista S1, asf como predichas entre vistas a partir de tramas de las tramas de vistas S0 y S2 en las mismas ubicaciones temporales. Por ejemplo, la trama B de la vista S1 en la ubicacion temporal T1 se predice a partir de cada una de las tramas B de la vista S1 en las ubicaciones temporales T0 y T2, asf como las tramas B de las vistas S0 y S2 en la ubicacion temporal T1.
En el ejemplo de la FIG. 4, la letra "B" mayuscula y la "b" minuscula estan concebidas para indicar diferentes relaciones jerarquicas entre las tramas, en lugar de diferentes metodologfas de codificacion. En general, las tramas con "B" mayuscula son relativamente mas altas en la jerarqufa de prediccion que las tramas con "b" minuscula. La FIG. 4 tambien ilustra las variaciones en la jerarqufa de prediccion utilizando diferentes niveles de sombreado, donde las tramas con una mayor magnitud de sombreado (es decir, relativamente mas oscuras) estan mas altas en la jerarqufa de prediccion que aquellas tramas que tienen menos sombreado (es decir, relativamente mas claras). Por ejemplo, todas las tramas I en la FIG. 4 se ilustran con sombreado completo, mientras que las tramas P tienen un sombreado algo mas claro, y las tramas B (y las tramas con b minuscula) tienen diversos niveles de sombreado, pero siempre mas claros que el sombreado de las tramas P y las tramas I.
En general, la jerarqufa de prediccion se relaciona con indices del orden de vista, en cuanto a que las tramas relativamente mas altas en la jerarqufa de prediccion deberfan ser descodificadas antes de la descodificacion de tramas que estan relativamente mas bajas en la jerarqufa, de tal modo que esas tramas relativamente mas altas en la jerarqufa se pueden utilizar como tramas de referencia durante la descodificacion de las tramas relativamente mas bajas en la jerarqufa. Un fndice de orden de vista es un fndice que indica el orden de descodificacion de componentes de vista en una unidad de acceso. Los indices de orden de vista estan implfcitos en la ampliacion SPS MVC, como se especifica en el anexo H de H.264/AVC (la enmienda MVC). En el SPS, para cada fndice i, se senala el correspondiente view_id. En algunos ejemplos, la descodificacion de los componentes de vista seguira el orden ascendente del fndice de orden de vista. Si se presentan todas las vistas, los indices de orden de vista se encuentran en un orden consecutivo de 0 a num_views_minus_1.
De esta manera, las tramas utilizadas como tramas de referencia pueden ser descodificadas antes de la descodificacion de las tramas que se codifican con referencia a las tramas de referencia. Un fndice de orden de vista es un fndice que indica el orden de descodificacion de componentes de vista en una unidad de acceso. Para cada fndice de orden de visualizacion i, se senala el view_id correspondiente. La descodificacion de los componentes de vista sigue el orden ascendente de los indices de orden de vista. Si se presentan todas las vistas, entonces el
5
10
15
20
25
30
35
conjunto de indices de orden de vista puede comprender un conjunto consecutivamente ordenado de cero a uno menos que el numero total de vistas.
Para ciertas tramas a niveles iguales de la jerarquia, el orden de descodificacion entre ellas puede no importar. Por ejemplo, la trama I de la vista S0 en la posicion temporal T0 se utiliza como trama de referencia para la trama P de la vista S2 en la posicion temporal T0, que a su vez se utiliza como trama de referencia para la trama P de la vista S4 en la posicion temporal T0. En consecuencia, la trama I de la vista S0 en la posicion temporal T0 deberia descodificarse antes de la trama P de la vista S2 en la posicion temporal T0, la cual deberia descodificarse antes de la trama P de la vista S4 en la posicion temporal T0. Sin embargo, entre las vistas S1 y S3, no importa un orden de descodificacion, porque las vistas S1 y S3 no se basan la una en la otra para la prediccion, sino que se predicen solo a partir de vistas que son mas altas en la jerarquia de prediccion. Ademas, la vista S1 puede descodificarse antes que la vista S4, siempre que la vista S1 sea descodificada despues de las vistas S0 y S2.
De esta manera, puede utilizarse un ordenamiento jerarquico para describir las vistas S0 a S7. Deje que la notacion SA> SB signifique que la vista SA debe ser descodificada antes que la vista SB. Utilizando esta notacion, S0> S2> S4> S6> S7, en el ejemplo de la FIG. 4. Tambien con respecto al ejemplo de la FIG. 4, S0> S1, S2> S1, S2> S3, S4> S3, S4> S5 y S6> S5. Cualquier orden de descodificacion para las vistas que no viole estos requisitos es posible. En consecuencia, son posibles muchos ordenes de descodificacion diferentes con solo ciertas limitaciones.
De acuerdo con las tecnicas de esta divulgacion, cada una de las vistas S0-S7 puede considerarse una capa respectiva de un flujo de bits correspondiente. De este modo, un VPS puede describir parametros del flujo de bits aplicables a cualquiera de, o todas, las vistas S0-S7, mientras que puedan proporcionarse conjuntos de parametros de capas individuales para cualquiera de, o todas, las vistas S0-S7. Ademas, puede proporcionarse un conjunto de parametros de agrupacion para un grupo de conjuntos de parametros, de manera que los fragmentos dentro de las imagenes individuales de las vistas S0-S7 pueden referirse simplemente al identificador de un conjunto de parametros de agrupacion.
Como se muestra en la FIG. 4, un componente de vista puede utilizar los componentes de vista en otras vistas como referencia. Esto se denomina prediccion entre vistas. En MVC, la prediccion entre vistas se realiza como si el componente de vista en otra vista fuera una referencia de interprediccion. El codificador de video 20 y el descodificador de video 30 pueden codificar las posibles referencias entre vistas en la ampliacion MVC del Conjunto de Parametros de Secuencia (SPS) (como se muestra en el ejemplo de la Tabla 1). El codificador de video 20 y el descodificador de video 30 pueden modificar adicionalmente las posibles referencias entre vistas ejecutando el proceso de construccion de lista de imagenes de referencia, lo cual puede permitir el ordenamiento flexible de las referencias de prediccion entre vistas o interprediccion.
TABLA 1
seq_parameter_set_mvc_extension( ) {
C Descriptor
num_views_minus1
0 ue(v)
para( i = 0; i <= num_views_minus1; i++ )
view_id[ i ]
0 ue(v)
para( i = 1; i <= num_views_minus1; i++ ) {
num_anchor_refs_l0[i]
0 ue(v)
para( j = 0; j < num_anchor_refs_l0[i]; j++ )
anchor_ref_l0[ i ][ j ]
0 ue(v)
num_anchor_refs_l1[ i ]
0 ue(v)
para( j = 0; j < num_anchor_refs_l1[i]; j++ )
anchor_ref_l1[ i ][ j ]
0 ue(v)
}
para( i = 1; i <= num_views_minus1; i++) {
num_non_anchor_refs_l0[ i ]
0 ue(v)
para( j = 0; j < num_non_anchor_refs_l0[ i ]; j++ )
non_anchor_ref_l0[i][j]
0 ue(v)
num_non_anchor_refs_l1[ i ]
0 ue(v)
para( j = 0; j < num_non_anchor_refs_l1[ i ]; j++ )
non_anchor_ref_l1[ i ][ j ]
0 ue(v)
5
10
15
20
25
30
35
40
45
}
num_level_values_signaled_minus1
0 ue(v)
para( i = 0; i <= num_level_values_signaled_minus1; i++ ) {
level_idc[ i ]
0 u(8)
num_applicable_ops_minus1[ i ]
0 ue(v)
para( j = 0; j <= num_applicable_ops_minus1[i]; j++ ) {
applicable_op_temporal_id[i][j]
0 u(3)
applicable_op_num_target_views_minus1[ i ][ j ]
0 ue(v)
para( k = 0; k <= applicable_op_num_target_views_minus1[ i ][ j ]; k++ )
applicable_op_target_view_id[ i ][ j ][ k ]
0 ue(v)
applicable_op_num_views_minus1[ i ][ j ]
0 ue(v)
}
}
}
En la ampliacion SPS MVC mostrada en la Tabla 1, para cada vista, se senala el numero de vistas que se pueden utilizar para formar la lista de imagenes de referencia 0 y la lista de imagenes de referencia 1. La relacion de prediccion para una imagen de anclaje, tal como se senala en la ampliacion SPS MVC, puede ser diferente de la relacion de prediccion para una imagen sin anclaje (senalada en la ampliacion SPS MVC) de la misma vista.
Entre las normas de codificacion de video se incluyen ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 o ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual e ITU-T H.264 (tambien conocida como ISO/IEC MPEG-4 AVC), incluyendo sus ampliaciones de codificacion de video ajustable a escala (SVC) y de codificacion de video multivista (MVC).
Ademas, existe una nueva norma de codificacion de video, concretamente la Codificacion de Video de Alta Eficiencia (HEVC) que esta siendo desarrollada por el Equipo de Colaboracion Conjunta en Codificacion de Video (JCT-VC) del Grupo de Expertos en Codificacion de Video (VCEG) de ITU-T y el Grupo de Expertos en Imagenes en Movimiento (MPEG) de ISO/IEC. Un reciente Borrador de Trabajo (BT) de la HEVC, y denominado HEVC WD4 en adelante, esta disponible en
http://phenix.int-evry.fr/jct/doc_end_user/documents/6_Torino/wg11/JCTVC-F803-v3.zip, denotado como HEVC WD4d1.
El mecanismo de conjunto de parametros de secuencia e imagen desacopla la transmision de informacion que cambia poco frecuentemente de la transmision de datos de bloque codificados. En algunas aplicaciones, los conjuntos de parametros de secuencia e imagen pueden ser transportados "fuera de banda" usando un mecanismo de transporte fiable. Una carga util de secuencia de bytes sin procesar (RBSP) de un conjunto de parametros de imagen puede incluir parametros a los que pueden referirse las unidades de capa de abstraccion de red de fragmento codificado (NAL) de una o mas imagenes codificadas. Una o mas RBSP de un conjunto de parametros de secuencia puede incluir parametros a los que puede referirse una o mas RBSP de un conjunto de parametros de imagen o una o mas unidades NAL de informacion de mejora complementaria (SEI) que contienen un mensaje SEI de periodo de almacenamiento intermedio. Una RBSP de un conjunto de parametros de secuencia puede incluir parametros a los que puede hacer referencia una o mas RBSP de un conjunto de parametros de imagen o una o mas unidades SEI NAL que contienen un mensaje SEI de periodo de almacenamiento intermedio.
El conjunto de parametros de secuencia puede incluir un conjunto opcional de parametros denominado informacion de usabilidad de video (VUI). La VUI puede incluir las siguientes tres categorfas de informacion opcional: informacion de representacion de video, informacion del descodificador de referencia hipotetica (HRD) e informacion de restriccion del flujo de bits. La informacion de representacion de video incluye la relacion de aspecto, cambios de fase de croma de informacion de transformacion de espacio de color relativos a luma y velocidad de tramas. El HRD incluye parametros de almacenamiento intermedio de video para las secuencias de video codificadas. La informacion de restriccion del flujo de bits incluye restricciones sobre el rango del vector de movimiento, el tamano de la memoria intermedia de imagenes descodificadas (DPB) y el numero de tramas de reordenacion y los tamanos codificados de bloques (por ejemplo, macrobloques o unidades de codificacion (CU)) e imagenes.
HEVC WD5 incluye el conjunto de parametros de adaptacion de soporte (APS). El concepto de conjunto de parametros de adaptacion (APS) tambien se puede encontrar en JCTVC-F747, disponible en
http://phenix.int- evry.fr/jct/doc_end_user/documents/6_Torino/wgl11JCTVC-F747-v4.zip.
Se puede utilizar una cabecera de unidad NAL unificada tanto para los flujos de bits HEVC no escalables como para
los flujos de bits escalables que se ajustan a las ampliaciones potenciales escalables o multivista de HEVC. Una cabecera de unidad NAL unificada puede diferir de la cabecera de unidad HEVC NAL actual en los siguientes aspectos: puede haber una longitud de cabecera de unidad NAL fija para una secuencia de video codificada completa, mientras que la longitud puede variar entre secuencias de video codificadas diferentes, y una codificacion 5 eficaz de los elementos sintacticos de escalabilidad en la cabecera de unidad NAL y, cuando un elemento sintactico particular no es necesario, no necesita estar presente. En tal diseno, se puede usar un tipo de unidad NAL o un conjunto de parametros diferente para todo el flujo de bits.
10
15
20
video_parameter_set_rbsp( ) {
Descriptor
video_para_set_id
u(8)
// descripcion del contador de dimension de la muestra
cnt_p
u(3)
cnt_d
u(3)
cnt_t
u(3)
cnt_q
u(3)
cnt_v
u(4)
cnt_f
u(4)
// indice de muestra para la asignacion de caracterfsticas
para(i = 0; i < cnt_d; i++) {
pic_width_in_luma_samples[ i ]
ue(v)
pic_height_in_luma_samples[ i ]
ue(v)
bit_depth_luma_minus8[ i ]
ue(v)
bit_depth_chroma_minus8[ i ]
ue(v)
chroma_format_idc[ i ]
u(2)
}
para( i = 0; i < cnt_t; i++)
averge_frame_rate[ i ]
u(16)
si( cnt_v > 1)
para( i=0; i < cnt_v; i++)
view_id[ i ]
ue(v)
// parametros de control e indicadores de habilitacion / deshabilitacion de herramientas
log2_max_pic_order_cnt_lsb_minus4
ue(v)
chroma_pred_from_luma_enabled_flag
u(l)
loop_filter_across_slice_flag
u(l)
sample_adaptive_offset_enabled_flag
u(l)
adaptive_loop_filter_enabled_flag
u(l)
pcm_loop_filter_disable_flag
u(l)
cu_qp_delta_enabled_flag
u(l)
La FIG. 5 es un diagrama conceptual que ilustra un conjunto de parametros de video (VPS) y varios conjuntos de parametros de capa (LPS). Las elipses que siguen al segundo LPS de la FIG. 5 pretenden indicar que puede haber cualquier numero N de VPS, donde N es un numero entero. Por ejemplo, cada capa (por ejemplo, cada capa SVC o cada vista MVC) puede tener un LPS correspondiente. Un codificador de video, tal como el codificador de video 20 o el descodificador de video 30, puede configurarse para codificar un VPS y uno o mas LPS, como los ilustrados en la FIG. 5.
La Tabla 2 siguiente proporciona un ejemplo de sintaxis de carga util de secuencia de bytes sin procesar (RBSP) para un VPS.
TABLA 2
5
10
15
20
25
30
35
40
45
50
temporal_id_nesting_flag
u(l)
inter_4x4_enabled_flag
u(l)
operation_point_desription( )
vps_extension_flag
u(l)
si( vps_extension_flag )
mientras( more_rbsp_data( ) )
vps_extension_data_flag
u(l)
rbsp_trailing_bits( )
}
Los codificadores de video se pueden configurar de tal manera que una secuencia de video codificada (por ejemplo, un flujo de bits que incluya una o mas capas) solo pueda tener un conjunto de parametros de video (VPS) activo . El VPS puede estar encapsulado dentro de una unidad NAL de un tipo particular. Por ejemplo, el nal_unit_type para un VPS RBSP puede ser 10. La semantica de ejemplo para el VPS de la Tabla 2 se describe a continuacion:
En este ejemplo, video_para_set_id identifica un conjunto de parametros de video (VPS) correspondiente.
En este ejemplo, cnt_p especifica el numero maximo de valores de priority_id presentes en la secuencia de video codificada correspondiente.
En este ejemplo, cnt_d especifica el numero maximo de capas de dependencia presentes en la secuencia de video codificada correspondiente. Varias vistas con la misma resolucion pueden considerarse como pertenecientes a una misma capa de dependencia. Dos capas de dependencia pueden tener la misma resolucion espacial.
En este ejemplo, cnt_t especifica el numero maximo de capas temporales presentes en la secuencia de video codificada.
En este ejemplo, cnt_q especifica el numero maximo de capas de calidad presentes en una capa de dependencia en la secuencia de video codificada.
En este ejemplo, cnt_v especifica el numero maximo de vistas presentes en la secuencia de video codificada.
En este ejemplo, cnt_f especifica el numero de bits utilizados para representar el elemento sintaxis reserved_flags en la cabecera de la unidad NAL.
En este ejemplo, pic_width_in_luma_samples [i] y pic_height_in_luma_samples [i] especifican, respectivamente, la anchura y la altura de la i-esima resolucion de la capa de dependencia en unidades de muestras de luma.
En este ejemplo, bit_depth_luma_minus8 [i] mas 8 y bit_depth_chroma_minus8 [i] mas 8 especifica la profundidad de bits de los componentes luma y croma de la i-esima representacion de profundidad de bits.
En este ejemplo, chroma_format_idc [i] especifica el formato de la muestra de croma de la i-esima representacion del formato de la muestra de croma. Por ejemplo, un valor igual a 0 puede indicar 4:2:0; un valor igual a 1 puede indicar 4:4:4, un valor igual a 2 puede indicar 4:2:2 y un valor igual a 3 puede indicar 4:0:0.
En este ejemplo, average_frame_rate[i] especifica la velocidad media de la i-esima representacion de la capa temporal en unidades de tramas por 256 segundos.
En este ejemplo, view_id[i] especifica el identificador de vista de la i-esima vista, que tiene indice de orden de vista igual a i. Cuando no esta presente, se puede inferir que el valor de view_id[0] es 0. vps_extension_flag igual a 0 especifica que no hay elementos sintacticos vps_extension_data_flag presentes en la estructura de sintaxis RBSP del conjunto de parametros de video. vps_extension_flag puede ser igual a 0 en flujos de bits conforme a la proxima norma HEVC. El valor 1 para vps_extension_flag puede reservarse, por ejemplo, para un uso futuro mediante ITU-T | ISO/IEC. Los descodificadores, como el descodificador de video 30, pueden ignorar todos los datos que siguen al valor 1 para vps_extension_flag en una unidad NAL del conjunto de parametros de video.
En este ejemplo, vps_extension_data_flag puede tener cualquier valor. No afecta a la conformidad con los perfiles especificados en la proxima norma HEVC, pero permite el desarrollo posterior de la proxima norma.
Otros elementos sintacticos en el VPS pueden tener la misma semantica que los elementos sintacticos con los mismos nombres en el SPS del borrador de trabajo HEVC actual. Esos elementos sintacticos pueden aplicarse a la secuencia de video codificada que hace referencia a este VPS, a menos que sean sobrescritos por conjuntos de
5
10
15
20
25
30
35
40
45
50
55
60
parametros de nivel inferior.
En algunos ejemplos, una senal 3DV_flag puede indicarse adicionalmente en el VPS para indicar si la profundidad esta presente en la secuencia de video codificada.
En algunos ejemplos, los parametros VUI se senalan en el LPS.
En algunos ejemplos, los elementos sintacticos cnt_p, cnt_t, cnt_d, cnt_q y cnt_v especifican los numeros de bits utilizados para codificar priority_id, temporal_id, dependency_id, quality_id y view_idx, respectivamente, y los numeros maximos de valores priority_id, capas temporales, capas de dependencia, capas de calidad y vistas presentes en las secuencias de video codificadas tambien se pueden senalar en el VPS.
En algunos ejemplos, se puede introducir otro tipo de unidad NAL para contener los elementos sintacticos cnt_p, cnt_t, cnt_d, cnt_q, cnt_v y cnt_f. Este nuevo tipo de unidad NAL tambien puede incluir un identificador (ID) y puede hacerse referencia al ID en el VPS.
En algunos ejemplos, los elementos sintacticos de
log2_max_pic_order_cnt_lsb_minus4 a inter_4x4_enabled_flag en la Tabla 2 no estan senalados en el VPS, sino que en su lugar, el codificador de video 20 y el descodificador de video 30 pueden codificar estos elementos sintacticos en el LPS.
En algunos ejemplos, la estructura de sintaxis operation_point_desription () de la Tabla 2 no esta incluida en el VPS; en su lugar, el codificador de video 20 y el descodificador de video 30 u otros elementos (por ejemplo, la interfaz de salida 22 y/o la interfaz de entrada 28), pueden codificar el contenido en la estructura de sintaxis de operation_point_description () en un mensaje de informacion de mejora complementaria (SEI).
En algunos ejemplos, el codificador de video 20 y/o el descodificador de video 30 pueden codificar los parametros de informacion de usabilidad de video (VUI) en el VPS. Por ejemplo, un VPS puede incluir datos que especifican informacion de restriccion del flujo de bits, tales como restricciones en el rango de vectores de movimiento, tamano DPB, numero de tramas de reordenamiento y tamanos codificados de bloques (por ejemplo, macrobloques o CU) e imagenes. De esta manera, un VPS puede especificar informacion que indica un tamano DPB requerido para que un descodificador de video (tal como el descodificador de video 30) descodifique adecuadamente un flujo de bits correspondiente, es decir, un flujo de bits que incluya el VPS. Del mismo modo, un VPS puede especificar informacion de reordenacion de imagen, es decir, un cierto numero de imagenes que pueden preceder a una imagen dada en orden de descodificacion y que suceden a la imagen dada en orden de salida (es decir, orden de visualizacion).
Adicionalmente o de forma alternativa, un VPS puede incluir datos que especifican informacion de descodificador de referencia hipotetica (HRD). Como se ha indicado anteriormente, el codificador de video 20 y/o el descodificador de video 30 pueden codificar (es decir, senalar) los parametros VUI, que pueden incluir informacion HRD en el VPS. Por lo tanto, un VPS puede incluir datos que describen, por ejemplo, puntos de operacion de un flujo de bits correspondiente. Por ejemplo, un VPS puede incluir datos que describen uno o mas de un cierto numero de puntos de operacion maximos, dependencias entre capas o vistas diferentes, informacion de perfil y nivel para cada punto de operacion, representacion de unidad de VCL NAL de punto de operacion para cada punto de operacion, velocidad de bits para cada punto de operacion, dependencia entre puntos de operacion, restricciones para cada punto de operacion, VUI o VUI parcial para cada punto de operacion y/o VUI o VUI parcial para cada capa o vista.
Un VPS tambien puede incluir para cada dimension: un valor de indice especffico, un intervalo de valores de indice o una lista de valores de indice. Por ejemplo, cuando un VPS incluye datos que describen un valor de indice especffico, el valor de fndice puede corresponder, para una resolucion espacial, a la profundidad de bits para el formato de muestreo de croma. Para mencionar otro ejemplo, cuando un VPS incluye un intervalo de valores de fndice, para capas temporales, el intervalo puede comprender desde cero (0) al ID de capa temporal mas alto, y para capas de calidad, el intervalo puede comprender desde cero (0) al ID de capa de calidad mas alto. Como otro ejemplo, cuando un VPS incluye datos que describen una lista de valores de fndice, la lista puede comprender una lista de valores de fndice de vista para multiples vistas.
En algunos ejemplos, el codificador de video 20 puede codificar (es decir, senalar) y el descodificador de video puede descodificar, uno o mas parametros de formato de representacion (anchura, altura, profundidad de bits, etc.) y puede haber diferentes conjuntos de parametros de formato de representacion. Una capa o punto de operacion puede entonces referirse a un fndice de dicho conjunto de parametros de formato de representacion. Un ejemplo del diseno de sintaxis para tal conjunto se muestra en la Tabla 3 siguiente.
TABLA 3
num_rep_formats_minus1
ue(v)
para( i = 0; i <= num rep formats minusl; i++ ) {
pic_width_in_luma_samples[ i ]
ue(v)
pic_height_in_luma_samples[ i ]
ue(v)
bit_depth_luma_minus8[ i ]
ue(v)
bit_depth_chroma_minus8[ i ]
ue(v)
chroma_format_idc[ i ]
u(2)
}
para( i = 0; i < cnt_d; i++) {
rep_format_idx[ i ]
ue(v)
}
En algunos ejemplos, en lugar de eso, el ref_format_idx puede senalarse en el conjunto de parametros de capa.
5
La Tabla 4 siguiente proporciona una sintaxis de ejemplo para las descripciones de punto de operacion.
TABLA 4
operation_points_description( ) {
Descriptor
num_operation_point_minus1
ue(v)
para( i = 0; i <= num_operation_points_minus1; i++ ) {
op_profile_level_idc[ i ]
u(24)
operation_point_id[ i ]
ue(v)
priority_id[ i ]
ue(v)
temporal_id[ i ]
ue(v)
quality_id[ i ]
ue(v)
dependency_id[ i]
ue(v)
if (cnt_v > 1) {
num_target_output_views_minus1[ i ]
ue(v)
para( j = 0; j <= num_target_output_views_minus1[ i ]; j++ )
view_idx[ i ][ j ]
ue(v)
}
frm_rate_info_present_flag[ i ]
u(l)
avg_bitrate[ i ]
u(16)
max_bitrate[ i ]
u(16)
max_bitrate_calc_window[ i ]
u(16)
constant_frm_rate_idc[ i ]
u(2)
si (cnt_v >1) {
num_directly_dependent_views[ i ]
para( j = 0; j < num directly dependent views[ i ]; j++ ) {
directly_dependent_view_idx[ i ][ j ]
}
}
si (cnt_v > 1)
para( i = 1; i < cnt_v; i++ ) {
num_ref_views[ i ]
ue(v)
para( j = 0; j < num_ref_views[i]; j++ )
ref_view_idx[ i ][ j ]
ue(v)
5
10
15
20
25
30
35
40
}
}
A continuacion se analizan ejemplos de la semantica de los elementos sintacticos de la Tabla 4:
En este ejemplo, num_operation_point_minus1 mas 1 especifica el numero maximo de puntos de operacion que estan presentes en la secuencia de video codificada y para los cuales la informacion de punto de operacion es senalada por los siguientes elementos sintacticos.
En este ejemplo, op_profile_level_idc [i], operation_point_id [i], priority_id [i], num_target_output_views_minus1 [i], frm_rate_info_present_flag [i], avg_bitrate [i], max_bitrate [i], max_bitrate_calc_window [i], constant_frm_rate_idc [i] y num_directly_dependent_views [I] puede tener la misma semantica que los elementos sintacticos con los mismos nombres en el mensaje SEI de informacion de escalabilidad de H.264.
En este ejemplo, quality_id [i] y dependency_id [i] pueden tener la misma semantica que los elementos sintacticos con los mismos nombres en el mensaje SEI de informacion de escalabilidad de H.264.
En este ejemplo, directly_dependent_view_idx[i][j] especifica el indice de vista de la j-esima vista de la cual depende directamente la vista de salida de destino del punto de operacion actual en la representacion del punto de operacion actual.
En este ejemplo, num_ref_views[i] especifica el numero de componentes de vista para la prediccion entre vistas en la lista de imagenes de referencia inicial RefPicList0 y RefPicList1 en los componentes de vista de descodificacion con indice de orden de vista igual a i. En este ejemplo, el valor de las vistas num_ref[i] no sera mayor que Min (15, num_views_minus1). En algunos ejemplos, el valor de num_ref_views[0] es igual a 0.
En este ejemplo, ref_view_idx[i][j] especifica el indice de orden de vista del j-esimo componente de vista para la prediccion entre vistas en la lista de imagenes de referencia inicial RefPicList0 y RefPicList1 en la descodificacion de un componente de vista con indice de orden de vista igual a i. En este ejemplo, el valor de ref_view_idx[i][j] estara en el rango de 0 a 31, inclusive.
En algunos ejemplos, como alternativa, algunos de los elementos sintacticos del mensaje SEI de informacion de escalabilidad (por ejemplo, como se describe en H.264), por ejemplo, los elementos sintacticos relacionados con la informacion de dependencia de capa, se pueden incluir en la estructura de sintaxis operation_points_description() de la Tabla 4.
En algunos ejemplos, el codificador de video 20 y/o el descodificador de video 30 pueden codificar (es decir, senalar) algunos parametros VUI en la estructura de sintaxis operation_points_description() de la Tabla 4.
La Tabla 5 siguiente proporciona una sintaxis alternativa para un conjunto de parametros de video:
TABLA 5
video_parameter_set_rbsp( ) {
Descriptor
video_parameter_set_id
ue(v)
num_temporal_layers_minus1
u(3)
para ( i = 0; i <= num_temporal_layers_minus1; i++ ) {
profile_idc[ i ]
u(8)
reserved_zero_8bits[ i ] /* equal to 0 */
u(8)
level_idc[i ]
u(8)
}
bit_depth_luma_minus8
ue(v)
bit_depth_chroma_minus8
ue(v)
chroma_format_idc
u(2)
pic_width_in_luma_samples
ue(v)
pic_height_in_luma_samples
ue(v)
pic_cropping_flag
u(1)
si( pic_cropping_flag ) {
pic_crop_left_offset
ue(v)
pic_crop_right_offset
ue(v)
pi c_c rop_top_offset
ue(v)
pic_crop_botto m_offs et
ue(v)
}
temporal_id_nesting_flag
u(1)
bit_equal_to_one /* igual a 1 */
u(1)
extension_type /* igual a 0 para 3DV */
ue(v)
num_layers_minus2
ue(v)
num_rep_formats_minus1
ue(v)
para( i = 1; i <= num_rep_formats_minus1; i++) {
bit_depth_luma_minus8[ i ]
ue(v)
bit_depth_chroma_minus8[ i ]
ue(v)
chroma_format_idc[ i ]
u(2)
pic_width_in_luma_samples[ i ]
ue(v)
pic_height_in_luma_samples[ i ]
ue(v)
pic_cropping_flag[ i ]
u(1)
si( pic_cropping_flag[ i ] ) {
pic_crop_left_offset[ i ]
ue(v)
pic_crop_right_offset[ i ]
ue(v)
pic_crop_top_offset[ i ]
ue(v)
pic_crop_bottom_offset[ i ]
ue(v)
}
}
para( i = 1; i <= num_layers_minus1; i++ ) {
rep_format_idx[ i ]
ue(v)
si( extension_type = = 1) {
dependency_id[ i ]
ue(v)
quality_id[ i ]
ue(v)
num_directly_dependent_layers[ i ]
ue(v)
para( j = 0; j < num_directly_dependency_layers[ i ]; j++ )
delta_reference_layer_id_minus1[ i ][ j ]
ue(v)
}
}
nu m_short_term_ref_pic_sets
ue(v)
para( i = 0; i < num_short_term_ref_pic_sets; i++)
short_term_ref_pic_set( i )
si ( extension_type = =0 )
view_dependency( )
num_additional_profiles_levels_minus1
ue(v)
para(i = 0; i <= num_additional_profiles_levels_minus1; i++) {
additional_profile_idc[ i ]
u(8)
additional_reserved_zero_8bits[ i ] /* igual a 0 */
u(8)
additional_level_idc[ i ]
u(8)
num_applicable_operation_points_minus1[ i ]
ue(v)
para(j = 0; j <= num_applicable_operation_points[ i ]; j++) {
5
10
15
20
25
30
35
temporal_id[ i ][ j ]
ue(v)
layer_id[ i ][ j ]
ue(v)
si( extension_type = = 0 ) { /* Siempre verdadero para 3DV */
depth_included_flag
u(1)
num_target_output_views_minus1[ i ][ j ]
ue(v)
para( k = 0; k < num target output views minus1[ i ][ j ]; k++ )
layer_id[ i ][ j ][ k ]
ue(v)
}
si no (extension_type = = 1)
layer_id[ i ][ j ]
ue(v)
}
}
vps_vu i_para mete rs_p resent_flag
u(1)
si(vps_vui_parameters_present_flag)
vps_vui_parameters( )
vps_extension_flag
u(1)
si(vps_extension_flag)
mientras(more_rbsp_data( ) )
vps_exte nsion_d ata_fl a g
u(1)
rbsp_trailing_bits( )
}
Ejemplos de la semantica para la sintaxis del conjunto de parametros de video de la Tabla 5 se analizan continuacion. En general, los elementos sintacticos nombrados de forma similar que no se analizan a continuacion pueden tener la misma semantica como se ha analizado anteriormente con respecto a la Tabla 2. La semantica para los otros elementos sintacticos puede ser la siguiente:
En este ejemplo, bit_equal_to_one es igual a 1 (es decir, un valor binario "1").
En este ejemplo, extention_type igual a 0 indica que puede haber capas multivista en el flujo de bits. En este ejemplo, extension_type igual a 1 especifica que varias capas de dependencia y/o calidad pueden estar presentes en el flujo de bits.
En este ejemplo, num_rep_formats_minus1 mas 1 especifica el numero maximo de formatos de representacion de conjuntos diferentes compatibles con este conjunto de parametros de video; un formato de representacion incluye la profundidad de bits y el formato de croma (es decir, los conjuntos de valores de bit_depth_luma_minus8, bit_depth_chroma_minus8 y chroma_format_idc), informacion sobre la resolucion de imagen y la ventana de recorte en la secuencia de video codificada. El valor del num_rep_formats_minus1 puede estar en la gama entre 0 y X, inclusive. El codificador de video 20 y el descodificador de video 30 pueden codificar el conjunto de profundidad de bits y el formato de croma para la capa base mediante bit_depth_luma_minus8, bit_depth_chroma_minus8 y chroma_format_idc y los conjuntos de profundidad de bits y formato de croma son senalados para capas de realce mediante el siguiente conjunto de elementos sintacticos bit_depth_luma_minus8[i], bit_depth_chroma_minus8[i] y chroma_format_idc[i].
El codificador de video 20 y el descodificador de video 30 pueden codificar el primer conjunto de formato de representacion mediante muestras bit_depth_luma_minus8, bit_depth_chroma_minus8, chroma_format_idc, pic_width_in_luma, pic_height_in_luma_samples, pic_cropping_flag, pic_crop_left_offset, pic_crop_right_offset, pic_crop_top_offset y pic_crop_bottom_offset.
En este ejemplo, bit_depth_luma_minus8 i], bit_depth_chroma_minus8[i] y chroma_format_idc[i] especifican, respectivamente, el i-esimo conjunto de valores bit_depth_luma_minus8, bit_depth_chroma_minus8 y chroma_format_idc en la secuencia de video codificada.
En este ejemplo, pic_width_in_luma_samples[i] y
pic_height_in_luma_samples[i] especifican, respectivamente, la anchura y la altura de cada imagen descodificada en unidades de muestras de luma utilizando el i-esimo formato de representacion.
5
10
15
20
25
30
35
40
En este ejemplo, pic_cropping_flag [i] pic_crop_left_offset [i], pic_crop_right_offset [i], pic_crop_top_offset [i] y pic_crop_bottom_offset [i] especifican, para el i-esimo conjunto de formato de representacion, las muestras de las imagenes en la secuencia de video codificada que se emiten desde el proceso de descodificacion, en terminos de una region rectangular especificada en coordenadas de imagen para la salida.
En este ejemplo, rep_format_idx [i] especifica el indice de valores para el conjunto de profundidad de bits adicional y el formato de croma que se aplica a la capa con layer_id igual a i. Los valores de bit_depth_luma_minus8, bit_depth_chroma_minus8 y chroma_format_idc para la capa con layer_id igual a i pueden ser iguales a bit_depth_luma_minus8 [rep_format_idx[i]], bit_depth_chroma_minus8 [rep_format_idx[i]] y chroma_format_idc [rep_format_idx[i]], respectivamente. El valor de rep_format_idx[i] estara en la gama entre 0 y X, inclusive.
En este ejemplo, dependency_id[i] especifica un identificador de dependencia para la capa con layer_id igual a i. dependency_id[i] puede estar en el rango de 0 a X inclusive. Cuando no esta presente, se puede inferir que dependency_id[i] que es 0. Cuando num_directly_dependent_layers[i] es mayor que 0, dependency_id[i] puede ser igual o mayor que el identificador de dependencia de cualquier capa de la cual dependa la capa con layer_id igual a i.
En este ejemplo, quality_id[i] especifica un identificador de igualdad para la capa con layer_id igual a i. quality_id[i] puede estar en el rango de 0 a X inclusive. Cuando no esta presente, se puede inferir que quality_id [i] es 0. Cuando num_directly_dependent_layers[i] es mayor que 0, quality_id[i] puede ser igual o mayor que el identificador de calidad de cualquier capa de la cual dependa la capa con layer_id igual a i y que tenga un identificador de dependencia igual a dependency_id[i].
En este ejemplo, num_short_term_ref_pic_sets especifica el numero de conjuntos de imagenes de referencia a corto plazo que se especifican en el conjunto de parametros de video. El valor de num_short_term_ref_pic_sets puede estar en la gama entre 0 y 64, inclusive.
En este ejemplo, depth_included_flag igual a 1 indica que el punto de operacion 3DV actual contiene profundidad. En este ejemplo, depth_included_flag igual a 0 indica que el punto de operacion 3DV actual no contiene profundidad.
La sintaxis de ejemplo para el elemento de dependencia de vista de la Tabla 5 se proporciona en la Tabla 6 siguiente:
TABLA 6
view_dependency( ) {
num_views_minus1
ue(v)
para( i = 0; i <= num_views_minus1; i++ )
view_id[ i ]
ue(v)
para( i = 1; i <= num_views_minus1; i++ ) {
num_ref_views[ i ]
para( j = 0; j < num ref views[ i ]; j++ )
ref_view_idx[ i ][ j ]
ue(v)
inter_view_texture_flag[ i ][ j ]
u(1)
}
}
}
La Tabla 7 siguiente define un ejemplo de un conjunto de datos en los que la dependencia de vista de cada vista no basica se senala directamente en el nivel de secuencia.
TABLA 7
para( i = 1; i <= num views minus1; i++ ) {
num_ref_views[ i ]
ue(v)
para( j = 0; j < num ref views[ i ]; j++ ______)_____________________________
ref_view_idx[ i ][ j ]
ue(v)
}
En este ejemplo, num_ref_views[i] especifica el numero de componentes de vista para la prediccion entre vistas en la lista de imagenes de referencia inicial RefPicListO y RefPicListl en los componentes de vista de descodificacion con fndice de orden de vista igual a i. En este ejemplo, el valor de num_ref_views[i] no es mayor que Min(15, 5 num_views_minus1). En este ejemplo, el valor de num_ref_views[0] es igual a 0.
En este ejemplo, ref_view_idx[i][j] especifica el fndice de orden de vista del j-esimo componente de vista para la prediccion entre vistas en la lista de imagenes de referencia inicial RefPicListO y RefPicListl en la descodificacion de un componente de vista con fndice de orden de vista igual a i. En este ejemplo, el valor de ref_view_idx[i][j] esta en 10 el rango de 0 a 31, inclusive.
15
Como se ha indicado anteriormente, puede usarse un tipo particular de unidad NAL (por ejemplo, tipo de unidad NAL 10) para encapsular un conjunto de parametros de video. La sintaxis de la unidad NAL puede modificarse como se muestra en el ejemplo de la Tabla 8 siguiente.
TABLA 8
nal_unit( NumBytesInNALunit ) {
Descriptor
forbidden_zero_bit
f(1)
nal_ref_flag
u(1)
nal_unit_type
u(6)
NumBytesInRBSP = 0
nalUnitHeaderBytes = 1
si( nal_unit_type != 10 ) {// no unidad VPS NAL
si( cnt_p > 1 )
id de prioridad
u(v)
si(cnt_t> 1)
temporal_id
u(v)
reserved_one_bit
u(1)
si( cnt_d > 1 )
dependency_id
u(v)
si( cnt_q > 1 )
quality_id
u(v)
reserved_one_bit
u(1)
si( cnt_v > 1 )
view_idx
u(v)
si( cnt_f )
reserved_flags
u(v)
m = Ceil( log2(cnt_p) )+ Ceil(log2(cnt_t) ) + Ceil( log2(cnt_d) ) + Ceil(log2(cnt_q) ) + Ceil( log2(cnt v) ) + cnt f + 2
si( ( ( m + 7 >> 3) << 3) - m )
bits reservados
u(v)
nalUnitHeaderBytes += ( ( m + 7 ) >> 3)
}
para( i = nalUnitHeaderBytes; i < NumBytesInNALunit; i++ ) {
si( i + 2 < NumBytesInNALunit && next_bits(24) = = 0x000003 ) {
rbsp_byte[ NumBytesInRBSP++ ]
b(8)
rbsp_byte[ NumBytesInRBSP++ ]
b(8)
i+=2
5
10
15
20
25
30
35
emulation_prevention_three_byte /* igual a 0x03 */
f(8)
si no
rbsp_byte[ NumBytesInRBSP++ ]
b(8)
}
}
En este ejemplo, se anaden elementos dentro de la instruccion "si(nal_unit_type!=10)", en relacion con la sintaxis de la unidad NAL convencional. En este ejemplo, el numero de bits utilizados para senalar los elementos sintacticos priority_id, temporal_id, dependency_id, quality_id y view_idx es Ceil(log2 (cnt_p)), Ceil(log2 (cnt_t)), Ceil(log2 (cnt_d)), Ceil(log2(cnt_q)) y Ceil(log2(cnt_v)), respectivamente. Del mismo modo, en este ejemplo, cuando cualquiera de los elementos sintacticos priority_id, temporal_id, dependency_id, quality_id y view_idx no esta presente, se deduce que el valor de ese elemento sintactico es igual a 0.
Excepto como se ha definido anteriormente con respecto al numero de bits y las inferencias que pueden dibujarse, la semantica para los elementos sintacticos de la Tabla 8 puede definirse de la forma siguiente. La semantica de priority_id, dependency_id y quality_id puede ser tal como se define en la ampliacion SVC de ITU-T H.264/AVC. La semantica de temporal_id puede ser como se define en WD4 de HEVC. En este ejemplo, reserved_one_bit es igual a 1. El valor 0 para reserved_one_bit puede ser especificado por futuras ampliaciones de la norma HEVC. Los descodificadores, tales como el descodificador de video 30, pueden configurarse para ignorar el valor de reserved_one_bit.
En este ejemplo, view_idx especifica el indice de orden de vista para una vista. La semantica de view_idx puede ser la misma que el elemento sintactico "indice de orden de vista" tal como se especifica en la ampliacion MVC de ITU-T H.264/AVC.
En este ejemplo, cada bit de reserved_flags es igual a 1. Otros valores para reserved_flags pueden ser especificados por futuras ampliaciones de la proxima norma HEVC. Los descodificadores, tales como el descodificador de video 30, pueden configurarse para ignorar el valor de reserved_flags, a menos que esten configurados para funcionar de acuerdo con una ampliacion que asigne semantica a bits de reserved_flags. En este ejemplo, el numero de bits utilizados para representar reserved_flags es reserved_flags_len.
En este ejemplo, cada bit de reserved_bits es igual a 1. Otros valores para reserved_bits pueden ser especificados por la ampliacion futura de la proxima norma HEVC. Los descodificadores, tales como el descodificador de video 30, pueden configurarse para ignorar el valor de reserved_bits, de nuevo a menos que esten configurados de acuerdo con dicha ampliacion futura. El numero de bits utilizados para representar reserved_bits, en este ejemplo, es ((m+7 >> 3) << 3) -m.
La Tabla 9 siguiente proporciona una sintaxis de ejemplo para un conjunto de parametros de capa. Se puede usar la misma sintaxis para cada uno de los LPS de la FIG. 5, en algunos ejemplos.
TABLA 9
layer_para_set( ) {
Descriptor
depth_flag
u(1)
layer_para_set_id
ue(v)
vps_id
ue(v)
// cu hierarchy {{
log2_min_coding_block_size_minus3
ue(v)
log2_diff_max_min_coding_block_size
ue(v)
log2_min_transform_block_size_minus2
ue(v)
log2_diff_max_min_transform_block_size
ue(v)
log2_min_pcm_coding_block_size_minus3
ue(v)
max_transform_hierarchy_depth_inter
ue(v)
max_transform_hierarchy_depth_intra
ue(v)
// jerarqufa de cu }}
pcm_bit_depth_luma_minus1
u(4)
5
10
15
20
25
pcm_bit_depth_chroma_minus1
u(4)
loop_filter_across_slice_flag
u(1)
sample_adaptive_offset_enabled_flag
u(1)
adaptive_loop_filter_enabled_flag
u(1)
pcm_loop_filter_disable_flag
u(1)
cu_qp_delta_enabled_flag
u(1)
// componentes
num_tile_columns_minus1
ue(v)
num_tile_rows_minus1
ue(v)
si (num_tile_columns_minus1 != 0 || num_tile_rows_minus1 0) {
tile_boundary_independence_idc
u(1)
uniform_spacing_idc
u(1)
si (uniform_spacing_idc != 1) {
para (i=0; i<num_tile_columns_minus1 ; i++)
anchura de columna[i]
ue(v)
para (i=0; i <num_tile_rows_minus1; i++)
row_height[i]
ue(v)
}
}
lps_extension_flag
u(1)
si( lps_extension_flag )
mientras( more_rbsp_data( ) )
lps_exte nsion_d ata_fl ag
u(1)
rbsp_trailing_bits( )
}
A continuacion se describen ejemplos de la semantica para la sintaxis LPS de la Tabla 9. Diferentes capas (por ejemplo, diferentes vistas en MVC o diferentes capas en SVC) pueden referirse a diferentes LPS. Diferentes capas de calidad en una misma capa de dependencia pueden compartir el mismo LPS. Diferentes capas temporales en una misma capa de dependencia pueden compartir el mismo LPS. De forma alternativa, diferentes vistas pueden referirse a un mismo LPS y diferentes capas de dependencia pueden referirse a un mismo LPS.
En este ejemplo, depth_flag igual a 1 especifica que el LPS se aplica a las representaciones de profundidad identificadas por los valores de temporal_id, dependency_id, quality_id y view_idx de la unidad LPS NAL. Depth_flag igual a 0 especifica que el LPS se aplica a las representaciones de textura identificadas por los valores de temporal_id, dependency_id, quality_id y view_idx de la unidad LPS NAL.
En este ejemplo, layer_para_set_id especifica el id del conjunto de parametros de capa actual (LPS). Diferentes conjuntos de parametros de capa con los mismos valores de dependency_id y view_idx, respectivamente, comparten un espacio de valor para layer_para_set_id, lo cual significa que diferentes LPS con diferentes combinaciones de depencey_id y view_idx pueden tener el mismo valor de layer_para_set_id.
De forma alternativa, todos los LPS pueden compartir el espacio de un valor, lo cual significa que cada LPS tiene un valor distinto de layer_para_set_id.
En este ejemplo, vps_id identifica el conjunto de parametros de video al que se refiere este conjunto de parametros de capa.
En este ejemplo, lps_extension_flag igual a 0 especifica que no hay elementos sintacticos lps_extension_data_flag presentes en la estructura de sintaxis RBSP del conjunto de parametros de capa. En este ejemplo, lps_extension_flag puede ser igual a 0 en flujos de bits que se ajustan a la proxima norma HEVC. El valor 1 para
5
10
15
20
25
30
35
lps_extension_flag esta reservado para un uso futuro por ITU-T | ISO/IEC. Los descodificadores, como el descodificador de video 30, pueden ignorar todos los datos que siguen al valor 1 para lps_extension_flag en una unidad NAL de conjunto de parametros de capa.
En este ejemplo, lps_extension_data_flag puede tener cualquier valor y no afecta la conformidad con los perfiles especificados en la proxima norma HEVC.
Otros elementos sintacticos pueden tener la misma semantica que los elementos sintacticos con los mismos nombres en el SPS de la HEVC WD, pero aplicando solo a las imagenes que se refieren a este LPS.
Un LPS puede estar contenido en una unidad NAL cuya cabecera puede definirse de acuerdo con la Tabla 8 anterior. Los siguientes elementos sintacticos tienen la siguiente semantica ligeramente modificada cuando estan asociadas con un LPS.
En este ejemplo, priority_id es igual al valor minimo de los valores priority_id de todas las unidades NAL que se refieren a este LPS.
En este ejemplo, temporal_id es igual al valor minimo del temporal_id de todas las unidades NAL que se refieren a este LPS.
En este ejemplo, dependency_id es igual al dependency_id de todas las unidades NAL que se refieren a este LPS.
En este ejemplo, quality_id es igual al valor minimo de quality_id de todas las unidades NAL que se refieren a este LPS.
En este ejemplo, v_idx es el indice de vista del LPS actual. Todas las imagenes que se refieren a este LPS pueden tener un id de vista de view_id [v_idx].
De forma alternativa, los elementos sintacticos anteriores pueden senalarse directamente en la tabla de sintaxis del conjunto de parametros de capa, como se muestra en el ejemplo de la Tabla 10. Se puede disenar una tabla de sintaxis mas detallada de acuerdo con la Tabla 9 siguiente. En este caso, esos elementos sintacticos no estan en la cabecera de unidad NAL del LPS y el analisis del LPS puede depender del VPS con un ID igual a vps_id.
TABLA 10
layer_para_set( ) {
Descriptor
vps_id
u(8)
si( cnt_p > 1 )
priority_id
u(v)
si( cnt_t > 1 )
temporal_id
u(v)
reserved_one_bit
u(1)
si( cnt_d > 1 )
dependency_id
u(v)
si( cnt_q > 1 )
quality_id
u(v)
si( cnt_v > 1 )
view_idx
u(v)
depth_flag
u(1)
layer_para_set_id
ue(v)
// jerarqufa de cu { {
rbsp_trailing_bits( )
}
Un LPS, en este caso, no necesita tener una cabecera de unidad NAL duplicando los elementos sintacticos anteriores. Suponiendo que el tipo de unidad NAL de una unidad NAL que encapsula un LPS es, por ejemplo, 5, la
sintaxis de cabecera de unidad NAL puede modificarse ligeramente como se muestra en la Tabla 11, que anade la excepcion "&& nal_unit_type! = 5" en la instruccion "if" de la Tabla 8:
5
TABLA 11
nal_unit( NumBytesInNALunit ) {
Descriptor
forbidden_zero_bit
f(1)
nal_ref_flag
u(1)
nal_unit_type
u(6)
NumBytesInRBSP = 0
nalUnitHeaderBytes = 1
si( nal_unit_type != 10 && nal_unit_type !=5 ) { // no unidad VPS NAL
si( cnt_p > 1 )
priority_id
u(v)
si( cnt_t > 1 )
temporal_id
u(v)
reserved_one_bit
u(1)
si( cnt_d > 1 )
dependency_id
u(v)
si( cnt_q > 1 )
quality_id
u(v)
reserved_one_bit
u(1)
si( cnt_v > 1 )
view_idx
u(v)
si( cnt_f )
reserved_flags
u(v)
m = Ceil( log2(cnt_p))+ Ceil( log2(cnt_t) ) + Ceil( log2(cnt_d) ) + Ceil( log2(cnt_q) ) + Ceil( log2(cnt v) ) + cnt f + 2
si( ((m + 7 >> 3) << 3 ) - m)
reserved_bits
u(v)
nalUnitHeaderBytes += ( ( m + 7 ) >> 3 )
}
para( i = nalUnitHeaderBytes; i < NumBytesInNALunit; i++ ) {
si( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) {
rbsp_byte[ NumBytesInRBSP++ ]
b(8)
rbsp_byte[ NumBytesInRBSP++ ]
b(8)
i += 2
emulation_prevention_three_byte /* igual a 0x03 */
f(8)
} si no
rbsp_byte[ NumBytesInRBSP++ ]
b(8)
}
}
En otros ejemplos, el codificador de video 20 y el descodificador de video 30 pueden codificar los elementos sintacticos relacionados con las caracterfsticas escalables usando codificacion de longitud fija, como se muestra en el ejemplo de la Tabla 12 siguiente.
TABLA 12
layer_para_set( ) {
Descriptor
5
10
15
20
25
30
35
vps_id
u(8)
priority_id
u(5)
temporal_id
u(3)
dependency_id
u(3)
quality_id
u(3)
view_idx
u(8)
layer_para_set_id
ue(v)
// jerarqufa de cu { {
La Tabla 13 siguiente proporciona un ejemplo de sintaxis para un conjunto de parametros de imagen (PPS) de acuerdo con las tecnicas de esta divulgacion. En este ejemplo, el conjunto de parametros de imagen no necesita senalar un "seq_parameter_set_id", contrariamente al PPS de HEVC convencional.
TABLA 13
pic_parameter_set_rbsp( ) {
Descriptor
pic_parameter_set_id
ue(v)
pps_extension_flag
u(1)
si( pps_extension_flag)
mientras( more_rbsp_data( ) )
pps_extens ion_d ata_fl ag
u(1)
rbsp_trailing_bits( )
}
A continuacion se describen ejemplos de la semantica para el PPS de la Tabla 13.
En este ejemplo, pps_extension_flag igual a 0 especifica que no hay elementos sintacticos pps_extension_data_flag presentes en la estructura de sintaxis RBSP del conjunto de parametros de imagen. En este ejemplo, pps_extension_flag es igual a 0 en flujos de bits que cumplen con la proxima norma HEVC. El valor 1 para pps_extension_flag esta reservado para un uso futuro por ITU-T | ISO/IEC. Los descodificadores, como el descodificador de video 30, pueden ignorar todos los datos que siguen al valor 1 para pps_extension_flag en una unidad NAL del conjunto de parametros de imagen.
En este ejemplo, pps_extension_data_flag puede tener cualquier valor. No afecta necesariamente a la conformidad con los perfiles especificados en la proxima norma HEVC. La semantica para valores de pps_extension_data_flag puede asignarse en desarrollos adicionales de la norma HEVC o ampliaciones de la norma sin entrar en conflicto con las tecnicas de esta divulgacion.
En las tecnicas de esta divulgacion, no es necesario senalar en el PPS ningun id del conjunto de parametros de secuencia o id del conjunto de parametros de capa. Algunos otros elementos sintacticos en PPS se pueden mover a LPS. Es decir, el codificador de video 20 y/o el descodificador de video 30 pueden configurarse para codificar uno o mas LPS incluyendo datos similares a los elementos sintacticos mostrados en la Tabla 13.
La FIG. 6 es un diagrama conceptual que ilustra un ejemplo de un conjunto de parametros de agrupacion (GPS) y relaciones del GPS con otros conjuntos de parametros y cabeceras de fragmentos. En este ejemplo, los otros conjuntos de parametros incluyen LPS, SPS, PPS, conjuntos de parametros de adaptacion (APS) de tipo 0 (por ejemplo, APS que senalan parametros de filtro adaptativo de bucle (ALF)), APS de tipo 1 (por ejemplo, APS que senalan una matriz de cuantizacion) y otros conjuntos de parametros. En este ejemplo, el GPS incluye una pluralidad de grupos diferentes, cada uno de los cuales tiene un ID de GPS unico (tambien denominado ID de grupo), en el que cada grupo indica uno particular de cada uno de los diversos conjuntos de parametros mediante el ID de un conjunto de parametros. De esta manera, las cabeceras de fragmento solo necesitan especificar un group_id para especificar cada uno de los conjuntos de parametros correspondientes al grupo que tiene ese group_id.
Las tablas 14 y 15 siguientes proporcionan ejemplos alternatives de sintaxis para un conjunto de parametros de agrupacion RBSP.
5
TABLA 14
group_para_set_rbsp() {
Descriptor
number signaled_para_set_groups_minus1
ue(v)
para( i = 0; i<= number signaled para set groups minus1; i++ ) {
para_set_group_id[ i ]
ue(v)
lps_id[ i ]
ue(v)
pps_id[ i ]
ue(v)
para (j= 0; j< numParaSetTypes; j++)
para_set_type_id[ i ] [ j ]
}
gps_exte nsion_flag
u(1)
si( gps_extension_flag )
mientras( more_rbsp_data( ) )
gps_exte nsion_d ata_fl ag
u(1)
rbsp_trailing_bits( )
}
TABLA 15
group_para_set_rbsp( ) {
Descriptor
number_signaled_para set_groups_minus1
ue(v)
para( i = 0; i<= number signaled para set groups minus1; i++ ) {
para_set_roup_id[ i ]
ue(v)
lps_id[ i ]
ue(v)
pps_id[ i ]
ue(v)
aps_id[ i ]
ue(v)
}
gps_exte nsion_flag
u(1)
si( gps_extension_flag )
mientras( more_rbsp_data( ) )
gps_exte nsion_d ata_fl ag
u(1)
rbsp_trailing_bits( )
}
10 Los codificadores de video, tales como el codificador de video 20 y el descodificador de video 30, pueden configurarse para codificar un conjunto de parametros de agrupacion de acuerdo con, por ejemplo, la Tabla 14 o la Tabla 15. A continuacion se proporcionan ejemplos de semantica para la sintaxis de los conjuntos de parametros de agrupacion.
15 En este ejemplo, number_signalled_para_set_groups_minus1 mas 1 especifica el numero de grupos de parametros senalados. Este valor puede estar en la gama entre 0 y 30, inclusive.
En este ejemplo, para_set_group_id[ i ] especifica el ID del i-esimo grupo de conjuntos de parametros senalados. El valor de para_set_group_id[ i ] estara en la gama entre 0 y 31, inclusive.
En este ejemplo, para_set_type_id [ i ] [ j ] especifica el ID del j-esimo tipo del conjunto de parametros para el i-esimo
5
10
15
20
25
30
35
40
45
50
55
60
65
grupo del conjuntos de parametros.
En este ejemplo, lps_id [ i ] indica el id del conjunto de parametros de capa al que hace referenda el grupo de conjuntos de parametros con un id de grupo de para_set_group_id [ i ]. Los valores de dependency_id y view_idx de un LPS con layer_para_set_id igual a lps_id [ i ] pueden ser identicos a los valores de dependency_id y view_idx, respectivamente, de la unidad NAL del grupo de conjuntos de parametros.
Los valores de dependency_id y view_idx de un conjunto de parametros RBSP estan presentes en la cabecera de unidad NAL de esta RBSP en los ejemplos de las Tablas 14 y 15 y los valores de dependency_id y view_idx de un LPS pueden estar presentes en la cabecera de unidad NAL de este LPS o en la tabla de sintaxis del LPS.
De forma alternativa, los valores de dependency_id y view_idx de un LPS con layer_para_set_id igual a lps_id[i] pueden no ser identicos a los valores de dependency_id y view_idx, respectivamente, de la unidad NAL del grupo de conjuntos de parametros.
En este ejemplo, pps_id[ i ] indica el id del conjunto de parametros de imagen al que hace referencia el grupo de conjuntos de parametros con un id de grupo de para_set_group_id [ i ].
En este ejemplo, aps_id [ i ] indica el id del conjunto de parametros de adaptacion al que hace referencia el grupo de conjuntos de parametros con un id de grupo de para_set_group_id [ i ].
En este ejemplo, gps_extension_flag igual a 0 especifica que no hay elementos sintacticos gps_extension_data_flag presentes en la estructura de sintaxis RBSP de la agrupacion de conjunto de parametros. Gps_extension_flag puede ser igual a 0 en flujos de bits que cumplen con la proxima norma HEVC. El valor 1 para gps_extension_flag puede estar reservado para un uso futuro por parte de ITU-T | ISO/IEC. Los descodificadores, como el descodificador de video 30, pueden ignorar todos los datos que siguen al valor 1 para gps_extension_flag en la unidad NAL de la agrupacion del conjunto de parametros. En general, gps_extension_data_flag puede tener cualquier valor. No tiene por que afectar a la conformidad con los perfiles especificados en la proxima norma HEVC.
En algunos ejemplos, para_set_type_id [ i ] [ j ] puede en lugar de eso ser aps_id [ i ] [ j ], con similar semantica aaps_id [ i ] como se ha descrito anteriormente.
Como se muestra en la FIG. 6, en lugar de referirse al ID del conjunto de parametros de imagen en la cabecera de fragmento, de acuerdo con las tecnicas de esta divulgacion, la cabecera de fragmento puede referirse a un ID del grupo de conjuntos de parametros, haciendo referencia indirectamente a un LPS, un PPS y un APS de cada tipo (por ejemplo, APS que proporcionan parametros ALF y matrices de cuantizacion).
Un codificador de video puede activar un conjunto de parametros de video o unos conjuntos de parametros de capa cuando una unidad VCL NAL (que contiene un fragmento codificado) se refiere al conjunto de parametros, indirectamente, por ejemplo, basandose en el principio de diseno H.264/AVC.
En algunos ejemplos, los conjuntos de parametros pueden ser activados por un tipo especffico de unidad NAL en lugar de por un fragmento codificado. Por ejemplo, un tipo de unidad NAL de este tipo especffico (unidad de NAL de activacion de conjuntos de parametros), si esta presente en el flujo de bits, puede activar uno y exactamente uno, VPS. En varias alternativas, ademas, tal tipo de unidad NAL puede activar al menos un LPS. Ademas, dicho tipo de unidad NAL puede activar al menos un PPS. Ademas, dicho tipo de unidad NAL puede activar al menos un APS. Una unidad NAL de activacion de conjuntos de parametros puede ser un conjunto de parametros de agrupacion RBSP. Una unidad NAL de activacion de conjuntos de parametros (PSA) puede ser aplicable a una secuencia de video codificada. Una unidad PSA NAL puede considerarse una unidad NAL no VCL, es decir, no es directamente relevante para un codificador de video. La sintaxis de cabecera de unidad NAL de la unidad PSA NAL puede ser la misma que una unidad VAL NAL.
En algunos ejemplos, una unidad PSA NAL, si esta presente en una unidad de acceso, puede preceder a la primera unidad VAL NAL de la unidad de acceso. Puede haber al menos una unidad PSA NAL en la primera unidad de acceso de una secuencia de video codificada, por ejemplo, una imagen IDR. Multiples unidades PSA NAL en la misma secuencia de video codificada pueden contener el mismo id de VPS; por lo tanto, no es necesario activar diferentes conjuntos de parametros de video dentro de la misma secuencia de video codificada. Una unidad PSA NAL, si esta presente en una unidad de acceso, puede preceder a cualquier unidad LPS, PPS, APS o SEI NAL, si esta presente. Una unidad VPS NAL, si esta presente en una unidad de acceso, puede preceder a cualquier unidad LPS, PPS, APS o SEI NAL, si esta presente. En varias alternativas, ademas, una unidad PSA NAL, si esta presente en una unidad de acceso, puede preceder a una unidad VPS NAL, si esta presente.
En algunos ejemplos, los codificadores de video, tales como el codificador de video 20 y el descodificador de video 30, pueden configurarse para utilizar la sintaxis de la Tabla 16 para un conjunto de parametros de secuencia (SPS), en oposicion a la sintaxis SPS convencional de, por ejemplo, la HEVC.
ze
U)n
Beu-;u3S3jd-s3!d~(3J-iLiJ3i.-Buo|
(U)n
Be u-p31 q e u 3-^xt>-j 3^u |
( 0 = = £snu!LU_0Z!s_>joo|q_6Lupoo_u!LU_2:6o| )|s
(U)n
BBU-6uqs3U-p!-|BJodLU3i
(U)n
6e|j-3|qes!p-J3iiw-doo|-iuod
(6e|i_p0|qeu0_Luod )|s
(U)n
Be |i-ao j | s-u !-i0oo-i| b
( 6B|i_p0|qeu0_j0im_doo|_0AqdepB )|s
(U)n
BB|i_p3|qBU3_J3J|!i_doO|_3A!jdBpB
U)n
Bb u-p01 qB u 0-i0sy o-0A qd b pB-0| d lu b s
(U)n
BB|i_p0|qBU3_30jjpBnb_3JBnbs_uou
(U)n
BB|i-p0|qBU0-suoq!^iBd_uoqoLU-oui0LULuAsB
(U)n
BBU-p0|qBU0-s0O!|s-ssojoB-j0im-doo|-b0s
(U)n
BBU-p0|qBU0-sdB_U!-j0im-Bu!>|oo|q0p
U)n
BBU-p0|qBU0_BLun|-LuoJi-p0jd-BLUojqo
BBy-0|qBU0-iS!|-Bu!|BOS
(A)en
EJ}U!-q}d3p-Aq3JEJ3!q-iujojsuEJ}-XEiu
(A)en
J3jU!_qjd0p_AqojBJ3!q_LUJO:isuBJj_XBLU
{
(A)en
0Z!S->|oo|q-Bu!poo-LUod-U!LU-XBLU-y!p-3Bo|
(A)en
gsnu!LU-0Z!s->|oo|q-Bu!poo-Luod-u!LU-3Bo|
} ( 6B|i_p0|qBU0_LUod )|s
(A)en
3Z!S_>|30|q_lUJ0JSUEJ}_U!lU_XElU_.y!P_260|
(A)en
3snu!LU-0Z!s->|oo|q-LUJOisuBJi-u!LU-3Bo|
(A)en
3Z|s_>|oo|q_Bu!poo_u!LU_XBLU_:y!p_2Bo|
(A)en
gsnu!LU-0Z!S->|oo|q-Bu!poo-U!LU-3Bo|
(U)n
BBU-iU0S0jd-uoqBoy!poLU-siS!|
(6B|.}_S}S!|_3!d_.}0J_p0}3LqS0J )|S
U)n
BB|i_sjS!|_O!d_i3J_p0jO!JjS3J
{
(A)en
[ | ]j0sb0jou!-Aou01b|-xblu
(A)en
[ | ]so!d-j0pjo0j-Lunu
(A)en
[ | ]BuN0ijnq-o!d-o0p-XBLU
} ( ++| 1 |,snu!iu—sjbAbi-|BJodiu0}—XBiu => \ lo = \ )BJBd
(A)en
^snu!LU-qs|-iuo-j0pjo-o!d-XELU-3Bo|
(U)n
BBU-ssBdAq-iuBnbsuBJi_oj0z-A-0Luuddb
{
(fr)n
|,snu!LU-BLUOjqo-qid0p-i!q-LUod
(fr)n
|,snu!LU-BLun|-qid0p-i!q-Luod
} ( 6B|i_p0|qBU0_LUod )|s
U)n
Be y-p0| q b u 0-lu od
(A)en
xpj-JBLUJO^-d0J
(A)en
P!_J0S_J0J0LUBJBd—O0pjA
jojduosaQ
} () B!ou0no0s_0p_soJi0LUBJBd_0p_ojunruoo_0p_dsqj
91. vnavi
zuos-zo-eu
sesoozei.3
tiles_or_entropy_coding_sync_idc
u(2)
si( tiles_or_entropy_coding_sync_idc = = 1 ) {
num_tile_columns_minus1
ue(v)
num_tile_rows_minus1
ue(v)
uniform_spacing_flag
u(1)
si( !uniform_spacing_flag ) {
para( i = 0; i < num_tile_columns_minus1; i++ )
column_width[ i ]
ue(v)
para( i = 0; i < num_tile_rows_minus1; i++ )
row_height[ i ]
ue(v)
}
loop_filter_ac ross_ti les_e nabled_flag
u(1)
}
vui_parameters_present_flag
u(1)
si( vui_parameters_present_flag )
vui_parameters( )
sps_extension_flag
u(1)
si( sps_extension_flag )
mientras( more_rbsp_data( ) )
s ps_exte nsion_d ata_fl ag
u(1)
rbsp_trailing_bits( )
}
El ejemplo SPS de la Tabla 16 elimina profile_idc, reserved_zero_8bits, level_idc, chroma_format_idc, separate_colour_plane_flag y correspondiente condicional "si", max_temporal_layers_minus1, pic_width_in_luma_samples, pic_height_in_luma_samples, pic_cropping_flag, pic_crop_left_offset, 5 pic_crop_right_offset, pic_crop_top_offset, y pic_crop_bottom_offset y la correspondiente instruccion condicional "si", bit_depth_luma_minus8, bit_depth_chroma_minus8 , num_short_term_ref_pic_sets y short_term_ref_pic_set(i) y la correspondiente instruccion condicional "si" de la sintaxis SPS convencional. Ademas, el ejemplo SPS de la Tabla 16 anade un video_parameter_set_id y rep_format_idx. La semantica para los demas elementos sintacticos restantes puede ser la misma que se define en la HEVC convencional. La semantica para los elementos anadidos 10 video_parameter_set_id y rep_format_idx se puede definir de la siguiente manera:
En este ejemplo, video_parameter_set_id identifica el conjunto de parametros de video (VPS) al que hace referencia el SPS actual. De forma alternativa, video_parameter_set_id no necesita ser senalado y puede usarse un GPS para vincular un SPS a un VPS especifico.
15
En este ejemplo, rep_format_idx especifica el indice del formato de representacion senalado en el conjunto de parametros de video a los que se hace referencia.
Como otra alternativa, la Tabla 17 proporciona otro ejemplo de sintaxis para un conjunto de parametros de 20 agrupacion. Se supone que, en este ejemplo, el elemento sintactico del ID de conjunto de parametros de video no esta presente en la sintaxis de SPS, como se ha descrito anteriormente.
TABLA 17
group_para_set_rbsp( ) {
Descriptor
gps_is
ue(v)
vps_id
ue(v)
sps_id
ue(v)
pps_id
ue(v)
nu m_ref_aps_ids
ue(v)
5
10
15
20
25
30
35
40
45
para( i = 0; i < num ref aps ids; i++ ) {
ref_aps_id[ i ]
ue(v)
ref_aps_param_type[ i ]
ue(v)
}
gps_exte nsion_flag
u(1)
si( gps_extension_flag )
mientras( more_rbsp_data( ) )
g p s_exte nsion_d ata_fl a g
u(1)
rbsp_trailing_bits( )
}
La semantica para los elementos sintacticos de la Tabla 17 puede definirse de la forma siguiente:
En este ejemplo, gps_id especifica el identificador de un conjunto de parametros de grupo (GPS).
En este ejemplo, vps_id especifica el identificador del conjunto de parametros de video al que hace referencia el GPS.
En este ejemplo, sps_id especifica el identificador del conjunto de parametros de secuencia al que hace referencia el GPS.
En este ejemplo, pps_id especifica el identificador del conjunto de parametros de secuencia de imagenes al que hace referencia el GPS.
En este ejemplo, num_ref_aps_ids especifica el numero de los siguientes elementos sintacticos ref_aps_id [ i ]. El valor de num_ref_aps_ids puede estar en la gama entre 0 y 4, inclusive.
En este ejemplo, ref_aps_id [ i ] identifica el i-esimo conjunto de parametros de adaptacion al que hace referencia el conjunto de parametros de grupo.
El mismo valor de la ref_aps_id [ i ] puede estar presente en el bucle mas de una vez y, por lo tanto, se puede hacer referencia a mas de un tipo de parametros APS de la misma APS por parte del mismo GPS y puede aplicarse a los fragmentos codificados en relacion con el GPS .
En este ejemplo, ref_aps_param_type [ i ] especifica el tipo de los parametros APS incluidos en el i-esimo conjunto de parametros de adaptacion al que hace referencia el conjunto de parametros de grupo. El valor de ref_aps_parame_type[ i ] puede estar en la gama entre 0 y 3, inclusive. Los valores de 0 a 3, inclusive, para ref_aps_parame_type[ i ] corresponden a los tipos de parametro APS de la lista de escalado, filtro de desbloqueo, desviacion de adaptacion de muestra (SAO) y ALF, respectivamente. Los valores de ref_aps_parame_type [ i ] para dos valores cualesquiera diferentes de i no seran identicos, en algunos ejemplos.
En este ejemplo, gps_extension_flag igual a 0 especifica que no hay elementos sintacticos gps_extension_data_flag presentes en la estructura de sintaxis RBSP de agrupacion del conjunto de parametros. gps_extension_flag puede ser igual a 0 en flujos de bits que cumplen con la proxima norma HEVC. El valor 1 para gps_extension_flag puede estar reservado para un uso futuro por parte de ITU-T | ISO/IEC. Los descodificadores, como el descodificador de video 30, pueden ignorar todos los datos que siguen al valor 1 para gps_extension_flag en la unidad NAL de la agrupacion del conjunto de parametros.
En este ejemplo, gps_extension_data_flag puede tener cualquier valor. No tiene por que afectar la conformidad con los perfiles especificados en la proxima norma HEVC.
Los codificadores de video, tales como el codificador de video 20 y el descodificador de video 30, pueden aplicar el siguiente proceso para activar conjuntos de parametros para flujos de bits de una sola capa o de una sola vista, cuando el GPS se especifica de acuerdo con la Tabla 17 o se ajusta sustancialmente al ejemplo de la Tabla 17.
Una RBSP de un conjunto de parametros de adaptacion puede incluir parametros a los que pueden referirse indirectamente las unidades NAL de fragmento codificado de una o mas imagenes codificadas a traves de uno o mas conjuntos de parametros de grupo a los que hacen referencia las unidades NAL de fragmento codificado. Cada RBSP de un conjunto de parametros de adaptacion puede considerarse inicialmente no activa al comienzo del
5
10
15
20
25
30
35
40
45
50
55
60
65
funcionamiento del proceso de descodificacion. Como maximo una RBSP de un conjunto de parametros de adaptacion puede considerarse activa para cada tipo de parametros APS en cualquier momento dado durante el funcionamiento del proceso de descodificacion, y la activacion de cualquier RBSP de un conjunto de parametros de adaptacion particular para un tipo particular de parametros APS da como resultado la desactivacion de la RBSP de un conjunto de parametros de adaptacion previamente activa (si existe) para ese tipo particular de parametros APS.
Cuando una RBSP de un conjunto de parametros de adaptacion (con un valor particular de aps_id) no esta activa para un tipo particular de parametros de APS y se hace referencia a la misma indirectamente por parte de una unidad nAl de fragmento codificado para ese tipo particular de parametros APS (usando ese valor de aps_id) a traves de un conjunto de parametros de grupo al que hace referencia la unidad NAL de fragmento codificado, puede activarse para ese tipo particular de parametros APS. Esta RBSP del conjunto de parametros de adaptacion se denomina RBSP del conjunto de parametros de adaptacion activa para ese tipo particular de parametros APS hasta que se desactiva por la activacion de otra RBSP de un conjunto de parametros de adaptacion para ese tipo particular de parametros APS. Una RBSP de un conjunto de parametros de adaptacion, con ese valor particular de aps_id, puede estar disponible para el proceso de descodificacion antes de su activacion.
Una RBSP de un conjunto de parametros de imagen puede incluir parametros a los que las unidades NAL de fragmento codificadas de una o mas imagenes codificadas pueden referirse indirectamente a traves de uno o mas conjuntos de parametros de grupo a los que hacen referencia las unidades NAL de fragmento codificado. Cada RBSP de un conjunto de parametros de imagen puede considerarse inicialmente como activa al comienzo del funcionamiento del proceso de descodificacion. A lo sumo una RBSP de un conjunto de parametros de imagen puede considerarse activa en cualquier momento dado durante el funcionamiento del proceso de descodificacion, y la activacion de cualquier RBSP de un conjunto de parametros de imagen especffica da como resultado la desactivacion de la RBSP de un conjunto de parametros de imagen previamente activa (si la hubiera).
Cuando una RBSP de un conjunto de parametros de imagen (con un valor particular de pic_parameter_set_id) no esta activa y se hace referencia a la misma indirectamente por parte de una unidad NAL de fragmento codificado (utilizando ese valor de pic_parameter_set_id) a traves de un conjunto de parametros de grupo al que se hace referencia parte de la unidad NAL de fragmento codificado, puede activarse. Esta RBSP de un conjunto de parametros de imagen se denomina RBSP del conjunto de parametros de imagen activa hasta que se desactiva mediante la activacion de otra RBSP de un conjunto de parametros de imagen. Una RBSP de un conjunto de parametros de imagen, con ese valor particular de pic_parameter_set_id, puede estar disponible para el proceso de descodificacion antes de su activacion.
Cualquier conjunto de parametros de imagen NAL que contenga el valor de pic_parameter_set_id para la RBSP de conjunto de parametros de imagen activa para una imagen codificada puede tener el mismo contenido que el de la RBSP de conjunto de parametros de imagen activa para la imagen codificada a menos que siga la ultima unidad VCL NAL de la imagen codificada y preceda a la primera unidad VCL NAL de otra imagen codificada.
Una RBSP de un conjunto de parametros de secuencia puede incluir parametros a los que pueden referirse indirectamente las unidades NAL de fragmento codificado de una o mas imagenes codificadas a traves de uno o mas conjuntos de parametros de grupo a los que hacen referencia las unidades NAL de fragmento codificado o puede hacerse referencia a la misma por parte de una o mas unidades SEI NAL que contengan un mensaje SEI de perfodo de almacenamiento intermedio. Cada RBSP de un conjunto de parametros de secuencia puede considerarse inicialmente no activa al comienzo del funcionamiento del proceso de descodificacion. A lo sumo una RBSP de un conjunto de parametros de secuencia puede considerarse activa en cualquier momento dado durante el funcionamiento del proceso de descodificacion, y la activacion de cualquier RBSP de un conjunto de parametros de secuencia especffica da como resultado la desactivacion de la RBSP de un conjunto de parametros de secuencia previamente activa (si la hubiera).
Cuando una RBSP de un conjunto de parametros de secuencia (con un valor particular de seq_parameter_set_id) no esta ya activa y se hace referencia a la mismo indirectamente por parte de una unidad NAL de fragmento codificado a traves de un conjunto de parametros de grupo al que hace referencia la unidad NAL de fragmento codificado (utilizando ese valor de seq_parameter_set_id) o se hace referencia a la misma por parte de una unidad SEI NAL que contiene un mensaje SEI de perfodo de almacenamiento intermedio (que utiliza ese valor de seq_parameter_set_id), puede ser activada. Esta RBSP del conjunto de parametros de secuencia se denomina RBSP del conjunto de parametros de secuencia activa hasta que se desactiva mediante la activacion de otra RBSP de un conjunto de parametros de secuencia. Una RBSP de un conjunto de parametros de secuencia, con ese valor particular de seq_parameter_set_id y contenida dentro de una unidad de acceso con temporal_id igual a 0, puede estar disponible para el proceso de descodificacion antes de su activacion. Una RBSP de un conjunto de parametros de secuencia activada permanecera activa durante la secuencia entera de video codificado.
Una RBSP de un conjunto de parametros de video puede incluir parametros a los que pueden referirse indirectamente las unidades NAL de fragmento codificado de una o mas imagenes codificadas a traves de uno o mas conjuntos de parametros de grupo a los que hacen referencia las unidades NAL de fragmento codificado, o puede hacerse referencia a los mismos por parte de una o mas unidades SEI NAL que contienen un mensaje SEI de
5
10
15
20
25
30
35
40
45
50
55
60
65
periodo de almacenamiento intermedio. Cada RBSP de un conjunto de parametros de video puede considerarse inicialmente no activa al comienzo del funcionamiento del proceso de descodificacion. A lo sumo una RBSP de un conjunto de parametros de video puede considerarse activa en cualquier momento dado durante el funcionamiento del proceso de descodificacion, y la activacion de cualquier RBSP de un conjunto de parametros de video especffica da como resultado la desactivacion de la RBSP de un conjunto de parametros de video previamente activa (si la hubiera).
Cuando una RBSP de un conjunto de parametros de video (con un valor particular de video_parameter_set_id) no esta ya activa y se hace referencia a la misma indirectamente por parte de una unidad NAL de fragmento codificado a traves de un conjunto de parametros de grupo al que hace referencia la unidad NAL de fragmento codificado (utilizando ese valor de video_parameter_set_id) o se hace referencia a la misma por parte de una unidad SEI NAL que contiene un mensaje SEI de periodo de almacenamiento intermedio (que usa ese valor de video_parameter_set_id), puede activarse. Esta RBSP del conjunto de parametros de video se denomina RBSP del conjunto de parametros de video activa hasta que se desactiva mediante la activacion de otra RBSP del conjunto de parametros de video. Una RBSP de un conjunto de parametros de video, con ese valor particular de video_parameter_set_id y contenido dentro de una unidad de acceso con temporal_id igual a 0, estara disponible para el proceso de descodificacion antes de su activacion. Una RBSP de un conjunto de parametros de video activada permanecera activa durante la secuencia entera de video codificado.
Cualquier unidad de NAL de conjunto de parametros de secuencia que contenga el valor de seq_parameter_set_id para la RBSP del conjunto de parametros de secuencia activa para una secuencia de video codificado puede tener el mismo contenido que el de la RBSP del conjunto de parametros de secuencia activos para la secuencia de video codificada, a menos que siga a la ultima unidad de acceso de la secuencia de video codificada y preceda a la primera unidad de VCL NAL y a la primera unidad de SEI NAL que contiene un mensaje de SEI de periodo de almacenamiento intermedio (cuando este presente) de otra secuencia de video codificada.
Cualquier unidad de NAL del conjunto de parametros de video que contenga el valor de video_parameter_set_id para la RBSP del conjunto de parametros de video activa para una secuencia de video codificada puede tener el mismo contenido que el de la RBSP de conjunto de parametros de video activa para la secuencia de video codificada, a menos que siga a la ultima unidad de acceso de la secuencia de video codificada y pueda preceder a la primera unidad de VCL NAL y a la primera unidad de SEI NAL que contiene un mensaje de SEI de periodo de almacenamiento intermedio (cuando este presente) de otra secuencia de video codificada.
Todas las restricciones que se expresan en la relacion entre los valores de los elementos sintacticos (y los valores de las variables derivadas de esos elementos sintacticos) en conjuntos de parametros de video, conjuntos de parametros de secuencia, conjuntos de parametros de imagen y conjuntos de parametros de adaptacion y otros elementos sintacticos son expresiones de restricciones que pueden aplicarse solamente a los conjuntos de parametros de video activos, al conjunto de parametros de secuencia activos, al conjunto de parametros de imagen activos y al conjunto de parametros de adaptacion activos para cada tipo particular de parametros APS. Si existe cualquier RBSP de un conjunto de parametros de video que no este activada en el flujo de bits, sus elementos sintacticos pueden tener valores que se ajusten a las restricciones especificadas si se activaron por referencia en un flujo de bits que se ajusta de otro modo. Si existe cualquier RBSP de un conjunto de parametros de secuencia que no este activada en el flujo de bits, sus elementos sintacticos pueden tener valores que se ajusten a las restricciones especificadas si se activaron por referencia en un flujo de bits que se ajusta de otro modo. Si existe cualquier RBSP de un conjunto de parametros de imagen que no este nunca activada en el flujo de bits, sus elementos sintacticos pueden tener valores que se ajusten a las restricciones especificadas si se activaron por referencia en un flujo de bits que se ajusta de otro modo. Si existe cualquier RBSP de conjunto de parametros de adaptacion que no este nunca activada en el flujo de bits, sus elementos sintacticos pueden tener valores que se ajusten a las restricciones especificadas si se activaron por referencia en un flujo de bits que se ajusta de otro modo.
Durante el funcionamiento del proceso de descodificacion, pueden considerarse en efecto los valores de los parametros del conjunto de parametros de video activos, el conjunto de parametros de secuencia activos, el conjunto de parametros de imagen activos y el conjunto de parametros de adaptacion activos para cada tipo de parametros APS. Para la interpretacion de los mensajes SEI, pueden considerarse en efecto los valores de los parametros del conjunto de parametros de video, conjunto de parametros de secuencia, conjunto de parametros de imagen y conjunto de parametros de adaptacion que estan activos para el funcionamiento del proceso de descodificacion para las unidades VCL NAL de la imagen codificada en la misma unidad de acceso a menos que se especifique lo contrario en la semantica de mensajes SEI.
La FIG. 7 es un diagrama de flujo que ilustra un ejemplo de procedimiento para la codificacion de datos de video de acuerdo con las tecnicas de esta divulgacion. Aunque se describe con respecto al codificador de video 20, debe entenderse que otros dispositivos de codificacion de video pueden configurarse para llevar a cabo el procedimiento de la FIG. 7.
Inicialmente, en este ejemplo, el codificador de video 20 recibe un flujo de bits que incluye una o mas capas de datos de video sin procesar (100). Por ejemplo, la fuente de video 18 (FIG. 1) puede proporcionar datos de video
5
10
15
20
25
30
35
40
45
50
55
60
65
multivista al codificador de video 20. De forma alternativa, el codificador de video 20, o un preprocesador del mismo, puede dividir un flujo de bits de video sin procesar en una pluralidad de diversas capas, por ejemplo, capas de resolucion espacial, capas de calidad, capas temporales o similares. En otros ejemplos mas, un flujo de bits puede dividirse en una combinacion de varias capas, por ejemplo, cualquier combinacion de vistas, capas de resolucion espacial, capas de calidad, capas temporales o similares.
El codificador de video 20 puede determinar uno o mas parametros comunes para secuencias correspondientes entre un conjunto de capas (102). Las secuencias correspondientes pueden ser secuencias que tienen posiciones temporales correspondientes en diferentes capas. Es decir, una primera secuencia, que tiene un tiempo de inicio (en terminos de tiempo de visualizacion) de T1 y un tiempo de finalizacion (de nuevo en terminos de tiempo de visualizacion) de T2, y una segunda secuencia, que tambien tiene un tiempo de inicio de T1 y un tiempo de terminacion de T2, se puede decir que se corresponden entre si. En particular, la primera secuencia puede formar parte de una primera capa y la segunda secuencia puede formar parte de una segunda capa diferente. Una "secuencia" puede incluir una serie de imagenes consecutivas en orden de descodificacion, por ejemplo, comenzando con una imagen de actualizacion de descodificacion instantanea (IDR) y terminando inmediatamente antes de una imagen IDR posterior en el orden de descodificacion. En general, los parametros pueden corresponder a un conjunto de secuencias correspondientes de una o mas capas, por ejemplo, N capas, donde N es un numero entero. El codificador de video 20 puede entonces codificar un VPS que incluye datos para los parametros determinados (104). Por ejemplo, el codificador de video 20 puede codificar un VPS correspondiente a uno de los ejemplos de la Tabla 2 o de la Tabla 5.
El codificador de video 20 tambien puede determinar parametros comunes para una secuencia dentro de una capa (106). La secuencia puede comprender una de las secuencias correspondientes a otras secuencias en otras capas para las que se codifico el VPS. El codificador de video 20 puede codificar un conjunto de parametros de secuencia (SPS) que incluye los parametros comunes para la secuencia (108). Por lo tanto, debe entenderse que el VPS y el SPS son estructuras de datos separadas y que corresponden a diferentes tipos de datos de video. Mientras que un VPS puede corresponder a un conjunto de secuencias correspondientes entre una pluralidad de capas, el SPS corresponde a una secuencia en una capa. El SPS puede ajustarse sustancialmente a un SPS de H.264/AVC, el SPS de H.264/AVC ampliado por MVC (ilustrado en la Tabla 1 anterior), la proxima norma HEVC, o el ejemplo de la Tabla 16 descrito anteriormente. Ademas, el codificador de video 20 puede codificar un conjunto de parametros de imagen (PPS) para una imagen en la secuencia (110). El PPS puede ajustarse sustancialmente a un SPS de H.264/AVC, la proxima norma HEVC, o el ejemplo de la Tabla 13 descrito anteriormente. Aunque el procedimiento de la FIG. 7 muestra la codificacion de solo un PPS, debe entenderse que se pueden codificar multiples PPS. Una o mas imagenes pueden referirse al mismo PPS.
El codificador de video 20 puede determinar entonces si la capa reciente para la que se codifico un SPS y un PPS es la ultima capa (112). Si la ultima capa todavfa no se ha tratado (ramificacion "NO" de 112), el codificador de video 20 puede seleccionar una capa siguiente y codificar un SPS y uno o mas PPS para la siguiente capa, por ejemplo, de acuerdo con los pasos 106-110. Despues de que se haya tratado la ultima capa (ramificacion "SI" de 112), el codificador de video 20 puede codificar datos de video de las diversas capas basandose en los datos de los VPS, SPS y PPS. Diversos ejemplos de codificacion de datos de video basados, al menos en parte, en un VPS se describen con mayor detalle a continuacion con respecto a las FIGs. 9-12.
Aunque no se muestra en el ejemplo de la FIG. 7, en algunos ejemplos, el codificador de video 20 puede codificar adicionalmente uno o mas LPS y/o uno o mas GPS, como se ha descrito anteriormente. Los LPS pueden ajustarse sustancialmente a los ejemplos de la Tabla 9, Tabla 10 o Tabla 12, mientras que el GPS puede ajustarse sustancialmente a los ejemplos de la Tabla 14, Tabla 15 o Tabla 17. En tales ejemplos, el codificador de video 20 codifica los datos de video tambien basandose, al menos en parte, en los LPS y/o los GPS.
De esta manera, el procedimiento de la FIG. 7 representa un ejemplo de un procedimiento que incluye codificar un conjunto de parametros de video (VPS) para una o mas capas de datos de video, en el que cada una de una o mas capas de datos de video se refiere al vPs, y codificar una o mas capas de datos de video basandose, al menos en parte, en el VPS.
La FIG. 8 es un diagrama de flujo que ilustra un ejemplo de procedimiento de descodificacion de datos de video de acuerdo con las tecnicas de esta divulgacion. Aunque se describe con respecto al descodificador de video 30, debe entenderse que otros dispositivos de descodificacion de video pueden configurarse para llevar a cabo el procedimiento de la FIG. 8.
Inicialmente, el descodificador de video 30 recibe un flujo de bits que incluye un VPS, uno o mas SPS, y uno o mas PPS para capas de datos de video codificados (120). El descodificador de video 30 puede entonces descodificar el VPS, que incluye parametros comunes para secuencias correspondientes entre una o mas capas (122). Del mismo modo, el descodificador de video 30 puede descodificar un conjunto de parametros de secuencia que incluye parametros comunes para una secuencia de una capa (124). Ademas, el descodificador de video 30 puede descodificar un conjunto de parametros de imagen que incluye parametros para una imagen de la secuencia (126). Como se ha analizado anteriormente, una o mas imagenes pueden referirse al mismo PPS y, por lo tanto, los
5
10
15
20
25
30
35
40
45
50
55
60
65
parametros del PPS pueden considerarse comunes a una o mas imageries. Del mismo modo, el descodificador de video 30 puede descodificar una pluralidad de PPS para la secuencia, aunque no se muestra en la FIG. 8.
Ademas, el descodificador de video 30 puede determinar si la capa mas reciente era la ultima capa a tratar (128). Si la capa mas reciente no era la ultima capa (ramificacion "NO" de 128), el descodificador de video 30 puede proceder a descodificar un SPS y uno o mas PPS para una capa posterior de acuerdo con las etapas 124 y 126. Por otra parte, si la capa mas reciente era la ultima capa (ramificacion "YES" de 128), el descodificador de video 30 puede proceder a descodificar datos de video de las capas basandose en los VPS, SPS y PPS (130). Ejemplos de datos de video de codificacion basados, al menos en parte, en un VPS se analizan con mayor detalle con respecto a las FIGs. 9-12.
Aunque no se muestra en el ejemplo de la FIG. 8, en algunos ejemplos, el descodificador de video 30 puede descodificar adicionalmente uno o mas LPS y/o uno o mas GPS, como se ha descrito anteriormente. Los LPS pueden ajustarse sustancialmente a los ejemplos de la Tabla 9, Tabla 10 o Tabla 12, mientras que el GPS puede ajustarse sustancialmente a los ejemplos de la Tabla 14, Tabla 15 o Tabla 17. En tales ejemplos, el descodificador de video 30 descodifica los datos de video basandose tambien, al menos en parte, en los LPS y/o los GPS.
De esta manera, el procedimiento de la FIG. 8 representa un ejemplo de un procedimiento que incluye codificar un conjunto de parametros de video (VPS) para una o mas capas de datos de video, en el que cada una de una o mas capas de datos de video se refiere al VPS y codifica una o mas capas de datos de video basandose al menos en parte en el VPS.
La FIG. 9 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en un cierto numero de capas temporales como se senala en un VPS. El procedimiento de la FIG. 9 puede ser realizado por el codificador de video 20 y/o el descodificador de video 30. Para los propositos del ejemplo, el procedimiento de la FIG. 9 se describe con respecto al descodificador de video 30.
En este ejemplo, el descodificador de video 30 codifica (es decir, descodifica) un VPS que indica un cierto numero de capas temporales en datos de video (150), por ejemplo, de una o mas capas a las que corresponde el VPS. Por ejemplo, el descodificador de video 30 puede descodificar "cnt_t" como se describe con respecto a la Tabla 2 anterior. Para mencionar otro ejemplo, el descodificador de video 30 puede descodificar num_temporal_layers_minus1, como se describe con respecto a la Tabla 5 anterior.
Basandose en esta indicacion, en este ejemplo, el descodificador de video 30 descodifica identificadores temporales para cada una de las capas temporales (152). Del mismo modo, el descodificador de video 30 puede determinar los valores de identificador de la imagen de referencia basandose en el numero de capas temporales (154). Por ejemplo, el descodificador de video 30 puede configurarse para determinar que, para una imagen actual en la capa N, la imagen actual no usara imagenes en o sobre la capa N+1 como referencia. Por lo tanto, el descodificador video 30 puede determinar identificadores para posibles imagenes de referencia en capas en o debajo de la capa N. Ademas, el descodificador de video 30 puede descodificar datos de imagenes en la capa temporal N usando datos de referencia de capas hasta (e incluyendo) la capa N (156) . Por lo tanto, la FIG. 9 representa un ejemplo de un procedimiento que incluye codificacion de datos de un VPS indicativo de un numero maximo de capas temporales en una o mas capas de datos de video y codificacion de una o mas capas basandose, al menos en parte, en el VPS.
La FIG. 10 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en un cierto numero de imagenes a reordenar en una o mas capas e imagenes a almacenar en una memoria intermedia de imagenes descodificadas. El procedimiento de la FIG. 10 puede ser realizado por el codificador de video 20 y/o descodificador de video 30. Para los propositos del ejemplo, el procedimiento de la FIG. 10 se describe con respecto al descodificador de video 30.
En este ejemplo, el descodificador de video 30 descodifica un VPS que indica un cierto numero de imagenes a reordenar en una o mas capas de datos de video y un cierto numero de imagenes a almacenar en una memoria intermedia de imagenes descodificadas (por ejemplo, memoria de imagenes de referencia 82) en un momento dado (160). Por ejemplo, el descodificador de video 30 puede descodificar un elemento sintactico del VPS que corresponde sustancialmente a num_reorder_pics como se describe con respecto a la Tabla 16 anterior y/o informacion de restriccion del flujo de bits que especifica un tamano de DPB. En otros ejemplos, el VPS podrfa incluir solamente uno u otro, y no necesariamente ambos, del numero de imagenes a reordenar y del numero de imagenes que se van a almacenar en la memoria intermedia de imagenes descodificadas. El descodificador de video 30 puede entonces gestionar la memoria intermedia de imagenes descodificadas (por ejemplo, la memoria de imagenes de referencia 82) basandose en el numero de imagenes que se van a reordenar y/o almacenar (162). Por ejemplo, el descodificador de video 30 puede eliminar imagenes de la memoria 82 de la imagen de referencia cuando se almacena mas que el numero de imagenes a almacenar en la memoria 82 de imagenes de referencia.
El descodificador de video 30 tambien puede determinar los valores de identificador de la imagen de referencia basandose en el numero de imagenes en la DPB (es decir, en la memoria de imagenes de referencia 82) (164). Ademas, el descodificador de video 30 puede descodificar datos de imagenes basandose en los valores de
5
10
15
20
25
30
35
40
45
50
55
60
65
identificador de la imagen de referencia (166). De este modo, el procedimiento de la FIG. 10 representa un ejemplo de un procedimiento que incluye la codificacion de datos de un VPS indicativo de un cierto numero de imagenes a almacenar en una memoria intermedia de imagenes descodificadas (DPB) durante la descodificacion de una o mas capas y un procedimiento que incluye la codificacion de datos de un VPS indicativo de un cierto numero de tramas a reordenar en al menos una de una o mas capas.
La FIG. 11 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en parametros de descodificador de referencia hipoteticos (HRD) senalados en un VPS. El procedimiento de la FIG. 11 puede ser realizado por el codificador de video 20 y/o el descodificador de video 30. Para los propositos del ejemplo, el procedimiento de la FIG. 11 se describe con respecto al descodificador de video 30.
En este ejemplo, el descodificador de video 30 descodifica un VPS que indica los parametros HRD (170). El descodificador de video 30 puede determinar adicionalmente los tiempos de extraccion para las imagenes de una memoria intermedia de imagenes codificadas (CPB) basandose en los parametros HRD (172). El descodificador de video 30 puede a continuacion eliminar datos de la CPB basandose en los tiempos de eliminacion determinados (174), y descodificar los datos eliminados de la CPB. Del mismo modo, el procedimiento de la FIG. 11 representa un ejemplo de un procedimiento que incluye la codificacion de datos de un vPs indicativo de uno o mas parametros de descodificador de referencia hipotetico (HRD) y codificacion de datos de una o mas capas basandose en los parametros de HDR.
La FIG. 12 es un diagrama de flujo que ilustra un ejemplo de procedimiento de codificacion de datos de video basandose, al menos en parte, en datos de ampliacion senalados en un VPS. El procedimiento de la FIG. 12 puede ser realizado por el codificador de video 20 y/o descodificador de video 30. Para los propositos del ejemplo, el procedimiento de la FIG. 12 se describe con respecto al descodificador de video 30.
El descodificador de video 30, en este ejemplo, descodifica datos de un VPS indicando si el VPS incluye datos de ampliacion (180). Por ejemplo, el descodificador de video 30 puede descodificar un vps_extension_flag del VPS. El descodificador de video 30 determina entonces si los datos indican que el VPS incluye datos de ampliacion (182). Si los datos indican que el VPS incluye datos de ampliacion (ramificacion "SI" de 182), el descodificador de video 30 codifica datos de ampliacion VPS para una o mas herramientas de codificacion de ampliacion (184) y descodifica datos de video usando las herramientas de codificacion de ampliacion y datos de ampliacion 186). Por otra parte, si los datos indican que el VPS no incluye datos de ampliacion (ramificacion "NO" de 182), el descodificador de video 30 puede descodificar los datos de video usando herramientas de codificacion convencionales (188). De esta manera, el procedimiento de la FIG. 12 representa un ejemplo de un procedimiento que incluye codificacion de datos de un VPS indicativo de si el VPS incluye una ampliacion mas alla de una norma correspondiente y cuando el VPS incluye la ampliacion, datos para la ampliacion, asf como codificacion de datos de video basandose en los datos de ampliacion del VPS.
Debe reconocerse que, dependiendo del ejemplo, ciertos actos o sucesos de cualquiera de las tecnicas descritas en el presente documento pueden realizarse en una secuencia distinta, pueden anadirse, fundirse u omitirse por completo (por ejemplo, no todos los actos o sucesos descritos son necesarios para la puesta en practica de las tecnicas). Ademas, en ciertos ejemplos, los actos o sucesos pueden realizarse simultaneamente, por ejemplo, mediante el procesamiento de multiples hebras, el procesamiento de interrupciones o multiples procesadores, en lugar de secuencialmente.
En uno o mas ejemplos, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinacion de los mismos. Si se implementan en software, las funciones, como una o mas instrucciones o codigo, pueden almacenarse en, o transmitirse por, un medio legible por ordenador, y ejecutarse mediante una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador, que corresponden a un medio tangible tal como medios de almacenamiento de datos o medios de comunicacion que incluyen cualquier medio que facilite la transferencia de un programa informatico desde un lugar a otro, por ejemplo, de acuerdo con un protocolo de comunicacion. De esta manera, los medios legibles por ordenador pueden corresponder, en general, a (1) medios de almacenamiento tangibles y legibles por ordenador, que sean no transitorios, o (2) un medio de comunicacion tal como una senal o una onda portadora. Los medios de almacenamiento de datos pueden ser cualesquiera medios disponibles a los que se puede acceder desde uno o mas ordenadores o uno o mas procesadores para recuperar instrucciones, codigo y/o estructuras de datos para implementar las tecnicas descritas en la presente divulgacion. Un producto de programa informatico puede incluir un medio legible por ordenador.
A modo de ejemplo, y no de limitacion, tales medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco optico, almacenamiento de disco magnetico u otros dispositivos de almacenamiento magnetico, memoria flash o cualquier otro medio que pueda utilizarse para almacenar codigo de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador. Ademas, cualquier conexion recibe adecuadamente la denominacion de medios legibles por ordenador. Por ejemplo, si las instrucciones se transmiten desde una sede de la Red, un servidor u otra fuente
5
10
15
20
25
30
35
40
remota usando un cable coaxial, un cable de fibra optica, un par trenzado, una linea de abonado digital (DSL) o tecnologfas inalambricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra optica, el par trenzado, la DSL o las tecnologfas inalambricas tales como infrarrojos, radio y microondas se incluyen en la definicion de medio. Sin embargo, deberfa entenderse que los medios de almacenamiento legibles por ordenador y los medios de almacenamiento de datos no incluyen conexiones, ondas portadoras, senales u otros medios transitorios, sino que, en cambio, se orientan a medios de almacenamiento tangibles no transitorios. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco de laser, el disco optico, el disco versatil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos normalmente reproducen datos de manera magnetica, mientras que otros discos reproducen los datos de manera optica con laser. Las combinaciones de lo anterior tambien deberfan incluirse dentro del alcance de los medios legibles por ordenador.
Las instrucciones pueden ser ejecutadas por uno o mas procesadores, tales como uno o mas procesadores de senales digitales (DSP), microprocesadores de proposito general, circuitos integrados especfficos de la aplicacion (ASIC), formaciones logicas programables en el terreno (FPGA) u otros circuitos logicos integrados o discretos equivalentes. Por consiguiente, el termino "procesador", como se usa en el presente documento, puede referirse a cualquier estructura anterior o a cualquier otra estructura adecuada para la implementacion de las tecnicas descritas en el presente documento. Ademas, en algunos aspectos, la funcionalidad descrita en el presente documento puede proporcionarse dentro de modulos de hardware y/o software especfficos configurados para la codificacion y la descodificacion, o incorporarse en un codec combinado. Ademas, las tecnicas podrfan implementarse completamente en uno o mas circuitos o elementos logicos.
En otros ejemplos mas, esta divulgacion contempla un medio legible por ordenador que comprende una estructura de datos almacenada en el mismo, en el que la estructura de datos incluye un flujo de bits codificado consistente con esta divulgacion. En particular, el flujo de bits codificado puede incluir una o mas capas de datos de video y un parametro de video (VPS) para las una o mas capas de datos de video, en el que cada una de las una o mas capas de datos de video se refiere al VPS y una o mas capas de datos de video se codifican basandose, al menos en parte, en el VPS.
Las tecnicas de la presente divulgacion se pueden implementar en una amplia variedad de dispositivos o aparatos, incluyendo un telefono inalambrico, un circuito integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chips). En la presente divulgacion se describen varios componentes, modulos o unidades para enfatizar aspectos funcionales de dispositivos configurados para realizar las tecnicas divulgadas, pero no requieren necesariamente la realizacion mediante diferentes unidades de hardware. Mas bien, como se ha descrito anteriormente, pueden combinarse diversas unidades en una unidad de hardware de codec, o ser proporcionadas por una coleccion de unidades de hardware interoperativas, incluyendo uno o mas procesadores, como se ha descrito anteriormente, conjuntamente con el software y/o firmware adecuado.
Se han descrito diversos ejemplos. Estos y otros ejemplos estan dentro del alcance de las siguientes reivindicaciones.

Claims (9)

1.
5
10 15
20 2.
25
3.
30
35
4.
40
45
5.
50
55 60
65 6.
REIVINDICACIONES
Un procedimiento de codificacion de datos de video, comprendiendo el procedimiento:
codificacion (104, 122) de un conjunto de parametros de video, VPS, para una pluralidad de capas de datos de video, en el que cada una de la pluralidad de capas de datos de video se refiere al VPS, y en la que la codificacion del VPS comprende:
codificacion de datos del VPS indicativos de un cierto numero de tramas a reordenar en al menos una entre la pluralidad de capas de datos de video,
codificacion de datos del VPS indicativos de un cierto numero de imagenes a almacenar en una memoria intermedia de imagenes descodificadas, DPB, durante la descodificacion de la pluralidad de capas de datos de video, y
codificacion de datos del VPS indicativos de un numero maximo de capas temporales en la pluralidad de capas de datos de video; y
codificacion de (114, 130) la pluralidad de capas de datos de video basandose, al menos en parte, en el VPS.
El procedimiento segun la reivindicacion 1, en el que la codificacion del VPS comprende ademas al menos uno entre:
codificacion de datos de los VPS indicativos de uno o mas conjuntos de descodificadores de referencia hipoteticos, HRD, parametros; o
codificacion de datos del VPS indicativos de si el VPS incluye una ampliacion mas alla de una norma correspondiente, y cuando el VPS incluye la ampliacion, datos para la ampliacion.
El procedimiento segun la reivindicacion 1, en el que la codificacion de la pluralidad de capas de datos de video comprende al menos uno entre:
codificacion de la pluralidad de capas de datos de video de acuerdo con la Codificacion de Video de Alta Eficiencia, HEVC; o
codificacion de la pluralidad de capas de datos de video de acuerdo con, al menos uno entre, Codificacion de Video multivista, MVC y Codificacion de Video Escalable, SVC.
El procedimiento segun la reivindicacion 1, en el que codificar el VPS comprende codificar informacion que especifica, para una o mas dimensiones de la pluralidad de capas de datos de video, una o mas de un cierto numero de capas de prioridad en la pluralidad de capas de datos de video, un cierto numero de capas de dependencia en la pluralidad de capas de datos de video, un cierto numero de capas temporales en la pluralidad de capas de datos de video, un numero maximo de capas de calidad para cualquiera de las capas de dependencia en la pluralidad de capas de datos de video y un numero maximo de vistas en la pluralidad de capas de datos de video y, preferentemente, en el que cuando un subconjunto de la pluralidad de capas de datos de video tiene la misma resolucion espacial y la misma profundidad de bits, cada una de las capas del subconjunto corresponde a una diferente de las capas de dependencia.
El procedimiento segun la reivindicacion 4, en el que codificar el VPS comprende codificar informacion que define una asignacion de un indice de muestra a un indicador de caracterfsticas, y en el que la codificacion de la informacion que define la asignacion comprende al menos uno entre:
codificacion de informacion que especifica un indicador de caracterfsticas respectivo para cada uno de una pluralidad de indices de caracterfsticas cuando un indicador de caracterfsticas que define caracterfsticas de una dimension de la pluralidad de capas de datos de video no esta dentro de un rango de fndice de cero a un contador de dimension de muestra menos 1 en el que el contador se define mediante un fndice; o
codificacion de una o mas de una resolucion espacial respectiva para cada uno de una pluralidad de indices de dependencia, una velocidad de tramas para cada uno de una pluralidad de indices temporales, un identificador de vista para cada uno de una pluralidad de indices de vista, un par de valores de profundidad especfficos para la luminancia y crominancia para cada uno de una pluralidad de indices de profundidad de bits, y un indicador de formato de muestreo de crominancia especffico para cada uno de una pluralidad de formatos de muestreo de crominancia.
El procedimiento segun la reivindicacion 1, en el que codificar el VPS comprende codificar informacion que define parametros de control y uno o mas indicadores de habilitacion / deshabilitacion de herramienta y
7.
10
15
20 8.
25
30
35
40
9.
45
50
10.
55
11.
60
12.
65 13.
preferentemente, en el que los parametros de control y el uno o mas indicadores de habilitacion / deshabilitacion de herramienta comprenden uno o mas de pcm_bit_depth_luma_minus1, un
pcm_bit_depth_chroma_minus1, un loop_filter_across_slice_flag, un pcm_loop_filter_disable_flag, un temporal_id_nesting_flag, uno o mas elementos sintacticos relacionados con componentes, un chroma_pred_from_luma_enabled_flag, un sample_adaptive_offset_enabled_flag, un
adaptive_loop_filter_enabled_flag, y un inter_4x4_enabled_fla.
El procedimiento segun la reivindicacion 1, en el que codificar el VPS comprende codificar informacion que define uno o mas descriptores de punto de operacion y, preferentemente, en el que codificando la informacion que define el uno o mas descriptores de punto de operacion comprende informacion de codificacion que define uno o mas de un cierto numero de puntos de operacion maxima, dependencia entre diferentes capas o vistas, perfil y nivel para cada uno de los puntos de operacion, para cada punto de operacion, capa de codificacion de video de punto de operacion, VCL, capa de abstraccion de red, NAL, representacion de unidad, para cada dimension uno o mas de un valor de indice especifico, una gama de posibles valores de indice para la dimension, y una lista de valores de indice, velocidad de bits para cada uno de los puntos de operacion, dependencia entre los puntos de operacion, restricciones para cada uno de los puntos de operacion, informacion de usabilidad de video, VUI, para cada uno de los puntos de operacion, y VUI para cada una de la pluralidad de capas de datos de video.
El procedimiento segun la reivindicacion 1, que comprende ademas codificar un respectivo conjunto de parametros de secuencia de capas, LPS, para cada una de la pluralidad de capas de datos de video, en el que codificar la pluralidad de capas de datos de video basandose al menos en parte en el VPS comprende codificar la pluralidad de capas de datos de video basandose al menos en parte en el VPS y el LPS respectivo y, preferentemente, en el que la codificacion del LPS respectivo para cada una de la pluralidad de capas de datos de video comprende al menos uno de entre:
codificacion de informacion que define una indicacion de dimension de muestra que indica, para cada dimension, un indice para cada dimension;
codificacion de informacion que define los parametros de control y los indicadores de habilitacion / deshabilitacion de herramientas y, preferentemente, en el que los parametros de control y el uno o mas indicadores de habilitacion / deshabilitacion de herramientas comprenden uno o mas de un pcm_bit_depth_luma_minus1, un pcm_bit_depth_chroma_minus1, a loop_filter_across_slice_flag, un pcm_loop_filter_disable_flag, uno o mas elementos sintacticos relacionados con componentes, un chroma_pred_from_luma_enabled_flag, un sample_adaptive_offset_enabled_flag, un
adaptive_loop_filter_enabled_flag, y una unidad de codificacion, CU, jerarqufa; o
codificacion de informacion que define la informacion de uno o mas conjuntos de parametros diferentes que se aplican a al menos uno de un fragmento, un grupo de fragmentos, una imagen y varias imagenes que se refieren a un conjunto de parametros de imagen comun, PPS.
El procedimiento segun la reivindicacion 1, que comprende ademas codificar uno o mas conjuntos de parametros de imagen, PPS de tal manera que los PPS no se refieren al VPS, y no se refieren a conjuntos de parametros de secuencia de capas, LPS de la pluralidad de capas de datos de video y, preferiblemente, en el que la codificacion de la pluralidad de capas de datos de video basandose al menos en parte en el VPS comprende codificar la pluralidad de capas de datos de video basandose al menos en parte en el VPS, los PPS y los LPS, de tal manera que cuando un elemento sintactico de uno de los PPS entra en conflicto con el VPS o uno respectivo de los lPs, codificar una correspondiente de la pluralidad de capas de datos de video basandose en el elemento sintactico de uno de los PPS.
El procedimiento segun la reivindicacion 1, que comprende ademas la codificacion de un conjunto de parametros de agrupacion, GPS, que agrupa todos los conjuntos de parametros, incluyendo el VPS, para la pluralidad de capas de datos de video juntas y preferentemente, en el que codificar el GPS comprende la codificacion de informacion que define un identificador del GPS, comprendiendo ademas el procedimiento la codificacion de informacion de una cabecera de fragmento correspondiente al identificador del GPS.
El procedimiento segun la reivindicacion 1, en el que la codificacion de la pluralidad de capas de datos de video comprende descodificar la pluralidad de capas de datos de video, y en el que la codificacion del VPS comprende analizar el VPS.
El procedimiento segun la reivindicacion 1, en el que la codificacion de la pluralidad de capas de datos de video comprende codificar la pluralidad de capas de datos de video, y en el que codificar el VPS comprende construir el VPS.
Un dispositivo para codificar datos de video, comprendiendo el dispositivo:
5
10
15
20
25
30
medios para codificar (20, 30) un conjunto de parametros de video, VPS, para una pluralidad de capas de datos de video, en el que cada una de la pluralidad de capas de datos de video se refiere al VPS y en el que los medios para codificar el VPS comprenden:
medios para codificar datos del VPS indicativos de un cierto numero de tramas a reordenar en al menos una entre la pluralidad de capas de datos de video,
medios para codificar datos del VPS indicativos de un cierto numero de imagenes a almacenar en una memoria intermedia de imagenes descodificadas, DPB, durante la descodificacion de la pluralidad de capas de datos de video, y
medios para codificar datos del VPS indicativos de un numero maximo de capas temporales en la pluralidad de capas de datos de video; y
medios para codificar (20, 30) la pluralidad de capas de datos de video basandose al menos en parte en el VPS.
El dispositivo segun la reivindicacion 13, en el que los medios para codificar el VPS comprenden ademas al menos uno entre:
medios para codificar datos del VPS indicativos de uno o mas conjuntos de parametros de descodificador hipotetico de referencia, HRD; o
medios para codificar datos del VPS indicativos de si el VPS incluye una ampliacion mas alla de una norma correspondiente, y cuando el VPS incluya la ampliacion, datos para la ampliacion y en el que los medios para codificar la pluralidad de capas de datos de video comprenden medios para codificar la pluralidad de capas de datos de video de acuerdo con uno de Codificacion de Video de Alta Eficiencia, HEVC, Codificacion de Video multivista, MVC y Codificacion de Video Escalable, SVC.
Un medio de almacenamiento legible por ordenador que tiene instrucciones almacenadas en el mismo que, cuando son ejecutadas, hacen que un procesador realice el procedimiento segun cualquiera de las reivindicaciones 1 -12.
ES13700835.5T 2012-01-14 2013-01-11 Codificación de conjuntos de parámetros y cabeceras de unidad NAL para codificación de vídeo Active ES2633651T3 (es)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US201261586777P 2012-01-14 2012-01-14
US201261586777P 2012-01-14
US201261587070P 2012-01-16 2012-01-16
US201261587070P 2012-01-16
US201261588629P 2012-01-19 2012-01-19
US201261588629P 2012-01-19
US201261637195P 2012-04-23 2012-04-23
US201261637195P 2012-04-23
US201261637774P 2012-04-24 2012-04-24
US201261637774P 2012-04-24
US13/738,377 US9451252B2 (en) 2012-01-14 2013-01-10 Coding parameter sets and NAL unit headers for video coding
US201313738377 2013-01-10
PCT/US2013/021227 WO2013106705A2 (en) 2012-01-14 2013-01-11 Coding parameter sets and nal unit headers for video coding

Publications (1)

Publication Number Publication Date
ES2633651T3 true ES2633651T3 (es) 2017-09-22

Family

ID=48779946

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13700835.5T Active ES2633651T3 (es) 2012-01-14 2013-01-11 Codificación de conjuntos de parámetros y cabeceras de unidad NAL para codificación de vídeo

Country Status (19)

Country Link
US (1) US9451252B2 (es)
EP (1) EP2803193B1 (es)
JP (1) JP6117243B2 (es)
KR (1) KR101760165B1 (es)
CN (1) CN104054345B (es)
AU (1) AU2013207799B2 (es)
BR (1) BR112014017159B1 (es)
CA (1) CA2860776C (es)
DK (1) DK2803193T3 (es)
ES (1) ES2633651T3 (es)
HU (1) HUE032097T2 (es)
IL (1) IL233228A (es)
MY (1) MY167149A (es)
PH (1) PH12014501447A1 (es)
RU (1) RU2633117C2 (es)
SG (2) SG11201403325SA (es)
SI (1) SI2803193T1 (es)
TW (1) TWI517692B (es)
WO (1) WO2013106705A2 (es)

Families Citing this family (134)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8731285B1 (en) * 2011-09-30 2014-05-20 Tribune Broadcasting Company, Llc Systems and methods for identifying a video aspect-ratio frame attribute
US20130114710A1 (en) * 2011-11-08 2013-05-09 Samsung Electronics Co., Ltd. Method and apparatus for encoding video by prediction using reference picture list, and method and apparatus for decoding video by performing compensation using reference picture list
US9451252B2 (en) 2012-01-14 2016-09-20 Qualcomm Incorporated Coding parameter sets and NAL unit headers for video coding
KR20130116782A (ko) * 2012-04-16 2013-10-24 한국전자통신연구원 계층적 비디오 부호화에서의 계층정보 표현방식
EP2842322A1 (en) * 2012-04-24 2015-03-04 Telefonaktiebolaget LM Ericsson (Publ) Encoding and deriving parameters for coded multi-layer video sequences
GB2501535A (en) 2012-04-26 2013-10-30 Sony Corp Chrominance Processing in High Efficiency Video Codecs
US9716892B2 (en) 2012-07-02 2017-07-25 Qualcomm Incorporated Video parameter set including session negotiation information
KR101636269B1 (ko) * 2012-07-04 2016-07-05 인텔 코포레이션 3차원 비디오 코딩을 위한 뷰 간 필터 파라미터 재사용
CN104620587B (zh) * 2012-07-06 2018-04-03 三星电子株式会社 用于对多层视频进行编码的方法和设备以及用于对多层视频进行解码的方法和设备
US9992490B2 (en) * 2012-09-26 2018-06-05 Sony Corporation Video parameter set (VPS) syntax re-ordering for easy access of extension parameters
PL2901688T3 (pl) * 2012-09-28 2020-05-18 Nokia Technologies Oy Aparat i sposób do kodowania i dekodowania wideo
CA2885408C (en) * 2012-09-28 2021-11-30 Sony Corporation Image processing device and method
KR20140048802A (ko) * 2012-10-08 2014-04-24 삼성전자주식회사 멀티 레이어 비디오 부호화 방법 및 장치, 멀티 레이어 비디오 복호화 방법 및 장치
US9936196B2 (en) * 2012-10-30 2018-04-03 Qualcomm Incorporated Target output layers in video coding
KR20140087971A (ko) * 2012-12-26 2014-07-09 한국전자통신연구원 계층적 비디오 부호화에서 다중참조계층을 적용한 화면간 부／복호화 방법 및 그 장치
US9848202B2 (en) 2012-12-28 2017-12-19 Electronics And Telecommunications Research Institute Method and apparatus for image encoding/decoding
US10219006B2 (en) 2013-01-04 2019-02-26 Sony Corporation JCTVC-L0226: VPS and VPS_extension updates
US10419778B2 (en) 2013-01-04 2019-09-17 Sony Corporation JCTVC-L0227: VPS_extension with updates of profile-tier-level syntax structure
WO2014163455A1 (ko) * 2013-04-05 2014-10-09 삼성전자 주식회사 멀티 레이어 비디오의 복호화 방법 및 장치, 멀티 레이어 비디오의 부호화 방법 및 장치
CN109547815B (zh) * 2013-04-07 2021-05-18 杜比国际公司 用于视频解码的方法和电子设备
US9591321B2 (en) 2013-04-07 2017-03-07 Dolby International Ab Signaling change in output layer sets
US20140307803A1 (en) 2013-04-08 2014-10-16 Qualcomm Incorporated Non-entropy encoded layer dependency information
WO2015008464A1 (en) * 2013-07-14 2015-01-22 Sharp Kabushiki Kaisha Video parameter set signaling
US9100631B2 (en) * 2013-08-05 2015-08-04 Cable Television Laboratories, Inc. Dynamic picture quality control
US9426465B2 (en) * 2013-08-20 2016-08-23 Qualcomm Incorporated Sub-PU level advanced residual prediction
CN104427323B (zh) * 2013-08-23 2016-08-10 鸿富锦精密工业（深圳）有限公司 基于深度的三维图像处理方法
US20150078457A1 (en) * 2013-09-13 2015-03-19 Qualcomm Incorporated Representation format signaling in multi-layer video coding
EP3057325A4 (en) * 2013-10-08 2017-05-10 Sharp Kabushiki Kaisha Image decoding device, image coding device, and coded data
EP3056007A4 (en) * 2013-10-11 2017-05-24 Sharp Kabushiki Kaisha Color information and chromaticity signaling
EP3989585A1 (en) * 2013-10-11 2022-04-27 VID SCALE, Inc. High level syntax for hevc extensions
WO2015053601A1 (ko) * 2013-10-12 2015-04-16 삼성전자 주식회사 멀티 레이어 비디오 부호화 방법 및 그 장치, 멀티 레이어 비디오 복호화 방법 및 그 장치
US9936207B2 (en) * 2013-10-14 2018-04-03 Qualcomm Incorporated Indication of parallel processing in video coding
JP6336058B2 (ja) 2013-10-14 2018-06-06 マイクロソフト テクノロジー ライセンシング，エルエルシー ビデオ及び画像符号化及び復号のためのベースカラーインデックスマップモードの機能
WO2015056158A1 (en) * 2013-10-14 2015-04-23 Nokia Technologies Oy Multi-layer hypothetical reference decoder
JP6359101B2 (ja) 2013-10-14 2018-07-18 マイクロソフト テクノロジー ライセンシング，エルエルシー ビデオ及び画像の符号化及び復号のためのイントラブロックコピー予測モードの特徴
CN105659602B (zh) 2013-10-14 2019-10-08 微软技术许可有限责任公司 用于视频和图像编码的帧内块复制预测模式的编码器侧选项
CN105723712B (zh) * 2013-10-14 2019-06-28 韩国电子通信研究院 基于多层的图像编码/解码方法和设备
US10382752B2 (en) * 2013-10-15 2019-08-13 Sony Corporation Image processing device and method
BR112016012009B1 (pt) 2013-11-27 2023-11-07 Hfi Innovation Inc Método de sinalização de modo de codificação incluindo um modo intrabc para uma imagem
US9854270B2 (en) * 2013-12-19 2017-12-26 Qualcomm Incorporated Device and method for scalable coding of video information
CN104754358B (zh) * 2013-12-27 2019-02-19 中兴通讯股份有限公司 码流的生成和处理方法、装置及系统
WO2015103462A1 (en) * 2014-01-02 2015-07-09 Vidyo, Inc. Overlays using auxiliary pictures
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
CN105917650B (zh) 2014-01-03 2019-12-24 微软技术许可有限责任公司 视频和图像编/解码的方法、计算设备及计算机可读介质
US10567804B2 (en) * 2014-01-08 2020-02-18 Qualcomm Incorporated Carriage of HEVC extension bitstreams and buffer model with MPEG-2 systems
US9749642B2 (en) 2014-01-08 2017-08-29 Microsoft Technology Licensing, Llc Selection of motion vector precision
US20150195549A1 (en) 2014-01-08 2015-07-09 Qualcomm Incorporated Support of non-hevc base layer in hevc multi-layer extensions
US9774881B2 (en) * 2014-01-08 2017-09-26 Microsoft Technology Licensing, Llc Representing motion vectors in an encoded bitstream
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
RU2657210C2 (ru) 2014-03-04 2018-06-08 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Зеркальное отображение блоков и режим пропуска в интра-основанном на копии блока предсказании
JP6368795B2 (ja) * 2014-03-14 2018-08-01 ヴィド スケール インコーポレイテッド Ｒｇｂビデオコーディングエンハンスメントのためのシステムおよび方法
US20150264099A1 (en) * 2014-03-14 2015-09-17 Sharp Laboratories Of America, Inc. Systems and methods for constraining a bitstream
JP6150134B2 (ja) * 2014-03-24 2017-06-21 ソニー株式会社 画像符号化装置および方法、画像復号装置および方法、プログラム、並びに記録媒体
US9402083B2 (en) * 2014-04-24 2016-07-26 Vidyo, Inc. Signaling conformance points using profile space
CN105409221B (zh) 2014-04-29 2020-03-06 微软技术许可有限责任公司 用于样本自适应偏移滤波的编码器侧决策
EP3158734A4 (en) 2014-06-19 2017-04-26 Microsoft Technology Licensing, LLC Unified intra block copy and inter prediction modes
US9918091B2 (en) 2014-06-20 2018-03-13 Qualcomm Incorporated Systems and methods for assigning a minimum value to a syntax structure in a parameter set
WO2016041507A1 (en) * 2014-09-17 2016-03-24 Mediatek Inc. Syntax parsing apparatus with multiple syntax parsing circuits for processing multiple image regions within same frame or processing multiple frames and related syntax parsing method
EP3917146A1 (en) 2014-09-30 2021-12-01 Microsoft Technology Licensing, LLC Rules for intra-picture prediction modes when wavefront parallel processing is enabled
US10306269B2 (en) * 2014-10-10 2019-05-28 Qualcomm Incorporated Operation point for carriage of layered HEVC bitstream
US20160112724A1 (en) * 2014-10-15 2016-04-21 Qualcomm Incorporated Hrd descriptor and buffer model of data streams for carriage of hevc extensions
JP6690536B2 (ja) * 2015-01-09 2020-04-28 ソニー株式会社 画像処理装置、画像処理方法、およびプログラム
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
EP3251351B1 (en) 2015-01-27 2021-07-14 Dolby International AB Predictive image encoding and decoding with pixel group based quantization
US10148969B2 (en) * 2015-02-11 2018-12-04 Qualcomm Incorporated Of sample entry and operation point signalling in a layered video file format
US11418812B2 (en) * 2015-02-11 2022-08-16 Qualcomm Incorporated Placement of parameter sets and sync samples in video coding
WO2016197314A1 (en) 2015-06-09 2016-12-15 Microsoft Technology Licensing, Llc Robust encoding/decoding of escape-coded pixels in palette mode
US20170006283A1 (en) * 2015-06-30 2017-01-05 Microsoft Technology Licensing, Llc Computationally efficient sample adaptive offset filtering during video encoding
WO2017008263A1 (en) 2015-07-15 2017-01-19 Mediatek Singapore Pte. Ltd. Conditional binary tree block partitioning structure
US10547860B2 (en) * 2015-09-09 2020-01-28 Avago Technologies International Sales Pte. Limited Video coding with trade-off between frame rate and chroma fidelity
US10003822B2 (en) * 2016-02-10 2018-06-19 Primacomp, Inc. Error-resilient coder of image sequences and video
US11064195B2 (en) 2016-02-15 2021-07-13 Qualcomm Incorporated Merging filters for multiple classes of blocks for video coding
WO2017179592A1 (ja) * 2016-04-12 2017-10-19 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US10356800B2 (en) * 2016-05-09 2019-07-16 Qualcomm Incorporated Scalable numerology with symbol boundary alignment for uniform and non-uniform symbol duration in wireless communication
US10271069B2 (en) 2016-08-31 2019-04-23 Microsoft Technology Licensing, Llc Selective use of start code emulation prevention
US10506230B2 (en) * 2017-01-04 2019-12-10 Qualcomm Incorporated Modified adaptive loop filter temporal prediction for temporal scalability support
US10880617B2 (en) * 2017-04-25 2020-12-29 Sharp Kabushiki Kaisha Systems and methods for signaling quality information for regions in virtual reality applications
CN117201821A (zh) 2017-05-26 2023-12-08 Sk电信有限公司 对视频数据进行编码或解码的设备和存储比特流的方法
KR102435881B1 (ko) 2017-05-26 2022-08-24 에스케이텔레콤 주식회사 영상 부호화 또는 복호화하기 위한 장치 및 방법
US10986349B2 (en) 2017-12-29 2021-04-20 Microsoft Technology Licensing, Llc Constraints on locations of reference blocks for intra block copy prediction
WO2019172202A1 (ja) * 2018-03-05 2019-09-12 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 符号化装置及び符号化方法
KR20210016581A (ko) 2018-06-05 2021-02-16 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 Ibc 및 atmvp 간의 상호 작용
TWI739120B (zh) 2018-06-21 2021-09-11 大陸商北京字節跳動網絡技術有限公司 合併仿射模式與非合併仿射模式的統一拘束
EP3788782A1 (en) 2018-06-21 2021-03-10 Beijing Bytedance Network Technology Co. Ltd. Sub-block mv inheritance between color components
US10628276B2 (en) 2018-06-29 2020-04-21 International Business Machines Corporation Unit test framework for testing code in a gateway service
CN108898321B (zh) * 2018-07-09 2021-08-24 西北工业大学 一种基于语义模板的制造技术问题标准冲突参数获取方法
TWI818086B (zh) 2018-09-24 2023-10-11 大陸商北京字節跳動網絡技術有限公司 擴展Merge預測
CN116886926A (zh) 2018-11-10 2023-10-13 北京字节跳动网络技术有限公司 成对平均候选计算中的取整
WO2020103942A1 (en) 2018-11-22 2020-05-28 Beijing Bytedance Network Technology Co., Ltd. Sub-block temporal motion vector prediction
US10812818B2 (en) 2018-12-14 2020-10-20 Tencent America LLC Network abstraction unit layer type classes in network abstraction layer unit header
CN113228666B (zh) 2018-12-31 2022-12-30 华为技术有限公司 支持视频编解码中的自适应分辨率改变
EP3900362A4 (en) 2019-02-01 2022-03-02 Beijing Bytedance Network Technology Co., Ltd. SIGNALING LOOP SHAPED INFORMATION USING PARAMETER SETS
WO2020156530A1 (en) 2019-02-01 2020-08-06 Beijing Bytedance Network Technology Co., Ltd. Configuring luma-dependent chroma residue scaling for video coding
KR102661416B1 (ko) * 2019-02-27 2024-04-25 후아웨이 테크놀러지 컴퍼니 리미티드 인코더, 디코더 및 대응하는 방법
US11395006B2 (en) * 2019-03-06 2022-07-19 Tencent America LLC Network abstraction layer unit header
CN113574889B (zh) 2019-03-14 2024-01-12 北京字节跳动网络技术有限公司 环路整形信息的信令和语法
CN113678456A (zh) 2019-03-15 2021-11-19 Lg 电子株式会社 用信号通知关于色度格式的信息的方法和装置
CN113632469B (zh) * 2019-03-23 2022-12-13 北京字节跳动网络技术有限公司 默认的环内整形参数
CN116886931A (zh) * 2019-03-25 2023-10-13 寰发股份有限公司 用于视频编解码的量化矩阵计算和表示的方法和装置
US11917143B2 (en) * 2019-04-03 2024-02-27 Lg Electronics Inc. Adaptive loop filter-based video or image coding
KR20210130235A (ko) * 2019-04-15 2021-10-29 엘지전자 주식회사 스케일링 리스트 파라미터 기반 비디오 또는 영상 코딩
CN113728627B (zh) * 2019-04-26 2023-09-19 北京字节跳动网络技术有限公司 用于环路内重构的参数的预测
CA3141350A1 (en) * 2019-05-24 2020-12-03 Digitalinsights Inc. Video coding method and apparatus using adaptive parameter set
US11032548B2 (en) * 2019-06-24 2021-06-08 Tencent America LLC Signaling for reference picture resampling
EP3997868A4 (en) * 2019-08-10 2023-02-22 Beijing Bytedance Network Technology Co., Ltd. BUFFER MANAGEMENT DURING SUBPICTURE DECODING
KR20220043109A (ko) 2019-08-13 2022-04-05 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 서브 블록 기반 인터 예측의 모션 정밀도
CN114424553A (zh) 2019-09-22 2022-04-29 北京字节跳动网络技术有限公司 基于子块的帧间预测的缩放方法
EP4022930A4 (en) * 2019-09-24 2022-11-02 Huawei Technologies Co., Ltd. OLS FOR SPATIAL AND SNR Scalability
CN114424571A (zh) 2019-09-24 2022-04-29 华为技术有限公司 编码器、解码器及对应方法
MX2022003553A (es) * 2019-09-24 2022-06-02 Huawei Tech Co Ltd Señalización de encabezado de imagen en codificación de video.
CN117560496A (zh) 2019-12-26 2024-02-13 字节跳动有限公司 条带类型和视频层的信令通知
CN114902672A (zh) 2019-12-26 2022-08-12 字节跳动有限公司 视频编解码中的档次-层-级别参数集
WO2021134020A1 (en) 2019-12-26 2021-07-01 Bytedance Inc. Constraints on signaling of hypothetical reference decoder parameters in video bitstreams
US11343524B2 (en) * 2019-12-27 2022-05-24 Tencent America LLC Method for adaptation parameter set reference and constraints in coded video stream
JP2023508681A (ja) 2019-12-27 2023-03-03 バイトダンス インコーポレイテッド ビデオサブピクチャをシグナリングするための構文
US11356698B2 (en) * 2019-12-30 2022-06-07 Tencent America LLC Method for parameter set reference constraints in coded video stream
CN114946174A (zh) 2020-01-09 2022-08-26 字节跳动有限公司 层间参考图片的存在的信令通知
RU2730422C1 (ru) * 2020-01-14 2020-08-21 Федеральное государственное бюджетное образовательное учреждение высшего образования "Московский автомобильно-дорожный государственный технический университет (МАДИ) Способ пространственного кодирования и передачи цифровой информации
US20230050232A1 (en) * 2020-01-15 2023-02-16 Lg Electronics Inc. In-loop filtering-based image coding apparatus and method
WO2021145726A1 (ko) * 2020-01-15 2021-07-22 엘지전자 주식회사 적응적 루프 필터링 기반 영상 코딩 장치 및 방법
WO2021145725A1 (ko) * 2020-01-15 2021-07-22 엘지전자 주식회사 필터링 관련 정보 시그널링 기반 영상 코딩 장치 및 방법
MX2022009555A (es) * 2020-02-04 2022-11-16 Huawei Tech Co Ltd Un codificador, un decodificador y métodos correspondientes sobre señalización de sintaxis de alto nivel.
US20230064234A1 (en) * 2020-02-06 2023-03-02 Interdigital Patent Holdings, Inc. Systems and methods for encoding a deep neural network
CN115299051A (zh) 2020-03-11 2022-11-04 抖音视界有限公司 视频编解码的一致性窗口参数
US11509920B2 (en) * 2020-03-27 2022-11-22 Tencent America LLC Indication of max sublayer numbers in multilayered video stream
CN115299046A (zh) * 2020-04-01 2022-11-04 寰发股份有限公司 图像和视频编解码中发送切片分割信息的方法和装置
CN115462075A (zh) * 2020-04-21 2022-12-09 杜比实验室特许公司 用于视频译码中的约束处理和符合性测试的语义
WO2021236903A1 (en) 2020-05-21 2021-11-25 Bytedance Inc. Signaling of gradual decoding refresh and reference picture lists
US11431998B2 (en) 2020-05-22 2022-08-30 Tencent America LLC Systems and methods for decoding based on inferred video parameter sets
CN115668949A (zh) * 2020-05-26 2023-01-31 字节跳动有限公司 编解码视频中的帧间层参考图片的标识
CN115699753A (zh) 2020-05-31 2023-02-03 抖音视界有限公司 具有本地双树模式类型定义的调色板模式
US11770549B2 (en) * 2020-06-10 2023-09-26 Sony Group Corporation Video data encoding and decoding circuity applying constraint data
CN117256017A (zh) * 2021-04-23 2023-12-19 字节跳动有限公司 用于视频处理的方法、设备和介质

Family Cites Families (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7302490B1 (en) 2000-05-03 2007-11-27 Microsoft Corporation Media file format to support switching between multiple timeline-altered media streams
US20040006575A1 (en) 2002-04-29 2004-01-08 Visharam Mohammed Zubair Method and apparatus for supporting advanced coding formats in media files
EP1385337A1 (en) 2002-07-22 2004-01-28 Deutsche Thomson-Brandt Gmbh Method and apparatus for storing and transmitting audio-visual data
WO2004030369A1 (en) 2002-09-27 2004-04-08 Videosoft, Inc. Real-time video coding/decoding
US7724818B2 (en) 2003-04-30 2010-05-25 Nokia Corporation Method for coding sequences of pictures
US20050254575A1 (en) 2004-05-12 2005-11-17 Nokia Corporation Multiple interoperability points for scalable media coding and transmission
KR20050113501A (ko) 2004-05-29 2005-12-02 삼성전자주식회사 에이치 264 비디오 디코더를 위한 구문 분석기
DE102004042819A1 (de) 2004-09-03 2006-03-23 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und Verfahren zum Erzeugen eines codierten Multikanalsignals und Vorrichtung und Verfahren zum Decodieren eines codierten Multikanalsignals
US9560367B2 (en) 2004-09-03 2017-01-31 Nokia Technologies Oy Parameter set and picture header in video coding
US20060233247A1 (en) 2005-04-13 2006-10-19 Visharam Mohammed Z Storing SVC streams in the AVC file format
US8208564B2 (en) 2005-06-24 2012-06-26 Ntt Docomo, Inc. Method and apparatus for video encoding and decoding using adaptive interpolation
JP2009512306A (ja) 2005-10-11 2009-03-19 ノキア コーポレイション スケーラブルビデオコーディングのためのデコードされたピクチャーの効率的なバッファマネージメント
RU2488973C2 (ru) 2006-03-29 2013-07-27 Томсон Лайсенсинг Способы и устройство для использования в системе кодирования многовидового видео
JP5054092B2 (ja) 2006-03-30 2012-10-24 エルジー エレクトロニクス インコーポレイティド ビデオ信号のデコーディング／エンコーディング方法及び装置
KR101349836B1 (ko) 2006-11-17 2014-01-10 엘지전자 주식회사 비디오 신호의 디코딩/인코딩 방법 및 장치
EP2418851A3 (en) 2006-12-21 2012-05-23 Thomson Licensing Methods and apparatus for improved signaling using high level syntax for multi-view video coding and decoding
EP2116065A2 (en) * 2007-01-05 2009-11-11 Thomson Licensing Hypothetical reference decoder for scalable video coding
EP1994721A4 (en) 2007-01-12 2013-09-25 Univ Kyung Hee Univ Ind Coop Group PACKET FORMAT OF A NETWORK ABSTRACTION LAYER UNIT, ALGORITHM AND VIDEO ENCODING AND DECODING APPARATUS USING THE SAME, QOS CONTROL ALGORITHM AND IPV6 LABEL SWITCHING APPARATUS USING THE FORMAT
US20100266042A1 (en) 2007-03-02 2010-10-21 Han Suh Koo Method and an apparatus for decoding/encoding a video signal
US8548261B2 (en) 2007-04-11 2013-10-01 Samsung Electronics Co., Ltd. Method and apparatus for encoding and decoding multi-view image
KR101393169B1 (ko) 2007-04-18 2014-05-09 톰슨 라이센싱 코딩 시스템
US20090003431A1 (en) 2007-06-28 2009-01-01 Lihua Zhu Method for encoding video data in a scalable manner
JP5264919B2 (ja) * 2007-10-05 2013-08-14 トムソン ライセンシング マルチビュービデオ（ｍｖｃ）符号化システム内にビデオユーザビリティ情報（ｖｕｉ）を取り込む方法及び装置
CA2650151C (en) * 2008-01-17 2013-04-02 Lg Electronics Inc. An iptv receiving system and data processing method
EP2286595A1 (en) 2008-06-16 2011-02-23 Dolby Laboratories Licensing Corporation Rate control model adaptation based on slice dependencies for video coding
US8683515B2 (en) 2008-11-25 2014-03-25 Cisco Technology, Inc. Receiver for accelerating channel change time
US20100132007A1 (en) 2008-11-25 2010-05-27 Cisco Technology, Inc. Accelerating channel change time with external picture property markings
US20100189182A1 (en) 2009-01-28 2010-07-29 Nokia Corporation Method and apparatus for video coding and decoding
US9036705B2 (en) 2009-03-13 2015-05-19 Telefonaktiebolaget L M Ericsson (Publ) Technique for bringing encoded data items into conformity with a scalable coding protocol
CN102461171A (zh) 2009-05-01 2012-05-16 汤姆森特许公司 三维视频的参考画面列表
US9774882B2 (en) 2009-07-04 2017-09-26 Dolby Laboratories Licensing Corporation Encoding and decoding architectures for format compatible 3D video delivery
US8462797B2 (en) 2009-11-30 2013-06-11 Alcatel Lucent Method of priority based transmission of wireless video
US9094658B2 (en) 2010-05-10 2015-07-28 Mediatek Inc. Method and apparatus of adaptive loop filtering
WO2012096806A1 (en) 2011-01-14 2012-07-19 Vidyo, Inc. High layer syntax for temporal scalability
US9113172B2 (en) 2011-01-14 2015-08-18 Vidyo, Inc. Techniques for describing temporal coding structure
AU2012225513B2 (en) 2011-03-10 2016-06-23 Vidyo, Inc. Dependency parameter set for scalable video coding
JP6026443B2 (ja) 2011-03-10 2016-11-16 ヴィディオ・インコーポレーテッド ビデオ・ビットストリーム中の描画方向情報
CA2829335A1 (en) 2011-03-10 2012-09-13 Vidyo, Inc. Parameter set maintenance in video coding
US9635355B2 (en) 2011-07-28 2017-04-25 Qualcomm Incorporated Multiview video coding
US10237565B2 (en) 2011-08-01 2019-03-19 Qualcomm Incorporated Coding parameter sets for various dimensions in video coding
US20130094774A1 (en) * 2011-10-13 2013-04-18 Sharp Laboratories Of America, Inc. Tracking a reference picture based on a designated picture on an electronic device
US20130114694A1 (en) 2011-11-08 2013-05-09 Qualcomm Incorporated Parameter set groups for coded video data
WO2013106521A2 (en) 2012-01-10 2013-07-18 Vidyo, Inc. Techniques for layered video encoding and decoding
US9451252B2 (en) 2012-01-14 2016-09-20 Qualcomm Incorporated Coding parameter sets and NAL unit headers for video coding
US20150117526A1 (en) 2012-04-23 2015-04-30 Samsung Electronics Co., Ltd. Method for encoding multiview video using reference list for multiview video prediction and device therefor, and method for decoding multiview video using reference list for multiview video prediction and device therefor
US9716892B2 (en) 2012-07-02 2017-07-25 Qualcomm Incorporated Video parameter set including session negotiation information
US20140218473A1 (en) 2013-01-07 2014-08-07 Nokia Corporation Method and apparatus for video coding and decoding
US20140307803A1 (en) 2013-04-08 2014-10-16 Qualcomm Incorporated Non-entropy encoded layer dependency information

Also Published As

Publication number Publication date
SI2803193T1 (sl) 2017-08-31
JP2015507428A (ja) 2015-03-05
RU2014133415A (ru) 2016-03-10
AU2013207799A1 (en) 2014-08-07
JP6117243B2 (ja) 2017-04-19
PH12014501447B1 (en) 2014-10-08
CN104054345B (zh) 2017-09-08
CA2860776C (en) 2018-04-24
TWI517692B (zh) 2016-01-11
KR101760165B1 (ko) 2017-07-20
IL233228A0 (en) 2014-08-31
CA2860776A1 (en) 2013-07-18
WO2013106705A3 (en) 2014-07-17
US9451252B2 (en) 2016-09-20
BR112014017159A8 (pt) 2017-07-04
KR20140120336A (ko) 2014-10-13
RU2633117C2 (ru) 2017-10-11
MY167149A (en) 2018-08-13
SG11201403325SA (en) 2014-09-26
US20130182755A1 (en) 2013-07-18
HUE032097T2 (en) 2017-08-28
EP2803193A2 (en) 2014-11-19
BR112014017159B1 (pt) 2022-12-06
IL233228A (en) 2017-05-29
WO2013106705A2 (en) 2013-07-18
AU2013207799B2 (en) 2017-04-20
TW201342891A (zh) 2013-10-16
EP2803193B1 (en) 2017-04-19
SG10201605700SA (en) 2016-08-30
PH12014501447A1 (en) 2014-10-08
DK2803193T3 (en) 2017-06-12
CN104054345A (zh) 2014-09-17
BR112014017159A2 (pt) 2017-06-13

Similar Documents

Publication Publication Date Title
ES2633651T3 (es) Codificación de conjuntos de parámetros y cabeceras de unidad NAL para codificación de vídeo
ES2647948T3 (es) Reutilización de conjuntos de parámetros para la codificación de vídeo
JP7404373B2 (ja) ビデオエンコーダ、ビデオデコーダ、および対応する方法
ES2663444T3 (es) Información de temporización de codificación para codificación de vídeo
ES2895270T3 (es) Codificación de mensajes SEI de MCTS-EIS de una unidad de acceso
ES2656908T3 (es) Procesamiento paralelo para codificación de vídeo
ES2707890T3 (es) Codificación de vídeo de múltiples visualizaciones
ES2715980T3 (es) Codificación de valores de recuento del orden de imágenes que identifican tramas de referencia a largo plazo
KR101822247B1 (ko) Ｈｅｖｃ 및 확장들에 대한 비디오 파라미터 세트
KR20210135307A (ko) 인코더, 디코더, 및 대응하는 방법들
ES2686936T3 (es) Códec 3DVC basado en MVC que soporta el modo de predicción de movimiento de visualización interna (IVMP)
ES2657494T3 (es) Acceso aleatorio y señalización de imágenes de referencia a largo plazo en la codificación de vídeo
ES2613003T3 (es) Señalización de información de obtención de pulso de reloj para la temporización de vídeo en la codificación de vídeo
ES2884723T3 (es) Señalización de regiones de interés y actualización de decodificación gradual en la codificación de video
ES2715314T3 (es) Acceso aleatorio completo desde imágenes de acceso aleatorio limpio en codificación de vídeo
ES2730876T3 (es) Capas de salida de destino en la codificación de vídeo
ES2736312T3 (es) Señalización de imágenes de referencia a largo plazo para codificación de vídeo
ES2684546T3 (es) Codificación de vídeo con comportamientos de imagen de punto de acceso aleatorio mejorados
ES2696723T3 (es) Diseño del valor de POC para codificación de vídeo multicapa
KR20220053676A (ko) 서브픽처 기반 비디오 코딩에서의 서브픽처 id의 시그널링
JP2024071391A (ja) ビデオエンコーダ、ビデオデコーダ、および対応する方法
BR112016013141B1 (pt) Design de valor poc para codificação de vídeo de multicamadas