ES2895927T3 - Un aparato, un método y un programa de ordenador para la codificación y decodificación de vídeo - Google Patents

Un aparato, un método y un programa de ordenador para la codificación y decodificación de vídeo Download PDF

Info

Publication number
ES2895927T3
ES2895927T3 ES17211017T ES17211017T ES2895927T3 ES 2895927 T3 ES2895927 T3 ES 2895927T3 ES 17211017 T ES17211017 T ES 17211017T ES 17211017 T ES17211017 T ES 17211017T ES 2895927 T3 ES2895927 T3 ES 2895927T3
Authority
ES
Spain
Prior art keywords
image
encoded
rectangle
rectangles
coded
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
ES17211017T
Other languages
English (en)
Inventor
Miska Hannuksela
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.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
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 Nokia Technologies Oy filed Critical Nokia Technologies Oy
Application granted granted Critical
Publication of ES2895927T3 publication Critical patent/ES2895927T3/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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/174—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a slice, e.g. a line of blocks or a group of blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/154—Measured or subjectively estimated visual quality after decoding, e.g. measurement of distortion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

Un método que comprende: dividir (900) imágenes de una secuencia de imágenes fuente en una pluralidad de rectángulos de mosaico a lo largo de una cuadrícula, en el que un rectángulo de mosaico es un área rectangular en una imagen; formar un número correspondiente de secuencias de rectángulos de mosaicos, en el que cada secuencia de rectángulos de mosaicos corresponde a una determinada posición en la cuadrícula; codificar (902) cada secuencia de rectángulo de mosaico independientemente en una o más versiones de un número correspondiente de secuencias de rectángulo de mosaico codificadas con diferentes características para ser utilizadas para la entrega dependiente de la ventana gráfica, en el que las características comprenden la calidad de la imagen; y fusionar (904) dos o más rectángulos de mosaicos codificados de diferentes secuencias de rectángulos de mosaicos codificados verticalmente en cada instancia de tiempo en una imagen codificada de modo que cada rectángulo de mosaicos codificados forme un sector codificado en la imagen codificada para proporcionar una mejor calidad de imagen para una ventana gráfica que para un área restante de la imagen fuente, en la que una ventana gráfica representa una porción de la imagen decodificada presentada en una pantalla resultante de la decodificación de la imagen codificada.

Description

DESCRIPCIÓN
Un aparato, un método y un programa de ordenador para la codificación y decodificación de vídeo
Campo técnico
La presente invención se refiere a un aparato, un método y un programa informático para la codificación y decodificación de vídeo.
Antecedentes
Se han lanzado varias soluciones comerciales para transmisión adaptativa sobre Protocolo de Transferencia de Hipertexto (HTTP), tales como Microsoft® Smooth Streaming, Apple® Adaptive HTTP Live Streaming y Adobe® Dynamic Streaming, así como se han llevado a cabo proyectos de estandarización. DASH ha resultado ser un protocolo prometedor para aplicaciones de transmisión multimedia, especialmente para secuencias de bits de video de 360 grados o realidad virtual (VR).
Una tendencia reciente en la transmisión para reducir la tasa de bits de transmisión de video VR es la transmisión adaptativa de la ventana gráfica (también conocida como entrega dependiente de la ventana gráfica), en la que un subconjunto de contenido de video de 360 grados que cubre la ventana gráfica principal (es decir, la orientación de la vista actual ) se transmite con la mejor calidad/resolución, mientras que el resto del video de 360 grados se transmite con una calidad/resolución más baja.
En general, existen dos enfoques para la transmisión adaptativa de la ventana gráfica:
- Codificación y transmisión específica de la ventana gráfica, también conocida como codificación y transmisión dependiente de la ventana gráfica, también conocida como proyección asimétrica, también conocida como video VR empaquetado, donde el contenido de imagen de 360 grados se empaqueta en el mismo cuadro con énfasis en la ventana gráfica principal y los cuadros VR empaquetados se codifican en un solo flujo de bits.
- Video de ventana gráfica VR, también conocido como codificación y transmisión basada en mosaicos, donde el contenido de 360 grados se codifica y se pone a disposición de una manera que permite la transmisión selectiva de ventanas de visualización de diferentes codificaciones.
Se ha comparado la codificación y la transmisión específicas de ventana gráfica con la codificación y la transmisión basadas en mosaicos, con la conclusión de que esta última proporciona una mejor compensación entre varios parámetros. Sin embargo, varias implementaciones de códec pueden restringir la usabilidad de la codificación y la transmisión basadas en mosaicos; la mayoría de las implementaciones relacionadas con la codificación basada en mosaicos requieren el uso de conjuntos de mosaicos con restricción de movimiento, lo que tiene el inconveniente de que la herramienta de codificación de mosaicos solo está disponible en HEVC, mientras que puede ser ventajoso admitir otros formatos de codificación, como H.264/AVC.
Algunos entornos de cliente se limitan a ejecutar una única instancia de decodificador en paralelo. Una única instancia de decodificador también evita las necesidades de sincronización posdecodificador entre instancias de decodificador de diferencia y, en consecuencia, puede reducir el retardo, ya que el almacenamiento en búfer posdecodificador no necesita tener en cuenta dicha sincronización. La reducción del número de instancias de decodificador podría proporcionar beneficios también en la codificación y transmisión basadas en mosaicos rectangulares.
El documento EP 1162830 divulga un método para distribuir imágenes panorámicas en movimiento desde un servidor, que transforma los fotogramas de la imagen panorámica en un formato intermedio en el que partes de la imagen panorámica se codifican con una calidad superior en comparación con otras partes de la imagen panorámica. Un ordenador cliente obtiene información sobre la codificación y se suscribe a uno o más mosaicos según el punto de vista de interés. El ordenador cliente recibe y presenta los datos en estos mosaicos.
El documento EP 2490179 divulga un método para transmitir un flujo de video panorámico desde un servidor a un cliente, en el que el servidor transmite un primer flujo de video que comprende una proyección de una alimentación de video omnidireccional en una cuadrícula de píxeles rectangular y un segundo flujo de video que comprende una alimentación de video direccional que representa sustancialmente sincrónicamente una parte de dicha alimentación de vídeo omnidireccional. El servidor además transmite información de coordenadas que designa dicha parte de la transmisión de alimentación de video omnidireccional representada por dicha transmisión de alimentación de video direccional, en el que un aspecto de la calidad de imagen de dicho segundo flujo de video excede el mismo aspecto de la calidad de imagen de dicho primer flujo de video.
Resumen
Ahora, con el fin de aliviar al menos los problemas anteriores, se introduce aquí un método mejorado para la codificación y transmisión basadas en rectángulos de mosaicos. El alcance de protección buscado para varias realizaciones de la invención se establece en las reivindicaciones independientes.
Un método de acuerdo con un primer aspecto comprende dividir una secuencia de imágenes fuente que comprende una pluralidad de rectángulos de mosaicos en un número correspondiente de secuencias de rectángulos de mosaicos; codificar cada secuencia de rectángulo de mosaico independientemente en un número correspondiente de secuencias de rectángulo de mosaico codificadas; y fusionar dos o más rectángulos de mosaicos codificados de diferentes secuencias de mosaicos codificados verticalmente en una imagen codificada de modo que cada rectángulo de mosaicos codificados forme un sector codificado en la imagen codificada.
De acuerdo con una realización, la codificación de las secuencias de mosaicos rectangulares comprende restringir, para vectores de movimiento que requieren acceder a ubicaciones de muestra fuera de los límites de la imagen, el uso de valores de muestra fuera de los límites de la imagen.
De acuerdo con una realización, los vectores de movimiento que requieren acceder a ubicaciones de muestra verticalmente fuera de los límites de la imagen se evitan y los vectores de movimiento que requieren acceder a ubicaciones de muestra horizontalmente fuera de los límites de la imagen se utilizan en la codificación de secuencias de mosaicos rectangulares.
De acuerdo con una realización, dicha fusión comprende generar una línea de bloque adicional usando la predicción intra vertical a partir de la fila de muestra más inferior de un rectángulo de mosaico reconstruido.
De acuerdo con una realización, dicha fusión comprende generar una línea de bloque adicional usando codificación sin pérdidas que rellena la fila de muestra superior del rectángulo de mosaico verticalmente hasta la línea de bloque adicional.
De acuerdo con una realización, no se codifica ningún error de predicción para las líneas de bloque adicionales. De acuerdo con una realización, las secuencias de rectángulos de mosaicos de diferentes anchos se fusionan de manera que los rectángulos de mosaicos que son más estrechos que el rectángulo de mosaicos más ancho que se fusiona se añaden a la derecha con bloques que usan predicción intra horizontal.
De acuerdo con una realización, dicha fusión comprende reescribir conjuntos de parámetros y/o encabezados de sectores total o parcialmente para un flujo de bits que comprende la imagen codificada en comparación con los de las secuencias de rectángulo de mosaico codificadas.
Un segundo aspecto se refiere a un método, implementado, por ejemplo, mediante un escritor de archivos, el método comprende recibir una serie de secuencias de rectángulos de mosaicos codificadas, que se originan a partir de una secuencia de imágenes fuente, en las que una imagen fuente comprende un número correspondiente de rectángulos de mosaicos; e instrucciones de composición que hacen que dos o más rectángulos de mosaico codificados se fusionen verticalmente en una imagen codificada de modo que cada rectángulo de mosaico codificado forme un sector codificado en la imagen codificada, las instrucciones comprenden la extracción de bytes de los dos o más rectángulos de mosaico codificados de diferentes secuencias de mosaicos rectangulares.
Un tercer aspecto se refiere a un método, implementado, por ejemplo, mediante un decodificador, el método comprende recibir una serie de secuencias codificadas de rectángulos de mosaicos, que se originan a partir de una secuencia de imágenes fuente, en las que una imagen fuente comprende un número correspondiente de rectángulos de mosaicos; fusionar dos o más rectángulos de mosaicos codificados verticalmente en una imagen codificada de modo que cada rectángulo de mosaicos codificados forme un sector codificado en la imagen codificada; y decodificar la imagen codificada.
Otros aspectos se refieren a un aparato y un medio de almacenamiento legible por ordenador almacenado con código en el mismo, que están dispuestos para llevar a cabo el método anterior y una o más de las realizaciones relacionadas con el mismo.
Breve descripción de los dibujos
Para una mejor comprensión de la presente invención, ahora se hará referencia a modo de ejemplo a los dibujos adjuntos en los que:
La Figura 1 muestra esquemáticamente un dispositivo electrónico que emplea realizaciones de la invención;
La Figura 2 muestra esquemáticamente un equipo de usuario adecuado para emplear realizaciones de la invención; La Figura 3 muestra además dispositivos electrónicos esquemáticamente que emplean realizaciones de la invención conectados usando conexiones de red inalámbricas y cableadas;
La Figura 4 muestra esquemáticamente un codificador adecuado para implementar realizaciones de la invención; La Figura 5 muestra un ejemplo de un sistema de navegación desde puntos de vista libres;
La Figura 6a muestra un ejemplo de unión, proyección y mapeo de imágenes de la misma instancia de tiempo en un cuadro de realidad virtual empaquetado;
La Figura 6b muestra un proceso de formación de una imagen panorámica equirrectangular monoscópica;
La Figura 7 muestra un ejemplo de un modelo de datos jerárquico utilizado en DASH;
La Figura 8 muestra un ejemplo de mapeo de una cara frontal muestreada de mayor resolución de un mapa de cubo en el mismo cuadro de realidad virtual empaquetado que otras caras del cubo;
La Figura 9 muestra un diagrama de flujo del método de codificación de acuerdo con una realización de la invención; La Figura 10 muestra un ejemplo de fusión de secuencias rectangulares codificadas en un flujo de bits de acuerdo con una realización.
Las Figuras 11a y 11b muestran ejemplos de disposición de líneas de bloque adicionales para permitir referencias de vectores de movimiento sobre límites de imagen de acuerdo con una realización;
La Figura 12 muestra un ejemplo de fusión de secuencias rectangulares codificadas de diferentes tamaños en un flujo de bits de acuerdo con una realización.
La Figura 13 muestra un diagrama esquemático de un decodificador adecuado para implementar realizaciones de la invención; y
La Figura 14 muestra un diagrama esquemático de un sistema de comunicación multimedia de ejemplo dentro del cual se pueden implementar varias realizaciones.
Descripción detallada de algunas realizaciones de ejemplo
A continuación, se describe con más detalle el aparato adecuado y los posibles mecanismos para disminuir la tasa de bits descendente de la transmisión continua de un flujo de bits de vídeo escalable. A este respecto, se hace referencia primero a las Figuras 1 y 2, donde la Figura 1 muestra un diagrama de bloques de un sistema de codificación de video de acuerdo con una realización de ejemplo como un diagrama de bloques esquemático de un aparato o dispositivo 50 electrónico de ejemplo, que puede incorporar un códec de acuerdo con a una realización de la invención. La figura 2 muestra un diseño de un aparato de acuerdo con una realización de ejemplo. Los elementos de las Figs. 1 y 2 se explicarán a continuación.
El dispositivo 50 electrónico puede ser, por ejemplo, un terminal móvil o un equipo de usuario de un sistema de comunicación inalámbrica. Sin embargo, se apreciará que las realizaciones de la invención se pueden implementar dentro de cualquier dispositivo o aparato electrónico que pueda requerir codificación y decodificación o codificación o decodificación de imágenes de video.
El aparato 50 puede comprender una carcasa 30 para incorporar y proteger el dispositivo. El aparato 50 puede comprender además una pantalla 32 en forma de pantalla de cristal líquido. En otras realizaciones de la invención, la pantalla puede ser cualquier tecnología de pantalla adecuada para mostrar una imagen o un vídeo. El aparato 50 puede comprender además un teclado 34. En otras realizaciones de la invención se puede emplear cualquier mecanismo de interfaz de usuario o datos adecuado. Por ejemplo, la interfaz de usuario puede implementarse como un teclado virtual o un sistema de entrada de datos como parte de una pantalla sensible al tacto.
El aparato puede comprender un micrófono 36 o cualquier entrada de audio adecuada que puede ser una entrada de señal digital o analógica. El aparato 50 puede comprender además un dispositivo de salida de audio que en las realizaciones de la invención puede ser cualquiera de: un auricular 38, altavoz o una conexión de salida de audio analógica o de audio digital. El aparato 50 también puede comprender una batería 40 (o en otras realizaciones de la invención, el dispositivo puede ser alimentado por cualquier dispositivo de energía móvil adecuado, tal como una celda solar, una celda de combustible o un generador de relojería). El aparato puede comprender además una cámara 42 capaz de grabar o capturar imágenes y/o video. El aparato 50 puede comprender además un puerto de infrarrojos para comunicación de línea de visión de corto alcance con otros dispositivos. En otras realizaciones, el aparato 50 puede comprender además cualquier solución de comunicación de corto alcance adecuada como, por ejemplo, una conexión inalámbrica Bluetooth o una conexión por cable USB/Firewire.
El aparato 50 puede comprender un controlador 56 o procesador para controlar el aparato 50. El controlador 56 puede estar conectado a la memoria 58 que en realizaciones de la invención puede almacenar tanto datos en forma de imagen como datos de audio y/o puede también almacenar instrucciones para la implementación en el controlador 56. El controlador 56 puede conectarse además a un circuito 54 de códec adecuado para llevar a cabo la codificación y decodificación de datos de audio y/o video o ayudar en la codificación y decodificación llevada a cabo por el controlador.
El aparato 50 puede comprender además un lector 48 de tarjetas y una tarjeta 46 inteligente, por ejemplo, un lector de UICC y UICC para proporcionar información de usuario y ser adecuado para proporcionar información de autenticación para la autenticación y autorización del usuario en una red.
El aparato 50 puede comprender un circuito 52 de interfaz de radio conectado al controlador y adecuado para generar señales de comunicación inalámbrica, por ejemplo, para la comunicación con una red de comunicaciones celulares, un sistema de comunicaciones inalámbricas o una red de área local inalámbrica. El aparato 50 puede comprender además una antena 44 conectada al circuito 52 de interfaz de radio para transmitir señales de radiofrecuencia generadas en el circuito 52 de interfaz de radio a otros aparatos y para recibir señales de radiofrecuencia de otros aparatos.
El aparato 50 puede comprender una cámara capaz de grabar o detectar fotogramas individuales que luego se pasan al códec 54 o al controlador para su procesamiento. El aparato puede recibir los datos de imágenes de vídeo para su procesamiento desde otro dispositivo antes de la transmisión y/o almacenamiento. El aparato 50 también puede recibir de forma inalámbrica o mediante una conexión por cable la imagen para codificar/decodificar.
Con respecto a la Figura 3, se muestra un ejemplo de un sistema dentro del cual se pueden utilizar realizaciones de la presente invención. El sistema 10 comprende múltiples dispositivos de comunicación que pueden comunicarse a través de una o más redes. El sistema 10 puede comprender cualquier combinación de redes cableadas o inalámbricas que incluyen, entre otras, una red de telefonía celular inalámbrica (como una red GSM, UMTS, CDMA, etc.), una red de área local inalámbrica (WLAN) como la definida por cualquiera de los estándares IEEE 802.x, una red de área personal Bluetooth, una red de área local Ethernet, una red de área local token ring, una red de área amplia e Internet.
El sistema 10 puede incluir dispositivos y/o aparatos 50 de comunicación por cable e inalámbricos adecuados para implementar realizaciones de la invención.
Por ejemplo, el sistema que se muestra en la Figura 3 muestra una red 11 de telefonía móvil y una representación de Internet 28. La conectividad a Internet 28 puede incluir, pero no se limita a, conexiones inalámbricas de largo alcance, conexiones inalámbricas de corto alcance, y varias conexiones por cable que incluyen, entre otras, líneas telefónicas, líneas de cable, líneas eléctricas y vías de comunicación similares.
Los dispositivos de comunicación de ejemplo que se muestran en el sistema 10 pueden incluir, entre otros, un dispositivo o aparato electrónico 50, una combinación de un asistente digital personal (PDA) y un teléfono móvil 14, un PDA 16, un dispositivo 18 electrónico de mensajería integrado (IMD), un ordenador 20 de escritorio, un ordenador portátil 22. El aparato 50 puede ser estacionario o móvil cuando lo lleva una persona que se está moviendo. El aparato 50 también puede estar ubicado en un modo de transporte que incluye, entre otros, un automóvil, un camión, un taxi, un autobús, un tren, un bote, un avión, una bicicleta, una motocicleta o cualquier modo de transporte adecuado similar.
Las realizaciones también se pueden implementar en un decodificador; es decir, un receptor de televisión digital, que puede o no tener una pantalla o capacidades inalámbricas, en tabletas o (portátiles) ordenadores personales (PC), que tienen hardware o software o una combinación de las implementaciones del codificador/decodificador, en varios sistemas operativos, y en conjuntos de chips, procesadores, DSP y/o sistemas integrados que ofrecen codificación basada en hardware/software.
Algunos o más aparatos pueden enviar y recibir llamadas y mensajes y comunicarse con proveedores de servicios a través de una conexión 25 inalámbrica a una estación 24 base. La estación 24 base puede estar conectada a un servidor 26 de red que permite la comunicación entre la red 11 de telefonía móvil e Internet 28. El sistema puede incluir dispositivos de comunicación adicionales y dispositivos de comunicación de varios tipos.
Los dispositivos de comunicación pueden comunicarse utilizando diversas tecnologías de transmisión que incluyen, entre otros, acceso múltiple por división de código (CDMA), sistemas globales para comunicaciones móviles (GSM), sistema universal de telecomunicaciones móviles (UMTS), acceso múltiple por división de tiempo (TDMA), acceso múltiple por división de frecuencia (FDMA), protocolo de control de transmisión-protocolo de Internet (TCP-IP), servicio de mensajería corta (SMS), servicio de mensajería multimedia (MMS), correo electrónico, servicio de mensajería instantánea (IMS), Bluetooth, IEEE 802.11 y cualquier tecnología de comunicación inalámbrica similar. Un dispositivo de comunicaciones involucrado en la implementación de diversas realizaciones de la presente invención puede comunicarse usando varios medios que incluyen, pero no se limitan a, radio, infrarrojos, láser, conexiones de cable y cualquier conexión adecuada.
El protocolo de transporte en tiempo real (RTP) se usa ampliamente para el transporte en tiempo real de medios cronometrados como audio y video. RTP puede operar sobre el Protocolo de datagramas de usuario (UDP), que a su vez puede operar sobre el Protocolo de Internet (IP). RTP se especifica en la Solicitud de comentarios (RFC) 3550 del Grupo de trabajo de ingeniería de Internet (IETF), disponible en www.ietf.org/rfc/rfc3550.txt. En el transporte RTP, los datos de los medios se encapsulan en paquetes RTP. Normalmente, cada tipo de medio o formato de codificación de medio tiene un formato de carga útil r Tp dedicado.
Una sesión RTP es una asociación entre un grupo de participantes que se comunican con RTP. Es un canal de comunicaciones grupales que potencialmente puede transportar varios flujos RTP. Un flujo RTP es un flujo de paquetes RTP que comprenden datos de medios. Un tren RTP es identificado por un SSRC que pertenece a una sesión RTP particular. SSRC se refiere a una fuente de sincronización o un identificador de fuente de sincronización que es el campo SSRC de 32 bits en el encabezado del paquete RTP. Una fuente de sincronización se caracteriza porque todos los paquetes de la fuente de sincronización forman parte del mismo espacio de tiempo y número de secuencia, por lo que un receptor puede agrupar paquetes por fuente de sincronización para su reproducción. Los ejemplos de fuentes de sincronización incluyen el remitente de un flujo de paquetes derivados de una fuente de señal, como un micrófono o una cámara, o un mezclador RTP. Cada flujo RTP está identificado por un SSRC que es único dentro de la sesión RTP.
Una transmisión de transporte MPEG-2 (TS), especificada en ISO/IEC 13818-1 o equivalentemente en la Recomendación UIT-T H.222.0, es un formato para transportar audio, video y otros medios, así como metadatos de programa u otros metadatos, en una transmisión multiplexada. Se utiliza un identificador de paquete (PID) para identificar una transmisión elemental (también conocido como transmisión elemental empaquetada) dentro del TS.
Los estándares de formato de archivo de medios disponibles incluyen el formato de archivo de medios base ISO (ISO/IEC 14496-12, que puede abreviarse como Is Ob MFF), el formato de archivo MPEG-4 (ISO/IEC 14496-14, también conocido como formato MP4), formato de archivo para video estructurado de unidad NAL (ISO/IEC 14496­ 15) y formato de archivo 3GPP (3Gp P TS 26.244, también conocido como formato 3GP). ISOBMFF es la base para la derivación de todos los formatos de archivo mencionados anteriormente (excluyendo el propio ISOBMFF).
Algunos conceptos, estructuras y especificaciones de ISOBMFF se describen a continuación como un ejemplo de un formato de archivo contenedor, en base al cual se pueden implementar las realizaciones. Los aspectos de la invención no se limitan a ISOBMFF, sino que se da la descripción de una posible base sobre la cual la invención puede realizarse parcial o totalmente.
Un elemento fundamental básico en el formato de archivo de medios base ISO se denomina caja. Cada caja tiene un encabezado y una carga útil. El encabezado de lA caja indica el tipo de caja y el tamaño de la caja en términos de bytes. Una caja puede incluir otras cajas, y el formato de archivo ISO especifica qué tipos de caja están permitidos dentro de una caja de cierto tipo. Además, la presencia de algunas cajas puede ser obligatoria en cada archivo, mientras que la presencia de otras cajas puede ser opcional. Además, para algunos tipos de cajas, es posible que se permita tener más de una caja en un archivo. Por tanto, se puede considerar que el formato de archivo de medios base ISO especifica una estructura jerárquica de cajas.
De acuerdo con la familia ISO de formatos de archivo, un archivo incluye datos de medios y metadatos que se encapsulan en cajas. Cada caja se identifica con un código de cuatro caracteres (4CC) y comienza con un encabezado que informa sobre el tipo y tamaño de la caja.
En archivos que se ajustan al formato de archivo de medios de base ISO, los datos de medios pueden proporcionarse en una caja 'mdat' de datos de medios y la caja de película 'moov' puede usarse para encerrar los metadatos. En algunos casos, para que un archivo sea operativo, es posible que se requiera que estén presentes las cajas 'mdat' y 'moov'. La caja “moov” de la película puede incluir una o más pistas, y cada pista puede residir en una caja “trak” de la pista correspondiente. Una pista puede ser uno de los muchos tipos, incluida una pista de medios que se refiere a muestras formateadas de acuerdo con un formato de compresión de medios (y su encapsulación al formato de archivo de medios base ISO). Una pista puede considerarse un canal lógico.
Se pueden usar fragmentos de película, por ejemplo, al grabar contenido en archivos ISO, por ejemplo, para evitar la pérdida de datos si una aplicación de grabación falla, se queda sin espacio en la memoria u ocurre algún otro incidente. Sin fragmentos de película, la pérdida de datos puede ocurrir porque el formato de archivo puede requerir que todos los metadatos, por ejemplo, la caja de película, se escriban en un área contigua del archivo. Además, al grabar un archivo, es posible que no haya suficiente espacio en la memoria (por ejemplo, RAM de memoria de acceso aleatorio) para almacenar en búfer una caja de película para el tamaño del almacenamiento disponible, y volver a calcular el contenido de una caja de película cuando la película está cerrada puede ser demasiado lento. Además, los fragmentos de película pueden permitir la grabación y reproducción simultáneas de un archivo utilizando un analizador de archivos ISO normal. Además, es posible que se requiera una menor duración del almacenamiento en búfer inicial para descarga progresiva, por ejemplo, recepción y reproducción simultáneas de un archivo cuando se utilizan fragmentos de película y la caja de película inicial es más pequeño en comparación con un archivo con el mismo contenido de medios pero estructurado sin fragmentos de película.
La función de fragmento de película puede permitir dividir los metadatos que, de otro modo, podrían residir en la caja de la película en múltiples partes. Cada pieza puede corresponder a un determinado período de tiempo de una pista. En otras palabras, la función de fragmentos de película puede permitir intercalar metadatos de archivos y datos de medios. En consecuencia, el tamaño de la caja de películas puede ser limitado y los casos de uso mencionados anteriormente pueden realizarse.
En algunos ejemplos, las muestras de medios para los fragmentos de película pueden residir en una caja de mdat. Sin embargo, para los metadatos de los fragmentos de película, se puede proporcionar una caja de moof. La caja de moof puede incluir la información de una cierta duración del tiempo de reproducción que previamente habría estado en la caja de moov. La caja de moov todavía puede representar una película válida por sí solo, pero, además, puede incluir un cuadro mvex que indica que los fragmentos de la película seguirán en el mismo archivo. Los fragmentos de la película pueden extender la presentación asociada a la caja de moov en el tiempo.
Dentro del fragmento de película puede haber un conjunto de fragmentos de pista, que incluyen desde cero hasta una pluralidad por pista. Los fragmentos de pista pueden, a su vez, incluir desde cero hasta una pluralidad de recorridos de pista, cada uno de cuyos documentos es un recorrido contiguo de muestras para esa pista (y, por tanto, son similares a fragmentos). Dentro de estas estructuras, muchos campos son opcionales y pueden ser predeterminados. Los metadatos que pueden incluirse en la caja de moov pueden estar limitados a un subconjunto de los metadatos que pueden incluirse en una caja de moov y pueden codificarse de manera diferente en algunos casos. Los detalles sobre las cajas que se pueden incluir en una caja moof se pueden encontrar en la especificación ISOBMFF. Un fragmento de película autónomo se puede definir para que consta de una caja moof y una caja de mdat que son consecutivos en el orden de archivo y donde la caja de mdat contiene las muestras del fragmento de película (para el cual la caja moof proporciona los metadatos) y no contener muestras de ningún otro fragmento de película (es decir, cualquier otra caja de Moof).
El mecanismo de referencia de pista se puede utilizar para asociar pistas entre sí. TrackReferenceBox incluye caja (s), cada una de las cuales proporciona una referencia de la pista que la contiene a un conjunto de otras pistas. Estas referencias están etiquetadas a través del tipo de caja (es decir, el código de cuatro caracteres de la caja) de las cajas contenidas.
El formato de archivo de medios base ISO contiene tres mecanismos para metadatos cronometrados que se pueden asociar con muestras particulares: grupos de muestras, pistas de metadatos cronometrados e información auxiliar de muestra. La especificación derivada puede proporcionar una funcionalidad similar con uno o más de estos tres mecanismos.
Una agrupación de muestras en el formato de archivo de medios base ISO y sus derivados, como el formato de archivo AVC y el formato de archivo SVC, se puede definir como una asignación de cada muestra en una pista para que sea miembro de un grupo de muestra, basado en un criterio de agrupación. Un grupo de muestras en una agrupación de muestras no se limita a ser muestras contiguas y puede contener muestras no adyacentes. Como puede haber más de una agrupación de muestras para las muestras de una pista, cada agrupación de muestras puede tener un campo de tipo para indicar el tipo de agrupación. Las agrupaciones de muestras pueden estar representadas por dos estructuras de datos vinculadas: (1) un SampleToGroupBox (caja sbgp) representa la asignación de muestras a grupos de muestras; y (2) un SampleGroupDescriptionBox (caja sgpd) contiene una entrada de grupo de muestra para cada grupo de muestra que describe las propiedades del grupo. Puede haber varias instancias de SampleToGroupBox y SampleGroupDescriptionBox según diferentes criterios de agrupación. Estos se pueden distinguir por un campo de tipo utilizado para indicar el tipo de agrupación. SampleToGroupBox puede comprender un campo grouping_type_parameter que se puede usar, por ejemplo, para indicar un subtipo de agrupación.
Se ha especificado el mecanismo y la entrada de muestra de video restringido ('resv') para el ISOBMFF con el fin de manejar situaciones en las que el autor del archivo requiere ciertas acciones en el reproductor o renderizador después de la decodificación de una pista visual. Los reproductores que no reconocen o no pueden procesar las acciones requeridas no pueden decodificar o reproducir las pistas de video restringidas. El mecanismo de entrada de muestra 'resv' se aplica a cualquier tipo de códec de vídeo. Un RestrictedSchemelnfoBox está presente en la entrada de muestra de las pistas 'resv' y comprende un OriginalFormatBox, SchemeTypeBox y SchemelnformationBox. El tipo de entrada de muestra original que habría sido a menos que se hubiera utilizado el tipo de entrada de muestra 'resv' está contenido en OriginalFormatBox. SchemeTypeBox proporciona una indicación del tipo de procesamiento que se requiere en el reproductor para procesar el video. El SchemelnformationBox contiene más información sobre el procesamiento requerido. El tipo de esquema puede imponer requisitos sobre el contenido de SchemelnformationBox. Por ejemplo, el esquema de video estéreo indicado en SchemeTypeBox indica que cuando los cuadros decodificados contienen una representación de dos cuadros constituyentes empaquetados espacialmente que forman un par estéreo (empaquetado de cuadros) o solo una vista de un par estéreo (vistas izquierda y derecha en diferentes pistas). Stereo VideoBox puede estar contenido en SchemelnformationBox para proporcionar más información, por ejemplo, en qué tipo de arreglo de empaquetado del cuadro se ha utilizado (por ejemplo, uno al lado del otro o de arriba a abajo).
El Formato de Archivo de Imagen de Alta Eficiencia (HEIF, ISO/IEC 23008-12) especifica el almacenamiento de imágenes individuales, así como secuencias de imágenes en un archivo contenedor. HEIF incluye la especificación de almacenamiento de imágenes intracodificadas H.264/AVC o HEVC y secuencias de imágenes H.264/AVC o HEVC en las que la predicción inter se aplica de manera restringida. Los archivos HEIF son compatibles con el formato de archivo de medios base ISO (ISO/IEC 14496-12) y también pueden incluir otros flujos de medios, como texto y audio cronometrados.
HEIF especifica un formato estructural, a partir del cual se pueden derivar formatos de imagen específicos del códec. HEIF también incluye la especificación para encapsular imágenes y secuencias de imágenes conforme a HEVC. Se está trabajando para incluir la especificación para encapsular imágenes y secuencias de imágenes que cumplan con H.264/AVC, JPEG y HEVC multicapa en HEIF.
De acuerdo con HEIF, las imágenes fijas se almacenan como elementos. Todos los elementos de la imagen se codifican de forma independiente y no dependen de ningún otro elemento en su decodificación, con la excepción de las imágenes que utilizan la escalabilidad de códec híbrido. Se puede incluir cualquier número de elementos de imagen en el mismo archivo. Las secuencias de imágenes se almacenan como pistas. Se puede indicar que una pista de secuencia de imágenes se muestre como una secuencia cronometrada o de manera no cronometrada, como una galería de imágenes. Es necesario utilizar una pista de secuencia de imágenes en lugar de elementos de imagen cuando hay dependencia de codificación entre imágenes. Un archivo puede contener elementos de imagen y pistas de secuencia de imágenes junto con otros medios. Por ejemplo, es posible crear un archivo que incluya elementos de imagen o pistas de secuencia de imágenes que se ajusten a HEIF, junto con pistas de vídeo, audio y texto cronometrado que se ajusten a cualquier formato derivado de ISOBMFF.
De acuerdo con HEIF, se puede indicar que las imágenes tienen propiedades que son descriptivas (es decir, que no imponen una modificación al elemento de la imagen) o transformadoras (es decir, que modifican la imagen). Las propiedades se pueden marcar como esenciales imponiendo un análisis obligatorio por parte del reproductor de archivos. ItemPropertiesBox permite la asociación de cualquier elemento con un conjunto ordenado de propiedades del elemento. ItemPropertiesBox consta de dos partes: ItemPropertyContainerBox que contiene una lista indexada implícitamente de propiedades del elemento y uno o más cuadros ItemPropertyAssociation que asocian elementos con propiedades del elemento. Cada propiedad del elemento es una caja (de tipo Caja o FullBox).
El formato de archivo Matroska es capaz de (pero no limitado a) almacenar cualquier pista de video, audio, imagen o subtítulos en un archivo. Matroska se puede utilizar como formato base para formatos de archivo derivados, como WebM. Matroska utiliza como base Extensible Binary Meta Language (EBML). EBML especifica un formato alineado en binario y octeto (byte) inspirado en el principio de XML. EBML en sí mismo es una descripción generalizada de la técnica de marcado binario. Un archivo Matroska consta de elementos que componen un “documento” EBML. Los elementos incorporan un ID de elemento, un descriptor para el tamaño del elemento y los datos binarios en sí. Los elementos se pueden anidar. Un Elemento de Segmento de Matroska es un contenedor para otros elementos de nivel superior (nivel 1). Un archivo Matroska puede comprender (pero no se limita a estar compuesto por) un Segmento. Los datos de medios de los archivos Matroska se organizan en Clústeres (o Elementos de Clúster), cada uno de los cuales contiene normalmente unos pocos segundos de datos multimedia. Un Clúster eomprende elementos de BlockGroup, que a su vez comprenden elementos de bloque. Un Elemento Cues comprende metadatos que pueden ayudar en el acceso aleatorio o la búsqueda y pueden incluir punteros de archivo o marcas de tiempo respectivas para los puntos de búsqueda.
El códec de video consiste en un codificador que transforma el video de entrada en una representación comprimida adecuada para almacenamiento/transmisión y un decodificador que puede descomprimir la representación de video comprimido de nuevo en una forma visible. Un codificador de video y/o un decodificador de video también pueden estar separados entre sí, es decir, no es necesario que formen un códec. Normalmente, el codificador descarta parte de la información de la secuencia de vídeo original para representar el vídeo en una forma más compacta (es decir, con una tasa de bits más baja).
Los codificadores de video híbridos típicos, por ejemplo, muchas implementaciones de codificador de UIT-T H.263 y H.264, codifican la información de video en dos fases. En primer lugar, los valores de píxeles en una determinada área de imagen (o “bloque”) se predicen, por ejemplo, mediante medios de compensación de movimiento (encontrar e indicar un área en uno de los cuadros de vídeo codificados previamente que se corresponda estrechamente con el bloque que se está codificando) o mediante medios espaciales (utilizando los valores de píxel alrededor del bloque que se codificarán de una manera específica). En segundo lugar, se codifica el error de predicción, es decir, la diferencia entre el bloque de píxeles predicho y el bloque de píxeles original. Por lo general, esto se hace transformando la diferencia en los valores de los píxeles usando una transformación específica (por ejemplo, Transformada de coseno discreta (DCT) o una variante de la misma), cuantificando los coeficientes y codificando entropía los coeficientes cuantificados. Al variar la fidelidad del proceso de cuantificación, el codificador puede controlar el equilibrio entre la precisión de la representación de píxeles (calidad de imagen) y el tamaño de la representación de vídeo codificada resultante (tamaño de archivo o tasa de transmisión de bits).
La interpredicción, que también puede denominarse predicción temporal, compensación de movimiento o predicción con compensación de movimiento, reduce la redundancia temporal. En la inter predicción, las fuentes de predicción son imágenes previamente decodificadas. La predicción intra utiliza el hecho de que es probable que los píxeles adyacentes dentro de la misma imagen estén correlacionados. La predicción intra puede realizarse en el dominio espacial o de transformación, es decir, se pueden predecir valores de muestra o coeficientes de transformación. La predicción intra se explota típicamente en la codificación intra, donde no se aplica ninguna predicción inter.
Un resultado del procedimiento de codificación es un conjunto de parámetros de codificación, tales como vectores de movimiento y coeficientes de transformación cuantificados. Muchos parámetros pueden codificarse en entropía de manera más eficiente si se predicen primero a partir de parámetros vecinos espacial o temporalmente. Por ejemplo, un vector de movimiento puede predecirse a partir de vectores de movimiento espacialmente adyacentes y solo puede codificarse la diferencia relativa al predictor del vector de movimiento. La predicción de los parámetros de codificación y la predicción intra pueden denominarse colectivamente predicción en la imagen.
La figura 4 muestra un diagrama de bloques de un codificador de video adecuado para emplear realizaciones de la invención. La Figura 4 presenta un codificador para dos capas, pero se apreciaría que el codificador presentado podría simplificarse de manera similar para codificar solo una capa o extenderse para codificar más de dos capas. La figura 4 ilustra una realización de un codificador de vídeo que comprende una primera sección 500 de codificador para una capa base y una segunda sección 502 de codificador para una capa de mejora. Cada una de la primera sección 500 de codificador y la segunda sección 502 de codificador pueden comprender elementos similares para codificar imágenes entrantes. Las secciones 500, 502 de codificador pueden comprender un predictor 302, 402 de píxeles, un codificador 303, 403 de error de predicción y un decodificador 304, 404 de error de predicción. La figura 4 también muestra una realización del predictor 302, 402 de píxeles que comprende un inter-predictor 306, 406, un intra-predictor 308, 408, un selector 310, 410 de modo, un filtro 316, 416 y una memoria 318, 418 de cuadro de referencia. El predictor 302 de píxeles de la primera sección 500 de codificador recibe 300 imágenes de la capa base de una vídeosecuencia a codificar tanto en el inter-predictor 306 (que determina la diferencia entre la imagen y un cuadro 318 de referencia compensado por movimiento) como en el intra-predictor 308 (que determina una predicción para un bloque de imagen basado sólo en las partes ya procesadas de fotograma o imagen actual). La salida tanto del inter-predictor como del intra-predictor se pasa al selector 310 de modo. El intra-predictor 308 puede tener más de un modo de intra-predicción. Por tanto, cada modo puede realizar la intra-predicción y proporcionar la señal predicha al selector 310 de modo. El selector 310 de modo también recibe una copia de la imagen de la capa 300 base. En consecuencia, el predictor 402 de píxeles de la segunda sección 502 de codificador recibe 400 imágenes de la capa de mejora de un flujo de video para ser codificadas tanto en el inter-predictor 406 (que determina la diferencia entre la imagen y un cuadro 418 de referencia compensado por movimiento) como en el intra-predictor 408 (que determina una predicción para un bloque de imagen basado solamente en las partes ya procesadas del cuadro o imagen actual). La salida tanto del interpredictor como del intra-predictor se pasa al selector 410 de modo. El intra-predictor 408 puede tener más de un modo de intra-predicción. Por tanto, cada modo puede realizar la intra-predicción y proporcionar la señal predicha al selector 410 de modo. El selector 410 de modo también recibe una copia 400 de la imagen de la capa de mejora.
Dependiendo de qué modo de codificación se seleccione para codificar el bloque actual, la salida del inter-predictor 306, 406 o la salida de uno de los modos de intra-predictor opcionales o la salida de un codificador de superficie dentro del selector de modo se pasa a la salida del selector 310, 410 de modo. La salida del selector de modo se pasa a un primer dispositivo 321, 421 sumador. El primer dispositivo sumador puede restar la salida del predictor 302, 402 de píxeles de la imagen de la capa 300 base/imagen de capa de mejora 400 para producir una primera señal 320, 420 de error de predicción que se introduce en el codificador 303, 403 de error de predicción.
El predictor 302, 402 de píxeles recibe además de un reconstructor 339, 439 preliminar la combinación de la representación de predicción del bloque 312, 412 de imagen y la salida 338, 438 del decodificador 304, 404 de error de predicción. La imagen 314, 414 reconstruida preliminar se puede pasar al intra-predictor 308, 408 y a un filtro 316, 416. El filtro 316, 416 que recibe la representación preliminar puede filtrar la representación preliminar y generar una imagen 340, 440 reconstruida final que se puede guardar en una memoria de cuadros 318, 418 de referencia. La memoria de cuadros 318 de referencia puede conectarse al inter-predictor 306 para usarse como imagen de referencia con la que se compara una imagen 300 de capa base futura en operaciones de inter-predicción. Sujeto a que la capa base sea seleccionada e indicada como fuente para la predicción de muestras entre capas y/o la predicción de información de movimiento entre capas de la capa de mejora de acuerdo con algunas realizaciones, la memoria de cuadros 318 de referencia también puede estar conectada al inter-predictor 406 para ser utilizada como imagen de referencia con la que se comparan las imágenes 400 de una capa de mejora futura en operaciones de interpredicción. Además, la memoria 418 del cuadro de referencia puede conectarse al inter-predictor 406 para ser utilizado como la imagen de referencia con la que se compara una imagen 400 de capa de mejora futura en operaciones de inter­ predicción.
Los parámetros de filtrado del filtro 316 de la primera sección 500 de codificador pueden proporcionarse a la segunda sección 502 de codificador sujeto a que la capa base se seleccione e indique que es fuente para predecir los parámetros de filtrado de la capa de mejora de acuerdo con algunas realizaciones.
El codificador 303, 403 de error de predicción comprende una unidad 342, 442 de transformación y un cuantificador 344, 444. La unidad 342, 442 de transformación transforma la primera señal 320, 420 de error de predicción en un dominio de transformación. La transformación es, por ejemplo, la transformación DCT. El cuantificador 344, 444 cuantifica la señal del dominio de transformación, por ejemplo, los coeficientes DCT, para formar coeficientes cuantificados.
El decodificador 304, 404 de error de predicción recibe la salida del codificador 303, 403 de error de predicción y realiza los procesos opuestos del codificador 303, 403 de error de predicción para producir una señal 338, 438 de error de predicción decodificada que, cuando se combina con la representación de predicción del bloque 312, 412 de imagen en el segundo dispositivo 339, 439 sumador, produce la imagen 314, 414 reconstruida preliminar. Se puede considerar que el decodificador de error de predicción comprende un descuantificador 361,461, que descuantifica los valores de coeficientes cuantificados, por ejemplo, Coeficientes DCT, para reconstruir la señal de transformación y una unidad 363, 463 de transformación inversa, que realiza la transformación inversa a la señal de transformación reconstruida en la que la salida de la unidad 363, 463 de transformación inversa contiene bloques reconstruidos. El decodificador de error de predicción también puede comprender un filtro de bloque que puede filtrar el bloque o bloques reconstruidos de acuerdo con información decodificada adicional y parámetros de filtrado.
El codificador 330, 430 de entropía recibe la salida del codificador 303, 403 de error de predicción y puede realizar una codificación de entropía/codificación de longitud variable adecuada en la señal para proporcionar capacidad de detección y corrección de errores. Las salidas de los codificadores 330, 430 de entropía pueden insertarse en un flujo de bits, por ejemplo, por un multiplexor 508.
El estándar H.264/AVC fue desarrollado por el Equipo Conjunto de Video (JVT) del Grupo de Expertos en Codificación de Video (VCEG) del Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones (UIT-T) y el Grupo de Expertos en Imágenes en Movimiento (MPEG) de la Organización Internacional de Normalización (ISO)/Comisión Electrotécnica Internacional (IEC). El estándar H.264/AVC es publicado por ambas organizaciones de estandarización principales, y se conoce como la Recomendación UIT-T H.264 y el Estándar Internacional ISO/IEC 14496-10, también conocido como Codificación de Video Avanzada MPEG-4 Parte 10 (AVC). Ha habido múltiples versiones del estándar H.264/AVC, integrando nuevas extensiones o características a la especificación. Estas extensiones incluyen Codificación de Video Escalable (SVC) y Codificación de Video de Vista Múltiple (MVC).
La versión 1 del estándar de Codificación de Vídeo de Alta Eficiencia (H.265/HEVC también conocido como HEVC) fue desarrollada por el Equipo Colaborativo Conjunto - Codificación de Vídeo (JCT-VC) de VCEG y MPEG. El estándar fue publicado por ambas organizaciones de estandarización principales y se conoce como la Recomendación UIT-T H.265 y el Estándar Internacional ISO/IEC 23008-2, también conocido como Codificación de Video de Alta Eficiencia MPEG-H Parte 2 (HEVC). La versión 2 de H.265/HEVC incluía extensiones escalables, multivista y de rango de fidelidad, que pueden abreviarse como SHVC, MV-HEVC y REXT, respectivamente. La versión 2 de H.265/HEVC se publicó como Recomendación UIT-T H.265 (10/2014) y como Edición 2 de ISO/IEC 23008-2. Actualmente hay proyectos de normalización en curso para desarrollar más extensiones de H.265/HEVC, incluidas extensiones de codificación de contenido de pantalla y tridimensionales, que pueden abreviarse como 3D-HEVC y SCC, respectivamente.
SHVC, MV-HEVC y 3D-HEVC utilizan una especificación de base común, especificada en el Anexo F de la versión 2 del estándar HEVC. Esta base común comprende, por ejemplo, sintaxis y semántica de alto nivel, por ejemplo, especificando algunas de las características de las capas del flujo de bits, como las dependencias entre capas, así como los procesos de decodificación, como la construcción de la lista de imágenes de referencia, incluidas las imágenes de referencia entre capas y la derivación del recuento del orden de las imágenes para el flujo de bits multicapa. El anexo F también se puede utilizar en posibles extensiones multicapa posteriores de HEVC. Debe entenderse que, aunque un codificador de video, un decodificador de video, métodos de codificación, métodos de decodificación, estructuras de flujo de bits y/o realizaciones pueden describirse a continuación con referencia a extensiones específicas, tales como SHVC y/o MV-HEVC, son generalmente aplicables a cualquier extensión de múltiples capas de HEVC, e incluso más generalmente a cualquier esquema de codificación de video de múltiples capas.
Algunas definiciones clave, flujo de bits y estructuras de codificación, y conceptos de H.264/AVC y HEVC se describen en esta sección como un ejemplo de un codificador de video, decodificador, método de codificación, método de decodificación y una estructura de flujo de bits, en la que se pueden implementar realizaciones. Algunas de las definiciones clave, el flujo de bits y las estructuras de codificación y los conceptos de H.264/AVC son los mismos que en HEVC; por lo tanto, se describen a continuación de forma conjunta. Los aspectos de la invención no se limitan a H.264/AVC o HEVC, sino que la descripción se da para una posible base sobre la cual la invención puede realizarse total o parcialmente.
De forma similar a muchos estándares de codificación de vídeo anteriores, la sintaxis y la semántica del flujo de bits, así como el proceso de decodificación para los flujos de bits sin errores, se especifican en H.264/AVC y HEVc . No se especifica el proceso de codificación, pero los codificadores deben generar flujos de bits conformes. La conformidad del flujo de bits y del decodificador se puede verificar con el Decodificador de Referencia Hipotético (HRD). Los estándares contienen herramientas de codificación que ayudan a hacer frente a los errores y pérdidas de transmisión, pero el uso de las herramientas en la codificación es opcional y no se ha especificado ningún proceso de decodificación para flujos de bits erróneos.
En la descripción de estándares existentes, así como en la descripción de realizaciones de ejemplo, un elemento de sintaxis puede definirse como un elemento de datos representado en el flujo de bits. Una estructura de sintaxis puede definirse como cero o más elementos de sintaxis presentes juntos en el flujo de bits en un orden especificado. En la descripción de estándares existentes, así como en la descripción de realizaciones de ejemplo, se puede usar una frase “por medios externos” o “por medios externos”. Por ejemplo, una entidad, como una estructura sintáctica o un valor de una variable utilizada en el proceso de decodificación, puede proporcionarse “por medios externos” al proceso de decodificación. La frase “por medios externos” puede indicar que la entidad no está incluida en el flujo de bits creado por el codificador, sino que se transmite externamente desde el flujo de bits, por ejemplo, utilizando un protocolo de control. Alternativamente o adicionalmente, puede significar que la entidad no es creada por el codificador, pero puede ser creada, por ejemplo, en el reproductor o en la lógica de control de decodificación o similar que está usando el decodificador. El decodificador puede tener una interfaz para ingresar los medios externos, como valores variables.
La unidad elemental para la entrada a un codificador H.264/AVC o HEVC y la salida de un decodificador H.264/AVC o HEVC, respectivamente, es una imagen. Una imagen proporcionada como entrada a un codificador también puede denominarse imagen fuente, y una imagen decodificada por un decodificado puede denominarse imagen decodificada.
Las imágenes fuente y decodificadas están compuestas cada una de una o más matrices de muestra, como uno de los siguientes conjuntos de matrices de muestra:
- Luma (Y) solamente (monocromo).
- Luma y dos cromas (YCbCr o YCgCo).
- Verde, Azul y Rojo (GBR, también conocido como RGB).
- Matrices que representan otras muestras de color monocromáticas o de tres estímulos no especificadas (por ejemplo, YZX, también conocido como XYZ).
En lo que sigue, estas matrices pueden denominarse luma (o L o Y) y croma, donde las dos matrices de croma pueden denominarse Cb y Cr; independientemente del método de representación de color real que se utilice. El método de representación de color real en uso se puede indicar, por ejemplo, en un flujo de bits codificado, por ejemplo, utilizando la sintaxis de información de usabilidad de video (VUI) de H.264/AVC y/o HEVC. Un componente puede definirse como una matriz o una sola muestra de una de las tres matrices de matrices de muestras (luma y dos croma) o la matriz o una sola muestra de la matriz que componen una imagen en formato monocromático.
En H.264/AVC y HEVC, una imagen puede ser un cuadro o un campo. Un cuadro comprende una matriz de muestras de luminancia y posiblemente las correspondientes muestras de croma. Un campo es un conjunto de filas de muestra alternativas de un cuadro y se puede utilizar como entrada del codificador, cuando la señal fuente está entrelazada. Las matrices de muestras de croma pueden estar ausentes (y, por lo tanto, el muestreo monocromático puede estar en uso) o las matrices de muestras de croma se pueden submuestrear cuando se comparan con las matrices de muestras de luma. Los formatos cromáticos se pueden resumir de la siguiente manera:
- En el muestreo monocromático, solo hay una matriz de muestra, que nominalmente puede considerarse la matriz de luma.
- En el muestreo 4: 2: 0, cada una de las dos matrices de croma tiene la mitad de la altura y la mitad del ancho de la matriz de luma.
- En el muestreo 4: 2: 2, cada una de las dos matrices cromáticas tiene la misma altura y la mitad del ancho de la matriz de luma.
- En el muestreo 4: 4: 4 cuando no se utilizan planos de color separados, cada una de las dos matrices cromáticas tiene la misma altura y anchura que la matriz de luma.
En H.264/AVC y HEVC, es posible codificar matrices de muestra como planos de color separados en el flujo de bits y decodificar respectivamente planos de color codificados por separado del flujo de bits. Cuando se utilizan planos de color separados, cada uno de ellos se procesa por separado (por el codificador y/o el decodificador) como una imagen con muestreo monocromático.
Una partición se puede definir como una división de un conjunto en subconjuntos de modo que cada elemento del conjunto esté exactamente en uno de los subconjuntos.
En H.264/AVC, un macrobloque es un bloque de 16x16 de muestras de luma y los correspondientes bloques de muestras de croma. Por ejemplo, en el patrón de muestreo 4: 2: 0, un macrobloque contiene un bloque de muestras de croma de 8x8 por cada componente de croma. En H.264/AVC, una imagen se divide en uno o más grupos de sector, y un grupo de sector contiene uno o más sectores. En H.264/AVC, un sector consiste en un número entero de macrobloques ordenados consecutivamente en la exploración de cuadro dentro de un grupo de sector particular.
Cuando se describe el funcionamiento de la codificación y/o decodificación HEVC, se pueden utilizar los siguientes términos. Un bloque de codificación puede definirse como un bloque NxN de muestras para algún valor de N, de manera que la división de un bloque de árbol de codificación en bloques de codificación es una partición. Un bloque de árbol de codificación (CTB) puede definirse como un bloque NxN de muestras para algún valor de N, de modo que la división de un componente en bloques de árbol de codificación es una partición. Una unidad de árbol de codificación (CTU) puede definirse como un bloque de árbol de codificación de muestras de luma, dos bloques de árbol de codificación correspondientes de muestras de croma de una imagen que tiene tres matrices de muestras, o un bloque de árbol de codificación de muestras de una imagen monocromática o una imagen que se codifica utilizando tres planos de color separados y estructuras de sintaxis utilizadas para codificar las muestras. Una unidad de codificación (CU) puede definirse como un bloque de codificación de muestras de luma, dos bloques de codificación correspondientes de muestras de croma de una imagen que tiene tres matrices de muestras, o un bloque de codificación de muestras de una imagen monocromática o una imagen que se codifica utilizando tres planos de color separados y estructuras sintácticas que se utilizan para codificar las muestras.
En algunos códecs de vídeo, como el Códec de Codificación de Vídeo de Alta Eficiencia (HEVC), las imágenes de vídeo se dividen en unidades de codificación (CU) que cubren el área de la imagen. Una CU consta de una o más unidades de predicción (PU) que definen el proceso de predicción para las muestras dentro de la CU y una o más unidades de transformación (TU) que definen el proceso de codificación del error de predicción para las muestras en dicha CU. Normalmente, una CU consiste en un bloque cuadrado de muestras con un tamaño seleccionable de un conjunto predefinido de posibles tamaños de CU. Una CU con el tamaño máximo permitido puede denominarse LCU (unidad de codificación más grande) o unidad de árbol de codificación (CTU) y la imagen de vídeo se divide en LCU que no se superponen. Una LCU se puede dividir en una combinación de CU más pequeñas, por ejemplo, dividiendo recursivamente la LCU y las UC resultantes. Cada CU resultante tiene típicamente al menos una PU y al menos una TU asociada. Cada PU y TU se puede dividir aún más en PU y TU más pequeñas para aumentar la granularidad de los procesos de predicción y codificación de errores de predicción, respectivamente. Cada PU tiene asociada información de predicción que define qué tipo de predicción se va a aplicar para los píxeles dentro de esa PU (por ejemplo, información de vector de movimiento para PU entre predicciones e información de direccionalidad intrapredictiva para PU intrapredecibles).
Cada TU puede asociarse con información que describe el proceso de decodificación del error de predicción para las muestras dentro de dicha TU (incluyendo, por ejemplo, información de coeficientes DCT). Por lo general, se indica a nivel de CU si se aplica o no la codificación del error de predicción para cada CU. En el caso de que no exista un error de predicción residual asociado a la CU, se puede considerar que no existen TU para dicha CU. La división de la imagen en CU y la división de CU en PU y TU se señaliza típicamente en el flujo de bits, lo que permite que el decodificador reproduzca la estructura deseada de estas unidades.
En HEVC, una imagen se puede dividir en mosaicos, que son rectangulares y contienen un número entero de LCU. En HEVC, la división en mosaicos forma una cuadrícula de mosaicos que comprende una o más columnas de mosaicos y una o más filas de mosaicos. Un mosaico codificado está alineado por bytes, lo que puede lograrse agregando bits de alineación de bytes al final del mosaico codificado.
En HEVC, un sector se define como un número entero de unidades de árbol de codificación contenidas en un segmento de sector independiente y todos los segmentos de sector dependientes subsiguientes (si los hay) que preceden al siguiente segmento de sector independiente (si lo hay) dentro de la misma unidad de acceso. En HEVC, un segmento de sector se define como un número entero de unidades de árbol de codificación ordenadas consecutivamente en el escaneo de mosaicos y contenidas en una sola unidad NAL. La división de cada imagen en segmento de sector es una partición. En HEVC, un segmento de sector independiente se define como un segmento de sector para el cual los valores de los elementos de sintaxis del encabezado del segmento de sector no se infieren de los valores de un segmento de sector anterior, y un segmento de sector dependiente se define como un segmento de sector para el cual los valores de algunos elementos de sintaxis del encabezado del segmento de sector se infieren de los valores del segmento de sector independiente anterior en el orden de decodificación. En HEVC, un encabezado de segmento de sector se define como el encabezado de segmento de sector del segmento de sector independiente que es un segmento de sector actual o es el segmento de sector independiente que precede a un segmento de sector dependiente actual, y un encabezado de segmento de sector se define como parte de un segmento de sector codificado que contiene los elementos de datos pertenecientes a la primera o todas las unidades de árbol de codificación representadas en el segmento de sector. Las CU se escanean en el orden de escaneo ráster de LCU dentro de mosaicos o dentro de una imagen, si los mosaicos no están en uso. Dentro de una LCU, las CU tienen un orden de exploración específico.
En HEVC, un mosaico contiene un número entero de unidades de árbol de codificación y puede consistir en unidades de árbol de codificación contenidas en más de un sector. De manera similar, un sector puede consistir en unidades de árbol de codificación contenidas en más de un mosaico. En HEVC, todas las unidades del árbol de codificación en un sector pertenecen al mismo mosaico y/o todas las unidades del árbol de codificación en un mosaico pertenecen al mismo sector. Además, en HEVC, todas las unidades de árbol de codificación en un segmento de sector pertenecen al mismo mosaico y/o todas las unidades de árbol de codificación en un mosaico pertenecen al mismo segmento de sector.
Un conjunto de mosaicos con restricción de movimiento es tal que el proceso de inter predicción está restringido en la codificación de tal manera que ningún valor de muestra fuera del conjunto de mosaicos con restricción de movimiento, y ningún valor de muestra en una posición de muestra fraccionaria que se deriva usando uno o más valores de muestra fuera del conjunto de mosaicos con restricción de movimiento, se utiliza para la predicción inter de cualquier muestra dentro del conjunto de mosaicos con restricción de movimiento.
Se observa que las ubicaciones de muestra utilizadas en la inter predicción están saturadas de modo que una ubicación que estaría fuera de la imagen de otro modo se satura para apuntar a la muestra de límite correspondiente de la imagen. De manera equivalente a saturar las ubicaciones de las muestras en los límites de la imagen, las imágenes reconstruidas pueden rellenarse, es decir, las muestras fuera del límite de la imagen pueden tener el mismo valor de muestra que la muestra del límite más cercana horizontalmente para el relleno horizontal o la muestra del límite más cercana verticalmente para el relleno vertical.
El mensaje SEI de conjuntos de mosaicos con restricción de movimiento temporal de HEVC puede usarse para indicar la presencia de conjuntos de mosaicos con restricción de movimiento en el flujo de bits.
Un conjunto de mosaicos restringido entre capas es tal que el proceso de predicción entre capas está restringido en la codificación de modo que no hay valor de muestra fuera de cada conjunto de mosaicos de referencia asociado, y ningún valor de muestra en una posición de muestra fraccional que se deriva usando uno o más valores de muestra fuera de cada conjunto de mosaicos de referencia asociado, se utilizan para la predicción entre capas de cualquier muestra dentro del conjunto de mosaicos restringidos entre capas.
El mensaje SEI de conjuntos de mosaicos restringidos entre capas de HEVC puede usarse para indicar la presencia de conjuntos de mosaicos restringidos entre capas en el flujo de bits.
El decodificador reconstruye el vídeo de salida aplicando medios de predicción similares al codificador para formar una representación predicha de los bloques de píxeles (utilizando el movimiento o la información espacial creada por el codificador y almacenada en la representación comprimida) y la decodificación del error de predicción (operación inversa de la codificación del error de predicción recuperando la señal de error de predicción cuantificada en el dominio de píxeles espaciales). Después de aplicar los medios de decodificación de predicción y error de predicción, el decodificador suma las señales de predicción y error de predicción (valores de píxeles) para formar el cuadro de vídeo de salida. El decodificador (y codificador) también puede aplicar medios de filtrado adicionales para mejorar la calidad del video de salida antes de pasarlo para su visualización y/o almacenarlo como referencia de predicción para los próximos cuadros en la secuencia de video.
El filtrado puede incluir, por ejemplo, uno más de los siguientes: desbloqueo, desplazamiento adaptativo de muestra (SAO) y/o filtrado de bucle adaptativo (ALF). H.264/AVC incluye un desbloqueo, mientras que HEVc incluye tanto el desbloqueo como SAO.
En los códecs de vídeo típicos, la información de movimiento se indica con vectores de movimiento asociados con cada bloque de imagen con compensación de movimiento, como una unidad de predicción. Cada uno de estos vectores de movimiento representa el desplazamiento del bloque de imagen en la imagen a codificar (en el lado del codificador) o decodificar (en el lado del decodificador) y el bloque fuente de predicción en una de las imágenes previamente codificadas o decodificadas. Para representar eficazmente los vectores de movimiento, éstos se codifican típicamente de manera diferencial con respecto a los vectores de movimiento predichos específicos del bloque. En los códecs de vídeo típicos, los vectores de movimiento predichos se crean de una manera predefinida, por ejemplo, calculando la mediana de los vectores de movimiento codificados o decodificados de los bloques adyacentes. Otra forma de crear predicciones de vector de movimiento es generar una lista de predicciones candidatas a partir de bloques adyacentes y/o bloques coubicados en imágenes de referencia temporal y señalizar al candidato elegido como predictor de vector de movimiento. Además de predecir los valores del vector de movimiento, se puede predecir qué imágenes de referencia se utilizan para la predicción con compensación de movimiento y esta información de predicción se puede representar, por ejemplo, mediante un índice de referencia de una imagen previamente codificada/decodificada. El índice de referencia se predice típicamente a partir de bloques adyacentes y/o bloques coubicados en la imagen de referencia temporal. Además, los códecs de video típicos de alta eficiencia emplean un mecanismo de codificación/decodificación de información de movimiento adicional, a menudo llamado modo de fusión/fusión, donde toda la información del campo de movimiento, que incluye el vector de movimiento y el índice de imagen de referencia correspondiente para cada lista de imágenes de referencia disponible, se predice y utilizado sin ninguna modificación/corrección. De manera similar, la predicción de la información del campo de movimiento se lleva a cabo utilizando la información del campo de movimiento de los bloques adyacentes y/o bloques coubicados en imágenes de referencia temporal y la información del campo de movimiento usada se señala entre una lista de la lista de candidatos de campo de movimiento llena con información de campo de movimiento de bloques adyacentes/coubicados disponibles.
Los códecs de video típicos permiten el uso de unipredicción, donde se usa un solo bloque de predicción para un bloque que se (des) codifica, y bi-predicción, donde dos bloques de predicción se combinan para formar la predicción de un bloque que se (descifrado. Algunos códecs de video permiten la predicción ponderada, donde los valores de muestra de los bloques de predicción se ponderan antes de agregar información residual. Por ejemplo, factor de ponderación multiplicativo y una compensación aditiva que se puede aplicar. En la predicción ponderada explícita, habilitada por algunos códecs de vídeo, se puede codificar un factor de ponderación y un desplazamiento, por ejemplo, en el encabezado de sector para cada índice de imagen de referencia permitido. En la predicción ponderada implícita, habilitada por algunos códecs de vídeo, los factores de ponderación y/o compensaciones no se codifican, sino que se derivan, por ejemplo, basado en las distancias de recuento de orden de imagen relativo (POC) de las imágenes de referencia.
En los códecs de vídeo típicos, el residuo de predicción después de la compensación de movimiento se transforma primero con un núcleo de transformación (como DCT) y luego se codifica. La razón de esto es que a menudo todavía existe alguna correlación entre el residuo y la transformación que en muchos casos puede ayudar a reducir esta correlación y proporcionar una codificación más eficiente.
Los codificadores de vídeo típicos utilizan funciones de coste lagrangianas para encontrar modos de codificación óptimos, por ejemplo, el modo de macrobloque deseado y los vectores de movimiento asociados. Este tipo de función de coste utiliza un factor de ponderación A para unir la distorsión de la imagen (exacta o estimada) debido a los métodos de codificación con pérdida y la cantidad (exacta o estimada) de información que se requiere para representar los valores de píxeles en un área de imagen:
C = D AR, (1)
donde C es el coste lagrangiano a minimizar, D es la distorsión de la imagen (por ejemplo, Error Cuadrático Medio) con el modo y los vectores de movimiento considerados, y R el número de bits necesarios para representar los datos necesarios para reconstruir el bloque de imagen en el decodificador (incluida la cantidad de datos para representar los vectores de movimiento candidatos).
Los estándares y especificaciones de codificación de video pueden permitir que los codificadores dividan una imagen codificada en sectores codificados o similares y/o mosaicos o similares. Por lo general, la predicción en imagen está deshabilitada en los límites de los sectores y los límites de los mosaicos. Por lo tanto, los sectores y los mosaicos se pueden considerar como una forma de dividir una imagen codificada en piezas decodificables de forma independiente. En H.264/AVC y HEVC, la predicción en imagen puede desactivarse a través de los límites de los sectores, y en HEVC, la predicción en la imagen puede desactivarse a través de los límites de los mosaicos. Por lo tanto, los sectores se pueden considerar como una forma de dividir una imagen codificada en piezas decodificables de forma independiente y, por lo tanto, los sectores se consideran a menudo como unidades elementales para la transmisión y también se pueden utilizar como unidades elementales para la paralelización. Los mosaicos se pueden considerar como unidades elementales para la paralelización en la codificación y/o decodificación. En muchos casos, los codificadores pueden indicar en el flujo de bits qué tipos de predicción en la imagen están desactivados a través de los límites de los sectores o los límites de los mosaicos (por separado o conjuntamente para los límites de los sectores y los mosaicos), y la operación del decodificador tiene en cuenta esta información, por ejemplo, al concluir qué fuentes de predicción están disponibles. Por ejemplo, las muestras de un macrobloque o CU vecino pueden considerarse no disponibles para la predicción intra, si el macrobloque o CU vecino reside en un sector diferente.
Una unidad elemental para la salida de un codificador H.264/AVC o HEVC y la entrada de un decodificador H.264/AVC o HEVC, respectivamente, es una unidad de capa de abstracción de red (NAL). Para el transporte a través de redes orientadas a paquetes o el almacenamiento en archivos estructurados, las unidades NAL pueden encapsularse en paquetes o estructuras similares. Una unidad NAL puede definirse como una estructura de sintaxis que contiene una indicación del tipo de datos a seguir y bytes que contienen esos datos en forma de RBSP intercalados según sea necesario con bytes de prevención de emulación de código de inicio. Una carga útil de secuencia de bytes sin procesar (RBSP) puede definirse como una estructura de sintaxis que contiene un número entero de bytes que se encapsula en una unidad NAL. Una RBSP está vacía o tiene la forma de una cadena de bits de datos que contienen elementos de sintaxis seguidos de un bit de parada de RBSP y seguidos de cero o más bits posteriores iguales a 0. Las unidades NAL constan de un encabezado y una carga útil.
En HEVC, se utiliza un encabezado de unidad NAL de dos bytes para todos los tipos de unidad NAL especificados. El encabezado de la unidad NAL contiene un bit reservado, una indicación del tipo de unidad NAL de seis bits, una indicación nuh_temporal_id_plus1 de tres bits para el nivel temporal (puede ser necesario que sea mayor o igual a 1) y un elemento de sintaxis nuh_layer_id de seis bits. El elemento de sintaxis temporal_id_plus1 puede considerarse como un identificador temporal para la unidad NAL, y una variable TemporalId de base cero puede derivarse de la siguiente manera: TemporalId = temporal_id_plus1 -1. TemporalId igual a 0 corresponde al nivel temporal más bajo. Se requiere que el valor de temporal_id_plus1 sea distinto de cero para evitar la emulación de código de inicio que involucre los dos bytes de encabezado de unidad NAL. El flujo de bits creado excluyendo todas las unidades VCL NAL que tienen un TemporalId mayor o igual a un valor seleccionado e incluyendo todas las demás unidades VCL NAL sigue siendo conforme. En consecuencia, una imagen que tenga TemporalId igual a TID no utiliza ninguna imagen que tenga un TemporalId mayor que TID como referencia entre predicciones. Una subcapa o una subcapa temporal puede definirse como una capa temporal escalable de un flujo de bits temporal escalable, que consta de unidades VCL NAL con un valor particular de la variable TemporalId y las unidades NAL no VCL asociadas. nuh_layer_id puede entenderse como un identificador de capa de escalabilidad.
Las unidades NAL se pueden clasificar en unidades NAL de capa de codificación de vídeo (VCL) y unidades NAL que no son VCL. En H.264/AVC, las unidades NAL de sector codificado contienen elementos de sintaxis que representan uno o más macrobloques codificados, cada uno de los cuales corresponde a un bloque de muestras en la imagen sin comprimir. En HEVC, las unidades VCLNAL contienen elementos de sintaxis que representan una o más CU.
En HEVC, se puede indicar que una unidad NAL de sector codificada es uno de los siguientes tipos:
Figure imgf000015_0001
En HEVC, las abreviaturas para los tipos de imágenes se pueden definir de la siguiente manera: imagen de seguimiento (TRAIL), Acceso de Subcapa Temporal (TSA), Acceso de Subcapa Temporal por Etapas (STSA), imagen de Encabezado Decodificable de Acceso Aleatorio (RADL), imagen de Encabezado Omitida de Acceso Aleatorio (RASL), imagen de Acceso a Enlace Roto (BLA), imagen de Actualización de Decodificación Instantánea (IDR), imagen de Acceso Aleatorio Limpio (CRA).
Una imagen de Punto de Acceso Aleatorio (RAP), que también puede denominarse imagen de punto de acceso intraaleatorio (IRAP), es una imagen en la que cada sector o segmento de sector tiene nal_unit_type en el rango de 16 a 23, inclusive. Una imagen IRAP en una capa independiente contiene solo sectores intracodificados. Una imagen IRAP que pertenece a una capa predicha con el valor nuh_layer_id currLayerId puede contener sectores P, B e I, no puede usar la predicción inter de otras imágenes con nuh_layer_id igual a currLayerId, y puede usar la predicción entre capas de sus capas de referencia directa. En la versión actual de HEVC, una imagen IRAp puede ser una imagen BLA, una imagen CRA o una imagen IDR. La primera imagen de un flujo de bits que contiene una capa base es una imagen IRAP en la capa base. Siempre que los conjuntos de parámetros necesarios estén disponibles cuando sea necesario activarlos, una imagen IRAP en una capa independiente y todas las imágenes no RASL posteriores en la capa independiente en el orden de decodificación se pueden decodificar correctamente sin realizar el proceso de decodificación de las imágenes que preceden a la Imagen IRAP en orden de decodificación. La imagen IRAP que pertenece a una capa predicha con el valor nuh_layer_id currLayerId y todas las imágenes posteriores que no son RASL con nuh_layer_id igual a currLayerId en el orden de decodificación se pueden decodificar correctamente sin realizar el proceso de decodificación de ninguna imagen con un ID de capa nuh igual a currLayerId que preceda al IRAP imagen en orden de decodificación, cuando los conjuntos de parámetros necesarios están disponibles cuando necesitan ser activados y cuando se ha inicializado la decodificación de cada capa de referencia directa de la capa con nuh_layer_id igual a currLayerId (es decir, cuando LayerInitializedFlag [refLayerId] es igual a 1 para refLayerIdequal a todos los valores nuh_layer_id de las capas de referencia directa de la capa con nuh_layer_id igual a currLayerId). Es posible que haya imágenes en un flujo de bits que contengan solo sectores intracodificados que no sean imágenes IRAp .
En HEVC, una imagen CRA puede ser la primera imagen en el flujo de bits en el orden de decodificación, o puede aparecer más tarde en el flujo de bits. Las imágenes CRA en HEVc permiten las llamadas imágenes iniciales que siguen a la imagen CRA en el orden de decodificación, pero la preceden en el orden de salida. Algunas de las imágenes iniciales, las llamadas imágenes RASL, pueden utilizar imágenes decodificadas antes de la imagen CRA como referencia. Las imágenes que siguen a una imagen CRA tanto en la decodificación como en el orden de salida son decodificables si se realiza un acceso aleatorio en la imagen CRA y, por lo tanto, se logra un acceso aleatorio limpio de manera similar a la funcionalidad de acceso aleatorio limpio de una imagen IDR.
Una imagen CRA puede tener imágenes RADL o RASL asociadas. Cuando una imagen CRA es la primera imagen del flujo de bits en el orden de decodificación, la imagen CRA es la primera imagen de una secuencia de vídeo codificada en el orden de decodificación, y el decodificador no emite ninguna imagen RASL asociada y es posible que no se pueda decodificar, ya que puede contener referencias a imágenes que no están presentes en el flujo de bits.
Una imagen inicial es una imagen que precede a la imagen RAP asociada en el orden de salida. La imagen RAP asociada es la imagen RAP anterior en el orden de decodificación (si está presente). Una imagen inicial es una imagen RADL o una imagen RASL.
Todas las imágenes RASL son imágenes iniciales de una imagen BLA o CRA asociada. Cuando la imagen RAP asociada es una imagen BLA o es la primera imagen codificada en el flujo de bits, la imagen RASL no se emite y puede que no se pueda decodificar correctamente, ya que la imagen RASL puede contener referencias a imágenes que no están presentes en el flujo de bits. Sin embargo, una imagen RASL se puede decodificar correctamente si la decodificación se inició a partir de una imagen RAP antes de la imagen RAP asociada de la imagen RASL. Las imágenes RASL no se utilizan como imágenes de referencia para el proceso de decodificación de imágenes que no son RASL. Cuando están presentes, todas las imágenes RASL preceden, en orden de decodificación, a todas las imágenes finales de la misma imagen RAP asociada. En algunos borradores del estándar HEVC, una imagen RASL se refería a una imagen etiquetada para descartar (TFD).
Todas las imágenes RADL son imágenes iniciales. Las imágenes RADL no se utilizan como imágenes de referencia para el proceso de decodificación de imágenes finales de la misma imagen RAP asociada. Cuando están presentes, todas las imágenes RADL preceden, en orden de decodificación, a todas las imágenes finales de la misma imagen RAP asociada. Las imágenes RADL no se refieren a ninguna imagen que preceda a la imagen RAP asociada en el orden de decodificación y, por lo tanto, pueden decodificarse correctamente cuando la decodificación comienza a partir de la imagen RAP asociada.
Cuando una parte de un flujo de bits que comienza a partir de una imagen CRA se incluye en otro flujo de bits, las imágenes RASL asociadas con la imagen CRA pueden no ser correctamente decodificables, porque algunas de sus imágenes de referencia pueden no estar presentes en el flujo de bits combinado. Para simplificar la operación de empalme, el tipo de unidad NAL de la imagen CRA se puede cambiar para indicar que es una imagen BLA. Es posible que las imágenes RASL asociadas con una imagen BLA no se puedan decodificar correctamente, por lo que no se emiten/visualizan. Además, las imágenes RASL asociadas con una imagen BLA pueden omitirse de la decodificación.
Una imagen BLA puede ser la primera imagen en el flujo de bits en el orden de decodificación, o puede aparecer más tarde en el flujo de bits. Cada imagen BLA comienza una nueva secuencia de video codificada y tiene un efecto similar en el proceso de decodificación como una imagen IDR. Sin embargo, una imagen BLA contiene elementos de sintaxis que especifican un conjunto de imágenes de referencia no vacías. Cuando una imagen BLA tiene nal_unit_type igual a BLA_W_LP, puede tener imágenes RASL asociadas, que no son emitidas por el decodificador y pueden no ser decodificables, ya que pueden contener referencias a imágenes que no están presentes en el flujo de bits. Cuando una imagen BLA tiene nal_unit_type igual a BLA_W_LP, también puede tener imágenes RADL asociadas, que se especifican para decodificar. Cuando una imagen BLA tiene nal_unit_type igual a BLA_W _RADL, no tiene imágenes RASL asociadas, pero puede tener imágenes RADL asociadas, que se especifican para decodificar. Cuando una imagen BLA tiene nal_unit_type igual a BLA_N_LP, no tiene imágenes iniciales asociadas.
Una imagen IDR que tiene un tipo de unidad final igual a IDR_N_LP no tiene imágenes iniciales asociadas presentes en el flujo de bits. Una imagen IDR que tiene nal_unit_type igual a IDR_W_LP no tiene imágenes RASL asociadas presentes en el flujo de bits, pero puede tener imágenes RADL asociadas en el flujo de bits.
Cuando el valor de nal_unit_type es igual a TRAIL_N, TSA_N, STSA_N, RADL_N, RASL_N, RSV_VCL_N10, RSV_VCL_N12 o RSV_VCL_N14, la imagen decodificada no se usa como referencia para ninguna otra imagen de la misma subcapa temporal. Es decir, en HEVC, cuando el valor de nal_unit_type es igual a TRAIL_N, TSA_N, STSA_N, RADL_N, RASL_N, RSV_VCL_N10, RSV_VCL_N12 o RSV_VCL_N14, la imagen decodificada no se incluye en ninguno de RefPicSetStCurrAfter y RefCricSet mismo valor de TemporalId. Una imagen codificada con nal_unit_type igual a TRAIL_N, TSA_N, STSA_N, RADL_N, RASL_N, RSV_VCL_N10, RSV_VCL_N12 o RSV_VCL_N14 puede descartarse sin afectar la decodificación de otras imágenes con el mismo valor de TemporalId.
Una imagen final se puede definir como una imagen que sigue a la imagen RAP asociada en orden de salida. Cualquier imagen que sea una imagen final no tiene un tipo de unidad final igual a RADL N, RADL R, RASL_N o RASL R. Cualquier imagen que sea una imagen inicial puede estar restringida para preceder, en orden de decodificación, a todas las imágenes finales asociadas con la misma imagen RAP. No hay imágenes RASL presentes en el flujo de bits que estén asociadas con una imagen BLA que tenga nal_unit_type igual a BLA_W_rA d L o BLA_N_LP. No hay imágenes RADL presentes en el flujo de bits que estén asociadas con una imagen BLA que tenga nal_unit_type igual a BLA_N_LP o que estén asociadas con una imagen IDR que tenga nal_unit_type igual a IDR_N_LP. Cualquier imagen RASL asociada con una imagen CRA o BLA puede estar restringida para preceder a cualquier imagen RADL asociada con la imagen CRA o BLA en el orden de salida. Cualquier imagen RASL asociada con una imagen CRA puede estar limitada a seguir, en orden de salida, cualquier otra imagen RAP que preceda a la imagen CRA en orden de decodificación.
En HEVC hay dos tipos de imágenes, los tipos de imágenes TSA y STSA que pueden usarse para indicar puntos de conmutación de subcapa temporales. Si se han decodificado subcapas temporales con TemporalId hasta N hasta que la imagen TSA o STSA (exclusiva) y la imagen TSA o STSA tenga TemporalId igual a N 1, la imagen TSA o STSA permite decodificar todas las imágenes posteriores (en decodificación order) que tiene TemporalId igual a N 1. El tipo de imagen TSA puede imponer restricciones a la imagen TSA en sí y a todas las imágenes de la misma subcapa que siguen a la imagen TSA en orden de decodificación. Ninguna de estas imágenes puede utilizar la predicción inter de ninguna imagen de la misma subcapa que precede a la imagen TSA en el orden de decodificación. La definición de TSA puede imponer además restricciones a las imágenes en subcapas superiores que siguen a la imagen de TSA en el orden de decodificación. Ninguna de estas imágenes puede referirse a una imagen que precede a la imagen TSA en el orden de decodificación si esa imagen pertenece a la misma subcapa o una subcapa superior que la imagen TSA. Las imágenes de TSA tienen TemporalId mayor que 0. La STSA es similar a la imagen de TSA pero no impone restricciones sobre las imágenes en subcapas superiores que siguen a la imagen de STSA en orden de decodificación y, por lo tanto, permiten el cambio ascendente solo en la subcapa donde reside la imagen STSA.
Una unidad NAL no VCL puede ser, por ejemplo, uno de los siguientes tipos: un conjunto de parámetros de secuencia, un conjunto de parámetros de imagen, una unidad NAL de información de mejora suplementaria (SEI), un delimitador de unidad de acceso, una unidad NAL de fin de secuencia, una unidad NAL de fin de flujo de bits, o una unidad NAL de datos de relleno. Pueden ser necesarios conjuntos de parámetros para la reconstrucción de imágenes decodificadas, mientras que muchas de las otras unidades NAL no VCL no son necesarias para la reconstrucción de valores de muestra decodificados.
Los parámetros que permanecen sin cambios a través de una secuencia de video codificada pueden incluirse en un conjunto de parámetros de secuencia. Además de los parámetros que pueden ser necesarios para el proceso de decodificación, el conjunto de parámetros de secuencia puede contener opcionalmente información de usabilidad de video (VUI), que incluye parámetros que pueden ser importantes para el almacenamiento en búfer, el tiempo de salida de la imagen, la reproducción y la reserva de recursos. En HEVc , un conjunto de parámetros de secuencia RBSP incluye parámetros a los que se puede hacer referencia mediante una o más RBSP de conjuntos de parámetros de imagen o una o más unidades SEI NAL que contienen un mensaje SEI de período de almacenamiento en búfer. Un conjunto de parámetros de imagen contiene dichos parámetros que probablemente no se modifiquen en varias imágenes codificadas. Un conjunto de parámetros de imagen RBSP puede incluir parámetros a los que se puede hacer referencia mediante las unidades NAL de sector codificado de una o más imágenes codificadas.
En HEVC, un conjunto de parámetros de video (VPS) puede definirse como una estructura de sintaxis que contiene elementos de sintaxis que se aplican a cero o más flujos de bits de video codificados de múltiples vistas completas según lo determinado por el contenido de un elemento de sintaxis que se encuentra en el SPS referido por un elemento de sintaxis que se encuentra en el PPS al que se hace referencia mediante un elemento de sintaxis que se encuentra en el encabezado de cada segmento de sector. Una RBSP de conjunto de parámetros de vídeo puede incluir parámetros a los que se puede hacer referencia mediante una o más RBSP de conjunto de parámetros de secuencia.
La relación y jerarquía entre el conjunto de parámetros de vídeo (VPS), el conjunto de parámetros de secuencia (SPS) y el conjunto de parámetros de imagen (PPS) se pueden describir como sigue. VPS reside un nivel por encima de SPS en la jerarquía del conjunto de parámetros y en el contexto de escalabilidad y/o video 3D. El VPS puede incluir parámetros que son comunes para todos los sectores en todas las capas (escalabilidad o vista) en toda la secuencia de video codificado. SPS incluye los parámetros que son comunes para todos los sectores en una capa particular (escalabilidad o vista) en toda la secuencia de video codificada, y pueden ser compartidos por múltiples capas (escalabilidad o vista). PPS incluye los parámetros que son comunes para todos los sectores en una representación de capa particular (la representación de una escalabilidad o capa de vista en una unidad de acceso) y es probable que todos los sectores los compartan en representaciones de múltiples capas.
El VPS puede proporcionar información sobre las relaciones de dependencia de las capas en un flujo de bits, así como mucha otra información que es aplicable a todos los sectores en todas las capas (escalabilidad o vista) en la secuencia de video codificada completa. Se puede considerar que el VPS comprende dos partes, el VPS base y una extensión del VPS, donde la extensión del VPS puede estar presente opcionalmente. En HEVC, se puede considerar que el VPS base comprende la estructura de sintaxis video_parameter_set_rbsp () sin la estructura de sintaxis vps_extension (). La estructura de sintaxis video_parameter_set_rbsp () ya se especificó principalmente para HEVC versión 1 e incluye elementos de sintaxis que pueden ser útiles para la decodificación de la capa base. En HEVC, se puede considerar que la extensión VPS comprende la estructura de sintaxis vps_extension (). La estructura de sintaxis vps_extension () se especificó en HEVC versión 2 principalmente para extensiones de múltiples capas y comprende elementos de sintaxis que pueden ser útiles para decodificar una o más capas sin base, como elementos de sintaxis que indican relaciones de dependencia de capa.
El elemento de sintaxis max_tid_il_ref_pics_plus1 en la extensión VPS se puede usar para indicar que las imágenes que no son IRAP no se usan como referencia para la predicción entre capas y, de no ser así, qué subcapas temporales no se usan como referencia para entre -layer prediction: max_tid_il_ref_pics_plus1 [i] [j] igual a 0 especifica que las imágenes que no son IRAP con nuh_layer_id igual a layer_id_in_nuh [i] no se utilizan como imágenes fuente para la predicción entre capas para imágenes con un ID de capa igual a layer_id_in_nuh [j ]. max_tid_il_ref_pics_plus1 [i] [j] mayor que 0 especifica que las imágenes con nuh_layer_id igual a layer_id_in_nuh [i] y TemporalId mayor que max_tid_il_ref_pics_plus1 [i] [j] -1 no se utilizan como imágenes fuente para la predicción entre capas para imágenes con nuh layer_id igual a layer_id_in_nuh [j]. Cuando no está presente, se infiere que el valor de max_tid_il_ref_pics_plus1 [i] [j] es igual a 7.
La sintaxis H.264/AVC y HEVC permite muchas instancias de conjuntos de parámetros, y cada instancia se identifica con un identificador único. Para limitar el uso de memoria necesario para los conjuntos de parámetros, se ha limitado el rango de valores para los identificadores de conjuntos de parámetros. En H.264/AVC y HEVC, cada encabezado de sector incluye el identificador del conjunto de parámetros de imagen que está activo para la decodificación de la imagen que contiene el sector, y cada conjunto de parámetros de imagen contiene el identificador del conjunto de parámetros de secuencia activa. En consecuencia, la transmisión de conjuntos de parámetros de secuencia e imagen no tiene que sincronizarse con precisión con la transmisión de sectores. En cambio, es suficiente que la secuencia activa y los conjuntos de parámetros de imagen se reciban en cualquier momento antes de que sean referenciados, lo que permite la transmisión de conjuntos de parámetros “fuera de banda” utilizando un mecanismo de transmisión más confiable en comparación con los protocolos utilizados para los datos de sectores. Por ejemplo, los conjuntos de parámetros se pueden incluir como un parámetro en la descripción de la sesión para las sesiones del Protocolo de transporte en tiempo real (RTP). Si los conjuntos de parámetros se transmiten dentro de banda, pueden repetirse para mejorar la robustez de errores.
La transmisión, señalización o almacenamiento fuera de banda se puede utilizar adicional o alternativamente para otros fines que no sean la tolerancia contra errores de transmisión, como la facilidad de acceso o la negociación de la sesión. Por ejemplo, una entrada de muestra de una pista en un archivo conforme a ISOBMFF puede comprender conjuntos de parámetros, mientras que los datos codificados en el flujo de bits se almacenan en otra parte del archivo o en otro archivo. La frase a lo largo del flujo de bits (por ejemplo, que indica a lo largo del flujo de bits) puede usarse en las reivindicaciones y realizaciones descritas para referirse a la transmisión, señalización o almacenamiento fuera de banda de manera que los datos fuera de banda estén asociados con el flujo de bits. La frase decodificación a lo largo del flujo de bits o similar puede referirse a la decodificación de los datos fuera de banda referidos (que pueden obtenerse de la transmisión, señalización o almacenamiento fuera de banda) que están asociados con el flujo de bits. Una imagen codificada es una representación codificada de una imagen.
Un conjunto de parámetros puede activarse mediante una referencia de un sector o de otro conjunto de parámetros activos o, en algunos casos, de otra estructura de sintaxis, tal como un mensaje SEI de período de almacenamiento en búfer.
Una unidad SEI NAL puede contener uno o más mensajes SEI, que no son necesarios para la decodificación de imágenes de salida, pero pueden ayudar en procesos relacionados, tales como temporización de salida de imágenes, reproducción, detección de errores, ocultación de errores y reserva de recursos. Varios mensajes SEI se especifican en H.264/AVC y HEVC, y los mensajes SEI de datos de usuario permiten a las organizaciones y empresas especificar mensajes SEI para su propio uso. H.264/AVC y HEVC contienen la sintaxis y la semántica de los mensajes SEI especificados, pero no se define ningún proceso para manejar los mensajes en el destinatario. En consecuencia, los codificadores deben seguir el estándar H.264/AVC o el estándar HEVC cuando crean mensajes SEI, y los decodificadores que cumplen con el estándar H.264/AVC o el estándar HEVC, respectivamente, no están obligados a procesar mensajes SEI para conformidad de la orden de salida. Una de las razones para incluir la sintaxis y la semántica de los mensajes SEI en H.264/AVC y HEVC es permitir que diferentes especificaciones del sistema interpreten la información complementaria de forma idéntica y, por lo tanto, interoperen. Se pretende que las especificaciones del sistema puedan requerir el uso de mensajes SEI particulares tanto en el extremo de codificación como en el extremo de decodificación, y además se puede especificar el proceso para manejar mensajes SEI particulares en el destinatario.
En HEVC, hay dos tipos de unidades SEI NAL, a saber, la unidad SEI NAL del sufijo y la unidad SEI NAL del prefijo, que tienen un valor de tipo_unidad_nal diferente entre sí. Los mensajes SEI contenidos en una unidad SEI NAL de sufijo están asociados con la unidad NAL de VCL que precede, en orden de decodificación, a la unidad SEI NAL de sufijo. Los mensajes SEI contenidos en una unidad SEI NAL de prefijo están asociados con la unidad NAL VCL que sigue, en orden de decodificación, la unidad SEI NAL de prefijo.
Una imagen codificada es una representación codificada de una imagen. Una imagen codificada en H.264/AVC comprende las unidades VCL NAL que se requieren para la decodificación de la imagen. En H.264/AVC, una imagen codificada puede ser una imagen codificada primaria o una imagen codificada redundante. Una imagen codificada primaria se utiliza en el proceso de decodificación de flujos de bits válidos, mientras que una imagen codificada redundante es una representación redundante que solo debe decodificarse cuando la imagen codificada primaria no se puede decodificar correctamente. En HEVC, no se ha especificado ninguna imagen codificada redundante.
En H.264/AVC, una unidad de acceso (AU) comprende una imagen codificada primaria y las unidades NAL que están asociadas con ella. En H.264/AVC, el orden de aparición de las unidades NAL dentro de una unidad de acceso está restringido de la siguiente manera. Una unidad NAL delimitador de unidad de acceso opcional puede indicar el inicio de una unidad de acceso. Le siguen cero o más unidades SEI NAL. Los cortes codificados de la imagen codificada primaria aparecen a continuación. En H.264/AVC, el sector codificado de la imagen codificada primaria puede ir seguido de sectores codificados para cero o más imágenes codificadas redundantes. Una imagen codificada redundante es una representación codificada de una imagen o parte de una imagen. Una imagen codificada redundante puede decodificarse si el decodificador no recibe la imagen codificada primaria, por ejemplo, debido a una pérdida en la transmisión o una corrupción en el medio de almacenamiento físico.
En H.264/AVC, una unidad de acceso también puede incluir una imagen codificada auxiliar, que es una imagen que complementa la imagen codificada primaria y puede usarse, por ejemplo, en el proceso de visualización. Una imagen codificada auxiliar puede usarse, por ejemplo, como un canal alfa o plano alfa especificando el nivel de transparencia de las muestras en las imágenes decodificadas. Se puede usar un canal o plano alfa en una composición en capas o en un sistema de reproducción, donde la imagen de salida se forma superponiendo imágenes que son al menos parcialmente transparentes una encima de la otra. Una imagen codificada auxiliar tiene las mismas restricciones sintácticas y semánticas que una imagen codificada redundante monocroma. En H.264/AVC, una imagen codificada auxiliar contiene el mismo número de macrobloques que la imagen codificada primaria.
En HEVC, una imagen codificada se puede definir como una representación codificada de una imagen que contiene todas las unidades de árbol de codificación de la imagen. En HEVC, una unidad de acceso (AU) puede definirse como un conjunto de unidades NAL que están asociadas entre sí de acuerdo con una regla de clasificación específica, son consecutivas en el orden de decodificación y contienen como máximo una imagen con cualquier valor específico de capa nuh identificación. Además de contener las unidades VCL NAL de la imagen codificada, una unidad de acceso también puede contener unidades no VCL NAL.
Dicha regla de clasificación especificada se puede especificar, por ejemplo, como sigue. La primera unidad de acceso en el flujo de bits comienza con la primera unidad NAL del flujo de bits. Una unidad VCL NAL es la primera unidad VCL NAL de una unidad de acceso, cuando se cumplen todas las condiciones siguientes:
- El sector contenido en las unidades VCL NAL es el primer sector de una imagen codificada, que en HEVC es equivalente a la condición de que first_slice_segment_in_pic_flag es igual a 1.
- La imagen codificada anterior en el orden de decodificación pertenece a una unidad de acceso de diferencia, que en las extensiones de múltiples capas HEVC corresponden al menos a una de las siguientes condiciones si se cumple:
o La imagen anterior en el orden de decodificación pertenece a un período de reinicio de POC diferente al de la imagen que contiene la unidad VCL NAL.
o PicOrderCntVal derivado de la unidad VCL NAL difiere del PicOrderCntVal de la imagen anterior en el orden de decodificación.
La primera de las unidades NAL que están permitidas, según las especificaciones de la unidad NAL, para aparecer en la unidad de acceso antes de la primera unidad VCL NAL primero Vc1Na1UnitInAu de la unidad de acceso en orden de decodificación y que sigue a la última unidad VCL NAL de la unidad de acceso anterior, en orden de decodificación, inicia la unidad de acceso. En HEVC, la primera de cualquiera de las siguientes unidades NAL que precede a la primera unidad VCL NAL firstVclNalUnitInAu y que sigue a la última unidad VCL NAL que precede a firstVclNalUnitInAu, si existe, especifica el inicio de una nueva unidad de acceso:
- Unidad de acceso al delimitador NAL (si está presente).
- Unidad VPS NAL (si está presente)
- Unidad SPS NAL (si está presente)
- Unidad PPS NAL (si está presente)
- Unidad de prefijo SEI NAL (si está presente)
- Unidades NAL con nal_unit_type en el rango de RSV_NVCL41 ..RSV_NVCL44 (si está presente)
- Unidades NAL con nal_unit_type en el rango de UNSPEC48..UNSPEC55 (si está presente) Cuando no hay ninguna de las unidades NAL anteriores antes de firstVclNalUnitInAu y sucediendo a la última unidad VCL NAL que precede a firstVclNalUnitInAu, si existe, firstVclNalUnitInAu inicia una nueva unidad de acceso.
Puede ser necesario que las imágenes codificadas aparezcan en cierto orden dentro de una unidad de acceso. Por ejemplo, se puede requerir que una imagen codificada con nuh_layer_id igual a nuhLayerIdA preceda, en orden de decodificación, todas las imágenes codificadas con nuh ID de capa mayor que nuhLayerIdA en la misma unidad de acceso.
Puede ser necesario que el orden de las imágenes codificadas y las unidades NAL no VCL dentro de una unidad de acceso obedezca a ciertas restricciones como las siguientes especificadas para extensiones HEVC multicapa: - Cuando esté presente una unidad NAL delimitador de la unidad de acceso, será la primera unidad NAL. Habrá como máximo una unidad NAL delimitadora de unidad de acceso en cualquier unidad de acceso.
- Cuando se encuentran presentes unidades VPS NAL, unidades SPS NAL, unidades PPS NAL, unidades SEI NAL con prefijo, unidades NAL con nal_unit_type en el rango de RSV_NVCL41..RSV_NVCL44, o unidades NAL con nal_unit_type en el rango de UNSPEC48..UNSPEC55, no seguirá la última unidad VCL NAL de la unidad de acceso. - Las unidades NAL que tengan nal_unit_type igual a FD_NUT o SUFFIX_SEI_NUT, o en el rango de RSV_NVCL45..RSV_NVCL47 o UNSPEC56..UNSPEC63 no precederán a la primera unidad VCL NAL de la unidad de acceso.
- Cuando está presente una unidad NAL de fin de secuencia con nuh_layer_id nuhLayerId, será la última unidad NAL con nuh_layer_id igual a nuhLayerId en la unidad de acceso que no sea una unidad NAL de fin de flujo de bits (si está presente).
- Cuando está presente una unidad NAL de fin de flujo de bits, será la última unidad NAL en la unidad de acceso. En HEVC, una unidad de imagen puede definirse como un conjunto de unidades NAL que contienen todas las unidades VCL NAL de una imagen codificada y sus unidades NAL no VCL asociadas. Una unidad VCL NAL asociada para una unidad no VCL NAL puede definirse como la unidad VCL NAL anterior, en orden de decodificación, de la unidad no VCL NAL para ciertos tipos de unidades no VCL NAL y la siguiente unidad VCL NAL, en orden de decodificación, de la unidad NAL no VCL para otros tipos de unidades nA l no VCL. Una unidad NAL no VCL asociada para una unidad NAL VCL puede definirse como una unidad NAL no VCL para la cual la unidad NAL VCL es la unidad NAL VCL asociada. Por ejemplo, en HEVC, una unidad VCL NAL asociada puede definirse como la unidad VCL NAL anterior en el orden de decodificación para una unidad no VCL NAL con nal_unit_type igual a EOS_NUT, EOB_NUT, FD_NUT o SUFFIX SEI NUT, o en los rangos de RSV_NVCL45..RSV_NVCL47 o UNSPEC56..UNSPEC63; o de lo contrario, la siguiente unidad VCL NAL en orden de decodificación.
Un flujo de bits puede definirse como una secuencia de bits, en forma de un flujo de unidad NAL o un flujo de bytes, que forma la representación de imágenes codificadas y datos asociados que forman una o más secuencias de vídeo codificadas. Un primer flujo de bits puede ir seguido de un segundo flujo de bits en el mismo canal lógico, como en el mismo archivo o en la misma conexión de un protocolo de comunicación. Un flujo elemental (en el contexto de la codificación de video) puede definirse como una secuencia de uno o más flujos de bits. El final del primer flujo de bits puede indicarse mediante una unidad NAL específica, que puede denominarse unidad NAL de fin de flujo de bits (EOB) y que es la última unidad NAL del flujo de bits. En HEVC y sus extensiones de borrador actuales, se requiere que la unidad EOB NAL tenga una identificación de capa nueva igual a 0.
En H.264/AVC, una secuencia de video codificada se define como una secuencia de unidades de acceso consecutivas en orden de decodificación desde una unidad de acceso IDR, inclusive, a la siguiente unidad de acceso IDR, exclusiva, o al final del flujo de bits, lo que aparezca antes.
En HEVC, una secuencia de video codificada (CVS) puede definirse, por ejemplo, como una secuencia de unidades de acceso que consiste, en orden de decodificación, en una unidad de acceso IRAP con NoRaslOutputFlag igual a 1, seguido de cero o más unidades de acceso que no son unidades de acceso IRAP con NoRaslOutputFlag igual a 1, incluidas todas las unidades de acceso posteriores hasta, pero sin incluir, cualquier unidad de acceso posterior que sea una unidad de acceso IRAP con NoRaslOutputFlag igual a 1. Una unidad de acceso IRAP puede definirse como una unidad de acceso en el que la imagen de la capa base es una imagen IRAP. El valor de NoRaslOutputFlag es igual a 1 para cada imagen IDR, cada imagen BLA y cada imagen IRAP que es la primera imagen en esa capa particular en el flujo de bits en orden de decodificación, es la primera imagen IRAP que sigue a una unidad NAL de fin de secuencia teniendo el mismo valor de nuh_layer_id en el orden de decodificación. En HEVC multicapa, el valor de NoRaslOutputFlag es igual a 1 para cada imagen IRAP cuando su nuh_layer_id es tal que LayerInitializedFlag [nuh_layer_id] es igual a 0 y LayerInitializedFlag [refLayerId] es igual a 1 para todos los valores de refLayerId nuh_layer_id] [j], donde j está en el rango de 0 a NumDirectRefLayers [nuh_layer_id] -1, inclusive. De lo contrario, el valor de NoRaslOutputFlag es igual a HandleCraAsBlaFlag. NoRaslOutputFlag igual a 1 tiene el impacto de que las imágenes RASL asociadas con la imagen IRAP para la que se establece NoRaslOutputFlag no son emitidas por el decodificador. Puede haber medios para proporcionar el valor de HandleCraAsBlaFlag al decodificador desde una entidad externa, como un reproductor o un receptor, que puede controlar el decodificador. HandleCraAsBlaFlag puede establecerse en 1, por ejemplo, por un reproductor que busca una nueva posición en un flujo de bits o sintoniza una transmisión y comienza a decodificar y luego comienza a decodificar a partir de una imagen CRA. Cuando HandleCraAsBlaFlag es igual a 1 para una imagen CRA, la imagen CRA se maneja y decodifica como si fuera una imagen BLA.
En HEVC, una secuencia de vídeo codificada puede especificarse adicional o alternativamente (según la especificación anterior) para finalizar, cuando una unidad NAL específica, que puede denominarse unidad NAL de fin de secuencia (EOS), aparece en el flujo de bits y tiene un ID de capa nuh igual a 0.
En HEVC, un grupo de secuencia de video codificado (CVSG) puede definirse, por ejemplo, como uno o más CVS consecutivos en orden de decodificación que colectivamente consisten en una unidad de acceso IRAP que activa un VPS RBSP firstVpsRbsp que aún no estaba activo seguido por todas las unidades de acceso subsiguientes, en orden de decodificación, para las cuales firstVpsRbsp es el VPS RBSP activo hasta el final del flujo de bits o hasta pero excluyendo la unidad de acceso que activa un VPS RBSP diferente a firstVpsRbsp, lo que ocurra primero en el orden de decodificación.
Un grupo de imágenes (GOP) y sus características se pueden definir como sigue. Un GOP se puede decodificar independientemente de si se decodificaron imágenes anteriores. Un GOP abierto es un grupo de imágenes en el que las imágenes que preceden a la intraimagen inicial en el orden de salida pueden no ser correctamente decodificables cuando la decodificación comienza desde la intraimagen inicial del GOP abierto. En otras palabras, las imágenes de un GOP abierto pueden referirse (en inter predicción) a imágenes pertenecientes a un GOP anterior. Un decodificador HEVC puede reconocer una imagen interna que comienza un GOP abierto, porque un tipo de unidad NAL específico, el tipo de unidad CRA NAL, puede usarse para sus sectores codificados. Un g Op cerrado es un grupo de imágenes en el que todas las imágenes se pueden decodificar correctamente cuando la decodificación comienza desde la imagen intra inicial del GOP cerrado. En otras palabras, ninguna imagen en un GOP cerrado se refiere a ninguna imagen en GOP anteriores. En H.264/AVC y HEVC, un GOP cerrado puede comenzar desde una imagen IDR. En HEVC, un GOP cerrado también puede comenzar desde una imagen b La _W_RADL o BLA_N_LP. Una estructura de codificación GOP abierta es potencialmente más eficiente en la compresión en comparación con una estructura de codificación GOP cerrada, debido a una mayor flexibilidad en la selección de imágenes de referencia.
Una estructura de imágenes (SOP) puede definirse como una o más imágenes codificadas consecutivas en el orden de decodificación, en el que la primera imagen codificada en el orden de decodificación es una imagen de referencia en la subcapa temporal más baja y ninguna imagen codificada excepto potencialmente la primera imagen codificada en orden de decodificación es una imagen RAP. Todas las imágenes del SOP anterior preceden en orden de decodificación a todas las imágenes del SOP actual y todas las imágenes del SOP siguiente tienen éxito en el orden de decodificación de todas las imágenes del SOP actual. Un SOP puede representar una estructura de inter predicción jerárquica y repetitiva. El término grupo de imágenes (GOP) a veces se puede usar indistintamente con el término SOP y tiene la misma semántica que la semántica de SOP.
La sintaxis de flujo de bits de H.264/AVC y HEVC indica si una imagen en particular es una imagen de referencia para la predicción mutua de cualquier otra imagen. Las imágenes de cualquier tipo de codificación (I, P, B) pueden ser imágenes de referencia o imágenes no de referencia en H.264/AVC y HEVC.
En HEVC, se usa una estructura de sintaxis de conjunto de imágenes de referencia (RPS) y un proceso de decodificación. Un conjunto de imágenes de referencia válido o activo para una imagen incluye todas las imágenes de referencia utilizadas como referencia para la imagen y todas las imágenes de referencia que se mantienen marcadas como “utilizadas como referencia” para cualquier imagen posterior en el orden de decodificación. Hay seis subconjuntos del conjunto de imágenes de referencia, a los que se hace referencia como RefPicSetStCurr0 (también conocido como RefPicSetStCurrBefore), RefPicSetStCurr1 (también conocido como RefPicSetStCurrAfter), RefPicSetStCurr0, RefPicSetStPurrFoll1, RefPicSetStFoll1, RefPicSetStCurrAfter También se puede considerar que RefPicSetStFoll0 y RefPicSetStFoll1 forman conjuntamente un subconjunto RefPicSetStFoll. La notación de los seis subconjuntos es la siguiente. “Curr” se refiere a imágenes de referencia que están incluidas en las listas de imágenes de referencia de la imagen actual y, por lo tanto, pueden usarse como referencia entre predicciones para la imagen actual. “Foll” se refiere a imágenes de referencia que no están incluidas en las listas de imágenes de referencia de la imagen actual, pero que pueden usarse en imágenes posteriores en orden de decodificación como imágenes de referencia. “St” se refiere a imágenes de referencia a corto plazo, que generalmente pueden identificarse mediante un cierto número de bits menos significativos de su valor POC. “Lt” se refiere a imágenes de referencia a largo plazo, que se identifican específicamente y generalmente tienen una mayor diferencia de valores de POC con respecto a la imagen actual que lo que puede representarse mediante el determinado número mencionado de bits menos significativos. “0” se refiere a aquellas imágenes de referencia que tienen un valor POC menor que el de la imagen actual. “1” se refiere a las imágenes de referencia que tienen un valor de POC mayor que el de la imagen actual. RefPicSetStCurr0, RefPicSetStCurr1, RefPicSetStFoll0 y RefPicSetStFoll1 se denominan colectivamente el subconjunto a corto plazo del conjunto de imágenes de referencia. RefPicSetLtCurr y RefPicSetLtFoll se denominan colectivamente el subconjunto a largo plazo del conjunto de imágenes de referencia.
En HEVC, un conjunto de imágenes de referencia puede especificarse en un conjunto de parámetros de secuencia y ponerse en uso en el encabezado del sector a través de un índice del conjunto de imágenes de referencia. También se puede especificar un conjunto de imágenes de referencia en un encabezado de sector. Un conjunto de imágenes de referencia puede codificarse de forma independiente o puede predecirse a partir de otro conjunto de imágenes de referencia (conocido como predicción entre RPS). En ambos tipos de codificación de conjuntos de imágenes de referencia, se envía adicionalmente un indicador (used_by_curr_pic_X_flag) para cada imagen de referencia que indica si la imagen de referencia se usa como referencia por la imagen actual (incluida en una lista * Curr) o no (incluida en una * Foll lista). Las imágenes que están incluidas en el conjunto de imágenes de referencia utilizadas por el sector actual se marcan como “utilizadas como referencia” y las imágenes que no están en el conjunto de imágenes de referencia utilizadas por el sector actual se marcan como “no utilizadas como referencia”. Si la imagen actual es una imagen IDR, RefPicSetStCurr0, RefPicSetStCurr1, RefPicSetStFoll0, RefPicSetStFoll1, RefPicSetLtCurr y RefPicSetLtFoll están todos configurados como vacíos.
Puede usarse un búfer de imagen decodificada (DPB) en el codificador y/o en el decodificador. Hay dos razones para almacenar imágenes decodificadas en búfer, para referencias en la predicción inter y para reordenar las imágenes decodificadas en el orden de salida. Como H.264/AVC y HEVC proporcionan una gran flexibilidad tanto para el marcado de la imagen de referencia como para el reordenamiento de salida, los búferes separados para el almacenamiento en búfer de la imagen de referencia y el almacenamiento en búfer de la imagen de salida pueden desperdiciar recursos de memoria. Por tanto, el DPB puede incluir un proceso unificado de almacenamiento en memoria intermedia de imágenes decodificadas para imágenes de referencia y reordenamiento de salida. Una imagen decodificada se puede eliminar del DPB cuando ya no se usa como referencia y no se necesita para la salida.
En muchos modos de codificación de H.264/AVC y HEVC, la imagen de referencia para la inter predicción se indica con un índice a una lista de imágenes de referencia. El índice se puede codificar con una codificación de longitud variable, lo que generalmente hace que un índice más pequeño tenga un valor más corto para el elemento de sintaxis correspondiente. En H.264/AVC y HEVC, se generan dos listas de imágenes de referencia (lista de imágenes de referencia 0 y lista de imágenes de referencia 1) para cada sector bi-predictivo (B), y se forma una lista de imágenes de referencia (lista de imágenes de referencia 0) para cada sector (P) intercodificada.
Una lista de imágenes de referencia, como la lista de imágenes de referencia 0 y la lista de imágenes de referencia 1, se construye típicamente en dos etapas: Primero, se genera una lista de imágenes de referencia inicial. La lista de imágenes de referencia inicial puede generarse, por ejemplo, sobre la base del número de cuadro, POC, temporaljd (o TemporalId o similar), o información sobre la jerarquía de predicción, como la estructura GOP, o cualquier combinación de los mismos. En segundo lugar, la lista de imágenes de referencia inicial puede reordenarse mediante comandos de reordenación de la lista de imágenes de referencia (RPLR), también conocidos como estructura de sintaxis de modificación de la lista de imágenes de referencia, que pueden estar contenidos en encabezados de sector. Si se utilizan conjuntos de imágenes de referencia, la lista de imágenes de referencia 0 puede inicializarse para contener primero RefPicSetStCurr0, seguido de RefPicSetStCurr1, seguido de RefPicSetLtCurr. La lista de imágenes de referencia 1 puede inicializarse para contener primero RefPicSetStCurr1, seguido de RefPicSetStCurr0. En HEVC, las listas de imágenes de referencia iniciales pueden modificarse mediante la estructura de sintaxis de modificación de la lista de imágenes de referencia, donde las imágenes de las listas de imágenes de referencia iniciales pueden identificarse mediante un índice de entrada a la lista. En otras palabras, en HEVC, la modificación de la lista de imágenes de referencia se codifica en una estructura de sintaxis que comprende un bucle sobre cada entrada en la lista de imágenes de referencia final, donde cada entrada de bucle es un índice codificado de longitud fija a la lista de imágenes de referencia inicial e indica la imagen en orden de posición ascendente en la lista de imágenes de referencia final.
Muchos estándares de codificación, incluidos H.264/AVC y HEVC, pueden tener un proceso de decodificación para derivar un índice de imagen de referencia a una lista de imágenes de referencia, que puede usarse para indicar cuál de las múltiples imágenes de referencia se usa para la inter predicción para un bloque en particular. Un índice de imagen de referencia puede ser codificado por un codificador en el flujo de bits en algunos modos de intercodificación o puede derivarse (por un codificador y un decodificador), por ejemplo, utilizando bloques vecinos en algunos otros modos de intercodificación.
Para representar eficazmente vectores de movimiento en flujos de bits, los vectores de movimiento pueden codificarse diferencialmente con respecto a un vector de movimiento predicho específico de bloque. En muchos códecs de video, los vectores de movimiento predichos se crean de una manera predefinida, por ejemplo, calculando la mediana de los vectores de movimiento codificados o decodificados de los bloques adyacentes. Otra forma de crear predicciones de vectores de movimiento, a veces denominadas predicción de vectores de movimiento avanzada (AMVP), es generar una lista de predicciones candidatas a partir de bloques adyacentes y/o bloques coubicados en imágenes de referencia temporal y señalizar al candidato elegido como movimiento predictor vectorial. Además de predecir los valores del vector de movimiento, se puede predecir el índice de referencia de la imagen codificada/decodificada previamente. El índice de referencia se predice típicamente a partir de bloques adyacentes y/o bloques coubicados en la imagen de referencia temporal. La codificación diferencial de los vectores de movimiento se inhabilita típicamente a través de los límites de los sectores.
La codificación de vídeo escalable puede referirse a una estructura de codificación en la que un flujo de bits puede contener múltiples representaciones del contenido, por ejemplo, a diferentes velocidades de bits, resoluciones o velocidades de cuadro. En estos casos, el receptor puede extraer la representación deseada en función de sus características (por ejemplo, la resolución que mejor se adapta al dispositivo de visualización). Alternativamente, un servidor o un elemento de red puede extraer las porciones del flujo de bits para ser transmitidas al receptor dependiendo de, por ejemplo, las características de la red o las capacidades de procesamiento del receptor. Se puede producir una representación decodificada significativa decodificando solo ciertas partes de un flujo de bits escalable. Un flujo de bits escalable consiste típicamente en una “capa base” que proporciona la calidad de video más baja disponible y una o más capas de mejora que mejoran la calidad del video cuando se reciben y decodifican junto con las capas inferiores. Para mejorar la eficiencia de codificación de las capas de mejora, la representación codificada de esa capa depende típicamente de las capas inferiores. Por ejemplo, la información de movimiento y modo de la capa de mejora se puede predecir a partir de capas inferiores. De manera similar, los datos de píxeles de las capas inferiores se pueden usar para crear predicciones para la capa de mejora.
En algunos esquemas de codificación de video escalables, una señal de video se puede codificar en una capa base y una o más capas de mejora. Una capa de mejora puede mejorar, por ejemplo, la resolución temporal (es decir, la velocidad de cuadros), la resolución espacial o simplemente la calidad del contenido de vídeo representado por otra capa o parte de la misma. Cada capa junto con todas sus capas dependientes es una representación de la señal de video, por ejemplo, con una determinada resolución espacial, resolución temporal y nivel de calidad. En este documento, nos referimos a una capa escalable junto con todas sus capas dependientes como una “representación de capa escalable”. La porción de un flujo de bits escalable correspondiente a una representación de capa escalable se puede extraer y decodificar para producir una representación de la señal original con cierta fidelidad.
Los modos de escalabilidad o las dimensiones de escalabilidad pueden incluir, entre otros, los siguientes:
- Escalabilidad de calidad: las imágenes de la capa base se codifican con una calidad más baja que las imágenes de la capa de mejora, lo que puede lograrse, por ejemplo, utilizando un valor de parámetro de cuantificación mayor (es decir, un tamaño de paso de cuantificación mayor para la cuantificación del coeficiente de transformación) en la capa base que en la capa de mejora.
- Escalabilidad espacial: las imágenes de la capa base se codifican con una resolución más baja (es decir, tienen menos muestras) que las imágenes de la capa de mejora. La escalabilidad espacial y la escalabilidad de calidad, en particular su tipo de escalabilidad de grano grueso, a veces pueden considerarse el mismo tipo de escalabilidad.
- Escalabilidad de profundidad de bits: las imágenes de la capa base se codifican con una profundidad de bits más baja (por ejemplo, 8 bits) que las imágenes de la capa de mejora (por ejemplo, 10 o 12 bits).
- Escalabilidad de rango dinámico: las capas escalables representan un rango dinámico diferente y/o imágenes obtenidas usando una función de mapeo de tonos diferente y/o una función de transferencia óptica diferente.
- Escalabilidad del formato de croma: las imágenes de la capa base proporcionan una resolución espacial más baja en matrices de muestras de croma (por ejemplo, Codificadas en formato de croma 4: 2: 0) que las imágenes de capa de mejora (por ejemplo, Formato 4: 4: 4).
- Escalabilidad de la gama de colores: las imágenes de la capa de mejora tienen un rango de representación de color más rico/amplio que el de las imágenes de la capa base; por ejemplo, la capa de mejora puede tener una gama de colores UHDTV (ITU-R BT.2020) y la capa base puede tener la gama de colores ITU. -R BT.709 gama de colores.
- Ver escalabilidad, que también puede denominarse codificación multivista. La capa base representa una primera vista, mientras que una capa de mejora representa una segunda vista.
- Escalabilidad de profundidad, que también puede denominarse codificación de profundidad mejorada. Una capa o algunas capas de un flujo de bits pueden representar vistas de textura, mientras que otras capas pueden representar vistas de profundidad.
- Escalabilidad de la región de interés (como se describe a continuación).
- Escalabilidad de entrelazado a progresivo (también conocida como escalabilidad de campo a cuadro): el material de contenido de origen entrelazado codificado de la capa base se mejora con una capa de mejora para representar el contenido de origen progresivo.
- Escalabilidad del códec híbrido (también conocida como escalabilidad estándar de codificación): en la escalabilidad del códec híbrido, la sintaxis del flujo de bits, la semántica y el proceso de decodificación de la capa base y la capa de mejora se especifican en diferentes estándares de codificación de video. Por tanto, las imágenes de la capa base se codifican de acuerdo con un formato o estándar de codificación diferente al de las imágenes de la capa de mejora. Por ejemplo, la capa base se puede codificar con H.264/AVC y una capa de mejora se puede codificar con una extensión de múltiples capas HEVC.
Debe entenderse que muchos de los tipos de escalabilidad se pueden combinar y aplicar juntos. Por ejemplo, se pueden combinar la escalabilidad de la gama de colores y la escalabilidad de la profundidad de bits.
El término capa se puede utilizar en el contexto de cualquier tipo de escalabilidad, incluida la escalabilidad de la vista y las mejoras de profundidad. Una capa de mejora puede referirse a cualquier tipo de mejora, como SNR, espacial, multivista, profundidad, profundidad de bits, formato de croma y/o mejora de la gama de colores. Una capa base puede referirse a cualquier tipo de secuencia de video base, como una vista base, una capa base para SNR/escalabilidad espacial o una vista base de textura para codificación de video con profundidad mejorada.
Actualmente se están investigando y desarrollando diversas tecnologías para proporcionar contenido de vídeo tridimensional (3D). Se puede considerar que en el video estereoscópico o de dos vistas, se presenta una secuencia de video o vista para el ojo izquierdo mientras que se presenta una vista paralela para el ojo derecho. Es posible que se necesiten más de dos vistas paralelas para aplicaciones que permitan el cambio de punto de vista o para pantallas autoestereoscópicas que pueden presentar un gran número de vistas simultáneamente y permitir que los espectadores observen el contenido desde diferentes puntos de vista.
Una vista puede definirse como una secuencia de imágenes que representan una cámara o un punto de vista. Las imágenes que representan una vista también pueden denominarse componentes de vista. En otras palabras, un componente de vista puede definirse como una representación codificada de una vista en una única unidad de acceso. En la codificación de video de múltiples vistas, más de una vista se codifica en un flujo de bits. Dado que las vistas están destinadas típicamente a mostrarse en una pantalla autoestrereoscópica estereoscópica o multivista o para ser utilizadas para otras configuraciones 3D, típicamente representan la misma escena y se superponen parcialmente en cuanto al contenido, aunque representan diferentes puntos de vista del contenido. Por lo tanto, la predicción entre vistas se puede utilizar en la codificación de video de múltiples vistas para aprovechar la correlación entre vistas y mejorar la eficiencia de la compresión. Una forma de realizar la predicción entre vistas es incluir una o más imágenes decodificadas de una o más vistas en la lista o listas de imágenes de referencia de una imagen que se codifica o decodifica y que reside en una primera vista. La escalabilidad de vista puede referirse a dicha codificación de video de múltiples vistas o secuencias de bits de video de múltiples vistas, que permiten la eliminación u omisión de una o más vistas codificadas, mientras que la secuencia de bits resultante permanece conforme y representa el video con un número menor de vistas que originalmente. La codificación de la región de interés (ROI) se puede definir para hacer referencia a la codificación de una región particular dentro de un video con una mayor fidelidad.
La escalabilidad de ROI puede definirse como un tipo de escalabilidad en el que una capa de mejora solo una parte de una imagen de la capa de referencia, por ejemplo, espacialmente, en términos de calidad, en profundidad de bits y/o en otras dimensiones de escalabilidad. Dado que la escalabilidad del ROI se puede utilizar junto con otros tipos de escalabilidad, se puede considerar que forma una categorización diferente de los tipos de escalabilidad. Existen varias aplicaciones diferentes para la codificación de ROI con diferentes requisitos, que se pueden realizar utilizando la escalabilidad de ROI. Por ejemplo, se puede transmitir una capa de mejora para mejorar la calidad y/o la resolución de una región en la capa base. Un decodificador que reciba tanto la mejora como el flujo de bits de la capa base podría decodificar ambas capas y superponer las imágenes decodificadas una encima de la otra y mostrar la imagen final.
La correspondencia espacial de una imagen de la capa de referencia y una imagen de la capa de mejora puede inferirse o puede indicarse con uno o más tipos de los denominados desplazamientos de ubicación de la capa de referencia. En HEVC, los desplazamientos de ubicación de la capa de referencia pueden ser incluidos en el PPS por el codificador y decodificados desde el PPS por el decodificador. Los desplazamientos de ubicación de la capa de referencia se pueden utilizar para lograr la escalabilidad de ROI, pero no se limitan a ello. Los desplazamientos de ubicación de la capa de referencia pueden comprender uno o más desplazamientos de la capa de referencia escalados, desplazamientos de la región de referencia y conjuntos de fases de remuestreo. Los desplazamientos de la capa de referencia escalados se pueden considerar para especificar los desplazamientos horizontales y verticales entre la muestra en la imagen actual que está colocada con la muestra de luma superior izquierda de la región de referencia en una imagen decodificada en una capa de referencia y los desplazamientos horizontales y verticales entre la muestra en la imagen actual que está colocalizada con la muestra de luma inferior derecha de la región de referencia en una imagen decodificada en una capa de referencia. Otra forma es considerar los desplazamientos de la capa de referencia escalados para especificar las posiciones de las muestras de las esquinas de la región de referencia muestreada con respecto a las respectivas muestras de las esquinas de la imagen de la capa de mejora. Los valores de desplazamiento de la capa de referencia escalados pueden estar firmados. Los desplazamientos de la región de referencia se pueden considerar para especificar las compensaciones horizontales y verticales entre la muestra de luma superior izquierda de la región de referencia en la imagen decodificada en una capa de referencia y la muestra de luma superior izquierda de la misma imagen decodificada, así como los desplazamientos horizontal y vertical entre una muestra de luma vertical inferior derecha de la región de referencia en la imagen decodificada en una capa de referencia y la muestra de luma inferior derecha de la misma imagen decodificada. Los valores de desplazamiento de la región de referencia pueden estar firmados. Se puede considerar un conjunto de fases de remuestreo para especificar los desplazamientos de fase utilizados en el proceso de remuestreo de una imagen fuente para la predicción entre capas. Pueden proporcionarse diferentes desplazamientos de fase para los componentes de luma y croma.
En el video estereoscópico compatible con cuadros (también conocido como empaquetado de cuadros de video estereoscópico), se realiza un empaquetado espacial de un par estéreo en un solo cuadro en el lado del codificador como una etapa de preprocesamiento para la codificación y luego los cuadros empaquetados están codificados con un esquema de codificación de video 2D convencional. Los cuadros de salida producidas por el decodificador contienen cuadros constituyentes de un par estéreo.
En un modo de funcionamiento típico, la resolución espacial de los fotogramas originales de cada vista y el fotograma único empaquetado tienen la misma resolución. En este caso, el codificador reduce la resolución de las dos vistas del video estereoscópico antes de la operación de empaquetado. El empaquetado espacial puede usar, por ejemplo, un formato de lado a lado o de arriba a abajo, y el muestreo debe realizarse de acuerdo con lo anterior.
El empaquetado de cuadros puede ser preferible a la codificación de video de múltiples vistas (por ejemplo, extensión MVC de H.264/AVC o extensión MV-h Ev C de H.265/HEVC), por ejemplo, debido a las siguientes razones:
- Los flujos de trabajo de posproducción pueden adaptarse para una única señal de video. Es posible que algunas herramientas de posproducción no puedan manejar dos secuencias de imágenes separadas y/o no puedan mantener las secuencias de imágenes separadas en sincronía entre sí.
- El sistema de distribución, como los protocolos de transmisión, puede ser tal que admita solo una secuencia codificada única y/o no pueda mantener secuencias codificadas separadas en sincronía entre sí y/o puede requerir más almacenamiento en búfer o latencia para mantener las secuencias de codificación separadas en sincronía entre sí.
- La decodificación de flujos de bits con herramientas de codificación de video de múltiples vistas puede requerir la compatibilidad con modos de codificación específicos, que pueden no estar disponibles en los reproductores. Por ejemplo, muchos teléfonos inteligentes admiten la decodificación del perfil principa1H.265/HEVC, pero no pueden manejar la decodificación del perfil principal H.265/HEVC Multiview aunque solo requiere adiciones de alto nivel en comparación con el perfil principal.
Algunos esquemas de codificación de vídeo escalables pueden requerir que las imágenes IRAP se alineen a través de las capas de manera que todas las imágenes en una unidad de acceso sean imágenes IRAP o ninguna imagen en una unidad de acceso sea una imagen IRAP. Otros esquemas de codificación de video escalables, como las extensiones multicapa de HEVC, pueden permitir imágenes IRAP que no están alineadas, es decir, que una o más imágenes en una unidad de acceso son imágenes IRAP, mientras que una o más imágenes en una unidad de acceso no son imágenes IRAP. Los flujos de bits escalables con imágenes IRAP o similares que no están alineados entre capas pueden usarse, por ejemplo, para proporcionar imágenes IRAP más frecuentes en la capa base, donde pueden tener un tamaño codificado más pequeño debido a, por ejemplo, una resolución espacial más pequeña. En un esquema de decodificación de vídeo se puede incluir un proceso o mecanismo para el inicio de la decodificación por capas. Por lo tanto, los decodificadores pueden comenzar a decodificar un flujo de bits cuando una capa base contiene una imagen IRAP y comenzar a decodificar paso a paso otras capas cuando contienen imágenes IRAP. En otras palabras, en una puesta en marcha por capas del mecanismo o proceso de decodificación, los decodificadores aumentan progresivamente el número de capas decodificadas (donde las capas pueden representar una mejora en la resolución espacial, nivel de calidad, vistas, componentes adicionales como profundidad o una combinación) ya que las imágenes posteriores de las capas de mejora adicionales se decodifican en el proceso de decodificación. El aumento progresivo del número de capas decodificadas puede percibirse, por ejemplo, como una mejora progresiva de la calidad de la imagen (en caso de calidad y escalabilidad espacial).
Un mecanismo de puesta en marcha por capas puede generar imágenes no disponibles para las imágenes de referencia de la primera imagen en orden de decodificación en una capa de mejora particular. Alternativamente, un decodificador puede omitir la decodificación de imágenes que preceden, en orden de decodificación, a la imagen IRAP a partir de la cual se puede iniciar la decodificación de una capa. Estas imágenes que pueden omitirse pueden ser etiquetadas específicamente por el codificador u otra entidad dentro del flujo de bits. Por ejemplo, se pueden usar uno o más tipos de unidades NAL específicos para ellos. Estas imágenes, independientemente de si están marcadas específicamente con un tipo de unidad NAL o se infieren, por ejemplo, por el decodificador, pueden denominarse imágenes de salto de acceso aleatorio entre capas (CL-RAS). El decodificador puede omitir la salida de las imágenes no disponibles generadas y las imágenes CL-RAS decodificadas.
Un remitente, una puerta de enlace, un cliente u otra entidad pueden seleccionar las capas y/o subcapas transmitidas de un flujo de bits de vídeo escalable. Los términos extracción de capas, extracción de capas o conmutación de capas hacia abajo pueden referirse a transmitir menos capas de las que están disponibles en el flujo de bits recibido por el remitente, la puerta de enlace, el cliente u otra entidad. La conmutación ascendente de capa puede referirse a la transmisión de capas adicionales en comparación con las transmitidas antes de la conmutación ascendente de capa por parte del remitente, la puerta de enlace, el cliente u otra entidad, es decir, reiniciar la transmisión de una o más capas cuya transmisión fue cesó antes en la conmutación de capa hacia abajo. De manera similar a la conmutación descendente y/o ascendente de capa, el remitente, la puerta de enlace, el cliente u otra entidad pueden realizar conmutación descendente y/o ascendente de subcapas temporales. El remitente, la puerta de enlace, el cliente u otra entidad también pueden realizar conmutación descendente y/o conmutación ascendente de capa y subcapa. La conmutación hacia abajo y/o hacia arriba de capa y subcapa puede llevarse a cabo en la misma unidad de acceso o similar (es decir, virtualmente simultáneamente) o puede llevarse a cabo en diferentes unidades de acceso o similares (es decir, virtualmente en momentos distintos).
La escalabilidad se puede habilitar de dos formas básicas. Bien introduciendo nuevos modos de codificación para realizar la predicción de valores de píxeles o sintaxis de las capas inferiores de la representación escalable o colocando las imágenes de la capa inferior en una memoria intermedia de imágenes de referencia (por ejemplo, una memoria intermedia de imágenes decodificadas, DPB) de la capa superior. El primer enfoque puede ser más flexible y, por lo tanto, puede proporcionar una mejor eficiencia de codificación en la mayoría de los casos. Sin embargo, el segundo enfoque, la escalabilidad basada en el cuadro de referencia, se puede implementar de manera eficiente con cambios mínimos en los códecs de una sola capa y al mismo tiempo lograr la mayoría de las ganancias de eficiencia de codificación disponibles. Esencialmente, se puede implementar un códec de escalabilidad basado en cuadros de referencia utilizando la misma implementación de hardware o software para todas las capas, solo ocupándose de la gestión de DPB por medios externos.
Se puede implementar un codificador de video escalable para escalabilidad de calidad (también conocido como señal a ruido o SNR) y/o escalabilidad espacial como sigue. Para una capa base, se puede usar un codificador y decodificador de video no escalable convencional. Las imágenes reconstruidas/decodificadas de la capa base se incluyen en la memoria intermedia de imágenes de referencia y/o listas de imágenes de referencia para una capa de mejora. En caso de escalabilidad espacial, la imagen de la capa base reconstruida/decodificada se puede muestrear antes de su inserción en las listas de imágenes de referencia para una imagen de la capa de mejora. Las imágenes decodificadas de la capa base pueden insertarse en una lista o listas de imágenes de referencia para codificar/decodificar una imagen de la capa de mejora de manera similar a las imágenes de referencia decodificadas de la capa de mejora. En consecuencia, el codificador puede elegir una imagen de referencia de capa base como referencia entre predicciones e indicar su uso con un índice de imagen de referencia en el flujo de bits codificado. El decodificador decodifica a partir del flujo de bits, por ejemplo, a partir de un índice de imagen de referencia, que se utiliza una imagen de capa base como referencia entre predicciones para la capa de mejora. Cuando se utiliza una imagen de capa base decodificada como referencia de predicción para una capa de mejora, se denomina imagen de referencia entre capas.
Si bien el párrafo anterior describió un códec de video escalable con dos capas de escalabilidad con una capa de mejora y una capa base, debe entenderse que la descripción se puede generalizar a dos capas cualesquiera en una jerarquía de escalabilidad con más de dos capas. En este caso, una segunda capa de mejora puede depender de una primera capa de mejora en los procesos de codificación y/o decodificación y, por lo tanto, la primera capa de mejora puede considerarse como la capa base para la codificación y/o decodificación de la segunda capa de mejora. Además, debe entenderse que puede haber imágenes de referencia entre capas de más de una capa en una memoria intermedia de imágenes de referencia o listas de imágenes de referencia de una capa de mejora, y se puede considerar que cada una de estas imágenes de referencia entre capas reside en una capa base o una capa de referencia para la capa de mejora que se codifica y/o decodifica. Además, debe entenderse que en su lugar o adicionalmente pueden tener lugar otros tipos de procesamiento entre capas además del muestreo ascendente de imágenes de la capa de referencia. Por ejemplo, la profundidad de bits de las muestras de la imagen de la capa de referencia se puede convertir a la profundidad de bits de la capa de mejora y/o los valores de la muestra pueden someterse a un mapeo desde el espacio de color de la capa de referencia al espacio de color de la capa de mejora.
Un esquema de codificación y/o decodificación de video escalable puede usar codificación y/o decodificación de múltiples bucles, que se puede caracterizar como sigue. En la codificación/decodificación, se puede reconstruir/decodificar una imagen de capa base para utilizarla como imagen de referencia de compensación de movimiento para imágenes posteriores, en el orden de codificación/decodificación, dentro de la misma capa o como referencia para predicción entre capas (o entre -vista o entre componentes). La imagen de la capa base reconstruida/decodificada puede almacenarse en el DPB. Una imagen de capa de mejora también puede reconstruirse/decodificarse para ser utilizada como una imagen de referencia de compensación de movimiento para imágenes posteriores, en orden de codificación/decodificación, dentro de la misma capa o como referencia para entre predicción de capas (o entre vistas o entre componentes) para capas de mejora superiores, si las hubiera. Además de los valores de muestra reconstruidos/decodificados, los valores de los elementos de sintaxis de la capa de base/referencia o las variables derivadas de los valores de los elementos de sintaxis de la capa de base/de referencia pueden usarse en la predicción entre capas/entre componentes/inter vistas.
La predicción entre capas se puede definir como predicción de una manera que depende de elementos de datos (por ejemplo, valores de muestra o vectores de movimiento) de imágenes de referencia de una capa diferente a la capa de la imagen actual (que se codifica o decodifica). Existen muchos tipos de predicción entre capas y se pueden aplicar en un codificador/decodificador de video escalable. Los tipos disponibles de predicción entre capas pueden depender, por ejemplo, del perfil de codificación de acuerdo con el cual se codifica el flujo de bits o una capa particular dentro del flujo de bits o, cuando se decodifica, el perfil de codificación que tiene el flujo de bits o una capa particular dentro del flujo de bits es indicado para ajustarse. Alternativa o adicionalmente, los tipos disponibles de predicción entre capas pueden depender de los tipos de escalabilidad o del tipo de códec escalable o enmienda estándar de codificación de video (por ejemplo, SHVC, MV-HEVC o 3D-HEVC) que se esté utilizando.
Los tipos de predicción entre capas pueden comprender, entre otros, uno o más de los siguientes: predicción de muestras entre capas, predicción de movimiento entre capas, predicción residual entre capas. En la predicción de muestra entre capas, al menos un subconjunto de los valores de muestra reconstruidos de una imagen fuente para la predicción entre capas se usa como referencia para predecir valores de muestra de la imagen actual. En la predicción de movimiento entre capas, al menos un subconjunto de los vectores de movimiento de una imagen fuente para la predicción entre capas se usa como referencia para predecir los vectores de movimiento de la imagen actual. Normalmente, la predicción de información sobre qué imágenes de referencia están asociadas con los vectores de movimiento también se incluye en la predicción de movimiento entre capas. Por ejemplo, los índices de referencia de las imágenes de referencia para los vectores de movimiento pueden predecirse entre capas y/o el recuento del orden de las imágenes o cualquier otra identificación de una imagen de referencia puede predecirse entre capas. En algunos casos, la predicción de movimiento entre capas también puede comprender la predicción del modo de codificación de bloques, información de encabezado, particionamiento de bloques y/u otros parámetros similares. En algunos casos, la predicción de parámetros de codificación, como la predicción entre capas de la partición de bloques, puede considerarse como otro tipo de predicción entre capas. En la predicción residual entre capas, el error de predicción o residual de los bloques seleccionados de una imagen fuente para la predicción entre capas se utiliza para predecir la imagen actual. En la codificación de múltiples vistas más profundidad, como 3D-HEVC, se puede aplicar la predicción entre capas de componentes cruzados, en la que una imagen de un primer tipo, como una imagen de profundidad, puede afectar la predicción entre capas de una imagen de un segundo tipo, como una imagen de textura convencional. Por ejemplo, se puede aplicar un valor de muestra entre capas compensado por disparidad y/o predicción de movimiento, donde la disparidad puede derivarse al menos parcialmente de una imagen de profundidad.
Una capa de referencia directa puede definirse como una capa que puede usarse para la predicción entre capas de otra capa para la que la capa es la capa de referencia directa. Una capa de predicción directa se puede definir como una capa para la cual otra capa es una capa de referencia directa. Una capa de referencia indirecta puede definirse como una capa que no es una capa de referencia directa de una segunda capa, sino una capa de referencia directa de una tercera capa que es una capa de referencia directa o una capa de referencia indirecta de una capa de referencia directa de la segunda capa para la cual la capa es la capa de referencia indirecta. Una capa de predicción indirecta puede definirse como una capa para la cual otra capa es una capa de referencia indirecta. Una capa independiente se puede definir como una capa que no tiene capas de referencia directa. En otras palabras, no se predice una capa independiente mediante la predicción entre capas. Una capa sin base puede definirse como cualquier otra capa que la capa base, y la capa base puede definirse como la capa más baja en el flujo de bits. Una capa sin base independiente puede definirse como una capa que es tanto una capa independiente como una capa sin base.
En algunos casos, los datos en una capa de mejora se pueden truncar después de una determinada ubicación, o incluso en posiciones arbitrarias, donde cada posición de truncamiento puede incluir datos adicionales que representan una calidad visual cada vez más mejorada. Dicha escalabilidad se conoce como escalabilidad de grano fino (granularidad) (FGS).
De manera similar a MVC, en MV-HEVC, las imágenes de referencia entre vistas pueden incluirse en la lista o listas de imágenes de referencia de la imagen actual que se codifica o decodifica. SHVC utiliza una operación de decodificación de bucle múltiple (a diferencia de la extensión SVC de H.264/AVC). Se puede considerar que SHVC utiliza un enfoque basado en índices de referencia, es decir, se puede incluir una imagen de referencia entre capas en una o más listas de imágenes de referencia de la imagen actual que se codifica o decodifica (como se describió anteriormente).
Para la codificación de la capa de mejora, los conceptos y las herramientas de codificación de la capa base HEVC pueden usarse en SHVC, MV-HEVC y/o similares. Sin embargo, las herramientas adicionales de predicción entre capas, que emplean datos ya codificados (incluidas muestras de imágenes reconstruidas y parámetros de movimiento, también conocidos como información de movimiento) en la capa de referencia para codificar de manera eficiente una capa de mejora, pueden integrarse en SHVC, MV-HEVC y/o códec similar.
Una vista de textura se refiere a una vista que representa contenido de video ordinario, por ejemplo, que se ha capturado usando una cámara ordinaria y, por lo general, es adecuada para reproducir en una pantalla. Una vista de textura típicamente comprende imágenes que tienen tres componentes, un componente de luma y dos componentes de croma. A continuación, una imagen de textura comprende típicamente todas las imágenes que la componen o componentes de color a menos que se indique lo contrario, por ejemplo, con los términos imagen de textura luma e imagen de textura croma.
Una vista en profundidad se refiere a una vista que representa información de distancia de una muestra de textura del sensor de la cámara, información de disparidad o paralaje entre una muestra de textura y una muestra de textura respectiva en otra vista, o información similar. Una vista de profundidad puede comprender imágenes de profundidad (también conocidas como mapas de profundidad) que tienen un componente, similar al componente de luma de las vistas de textura. En algunos casos, también pueden estar presentes componentes de croma o matrices de muestras, aunque puede ser necesario que las matrices de muestras de croma decodificadas tengan un cierto valor de muestra y se puede ignorar la decodificación de las matrices de muestras de croma. Un mapa de profundidad es una imagen con información de profundidad por píxel, disparidad de píxeles respectivamente en dos vistas o similar. Por ejemplo, cada muestra en un mapa de profundidad representa la distancia de la muestra o muestras de textura respectivas desde el plano en el que se encuentra la cámara. En otras palabras, si el eje z está a lo largo del eje de disparo de las cámaras (y por lo tanto es ortogonal al plano en el que se encuentran las cámaras), una muestra en un mapa de profundidad representa el valor en el eje z.
El video de profundidad mejorada se refiere a un video de textura que tiene una o más vistas asociadas con un video de profundidad que tiene una o más vistas de profundidad. Se pueden usar varios enfoques para representar video con profundidad mejorada, incluido el uso de video más profundidad (V D) y video multivista más profundidad (MVD). En la representación de video más profundidad (V D), una vista única de la textura y la vista respectiva de la profundidad se representan como secuencias de imágenes de textura e imágenes de profundidad, respectivamente. La representación MVD contiene una serie de vistas de textura y sus respectivas vistas de profundidad. La información de profundidad se puede utilizar en la denominada representación basada en imágenes de profundidad para sintetizar vistas de textura en puntos de vista no representados por ninguna de las vistas de textura codificadas.
Un componente de vista de textura se puede definir como una representación codificada de la textura de una vista en una única unidad de acceso. Un componente de vista de textura en el flujo de bits de video de profundidad mejorada puede codificarse de una manera que sea compatible con un flujo de bits de textura de vista única o un flujo de bits de textura de vista múltiple para que un decodificador de vista única o de vista múltiple pueda decodificar las vistas de textura incluso si no tiene capacidad para decodificar vistas de profundidad. Por ejemplo, un decodificador H.264/AVC puede decodificar una vista de textura única de un flujo de bits H.264/AVC con profundidad mejorada. Un componente de vista de textura puede codificarse alternativamente de manera que un decodificador capaz de decodificar textura de vista única o de vista múltiple, como el decodificador H.264/AVC o MVC, no pueda decodificar el componente de vista de textura, por ejemplo, porque usa herramientas de codificación basadas en profundidad. Un componente de vista en profundidad puede definirse como una representación codificada de la profundidad de una vista en una única unidad de acceso. Un par de componentes de vista puede definirse como un componente de vista de textura y un componente de vista en profundidad de la misma vista dentro de la misma unidad de acceso. Un componente de vista de textura también puede denominarse imagen de textura o imagen de una vista o capa de textura, y un componente de vista de profundidad también puede denominarse imagen de profundidad o imagen de una vista o capa de profundidad.
El vídeo de profundidad mejorada se puede codificar de una manera en la que la textura y la profundidad se codifiquen independientemente entre sí. Por ejemplo, las vistas de textura pueden codificarse como un flujo de bits MVC y las vistas de profundidad pueden codificarse como otro flujo de bits MVC. El video con profundidad mejorada también se puede codificar de una manera en la que la textura y la profundidad se codifiquen conjuntamente. En una forma de codificación conjunta de vistas de textura y profundidad, algunas muestras decodificadas de una imagen de textura o elementos de datos para decodificar una imagen de textura se predicen o derivan de algunas muestras decodificadas de una imagen de profundidad o elementos de datos obtenidos en el proceso de decodificación de una imagen de profundidad. Alternativamente o además, algunas muestras decodificadas de una imagen de profundidad o elementos de datos para decodificar una imagen de profundidad se predicen o derivan de algunas muestras decodificadas de una imagen de textura o elementos de datos obtenidos en el proceso de decodificación de una imagen de textura. En otra opción, los datos de video codificados de textura y los datos de video codificados de profundidad no se predicen entre sí o uno no se codifica/decodifica sobre la base del otro, pero la textura codificada y la vista de profundidad se pueden multiplexar en el mismo flujo de bits en codificación y demultiplexado del flujo de bits en la decodificación. En otra opción más, mientras que los datos de video codificados de textura no se predicen a partir de los datos de video codificados de profundidad, por ejemplo, debajo de la capa de sector, algunas de las estructuras de codificación de alto nivel de las vistas de textura y las vistas de profundidad pueden compartirse o predecirse entre sí. Por ejemplo, se puede predecir un encabezado de sector de un sector de profundidad codificado a partir de un encabezado de sector de un sector de textura codificada. Además, algunos de los conjuntos de parámetros pueden ser utilizados tanto por vistas de textura codificadas como por vistas de profundidad codificadas.
Los formatos de vídeo de profundidad mejorada permiten la generación de vistas o imágenes virtuales en posiciones de cámara que no están representadas por ninguna de las vistas codificadas. En general, cualquier algoritmo de renderizado basado en imágenes en profundidad (DIBR) puede usarse para sintetizar vistas.
La entrada de un códec de vídeo 3D puede comprender, por ejemplo, un vídeo estereoscópico y la información de profundidad correspondiente con la línea de base estereoscópica b0. Luego, el códec de video 3D sintetiza una serie de vistas virtuales entre dos vistas de entrada con línea de base (bi <b0). Los algoritmos DIBR también pueden permitir la extrapolación de vistas que están fuera de las dos vistas de entrada y no entre ellas. De manera similar, los algoritmos DIBR pueden permitir la síntesis de vistas desde una vista única de la textura y la vista de profundidad respectiva. Sin embargo, para habilitar la representación multivista basada en DIBR, los datos de textura deben estar disponibles en el lado del decodificador junto con los datos de profundidad correspondientes.
En tal sistema 3DV, la información de profundidad se produce en el lado del codificador en forma de imágenes de profundidad (también conocidas como mapas de profundidad) para vistas de textura.
La información de profundidad se puede obtener por varios medios. Por ejemplo, la profundidad de la escena 3D puede calcularse a partir de la disparidad registrada capturando cámaras o sensores de imágenes en color. Un enfoque de estimación de profundidad, que también puede denominarse adaptación estéreo, toma una vista estereoscópica como entrada y calcula las disparidades locales entre las dos imágenes desplazadas de la vista. Dado que las dos vistas de entrada representan diferentes puntos de vista o perspectivas, el paralaje crea una disparidad entre las posiciones relativas de los puntos de la escena en los planos de imagen dependiendo de la distancia de los puntos. Un objetivo de la adaptación estéreo es extraer esas disparidades encontrando o detectando los puntos correspondientes entre las imágenes. Existen varios enfoques para la adaptación estéreo. Por ejemplo, en un enfoque de adaptación de bloques o plantillas, cada imagen se procesa píxel a píxel en bloques superpuestos, y para cada bloque de píxeles se realiza una búsqueda localizada horizontalmente de un bloque de adaptación en la imagen desplazada. Una vez que se calcula una disparidad de píxeles, se puede calcular el valor de profundidad correspondiente z, por ejemplo, por la ecuación (1):
Figure imgf000029_0001
donde f es la distancia focal de la cámara y b es la distancia de línea de base entre cámaras. Además, se puede considerar que d se refiere a la disparidad observada entre las dos cámaras o la disparidad estimada entre los píxeles correspondientes en las dos cámaras. Se puede considerar que el desplazamiento de la cámara Ad refleja un posible desplazamiento horizontal de los centros ópticos de las dos cámaras o un posible recorte horizontal en los fotogramas de la cámara debido al preprocesamiento. Sin embargo, dado que el algoritmo se basa en adaptación de bloques, la calidad de una estimación de la profundidad a través de la disparidad depende del contenido y, a menudo, no es precisa. Por ejemplo, no es posible una solución sencilla para la estimación de profundidad para fragmentos de imágenes que presentan áreas muy suaves sin texturas o con un gran nivel de ruido.
Alternativamente o además de la estimación de profundidad de vista estéreo descrita anteriormente, el valor de profundidad puede obtenerse usando el principio de tiempo de vuelo (TOF), por ejemplo, usando una cámara que puede estar provista de una fuente de luz, para ejemplo, un emisor de infrarrojos, para iluminar la escena. Un iluminador de este tipo puede disponerse para producir una emisión electromagnética de intensidad modulada para una frecuencia entre, por ejemplo, 10-100 MHz, lo que puede requerir el uso de LED o diodos láser. Se puede usar luz infrarroja para hacer que la iluminación sea discreta. La luz reflejada por los objetos en la escena es detectada por un sensor de imagen, que puede modularse sincrónicamente a la misma frecuencia que el iluminador. El sensor de imagen puede estar provisto de óptica; una lente que recoge la luz reflejada y un filtro óptico de paso de banda para pasar solo la luz con la misma longitud de onda que el iluminador, lo que ayuda a suprimir la luz de fondo. El sensor de imagen puede medir para cada píxel el tiempo que ha tardado la luz en viajar desde el iluminador hasta el objeto y viceversa. La distancia al objeto se puede representar como un cambio de fase en la modulación de iluminación, que se puede determinar a partir de los datos muestreados simultáneamente para cada píxel de la escena.
Alternativamente o además de la estimación de profundidad de vista estéreo y/o detección de profundidad del principio TOF descritas anteriormente, los valores de profundidad pueden obtenerse usando un enfoque de luz estructurada que puede operar, por ejemplo, aproximadamente como sigue. Un emisor de luz, como un emisor de láser infrarrojo o un emisor de LED infrarrojo, puede emitir luz que puede tener una cierta dirección en un espacio 3D (por ejemplo, seguir un escaneo de cuadro o un orden de escaneo pseudoaleatorio) y/o posición dentro de un conjunto de emisores de luz, así como un patrón determinado, por ejemplo, una cierta longitud de onda y/o patrón de amplitud. La luz emitida se refleja en los objetos y se puede capturar mediante un sensor, como un sensor de imagen infrarroja. La imagen/señales obtenidas por el sensor pueden procesarse en relación con la dirección de la luz emitida, así como el patrón de la luz emitida para detectar una correspondencia entre la señal recibida y la dirección/posición de la luz emitida, así como el patrón de la luz emitida, por ejemplo, utilizando un principio de triangulación. A partir de esta correspondencia se puede concluir una distancia y una posición de un píxel.
Debe entenderse que los métodos de estimación y detección de profundidad descritos anteriormente se proporcionan como ejemplos no limitantes y las realizaciones se pueden realizar con los métodos y aparatos de estimación y detección de profundidad descritos o cualquier otro.
Los mapas de disparidad o paralaje, tales como los mapas de paralaje especificados en la Norma Internacional ISO/IEC 23002-3, pueden procesarse de forma similar a los mapas de profundidad. La profundidad y la disparidad tienen una correspondencia directa y se pueden calcular entre sí mediante una ecuación matemática.
Las vistas de textura y las vistas de profundidad pueden codificarse en un solo flujo de bits donde algunas de las vistas de textura pueden ser compatibles con uno o más estándares de vídeo tales como H.264/AVC y/o MVC. En otras palabras, un decodificador puede decodificar algunas de las vistas de textura de tal flujo de bits y puede omitir las vistas de textura y las vistas de profundidad restantes.
Se ha especificado una enmienda para H.264/AVC para la codificación de mapas de profundidad. La enmienda se llama extensión MVC para la inclusión de mapas de profundidad y puede denominarse MVC D. La enmienda MVC D especifica la encapsulación de vistas de textura y vistas de profundidad en el mismo flujo de bits de manera que las vistas de textura sigan siendo compatibles con H.264/AVC y MVC para que un decodificador MVC pueda decodificar todas las vistas de textura de un flujo de bits MVC. D y un decodificador H.264/AVC es capaz de decodificar la vista de textura base de un flujo de bits MVC D. Además, las unidades VCL NAL de la vista en profundidad utilizan una sintaxis, semántica y proceso de decodificación idénticos a los de las vistas de textura debajo del encabezado de la unidad NAL.
Se ha especificado otra enmienda para H.264/AVC para mejorar la textura y la codificación del mapa de profundidad, que puede denominarse 3D-AVC. La enmienda 3D-AVC comprende herramientas de codificación de vídeo 3D específicas, como la predicción de síntesis de vistas. Los codificadores pueden optar por codificar vistas de profundidad sin base de una manera que se ajuste a MVC D o 3D-AVC. Del mismo modo, los codificadores pueden optar por codificar las vistas de textura sin base de una manera que se ajuste a MVC (y, por lo tanto, también a MVC D) o 3D-AVC.
La navegación desde el punto de vista libre puede referirse a aplicaciones o servicios en los que un usuario final tiene la capacidad de navegar libremente alrededor y a través de la escena que fue adquirida o capturada por un conjunto de cámaras. Las cámaras pueden formar, pero no es necesario, una matriz de cámaras sistemática, como una matriz de cámaras 1D paralelas. Además, las cámaras pueden estar ubicadas, pero no es necesario, de una manera que se adapte a la generación de contenido estereoscópico para pantallas estereoscópicas o multivista. Por ejemplo, las cámaras pueden formar un conjunto disperso de más de 10 cámaras, dispuestas arbitrariamente, con una línea de base más amplia que la que se usa normalmente para la generación de contenido de video estereoscópico para pantallas estereoscópicas.
Se puede usar equipo de usuario final específico para la aplicación o servicio de navegación de punto de vista libre. Por ejemplo, se pueden utilizar Oculus Rift o un visor de realidad virtual similar. El auricular puede rastrear el movimiento de la cabeza y/o los ojos y mostrar un punto de vista de acuerdo con lo anterior. El auricular puede ser capaz de visualizar contenido estereoscópico. Sin embargo, la navegación desde el punto de vista libre también se puede realizar con equipos de usuario final convencionales, como ordenadores de escritorio o portátiles, tabletas o teléfonos inteligentes.
La figura 5 muestra un ejemplo de un sistema para la transmisión de puntos de vista libres. Los datos de video de múltiples vistas se codifican, almacenan en un servidor y se proporcionan para el consumo de los dispositivos del cliente, lo que permite a los usuarios seleccionar de forma interactiva qué vista o vistas se representan. Cada cliente solicita una o más vistas del servidor según las capacidades de representación de su pantalla. Por ejemplo, un grupo de clientes utiliza pantallas 2D convencionales, un segundo grupo de clientes está equipado con pantallas estereoscópicas, mientras que un tercer grupo de usuarios puede mostrar más de dos vistas a la vez en una pantalla autoestereoscópica multivista. Para ahorrar ancho de banda de transmisión, el flujo de bits multivista transmitido se reduce de manera que solo incluye las vistas solicitadas y las vistas requeridas para decodificar las vistas solicitadas. Cuando un usuario cambia de punto de vista, el flujo de bits transmitido se adapta correspondientemente.
Los términos video de 360 grados o realidad virtual (VR) o video de video omnidireccional pueden usarse indistintamente. Por lo general, pueden referirse a contenido de video que proporciona un campo de visión tan grande que solo una parte del video se muestra en un solo punto de tiempo en configuraciones de visualización típicas. Por ejemplo, el video de realidad virtual se puede ver en una pantalla montada en el cabezal (HMD) que puede ser capaz de mostrar, por ejemplo, alrededor de un campo de visión de 100 grados. El subconjunto espacial del contenido de vídeo de realidad virtual que se va a visualizar puede seleccionarse basándose en la orientación de1HMD. En otro ejemplo, se supone un entorno de visualización de pantalla plana típico, en el que, por ejemplo, Se puede mostrar un campo de visión de hasta 40 grados. Cuando se muestra contenido de campo de visión amplio (por ejemplo, ojo de pez) en una pantalla de este tipo, puede ser preferible mostrar un subconjunto espacial en lugar de la imagen completa.
El contenido de imagen o video de 360 grados puede adquirirse y prepararse, por ejemplo, como sigue. Las imágenes o el video se pueden capturar con un conjunto de cámaras o un dispositivo de cámara con múltiples lentes y sensores. La adquisición da como resultado un conjunto de señales de imagen/vídeo digitales. Las cámaras/lentes generalmente cubren todas las direcciones alrededor del punto central del conjunto de cámara o dispositivo de cámara. Las imágenes de la misma instancia de tiempo se unen, proyectan y mapean en un cuadro VR empaquetado. El desglose del proceso de unión, proyección y mapeo de imágenes se ilustra en la Figura 6a y se describe a continuación. Las imágenes de entrada se unen y proyectan en una estructura de proyección tridimensional, como una esfera o un cubo. Se puede considerar que la estructura de proyección comprende una o más superficies, tales como planos o partes de los mismos. Una estructura de proyección puede definirse como una estructura tridimensional que consta de una o más superficies sobre las que se proyecta el contenido de imagen/vídeo de realidad virtual capturada, y a partir de las cuales se puede formar un cuadro proyectado respectiva. Los datos de imagen en la estructura de proyección se disponen además en un cuadro proyectado bidimensional. El término proyección puede definirse como un proceso mediante el cual se proyecta un conjunto de imágenes de entrada en un cuadro proyectado. Puede haber un conjunto predefinido de formatos de representación del cuadro proyectado, que incluye, por ejemplo, un panorama equirrectangular y un formato de representación de mapa de cubos.
Se puede aplicar un mapeo regional para mapear el cuadro proyectado en uno o más cuadros VR empaquetados. En algunos casos, se puede entender que el mapeo regional es equivalente a extraer dos o más regiones del cuadro proyectado, aplicando opcionalmente una transformación geométrica (como rotar, reflejar y/o remuestrear) a las regiones, y colocar las regiones transformadas en áreas espacialmente no superpuestas, también conocidas como particiones de cuadros constituyentes, dentro del cuadro de VR empaquetado. Si no se aplica el mapeo regional, el cuadro VR empaquetado es idéntica a el cuadro proyectado. De lo contrario, las regiones del cuadro proyectado se mapean en un cuadro VR empaquetado indicando la ubicación, forma y tamaño de cada región en el cuadro VR empaquetada. El término mapeo puede definirse como un proceso mediante el cual un cuadro proyectado se mapea a un cuadro VR empaquetado. El término empaquetamiento regional se puede usar indistintamente con mapeo regional. El término cuadro VR empaquetado puede definirse como un cuadro que resulta de un mapeo de un cuadro proyectado. En general, el mapeo regional podría aplicarse al contenido de origen que no tiene ningún formato de proyección, pero, por ejemplo, contenido de vídeo bidimensional convencional. Por lo tanto, el término cuadro empaquetado puede usarse indistintamente con el término cuadro VR empaquetado. En la práctica, las imágenes de entrada se pueden convertir en un cuadro VR empaquetado en un proceso sin etapas intermedios.
El contenido panorámico de 360 grados (es decir, imágenes y vídeo) cubre horizontalmente el campo de visión completo de 360 grados alrededor de la posición de captura de un dispositivo de formación de imágenes. El campo de visión vertical puede variar y puede ser, por ejemplo, 180 grados. La imagen panorámica que cubre un campo de visión de 360 grados horizontalmente y un campo de visión de 180 grados verticalmente se puede representar mediante una esfera que se puede asignar a un cilindro delimitador que se puede cortar verticalmente para formar una imagen en 2D (este tipo de proyección se conoce como proyección equirrectangular). El proceso de formación de una imagen panorámica equirrectangular monoscópica se ilustra en la Figura 6b. Un conjunto de imágenes de entrada, como imágenes de ojo de pez de un conjunto de cámaras o un dispositivo de cámara con múltiples lentes y sensores, se une a una imagen esférica. La imagen esférica se proyecta además en un cilindro (sin las caras superior e inferior). El cilindro se despliega para formar un cuadro proyectado bidimensional. En la práctica, se pueden fusionar uno o más de las etapas presentados; por ejemplo, las imágenes de entrada pueden proyectarse directamente sobre un cilindro sin una proyección intermedia sobre una esfera. La estructura de proyección para panorama equirrectangular puede considerarse un cilindro que comprende una sola superficie.
En general, el contenido de 360 grados se puede mapear en diferentes tipos de estructuras geométricas sólidas, como poliedro (es decir, un objeto sólido tridimensional que contiene caras poligonales planas, bordes rectos y esquinas o vértices afilados, por ejemplo, un cubo o una pirámide), cilindro (al proyectar una imagen esférica sobre el cilindro, como se describió anteriormente con la proyección equirrectangular), cilindro (directamente sin proyectar primero sobre una esfera), cono, etc. y luego desenvuelto en un plano de imagen bidimensional.
En algunos casos, el contenido panorámico con un campo de visión horizontal de 360 grados pero con un campo de visión vertical de menos de 180 grados puede considerarse casos especiales de proyección panorámica, donde las áreas polares de la esfera no han sido mapeado en el plano de imagen bidimensional. En algunos casos, una imagen panorámica puede tener un campo de visión horizontal de menos de 360 grados y un campo de visión vertical de hasta 180 grados, mientras que por lo demás tiene las características del formato de proyección panorámica.
Los ojos humanos no son capaces de ver todo el espacio de 360 grados, pero están limitados a un máximo de campo de visión horizontal y vertical (HHFoV, HVFoV). Además, un dispositivo HMD tiene limitaciones técnicas que solo permiten ver un subconjunto de todo el espacio de 360 grados en direcciones horizontal y vertical (DHFoV, DVFoV)).
En cualquier momento, un video renderizado por una aplicación en un HMD renderiza una porción del video de 360 grados. Esta porción se define aquí como Viewport. Una ventana gráfica es una ventana en el mundo 360 representado en el video omnidireccional que se muestra a través de una pantalla de renderizado. Una ventana gráfica se caracteriza por campos de visión horizontales y verticales (VHFoV, VVFoV). A continuación, VHFoV y VVFoV simplemente se abreviarán con HFoV y VFoV.
El tamaño de una ventana gráfica puede corresponder al HMD FoV o puede tener un tamaño más pequeño, dependiendo de la aplicación. En aras de claridad, definimos como ventana gráfica principal la parte del espacio de 360 grados que ve un usuario en un momento dado.
Cuando se almacena un flujo de bits multicapa, como un flujo de bits HEVC en capas, en un archivo, como un archivo ISOBMFF, se puede permitir almacenar una o más capas en una pista. Por ejemplo, cuando un proveedor de contenido desea proporcionar un flujo de bits multicapa que no está destinado a subconjuntos, o cuando el flujo de bits se ha creado para unos pocos conjuntos predefinidos de capas de salida donde cada capa corresponde a una vista (como 1, 2, 5 o 9 vistas), las pistas se pueden crear de acuerdo con lo anterior.
Cuando un flujo de bits con múltiples subcapas (también conocido como flujo de bits de múltiples subcapas), como un flujo de bits HEVC con múltiples subcapas, se almacena en un archivo, como un archivo ISOBMFF, se puede permitir almacenar de una o más subcapas en una pista y se puede utilizar más de una pista para contener el flujo de bits. Por ejemplo, una pista puede contener solo ciertas subcapas y no es necesario que contenga la subcapa más baja (por ejemplo, la subcapa con TemporalId igual a 0 en HEVC).
Un punto operativo puede definirse como un subconjunto decodificable de forma independiente de un flujo de bits en capas, que puede estar limitado además para comprender una o más capas que se indican como capas de salida. Cuando un flujo de bits multicapa y/o multicapa está representado por varias pistas y un reproductor utiliza un punto operativo para el que se necesita acceder a capas y/o subcapas de varias pistas, es posible que el reproductor deba reconstruir unidades de acceso antes de pasarlas al decodificador. Un punto de operación puede estar representado explícitamente por una pista, es decir, cada muestra en la pista contiene una unidad de acceso adecuada para el punto de operación, es decir, los datos, tales como unidades NAL, de la unidad de acceso pueden estar contenidos o referidos por extractores y agregadores. Además, la secuencia de muestras comprende un flujo de bits válido para el punto operativo. Si el número de puntos de operación es grande, puede requerir mucho espacio y ser poco práctico crear una pista para cada punto de operación. En tal caso, las pistas pueden comprender datos para ciertas capas y/o subcapas solamente y pueden no representar unidades de acceso completas y la secuencia de muestras puede no comprender un flujo de bits válido para un punto operativo. Un jugador puede utilizar un proceso de reconstrucción de unidades de acceso implícito para reconstruir unidades de acceso.
Un extractor puede definirse como un conjunto de instrucciones que, cuando se ejecutan, dan como resultado una pieza válida de datos de muestra de acuerdo con el formato de muestra subyacente. Por ejemplo, un extractor en una pista compatible con HEVC, cuando se ejecuta, da como resultado una o más unidades HEVc NAL completas. Los extractores especificados en ISO/IEC 14496-15 para H.264/AVC y HEVC permiten la formación compacta de pistas que extraen datos de la unidad NAL por referencia. Un extractor es una estructura similar a una unidad NAL. Se puede especificar una estructura similar a una unidad NAL para que comprenda un encabezado de unidad NAL y una carga útil de unidad NAL como cualquier unidad NAL, pero la prevención de emulación de código de inicio (que se requiere para una unidad NAL) podría no seguirse en una unidad similar a estructura NAL. Para HEVC, un extractor contiene uno o más constructores. Un constructor de muestras extrae, por referencia, datos de unidades NAL de una muestra de otra pista. Un constructor en línea incluye datos de la unidad NAL. Cuando un extractor es procesado por un lector de archivos que lo requiere, el extractor es reemplazado lógicamente por los bytes resultantes al resolver los constructores contenidos en su orden de aparición. La extracción anidada puede no permitirse, por ejemplo, los bytes a los que hace referencia un constructor de muestra no deben contener extractores; un extractor no hará referencia, directa o indirectamente, a otro extractor. Un extractor puede contener uno o más constructores para extraer datos de la pista actual o de otra pista que esté vinculada a la pista en la que reside el extractor mediante una referencia de pista de tipo 'sello'. Los bytes de un extractor resuelto pueden representar una o más unidades NAL completas. Un extractor resuelto comienza con un campo de longitud válido y un encabezado de unidad NAL. Los bytes de un constructor de muestra se copian solo de la muestra única identificada en la pista referenciada a través de la referencia de pista 'scal' indicada. La alineación se realiza en el tiempo de decodificación, es decir, utilizando solo la tabla de tiempo de muestreo, seguida de un desplazamiento contado en el número de muestra. Los extractores son un concepto de nivel de medios y, por lo tanto, se aplican a la pista de destino antes de que se considere cualquier lista de edición. (Sin embargo, normalmente se esperaría que las listas de edición en las dos pistas fueran idénticas).
Un identificador uniforme de recursos (URI) puede definirse como una cadena de caracteres utilizada para identificar un nombre de un recurso. Dicha identificación permite la interacción con representaciones del recurso a través de una red, utilizando protocolos específicos. Un URI se define mediante un esquema que especifica una sintaxis concreta y un protocolo asociado para el URI. El localizador uniforme de recursos (URL) y el nombre uniforme del recurso (URN) son formas de URI. Una URL puede definirse como una URI que identifica un recurso web y especifica los medios para actuar sobre el recurso u obtener la representación del mismo, especificando tanto su mecanismo de acceso principal como la ubicación de la red. Un URN puede definirse como un URI que identifica un recurso por su nombre en un espacio de nombres en particular. Un URN puede usarse para identificar un recurso sin implicar su ubicación o cómo acceder a él.
En muchos sistemas de transmisión o comunicación de video, mecanismos de transporte y formatos de archivo de contenedor multimedia, existen mecanismos para transmitir o almacenar una capa de escalabilidad separada de otra capa de escalabilidad del mismo flujo de bits, por ejemplo, para transmitir o almacenar la capa base por separado de la (s) capa (s) de mejora. Se puede considerar que las capas se almacenan o se transmiten a través de canales lógicos separados. A continuación, se proporcionan ejemplos:
- Formato de Archivo de Medios Base ISO (ISOBMFF, Estándar Internacional ISO/IEC 14496-12): la capa base se puede almacenar como una pista y cada capa de mejora se puede almacenar en otra pista. De manera similar, en un caso de escalabilidad de códec híbrido, una capa base no codificada en HEVC se puede almacenar como una pista (por ejemplo, del tipo de entrada de muestra 'avc1'), mientras que las capas de mejora se pueden almacenar como otra pista que está vinculada a la pista de la capa base utilizando las denominadas referencias de pista.
- Protocolo de Transporte en Tiempo Real (RTP): un flujo RTP se puede utilizar para transportar una o más capas y, por lo tanto, los flujos RTP de la misma sesión RTP pueden separar lógicamente diferentes capas.
- Flujo de transporte MPEG-2 (TS): cada capa puede tener un valor de identificador de paquete (PID) diferente.
Muchos sistemas de transmisión o comunicación de vídeo, mecanismos de transporte y formatos de archivo contenedor multimedia proporcionan medios para asociar datos codificados de canales lógicos separados, tales como pistas o sesiones diferentes, entre sí. Por ejemplo, existen mecanismos para asociar datos codificados de la misma unidad de acceso. Por ejemplo, los tiempos de decodificación o salida pueden proporcionarse en el formato de archivo contenedor o mecanismo de transporte, y se puede considerar que los datos codificados con el mismo tiempo de decodificación o salida forman una unidad de acceso.
Recientemente, el Protocolo de Transferencia de Hipertexto (HTTP) se ha utilizado ampliamente para la entrega de contenido multimedia en tiempo real a través de Internet, como en aplicaciones de transmisión de vídeo. A diferencia del uso del Protocolo de Transporte en Tiempo Real (RTP) sobre el Protocolo de Datagramas de Usuario (UDP), HTTP es fácil de configurar y, por lo general, se le otorga un cruce de firewalls y traductores de direcciones de red (NAT), lo que lo hace atractivo para aplicaciones de transmisión multimedia.
Se han lanzado varias soluciones comerciales para la transmisión adaptativa sobre HTTP, como Microsoft® Smooth Streaming, Apple® Adaptive HTTP Live Streaming y Adobe® Dynamic Streaming, así como se han llevado a cabo proyectos de estandarización. La transmisión HTTP adaptable (AHS) se estandarizó por primera vez en la versión 9 del servicio de transmisión por conmutación de paquetes (PSS) del Proyecto de Asociación de Tercera Generación (3GPP) (3GPP TS 26.234 versión 9: “Transparent end-to-end packetswitched streaming service (PSS); protocols and codecs”). MPEG tomó 3GPP AHS Release 9 como punto de partida para el estándar MPEG DASH (Is O/IEC 23009­ 1: “Dynamic adaptive streaming over HTTP (DASH)-Part 1: Media presentation description and segment formats,” Estándar internacional, segunda edición, 2014). 3GPP continuó trabajando en transmisión HTTP adaptativa en comunicación con MPEG y publicó 3GP-DASH (Transmisión dinámica adaptativa a través de HTTP; 3GPP Ts 26.247: “Transparent end-to-end packet-switched streaming Service (PSS); Progressive download and dynamic adaptive Streaming over HTTP (3GP-DASH)”. MPEG DASH y 3GP-DASH están técnicamente cerca entre sí y, por lo tanto, pueden denominarse colectivamente DASH. Algunos conceptos, formatos y operaciones de DASH se describen a continuación como un ejemplo de un sistema de transmisión de video, en el que se pueden implementar las realizaciones. Los aspectos de la invención no se limitan a DASH, sino que se da la descripción de una posible base sobre la cual la invención puede realizarse parcial o totalmente.
En DASH, el contenido multimedia puede almacenarse en un servidor HTTP y puede entregarse usando HTTP. El contenido puede almacenarse en el servidor en dos partes: Descripción de presentación de medios (MPD), que describe un manifiesto del contenido disponible, sus diversas alternativas, sus direcciones URL y otras características; y segmentos, que contienen los flujos de bits multimedia reales en forma de fragmentos, en uno o varios archivos. El MDP proporciona la información necesaria para que los clientes establezcan una transmisión dinámica adaptativa a través de HTTP. El MPD contiene información que describe la presentación de los medios, como un localizador de recursos (URL) uniforme HTTP de cada Segmento para realizar una solicitud de Segmento GET. Para reproducir el contenido, el cliente DASH puede obtener el MPD, por ejemplo, mediante HTTP, correo electrónico, memoria USB, difusión u otros métodos de transporte. Al analizar el MPD, el cliente DASH puede conocer el tiempo del programa, la disponibilidad del contenido de los medios, los tipos de medios, las resoluciones, los anchos de banda mínimos y máximos, y la existencia de varias alternativas codificadas de componentes multimedia, características de accesibilidad y administración de derechos digitales requeridos (DRM), ubicaciones de los componentes de medios en la red y otras características del contenido. Usando esta información, el cliente DASH puede seleccionar la alternativa codificada apropiada y comenzar a transmitir el contenido obteniendo los segmentos usando, por ejemplo, Solicitudes HTTP GET. Después del almacenamiento en búfer apropiado para permitir variaciones de rendimiento de la red, el cliente puede continuar obteniendo los segmentos subsiguientes y también monitorear las fluctuaciones del ancho de banda de la red. El cliente puede decidir cómo adaptarse al ancho de banda disponible obteniendo segmentos de diferentes alternativas (con tasas de bits más bajas o más altas) para mantener un búfer adecuado.
En DASH, el modelo de datos jerárquico se usa para estructurar la presentación de los medios como se muestra en la Figura 7. Una presentación de medios consta de una secuencia de uno o más períodos, cada período contiene uno o más grupos, cada grupo contiene uno o más Conjuntos de Adaptación, cada Conjunto de Adaptación contiene una o más representaciones, cada representación consta de uno o más segmentos. Una representación es una de las opciones alternativas del contenido de los medios o un subconjunto del mismo que típicamente difiere por la elección de codificación, por ejemplo, por tasa de bits, resolución, idioma, códec, etc. El Segmento contiene cierta duración de datos de medios y metadatos para decodificar y presentar el contenido de medios incluido. Un Segmento se identifica mediante un URI y, por lo general, se puede solicitar mediante una solicitud HTTP GET. Un Segmento puede definirse como una unidad de datos asociada con una URL HTTP y, opcionalmente, un rango de bytes especificado por un MPD.
El DASH MPD cumple con el Lenguaje de marcado extensible (XML) y, por lo tanto, se especifica mediante elementos y atributos definidos en XML. El MPD puede especificarse utilizando las siguientes convenciones: Los elementos de un documento XML pueden identificarse mediante una primera letra mayúscula y pueden aparecer en negrita como Element. Para expresar que un elemento Element1 está contenido en otro elemento Element2, se puede escribir Element2.Element1. Si el nombre de un elemento consta de dos o más palabras combinadas, se puede utilizar la envoltura de camello, por ejemplo, ImportantElement. Los elementos pueden estar presentes exactamente una vez, o la ocurrencia mínima y máxima puede ser definida por <minOccurs> ... <maxOccurs>. Los atributos en un documento XML pueden identificarse con una primera letra minúscula y también pueden estar precedidos por un signo '@', por ejemplo, @attribute. Para señalar un atributo @attribute específico contenido en un elemento Element, se puede escribir Element @attribute. Si el nombre de un atributo consta de dos o más palabras combinadas, se puede usar la palabra camel-case después de la primera palabra, por ejemplo, @veryImportantAttribute. Los atributos pueden tener asignado un estado en el XML como obligatorio (M), opcional (O), opcional con valor predeterminado (OD) y condicionalmente obligatorio (CM).
En DASH, todos los elementos descriptores están estructurados de la misma manera, es decir, contienen un atributo @schemeIdUri que proporciona un URI para identificar el esquema y un atributo opcional @value y un atributo opcional @id. La semántica del elemento es específica del esquema empleado. El URI que identifica el esquema puede ser un URN o un URL. Algunos descriptores se especifican en Mp EG-DASH (ISO/IEC 23009-1), mientras que los descriptores se pueden especificar adicional o alternativamente en otras especificaciones. Cuando se especifica en especificaciones distintas de MPEG-DASH, el MPD no proporciona ninguna información específica sobre cómo utilizar los elementos descriptores. Depende de la aplicación o especificación que emplee formatos DASH instanciar los elementos de descripción con la información de esquema adecuada. Las aplicaciones o especificaciones que usan uno de estos elementos definen un Identificador de Esquema en forma de URI y el espacio de valores para el elemento cuando se usa ese Identificador de Esquema. El Identificador de Esquema aparece en el atributo @schemeIdUri. En el caso de que se requiera un conjunto simple de valores enumerados, se puede definir una cadena de texto para cada valor y esta cadena se puede incluir en el atributo @value. Si se requieren datos estructurados, cualquier elemento de extensión o atributo se puede definir en un espacio de nombres separado. El valor @id se puede utilizar para hacer referencia a un descriptor único o a un grupo de descriptores. En el último caso, se puede requerir que los descriptores con valores idénticos para el atributo @id sean sinónimos, es decir, el procesamiento de uno de los descriptores con un valor idéntico para @id es suficiente. Dos elementos de tipo DescriptorType son equivalentes, si el nombre del elemento, el valor del @schemeIdUri y el valor del atributo @value son equivalentes. Si @schemeIdUri es un URN, entonces la equivalencia puede referirse a la equivalencia léxica como se define en la cláusula 5 de RFC 2141. Si el @schemeIdUri es una URL, entonces la equivalencia puede referirse a la igualdad carácter por carácter como se define en la cláusula 6.2.1 de RFC3986. Si el atributo @value no está presente, la equivalencia se puede determinar solo por la equivalencia de @schemeIdUri. Es posible que los atributos y elementos de los espacios de nombres de extensión no se utilicen para determinar la equivalencia. El atributo @id puede ignorarse para la determinación de equivalencia.
MPEG-DASH especifica los descriptores EssentialProperty y SupplementalProperty. Para el elemento EssentialProperty, el autor de la Presentación De medios expresa que el procesamiento exitoso del descriptor es esencial para usar correctamente la información en el elemento padre que contiene este descriptor, a menos que el elemento comparta el mismo @id con otro elemento EssentialProperty. Si los elementos EssentialProperty comparten el mismo @id, entonces es suficiente procesar uno de los elementos EssentialProperty con el mismo valor para @id.
Se espera que se procese al menos un elemento EssentialProperty de cada valor de @id distinto. Si no se reconoce el esquema o el valor de un descriptor de EssentialProperty, se espera que el cliente DASH ignore el elemento principal que contiene el descriptor. Varios elementos EssentialProperty con el mismo valor para @id y con diferentes valores para @id pueden estar presentes en un MPD.
Para el elemento SupplementalProperty, el autor de la Presentación De medios expresa que el descriptor contiene información complementaria que puede ser utilizada por el cliente DASH para un procesamiento optimizado. Si no se reconoce el esquema o el valor de un descriptor de propiedad suplementaria, se espera que el cliente DASH ignore el descriptor. Es posible que haya varios elementos SupplementalProperty en un MPD.
En DASH, una representación independiente se puede definir como una representación que se puede procesar independientemente de cualquier otra representación. Puede entenderse que una representación independiente comprende un flujo de bits independiente o una capa independiente de un flujo de bits. Una representación dependiente puede definirse como una representación para la cual los segmentos de sus representaciones complementarias son necesarios para la presentación y/o decodificación de los componentes de contenido de medios contenidos. Puede entenderse que una representación dependiente comprende, por ejemplo, una capa predicha de un flujo de bits escalable. Una representación complementaria puede definirse como una representación que complementa al menos una representación dependiente. Una representación complementaria puede ser una representación independiente o una representación dependiente. Las Representaciones Dependientes se pueden describir mediante un elemento de Representación que contiene un atributo @dependencyld. Las Representaciones Dependientes pueden considerarse Representaciones regulares, excepto que dependen de un conjunto de Representaciones complementarias para la decodificación y/o presentación. El @dependencyld contiene los valores del atributo @id de todas las Representaciones complementarias, es decir, las Representaciones que son necesarias para presentar y/o decodificar los componentes de contenido de medios contenidos en esta Representación dependiente.
Se puede proporcionar un servicio DASH como servicio bajo demanda o servicio en vivo. En el primero, el MPD es estático y todos los segmentos de una presentación de medios ya están disponibles cuando un proveedor de contenido publica un MPD. En este último, sin embargo, el MPD puede ser estático o dinámico dependiendo del método de construcción de URL de Segmento empleado por un MPD y los segmentos se crean continuamente a medida que un proveedor de contenido produce y publica el contenido para los clientes de DASH. El método de construcción de URL de Segmento puede ser un método de construcción de URL de Segmento basado en plantilla o el método de generación de lista de Segmento. En el primero, un cliente DASH puede construir URL de Segmento sin actualizar un MPD antes de solicitar un Segmento. En este último, un cliente DASH tiene que descargar periódicamente los MPD actualizados para obtener las URL de Segmento. Por lo tanto, para el servicio en vivo, el método de construcción de URL de Segmento basado en plantilla es superior al método de generación de lista de Segmento.
En el contexto de DASH, se pueden usar las siguientes definiciones: Un componente de contenido de medios o un componente de medios se puede definir como un componente continuo del contenido de medios con un tipo de componente de medios asignado que se puede codificar individualmente en una transmisión de medios. El contenido de medios puede definirse como un período de contenido de medios o una secuencia contigua de períodos de contenido de medios. El tipo de componente de contenido de medios puede definirse como un solo tipo de contenido de medios, como audio, video o texto. Una transmisión de medios puede definirse como una versión codificada de un componente de contenido de medios.
Un Segmento de inicialización puede definirse como un Segmento que contiene metadatos que son necesarios para presentar los flujos de medios encapsulados en Segmentos de Medios. En los formatos de segmento basados en ISOBMFF, un Segmento de Inicialización puede comprender el Movie Box ('moov') que puede no incluir metadatos para ninguna muestra, es decir, cualquier metadato para muestras se proporciona en 'moof boxes'.
Un Segmentos de Medios contiene cierta duración de datos de medios para su reproducción a una velocidad normal, dicha duración se denomina duración del Segmentos de Medios o duración del Segmento. El productor de contenido o proveedor de servicios puede seleccionar la duración del Segmento de acuerdo con las características deseadas del servicio. Por ejemplo, se puede usar una duración de Segmento relativamente corta en un servicio en vivo para lograr una latencia corta de un extremo a otro. La razón es que la duración del Segmento suele ser un límite inferior en la latencia de extremo a extremo percibida por un cliente DASH, ya que un Segmento es una unidad discreta de generación de datos de medios para DASH. La generación de contenido se realiza típicamente de tal manera que un Segmento completo de datos de medios está disponible para un servidor. Además, muchas implementaciones de clientes utilizan un Segmento como unidad para las solicitudes GET. Por lo tanto, en arreglos típicos para servicios en vivo, un cliente DASH puede solicitar un Segmento solo cuando la duración completa del Segmentos de Medios está disponible, así como codificado y encapsulado en un Segmento. Para el servicio a pedido, se pueden utilizar diferentes estrategias para seleccionar la duración del Segmento.
Un Segmento puede dividirse adicionalmente en Subsegmentos, por ejemplo, para permitir la descarga de segmentos en varias partes. Es posible que se requiera que los Subsegmentos contengan unidades de acceso completas. Los Subsegmentos se pueden indexar por caja de índice de Segmento, que contiene información para mapear el rango de tiempo de presentación y el rango de bytes para cada Subsegmento. La caja Índice de Segmento también puede describir Subsegmentos y puntos de acceso de transmisión en el segmento indicando sus duraciones y desplazamientos de bytes. Un cliente DASH puede usar la información obtenida de la (s) caja (s) de índice de Segmento para realizar una solicitud HTTP GET para un Subsegmento específico utilizando una solicitud HTTP de rango de bytes. Si se utiliza una duración de Segmento relativamente larga, se pueden utilizar Subsegmentos para mantener el tamaño de las respuestas HTTP razonable y flexible para la adaptación de la velocidad de bits. La información de indexación de un Segmento puede colocarse en la caja única al comienzo de ese Segmento o distribuirse entre muchos cuadros de indexación en el Segmento. Son posibles diferentes métodos de propagación, como jerárquico, en cadena e híbrido. Esta técnica puede evitar agregar una caja grande al comienzo del Segmento y, por lo tanto, puede evitar un posible retraso en la descarga inicial.
El (Sub) segmento de notación se refiere a un Segmento o un Subsegmento. Si las cajas de índice de Segmento no están presentes, el (Sub) segmento de notación se refiere a un Segmento. Si hay cajas de índice de Segmento, el (Sub) segmento de notación puede referirse a un Segmento o Subsegmento, por ejemplo, dependiendo de si el cliente emite solicitudes por Segmento o Subsegmento.
Los Segmentos (o Subsegmentos respectivamente) pueden definirse como no superpuestos de la siguiente manera: Sea Te(S, i) el tiempo de presentación más temprano de cualquier unidad de acceso en el flujo i de un Segmento o Subsegmento S, y sea Tl(S, i) el último tiempo de presentación de cualquier unidad de acceso en el flujo i de un Segmento o Subsegmento S. Dossegmentos (respectivamente Subsegmentos), A y B, que pueden o no ser de diferentes Representaciones, pueden definirse como no superpuestos, cuando Tl(A, i) < Te(B, i) para todos los flujos de medios i en A y B o si Tl(B, i) < Te(A, i) para todos los flujos i en A y B donde i se refiere al mismo componente de medios.
Puede ser necesario que para cualquier Representación X dependiente que dependa de la Representación Y complementaria, el Subsegmento m de X y el Subsegmento n de Y no se superpongan siempre que m no sea igual a n. Puede ser necesario que para las Representaciones dependientes la concatenación del Segmento de Inicialización con la secuencia de Subsegmentos de las Representaciones dependientes, cada una de las cuales esté precedida por el Subsegmento correspondiente de cada una de las Representaciones complementarias en el orden previsto en el atributo @dependencyld representará una secuencia de Subsegmentos de conformidad conforme al formato de medios como se especifica en el atributo @mimeType para esta Representación dependiente.
MPEG-DASH define formatos de contenedor de segmento tanto para el formato de archivo de medios base ISO como para los flujos de transporte MPEG-2. Otras especificaciones pueden especificar formatos de segmento basados en otros formatos de contenedor. Por ejemplo, se ha propuesto un formato de segmento basado en el formato de archivo contenedor de Matroska y se puede resumir de la siguiente manera. Cuando los archivos Matroska se transportan como segmentos DASH o similares, la asociación de unidades DASH y unidades Matroska se puede especificar de la siguiente manera. Un subsegmento (de DASH) puede definirse como uno o más grupos consecutivos de contenido encapsulado en Matroska. Es posible que se requiera un Segmento de inicialización de DASH para comprender el encabezado EBML, el encabezado del Segmento (de Matroska), la información del Segmento (de Matroska) y las pistas, y opcionalmente puede comprender otros elementos y relleno de nivel 1. Un índice de Segmento de DASH puede comprender un elemento Cues de Matroska.
DASH especifica diferentes líneas de tiempo, incluida la línea de tiempo de presentación de medios y los tiempos de disponibilidad de Segmento. El primero indica el tiempo de presentación de la unidad de acceso con un contenido de medios que se mapea a la línea de tiempo de presentación común global. La línea de tiempo de presentación de medios permite a DASH sincronizar sin problemas diferentes componentes de medios que están codificados con diferentes técnicas de codificación y comparten una línea de tiempo común. Este último indica un tiempo de reloj de pared y se utiliza para indicar a los clientes el tiempo de disponibilidad de los Segmentos que se identifica mediante las URL HTTP. Un cliente DASH puede identificar un tiempo de disponibilidad de un determinado Segmento comparando el tiempo del reloj de pared con el tiempo de disponibilidad del Segmento asignado a ese Segmento. El tiempo de disponibilidad del Segmento juega un papel clave en la entrega en vivo de los Segmentos de Medios, lo que se conoce como servicio en vivo. Para el servicio en vivo, el tiempo de disponibilidad del Segmento es diferente de un Segmento a otro Segmento y el tiempo de disponibilidad de un determinado Segmento depende de la posición del Segmento en la línea de tiempo de la presentación de medios. Para el servicio a pedido, el tiempo de disponibilidad del Segmento suele ser el mismo para todos los Segmentos.
DASH admite la adaptación de la tasa solicitando dinámicamente Segmentos de Medios de diferentes representaciones dentro de un Conjunto de Adaptación para que coincida con el ancho de banda de red variable. Cuando un cliente DASH cambia la Representación hacia arriba o hacia abajo, se deben tener en cuenta las dependencias de codificación dentro de la Representación. Un cambio de Representación solo puede ocurrir en un punto de acceso aleatorio (RAP), que generalmente se usa en técnicas de codificación de video como H.264/AVC. En DASH, se introduce un concepto más general llamado Punto de Acceso de Transmisión (SAP) para proporcionar una solución independiente del códec para acceder a una Representación y cambiar entre Representaciones. En DASH, un SAP se especifica como una posición en una Representación que permite que se inicie la reproducción de un flujo de medios utilizando solo la información contenida en los datos de Representación a partir de esa posición (precedida por la inicialización de datos en el Segmento de inicialización, si corresponde). Por lo tanto, el cambio de Representación se puede realizar en SAP.
Se han especificado varios tipos de SAP, incluidos los siguientes. SAP Tipo 1 corresponde a lo que se conoce en algunos esquemas de codificación como un “Punto de acceso aleatorio GOP cerrado” (en el que todas las imágenes, en orden de decodificación, se pueden decodificar correctamente, lo que da como resultado una secuencia de tiempo continua de imágenes decodificadas correctamente sin espacios) y además la primera imagen en el orden de decodificación es también la primera imagen en el orden de presentación. SAP Tipo 2 corresponde a lo que se conoce en algunos esquemas de codificación como un “Punto de acceso aleatorio GOP cerrado” (en el que todas las imágenes, en orden de decodificación, se pueden decodificar correctamente, lo que da como resultado una secuencia de tiempo continua de imágenes decodificadas correctamente sin espacios), por lo que la primera imagen en el orden de decodificación puede no ser la primera imagen en orden de presentación. SAP Tipo 3 corresponde a lo que se conoce en algunos esquemas de codificación como un “punto de acceso aleatorio Open GOP”, en el que puede haber algunas imágenes en orden de decodificación que no se pueden decodificar correctamente y tienen tiempos de presentación menores que la imagen intracodificada asociada con el SAP.
Los puntos de acceso de transmisión (que también o alternativamente pueden denominarse punto de acceso de capa) para la codificación en capas pueden definirse de manera similar de una manera por capas. Un SAP para capa puede definirse como una posición en una capa (o similar) que permite que la reproducción de la capa se inicie utilizando solo la información de esa posición en adelante, asumiendo que las capas de referencia de la capa ya se han decodificado antes.
Un grupo de muestras de punto de acceso al flujo (SAP) como se especifica en ISOBMFF identifica las muestras como si fueran del tipo de SAP indicado. El grouping_type_parameter para el grupo de muestra de SAP comprende los campos de las capas de destino y layer_id_method_idc. target_layers especifica las capas de destino para los SAP indicados. La semántica de target_layers puede depender del valor de layer_id_method_idc. layer_id_method_idc especifica la semántica de target_layers. layer_id_method_idc igual a 0 especifica que las capas de destino constan de todas las capas representadas por la pista. La entrada de descripción del grupo de muestra para el grupo de muestra de sAp comprende los campos dependent_flag y SAP_type. Es posible que se requiera que la dependent_flag sea 0 para los medios sin capas. dependent_flag igual a 1 especifica que las capas de referencia, si las hay, para predecir las capas objetivo pueden tener que decodificarse para acceder a una muestra de este grupo de muestras. dependent_flag igual a 0 especifica que las capas de referencia, si las hay, para predecir las capas de destino no necesitan decodificarse para acceder a ningún sA p de este grupo de muestras. Los valores de sap_type en el rango de 1 a 6, inclusive, especifican el tipo de SAP de las muestras asociadas.
La caja de índice de Subsegmento ('ssix') proporciona un mapeo de niveles (como se especifica en la caja de Asignación de Nivel) a rangos de bytes del Subsegmento indexado. En otras palabras, esta caja proporciona un índice compacto de cómo se ordenan los datos en un Subsegmento de acuerdo con niveles en Subsegmentos parciales. Permite a un cliente acceder fácilmente a los datos de Subsegmentos parciales descargando rangos de datos en el Subsegmento. Cuando la caja Índice de Subsegmento está presente, cada byte del Subsegmento se asigna a un nivel. Si el rango no está asociado con ninguna información en la asignación de nivel, entonces se puede usar cualquier nivel que no esté incluido en la asignación de nivel. Hay 0 o 1 cajas de índice de Subsegmento presentes por cada caja de índice de Segmento que indexa solo subsegmentos hoja, es decir, que solo indexa subsegmentos pero no índices de segmento. Una caja de índice de Subsegmento, si lo hay, es la siguiente caja después de la caja de índice de Segmento asociada. Una caja de índice de Subsegmento documenta el subsegmento que se indica en la caja de índice de Segmento inmediatamente anterior. Cada nivel puede asignarse exactamente a un subsegmento parcial, es decir, los rangos de bytes para un nivel son contiguos. Los niveles de subsegmentos parciales se asignan mediante números crecientes dentro de un Subsegmento, es decir, las muestras de un Subsegmento parcial pueden depender de cualquier muestra de Subsegmentos parciales anteriores en el mismo Subsegmento, pero no al revés. Por ejemplo, cada subsegmento parcial contiene muestras que tienen una subcapa temporal idéntica y los subsegmentos parciales aparecen en orden de subcapa temporal creciente dentro del subsegmento. Cuando se accede a un subsegmento parcial de esta manera, la caja de datos de medios final puede estar incompleto, es decir, se accede a menos datos de los que indica la longitud de la caja de datos de medios que está presente. Es posible que sea necesario ajustar la longitud de la caja de datos de medios o se puede utilizar un relleno. El padding_flag en la caja de asignación de nivel indica si estos datos faltantes se pueden reemplazar por ceros. De lo contrario, los datos de las muestras asignadas a los niveles a los que no se accede no están presentes y se debe tener cuidado de no intentar procesar dichas muestras.
Un proveedor de contenido puede crear Segmentos y Subsegmentos de múltiples representaciones de una manera que simplifica la conmutación. En un caso simple, cada Segmento y Subsegmento comienza con un SAP y los límites del Segmento y Subsegmento se alinean a través de la representación de un Conjunto de Adaptación. En tal caso, un cliente DASH puede cambiar de Representaciones sin derivación de errores solicitando Segmentos o Subsegmentos de una Representación original a una Representación nueva. En DASH, las restricciones para construir Segmento y Subsegmento se especifican en MPD e Índice de Segmento para facilitar que un cliente DASH cambie de Representación sin introducir una derivación de error. Uno de los usos del perfil especificado en DASH es proporcionar diferentes niveles de restricciones para construir Segmentos y Subsegmentos.
El borrador de la especificación MPEG-DASH incluye esa característica de Señalización SAP Independiente de Segmento (SISSI), que permite la señalización de Segmentos que comienzan con SAP que tiene duraciones desiguales. El borrador de la especificación MPEG-DASH define la señalización SISSI para conmutación dentro de un Conjunto de Adaptación y entre Conjuntos de Adaptación.
En la conmutación dentro de un Conjunto de Adaptación, la conmutación se refiere a la presentación de datos decodificados desde una Representación hasta un cierto tiempo t, y la presentación de datos decodificados de otra Representación desde el momento t en adelante. Si se incluyen representaciones en un Conjunto de Adaptación y el cliente cambia correctamente, se espera que la presentación de medios se perciba sin problemas en todo el conmutador. Los clientes pueden ignorar las Representaciones que se basan en códecs u otras tecnologías de renderizado que no son compatibles o que, por lo demás, no son adecuadas.
Al cambiar entre Conjuntos de Adaptación, las Representaciones en dos o más Conjuntos de Adaptación pueden proporcionar el mismo contenido. Además, el contenido puede estar alineado en el tiempo y puede ofrecerse de manera que sea posible la conmutación sin problemas entre las Representaciones en diferentes Conjuntos de Adaptación. Ejemplos típicos son la oferta del mismo contenido con diferentes códecs, por ejemplo, H.264/AVC y H.265/HEVC, y el autor del contenido desea proporcionar dicha información al receptor para cambiar sin problemas las representaciones entre diferentes Conjuntos de Adaptación. Este permiso de conmutación puede ser utilizado por clientes avanzados.
Un autor de contenido puede señalar tal propiedad de conmutación sin interrupciones en los Conjuntos de Adaptación proporcionando un Descriptor suplementario junto con un Conjunto de Adaptación con @schemeIdURI establecido en urn:mpeg:dash:adaptation-set-switching:2016 y @value es una coma lista separada por comas de ID de conjuntos de Adaptación a los que se puede cambiar sin problemas desde este conjunto de Adaptación.
Si el autor del contenido indica la capacidad de conmutación del Conjunto de Adaptación y cuando @segmentAlignment o @subsegmentAlignment se establecen en TRUE o el elemento Switching se proporciona para un Conjunto de Adaptación, la alineación de (sub) Segmento o el elemento Switching es válido para todas las representaciones en todos los Conjuntos de Adaptación para los que el valor @id se incluye en el atributo @value del descriptor suplementario.
Como ejemplo, un autor de contenido puede indicar que la conmutación perfecta entre un Conjunto de Adaptación H.264/AVC con AdaptationSet@id = “h264” y un Conjunto de Adaptación HEVC con AdaptationSet @id = “h265” es posible agregando un Descriptor suplementario al Conjunto de Adaptación H.264/AVC con @schemeIdURI establecido en urn:mpeg:dash:adapt-set-switching:2016 y @value = “h265” y agregando un descriptor suplementario al Conjunto de Adaptación HEVC con @schemeIdURI establecido en urn:mpeg:dash:adaptation-set-switching:2016 y el @value=“h264”.
Además, si el autor del contenido señala la capacidad de conmutación del Conjunto de Adaptación para cualquier Conjunto de Adaptación, entonces los parámetros definidos para un Conjunto de Adaptación también son válidos para todos los Conjuntos de Adaptación que están incluidos en el atributo @value. Tenga en cuenta que esta restricción puede dar como resultado que la conmutación solo se pueda señalizar con un Conjunto de Adaptación, pero no con ambos, ya que, por ejemplo, la señalización de un Conjunto de Adaptación puede incluir todas las resoluciones espaciales de otro, mientras que no es el caso al revés.
El estándar DASH incluye mecanismos para permitir un inicio rápido de una sesión de medios. Por ejemplo, el MPD puede anunciar más de una representación, con diferentes velocidades de bits, en un Conjunto de Adaptación. Además, cada segmento y/o subsegmento podría comenzar con un punto de acceso al flujo, donde las imágenes dentro del Segmento y/o subsegmento se codifican sin hacer referencia a ninguna otra imagen de un segmento diferente. De esta manera, un cliente DASH puede comenzar con una representación de tasa de bits más baja para aumentar rápidamente el nivel de ocupación del búfer. Entonces, el cliente puede cambiar a los segmentos solicitantes y/o subsegmentos de una representación de velocidad de bits más alta (que puede tener, por ejemplo, una resolución espacial más alta que la representación recibida anteriormente). El cliente puede apuntar a alcanzar un cierto nivel de ocupación del búfer, por ejemplo, en términos de duración de los medios, durante el inicio rápido y puede apuntar a mantener el mismo o similar nivel de ocupación del búfer durante la operación después de una fase de inicio rápido. El cliente puede iniciar la reproducción de medios después de iniciar una sesión de transmisión de medios y/o después de una operación de acceso aleatorio solo después de que se haya almacenado una cierta cantidad de medios. Esta cantidad de medio puede ser igual, pero no necesariamente relacionada con, el nivel de ocupación de la memoria intermedia que se pretende alcanzar en un inicio rápido. En todos los casos, el inicio rápido puede permitir que el cliente inicie la reproducción de medios más rápido de lo que sería posible si solo se recibiera consistentemente una representación de tasa de bits más alta después de iniciar una sesión de transmisión de medios y/o después de una operación de acceso aleatorio.
Como se describió anteriormente, el cliente o jugador puede solicitar la transmisión de Segmentos o Subsegmentos desde diferentes representaciones de manera similar a cómo se pueden determinar las capas y/o subcapas transmitidas de un flujo de bits de video escalable. Los términos representación de conmutación descendente o conmutación descendente de flujo de bits pueden referirse a solicitar o transmitir una representación de velocidad de bits más baja que la que se solicitó o transmitió (respectivamente) anteriormente. Los términos de representación de conmutación ascendente o conmutación ascendente de flujo de bits pueden referirse a solicitar o transmitir una representación de velocidad de bits más alta que la que se solicitó o transmitió (respectivamente) anteriormente. Los términos conmutación de representación o conmutación de flujo de bits pueden referirse colectivamente a representación o conmutación ascendente y descendente de flujo de bits y pueden cubrir también o alternativamente la conmutación de representaciones o flujos de bits de diferentes puntos de vista.
Los sistemas de transmisión similares a MPEG-DASH incluyen, por ejemplo, HTTP Live Streaming (también conocido como HLS), especificado en el IETF Internet Draft draft-pantos-http-live-streaming-13 (y otras versiones del mismo Internet Draft). Como formato de manifiesto correspondiente al MPD, HLS usa un formato M3U extendido. M3U es un formato de archivo para listas de reproducción multimedia, desarrollado originalmente para archivos de audio. Una lista de reproducción M3U es un archivo de texto que consta de líneas individuales, y cada línea es un URI, en blanco o comienza con el carácter '#' que indica una etiqueta o un comentario. Una línea URI identifica un segmento de medios o un archivo de lista de reproducción. Las etiquetas comienzan con #EXT. La especificación HLS especifica una serie de etiquetas, que pueden considerarse pares clave-valor. La parte de valor de las etiquetas puede comprender una lista de atributos, que es una lista separada por comas de pares atributo-valor, donde se puede considerar que un par atributo-valor tiene la sintaxis AttributeName = AttributeValue. Por lo tanto, las etiquetas de los archivos HLS M3U8 pueden considerarse similares a los elementos en MPD o XML, y los atributos de los archivos HLS M3U8 pueden considerarse similares a los atributos en MPD o XML. Los Segmentos de Medios en HLS están formateados de acuerdo con MPEG-2 Transport Stream y contienen un único programa MPEG-2. Se recomienda que cada segmento de medios comience con una Tabla de asociación de programas (PAT) y una Tabla de mapa de programas (PMT).
Como se explicó anteriormente, DASH y otros sistemas de transmisión similares proporcionan un protocolo y/o formatos atractivos para aplicaciones de transmisión multimedia, especialmente para flujos de bits de video codificados de múltiples vistas de múltiples vistas. Una tendencia reciente en la transmisión para reducir la tasa de bits de transmisión de video de realidad virtual es la siguiente: un subconjunto de contenido de video de 360 grados que cubre la ventana gráfica principal (es decir, la orientación de la vista actual) se transmite con la mejor calidad/resolución, mientras que el resto de video de 360 grados se transmite con una calidad/resolución más baja. En general, existen dos enfoques para la transmisión adaptativa de la ventana gráfica:
1. Codificación y transmisión específica de la ventana gráfica, también conocida como codificación y transmisión dependiente de la ventana gráfica, también conocida como proyección asimétrica, también conocida como video VR empaquetado.
En este enfoque, el contenido de la imagen de 360 grados se empaqueta en el mismo cuadro con un énfasis (por ejemplo, mayor área espacial) en la ventana gráfica principal. Los cuadros VR empaquetados se codifican en un solo flujo de bits.
Por ejemplo, la cara frontal de un mapa de cubo se puede muestrear con una resolución más alta en comparación con otras caras de cubo y las caras de cubo se pueden asignar al mismo cuadro VR empaquetado como se muestra en la Figura 8, donde la cara frontal del cubo es muestreada con el doble de resolución en comparación con las otras caras del cubo.
2. Video de la ventana gráfica de realidad virtual, también conocido como codificación y transmisión basadas en mosaicos
En este enfoque, el contenido de 360 grados se codifica y se pone a disposición de una manera que permite la transmisión selectiva de vistas desde diferentes codificaciones.
Por ejemplo, cada cara del cubo puede codificarse y encapsularse por separado en su propia pista (y Representación). Puede proporcionarse más de un flujo de bits codificado para cada cara del cubo, por ejemplo, cada uno con diferente resolución espacial. Los reproductores pueden elegir pistas (o representaciones) para decodificar y reproducir en función de la orientación de visualización actual. Se pueden seleccionar pistas (o Representaciones) de alta resolución para las caras del cubo utilizadas para representar para la orientación de visualización actual, mientras que las caras restantes del cubo se pueden obtener de sus pistas (o Representaciones) de baja resolución.
En otro ejemplo, el contenido de panorama equirrectangular se codifica utilizando conjuntos de mosaicos con limitación de movimiento. Puede proporcionarse más de un flujo de bits codificado, por ejemplo, con diferente resolución espacial y/o calidad de imagen. Cada conjunto de mosaicos con restricción de movimiento está disponible en su propia pista (y Representación). Los reproductores pueden elegir pistas (o representaciones) para decodificar y reproducir en función de la orientación de visualización actual. Se pueden seleccionar pistas (o representaciones) de alta resolución o alta calidad para los conjuntos de mosaicos que cubren la ventana gráfica principal actual, mientras que el área restante del contenido de 360 grados se puede obtener de pistas (o representaciones) de baja resolución o baja calidad.
También es posible combinar los enfoques 1. y 2. anteriores. Entonces podríamos imaginar el espacio de 360 grados dividido en un conjunto discreto de ventanas gráficas, cada una separada por una distancia determinada (por ejemplo, Expresada en grados), de modo que el espacio omnidireccional se pueda imaginar como un mapa de ventanas gráficas superpuestas, y la ventana gráfica principal es cambia discretamente a medida que el usuario cambia su orientación mientras mira contenido con un HMD. Cuando la superposición entre las ventanas gráficas se reduce a cero, las ventanas gráficas pueden imaginarse como mosaicos adyacentes no superpuestos dentro del espacio de 360 grados. El códec de vídeo H.265 implementa el concepto de mosaicos que pueden utilizarse para realizar este escenario (tanto superpuestos como no).
La mayoría de las implementaciones relacionadas con la codificación basada en mosaicos requieren el uso de conjuntos de mosaicos con restricción de movimiento (MCTS), que tiene el inconveniente de que la herramienta de codificación de mosaicos solo está disponible en HEVC, mientras que puede ser ventajoso admitir otros formatos de codificaciones, como H.264/AVC. Además, los conjuntos de mosaicos con restricción de movimiento son una característica opcional del codificador y, por lo tanto, es posible que muchos codificadores no lo admitan.
Algunos entornos de cliente están limitados a ejecutar una única instancia de decodificador o un número limitado de instancias de decodificador en paralelo. Una única instancia de decodificador también evita las necesidades de sincronización posdecodificador entre instancias de decodificador de diferencia y, en consecuencia, puede reducir el retardo, ya que el almacenamiento en búfer posdecodificador no necesita tener en cuenta dicha sincronización. Suponiendo que el cliente solo puede ejecutar hasta M instancias de decodificador en paralelo, la entrega dependiente de la ventana gráfica se puede lograr mediante la codificación y transmisión dependientes de la ventana gráfica o mediante la codificación y transmisión basadas en mosaicos, donde los mosaicos se combinan para formar menos de o igual a M flujos de bits. Para la codificación y transmisión basadas en mosaicos, sería deseable habilitar la codificación y la transmisión basadas en rectángulos de mosaicos de una manera en la que se pueda ajustar el número de instancias de decodificador, según las capacidades del cliente, incluso hasta una instancia de decodificador.
Ahora, con el fin de aliviar al menos las desventajas anteriores, a continuación, se presenta un método para la codificación y transmisión basadas en rectángulos de mosaicos.
En el método, que se representa en la Figura 9, una secuencia de imágenes fuente que comprende una pluralidad de rectángulos de mosaicos se divide (900) en un número correspondiente de secuencias de rectángulos de mosaicos; cada secuencia de rectángulo de mosaico se codifica (902) independientemente en un número correspondiente de secuencias de rectángulo de mosaico codificadas; y dos o más secuencias de rectángulos de mosaicos codificados se fusionan verticalmente (904) en una imagen codificada del flujo de bits de manera que cada rectángulo de mosaicos codificados en una imagen codificada forma un sector codificado.
La figura 10 muestra un ejemplo del concepto subyacente a las realizaciones. La secuencia de imágenes fuente 1000, que consta de los rectángulos de mosaicos 1 - 8 en este ejemplo, se divide en secuencias de rectángulos de mosaicos 1002 (1) - 1002 (8). A continuación, cada secuencia de rectángulo de mosaico se codifica de forma independiente en secuencias de rectángulo de mosaico codificadas 1004 (1) - 1004 (8). Dos o más secuencias de rectángulos de mosaicos codificadas se fusionan en un flujo de bits 1006. Las secuencias de rectángulos de mosaicos codificadas pueden tener diferentes características, tales como calidad de imagen, para ser utilizadas para la entrega dependiente de la ventana gráfica. En el ejemplo de la Figura 10, los rectángulos de mosaico 1, 2, 5 y 6 representan la ventana gráfica principal. Así, los rectángulos de mosaico codificados 1004 (1), 1004 (2), 1004 (5) y 1004 (6) de cada instancia de tiempo tü, t-i, ..., tN se fusionan verticalmente en una imagen codificada del flujo de bits 1006 tal que cada rectángulo de mosaico codificado en una imagen codificada forma un sector codificado.
La disposición vertical de los rectángulos de mosaicos codificados en una imagen codificada trae al menos el beneficio de que los cortes se pueden usar como una unidad para llevar un rectángulo de mosaicos codificados y no se necesita soporte de mosaicos en el códec, por lo tanto, la invención es adecuada, por ejemplo, para H.264/AVC. Además, no se necesita transcodificación para la disposición vertical, a diferencia de la disposición horizontal donde la transcodificación sería necesaria ya que los rectángulos de mosaico codificados se intercalarían en el orden de exploración del cuadro (es decir, el orden de decodificación) de los bloques (por ejemplo, macrobloques en H.264/AVC o unidades de árbol de codificación en HEVC).
De acuerdo con una realización, la codificación de secuencias de rectángulos de mosaico se realiza de manera que se evitan los vectores de movimiento que requieren acceder a ubicaciones de muestra fuera de los límites de la imagen (en inter predicción). Los vectores de movimiento se pueden restringir de modo que no se utilice ningún valor de muestra fuera de los límites de la imagen y ningún valor de muestra en una posición de muestra fraccionaria que se derive usando uno o más valores de muestra fuera de los límites de la imagen.
De acuerdo con una realización, un codificador indica en o a lo largo del flujo de bits, por ejemplo, en un mensaje SEI, esa codificación se ha realizado de una manera que se evitan los vectores de movimiento que requieren acceder a ubicaciones de muestra fuera de los límites de la imagen (en inter predicción).
De acuerdo con una realización, los vectores de movimiento que requieren acceder a ubicaciones de muestra verticalmente fuera de los límites de la imagen (en inter predicción) se evitan y los vectores de movimiento que requieren acceder a ubicaciones de muestra horizontalmente fuera de los límites de la imagen (en inter predicción) se utilizan o pueden usarse en la codificación de secuencias de rectángulos de mosaicos.
De acuerdo con una realización, un codificador indica en o a lo largo del flujo de bits, por ejemplo, en un mensaje SEI, esa codificación se ha realizado de una manera que se evitan los vectores de movimiento que requieren acceder a ubicaciones de muestra verticalmente fuera de los límites de la imagen (en inter predicción). Un codificador puede indicar adicional o alternativamente en o a lo largo del flujo de bits que se han utilizado o pueden haber sido utilizados vectores de movimiento que requieren acceder a ubicaciones de muestra horizontalmente fuera de los límites de la imagen (en inter predicción).
De acuerdo con una realización, un decodificador decodifica desde o a lo largo del flujo de bits, por ejemplo, a partir de un mensaje SEI, si los vectores de movimiento se han codificado de manera que se evite el acceso a ubicaciones de muestra horizontal y/o verticalmente fuera de los límites de la imagen (en inter predicción). De acuerdo con una realización, si el decodificador decodifica el acceso a ubicaciones de muestra verticalmente fuera de los límites de la imagen (en inter predicción) se evita, el decodificador fusiona dos o más rectángulos de mosaicos codificados verticalmente en una imagen codificada de modo que cada rectángulo de mosaicos codificados forme un sector codificado en la imagen codificada.
De acuerdo con una realización, tales secuencias de rectángulos de mosaicos codificadas se fusionan cuando los vectores de movimiento que acceden a ubicaciones de muestra fuera de los límites de la imagen no se han evitado o podrían no haberse evitado. El proceso de fusión puede comprender generar una línea de bloque adicional usando la predicción intra vertical de la fila de muestra más inferior de un rectángulo de mosaico reconstruido. Opcionalmente, no se codifica ningún error de predicción para la línea de bloque adicional. Por lo tanto, se puede considerar que la línea de bloque adicional reconstruida rellena el límite del rectángulo de mosaico, como el procesamiento del manejo de vectores de movimiento que hacen referencia a ubicaciones de muestra fuera del límite de la imagen.
La figura 11a muestra un ejemplo de cómo manejar el caso en el que la codificación de secuencias de rectángulos de mosaicos permite vectores de movimiento que provocan referencias a datos por debajo del límite inferior de la imagen. En la Figura 11a, se genera una línea de bloque adicional a partir de la fila de muestra más inferior del rectángulo de mosaico reconstruido 1 utilizando la predicción intra vertical.
De acuerdo con otra realización, el proceso de fusión puede comprender generar una línea de bloque adicional usando codificación sin pérdidas que rellena la fila de muestra superior del rectángulo de mosaico verticalmente a la línea de bloque adicional. Puede que sea necesario utilizar un modo de codificación sin pérdidas del códec. La línea de bloque adicional puede codificarse como un sector que está separado del sector que contiene el rectángulo de mosaico.
La figura 11b muestra un ejemplo de cómo manejar el caso en el que la codificación de secuencias de rectángulos de mosaicos permite vectores de movimiento que provocan referencias a datos por encima del límite de la imagen superior. En la Figura 11b, se genera una (segunda) línea de bloque adicional repitiendo la fila de muestra superior del rectángulo de mosaico 2 usando codificación sin pérdidas.
Por lo tanto, se mantiene el beneficio de eficiencia de compresión que proviene de permitir vectores de movimiento sobre los límites horizontales de la imagen (a diferencia de, por ejemplo, cuando se usan conjuntos de mosaicos con movimiento restringido). En ambos casos anteriores, se puede realizar la decodificación de entropía del rectángulo de mosaico. Luego, el sector que contiene el rectángulo de mosaico adjunto con líneas de bloque adicionales puede codificarse de nuevo con entropía.
De acuerdo con una realización, las secuencias de rectángulos de mosaicos de diferentes anchos se fusionan de manera que los rectángulos de mosaicos que son más estrechos que el rectángulo de mosaicos más ancho que se fusiona se añaden a la derecha con bloques que usan predicción intra horizontal. No se codifica ningún error de predicción para los bloques adjuntos. Por lo tanto, los bloques adicionales reconstruidos rellenan el límite del rectángulo de mosaico, como el procesamiento del manejo de vectores de movimiento que hacen referencia a ubicaciones de muestra fuera del límite de la imagen. Se realiza la decodificación de entropía del rectángulo de mosaico. Luego, el sector que contiene el rectángulo de mosaico y los bloques adjuntos se codifican de nuevo en entropía.
La Figura 12 muestra un ejemplo de cómo fusionar secuencias de rectángulos de mosaicos de diferentes tamaños. Por lo demás, la Figura 12 es similar a la Figura 10, pero aquí los rectángulos de mosaico 5 y 6 de la ventana gráfica principal se consideran menos importantes y están codificados con menor calidad. Por lo tanto, al fusionar los rectángulos de mosaico codificados 1, 2, 5 y 6 en cada instancia de tiempo tü, t-i, ..., tN verticalmente en una imagen codificada, se añaden bloques adicionales que utilizan la predicción intra horizontal en el lado derecho de los rectángulos 5 y 6 de mosaicos codificados (mostrados con líneas horizontales densas).
Se pueden formar varias secuencias de rectángulos de mosaicos codificadas a partir de la misma secuencia de rectángulos de mosaicos (fuente). Por ejemplo, las secuencias de rectángulos de mosaicos codificadas pueden diferir entre sí, por ejemplo, en una o más de las siguientes propiedades:
- Tasa de bits
- Calidad de imagen o parámetro de cuantificación, por ejemplo, QP de H.264/AVC o HEVC
- Densidad de muestreo o resolución espacial
- Profundidad de bits para uno o más componentes de color
- Gama dinámica
- Gama de colores
- Códec (por ejemplo, una primera secuencia de rectángulo de mosaico puede codificarse con H.264/AVC y una segunda secuencia de rectángulo de mosaico con HEVC)
- Perfil de códec (por ejemplo, una primera secuencia de rectángulo de mosaico puede codificarse con el perfil de línea base restringida H.264/AVC y una segunda secuencia de rectángulo de mosaico con perfil alto de H.264/AVC) Cada flujo de bits de rectángulo de mosaico puede encapsularse en un archivo como su propia pista. Cada pista rectangular de mosaico puede estar disponible para transmisión, por ejemplo, como Representación en DASH MPD. En el lado del receptor, las pistas que se transmitirán se pueden seleccionar en función de los metadatos de orientación/ventana gráfica. El cliente puede recibir pistas que cubran todo el contenido omnidireccional. Se pueden recibir pistas de mejor calidad o mayor resolución para la ventana gráfica actual en comparación con la calidad o resolución que cubre las ventanas gráficas restantes, actualmente no visibles.
De acuerdo con una realización, un cliente puede determinar un número deseado de instancias de decodificador L y fusionar pistas rectangulares de mosaicos recibidos o flujos de bits en L flujos de bits. La fusión puede estar limitada, por ejemplo, sobre la base de los anchos de los rectángulos de mosaicos, es decir, puede ser deseable fusionar solo flujos de bits de rectángulos de mosaicos que tengan el mismo ancho. Adicional o alternativamente, la fusión puede verse limitada por los requisitos del flujo de bits fusionado. Por ejemplo, la relación de aspecto de la imagen de un flujo de bits fusionado puede estar restringida, por ejemplo, en un estándar.
De acuerdo con otra realización, el proceso de fusión puede comprender reescribir ciertas estructuras del flujo de bits, tales como conjuntos de parámetros y/o encabezados de segmento de sector, total o parcialmente cuando se comparan con los de la pista o flujo de bits del rectángulo de mosaico.
De acuerdo con una realización, un encapsulador de archivos o similar genera una pista de recogida de mosaicos rectangulares que puede utilizarse para llevar a cabo la reescritura. De acuerdo con una realización, un desencapsulador de archivos o similar analiza una pista de colección de mosaicos rectangulares para llevar a cabo la reescritura.
En esta descripción, al explicar las diversas realizaciones, se pueden usar los siguientes términos y sus definiciones. Un constructor de muestra es un constructor que, cuando se ejecuta, copia los datos de muestra de un rango de bytes indicado de una muestra indicada de una pista indicada. La inclusión por referencia puede definirse como un extractor o similar que, cuando se ejecuta, copia los datos de muestra de un rango de bytes indicado de una muestra indicada de una pista indicada.
Una colección de rectángulos de mosaicos que cumple con la imagen completa {track | bitstream} es una {pista | bitstream} que se ajusta a la imagen completa {pista | bitstream} y extrae datos de video codificados de dos o más mosaicos rectangulares {pistas | flujos de bits}. Aquí, la notación {optionA | optionB} ilustra alternativas, es decir, optionA u optionB, que se selecciona de forma coherente en todas las selecciones. Una pista de conjunto de mosaicos compatible con imagen completa se puede reproducir como con cualquier pista de imagen completa utilizando el proceso de análisis y decodificación de pistas de imagen completa. Un flujo de bits compatible con imagen completa se puede decodificar como con cualquier flujo de bits de imagen completa utilizando el proceso de decodificación de flujos de bits de imagen completa.
Un constructor en línea es un constructor que, cuando se ejecuta, devuelve los datos de muestra que contiene. Por ejemplo, un constructor en línea puede comprender un conjunto de instrucciones para reescribir un nuevo encabezado de segmento. La frase en línea se puede utilizar para indicar datos codificados que se incluyen en la muestra de una pista.
Una estructura similar a una unidad NAL se refiere a una estructura con las propiedades de una unidad NAL, excepto que no se realiza la prevención de la emulación del código de inicio.
Un flujo de bits de rectángulo de mosaico es un flujo de bits que contiene un rectángulo de mosaico de un contenido fuente original pero que no representa todo el contenido fuente original.
Una pista de rectángulo de mosaicos es una pista que representa una secuencia de rectángulos de mosaicos codificada.
En una realización, los conjuntos de parámetros se incluyen en la descripción de entrada de muestra de la (s) pista (s) de recogida de mosaicos rectangulares. En una realización, los conjuntos de parámetros se incluyen en muestras de la (s) pista (s) de recopilación de mosaicos rectangulares (de forma alternativa o adicional a la inclusión de conjuntos de parámetros en la descripción de entrada de muestra de la (s) pista (s) de recopilación de mosaicos rectangulares). En una realización, los conjuntos de parámetros se incluyen en línea en las muestras. En una realización, los conjuntos de parámetros son, de forma alternativa o adicional a la inclusión de conjuntos de parámetros en línea en muestras, construidos en muestras. Por ejemplo, una parte de un conjunto de parámetros puede extraerse de una muestra de otra pista, y otra parte de un conjunto de parámetros puede incluirse utilizando un constructor en línea.
En una realización, los encabezados de unidad NAL de una pista de colección de mosaicos rectangulares se incluyen usando un constructor en línea.
En una realización, los encabezados de sector o los encabezados de segmento de sector se incluyen en muestras de una pista de colección de rectángulos de mosaicos usando un constructor en línea. En una realización, adicional o alternativamente para incluir encabezados de sector o encabezados de segmento de sector con constructor en línea, los encabezados de sector o encabezados de segmento de sector se pueden extraer de otra pista. Por ejemplo, parte de los encabezados de sector o encabezado de segmento de sector puede extraerse de una muestra de otra pista, y otra parte de los encabezados de sector o encabezado de segmento de sector puede incluirse usando un constructor en línea.
En un ejemplo, un extractor en una pista de colección de mosaicos rectangulares puede comprender, por ejemplo, un constructor en línea que incluye un encabezado de sector y un constructor de muestra que extrae datos de video codificados para un sector de una pista de mosaico rectangular referenciada.
De acuerdo con una realización, que puede aplicarse junto con o independientemente de otra realización, un mapeo de regiones dentro de un flujo de bits, como el flujo de bits combinado 1006, a una disposición espacial se codifica en o a lo largo del flujo de bits, y/o se decodifica desde o a lo largo del flujo de bits. La disposición espacial puede estar predefinida, por ejemplo, en un estándar, o puede codificarse en o a lo largo del flujo de bits y/o decodificarse desde o a lo largo del flujo de bits. La disposición espacial puede comprender, por ejemplo, una proyección para imágenes/vídeo de 360 grados y/o empaquetamiento de cuadros estereoscópicos.
De acuerdo con una realización, una proyección para imágenes/vídeo de 360 grados, empaquetamiento de cuadros estereoscópicos y/o empaquetamiento regional se indican dentro de la misma estructura de contenedor. El orden de las etapas de procesamiento desde el contenido fuente hasta las imágenes de entrada para la codificación puede estar predefinido, por ejemplo, en un estándar, o puede codificarse en o a lo largo del flujo de bits y/o decodificarse desde o a lo largo del flujo de bits. Por ejemplo, puede estar predefinido que una conversión, como la unión, se realice primero de las imágenes fuente a una imagen omnidireccional de un formato de proyección omnidireccional, seguida de un empaquetamiento estereoscópico de cuadros de imágenes omnidireccionales del ojo izquierdo y derecho en el mismo fotograma (si corresponde), seguido del empaquetado regional del fotograma lleno de fotogramas estereoscópicos. las etapas de procesamiento pueden ser opcionales. Por ejemplo, no se aplica ningún empaquetamiento de cuadro estereoscópico para el contenido monoscópico y no es necesario aplicar el empaquetamiento regional. La estructura del contenedor puede proporcionar un mecanismo de extensión para que se puedan definir otros tipos de etapas de procesamiento. Puede ser necesario que los reproductores que no reconozcan o no puedan realizar una etapa de procesamiento incluido en la estructura del contenedor no muestren el contenido.
De acuerdo con una realización, un mensaje SEI anidado para indicar disposiciones espaciales se codifica en un flujo de bits y/o se decodifica a partir de un flujo de bits. Las disposiciones espaciales dentro del mensaje SEI anidado pueden indicarse como mensajes SEI contenidos dentro del mensaje SEI anidado, por ejemplo, uno o más de un mensaje SEI para indicar el formato de proyección omnidireccional (por ejemplo, llamado mensaje SEI de proyección omnidireccional), un mensaje SEI para indicar la disposición de empaquetado del cuadro estereoscópico (por ejemplo, el mensaje SEI del arreglo de empaquetado del cuadro como se especifica en HEVC o H.264/AVC, o el mensaje SEI de empaquetado del cuadro rectangular segmentado como se especifica en HEVC), y un mensaje SEI para indicar el arreglo de empaquetado regional (por ejemplo, llamado mensaje SEI de empaquetado regional). Es posible que se requiera o se recomiende usar este mensaje SEI anidado cuando se haya aplicado más de una proyección omnidireccional, disposición de empaquetado de cuadros y empaquetado regional al contenido de origen antes de la codificación. El mensaje SEI de anidamiento puede contener adicional o alternativamente otros tipos de mensajes SEI de disposición espacial que pueden requerir que el jugador procese las imágenes decodificadas antes de visualizarlas.
De acuerdo con una realización, un flujo de bits de vídeo se encapsula y/o se desencapsula a partir de una pista que tiene una entrada de muestra de vídeo restringida (“resv”) del formato de archivo de medios base ISO. El SchemeInformationBox en la entrada de muestra actúa como la estructura del contenedor para indicar arreglos espaciales. Por ejemplo, SchemeInformationBox puede comprender uno o más de una caja para indicar el formato de proyección omnidireccional (por ejemplo, llamado ProjectionFormatBox), una caja para indicar la disposición de empaquetado del cuadro estereoscópico (por ejemplo, StereoVideoBox) y una caja para indicar la disposición de empaquetado regional (por ejemplo, RegionWisePackingBox).
De acuerdo con una realización, un flujo de bits de imagen o vídeo que comprende una unidad de acceso se encapsula en y/o se desencapsula a partir de un elemento de imagen de HEIF. ItemPropertyContainerBox actúa como la estructura contenedora para indicar arreglos espaciales, y los arreglos espaciales que caracterizan el elemento de imagen se indican con el cuadro ItemPropertyAssociation. Por ejemplo, ItemPropertyContainerBox puede comprender una o más de una propiedad de artículo para indicar el formato de proyección omnidireccional, una propiedad de artículo para indicar la disposición de empaquetado del cuadro estereoscópico y una propiedad de artículo para indicar la disposición de empaquetado regional.
De acuerdo con una realización, la estructura de contenedor para indicar disposiciones espaciales se genera y/o analiza a partir de un manifiesto de transmisión, tal como DASh MPD. La estructura contenedora puede ser, por ejemplo, un elemento AdaptationSet, Representation o SubRepresentation, o puede ser un elemento específico dentro de un elemento AdaptationSet, Representation o SubRepresentation. Por ejemplo, el elemento contenedor puede comprender uno o más de un descriptor de propiedad esencial para indicar el formato de proyección omnidireccional, un descriptor de propiedad esencial para indicar la disposición de empaquetado del cuadro estereoscópico y un descriptor de propiedad esencial para indicar la disposición de empaquetado regional.
De acuerdo con una realización, la información de empaquetado regional incluida en cualquier indicación anterior describe un proceso regional aplicado a un cuadro de origen (por ejemplo, un cuadro proyectado) para obtener un cuadro de destino (por ejemplo, un cuadro empaquetado) que ha sido codificado. De acuerdo con otra realización, la información de empaquetamiento regional incluida en cualquier indicación anterior describe un proceso regional que se aplicará a un cuadro decodificado (por ejemplo, un cuadro empaquetado) para obtener un cuadro reorganizado (por ejemplo, un cuadro proyectado o un cuadro proyectado estereoscópico que está empaquetado en cuadros). El último proceso regional también puede denominarse mapeo inverso regional.
El mapeo inverso regional puede especificarse o implementarse como un proceso que mapea regiones de un cuadro VR empaquetado a un cuadro proyectado. Se pueden incluir metadatos en o a lo largo del flujo de bits que describe el mapeo regional desde un cuadro proyectado a un cuadro VR empaquetado. Por ejemplo, puede incluirse en dichos metadatos un mapeo de un rectángulo de origen de un cuadro proyectado a un rectángulo de destino en un cuadro de VR empaquetado. La anchura y la altura del rectángulo de origen en relación con la anchura y la altura del rectángulo de destino, respectivamente, pueden indicar una relación de remuestreo horizontal y vertical, respectivamente. Un proceso de mapeo posterior mapea muestras del rectángulo de destino (como se indica en los metadatos) del cuadro VR empaquetado al rectángulo de origen (como se indica en los metadatos) de un cuadro proyectado de salida. El proceso de mapeo posterior puede incluir un nuevo muestreo de acuerdo con las proporciones de ancho y alto de los rectángulos de origen y destino.
De acuerdo con una realización, una disposición espacial se decodifica desde o a lo largo del flujo de bits. La disposición espacial puede comprender, por ejemplo, una o más de una proyección omnidireccional, una disposición de empaquetamiento de cuadros estereoscópicos y una disposición de empaquetamiento regional. La disposición espacial decodificada se procesa de manera inversa para obtener imágenes decodificadas de un formato particular. Por ejemplo, se puede aplicar un mapeo posterior por regiones para obtener un cuadro proyectado monoscópico o estereoscópico, y los cuadros constituyentes pueden extraerse de un cuadro proyectado estereoscópico para obtener un cuadro proyectado individual para la vista izquierda o derecha. La imagen o imágenes decodificadas obtenidas de un formato particular pueden procesarse adicionalmente, por ejemplo, extrayendo una ventana gráfica que se muestra.
De acuerdo con una realización, una primera pista de recogida de rectángulos de mosaicos se indica como una primera representación en un DASH MPD, y una segunda pista de recogida de rectángulos de mosaicos se indica como una segunda representación en un DASH MPD. También pueden indicarse otros metadatos, como la disposición espacial y/o el descriptor de relación espacial, para las Representaciones de colección de mosaicos rectangulares. Las representaciones de colección rectangulares pueden ser Representaciones dependientes, y las dependencias de las Representaciones de mosaicos rectangulares en particular pueden indicarse mediante el atributo @dependencyId de mosaicos
De acuerdo con una realización, la disponibilidad de una primera Representación de colección de rectángulo de mosaico y de una segunda Representación de colección de rectángulo de mosaico se analiza sintácticamente a partir de DASH MPD. Otros metadatos, como la disposición espacial y/o el descriptor de relación espacial, también se pueden analizar para obtener representaciones de colección de mosaicos rectangulares de DASH MPD. Según los metadatos y la orientación de visualización (y otras condiciones de visualización) y las condiciones de la red (por ejemplo, tasa de bits recibida estimada), un cliente DASH puede determinar qué Representaciones de colección de mosaicos rectangulares se adaptan mejor a su propósito. Un cliente DASH puede analizar de qué Representaciones de rectángulos de mosaicos depende la representación de la colección de rectángulos de mosaicos seleccionada, por ejemplo, basado en el atributo @dependencyId. De acuerdo con lo anterior, el cliente DASH puede solicitar (Sub) segmento (s) de la Representación de colección de mosaicos rectangulares y las Representaciones de mosaicos rectangulares de las que depende la Representación de colección de mosaicos rectangulares.
En una realización, un video panorámico de 360 grados se divide en 12 rectángulos de mosaicos, cada uno de los cuales cubre un campo de visión horizontal de 90 grados (es decir, cuatro columnas de mosaicos de igual ancho), la fila de mosaicos superior cubre 45 grados de campo vertical de vista, la fila de mosaicos central cubre 90 grados de campo de visión vertical y la fila de mosaicos inferior cubre 45 grados de campo de visión vertical. Suponiendo que el campo de visión en una pantalla montada en el cabezal es de aproximadamente 100 grados, la transmisión y/o decodificación de cuatro secuencias de rectángulos de mosaicos codificadas suele ser suficiente para cubrir el campo de visión necesario para la visualización, particularmente cuando se trata de una versión o base de baja resolución. La capa se puede utilizar para cubrir cualquier área que posiblemente falte en los lados de las imágenes mostradas.
En una realización, un vídeo panorámico de 360 grados se divide en 8 rectángulos de mosaicos, cada uno de los cuales cubre 90 grados horizontal y verticalmente. Suponiendo que el campo de visión en una pantalla montada en el cabezal es de aproximadamente 100 grados, la transmisión y/o decodificación de cuatro secuencias de rectángulos de mosaicos codificadas suele ser suficiente para cubrir el campo de visión necesario para la visualización, particularmente cuando se trata de una versión o base de baja resolución. La capa se puede utilizar para cubrir cualquier área que posiblemente falte en los lados de las imágenes mostradas.
La figura 13 muestra un diagrama de bloques de un decodificador de video adecuado para emplear realizaciones de la invención. La figura 14 representa una estructura de un decodificador de dos capas, pero se apreciará que las operaciones de decodificación se pueden emplear de manera similar en un decodificador de una sola capa.
El decodificador 550 de video comprende una primera sección 552 de decodificador para componentes de vista base y una segunda sección 554 de decodificador para componentes de vista sin base. El bloque 556 ilustra un demultiplexor para entregar información relativa a componentes de vista base a la primera sección de decodificador 552 y para entregar información relativa a componentes de vista sin base a la segunda sección de decodificador 554. La referencia P'n significa una representación predicha de un bloque de imagen. La referencia D'n significa una señal de error de predicción reconstruida. Los bloques 704, 804 ilustran imágenes reconstruidas preliminares (I'n). La referencia R'n representa una imagen reconstruida final. Los bloques 703, 803 ilustran la transformada inversa (T-1). Los bloques 702, 802 ilustran la cuantificación inversa (Q-1). Los bloques 701, 801 ilustran la decodificación de entropía (E-1). Los bloques 705, 805 ilustran una memoria de cuadro de referencia (RFM). Los bloques 706, 806 ilustran la predicción (P) (ya sea entre predicciones o intra predicciones). Los bloques 707, 807 ilustran el filtrado (F). Los bloques 708, 808 se pueden usar para combinar información de error de predicción decodificada con componentes de vista base/vista sin base pronosticados para obtener las imágenes reconstruidas preliminares (I'n). Las imágenes de vista de base reconstruidas y filtradas preliminares pueden salir 709 desde la primera sección de decodificador 552 y las imágenes de vista de base reconstruidas y filtradas preliminares pueden enviarse 809 desde la primera sección de decodificador 554.
Aquí, el decodificador debe interpretarse para cubrir cualquier unidad operativa capaz de realizar las operaciones de decodificación, como un reproductor, un receptor, una puerta de enlace, un demultiplexor y/o un decodificador.
La figura 14 es una representación gráfica de un sistema de comunicación multimedia de ejemplo dentro del cual se pueden implementar varias realizaciones. Una fuente 1510 de datos proporciona una señal de fuente en un formato analógico, digital sin comprimir o digital comprimido, o cualquier combinación de estos formatos. Un codificador 1520 puede incluir o estar conectado con un preprocesamiento, tal como conversión de formato de datos y/o filtrado de la señal fuente. El codificador 1520 codifica la señal fuente en un flujo de bits de medios codificado. Cabe señalar que un flujo de bits a decodificar puede recibirse directa o indirectamente desde un dispositivo remoto ubicado dentro de prácticamente cualquier tipo de red. Además, el flujo de bits se puede recibir desde hardware o software local. El codificador 1520 puede ser capaz de codificar más de un tipo de medio, como audio y video, o puede ser necesario más de un codificador 1520 para codificar diferentes tipos de medios de la señal fuente. El codificador 1520 también puede obtener una entrada producida sintéticamente, como gráficos y texto, o puede ser capaz de producir flujos de bits codificados de medios sintéticos. A continuación, solo se considera que el procesamiento de un flujo de bits de medios codificado de un tipo de medio simplifica la descripción. Sin embargo, debe tenerse en cuenta que, por lo general, los servicios de transmisión en tiempo real comprenden varias transmisiones (por lo general, al menos una transmisión de subtítulos de audio, video y texto). También debe tenerse en cuenta que el sistema puede incluir muchos codificadores, pero en la figura solo se representa un codificador 1520 para simplificar la descripción sin falta de generalidad. Debe entenderse además que, aunque el texto y los ejemplos contenidos en este documento pueden describir específicamente un proceso de codificación, un experto en la técnica entendería que los mismos conceptos y principios también se aplican al proceso de decodificación correspondiente y viceversa.
El flujo de bits de medios codificado se puede transferir a un almacenamiento 1530. El almacenamiento 1530 puede comprender cualquier tipo de memoria masiva para almacenar el flujo de bits de medios codificados. El formato del flujo de bits de medios codificados en el almacenamiento 1530 puede ser un formato de flujo de bits autónomo elemental, o uno o más flujos de bits de medios codificados pueden encapsularse en un archivo contenedor, o el flujo de bits de medios codificados puede encapsularse en un formato de Segmento adecuado para DASH (o un sistema de transmisión similar) y se almacena como una secuencia de segmentos. Si uno o más flujos de bits de medios están encapsulados en un archivo contenedor, se puede usar un generador de archivos (no se muestra en la figura) para almacenar uno o más flujos de bits de medios en el archivo y crear metadatos de formato de archivo, que también pueden almacenarse en el archivo. El codificador 1520 o el almacenamiento 1530 pueden comprender el generador de archivos, o el generador de archivos está conectado operativamente al codificador 1520 o al almacenamiento 1530. Algunos sistemas funcionan “en vivo”, es decir, omiten el almacenamiento y transfieren el flujo de bits de medios codificados desde el codificador 1520 directamente al remitente 1540. El flujo de bits de medios codificado puede entonces transferirse al remitente 1540, también denominado servidor, según sea necesario. El formato utilizado en la transmisión puede ser un formato de flujo de bits autónomo elemental, un formato de flujo de paquetes, un formato de Segmento adecuado para DASH (o un sistema de flujo similar), o uno o más flujos de bits de medios codificados pueden encapsularse en un archivo contenedor. El codificador 1520, el almacenamiento 1530 y el servidor 1540 pueden residir en el mismo dispositivo físico o pueden estar incluidos en dispositivos separados. El codificador 1520 y el servidor 1540 pueden funcionar con contenido en vivo en tiempo real, en cuyo caso el flujo de bits de medios codificado no se almacena normalmente de forma permanente, sino que se almacena en búfer durante pequeños períodos de tiempo en el codificador de contenido 1520 y/o en el servidor 1540 para suavizar variaciones en el retardo de procesamiento, retardo de transferencia y tasa de bits de medios codificados.
El servidor 1540 envía el flujo de bits de medios codificado usando una pila de protocolos de comunicación. La pila puede incluir, entre otros, uno o más Protocolo de transporte en tiempo real (RTP), Protocolo de datagramas de usuario (UDP), Protocolo de transferencia de hipertexto (HTTP), Protocolo de control de transmisión (TCP) y Protocolo de Internet (IP). Cuando la pila de protocolos de comunicación está orientada a paquetes, el servidor 1540 encapsula el flujo de bits de medios codificados en paquetes. Por ejemplo, cuando se usa RTP, el servidor 1540 encapsula el flujo de bits de medios codificados en paquetes RTP de acuerdo con un formato de carga útil RTP. Normalmente, cada tipo de medio tiene un formato de carga útil RTP dedicado. Cabe señalar de nuevo que un sistema puede contener más de un servidor 1540, pero en aras de la simplicidad, la siguiente descripción solo considera un servidor 1540.
Si el contenido de los medios está encapsulado en un archivo contenedor para el almacenamiento 1530 o para ingresar los datos al remitente 1540, el remitente 1540 puede comprender o estar conectado operativamente a un “analizador de archivos de envío” (no se muestra en la figura). En particular, si el archivo contenedor no se transmite como tal, pero al menos uno de los flujos de bits de medios codificados contenidos está encapsulado para su transporte a través de un protocolo de comunicación, un analizador de archivos de envío ubica las partes apropiadas del flujo de bits de medios codificados para ser transportados a través del protocolo de comunicación. El analizador de archivos de envío también puede ayudar a crear el formato correcto para el protocolo de comunicación, como encabezados de paquetes y cargas útiles. El archivo contenedor multimedia puede contener instrucciones de encapsulación, tales como pistas indirectas en el ISOBMFF, para encapsular al menos uno de los flujos de bits de medios contenidos en el protocolo de comunicación.
El servidor 1540 puede estar conectado o no a una puerta de enlace 1550 a través de una red de comunicación, que puede, por ejemplo, ser una combinación de CDN, Internet y/o una o más redes de acceso. La puerta de enlace también puede denominarse, o alternativamente, caja intermedia. Para DASH, la puerta de enlace puede ser un servidor de borde (de una CDN) o un proxy web. Se observa que el sistema generalmente puede comprender cualquier número de puerta de enlaces o similar, pero en aras de la simplicidad, la siguiente descripción solo considera una puerta de enlace 1550. La puerta de enlace 1550 puede realizar diferentes tipos de funciones, como la traducción de un flujo de paquetes de acuerdo con una pila de protocolos de comunicación a otra pila de protocolos de comunicación, fusión y bifurcación de flujos de datos, y manipulación del flujo de datos de acuerdo con las capacidades del enlace descendente y/o del receptor, como controlar la velocidad de bits del flujo reenviado según las condiciones de la red del enlace descendente predominantes.
El sistema incluye uno o más receptores 1560, típicamente capaces de recibir, demodular y desencapsular la señal transmitida en un flujo de bits de medios codificado. El flujo de bits de medios codificados puede transferirse a un almacenamiento 1570 de grabación. El almacenamiento 1570 de grabaciones puede comprender cualquier tipo de memoria masiva para almacenar el flujo de bits de medios codificados. El almacenamiento 1570 de grabación puede comprender de forma alternativa o aditiva una memoria de cálculo, tal como una memoria de acceso aleatorio. El formato del flujo de bits de medios codificados en el almacenamiento 1570 de grabación puede ser un formato de flujo de bits autónomo elemental, o se pueden encapsular uno o más flujos de bits de medios codificados en un archivo contenedor. Si hay múltiples flujos de bits de medios codificados, como un flujo de audio y un flujo de video, asociados entre sí, se usa típicamente un archivo contenedor y el receptor 1560 comprende o está conectado a un generador de archivos contenedor que produce un archivo contenedor a partir de flujos de entrada. Algunos sistemas operan “en vivo”, es decir, omiten el almacenamiento 1570 de grabación y transfieren el flujo de bits de medios codificados desde el receptor 1560 directamente al decodificador 1580. En algunos sistemas, solo la parte más reciente del flujo grabado, por ejemplo, los últimos 10 minutos extracto del flujo grabado, se mantiene en el almacenamiento 1570 de grabación, mientras que cualquier dato grabado anteriormente se descarta del almacenamiento 1570 de grabación.
El flujo de bits de medios codificado puede transferirse desde el almacenamiento 1570 de grabación al decodificador 1580. Si hay muchos flujos de bits de medios codificados, como un flujo de audio y un flujo de video, asociados entre sí y encapsulados en un archivo contenedor o un flujo de bits de un solo medio está encapsulado en un archivo contenedor, por ejemplo, para facilitar el acceso, se utiliza un analizador de archivos (no se muestra en la figura) para desencapsular cada flujo de bits de medios codificados del archivo contenedor. El almacenamiento 1570 de grabaciones o un decodificador 1580 pueden comprender el analizador de archivos, o el analizador de archivos se adjunta al almacenamiento 1570 de grabaciones o al decodificador 1580. También debe tenerse en cuenta que el sistema puede incluir muchos decodificadores, pero aquí solo se incluye un decodificador 1580. discutido para simplificar la descripción sin falta de generalidad
El flujo de bits de medios codificado puede ser procesado adicionalmente por un decodificador 1580, cuya salida es uno o más flujos de medios sin comprimir. Finalmente, un renderizador 1590 puede reproducir los flujos de medios sin comprimir con un altavoz o una pantalla, por ejemplo. El receptor 1560, el almacenamiento 1570 de grabación, el decodificador 1580 y el renderizador 1590 pueden residir en el mismo dispositivo físico o pueden estar incluidos en dispositivos separados.
Un remitente 1540 y/o una puerta de enlace 1550 pueden configurarse para realizar la conmutación entre diferentes representaciones, por ejemplo, para conmutación de vista, adaptación de velocidad de bits y/o arranque rápido, y/o un remitente 1540 y/o una puerta de enlace 1550 pueden configurarse para seleccionar la representación o representaciones transmitidas. La conmutación entre diferentes representaciones puede tener lugar por múltiples razones, tales como responder a solicitudes del receptor 1560 o condiciones predominantes, tales como rendimiento, de la red por la que se transmite el flujo de bits. Una solicitud del receptor puede ser, por ejemplo, una solicitud de un Segmento o un Subsegmento de una representación diferente a la anterior, una solicitud de un cambio de capas y/o subcapas de escalabilidad transmitidas, o un cambio de un dispositivo de representación que tiene diferentes capacidades en comparación con el anterior. Una solicitud de un Segmento puede ser una solicitud HTTP GET. Una solicitud de un subsegmento puede ser una solicitud HTTP GET con un rango de bytes. Adicional o alternativamente, el ajuste de la tasa de bits o la adaptación de la tasa de bits se pueden usar, por ejemplo, para proporcionar el llamado inicio rápido en servicios de transmisión, donde la tasa de bits de la transmisión transmitida es menor que la tasa de bits del canal después de iniciar o acceder aleatoriamente a la transmisión con el fin de iniciar la reproducción inmediatamente y lograr un nivel de ocupación del búfer que tolere retrasos ocasionales de paquetes y/o retransmisiones. La adaptación de la velocidad de bits puede incluir operaciones de representación múltiple o conmutación ascendente y representación o conmutación descendente de capas que tienen lugar en varios órdenes.
Un decodificador 1580 puede configurarse para realizar la conmutación entre diferentes representaciones, por ejemplo, para conmutación de vista, adaptación de velocidad de bits y/o arranque rápido, y/o puede configurarse un decodificador 1580 para seleccionar la representación o representaciones transmitidas. La conmutación entre diferentes representaciones puede tener lugar por múltiples razones, como para lograr una operación de decodificación más rápida o para adaptar el flujo de bits transmitido, por ejemplo, en términos de tasa de bits, a las condiciones predominantes, como el rendimiento, de la red por la que se transmite el flujo de bits. Podría ser necesaria una operación de decodificación más rápida, por ejemplo, si el dispositivo que incluye el decodificador 1580 es multitarea y utiliza recursos informáticos para otros fines distintos de la decodificación del flujo de bits de vídeo escalable. En otro ejemplo, podría ser necesaria una operación de decodificación más rápida cuando el contenido se reproduce a un ritmo más rápido que la velocidad de reproducción normal, por ejemplo, dos o tres veces más rápido que la velocidad de reproducción en tiempo real convencional. La velocidad de la operación del decodificador puede cambiarse durante la decodificación o reproducción, por ejemplo, como respuesta al cambio de una reproducción en avance rápido a una velocidad de reproducción normal o viceversa, y en consecuencia, las operaciones de conmutación hacia arriba y hacia abajo de múltiples capas pueden tener lugar en varios órdenes.
Debe entenderse que dividir una imagen fuente en rectángulos de mosaico puede, pero no necesariamente, dar como resultado rectángulos de mosaico no superpuestos. En general, los rectángulos de mosaicos pueden superponerse y las realizaciones se pueden aplicar a rectángulos de mosaicos superpuestos.
En lo anterior, se han descrito algunas realizaciones con referencia al término segmento de sector. Debe entenderse que las realizaciones se aplican de manera similar a otras unidades de particionamiento de imágenes similares. Por ejemplo, algunos esquemas de codificación pueden no incluir el concepto de segmentos de sectores, pero pueden tener el concepto de sectores, como se define en los estándares de codificación de video que incluyen H.264/AVC y HEVC, en cuyo caso las realizaciones se aplican a los sectores.
En lo anterior, se han descrito algunas realizaciones en relación con H.264/AVC y/o HEVC y/o términos usados en la especificación H.264/AVC y/o HEVC. Debe entenderse que las realizaciones se aplican de manera similar a otros códecs y formatos de codificación y otra terminología con equivalencia o similitud con los términos usados en las realizaciones descritas anteriormente.
En lo anterior, se han descrito algunas realizaciones en relación con ISOBMFF y/o formatos derivados de ISOBMFF. Debe entenderse que las realizaciones se aplican de manera similar a otros formatos de archivo y segmento, como el formato de archivo Matroska.
En lo anterior, se han descrito algunas realizaciones en relación con MPEG-DASH o DASH. Debe entenderse que las realizaciones se aplican de manera similar a otras formas de transmisión a través de HTTP, como Apple HTTP Live Streaming (HLS).
En lo anterior, se han descrito algunas realizaciones haciendo referencia al término transmisión. Debe entenderse que las realizaciones se aplican de manera similar a otras formas de transmisión de video, como la descarga progresiva, la entrega de archivos y las comunicaciones de video conversacionales, como el teléfono de video.
En lo anterior, donde las realizaciones de ejemplo se han descrito con referencia a un codificador, debe entenderse que el flujo de bits resultante y el decodificador pueden tener elementos correspondientes en ellos. Asimismo, cuando las realizaciones de ejemplo se han descrito con referencia a un decodificador, debe entenderse que el codificador puede tener una estructura y/o un programa informático para generar el flujo de bits a decodificar el decodificador.
Las realizaciones de la invención descritas anteriormente describen el códec en términos de un aparato codificador y decodificador separados para ayudar a la comprensión de los procesos implicados. Sin embargo, se apreciará que el aparato, las estructuras y las operaciones pueden implementarse como un único aparato/estructura/operación codificador-decodificador. Además, es posible que el codificador y el decodificador compartan algunos o todos los elementos comunes.
Aunque los ejemplos anteriores describen realizaciones de la invención que operan dentro de un códec dentro de un dispositivo electrónico, se apreciará que la invención tal como se define en las reivindicaciones puede implementarse como parte de cualquier códec de video. Así, por ejemplo, las realizaciones de la invención pueden implementarse en un códec de video que puede implementar la codificación de video sobre rutas de comunicación fijas o cableadas.
Por tanto, el equipo de usuario puede comprender un códec de vídeo como los descritos anteriormente en las realizaciones de la invención. Se apreciará que el término equipo de usuario está destinado a cubrir cualquier tipo adecuado de equipo de usuario inalámbrico, como teléfonos móviles, dispositivos portátiles de procesamiento de datos o navegadores web portátiles.
Además, los elementos de una red móvil terrestre pública (PLMN) también pueden comprender códecs de vídeo como se describió anteriormente.
En general, las diversas realizaciones de la invención pueden implementarse en hardware o circuitos de propósito especial, software, lógica o cualquier combinación de los mismos. Por ejemplo, algunos aspectos pueden implementarse en hardware, mientras que otros aspectos pueden implementarse en firmware o software que pueden ser ejecutados por un controlador, microprocesador u otro dispositivo informático, aunque la invención no se limita a los mismos. Si bien varios aspectos de la invención pueden ilustrarse y describirse como diagramas de bloques, diagramas de flujo o usando alguna otra representación pictórica, se entiende bien que estos bloques, aparatos, sistemas, técnicas o métodos descritos en este documento pueden implementarse en, como no- ejemplos limitantes, hardware, software, firmware, circuitos o lógica de propósito especial, hardware o controlador de propósito general u otros dispositivos informáticos, o alguna combinación de los mismos.
Las realizaciones de esta invención pueden implementarse mediante software de ordenador ejecutable por un procesador de datos del dispositivo móvil, tal como en la entidad procesadora, o por hardware, o por una combinación de software y hardware. Además, a este respecto, debe tenerse en cuenta que cualquier bloque del flujo lógico como en las Figuras puede representar etapas del programa, o circuitos, bloques y funciones lógicas interconectadas, o una combinación de etapas del programa y circuitos, bloques y funciones lógicas. El software puede almacenarse en medios físicos como chips de memoria o bloques de memoria implementados dentro del procesador, medios magnéticos como discos duros o disquetes y medios ópticos como, por ejemplo, DVD y sus variantes de datos, CD.
La memoria puede ser de cualquier tipo adecuado al entorno técnico local y puede implementarse utilizando cualquier tecnología de almacenamiento de datos adecuada, como dispositivos de memoria basados en semiconductores, dispositivos y sistemas de memoria magnética, dispositivos y sistemas de memoria óptica, memoria fija y memoria extraíble. Los procesadores de datos pueden ser de cualquier tipo adecuado para el entorno técnico local, y pueden incluir una o más ordenadores de uso general, ordenadores de propósito especial, microprocesadores, procesadores de señales digitales (DSP) y procesadores basados en arquitectura de procesador de múltiples núcleos, como ejemplos no limitantes.
Las realizaciones de las invenciones se pueden poner en práctica en varios componentes, tales como módulos de circuitos integrados. El diseño de circuitos integrados es, en general, un proceso altamente automatizado. Se encuentran disponibles herramientas de software complejas y poderosas para convertir un diseño de nivel lógico en un diseño de circuito semiconductor listo para ser grabado y formado en un sustrato semiconductor.
Los programas, como los proporcionados por Synopsys, Inc. de Mountain View, California y Cadence Design, de San José, California, enrutan automáticamente los conductores y ubican los componentes en un chip semiconductor utilizando reglas de diseño bien establecidas, así como bibliotecas de módulos de diseño pre - almacenados. Una vez que se ha completado el diseño de un circuito semiconductor, el diseño resultante, en un formato electrónico estandarizado (por ejemplo, Opus, GDSII o similar) puede transmitirse a una instalación de fabricación de semiconductores o “fab” para su fabricación.
La descripción anterior ha proporcionado a modo de ejemplos ejemplares y no limitantes una descripción completa e informativa de la realización ejemplar de esta invención. Sin embargo, varias modificaciones y adaptaciones pueden resultar evidentes para los expertos en las técnicas relevantes a la vista de la descripción anterior, cuando se leen junto con los dibujos adjuntos y las reivindicaciones adjuntas.

Claims (16)

REIVINDICACIONES
1. Un método que comprende:
dividir (900) imágenes de una secuencia de imágenes fuente en una pluralidad de rectángulos de mosaico a lo largo de una cuadrícula, en el que un rectángulo de mosaico es un área rectangular en una imagen;
formar un número correspondiente de secuencias de rectángulos de mosaicos, en el que cada secuencia de rectángulos de mosaicos corresponde a una determinada posición en la cuadrícula;
codificar (902) cada secuencia de rectángulo de mosaico independientemente en una o más versiones de un número correspondiente de secuencias de rectángulo de mosaico codificadas con diferentes características para ser utilizadas para la entrega dependiente de la ventana gráfica, en el que las características comprenden la calidad de la imagen; y
fusionar (904) dos o más rectángulos de mosaicos codificados de diferentes secuencias de rectángulos de mosaicos codificados verticalmente en cada instancia de tiempo en una imagen codificada de modo que cada rectángulo de mosaicos codificados forme un sector codificado en la imagen codificada para proporcionar una mejor calidad de imagen para una ventana gráfica que para un área restante de la imagen fuente, en la que una ventana gráfica representa una porción de la imagen decodificada presentada en una pantalla resultante de la decodificación de la imagen codificada.
2. Un método de la reivindicación 1, en el que los vectores de movimiento que requieren acceder a ubicaciones de muestra verticalmente fuera de los límites del rectángulo de mosaico se evitan y los vectores de movimiento que requieren acceder a ubicaciones de muestra horizontalmente fuera de los límites del rectángulo de mosaico se utilizan en la codificación de secuencias de rectángulo de mosaico.
3. Un método de cualquier reivindicación anterior, en el que dicha fusión comprende generar una línea de bloque adicional usando la predicción intra vertical de la fila de muestra más inferior de un rectángulo de mosaico reconstruido.
4. Un método de la reivindicación 3, en el que dicha fusión comprende generar una línea de bloque adicional usando codificación sin pérdidas que rellena la fila de muestra superior del rectángulo de mosaico verticalmente hasta la línea de bloque adicional.
5. Un método de cualquier reivindicación anterior, en el que las secuencias de rectángulos de mosaicos de diferentes anchos se combinan de manera que los rectángulos de mosaicos que son más estrechos que el rectángulo de mosaicos más ancho que se fusiona se añaden a la derecha con bloques que utilizan predicción intra horizontal.
6. Un método de cualquiera de las reivindicaciones anteriores, en el que las características de las secuencias de rectángulos de mosaicos codificadas comprenden además uno o más de los siguientes:
- Tasa de bits
- Densidad de muestreo o resolución espacial
- Profundidad de bits para uno o más componentes de color
- Gama dinámica
- Gama de colores
- Códec
- Perfil de códec.
7. Un método que comprende
recibir, por un servidor o un elemento de red, una pluralidad de secuencias de rectángulos de mosaicos codificadas con diferentes características para ser utilizadas para la entrega dependiente de la ventana gráfica, en el que las características comprenden calidad de imagen, dichas secuencias de rectángulos de mosaicos codificadas se originan a partir de imágenes de una secuencia de imagen fuente cuyas imágenes se han dividido en una pluralidad de rectángulos de mosaicos a lo largo de una cuadrícula, en la que un rectángulo de mosaicos es un área rectangular en una imagen, y en la que cada secuencia de rectángulos de mosaicos corresponde a una determinada posición en la cuadrícula; y
componer instrucciones, por el servidor o el elemento de red, haciendo que dos o más rectángulos de mosaico codificados se fusionen verticalmente en cada instancia de tiempo en una imagen codificada de modo que cada rectángulo de mosaico codificado forme un sector codificado en la imagen codificada para proporcionar una mejor calidad de imagen para una ventana gráfica que para un área restante de la imagen fuente, en la que una ventana gráfica representa una porción visualizada de la imagen decodificada resultante de la decodificación de la imagen codificada, las instrucciones comprenden instrucciones para la extracción de bytes de los dos o más rectángulos de mosaico codificados de diferentes secuencias de rectángulos de mosaicos codificados; e
incluir las instrucciones en o a lo largo de un flujo de bits o una pista que comprende al menos dichas dos o más secuencias de rectángulos de mosaicos codificadas.
8. Un método de la reivindicación 7, que comprende, además
componer instrucciones que hacen que dicha fusión comprenda generar una línea de bloque adicional usando la predicción intra vertical de la fila de muestra más inferior de un rectángulo de mosaico reconstruido.
9. Un método de la reivindicación 8, en el que dicha combinación comprende generar una línea de bloque adicional usando codificación sin pérdidas que rellena la fila de muestra superior del rectángulo de mosaico verticalmente hasta la línea de bloque adicional.
10. Un método de cualquiera de las reivindicaciones 7 a 9, que comprende, además
instrucciones de composición que hacen que las secuencias de rectángulos de mosaicos de diferentes anchos se fusionen de modo que los rectángulos de mosaicos que son más estrechos que el rectángulo de mosaicos más ancho que se fusiona se añaden a la derecha con bloques que utilizan la predicción intra horizontal.
11. Un método que comprende
determinar secuencias codificadas de rectángulos de mosaicos con diferentes características que se van a recibir, en las que las características comprenden la calidad de la imagen, a fin de proporcionar una mejor calidad de imagen para una ventana gráfica que representa una porción visualizada de las secuencias de rectángulos de mosaicos que se van a recibir que para el área restante de una imagen fuente, las secuencias de rectángulos de mosaicos codificadas que se originan a partir de una secuencia de imágenes fuente, cuyas imágenes se han dividido en una pluralidad de rectángulos de mosaicos a lo largo de una cuadrícula, donde un rectángulo de mosaicos es un área rectangular en una imagen, y donde cada secuencia de rectángulos de mosaicos corresponde a una cierta posición en la cuadrícula;
fusionar dos o más rectángulos de mosaicos codificados verticalmente en cada caso de tiempo en una imagen codificada de modo que cada rectángulo de mosaicos codificados forme un sector codificado en la imagen codificada; y
decodificar la imagen codificada.
12. Un método de la reivindicación 11, en el que dicha combinación comprende generar una línea de bloque adicional usando la predicción intra vertical de la fila de muestra más inferior de un rectángulo de mosaico reconstruido.
13. Un método de la reivindicación 12, en el que dicha fusión comprende generar una línea de bloque adicional usando codificación sin pérdidas que rellena la fila de muestra superior del rectángulo de mosaico verticalmente hasta la línea de bloque adicional.
14. Un método de cualquiera de las reivindicaciones 11-13, en el que las secuencias de rectángulos de mosaicos de diferentes anchos se combinan de modo que los rectángulos de mosaicos que son más estrechos que el rectángulo de mosaicos más ancho que se fusiona se añaden a la derecha con bloques que usan intra predicción horizontal.
15. Un aparato que comprende
al menos un procesador y al menos una memoria, dicha al menos una memoria almacenada con código en el mismo, que cuando se ejecuta por dicho al menos un procesador, hace que el aparato realice el método de acuerdo con cualquiera de las reivindicaciones 1 a 14.
16. Un medio de almacenamiento legible por ordenador almacenado con código en el mismo para su uso por un aparato, que cuando es ejecutado por un procesador, hace que el aparato realice el método de cualquiera de las reivindicaciones 1-14.
ES17211017T 2017-01-05 2017-12-29 Un aparato, un método y un programa de ordenador para la codificación y decodificación de vídeo Active ES2895927T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FI20175011 2017-01-05

Publications (1)

Publication Number Publication Date
ES2895927T3 true ES2895927T3 (es) 2022-02-23

Family

ID=60813776

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17211017T Active ES2895927T3 (es) 2017-01-05 2017-12-29 Un aparato, un método y un programa de ordenador para la codificación y decodificación de vídeo

Country Status (3)

Country Link
EP (2) EP3346709B1 (es)
ES (1) ES2895927T3 (es)
PL (1) PL3346709T3 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220224917A1 (en) * 2019-06-28 2022-07-14 Sony Semiconductor Solutions Corporation Transmitting apparatus, receiving apparatus, and transmission system

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10893256B2 (en) 2017-06-26 2021-01-12 Nokia Technologies Oy Apparatus, a method and a computer program for omnidirectional video
EP3673665A4 (en) * 2017-08-24 2021-03-10 Nokia Technologies Oy APPARATUS, PROCESS AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO
KR102411337B1 (ko) 2017-10-09 2022-06-22 노키아 테크놀로지스 오와이 비디오 코딩 및 디코딩을 위한 장치, 방법 및 컴퓨터 프로그램
WO2020071724A1 (en) * 2018-10-04 2020-04-09 Lg Electronics Inc. An apparatus for transmitting a video, a method for transmitting a video, an apparatus for receiving a video, and a method for receiving a video
EP3854092A4 (en) 2018-11-02 2021-11-17 Beijing Bytedance Network Technology Co. Ltd. KEEPING TABLES FOR THE STORAGE OF HMVP CANDIDATES
CN113302944B (zh) * 2018-12-28 2023-10-27 索尼集团公司 信息处理装置和信息处理方法
WO2020224639A1 (en) * 2019-05-09 2020-11-12 Beijing Bytedance Network Technology Co., Ltd. Improvement on hmvp table
EP3975552A4 (en) * 2019-06-18 2022-06-01 Sony Group Corporation FILE PROCESSING DEVICE, FILE PROCESSING METHOD AND PROGRAM
US11792432B2 (en) * 2020-02-24 2023-10-17 Tencent America LLC Techniques for signaling and identifying access unit boundaries
CN112150567B (zh) * 2020-11-06 2023-07-18 北京深维科技有限公司 一种heif图像编码方法及相关设备
US11483368B1 (en) 2021-07-06 2022-10-25 City University Of Hong Kong Video streaming method and system
EP4192008A1 (en) * 2021-12-01 2023-06-07 Axis AB An image processing device and a method for encoding a view area within an image frame of a video into an encoded video area frame
EP4195677A1 (en) * 2021-12-08 2023-06-14 Nokia Technologies Oy Displayed image transition

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6466254B1 (en) * 1997-05-08 2002-10-15 Be Here Corporation Method and apparatus for electronically distributing motion panoramic images
ES2675802T3 (es) * 2011-02-18 2018-07-12 Alcatel Lucent Procedimiento y aparato para transmitir y recibir un flujo de video panorámico

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220224917A1 (en) * 2019-06-28 2022-07-14 Sony Semiconductor Solutions Corporation Transmitting apparatus, receiving apparatus, and transmission system
US11871008B2 (en) * 2019-06-28 2024-01-09 Sony Semiconductor Solutions Corporation Transmitting apparatus, receiving apparatus, and transmission system

Also Published As

Publication number Publication date
PL3346709T3 (pl) 2022-01-03
EP3346709B1 (en) 2021-09-15
EP3979646A2 (en) 2022-04-06
EP3346709A1 (en) 2018-07-11
EP3979646A3 (en) 2022-05-18

Similar Documents

Publication Publication Date Title
ES2895927T3 (es) Un aparato, un método y un programa de ordenador para la codificación y decodificación de vídeo
US12022117B2 (en) Apparatus, a method and a computer program for video coding and decoding
US10893256B2 (en) Apparatus, a method and a computer program for omnidirectional video
US20200177809A1 (en) Method and an apparatus and a computer program for encoding media content
US11689705B2 (en) Apparatus, a method and a computer program for omnidirectional video
US11095907B2 (en) Apparatus, a method and a computer program for video coding and decoding
EP3979659B1 (en) A method, an apparatus and a computer readable storage medium for video streaming
CN108702503B (zh) 用于提供视频比特流的方法及装置
EP3349467B1 (en) An apparatus, a method and a computer program for video coding and decoding
WO2019141907A1 (en) An apparatus, a method and a computer program for omnidirectional video
WO2017093611A1 (en) A method for video encoding/decoding and an apparatus and a computer program product for implementing the method
US20230059516A1 (en) Apparatus, a method and a computer program for omnidirectional video
WO2018115572A2 (en) An apparatus, a method and a computer program for video coding and decoding
WO2020201632A1 (en) An apparatus, a method and a computer program for omnidirectional video
US11909983B2 (en) Apparatus, a method and a computer program for video coding and decoding
WO2019038473A1 (en) APPARATUS, METHOD AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO