ES2650220T3

ES2650220T3 - Señalización de las características de un punto de operación de MVC

Info

Publication number: ES2650220T3
Application number: ES10749537.6T
Authority: ES
Inventors: Ying Chen; Peisong Chen; Marta Karczewicz
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2009-08-07
Filing date: 2010-08-06
Publication date: 2018-01-17
Anticipated expiration: 2030-08-06
Also published as: SG177621A1; EP2462742A1; JP2013502097A; MY180768A; RU2012108618A; CN102474655A; WO2011017661A1; TW201112769A; KR101293425B1; EP2462742B1; KR20120054052A; IL217436A0; HUE037168T2; TWI581635B; IL217436A; RU2530740C2; CA2768618C; US8948241B2; CN102474655B; BR112012002259A2

Abstract

Un procedimiento que comprende: construir, con un dispositivo de origen, una pluralidad de descriptores de puntos de operación de codificación de vídeo multivista (MVC) (114,140), cada uno correspondiente a un punto de operación de MVC, en el que cada descriptor de punto de operación de MVC se inserta en la Tabla de Mapas de Programa (PMT) o los bucles descriptores de Mapas de Flujos de Programa (PSM) de un flujo de bits estándar del sistema de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), en el que cada descriptor de punto de operación de MVC (114, 140) señaliza un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo de recepción para usar el correspondiente punto de operación de MVC, y un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para usar el correspondiente punto de operación de MVC, en el que el valor de capacidad de representación describe al menos un número de vistas destinadas para representar (150), para el correspondiente punto de operación de MVC, una velocidad de tramas para datos de vídeo (149) del correspondiente punto de operación de MVC, y un valor de identificador temporal (158) para el correspondiente punto de operación de MVC; en el que el valor de la capacidad de decodificación describe al menos un número de vistas a decodificar (152) para el correspondiente punto de operación de MVC, un valor de nivel (148) correspondiente al punto de operación de MVC y un valor de perfil (146) correspondiente al punto de operación de MVC; y emitir el flujo de bits que comprende la pluralidad de descriptores de puntos de operación de MVC (114, 140).

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

descripción

Señalización de las características de un punto de operación de MVC

campo técnico

[0001] Esta divulgación se refiere al transporte de datos de vídeo codificados.

antecedentes

[0002] Las capacidades del vídeo digital pueden incorporarse a una amplia gama de dispositivos, incluidos televisores digitales, sistemas de difusión directa digital, sistemas de radiodifusión inalámbrica, asistentes digitales personales (PDA), ordenadores portátiles o de escritorio, cámaras digitales, dispositivos de grabación digitales, reproductores de medios digitales, dispositivos de vídeojuegos, consolas de vídeojuegos, teléfonos celulares o de radio por satélite, dispositivos de vídeoconferencia y similares. Los dispositivos de vídeo digitales implementan técnicas de compresión de vídeo, tales como las descritas en las normas definidas por MPEG-2, MPEG-4, ITU-T H.263 o ITU-T H.264/MPEG-4, parte 10, codificación avanzada de vídeo (AVC) y ampliaciones de dichas normas, para transmitir y recibir información de vídeo digital de manera más eficaz.

[0003] Las técnicas de compresión de vídeo llevan a cabo una predicción espacial y/o una predicción temporal para reducir o eliminar la redundancia inherente a las secuencias de vídeo. Para la codificación de vídeo basada en bloques, una trama o un fragmento de vídeo pueden dividirse en macrobloques. Cada macrobloque se puede dividir aún más. Los macrobloques en una trama o un fragmento intracodificado (I) se codifican mediante predicción espacial con respecto a los macrobloques contiguos. Los macrobloques de una trama o fragmento intercodificado (P o B) pueden utilizar predicción espacial con respecto a los macrobloques contiguos en la misma trama o fragmento, o predicción temporal con respecto a otras tramas de referencia.

[0004] Después de que se hayan codificado los datos de vídeo, los datos de vídeo pueden agruparse en paquetes para su transmisión o almacenamiento. MPEG-2 incluye una sección "Sistemas" que define un nivel de transporte para muchos estándares de codificación de vídeo. Los sistemas del nivel de transporte de MPEG-2 pueden ser utilizados por codificadores de vídeo de MPEG-2 u otros codificadores de vídeo que cumplan con diferentes estándares de codificación de vídeo. Por ejemplo, MPEG-4 prescribe metodologías de codificación y decodificación diferentes a las de MPEG-2, pero los codificadores de vídeo que implementan las técnicas del estándar MPEG-4 pueden utilizar aún las metodologías del nivel de transporte de MPEG-2.

[0005] En general, las referencias a "Sistemas de MPEG-2" en esta divulgación se refieren al nivel de transporte de datos de vídeo prescritos por MPEG-2. El nivel de transporte prescrito por MPEG-2 también se menciona en esta divulgación como un "flujo de transporte de MPEG-2" o simplemente un "flujo de transporte". Asimismo, el nivel de transporte de los sistemas de MPEG-2 también incluye flujos de programas. Los flujos de transporte y los flujos de programas incluyen generalmente diferentes formatos para suministrar datos similares, donde un flujo de transporte comprende uno o más "programas" que incluyen tanto datos de audio como de vídeo, mientras que los flujos de programas incluyen un programa que incluye tanto datos de audio como de vídeo.

[0006] Se han dedicado esfuerzos para elaborar nuevas normas de codificación de vídeo basándose en la H.264/AVC. Una de estas normas es la norma de codificación de vídeo ajustable a escala (SVC), que es la extensión ajustable a escala para la H.264/AVC. Otra norma es la codificación de vídeo multivista (MVC), que se ha convertido en la extensión multivista para la H.264/AVC. La especificación de los sistemas de MPEG-2 describe cómo los flujos de datos de multimedios (vídeo y audio) comprimidos pueden multiplexarse junto con otros datos para formar un solo flujo de datos adecuado para la transmisión o almacenamiento digital. La más reciente especificación de los sistemas de MPEG-2 se especifica en el artículo "Tecnología de la información-Codificación genérica de imágenes en movimiento y audio asociado: Sistemas, Recomendación H.222.0; Organización Internacional de Normalización, ISO / IEC TTC1 / SC29 / WG11; Codificación de imágenes en movimiento y audio asociado", mayo de 2006. El MPEG ha diseñado recientemente el estándar de transporte de la MVC sobre los sistemas de MPEG-2 y la versión más reciente de esta especificación es "Estudio de ISO / IEC 13818-1: 2007 / FPDAM4 Transporte de MVC", MPEG doc. N10572, MPEG de ISO / IEC JTC1 / SC29 / WG11, Maui, Hawai, EE UU, abril de 2009.

resumen

[0007] En general, esta divulgación describe técnicas para mejorar la codificación de vídeo multivista en los sistemas de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento). En particular, las técnicas de esta divulgación se dirigen a una estructura de datos para un punto de operación de un flujo de bits del Sistema MPEG-2, donde la estructura de datos señaliza una capacidad de representación para un dispositivo receptor, una capacidad de decodificación para el dispositivo receptor y, en algunos ejemplos, una tasa de bits para el punto de operación. La estructura de datos puede corresponder a un descriptor de punto de operación que se incluye en el flujo de bits del Sistema MPEG-2.

5

10

15

20

25

30

35

40

45

50

55

60

65

[0008] Con el fin de descodificar y exhibir correctamente los datos de vídeo de un punto de operación, un dispositivo de recepción debería satisfacer las propiedades descritas por la capacidad de representación y la capacidad de decodificación señalizadas en la estructura de datos. Los flujos de bits de los sistemas MPEG-2 pueden incluir una pluralidad de puntos de operación que corresponden a varias vistas de un programa. El uso de diferentes puntos de operación para un programa permite que varios dispositivos clientes realicen la adaptación. Es decir, los dispositivos clientes con diferentes capacidades de representación y decodificación pueden extraer vistas desde el mismo programa para mostrar datos de vídeo bidimensionales o tridimensionales. Los dispositivos clientes también pueden negociar con un dispositivo servidor para recuperar datos de velocidades de bits variables, para adaptarse a medios de transporte de varias capacidades de ancho de banda.

[0009] En un ejemplo, un procedimiento incluye la construcción, con un dispositivo de origen, de una estructura de datos correspondiente a un punto de operación de codificación de vídeo multivista (MVC) de un flujo de bits estándar del Sistema MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para usar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC, y en el que la estructura de datos se incluye como parte del flujo de bits, y la emisión del flujo de bits que comprende la estructura de datos.

[0010] En otro ejemplo, un aparato incluye un multiplexor que construye una estructura de datos correspondiente a un punto de operación de MVC de un flujo de bits estándar de un Sistema de MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación a ser satisfecha por un dispositivo de recepción para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para utilizar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC y que incluye la estructura de datos como parte del flujo de bits, y una interfaz de salida que emite el flujo de bits que comprende la estructura de datos.

[0011] En otro ejemplo, un aparato incluye medios para la construcción de una estructura de datos correspondiente a un punto de operación de MVC de un flujo de bits estándar de un Sistema de MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación a ser satisfecha por un dispositivo receptor para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de descodificación que debe satisfacer el dispositivo receptor para utilizar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC, y en el que la estructura de datos se incluye como parte del flujo de bits, y medios para emitir el flujo de bits que comprende la estructura de datos.

[0012] En otro ejemplo, un medio de almacenamiento legible por ordenador comprende instrucciones que hacen que un procesador de un dispositivo de origen construya una estructura de datos correspondiente a un punto de operación de MVC de un flujo de bits estándar de un Sistema de MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para utilizar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC, y en el que la estructura de datos se incluye como parte del flujo de bits, y hacen que una interfaz de salida emita el flujo de bits que comprende la estructura de datos.

[0013] En otro ejemplo, un procedimiento incluye la recepción, con un dispositivo de destino, de una estructura de datos correspondiente a un punto de operación de MVC de un flujo de datos estándar de un Sistema MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para utilizar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC, la determinación de si un decodificador de vídeo del dispositivo de destino es capaz de decodificar vistas correspondientes al punto de operación de la MVC sobre la base de la capacidad de decodificación señalizada por la estructura de datos, la determinación de si el dispositivo de destino es capaz de representar las vistas correspondientes a el punto de operación de la MVC basándose en la capacidad de representación señalizada por la estructura de datos, y el envío de las vistas correspondientes al punto de operación de la MVC al decodificador de vídeo del dispositivo de destino cuando se determina que el decodificador de vídeo del dispositivo de destino es capaz de decodificar y representar las vistas correspondientes al punto de operación de la MVC.

[0014] En otro ejemplo, un aparato incluye una interfaz de entrada configurada para recibir una estructura de datos correspondiente a un punto de operación de MVC de un flujo de bits estándar de un Sistema de MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de

5

10

15

20

25

30

35

40

45

50

55

60

65

representación para ser satisfecho por un dispositivo receptor para usar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para usar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC, un decodificador de vídeo configurado para decodificar datos de vídeo; y un demultiplexor configurado para determinar si el decodificador de vídeo es capaz de decodificar vistas que corresponden al punto de operación de la MVC basándose en la capacidad de decodificación señalizada por la estructura de datos, determinar si el aparato es capaz de representar las vistas correspondientes al punto de operación de la MVC basándose en la capacidad de representación señalizada por la estructura de datos, y enviar las vistas correspondientes al punto de operación de la MVC al decodificador de vídeo cuando se determina que el decodificador de vídeo es capaz de decodificar y representar las vistas correspondientes al punto de operación de la MVC.

[0015] En otro ejemplo, un aparato incluye medios para recibir una estructura de datos correspondiente a un punto de operación de MVC de un flujo de bits estándar de un Sistema de MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación a ser satisfecha por un dispositivo receptor para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que debe satisfacer el dispositivo receptor para utilizar el punto de operación de la MVC y un valor de velocidad de bits que describe un valor de velocidad de bits del punto de operación de la MVC, medios para determinar si un decodificador de vídeo del aparato es capaz de decodificar vistas correspondientes al punto de operación de la MVC basándose en la capacidad de decodificación señalizada por la estructura de datos, medios para determinar si el aparato es capaz de representar las vistas correspondientes al punto de operación de la MVC basándose en la capacidad de representación señalizada por la estructura de datos, y medios para enviar las vistas correspondientes al punto de operación de la MVC al decodificador de vídeo del aparato cuando se determina que el decodificador de vídeo del aparato es capaz de decodificar y representar las vistas correspondientes al punto de operación de la MVC.

[0016] En otro ejemplo, un medio de almacenamiento legible por ordenador comprende instrucciones que hacen que un procesador de un dispositivo de destino reciba una estructura de datos correspondiente a un punto de operación de MVC de un flujo de bits estándar de un Sistema de MPEG-2, en el que la estructura de datos señaliza un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para utilizar el punto de operación de la MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para utilizar el punto de operación de la MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de la MVC, determine si un decodificador de vídeo del dispositivo de destino es capaz de decodificar vistas que corresponden al punto de operación de la MVC basándose en la capacidad de decodificación señalizada por la estructura de datos, determine si el dispositivo de destino es capaz de representar las vistas correspondiente al punto de operación de la MVC basándose en la capacidad de representación señalizada por la estructura de datos, y envíe las vistas correspondientes al punto de operación de la MVC al decodificador de vídeo del dispositivo de destino cuando se determina que el decodificador de vídeo del dispositivo de destino es capaz de decodificar y representar las vistas correspondientes al punto de operación de la MVC.

[0017] Los detalles de uno o más ejemplos se exponen en los dibujos adjuntos y en la descripción siguiente. Otras características, objetos y ventajas resultarán evidentes a partir de la descripción y de los dibujos, y a partir de las reivindicaciones.

breve descripción de los dibujos

[0018]

La FIG. 1 es un diagrama de bloques que ilustra un sistema ejemplar en el que un dispositivo de origen de audio / vídeo (A / V) transporta datos de audio y vídeo a un dispositivo de destino de A / V.

La FIG. 2 es un diagrama de bloques que ilustra una disposición ejemplar de componentes de un multiplexor, compatible con esta divulgación.

La FIG. 3 es un diagrama de bloques que ilustra un conjunto ejemplar de tablas de información específica del programa, compatibles con esta divulgación.

Las FIGS. 4 a 6 son diagramas conceptuales que ilustran varios ejemplos de conjuntos de datos que pueden incluirse en un descriptor de punto de operación.

La FIG. 7 es un diagrama conceptual que ilustra un patrón ejemplar de predicción de la MVC.

La FIG. 8 es un diagrama de flujo que ilustra un procedimiento ejemplar para usar una estructura de datos que señaliza características de un punto de operación.

5

10

15

20

25

30

35

40

45

50

55

60

65

descripción detallada

[0019] Las técnicas de la presente divulgación son generalmente dirigidas a la mejora de la Codificación de Vídeo Multivista (MVC) en sistemas de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), es decir, sistemas que cumplen con la norma MPEG-2 con respecto a los detalles del nivel de transporte. La norma MPEG-4, por ejemplo, proporciona estándares para la codificación de vídeo, pero generalmente supone que los codificadores de vídeo que se ajustan al estándar MPEG-4 utilizarán sistemas del nivel de transporte de MPEG-2. En consecuencia, las técnicas de esta divulgación son aplicables a codificadores de vídeo que se ajustan a las normas MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4 o cualquier otro estándar de codificación de vídeo que utilice flujos de transporte y / o flujos de programa de MPEG-2 (también llamados "flujos de programa").

[0020] En particular, las técnicas de la presente divulgación pueden modificar los elementos sintácticos en el nivel de transporte para flujos de transporte y flujos de programa de MPEG-2. Por ejemplo, las técnicas de esta divulgación incluyen un descriptor que se transmite en el flujo de transporte para describir características de un punto de operación. Un dispositivo servidor, por ejemplo, puede proporcionar varios puntos de operación en un flujo de bits de la capa de transporte de MPEG-2, cada uno de los cuales corresponde a un subconjunto respectivo de vistas particulares de datos de vídeo de la codificación de vídeo multivista. Es decir, un punto de operación generalmente corresponde a un subconjunto de vistas de un flujo de bits. En algunos ejemplos, cada vista de un punto de operación incluye datos de vídeo a la misma velocidad de tramas.

[0021] Un dispositivo de destino puede utilizar descriptores de punto de operación incluidos en un flujo de bits para seleccionar uno de los puntos de operación a decodificar y presentar (por ejemplo, exhibir) en última instancia a un usuario. En lugar de pasar datos para todas las vistas a un decodificador de vídeo tras la recepción, el dispositivo de destino puede enviar sólo las vistas de un punto de operación seleccionado al decodificador de vídeo. De esta manera, el dispositivo de destino puede descartar datos para vistas que no se decodificarán. El dispositivo de destino puede seleccionar un punto de operación basándose en la calidad más alta con soporte de uno de los puntos de operación para un flujo de bits.

[0022] El dispositivo servidor puede enviar una pluralidad de sub-flujos de bits (cada uno de los cuales puede corresponder a un punto de operación) en un único flujo de transporte o flujo de programa. Aunque en varias secciones esta divulgación puede referirse individualmente a un "flujo de transporte" o un "flujo de programa", debería entenderse que las técnicas de esta divulgación son generalmente aplicables a cualquiera de los flujos de transporte y flujos de programas de MPEG-2, o a ambos. En general, esta divulgación describe el uso de descriptores como estructuras de datos ejemplares para llevar a cabo las técnicas de esta divulgación. Los descriptores se utilizan para ampliar la funcionalidad de un flujo. Los descriptores de esta divulgación pueden ser usados tanto por flujos de transporte como por flujos de programas para implementar las técnicas de esta divulgación. Aunque esta divulgación se centra principalmente en los descriptores como una estructura de datos ejemplares que puede usarse para señalizar un valor de capacidad de representación para un punto de operación, un valor de capacidad de decodificación para el punto de operación y un valor de velocidad de bits para el punto de operación, debería entenderse que otras estructuras de datos también pueden usarse para llevar a cabo estas técnicas.

[0023] De acuerdo a las técnicas de la presente divulgación, el dispositivo de origen 20 puede construir un descriptor de punto de operación que describe características de un punto de operación. Las características pueden incluir, por ejemplo, qué vistas están incluidas en un punto de operación y las velocidades de tramas para las vistas del punto de operación. El descriptor de punto de operación puede especificar una capacidad de representación que debería tener soporte por parte de un decodificador de vídeo con el fin de recibir y decodificar el punto de operación, una capacidad de decodificación que debería tener soporte por parte del decodificador de vídeo para recibir y descodificar el punto de operación y una velocidad de bits para el punto de operación.

[0024] Las técnicas de esta divulgación, en general, pueden representar cada punto de operación como si el punto de operación fuera su propio programa, señalizado por una tabla de mapas de programa en un flujo de transporte o un mapa de flujos de programa en un flujo de programa. Alternativamente, cuando un programa contiene múltiples puntos de operación, las técnicas de esta divulgación proporcionan información sobre cómo se han de reensamblar los puntos de operación en los descriptores de punto de operación. Los descriptores de punto de operación pueden señalizar además dependencias de puntos de operación, que pueden ahorrar bits.

[0025] La FIG. 1 es un diagrama de bloques que ilustra un sistema ejemplar 10 en el que el dispositivo de origen de audio / vídeo (A / V) 20 transporta datos de audio y vídeo al dispositivo de destino de A / V 40. El sistema 10 de la FIG. 1 puede corresponder a un sistema de teleconferencia por vídeo, un sistema de servidor / cliente, un sistema de difusor / receptor, o cualquier otro sistema en el que se envíen datos de vídeo desde un dispositivo de origen, tal como un dispositivo de origen de A / V 20, a un dispositivo de destino, tal como un dispositivo de destino de A / V 40. En algunos ejemplos, el dispositivo de origen de A / V 20 y el dispositivo de destino de A / V 40 pueden realizar el intercambio bidireccional de información. Es decir, el dispositivo de origen de A / V 20 y el dispositivo de destino de A / V 40 pueden ser capaces tanto de codificar como de decodificar (y transmitir y recibir) datos de audio y vídeo. En algunos ejemplos, el codificador de audio 26 puede comprender un codificador de voz, también denominado

5

10

15

20

25

30

35

40

45

50

55

60

65

vocodificador.

[0026] El dispositivo de origen de A / V 20, en el ejemplo de la FIG. 1, comprende el origen de audio 22 y el origen de vídeo 24. El origen de audio 22 puede comprender, por ejemplo, un micrófono que produce señales eléctricas representativas de los datos de audio capturados que han de ser codificados por el codificador de audio 26. Como alternativa, el origen de audio 22 puede comprender un medio de almacenamiento que almacena datos de audio previamente grabados, un generador de datos de audio tal como un sintetizador informatizado o cualquier otro origen de datos de audio. El origen de vídeo 24 puede comprender una cámara de vídeo que produce datos de vídeo que han de ser codificados por el codificador de vídeo 28, un medio de almacenamiento codificado con datos de vídeo previamente grabados, una unidad de generación de datos de vídeo o cualquier otro origen de datos de vídeo.

[0027] Los datos de audio y de vídeo en bruto pueden comprender datos analógicos o digitales. Los datos analógicos pueden digitalizarse antes de ser codificados por el codificador de audio 26 y / o el codificador de vídeo 28. El origen de audio 22 puede obtener datos de audio de un participante que habla mientras el hablante está hablando y el origen de vídeo 24 puede obtener simultáneamente datos de vídeo del participante que habla. En otros ejemplos, el origen de audio 22 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de audio almacenados, y el origen de vídeo 24 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de vídeo almacenados. De esta manera, las técnicas descritas en esta divulgación pueden aplicarse a datos de audio y vídeo en tiempo real, de flujo de transmisión en vivo, o a datos de audio y vídeo archivados y pre-grabados.

[0028] Las tramas de audio que corresponden a tramas de vídeo son generalmente tramas de audio que contienen datos de audio que fueron capturados por el origen de audio 22 contemporáneamente con los datos de vídeo capturados por el origen de vídeo 24, que están contenidos dentro de las tramas de vídeo. Por ejemplo, aunque un participante hablante produce generalmente datos de audio hablando, el origen de audio 22 captura los datos de audio y el origen de vídeo 24 captura los datos de vídeo del participante que habla al mismo tiempo, es decir, mientras el origen de audio 22 captura los datos de audio. Por lo tanto, una trama de audio puede corresponder temporalmente a una o más tramas de vídeo particulares. Por consiguiente, una trama de audio correspondiente a una trama de vídeo corresponde generalmente a una situación en la que se capturaron datos de audio y datos de vídeo al mismo tiempo, y para la cual una trama de audio y una trama de vídeo comprenden respectivamente los datos de audio y los datos de vídeo que fueron capturados al mismo tiempo.

[0029] En algunos ejemplos, el codificador de audio 26 puede codificar un sello horario en cada trama de audio codificada, que representa una hora en que se registraron los datos de audio para la trama de audio codificada y, de manera similar, el codificador de vídeo 28 puede codificar un sello horario en cada trama de vídeo codificado, que representa una hora en la que se grabaron los datos de vídeo para la trama de vídeo codificada. En dichos ejemplos, una trama de audio correspondiente a una trama de vídeo puede comprender una trama de audio que comprende un sello horario y una trama de vídeo que comprende el mismo sello horario. El dispositivo de origen de A / V 20 puede incluir un reloj interno a partir del cual el codificador de audio 26 y / o el codificador de vídeo 28 pueden generar los sellos horarios, o que el origen de audio 22 y el origen de vídeo 24 pueden utilizar para asociar datos de audio y vídeo, respectivamente, con un sello horario.

[0030] En algunos ejemplos, el origen de audio 22 puede enviar datos al codificador de audio 26 correspondiente a una hora en la que se registraron los datos de audio, y el origen de vídeo 24 puede enviar datos al codificador de vídeo 28, correspondientes a una hora en la que se registraron los datos de vídeo. En algunos ejemplos, el codificador de audio 26 puede codificar un identificador de secuencia en datos de audio codificados para indicar un ordenamiento temporal relativo de datos de audio codificados, pero sin indicar necesariamente una hora absoluta a la cual se grabaron los datos de audio y, de manera similar, el codificador de vídeo 28 también puede usar identificadores de secuencia para indicar un ordenamiento temporal relativo de datos de vídeo codificados. De manera similar, en algunos ejemplos, un identificador de secuencia puede ser asociado o correlacionado de otro modo con un sello horario.

[0031] Las técnicas de la presente divulgación son generalmente dirigidas al transporte de datos de multimedios codificados (por ejemplo, audio y vídeo), y a la recepción y la posterior interpretación y decodificación de los datos de multimedios transportados. Las técnicas de esta divulgación son particularmente aplicables al transporte de datos de codificación de vídeo multivista (MVC), es decir, datos de vídeo que comprenden una pluralidad de vistas. Como se ilustra en el ejemplo de la FIG. 1, el origen de vídeo 24 puede proporcionar una pluralidad de vistas de una escena al codificador de vídeo 28. La MVC puede ser útil para generar datos de vídeo tridimensionales, a ser utilizados por una pantalla tridimensional, tal como una pantalla tridimensional estereoscópica o auto- estereoscópica.

[0032] El dispositivo de origen de A / V 20 puede proporcionar un "servicio" al dispositivo de destino de A / V 40. Un servicio generalmente corresponde a un subconjunto de vistas disponibles de datos de MVC. Por ejemplo, los datos de MVC pueden estar disponibles para ocho vistas, ordenadas de cero a siete. Un servicio puede corresponder a vídeo estéreo que tiene dos vistas, mientras que otro servicio puede corresponder a cuatro vistas, y otro servicio

5

10

15

20

25

30

35

40

45

50

55

60

65

más puede corresponder a las ocho vistas. En general, un servicio corresponde a cualquier combinación (es decir, a cualquier subconjunto) de las vistas disponibles. Un servicio también puede corresponder a una combinación de vistas disponibles, así como datos de audio. Un punto de operación puede corresponder a un servicio, de manera que el dispositivo de origen de A / V 20 pueda proporcionar además un descriptor de punto de operación para cada servicio proporcionado por el dispositivo de origen de A / V 20.

[0033] El dispositivo de origen de A / V 20, de acuerdo a las técnicas de esta divulgación, es capaz de proporcionar servicios que corresponden a un subconjunto de vistas. En general, una vista está representada por un identificador de vista, también denominado "id_vista". Los identificadores de vistas generalmente comprenden elementos sintácticos que pueden usarse para identificar una vista. Un codificador de MVC proporciona el id_vista de una vista cuando la vista está codificada. El id_vista puede ser utilizado por un decodificador de MVC para la predicción entre vistas, o por otras unidades con otros propósitos, por ejemplo, para representación.

[0034] La predicción entre vistas es una técnica para codificar datos de vídeo de MVC de una trama, con referencia a una o más tramas en una localización temporal común, como la trama codificada de vistas diferentes. La FIG. 7, que se analiza con más detalle a continuación, proporciona un esquema de codificación ejemplar para la predicción entre vistas. En general, una trama codificada de datos de vídeo de MVC puede codificarse de forma predictiva espacialmente, temporalmente y / o con referencia a tramas de otras vistas en una ubicación temporal común. Por consiguiente, las vistas de referencia, a partir de las cuales se predicen otras vistas, se decodifican generalmente antes de las vistas para las que las vistas de referencia actúan como referencia, de modo que estas vistas decodificadas se puedan usar como referencia cuando se decodifican vistas referenciales. El orden de decodificación no necesariamente corresponde al orden de los id_vista. Por lo tanto, el orden de decodificación de vistas se describe utilizando índices de orden de vista. Los índices de orden de vista son índices que indican el orden de decodificación de los correspondientes componentes de vista en una unidad de acceso.

[0035] Cada flujo individual de datos (ya sea de audio o vídeo) se menciona como un flujo elemental. Un flujo elemental es un componente único, codificado digitalmente (posiblemente comprimido) de un programa. Por ejemplo, la parte de vídeo o audio codificado del programa puede ser un flujo elemental. Un flujo elemental puede convertirse en un flujo elemental empaquetado (PES) antes de multiplexarse en un flujo de programa o flujo de transporte. Dentro del mismo programa, se utiliza un Identificador de flujo para distinguir los paquetes PES pertenecientes a un flujo elemental del otro. La unidad básica de datos de un flujo elemental es un paquete de flujo elemental empaquetado (PES). Por lo tanto, cada vista de datos de vídeo de MVC corresponde a respectivos flujos elementales. De forma similar, los datos de audio corresponden a uno o más respectivos flujos elementales.

[0036] Una secuencia de vídeo de MVC codificada puede ser separada en varios sub-flujos de bits, cada uno de los cuales es un flujo elemental. Cada sub-flujo de bits puede identificarse utilizando un subconjunto de los id_vista de la MVC. Basándose en el concepto de cada subconjunto de los id_vista de la MVC, se define un sub-flujo de bits de vídeo de la MVC. Un sub-flujo de bits de vídeo de MVC contiene las unidades de NAL de las vistas enumeradas en el subconjunto de los id_vista de la MVC. Un flujo de programas contiene generalmente sólo las unidades de NAL que son de las de los flujos elementales. También se diseña que dos flujos elementales cualesquiera no pueden contener una vista idéntica.

[0037] En el ejemplo de la FIG. 1, el multiplexor 30 recibe flujos elementales que comprenden datos de vídeo procedentes del codificador de vídeo 28 y flujos elementales que comprenden datos de audio procedentes del codificador de audio 26. En algunos ejemplos, el codificador de vídeo 28 y el codificador de audio 26 pueden incluir, cada uno, empaquetadores para formar paquetes PES a partir de datos codificados. En otros ejemplos, el codificador de vídeo 28 y el codificador de audio 26 pueden interactuar, cada uno, con los empaquetadores respectivos para formar paquetes PES a partir de datos codificados. En otros ejemplos más, el multiplexor 30 puede incluir empaquetadores para formar paquetes PES a partir de datos de audio y vídeo codificados.

[0038] Un "programa", tal como se utiliza en esta divulgación, puede comprender una combinación de datos de audio y datos de vídeo, por ejemplo, un flujo elemental de audio y un subconjunto de vistas disponibles entregadas por un servicio del dispositivo de origen de A / V 20. Cada paquete PES incluye un id_flujo que identifica el flujo elemental al que pertenece el paquete PES. El multiplexor 30 es responsable de ensamblar flujos elementales en flujos de programas o flujos de transporte constituyentes. Un flujo de programa y un flujo de transporte son dos multiplexores alternativos que apuntan a diferentes aplicaciones.

[0039] En general, un flujo de programa incluye datos de un programa, mientras que un flujo de transporte puede incluir datos para uno o más programas. El multiplexor 30 puede codificar uno cualquiera entre un flujo de programa o un flujo de transporte, o ambos, basándose en un servicio que se proporciona, un medio en el que se pasará el flujo, un número de programas que se enviarán u otras consideraciones. Por ejemplo, cuando los datos de vídeo han de ser codificados en un medio de almacenamiento, puede ser más probable que el multiplexor 30 forme un flujo de programas, mientras que, cuando los datos de vídeo han de ser transmitidos en flujo por una red, o transmitidos o enviados como parte de vídeotelefonía, puede ser más probable que el multiplexor 30 utilice un flujo de transporte.

[0040] El multiplexor 30 puede estar sesgado a favor de utilizar un flujo de programas para el almacenamiento y la

5

10

15

20

25

30

35

40

45

50

55

60

65

exhibición de un solo programa desde un servicio de almacenamiento digital. Un flujo de programas está diseñado para su uso en entornos libres de errores o entornos menos susceptibles de encontrar errores, ya que los flujos de programas son más susceptibles a los errores. Un flujo de programa comprende simplemente los flujos elementales que le pertenecen y normalmente contiene paquetes de longitudes variables. En un flujo de programas, los paquetes PES que se derivan de los flujos elementales contribuyentes se organizan en "paquetes". Un paquete comprende una cabecera de paquete, una cabecera de sistema optativa y cualquier número de paquetes PES tomados de cualquiera de los flujos elementales contribuyentes, en cualquier orden. La cabecera del sistema contiene un resumen de las características del flujo del programa, tales como su velocidad máxima de datos, el número de flujos elementales de vídeo y audio contribuyentes, información de temporización adicional u otra información. Un decodificador puede utilizar la información contenida en una cabecera del sistema para determinar si el decodificador es o no capaz de decodificar el flujo del programa.

[0041] El multiplexor 30 puede utilizar un flujo de transporte para la entrega simultánea de una pluralidad de programas por canales potencialmente propensos a error. Un flujo de transporte es un multiplex diseñado para aplicaciones de múltiples programas, tales como la difusión, de manera que un solo flujo de transporte pueda asimilar muchos programas independientes. Un flujo de transporte puede comprender una sucesión de paquetes de transporte, siendo cada uno de los paquetes de transporte de 188 octetos de longitud. El uso de paquetes cortos de longitud fija hace que el flujo de transporte sea menos susceptible a errores que el flujo del programa. Además, cada paquete de transporte de 188 octetos de largo puede recibir protección adicional ante errores, procesando el paquete a través de un proceso estándar de protección de errores, tal como la codificación de Reed-Solomon. La mejora de la resistencia a errores del flujo de transporte significa que tiene una mejor oportunidad de sobrevivir a los canales propensos a errores que se encuentran en un entorno de difusión, por ejemplo.

[0042] Podría parecer que el flujo de transporte es mejor que un flujo de programa debido a su mayor capacidad de resistencia ante errores y su capacidad de llevar muchos programas simultáneos. Sin embargo, el flujo de transporte es un multiplex más sofisticado que el flujo del programa y, en consecuencia, es más difícil de crear y más complicado de demultiplexar que un flujo de programas. El primer octeto de un paquete de transporte puede ser un octeto de sincronización que tiene un valor de 0x47 (hexadecimal 47, binario '01000111', decimal 71). Un único flujo de transporte puede llevar muchos programas diferentes, comprendiendo cada programa muchos flujos elementales empaquetados. El multiplexor 30 puede utilizar un campo de identificador de paquete (PID) de trece bits para distinguir los paquetes de transporte que contienen los datos de un flujo elemental de los que transportan los datos de otros flujos elementales. Es responsabilidad del multiplexor garantizar que cada flujo elemental reciba un valor único del PID. El último octeto de un paquete de transporte puede ser el campo de recuento de continuidad. El multiplexor 30 incrementa el valor del campo de recuento de continuidad entre sucesivos paquetes de transporte pertenecientes al mismo flujo elemental. Esto permite que un decodificador u otra unidad de un dispositivo de destino, tal como el dispositivo de destino de A / V 40, detecte la pérdida o ganancia de un paquete de transporte y oculte, eventualmente, los errores que de otro modo podrían resultar de tal suceso.

[0043] El multiplexor 30 recibe paquetes PES para flujos elementales de un programa desde el codificador de audio 26 y el codificador de vídeo 28, y forma unidades correspondientes de la capa de abstracción de red (NAL) a partir de los paquetes PES. En el ejemplo de la H.264/AVC (Codificación Avanzada de Vídeo), los segmentos de vídeo codificados están organizados en unidades de NAL, que proporcionan una representación de vídeo "amigable con las redes" que aborda aplicaciones tales como la telefonía, el almacenamiento, la difusión o la transmisión por flujo del vídeo. Las unidades de NAL pueden categorizarse en unidades de NAL de la capa de codificación de vídeo (VCL) y unidades de NAL no de la VCL. Las unidades de VCL contienen el motor de compresión del núcleo y pueden comprender los niveles de bloque, macrobloque y / o fragmento. Otras unidades de NAL son unidades de NAL no de la VCL.

[0044] El multiplexor 30 puede formar unidades de NAL que comprenden una cabecera que identifica un programa al cual pertenece la NAL, así como una carga útil, por ejemplo, datos de audio, datos de vídeo o datos que describen el flujo de transporte o de programa al cual corresponde la unidad de NAL. Por ejemplo, en la norma H.264/AVC, una unidad de NAL incluye una cabecera de 1 octeto y una carga útil de tamaños variables. En un ejemplo, una cabecera de unidad de NAL comprende un elemento id_prioridad, un elemento id_temporal, un elemento indicador_img_ancla, un elemento id_vista, un elemento indicador_no_idr y un elemento indicador_entre_vistas. En la MVC convencional, se conserva la unidad de NAL definida por la norma H.264, excepto para las unidades de NAL de prefijo y las unidades de NAL de fragmento codificado mediante la MVC, que incluyen una cabecera de unidad de NAL de la MVC de 4 octetos y la carga útil de la unidad de NAL.

[0045] El elemento id_prioridad de una cabecera de NAL se puede utilizar para un proceso sencillo de adaptación de flujo de bits de un trayecto. El elemento id_temporal puede usarse para especificar el nivel temporal de la unidad de NAL correspondiente, donde diferentes niveles temporales corresponden a diferentes velocidades de tramas.

[0046] El elemento indicador_img_ancla puede indicar si una imagen es una imagen anclada o no anclada. Las imágenes ancladas y todas las imágenes que suceden a estas en el orden de salida (es decir, el orden de visualización) se pueden decodificar correctamente sin decodificar las imágenes anteriores en el orden de decodificación (es decir, el orden del flujo de bits) y, por lo tanto, pueden utilizarse como puntos de acceso aleatorio.

5

10

15

20

25

30

35

40

45

50

55

60

65

Las imágenes ancladas y las imágenes no ancladas pueden tener dependencias diferentes, ambas señalizadas en el conjunto de parámetros de secuencia. Otros indicadores serán expuestos y usados en las siguientes secciones de este capítulo. Una imagen de anclaje de ese tipo también puede denominarse punto de acceso de GOP (Grupo de imágenes) abierto, mientras que un punto de acceso de GOP cercano también tiene soporte cuando el elemento indicador_no_idr es igual a cero. El elemento indicador_no_idr indica si una imagen es una imagen de actualización instantánea de decodificador (IDR) o de IDR de vista (V-IDR). En general, una imagen de IDR y todas las imágenes que la suceden en orden de salida u orden de flujo de bits, se pueden decodificar correctamente sin la decodificación de imágenes anteriores, ya sea en orden de decodificación o en orden de visualización.

[0047] El elemento id_vista puede comprender información sintáctica que se puede utilizar para identificar una vista, que puede ser utilizada para la interactividad de datos dentro de un decodificador de la MVC, por ejemplo, para la predicción entre vistas, y fuera de un decodificador, por ejemplo, para la representación. El elemento indicador_entre_vistas puede especificar si la correspondiente unidad de NAL es utilizada por otras vistas para la predicción entre vistas. Para transmitir la información de cabecera de la unidad de NAL de 4 octetos para una vista base, que puede ser compatible con la AVC, se define una unidad de NAL de prefijo en la MVC. En el contexto de la MVC, la unidad de acceso de vista base incluye las unidades de NAL de la VCL de la instancia temporal actual de la vista, así como su unidad de NAL de prefijo, que contiene sólo la cabeza de la unidad de NAL. Un decodificador de H.264 / AVC puede ignorar la unidad de prefijo de NAL.

[0048] Una unidad de NAL que incluye datos de vídeo en su carga útil puede comprender diversos niveles de granularidad de datos de vídeo. Por ejemplo, una unidad de NAL puede comprender un bloque de datos de vídeo, un macrobloque, una pluralidad de macrobloques, un fragmento de datos de vídeo o una trama completa de datos de vídeo. El multiplexor 30 puede recibir datos de vídeo codificados desde el codificador de vídeo 28 en forma de paquetes PES de flujos elementales. El multiplexor 30 puede asociar cada flujo elemental con un programa correspondiente mediante la correlación de los id_flujo a los programas correspondientes, por ejemplo, en una base de datos u otra estructura de datos, tal como una Tabla de Mapas de Programa (PMT) o un Mapa de Flujos de Programa (PSM).

[0049] El multiplexor 30 también puede ensamblar unidades de acceso a partir de una pluralidad de unidades de NAL. En general, una unidad de acceso puede comprender una o más unidades de NAL para representar una trama de datos de vídeo, así como datos de audio correspondientes a la trama cuando dichos datos de audio estén disponibles. Una unidad de acceso generalmente incluye todas las unidades de NAL para un instante de salida, por ejemplo, todos los datos de audio y vídeo para un instante. Por ejemplo, si cada vista tiene una velocidad de tramas de 20 tramas por segundo (fps), entonces cada instante puede corresponder a un intervalo de tiempo de 0,05 segundos. Durante este intervalo de tiempo, las tramas específicas para todas las vistas de la misma unidad de acceso (el mismo instante) se pueden representar simultáneamente. En un ejemplo correspondiente a la H.264 / AVC, una unidad de acceso puede comprender una imagen codificada en un instante, que puede presentarse como una imagen codificada primaria. Por consiguiente, una unidad de acceso puede comprender todas las tramas de audio y vídeo de una instancia temporal común, por ejemplo, todas las vistas correspondientes al momento X. Esta divulgación también se refiere a una imagen codificada de una vista particular como un "componente de vista". Es decir, un componente de vista puede comprender una imagen (o trama) codificada para una vista particular en un momento particular. Por consiguiente, se puede definir que una unidad de acceso comprenda todos los componentes de vista de una instancia temporal común. El orden de decodificación de las unidades de acceso puede no ser idéntico al orden de salida o de visualización.

[0050] El multiplexor 30 también puede integrar datos relativos a un programa en una unidad de NAL. Por ejemplo, el multiplexor 30 puede crear una unidad de NAL que comprende una Tabla de Mapas de Programa (PMT) o un Mapa de Flujos de Programa (PSM). En general, una PMT se utiliza para describir un flujo de transporte, mientras que un PSM se utiliza para describir un flujo de programas. Como se describe con mayor detalle con respecto al ejemplo de la FIG. 2, el multiplexor 30 puede comprender o interactuar con una unidad de almacenamiento de datos que asocia flujos elementales recibidos desde el codificador de audio 26 y el codificador de vídeo 28 con programas y, en consecuencia, con respectivos flujos de transporte y / o flujos de programas.

[0051] Como ocurre con la mayoría de las normas de codificación de vídeo, la norma H.264/AVC define la sintaxis, la semántica y el proceso de decodificación para flujos de bits libres de errores, cualquiera de los cuales se ajusta a un cierto perfil o nivel. La norma H.264/AVC no especifica el codificador, pero el codificador tiene la tarea de garantizar que los flujos de bits generados sean compatibles con la norma para un descodificador. En el contexto de normas de codificación de vídeo, un "perfil" corresponde a un subconjunto de algoritmos, características o herramientas y restricciones que se les aplican. Como se define en la norma H.264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits que está especificada por la norma H.264. Un "nivel" corresponde a las limitaciones del consumo de recursos del decodificador, tales como, por ejemplo, la memoria y el cálculo del decodificador, que están relacionadas con la resolución de las imágenes, la velocidad de bits y la velocidad de procesamiento de los macrobloques (MB).

[0052] El estándar H.264, por ejemplo, reconoce que, dentro de los límites impuestos por la sintaxis de un perfil dado, todavía es posible requerir una gran variación en el rendimiento de los codificadores y decodificadores, según

5

10

15

20

25

30

35

40

45

50

55

60

65

los valores tomados por los elementos sintácticos en el flujo de bits, tales como el tamaño especificado de las imágenes decodificadas. La norma H.264 reconoce además que, en muchas aplicaciones, no es ni práctico ni económico implementar un decodificador capaz de tratar todos los usos hipotéticos de la sintaxis dentro de un perfil particular. En consecuencia, el estándar H.264 define un "nivel" como un conjunto especificado de restricciones impuestas a los valores de los elementos sintácticos en el flujo de bits. Estas restricciones pueden ser simples limitaciones de valores. Como alternativa, estas restricciones pueden tomar la forma de restricciones sobre combinaciones aritméticas de valores (por ejemplo, el ancho de imagen multiplicado por la altura de imagen multiplicada por el número de imágenes decodificadas por segundo). El estándar H.264 provee además que implementaciones individuales puedan dar soporte a un nivel diferente para cada perfil con soporte.

[0053] Un decodificador conforme a un perfil normalmente da soporte a todas las características definidas en el perfil. Por ejemplo, como una característica de codificación, la codificación de imágenes B no tiene soporte en el perfil de línea de base de la H.264 / AVC, pero tiene soporte en otros perfiles de la H.264 / AVC. Un decodificador conforme a un nivel debería ser capaz de decodificar cualquier flujo de bits que no requiera recursos más allá de las limitaciones definidas en el nivel. Las definiciones de perfiles y niveles pueden ser útiles para la interpretabilidad. Por ejemplo, durante la transmisión de vídeo, se pueden negociar y acordar un par de definiciones de perfil y nivel para una sesión de transmisión completa. Más específicamente, en la H.264 / AVC, un nivel puede definir, por ejemplo, limitaciones en el número de macrobloques que necesitan ser procesados, el tamaño del almacenamiento intermedio de imágenes decodificadas (DPB), el tamaño del almacenamiento intermedio de imágenes codificadas (CPB), el rango vectorial de movimiento vertical, el número máximo de vectores de movimiento por dos MB consecutivos y si un bloque B puede tener particiones de sub-macrobloque inferiores a 8x8 píxeles. De esta manera, un decodificador puede determinar si el decodificador es capaz de decodificar adecuadamente el flujo de bits.

[0054] Los conjuntos de parámetros contienen información de cabecera de capa de secuencia en conjuntos de parámetros de secuencia (SPS), e información de cabecera de capa de imagen que cambia raramente en conjuntos de parámetros de imagen (PPS). Con los conjuntos de parámetros, esta información que cambia raramente no necesita repetirse para cada secuencia o imagen, de ahí que pueda mejorar la eficacia de codificación. Además, el uso de conjuntos de parámetros puede permitir la transmisión fuera de banda de la información de cabecera, evitando la necesidad de transmisiones redundantes para lograr resistencia frente a errores. En la transmisión fuera de banda, las unidades de NAL de conjuntos de parámetros se transmiten por un canal diferente al de las otras unidades de NAL.

[0055] El estándar de los sistemas de MPEG-2 admite extensiones del sistema a modo de "descriptores". Tanto las PMT como los PSM incluyen bucles de descriptor en los cuales uno o más descriptores pueden ser insertados. En general, un descriptor puede comprender una estructura de datos que se puede utilizar para extender la definición de programas y / o elementos de programa. Esta divulgación describe un descriptor de punto de operación para realizar las técnicas de esta divulgación. En general, el descriptor de punto de operación de esta divulgación mejora el descriptor convencional de extensión de la MVC, describiendo una capacidad de representación, una capacidad de decodificación y una velocidad de bits para un punto de operación. Un dispositivo de destino, tal como el dispositivo de destino de A / V 40, puede utilizar descriptores de punto de operación para cada punto de operación, para seleccionar uno de los puntos de operación de un flujo de bits a decodificar.

[0056] Cada PMT o PSM puede incluir un descriptor de punto de operación que describe características de un punto de operación. Por ejemplo, el dispositivo de origen 20 puede proporcionar el descriptor de punto de operación para proporcionar un valor de capacidad de representación que describe una capacidad de representación para el dispositivo cliente 40. Para que el dispositivo cliente 40 pueda representar adecuadamente (por ejemplo, exhibir) datos de vídeo del punto de operación, el dispositivo cliente 40 debería satisfacer las capacidades de representación señalizadas por el valor de capacidad de representación. El valor de capacidad de representación puede describir, por ejemplo, un número de vistas a exhibir (por ejemplo, un número de vistas destinadas para representación) y / o la velocidad de tramas de los datos de vídeo para las vistas. De este modo, el dispositivo cliente 40 puede determinar que las capacidades de representación se satisfacen cuando la salida de vídeo 44 del dispositivo cliente 40 es capaz de exhibir el número de vistas del punto de operación a la velocidad de tramas especificada por el descriptor de punto de operación.

[0057] En los ejemplos en los que el dispositivo de origen 20 transmite un flujo de bits de MVC usando protocolos de multidifusión o difusión, el dispositivo de origen 20 puede empaquetar todo el flujo de bits de MVC en flujos de transporte, que pueden ser recibidos por dispositivos clientes que tienen diversas capacidades de representación. Por ejemplo, algunos programas tridimensionales pueden tener diferentes números de vistas (por ejemplo, dos vistas, cuatro vistas, seis vistas u ocho vistas) y varios dispositivos pueden ser capaces de utilizar entre uno y cuatro pares de vistas. De este modo, cada dispositivo cliente puede determinar qué punto de operación utilizar sobre la base del número de vistas con soporte que puede ser exhibido por el dispositivo cliente. Por ejemplo, el dispositivo cliente 40 puede determinar cuál de los puntos de operación utilizar determinando un número de vistas que pueden ser exhibidas por la salida de vídeo 44 y una velocidad de tramas en la que la salida de vídeo 44 es capaz de exhibir datos de vídeo y determinar cuáles de los puntos de operación deberían utilizarse puntos basándose en las capacidades de representación de la salida de vídeo 44.

5

10

15

20

25

30

35

40

45

50

55

60

65

[0058] En ejemplos en los que el dispositivo de origen transmite un flujo de bits de MVC usando un protocolo de unidifusión, el dispositivo cliente 40 puede establecer una sesión correspondiente a un programa con un número aceptable de vistas, comprobando la capacidad de representación especificada en los correspondientes descriptores de punto de operación. De manera similar, en los ejemplos en los que el flujo de bits de MVC está codificado en un medio de almacenamiento legible por ordenador para su reproducción local, el dispositivo cliente 40 puede seleccionar un programa adecuado comprobando la capacidad de representación especificada en los descriptores de punto de operación de las PMT o los PSM.

[0059] El dispositivo de origen 20 también puede proporcionar un valor de las capacidades de decodificación en un descriptor de punto de operación. El número de vistas a decodificar puede no ser necesariamente el mismo que el número de vistas a exhibir. Por lo tanto, el descriptor de punto de operación puede señalizar por separado el número de vistas a exhibir y el número de vistas a decodificar para el punto de operación. Además, el descriptor de punto de operación puede identificar específicamente las vistas correspondientes al punto de operación. Ciertos dispositivos clientes pueden preferir vistas particulares para diversos propósitos, por ejemplo, basándose en el ángulo de visión. Por consiguiente, el dispositivo cliente 40 puede estar configurado para seleccionar un punto de operación basándose en qué vistas están disponibles en el punto de operación.

[0060] En algunos ejemplos, las capacidades de decodificación señalizadas en el punto de operación puede especificar, adicional o alternativamente, un perfil y un nivel a los que corresponde el punto de operación. En los ejemplos en los que el dispositivo de origen 20 transmite el flujo de bits utilizando protocolos de multidifusión o de difusión, varios dispositivos clientes con diferentes capacidades de decodificación pueden recibir el flujo de bits. Por ejemplo, algunos descodificadores sólo podrían ser capaces de decodificar dos vistas con 30 fps, mientras que algunos podrían ser capaces de decodificar cuatro vistas con 60 fps. En los ejemplos en los que el dispositivo de origen 20 transmite el flujo de bits utilizando un protocolo de unidifusión, el dispositivo cliente 40 puede establecer una sesión adecuada (para un programa tridimensional específico) después de comprobar la capacidad de decodificación especificada en los descriptores en las PMT. De manera similar, para la reproducción local, el dispositivo cliente 40 puede seleccionar un programa adecuado comprobando la capacidad de decodificación especificada en los descriptores de punto de operación de las PMT o los PSM.

[0061] El dispositivo de origen 20 puede además señalizar información de velocidad de bits en el descriptor de punto de operación. La información de velocidad binaria puede describir una entre la velocidad media de bits y la velocidad máxima de bits, o ambas, para el punto de operación. Por ejemplo, cuando el dispositivo de origen 20 transmite el flujo de bits utilizando un protocolo de unidifusión, el canal utilizado para transmitir el flujo de bits puede estar limitado en términos de ancho de banda. Por consiguiente, el dispositivo cliente 40 puede seleccionar un punto de operación que tenga una velocidad de bits máxima o media tolerable para el canal de comunicación.

[0062] En algunos ejemplos, el dispositivo de origen 20 puede especificar adicionalmente la velocidad de tramas del punto de operación en el descriptor de punto de operación. Ciertas vistas del punto de operación pueden tener velocidades de tramas que no coinciden con la velocidad de tramas del punto de operación. De este modo, el dispositivo cliente 40 puede determinar la velocidad de tramas del punto de funcionamiento y la velocidad de tramas de dicha vista para facilitar el proceso de reensamblaje de los datos de vídeo decodificados, con el fin de exhibir los datos de vídeo. En varios ejemplos, cuando las velocidades de tramas de dos puntos de operación no coinciden, el dispositivo cliente 40 puede descartar tramas de las vistas del punto de operación que tenga la velocidad de tramas más alta o interpolar tramas desde vistas del punto de operación que tenga la velocidad de tramas inferior.

[0063] Habitualmente, un flujo elemental incluye los indicadores "ninguna_unidad_de_nal_de_sei_presente" y "ninguna_unidad_de_nal_de_prefijo_presente" que describen, respectivamente, si el flujo elemental incluye mensajes de SEI y unidades de NAL de prefijo. Esta divulgación propone que los dispositivos clientes, tales como el dispositivo cliente 40, deduzcan si los mensajes de SEI y / o las unidades de NAL de prefijo están presentes dentro de un punto de operación, en lugar de señalizar explícitamente estos valores para el punto de operación. Para determinar si los mensajes de SEI están presentes en un punto de operación, el dispositivo cliente 40 puede determinar si el valor máximo de los valores de ninguna_unidad_de_nal_de_sei_presente de los flujos elementales para el punto de operación es igual a uno. De forma similar, para determinar si las unidades de NAL de prefijo están presentes en el punto de operación, el dispositivo cliente 40 puede determinar si el valor máximo de los valores de ninguna_unidad_de_nal_de_prefijo_presente de los flujos elementales para el punto de operación es igual a uno.

[0064] Los ejemplos expuestos anteriormente se han centrado en los descriptores de punto de operación incluidos para cada punto de funcionamiento de un flujo de bits de MVC. Como una alternativa, el dispositivo de origen 20 puede proporcionar descriptores de extensión de MVC que señalicen datos similares. Por ejemplo, el dispositivo de origen 20 puede asociar más de un descriptor de extensión de MVC con un sub-flujo de bits de vídeo de MVC que corresponde a un flujo elemental. El dispositivo de origen 20 puede especificar, en el descriptor de extensión de MVC para un sub-flujo de bits, una velocidad de tramas, un subconjunto de los id_vista de las vistas a exhibir y un número de vistas a decodificar. El dispositivo de origen 20 puede indicar además una correlación entre los descriptores de extensión de MVC y el punto de operación correspondiente.

[0065] Los estándares de compresión vídeo, tales como ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2 y H.264 /

5

10

15

20

25

30

35

40

45

50

55

60

65

MPEG-4 parte 10, hacen uso de la predicción temporal compensada por movimiento para reducir la redundancia temporal. El codificador utiliza una predicción compensada por movimiento de algunas imágenes previamente codificadas (también mencionadas aquí como tramas) para predecir las imágenes codificadas actuales de acuerdo a los vectores de movimiento. Existen tres tipos de imagen principales en la codificación de vídeo típica. Se trata de imágenes intra-codificadas ("imágenes-I" o "tramas-I"), imágenes predichas ("imágenes-P" o "tramas-P") e imágenes predichas bidireccionales ("imágenes-B" o "tramas-B"). Las imágenes-P utilizan sólo la imagen de referencia antes de la imagen actual en orden temporal. En una imagen-B, cada bloque de la imagen-B puede predecirse a partir de una o dos imágenes de referencia. Estas imágenes de referencia podrían situarse antes o después de la imagen actual en orden temporal.

[0066] De acuerdo al estándar de codificación H.264, como un ejemplo, las imágenes-B usan dos listas de imágenes de referencia codificadas previamente, la lista 0 y la lista 1. Estas dos listas pueden contener imágenes codificadas pasadas y / o futuras en orden temporal. Los bloques en una imagen-B se pueden predecir de una entre varias maneras: predicción compensada por movimiento de una imagen de referencia de lista 0, predicción compensada por movimiento de una imagen de referencia de lista 1 o predicción compensada por movimiento de la combinación de imágenes de referencia de ambas listas, lista 0 y lista 1. Para obtener la combinación de las imágenes de referencia, tanto de la lista 0 como de la lista 1, se obtienen dos áreas de referencia compensadas por movimiento de imágenes de referencia de la lista 0 y de la lista 1, respectivamente. Su combinación se utilizará para predecir el bloque actual.

[0067] La norma ITU-T H.264 presta soporte a la intra-predicción en varios tamaños de bloque, tales como 16 por 16, 8 por 8 o 4 por 4 para componentes de luma, y 8x8 para componentes de croma, así como a la inter-predicción en varios tamaños de bloque, tales como 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 y 4x4 para componentes de luma y los correspondientes tamaños ajustados a escala para componentes de croma. En la presente divulgación, "x" y "por" pueden utilizarse indistintamente para hacer referencia a las dimensiones de píxeles del bloque en términos de las dimensiones vertical y horizontal, por ejemplo, 16x16 píxeles o 16 por 16 píxeles. En general, un bloque de tamaño 16x16 tendrá 16 píxeles en una dirección vertical (y = 16) y 16 píxeles en una dirección horizontal (x = 16). Asimismo, un bloque de tamaño NxN tiene, en general, N píxeles en una dirección vertical y N píxeles en una dirección horizontal, donde N representa un valor entero no negativo. Los píxeles en un bloque pueden estar dispuestos en filas y columnas.

[0068] Los tamaños de bloque que son inferiores a 16 por 16 pueden denominarse divisiones de un macrobloque de 16 por 16. Los bloques de vídeo pueden comprender bloques de datos de píxeles en el dominio de píxeles, o bloques de coeficientes de transformación en el dominio de transformación, por ejemplo, tras la aplicación de una transformación, tal como una transformación discreta del coseno (DCT), una transformación de números enteros, una transformación de ondículas o una transformación conceptualmente similar a los datos residuales de bloques de vídeo que representan diferencias de píxeles entre bloques de vídeo codificados y bloques de vídeo predictivos. En algunos casos, un bloque de vídeo puede comprender bloques de coeficientes de transformación cuantizados en el dominio de transformación.

[0069] Los bloques de vídeo más pequeños pueden proporcionar una mejor resolución y pueden usarse en ubicaciones de una trama de vídeo que incluyen altos niveles de detalle. En general, los macrobloques y las diversas divisiones, denominadas en ocasiones sub-bloques, pueden considerarse bloques de vídeo. Además, un fragmento puede considerarse una pluralidad de bloques de vídeo, tales como macrobloques y/o sub-bloques. Cada fragmento puede ser una unidad independientemente decodificable de una trama de vídeo. De forma alternativa, las propias tramas pueden ser unidades decodificables, o pueden definirse otras partes de una trama como unidades decodificables. El término «unidad codificada» o "unidad de codificación" puede referirse a cualquier unidad independientemente decodificable de una trama de vídeo, tal como una trama completa, un fragmento de una trama, un grupo de imágenes (GOP), denominado también secuencia, u otra unidad independientemente decodificable definida de acuerdo a técnicas de codificación aplicables.

[0070] El término macrobloque se refiere a una estructura de datos para la codificación de datos de imagen y / o vídeo de acuerdo a una formación bidimensional de píxeles que comprende 16x16 píxeles. Cada píxel comprende un componente de crominancia y un componente de luminancia. En consecuencia, el macrobloque puede definir cuatro bloques de luminancia, cada uno de los cuales comprende una formación bidimensional de 8x8 píxeles, dos bloques de crominancia, cada uno de los cuales comprende una formación bidimensional de 16x16 píxeles, y una cabecera que comprende información sintáctica, tal como un patrón de bloque codificado (CBP), una modalidad de codificación (por ejemplo, modalidades de codificación intra- (I) o inter- (P o B)), un tamaño de partición para particiones de un bloque intra-codificado (por ejemplo, 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 o 4x4), o uno o más vectores de movimiento para un macrobloque inter-codificado.

[0071] El codificador de vídeo 28, el decodificador de vídeo 48, el codificador de audio 26, el decodificador de audio 46, el multiplexor 30 y el demultiplexor 38 pueden implementarse, cada uno, como cualquiera entre una variedad de circuitos de codificador o decodificador adecuados, según corresponda, tal como uno o más microprocesadores, procesadores de señales digitales (DSP), circuitos integrados específicos de la aplicación (ASIC), formaciones de compuertas programables en el terreno (FPGA), circuitos de lógica discreta, software, hardware, firmware o

5

10

15

20

25

30

35

40

45

50

55

60

65

combinaciones cualesquiera de los mismos. Cada uno entre el codificador de vídeo 28 y el decodificador de vídeo 48 puede incluirse en uno o más codificadores o descodificadores, cualquiera de los cuales puede integrarse como parte de un codificador/decodificador (CÓDEC) de vídeo combinado. Asimismo, cada uno entre el codificador de audio 26 y el decodificador de audio 46 puede incluirse en uno o más codificadores o decodificadores, cualquiera de los cuales puede integrarse como parte de un codificador/decodificador (CÓDEC) combinado. Un aparato que incluye un codificador de vídeo 28, un decodificador de vídeo 48, un codificador de audio 26, un decodificador de audio 46, un multiplexor 30 y / o un demultiplexor 38 puede comprender un circuito integrado, un microprocesador y/o un dispositivo de comunicación inalámbrica, tal como un teléfono celular.

[0072] Las técnicas de la presente divulgación pueden ofrecer ciertas ventajas sobre las técnicas convencionales para los sub-flujos de bits de MVC, que no proporcionan las características de señalización de puntos de operación. Cada sub-flujo de bits puede incluir una o más vistas del flujo de bits correspondiente. En algunos casos, un punto de operación puede corresponder a vistas de diferentes flujos de bits. Las técnicas de esta divulgación proporcionan un descriptor de punto de operación que identifica las vistas del punto de operación correspondiente.

[0073] Después de que el multiplexor 30 ha ensamblado una unidad de NAL y / o una unidad de acceso a partir de los datos recibidos, el multiplexor 30 pasa la unidad a la interfaz de salida 32 para su salida. La interfaz de salida 32 puede comprender, por ejemplo, un transmisor, un transceptor, un dispositivo para escribir datos en un medio legible por ordenador tal como, por ejemplo, una unidad óptica, una unidad de medios magnéticos (por ejemplo, una unidad de disquete), un bus en serie universal (USB), una interfaz de red u otra interfaz de salida. La interfaz de salida 32 emite la unidad de NAL o la unidad de acceso a un medio legible por ordenador 34, tal como, por ejemplo, una señal de transmisión, un medio magnético, un medio óptico, una memoria, una unidad de memoria flash u otro medio legible por ordenador.

[0074] En última instancia, la interfaz de entrada 36 recupera los datos del medio legible por ordenador 34. La interfaz de entrada 36 puede comprender, por ejemplo, una unidad óptica, una unidad de medios magnéticos, un puerto de USB, un receptor, un transceptor u otra interfaz de medio legible por ordenador. La interfaz de entrada 36 puede proporcionar la unidad de NAL o la unidad de acceso al demultiplexor 38. El demultiplexor 38 puede demultiplexar un flujo de transporte o un flujo de programas en flujos de PES constituyentes, desempaquetar los flujos de PES para recuperar datos codificados y enviar los datos codificados al decodificador de audio 46 o bien al decodificador de vídeo 48, en función de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, según lo indicado por las cabeceras de paquetes PES del flujo. El decodificador de audio 46 decodifica datos de audio codificados y envía los datos de audio decodificados a la salida de audio 42, mientras que el decodificador de vídeo 48 decodifica datos de vídeo codificados y envía los datos de vídeo decodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de vídeo 44. La salida de vídeo 44 puede comprender una pantalla que utiliza una pluralidad de vistas de una escena, por ejemplo, una presentación estereoscópica o auto-estereoscópica que presenta cada vista de una escena simultáneamente.

[0075] En particular, el demultiplexor 38 puede seleccionar un punto de funcionamiento de un flujo de bits recibido. Por ejemplo, el demultiplexor 38 puede comparar características de los puntos de operación del flujo de bits para seleccionar un punto de operación adecuado, a ser utilizado por el dispositivo de destino de A / V 40. En general, el demultiplexor 38 puede intentar seleccionar uno de los puntos de operación que proporcionará la experiencia de visualización de la más alta calidad para un usuario que pueda ser decodificada por el decodificador de vídeo 48. Por ejemplo, el demultiplexor 38 puede comparar las capacidades de representación y las capacidades de decodificación del decodificador de vídeo 48 con las capacidades sugeridas de representación y decodificación señalizadas por los descriptores de punto de operación del flujo de bits. De los puntos de operación que el demultiplexor 38 determina que podrían ser decodificados adecuadamente por el decodificador de vídeo 48, el demultiplexor 38 puede seleccionar un punto de operación que proporcionará los datos de vídeo de la más alta calidad, por ejemplo, la velocidad de tramas y / o velocidad de bits más alta. En otros ejemplos, el demultiplexor 38 puede seleccionar uno de los puntos de operación con soporte basándose en otras consideraciones, tales como, por ejemplo, el consumo de energía.

[0076] La FIG. 2 es un diagrama de bloques que ilustra una disposición ejemplar de componentes del multiplexor 30 (FIG. 1). En el ejemplo de la FIG. 2, el multiplexor 30 incluye la unidad de gestión de flujo 60, la interfaz de entrada de vídeo 80, la interfaz de entrada de audio 82, la interfaz de salida de flujo multiplexado 84 y las tablas de información específicas del programa 88. La unidad de gestión de flujo 60 incluye el constructor 62 de unidad de NAL, el constructor de PMT 64, la unidad de búsqueda de identificador de flujo (Identificador de flujo) 66 y la unidad de asignación de identificador de programa (PID) 68.

[0077] En el ejemplo de la FIG. 2, la interfaz de entrada de vídeo 80 y la interfaz de entrada de audio 82 incluyen empaquetadores respectivos para formar unidades de PES a partir de datos de vídeo codificados y datos de audio codificados. En otros ejemplos, se pueden incluir empaquetadores de vídeo y / o audio en una unidad o módulo que es externo al multiplexor 30. Con respecto al ejemplo de la FIG. 2, la interfaz de entrada de vídeo 80 puede formar paquetes PES a partir de datos de vídeo codificados recibidos desde el codificador de vídeo 28 y la interfaz de entrada de audio 82 puede formar paquetes PES a partir de datos de audio codificados recibidos desde el codificador de audio 26.

5

10

15

20

25

30

35

40

45

50

55

60

65

[0078] La unidad de gestión de flujo 60 recibe paquetes PES desde la interfaz de entrada de vídeo 80 y la interfaz de entrada de audio 82. Cada paquete PES incluye un Identificador de flujo que identifica el flujo elemental al que pertenece el paquete PES. La unidad de búsqueda de Identificador de flujo 66 puede determinar un programa al que corresponde el paquete PES consultando tablas de información específicas del programa 88. Es decir, la unidad de búsqueda de Identificador de flujo 66 puede determinar a qué programa corresponde un paquete PES recibido. Cada programa puede comprender una pluralidad de flujos elementales, mientras que, en general, un flujo elemental corresponde a sólo un programa. Sin embargo, en algunos ejemplos, puede incluirse un flujo elemental en una pluralidad de programas. Cada paquete PES puede estar incluido en una pluralidad de flujos emitidos desde el multiplexor 30, ya que varios servicios pueden incluir, cada uno, varios subconjuntos de flujos de audio y vídeo disponibles. Por consiguiente, la unidad de búsqueda de Identificador de flujo 66 puede determinar si un paquete PES debería incluirse en uno o más flujos de salida (por ejemplo, uno o más flujos de transporte o de programa) y, en particular, en cuál de los flujos de salida se incluye el paquete PES.

[0079] En un ejemplo, cada flujo elemental corresponde a un programa. El multiplexor 30 puede ser responsable de asegurar que cada flujo elemental esté asociado a un programa particular y, en consecuencia, a un Identificador de programa (PID). Cuando se recibe un paquete PES que incluye un Identificador de flujo que no es reconocido por el multiplexor 30 (por ejemplo, un Identificador de flujo no almacenado en las tablas de información específicas del programa 88), la unidad de asignación de PID 68 crea una o más entradas nuevas en las tablas de información específicas del programa 88, para asociar el nuevo Identificador de flujo con un PID no utilizado.

[0080] Después de la determinación de un programa al que corresponde un paquete PES, el constructor de unidades de NAL 62 forma una unidad de NAL que comprende el paquete PES, por ejemplo, mediante la encapsulación del paquete PES con una cabecera de unidad de NAL, incluyendo el PID del programa al que corresponde el Identificador de flujo del paquete PES. En algunos ejemplos, el constructor de unidades de NAL 62, u otra sub-unidad de la unidad de gestión de flujos 60, pueden formar una unidad de acceso que comprende una pluralidad de unidades de NAL.

[0081] El constructor de PMT 64 crea las tablas de mapas de programa (PMT) para un flujo de salida correspondiente del multiplexor 30 utilizando información de las tablas de información específica del programa 88. En otro ejemplo, la unidad de gestión de flujos 60 puede comprender un constructor de PSM para crear mapas de flujos de programas para un flujo de programa emitido por el multiplexor 30. En algunos ejemplos, el multiplexor 30 puede comprender tanto el constructor de PMT 64 como un constructor de PSM, y emitir uno entre un flujo de transporte y un flujo de programas, o ambos. En el ejemplo de la FIG. 2, el constructor de PMT 64 puede construir una PMT que incluye los nuevos descriptores descritos por esta divulgación, por ejemplo, un descriptor de punto de operación, así como cualquier otro descriptor y datos de PMT necesarios para la PMT. El constructor de PMT 64, periódicamente, puede, por ejemplo, después de un cierto período de tiempo o después de que se ha transmitido una cierta cantidad de datos, enviar una PMT posterior para el flujo de transporte. El constructor de PMT 64 puede pasar las PMT creadas al constructor de unidades de NAL 62 para formar una unidad de NAL que comprende la PMT, por ejemplo, encapsulando la PMT con una correspondiente cabecera de unidad de NAL, que incluye el PID correspondiente.

[0082] El constructor de PMT 64 puede crear una estructura de datos, tal como un descriptor de punto de operación, para cada punto de operación de un programa. La estructura de datos creada por el constructor de PMT 64 puede indicar un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para utilizar el punto de operación, un valor de capacidad de decodificación que describe una capacidad de decodificación que el dispositivo receptor debe satisfacer para usar el punto de operación y un valor de velocidad de bits que describe una velocidad de bits del punto de operación.

[0083] Por ejemplo, el constructor de PMT 64 puede determinar un número de vistas a exhibir para un punto de operación y una velocidad de tramas para las vistas del punto de operación, basándose en la información almacenada por las tablas de información específica del programa 88 o en la información recibida desde el codificador de vídeo 28 a través de la interfaz de entrada de vídeo 80. El constructor de PMT 64 puede señalizar uno entre el número de vistas y la velocidad de tramas, o ambos, para las vistas del punto de operación usando el valor de capacidad de representación de la estructura de datos.

[0084] El constructor de PMT 64 también puede determinar un número de vistas a decodificar para el punto de operación y un valor de nivel para un perfil al que corresponden las vistas del punto de operación. Por ejemplo, el constructor de PMT 64 puede determinar un número de macrobloques que necesitan ser procesados, un tamaño de almacenamiento intermedio de imágenes decodificadas, un tamaño de almacenamiento intermedio de imágenes codificadas, un rango vectorial de movimiento vertical, un número máximo de vectores de movimiento por cada dos macrobloques consecutivos y / o si un bloque-B puede tener particiones de macrobloques inferiores a 8x8 píxeles, y usar estas determinaciones para determinar el nivel para el punto de operación. El constructor de PMT 64 puede recibir esta información desde el codificador de vídeo 28 a través de la interfaz de entrada de vídeo 80. El constructor de PMT 64 puede entonces representar el número de vistas a descodificar y / o el valor de nivel del perfil utilizando el valor de capacidad de decodificación para el punto de operación.

5

10

15

20

25

30

35

40

45

50

55

60

65

[0085] El constructor de PMT 64 puede determinar adicionalmente un valor de velocidad de bits para el punto de operación y codificar el valor de velocidad de bits en la estructura de datos. El valor de la velocidad de bits puede corresponder a una velocidad de bits media o a una velocidad de bits máxima para el punto de operación. El constructor de PMT 64 puede calcular la velocidad de bits para el punto de operación o recibir una indicación de la velocidad de bits desde el codificador de vídeo 28.

[0086] La interfaz de salida de flujo multiplexado 84 puede recibir una o más unidades de NAL y / o unidades de acceso desde la unidad de gestión de flujos 60, por ejemplo, unidades de NAL que comprenden paquetes PES (por ejemplo, datos de audio o de vídeo) y / o unidades NAL que comprenden una pMt. En algunos ejemplos, la interfaz de salida de flujo multiplexado 84 puede formar unidades de acceso desde una o más unidades de NAL correspondientes a una ubicación temporal común después de que las unidades de NAL son recibidas desde la unidad de gestión de flujos 60. La interfaz de salida de flujo multiplexado 84 transmite las unidades NAL o unidades de acceso como salida en un correspondiente flujo de transporte o flujo de programas. La interfaz de salida de flujo multiplexado 84 también puede recibir la estructura de datos desde el constructor de PMT 64 e incluir la estructura de datos como parte del flujo de bits.

[0087] La FIG. 3 es un diagrama de bloques que ilustra un conjunto ejemplar de tablas de información específica del programa 88. El flujo elemental al que pertenece un paquete de transporte puede determinarse en base al valor del PID del paquete de transporte. Para que un decodificador decodifique adecuadamente los datos recibidos, el decodificador necesita poder determinar qué flujos elementales pertenecen a cada programa. La información específica del programa, según lo incluido en la tabla de información específica del programa 88, puede especificar explícitamente las relaciones entre los programas y los flujos elementales de componentes. En el ejemplo de la FIG. 3, las tablas de información específica del programa 88 incluyen la tabla de información de red 100, la tabla de acceso condicional 102, la tabla de acceso de programas 104 y la tabla de mapas de programa 106. Para el ejemplo de la FIG. 3, se supone que el flujo de salida comprende un flujo de transporte de MPEG-2. En un ejemplo alternativo, el flujo de salida puede comprender un flujo de programa, en cuyo caso la tabla de mapas de programa 106 puede ser sustituida por un mapa de flujos de programa.

[0088] La especificación de sistemas de MPEG-2 especifica que cada programa transportado en un flujo de transporte tiene una tabla de mapas de programa, tal como la tabla de mapas de programa 106, asociada al mismo. La tabla de mapas de programas 106 puede incluir detalles sobre el programa y los flujos elementales que incluye el programa. Como un ejemplo, un programa, identificado como el programa número 3, puede contener un flujo elemental de vídeo con PID 33, un flujo de audio inglés con PID 57 y un flujo de audio chino con PID 60. Está permitido que una PMT incluya más de un programa.

[0089] La tabla básica de mapas de programa, especificada por la especificación de sistemas de MPEG-2, puede ser adornada con algunos de los muchos descriptores, por ejemplo, los descriptores 108, especificados dentro de la especificación de sistemas de MPEG-2. Los descriptores 108 pueden incluir cualquiera de, o todos, los descriptores especificados de la especificación de sistemas de MPEG-2. En general, los descriptores, tales como los descriptores 108, transmiten información adicional sobre un programa o sus flujos elementales o sub-flujos de bits componentes. Los descriptores pueden incluir parámetros de codificación de vídeo, parámetros de codificación de audio, identificación de idioma, información panorámica y de exploración, detalles de acceso condicional, información de copyright u otra información similar. Un difusor u otro usuario puede definir descriptores privados adicionales.

[0090] Esta divulgación proporciona un descriptor de punto de operación para describir características de un punto de operación en sistemas de MPEG-2 que conforman un flujo de bits. Los descriptores 108 pueden incluir descriptores de punto de operación para cada punto de operación del flujo de bits correspondiente. Como se muestra en la FIG. 3, los descriptores 108 incluyen descriptores de extensión de MVC 110, un descriptor de jerarquía 112 y descriptores de punto de operación 114. Cada uno de los descriptores de punto de operación 114 puede corresponder a un punto de operación particular de un flujo de bits y señalizar, para el punto de operación, un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para usar el punto de operación, un valor de capacidad de decodificación que describe una capacidad de decodificación que ha de satisfacer el dispositivo receptor para utilizar el punto de operación y un valor de velocidad de bits que describe una velocidad de bits del punto de operación. En los flujos elementales de componentes relacionados con vídeo, también hay un descriptor de jerarquía, que proporciona información para identificar los elementos de programa que contienen componentes de vídeo, audio y flujos privados jerárquicamente codificados.

[0091] La Tabla 1 a continuación proporciona un ejemplo de datos incluidos en los descriptores de extensión de MVC 110. Los diversos campos y profundidades de bits de los campos, mostrados en la Tabla 1, son meramente un ejemplo. En un ejemplo, cada sub-flujo de bits de vídeo de MVC está asociado con un correspondiente, entre los descriptores de extensión de MVC 110, que especifica las características del correspondiente sub-flujo de bits de vídeo de MVC. Un sub-flujo de bits de vídeo de MVC puede necesitar ensamblar otros sub-flujos de bits de vídeo de MVC. Es decir, con el fin de decodificar y presentar un sub-flujo de bits en particular, un dispositivo cliente puede necesitar extraer y decodificar datos de vídeo de otros sub-flujos de bits de un flujo de bits común que incluye los

5

10

15

20

25

30

35

40

dos sub-flujos de bits.

TABLA l-üeseriptor de extensión de MVC

Sintaxis: N° de bits Abreviatura

descriptor_extensión_MVC () {

etiqueta_descriptor: 8 uimsbf

longitud_descriptor: 8 uimsbf

velocidad_media_bits: 16 uimsbf

velocidad_máxima_bits: 16 uimsbf

reservado: 4 bslbf

mín_índice_orden_vista: 10 bslbf

máx_índice_orden_vista: 10 bslbf

inicio_id_temporal: 3 bslbf

fin_id_temporal: 3 bslbf

ninguna_unidad_de_nal_de sei presente: 1 bslbf

reservado: 1 bslbf

}

[0092] En el ejemplo de la Tabla 1, el campo de etiqueta de descriptor puede corresponder a un campo de etiqueta de descriptor de ocho bits que se incluye en cada descriptor, según lo establecido por la norma de sistemas de MPEG-2, para identificar en particular el descriptor. El estándar de sistemas de MPEG-2 define ciertas etiquetas de descriptor y marca otros valores de etiqueta de descriptor, por ejemplo, valores 36 a 63, como "reservados". Sin embargo, la enmienda 4 a la norma de sistemas de MPEG-2 propone fijar el descriptor de extensión de MVC en "49", que corresponde a una de las etiquetas de descriptor reservadas, tal como se especifica en la especificación de los sistemas de MPEG-2. Esta divulgación, por lo tanto, propone fijar el valor de la etiqueta_descriptor de los descriptores de extensión de MVC 110 en un valor de "49".

[0093] Una vez más, el campo de longitud del descriptor puede corresponder a un campo de longitud de descriptor de ocho bits que también se incluye en cada descriptor, según lo establecido por la norma de sistemas de MPEG-2. El multiplexor 30 puede fijar el valor del campo de longitud de descriptor igual al número de octetos del correspondiente, entre los descriptores de extensión de MVC 110, inmediatamente después del campo de longitud del descriptor. Debido a que la longitud de un descriptor de extensión de MVC no cambia, el multiplexor 30 puede fijar el valor del campo de longitud de descriptor, para cada uno de los descriptores de extensión de MVC 110, en un valor de ocho, para representar la presencia de ocho octetos de información a continuación del campo de longitud del descriptor.

[0094] El campo de velocidad media de bits puede comprender un campo de dieciséis bits que indica la velocidad media de bits, en kilobits por segundo, de un flujo de vídeo de AVC re-ensamblado. Es decir, el campo de velocidad media de bits describe la velocidad media de bits para un flujo de vídeo cuando el flujo de vídeo se ensambla a partir de partes constituyentes del flujo de transporte o del flujo de programas al que corresponde el descriptor entre los descriptores de extensión de MVC 110. En algunos ejemplos, el multiplexor 30 puede fijar el valor del campo de velocidad media de bits en cero para indicar que la velocidad media de bits no está indicada por el descriptor entre los descriptores de extensión de MVC 110.

[0095] El campo de velocidad máxima de bits puede comprender un campo de dieciséis bits que indica la velocidad máxima de bits, en kilobits por segundo, del flujo de vídeo de AVC re-ensamblado. Es decir, el campo de velocidad máxima de bits describe la velocidad máxima de bits para un flujo de vídeo cuando el flujo de vídeo se ensambla a partir de partes constituyentes del flujo de transporte o del flujo de programas al que corresponde el descriptor entre los descriptores de extensión de MVC 110. En algunos ejemplos, el multiplexor 30 puede fijar el valor del campo de velocidad máxima de bits en cero para indicar que la velocidad máxima de bits no está indicada por el descriptor entre los descriptores de extensión de MVC 110.

[0096] El campo de mínimo índice de orden de vista puede comprender un campo de diez bits que indica el valor mínimo del índice de orden de vista de todas las unidades de NAL contenidas en el sub-flujo asociado de bits de vídeo de MVC. De manera similar, el campo de máximo índice de orden de vista es un campo de diez bits que indica

5

10

15

20

25

30

35

40

45

el valor máximo del índice de orden de vista de todas las unidades de NAL contenidas en el sub-flujo asociado de bits de vídeo de MVC.

[0097] El campo de inicio de Identificador temporal puede comprender un campo de tres bits que indica el valor mínimo del id_temporal del elemento sintáctico de la cabecera de la unidad de NAL, de todas las unidades de NAL contenidas en el sub-flujo asociado de bits de vídeo de MVC. Es decir, un valor de Identificador temporal se incluye en una cabecera para cada unidad de NAL. En general, el valor del Identificador temporal corresponde a una velocidad particular de tramas, donde los valores del Identificador temporal relativamente mayores corresponden a mayores velocidades de tramas. Por ejemplo, un valor de '0' para un Identificador temporal puede corresponder a una velocidad de tramas de 15 tramas por segundo (fps), y un valor de '1' para un Identificador temporal puede corresponder a una velocidad de tramas de 30 fps. De esta manera, la recopilación de todas las imágenes que tienen un Identificador temporal de 0, en este ejemplo, en un conjunto puede usarse para formar un segmento de vídeo que tenga una velocidad de tramas de 15 fps, mientras que la recolección de todas las imágenes que tienen un Identificador temporal de 0 y de todas las imágenes que tienen un Identificador temporal de 1 en un conjunto diferente se puede utilizar para formar un segmento de vídeo diferente que tenga una velocidad de tramas de 30 fps. El multiplexor 30 determina el Identificador temporal más pequeño de todas las unidades de NAL del sub-flujo de bits de vídeo de MVC y fija el valor del campo de inicio de Identificador temporal igual a este valor determinado del Identificador temporal más pequeño.

[0098] El campo de fin de Identificador temporal puede comprender un campo de tres bits que indica el valor máximo del Identificador temporal del elemento sintáctico de la cabecera de la unidad de NAL, de todas las unidades de NAL contenidas en el sub-flujo asociado de bits de vídeo de MVC. Por consiguiente, el multiplexor 30 determina el Identificador temporal más grande de todas las unidades de NAL del sub-flujo de bits de vídeo de MVC y fija el valor del campo de inicio de Identificador temporal igual a este valor determinado del Identificador temporal más grande.

[0099] El campo de ninguna unidad de NAL de SEI presente puede comprender un indicador de un bit que, cuando se fija en '1', indica que no hay ninguna unidad de NAL de información de mejora suplementaria presente en el subflujo asociado de bits de vídeo de MVC. El multiplexor 30 puede determinar si una o más unidades de NAL de información de mejora suplementaria se han colocado en el flujo de bits y fijar el valor del campo de ninguna unidad de NAL de SEI presente en un valor de 1 cuando no hay ninguna unidad de NAL de SEI en el flujo de bits, pero puede fijar el valor del campo de ninguna unidad de NAL de SEI presente en un valor de '0' cuando al menos una unidad de NAL de SEI está presente en el flujo de bits.

[0100] La Tabla 2 a continuación proporciona un ejemplo de datos incluidos en el descriptor de jerarquía 112. En los sistemas de MPEG-2, se puede definir un descriptor de jerarquía para un flujo de programas de vídeo que contenga un flujo integrado de programas de vídeo. Los diferentes campos y profundidades de bits de los campos, mostrados en la Tabla 2, se proporcionan como un ejemplo. El valor de índice_capa_jerarquía identifica el índice de capa del flujo de programa actual y el valor de índice_capa_integrada_jerarquía identifica una capa dependiente. En el diseño de la MVC, un flujo de programa puede depender de otro flujo de programa utilizando el descriptor de jerarquía. Es decir, las dependencias entre flujos de programas se pueden determinar basándose en datos incluidos en el descriptor de jerarquía.

TABLA 2-üescriptor de jerarquía

Sintaxis: N° de bits Abreviatura

descriptor jerarquía () {

etiqueta_descriptor: 8 uimsbf

longitud_descriptor: 8 uimsbf

reservado: 1 bslbf

indicador_adjustabilidad_temporal_a

escala: 1

indicador ajustabilidad espacial a: 1 bslbf

escala

indicador ajustabilidad a escala ca: H bslbf

lidad

tipo_jerarquía: 4 Uimsbf

reservado: 2 bslbf

índice_capa_jerarquía: 6 uimsbf

Indicador_T ref_presente: 1 bslbf

reservado: 1 bslbf

índice_capa_integrada_jerarquía: 6 uimsbf

5

10

15

20

25

30

35

40

45

50

55

Sintaxis: N° de bits Abreviatura

descriptor jerarquía () {

reservado canal_jerarquía }: 2 6 bslbf uimsbf

[0101] Como se ha señalado anteriormente, la especificación de sistemas de MPEG-2 especifica que cada descriptor incluye un campo de etiqueta de descriptor y un campo de longitud de descriptor. Por consiguiente, el descriptor de jerarquía 112 incluye un campo de etiqueta de descriptor y un campo de longitud de descriptor. De acuerdo a la especificación de los Sistemas de MPEG-2, el multiplexor 30 puede fijar el valor del campo de etiqueta de descriptor en un valor de "4" para el descriptor de jerarquía 112.

[0102] La longitud del descriptor jerarquía 112 se puede determinar a priori, ya que cada instancia del descriptor de jerarquía 112 debería incluir la misma cantidad de datos. En un ejemplo, el multiplexor 30 puede fijar el valor del campo de longitud del descriptor en un valor de cuatro, indicativo de cuatro octetos en una instancia del descriptor de jerarquía 112 después del final del campo de longitud del descriptor.

[0103] El campo de tipo de jerarquía describe la relación jerárquica entre la capa de jerarquía asociada y su capa de jerarquía integrada. En un ejemplo, el multiplexor 30 establece el valor del campo de tipo jerárquico basándose en la relación jerárquica, por ejemplo, como se describe en la Tabla 3 a continuación. Como ejemplo, cuando la ajustabilidad a escala se aplica en más de una dimensión, el multiplexor 30 puede fijar el campo del tipo de jerarquía en un valor de "8" ("Ajustabilidad a Escala Combinada", como se muestra en la Tabla 3), y el multiplexor 30 establece los valores del campo indicador de ajustabilidad a escala temporal, del campo indicador de ajustabilidad a escala espacial y del campo indicador de ajustabilidad a escala de calidad de acuerdo a los datos recuperados desde los paquetes PES y las cabeceras de paquetes PES de los respectivos flujos. En general, el multiplexor 30 puede determinar dependencias entre los diferentes flujos correspondientes a diversas vistas y / o flujos de datos de audio. El multiplexor 30 también puede determinar si un flujo dependiente que comprende una capa de realce es una capa espacial, una capa de mejora de razón entre señal y ruido (SNR), una capa de mejora de calidad u otro tipo de capa de mejora.

[0104] Como otro ejemplo, para sub-flujos de bits de vídeo de MVC, el multiplexor 30 puede fijar el campo de tipo de jerarquía en un valor de '9' ( "MVC", como se muestra en la Tabla 3) y puede fijar los valores de cada uno entre el campo indicador de ajustabilidad a escala, el campo indicador de ajustabilidad a escala espacial y el campo indicador de ajustabilidad a escala de calidad en '1'. Como otro ejemplo más, para los sub-flujos de bits de vista base de MVC, el multiplexor 30 puede fijar el valor del campo de tipo de jerarquía en un valor de '15' y puede fijar los valores del campo indicador de ajustabilidad a escala, del campo indicador de ajustabilidad a escala espacial y del campo indicador de ajustabilidad a escala de calidad en '1'. Como otro ejemplo, para el sub-flujo de bits de MVC de Prefijo, el multiplexor 30 puede fijar el campo de tipo de jerarquía en un valor de '14' y puede fijar el campo indicador de ajustabilidad a escala, el campo indicador de ajustabilidad a escala espacial y el campo indicador de ajustabilidad a escala de calidad en '1'.

[0105] El campo de índice de capa de jerarquía puede comprender un campo de seis bits que define un índice único del elemento de programa asociado en una tabla de jerarquías de capas de codificación. Los índices pueden ser únicos dentro de una sola definición de programa. Para sub-flujos de bits de vídeo de AVC, los flujos de vídeo que se ajustan a uno o más perfiles definidos en el anexo G de la Rec. de UIT-T H.264 | ISO / IEC 14496-10, éste es el índice de elemento de programa, que se asigna de tal manera que el orden del flujo de bits será correcto si las representaciones asociadas de dependencia de SVC de los sub-flujos de bits de vídeo de la misma unidad de acceso se reensamblan en orden creciente del índice_capa_jerarquía. Para sub-flujos de bits de vídeo de MVC de flujos de vídeo de AVC que se ajusten a uno o más perfiles definidos en el anexo H de la Rec. de ITU-T H.264 | ISO / IEC 14496-10, éste es el índice de elemento de programa, que se asigna de tal forma que cualquiera de estos valores sea mayor que el valor del índice_capa_jerarquía especificado en el descriptor de jerarquía para el sub-flujo de bits de MVC de prefijo.

[0106] El campo de índice de capa integrada de jerarquía puede comprender un campo de seis bits que define el índice de la tabla de jerarquías del elemento de programa al que se necesita acceder antes de la decodificación del flujo elemental asociado a la instancia correspondiente del descriptor de jerarquía 112. Esta divulgación deja indefinido el valor para el campo de índice de capa integrada de jerarquía para cuando el campo de tipo de jerarquía tiene un valor de 15 (es decir, un valor correspondiente a la capa base).

[0107] El campo de canal de jerarquía puede comprender un campo de seis bits que indica el número de canal previsto para el elemento de programa asociado en un conjunto ordenado de canales de transmisión. El canal de transmisión más robusto está definido por el valor más bajo del campo de canal de jerarquía, con respecto a la definición general de la jerarquía de transmisión. Obsérvese que un canal jerárquico dado puede ser asignado

5

10

15

20

25

30

35

40

simultáneamente a varios elementos del programa.

[0108] Los campos reservados de las Tablas 1 y 2 están reservados para uso futuro por el desarrollo de normas futuras. Las técnicas de esta divulgación no proponen, en este momento, asignar significado semántico a los valores de los campos reservados.

[0109] La Tabla 3 a continuación ilustra los valores potenciales para el campo de tipo de jerarquía descrito anteriormente:

TABLA 3-Valores del campo de tipo de jerarquía

Valor: Descripción

0: Reservado

1: Ajustabilidad a escala espacial

2: Ajustabilidad a escala de la SNR

3: Ajustabilidad a escala temporal

4: División de datos

5: Flujo de bits de extensión

6: Flujo privado

7: Perfil de multi-vista

8: Ajustabilidad a escala combinada

9: Sub-flujo de bits de vídeo de MVC

10 a 13: Reservado

14: Sub-flujo de bits de MVC de prefijo

15: La capa base o el sub-flujo de bits de vista base de MVC o el sub-flujo de bits de vídeo de AVC de MVC

[0110] En algunos ejemplos, el descriptor de jerarquía 112 puede usarse para indicar un sub-flujo de bits de MVC señalizado por un sub-flujo de bits incremental y los sub-flujos de bits integrados. Los sub-flujos de bits integrados incluyen el sub-flujo de bits dependiente directo correspondiente al índice_capa_integrada_jerarquía y todos los subflujos de bits integrados de este sub-flujo de bits dependiente directo. En esta divulgación, las vistas que están contenidas explícitamente se llaman vistas de realce, mientras que las vistas que están integradas se llaman vistas dependientes.

[0111] En un ejemplo en el que la salida del multiplexor 30 comprende un flujo de programa, las tablas de información específica de programa 88 puede incluir un mapa de flujos de programa (PSM). Un PSM puede proporcionar una descripción de los flujos elementales en el flujo de programa correspondiente y las relaciones de los flujos elementales entre sí. En algunos ejemplos, un mapa de flujos de programas también puede corresponder a un flujo de transporte. Cuando se transporta en un flujo de transporte correspondiente, la estructura del PSM no debería modificarse. El multiplexor 30 puede indicar que un PSM está presente en un paquete PES fijando el valor del id_flujo del paquete PES en 0xBC, es decir, el valor hexadecimal BC, que corresponde al valor binario 10111100 o al valor decimal 188.

[0112] El multiplexor 30 mantiene una lista completa de todos los programas disponibles en un flujo de transporte en la tabla de asociación de programas 104. El multiplexor 30 también puede integrar tablas de asociación de programas en unidades de NAL. El multiplexor 30 puede indicar que una unidad de NAL incluye una tabla de asociación de programas asignando a la unidad de NAL un valor PID de 0. El multiplexor 30 puede enumerar cada programa, junto con el valor del PID de los paquetes de transporte que contienen la correspondiente tabla de mapas de programas, en la tabla de asociación de programas 104. Utilizando el mismo ejemplo mencionado anteriormente, la tabla ejemplar de mapas de programas que especifica los flujos elementales del programa número 3 tiene un PID de 1001 y otra PMT tiene otro PID de 1002. Este conjunto de información, o similares, pueden incluirse en la tabla de asociación de programas 104.

[0113] Las tablas de información específica de programa 88 también incluyen la tabla de información de red (NIT) 100 y la tabla de acceso condicional (CAT) 102. El programa número cero, tal como se especifica en la PAT, tiene un significado especial. En particular, se puede utilizar el programa número cero para señalar el camino a la tabla de información de red 100. La tabla es optativa y, cuando está presente, la tabla puede proporcionar información sobre

5

10

15

20

25

30

35

40

45

50

55

60

65

la red física que transporta el flujo de transporte, tal como frecuencias de canal, detalles del transpondedor de satélite, características de modulación, originador del servicio, nombre del servicio y detalles de las redes alternativas disponibles.

[0114] Si flujos elementales cualesquiera dentro de un flujo de transporte están aleatorizados, entonces, una tabla de acceso condicional 102 debe estar presente. La tabla de acceso condicional 102 proporciona detalles del (de los) sistema (s) de aleatorización en uso y proporciona los valores de PID de los paquetes de transporte que contienen la información de gestión y titularidad del acceso condicional. El formato de esta información no se especifica dentro de la norma de sistemas de MPEG-2.

[0115] La FIG. 4 es un diagrama de bloques que ilustra un ejemplo de conjunto de datos que pueden estar incluidos en uno de los descriptores de punto de operación 114 (FIG. 3). En el ejemplo de la FIG. 4, el descriptor de punto de operación 118 incluye el campo de etiqueta de descriptor 120, el campo de longitud de descriptor 122, el campo de velocidad de tramas 124, el campo del número de vistas de exhibición 126, el campo del número de vistas de decodificación 128, los campos de identificadores de vistas 130, el campo de velocidad media de bits 132, el campo de velocidad máxima de bits 134, el campo de identificador temporal 136 y los campos de bits de cola reservados 138.

[0116] En el ejemplo de la FIG. 4, el campo de velocidad de tramas 124 y el campo del número de vistas de exhibición 126 corresponden a un valor ejemplar de capacidad de representación, el campo del número de vistas de decodificación 128 corresponde a un valor ejemplar de capacidad de decodificación y el campo de velocidad media de bits 132 y el campo de velocidad máxima de bits 134 corresponden a un valor ejemplar de velocidad de bits. El descriptor de punto de operación 118 es meramente un ejemplo de una estructura de datos que puede usarse para señalizar características de un punto de operación, tal como una capacidad de representación, una capacidad de decodificación y una velocidad de bits. Las FIGS. 5 y 6 a continuación proporcionan ejemplos alternativos de descriptores de puntos de operación que señalizan estas características.

[0117] Como se ha descrito anteriormente, la especificación de sistemas de MPEG-2 especifica que cada descriptor tiene un campo de etiqueta de descriptor y un campo de longitud de descriptor, de 8 bits cada uno. De este modo, el multiplexor 30 (FIG. 1) puede asignar un valor al campo de etiqueta de descriptor 120, indicativo de un descriptor de punto de operación de MVC. El multiplexor 30 también puede determinar una serie de vistas para el punto de operación y una serie de bits reservados para el descriptor de punto de operación y luego calcular la longitud del descriptor de punto de operación 118 en octetos a continuación del campo de longitud de descriptor 122. El multiplexor 30 puede asignar este valor de longitud calculado al campo de longitud del descriptor 122 al instanciar el descriptor de punto de operación 118.

[0118] El campo de velocidad de tramas 124 puede comprender un campo de 16 bits que indica la velocidad máxima de tramas, en tramas / 256 segundos, del flujo de vídeo de AVC reensamblado. Es decir, el multiplexor 30 puede calcular la velocidad máxima de tramas de un periodo de tiempo de 256 segundos para fijar el valor del campo de velocidad de tramas 124. En algunos ejemplos, la división entre 256 puede dar como resultado una conversión de un valor de punto flotante en un valor entero. En otros ejemplos, pueden utilizarse períodos de tiempo distintos a 256 segundos. El periodo de tiempo de 256 segundos descrito con respecto al campo de velocidad de tramas 124 es meramente un ejemplo potencial para el que se puede calcular la velocidad máxima de tramas de un punto de operación.

[0119] El campo del número de vistas de exhibición 126 puede comprender un campo de diez bits que indica el valor del número de las vistas destinadas a la salida, del flujo de vídeo de AVC reensamblado. En general, el campo del número de vistas de exhibición 126 representa un número de vistas a exhibir para un punto de operación correspondiente. Debido a que diferentes pantallas pueden ser capaces de exhibir diferentes números de vistas, un dispositivo cliente puede utilizar el valor del campo del número de vistas de exhibición 126 para seleccionar un punto de operación que tenga tantas vistas a exhibir como sea posible en la pantalla para el dispositivo cliente. Por ejemplo, si un dispositivo cliente es capaz de exhibir cuatro vistas, el dispositivo cliente puede seleccionar un punto de operación con un campo del número de vistas de exhibición que tenga un valor que indique que se exhibirán cuatro vistas para el punto de operación correspondiente. Por consiguiente, el campo del número de vistas de exhibición 126 puede incluirse como parte de un valor de capacidad de representación. Del mismo modo, el multiplexor 30 puede establecer el valor del campo del número de vistas de exhibición 126 de acuerdo a un número de vistas a exhibir para un punto de operación.

[0120] El campo del número de vistas de decodificación 128 puede comprender un campo de diez bits que indica el valor del número de vistas requerido para decodificar el flujo de vídeo de AVC reensamblado. Este valor puede diferir del número de vistas a exhibir, indicado por el campo del número de vistas de exhibición 126. Esto puede resultar de ser requeridas ciertas vistas para la decodificación debido a dependencias de vista, pero que no se exhiben realmente.

[0121] Con referencia breve a la FIG. 7, como ejemplo, las vistas S0 y S1 pueden ser vistas que han de exhibirse para un punto de operación. La vista S0 se puede decodificar directamente sin decodificar ninguna otra vista. Sin

5

10

15

20

25

30

35

40

45

50

55

60

65

embargo, para decodificar la vista S1, la vista S2 también debe ser decodificada, porque la vista S1 incluye datos de predicción referidos a la vista S2. Por lo tanto, en este ejemplo, el campo del número de vistas de exhibición 126 tendría un valor de dos, pero el campo del número de vistas de decodificación 128 tendría un valor de tres. En algunos ejemplos, una vista a exhibir puede ser interpolada a partir de otras una o más vistas, de tal manera que el número de vistas a exhibir pueda ser mayor que el número de vistas a decodificar. Es decir, usando una vista de base e información de profundidad, el decodificador de vídeo 48 (FIG. 1) puede interpolar una segunda vista. El decodificador de vídeo 48 puede usar dos o más vistas para calcular la información de profundidad para interpolar una nueva vista, o el decodificador de vídeo 48 puede recibir información de profundidad para una vista desde el dispositivo de origen 20.

[0122] El campo del número de vistas de decodificación 128 puede corresponder a un valor de capacidad de decodificación, en cuanto a que un decodificador de un dispositivo cliente (tal como el decodificador de vídeo 48 del dispositivo de destino 40) debería ser capaz de decodificar un número de vistas igual al valor del campo del número de vistas de decodificación 128. En consecuencia, el dispositivo cliente puede seleccionar un punto de operación que tenga un campo del número de vistas de decodificación, representativo de un número de vistas que un decodificador de vídeo del dispositivo cliente sea capaz de decodificar.

[0123 El descriptor de punto de operación 118 de la FIG. 4 también incluye campos identificadores de vistas 130. Cada uno de los campos identificadores de vistas 130 puede comprender un campo de diez bits que indica el valor del id_vista de las unidades de NAL contenidas en el flujo de bits de vídeo de AVC reensamblado. De este modo, los identificadores de vistas de cada vista exhibida para un punto de operación son señalizados utilizando campos identificadores de vistas 130. Es decir, los identificadores de vistas de los campos identificadores de vistas 130 corresponden a las vistas exhibidas. De este modo, las vistas que se decodifican pero que no se exhiben no están señalizadas por los campos identificadores de vistas 130, en el ejemplo de la FIG. 4.

[0124] El campo de velocidad media de bits 132 puede comprender un campo de dieciséis bits que indica la velocidad media de bits, en kilobits por segundo, del flujo de vídeo de AVC re-ensamblado. Cuando se fija en 0, la velocidad media de bits no está indicada. Es decir, un valor de cero para el campo de velocidad media de bits 132 implica que el campo de velocidad media de bits 132 no debería utilizarse para determinar la velocidad media de bits del flujo de vídeo de AVC reensamblado.

[0125] El campo de velocidad máxima de bits 134 puede comprender un campo de dieciséis bits que indica la velocidad máxima de bits, en kbits por segundo, de la secuencia de vídeo de AVC re-ensamblado. Cuando se fija en 0, la velocidad máxima de bits no está indicada. Es decir, cuando el valor del campo de velocidad máxima de bits 134 se fija en cero, el campo de velocidad máxima de bits 134 no debería utilizarse para determinar la velocidad máxima de bits del flujo de vídeo de AVC re-ensamblado.

[0126] El campo de identificador temporal 136 puede comprender un campo de tres bits que indica el valor del id_temporal, correspondiente a la velocidad de tramas del flujo de vídeo de AVC re-ensamblado. Es decir, se puede usar el id_temporal para determinar la velocidad de tramas del flujo de vídeo de AVC re-ensamblado, como se ha expuesto anteriormente.

[0127] El descriptor de punto de operación 118 ejemplar también incluye campos de bits de cola reservados 138. En un ejemplo, por ejemplo, tal como se muestra en la Tabla 4 a continuación, el número de bits de cola reservados puede usarse tanto para señalización adicional como para rellenar el descriptor de punto de operación 118, de tal manera que el descriptor de punto de operación 118 termine en un límite de octeto. Por ejemplo, como se ha expuesto anteriormente, el descriptor de punto de operación 118 puede utilizar diez bits para representar el identificador de vista de cada vista exhibida. El número estático de bits, aparte de los bits utilizados para los identificadores de vistas y los bits de cola reservados es 87, en este ejemplo. De este modo, para asegurar que el descriptor de punto de operación 118 termine en un límite de octeto (es decir, que tenga un número de bits que sea exactamente divisible entre ocho), el multiplexor 30 puede añadir una serie de bits de cola de acuerdo a la siguiente fórmula:

bits de cola = (1 + 6 * núm_vistas_exhibición) % 8

donde '%' representa el operador de módulo matemático. Es decir, A % B da como resultado el resto de A dividido entre B, de modo que el resto esté en el intervalo de enteros entre 0 y B-1.

[0128] La Tabla 4 resume un ejemplo de conjunto de datos que se pueden incluir en el ejemplo del descriptor de punto de operación 118 de la FlG. 4.

5

10

15

20

25

30

35

TABLA 4-üescriptor del punto de operación de MVC

Sintaxis: N° de bits Abreviatura

descriptor op MVC () {

etiqueta_descriptor: 8 uimsbf

longitud_descriptor: 8 uimsbf

velocidad_tramas: 16 uimsbf

núm_vistas_exhibición: 10 uimsbf

núm_vistas_decodificación: 10 uimsbf

for(i = 0; i <= núm vistas exhibición; i++) {

id_vista: 10 uimsbf

}

velocidad_media_bits: 16 uimsbf

velocidad_máxima_bits: 16 uimsbf

id_temporal: 3 uimsbf

for (i = 0; i <(1 + 6 * núm vistas exhibición) % 8; i ++) {

bit_reservado: 1 bslbf

}

}

[0129] La FIG. 5 es un diagrama de bloques que ilustra un conjunto ejemplar alternativo de datos que se pueden incluir en uno de los descriptores de punto de operación 114 (FIG. 3). En general, cada uno de los descriptores de punto de operación 114 debería tener un formato común, de tal manera que un dispositivo cliente pueda configurarse para recibir descriptores de punto de operación de un solo formato. De este modo, cada uno de los descriptores de punto de operación 114 puede tener un formato similar al descriptor de punto de operación de la FIG. 4, la FIG. 5 o la FIG. 6, u otro formato común que incluya datos de señalización similares.

[0130] En el ejemplo de la FIG. 5, el descriptor de punto de operación 140 incluye el campo de etiqueta de descriptor 142, el campo de longitud de descriptor 144, el campo IDC_perfil 146, el campo IDC_nivel 148, el campo de velocidad de tramas 149, el campo del número de vistas de exhibición 150, el campo del número de vistas de decodificación 152, el campo de velocidad media de bits 154, el campo de velocidad máxima de bits 156, el campo de identificador temporal 158, el campo de bit reservado 160, los campos de índices de orden de vista 162, los campos de identificadores de vista 164 y los campos de bits de cola reservados 166. IDC significa "indicador". Como se explica a continuación, el ejemplo del descriptor de punto de operación 140 señaliza explícitamente los valores de idc_perfil y de idc_nivel para un punto de operación, así como información sobre cómo se ensambla un punto de operación.

[0131] El campo del número de vistas de exhibición 150 y el campo de velocidad de tramas 149 corresponden a un valor de capacidades de representación señalizado por el descriptor de punto de operación 140. El campo IDC_perfil 146, el campo IDC_nivel 148 y el campo del número de vistas de decodificación 152, en el ejemplo de la FIG. 5, representan ejemplos de datos que pueden corresponder a un valor de capacidades de decodificación señalizado por el descriptor de punto de operación 140. El campo de velocidad media de bits 154 y el campo de velocidad máxima de bits 156 corresponden a un valor de velocidad de bits señalizado por el descriptor de punto de operación 140.

[0132] Como se ha descrito anteriormente, la especificación de sistemas de MPEG-2 especifica que cada descriptor tiene un campo de etiqueta de descriptor y un campo de longitud de descriptor, cada uno de los cuales puede ser de 8 bits de longitud. De este modo, el multiplexor 30 (FIG. 1) puede asignar un valor al campo de etiqueta de descriptor 142, indicativo de un descriptor de punto de operación de MVC. El multiplexor 30 también puede determinar un número de vistas para el punto de operación y un número de bits reservados para el descriptor de punto de operación, y luego calcular la longitud del descriptor de punto de operación 140 en octetos a continuación del campo de longitud de descriptor 144. El multiplexor 30 puede asignar este valor de longitud calculado al campo de longitud de descriptor 144 al instanciar el descriptor de punto de operación 140.

5

10

15

20

25

30

35

40

45

50

55

60

65

[0133] El campo IDC_perfil 146 puede comprender un campo de ocho bits que indica el idc_perfil del punto de

operación re-ensamblado por la información dada en el descriptor de punto de operación 140. El campo IDC_nivel 148 puede comprender un campo de ocho bits que indica el idc_nivel del punto de operación re-ensamblado por la información dada en el descriptor de punto de operación 140.

[0134] El campo de velocidad de tramas 149 puede comprender un campo de 16 bits que indica la velocidad máxima de tramas, en tramas / 256 segundos, del flujo de vídeo de AVC re-ensamblado. Es decir, el multiplexor 30 puede calcular la velocidad máxima de tramas de un periodo de tiempo de 256 segundos para establecer el valor del campo de velocidad de tramas 149. Al igual que con el campo de velocidad de tramas 124, en otros ejemplos para el campo de velocidad de tramas 149, pueden usarse otros períodos de tiempo además de 256 segundos.

[0135] El campo del número de vistas de exhibición 150 puede comprender un campo de diez bits que indica el valor del número de las vistas destinadas a la salida, el flujo de vídeo de AVC re-ensamblado. En general, el campo del número de vistas de exhibición 150 representa una serie de vistas a exhibir para un punto de operación correspondiente. El campo del número de vistas de decodificación 152 puede comprender un campo de diez bits que indica el valor del número de vistas requeridas para decodificar el flujo de vídeo de AVC re-ensamblado. Este valor puede diferir del número de vistas a exhibir, indicado por el campo del número de vistas de exhibición 150. Esto puede resultar por ser requeridas ciertas vistas para la decodificación, debido a las dependencias de las vistas, pero que no se exhiben realmente, por ejemplo, como se ha descrito anteriormente con respecto al campo del número de vistas de decodificación 128.

[0136] El campo de velocidad media de bits 154 puede comprender un campo de dieciséis bits que indica la velocidad media de bits, en kilobits por segundo, del flujo de vídeo de AVC re-ensamblado. Cuando se fija en 0, la velocidad media de bits no está indicada. Es decir, un valor de cero para el campo de velocidad media de bits 154 implica que el campo de velocidad media de bits 154 no debería usarse para determinar el promedio de velocidad de bits del flujo de vídeo de AVC re-ensamblado. El campo de velocidad máxima de bits 156 puede comprender un campo de dieciséis bits que indica la velocidad máxima de bits, en kbits por segundo, del flujo de vídeo de AVC reensamblado. Cuando se fija en 0, la velocidad máxima de bits no está indicada. Es decir, cuando el valor del campo de velocidad máxima de bits 156 se fija en cero, el campo de velocidad máxima de bits 156 no debería utilizarse para determinar la velocidad máxima de bits del flujo de vídeo de AVC re-ensamblado.

[0137] El campo de identificador temporal 158 puede comprender un campo de tres bits que indica el valor del id_temporal correspondiente a la velocidad de tramas del flujo de vídeo de AVC re-ensamblado. Es decir, se puede usar el id_temporal para determinar la velocidad de tramas del flujo de vídeo de AVC re-ensamblado, como se ha expuesto anteriormente.

[0138] El descriptor de punto de operación 140 también incluye campos de índices de orden de vista 162 y campos de identificadores de vista 164. Cada uno de los campos de índice de orden de vista 162 puede comprender un campo de diez bits que indica el valor del índice de orden de vista de las unidades de NAL contenidas en el punto de operación. Un dispositivo cliente puede volver a ensamblar las unidades de NAL correspondientes a todos los valores señalizados de índice_orden_vista en el descriptor de punto de operación 140 por los campos de índice de orden de vista 162. Los campos de índice de orden de vista 162 incluyen campos de índice de orden de vista para cada una de las vistas a decodificar. Dado un valor de índice_orden_vista, un dispositivo cliente puede extraer las unidades de NAL correspondientes de los flujos elementales porque el descriptor de extensión de MVC indica el rango de los valores del índice de orden de vista en ese flujo elemental y el intervalo abarca el valor de índice_orden_vista señalizado en el descriptor de punto de operación.

[0139] Cada uno de los campos de identificador de vista 164 puede comprender un campo de diez bits que indica el valor del id_vista de las unidades de NAL contenidas en el flujo de bits de vídeo de AVC re-ensamblado. De este modo, los identificadores de vistas de cada vista exhibida para un punto de operación son señalizados usando campos identificadores de vistas 164. Es decir, los identificadores de vistas de los campos identificadores de vistas 164 corresponden a las vistas exhibidas. Por lo tanto, las vistas que se decodifican pero que no se exhiben no están señalizadas por los campos identificadores de vistas 164, en el ejemplo de la FIG. 5.

[0140] El descriptor de punto de operación 140 también incluye los campos de bits de cola reservados 166. El descriptor de punto de operación 140 puede incluir bits de cola como relleno, de manera que el número de bits en el descriptor de punto de operación 140 sea exactamente divisible entre ocho. Debido a que el número de campos de índices de orden de vista y de campos identificadores de vista puede variar, el número de bits de cola que el multiplexor 30 incluye en el descriptor de punto de operación 140 puede variar en consecuencia. Por ejemplo, el número de bits de cola se puede determinar de acuerdo a la siguiente fórmula

bits de cola = (6 * (núm_vistas_exhibición + núm_vistas_decodificación)) % 8

donde '%' representa el operador de módulo.

[0141] La Tabla 5 resume un ejemplo de conjunto de datos que se pueden incluir en el descriptor ejemplar de punto

de operación 140 de la FIG. 5.

TABLA 5-üescriptor de punto de operación de MVC

Sintaxis: N° de bits Abreviatura

descriptor op MVC () {

etiqueta_descriptor: 8 uimsbf

longitud_descriptor: 8 uimsbf

idc_perfil: 8 uimsbf

idc_nivel: 8 uimsbf

velocidad de tramas: 16 uimsbf

núm_vistas_exhibición: 10 uimsbf

núm_vistas_decodificación: 10 uimsbf

velocidad_media_bits: 16

velocidad_máxima_bits: 16 uimsbf

id_temporal: 3 uimsbf

bit_reservado: 1 bslbf

for (i = 0; i< núm vistas decodificación; i++) {

índice_orden_vista: 10 uimsbf

}

for(i = 0; i <= núm vistas exhibición; i++) {

id_vista: 10 uimsbf

}

for (i = 0 ; i<6*(núm vistas exhibición + núm vistas decodificación) % 8; i++) {

bit_reservado: 1 bslbf

}

}

5

[0142] La FIG. 6 es un diagrama de bloques que ilustra otro conjunto ejemplar alternativo de datos que se pueden incluir en uno de los descriptores de punto de operación 114 (FIG. 3). En el ejemplo de la FIG. 6, el descriptor de punto de operación 170 incluye el campo de etiqueta de descriptor 172, el campo de longitud de descriptor 174, el campo de IDC_perfil 176, el campo de IDC_nivel 178, el campo de velocidad de tramas 180, el campo del número

10 de vistas de exhibición 182, el campo del número de vistas de decodificación 184, el campo de velocidad media de bits 186, el campo de velocidad máxima de bits 188, el campo de identificador temporal 190, el campo de bit reservado 192, el campo de identificador de punto de operación 194, el campo de indicador dependiente de punto de operación 196, el campo de identificador de punto de operación dependiente optativo 198, los campos de índice de orden de vista 200, los campos de identificador de vista 202 y los campos de bits de cola reservados 204. Como se 15 describe a continuación, el descriptor de punto de operación 170 proporciona un descriptor ejemplar de punto de operación para un punto de operación que depende de otro punto de operación y que señaliza vistas adicionales requeridas para la decodificación.

[0143] El campo del número de vistas de exhibición 182 y el campo de velocidad de tramas 180 corresponden a un 20 valor de capacidades de representación señalizado por el descriptor de punto de operación 140. El campo IDC_perfil

176, el campo IDC_nivel 178 y campo del número de vistas de decodificación 184, en el ejemplo de la FIG. 6, representan ejemplos de datos que pueden corresponder a un valor de capacidades de decodificación señalizado por el descriptor de punto de operación 140. El campo de velocidad media de bits 154 y el campo de velocidad máxima de bits 156 corresponden a un valor de velocidad de bits señalizado por el descriptor de punto de operación 25 140.

[0144] Como se ha descrito anteriormente, la especificación de sistemas de MPEG-2 especifica que cada descriptor tiene un campo de etiqueta de descriptor y un campo de longitud descriptor, de 8 bits cada uno. De este modo, el

5

10

15

20

25

30

35

40

45

50

55

60

65

multiplexor 30 (FIG. 1) puede asignar un valor al campo de etiqueta de descriptor 172, indicativo de un descriptor de punto de operación de MVC. El multiplexor 30 también puede determinar un número de vistas para el punto de operación y un número de bits reservados para el descriptor de punto de operación y luego calcular la longitud del descriptor de punto de operación 170 en octetos a continuación del campo de longitud de descriptor 174. El multiplexor 30 asigna este valor de longitud calculado al campo de longitud del descriptor 174 al instanciar el descriptor de punto de operación 140.

[0145] El campo idc_perfil 176 puede comprender un campo de ocho bits que indica el idc_perfil del punto de

operación re-ensamblado por la información dada en el descriptor de punto de operación 170. El campo IDC_nivel 178 puede comprender un campo de ocho bits que indica el idc_nivel del punto de operación re-ensamblado por la información dada en el descriptor de punto de operación 170.

[0146] El campo de velocidad de tramas 180 puede comprender un campo de 16 bits que indica la velocidad máxima de tramas, en tramas / 256 segundos, del flujo de vídeo de AVC re-ensamblado. Es decir, el multiplexor 30 puede calcular la velocidad máxima de tramas de un periodo de tiempo de 256 segundos para establecer el valor del campo de velocidad de tramas 149. Como en el campo de velocidad de tramas 124, en otros ejemplos para el campo de velocidad de tramas 180, pueden usarse otros períodos de tiempo además de 256 segundos.

[0147] El campo del número de vistas de exhibición 182 puede comprender un campo de diez bits que indica el valor del número de las vistas destinadas a la salida, del flujo de vídeo de AVC re-ensamblado. En general, el campo del número de vistas de exhibición 182 representa un número de vistas a exhibir para un punto de operación correspondiente. El campo del número de vistas de decodificación 184 puede comprender un campo de diez bits que indica el valor del número de vistas requerido para decodificar el flujo de vídeo de AVC re-ensamblado. Este valor puede diferir del número de vistas a exhibir, indicado por el campo del número de vistas de exhibición 182. Esto puede resultar por ser requeridas ciertas vistas para la decodificación, debido a las dependencias de las vistas, pero que no se exhiben realmente, por ejemplo, como se ha descrito anteriormente con respecto al campo del número de vistas de decodificación 128.

[0148] El campo de velocidad media de bits 186 puede comprender un campo de dieciséis bits que indica la velocidad media de bits, en kilobits por segundo, del flujo de vídeo de AVC re-ensamblado. Cuando se fija en 0, la velocidad media de bits no está indicada. Es decir, un valor de cero para el campo de velocidad media de bits 186 implica que el campo de velocidad media de bits 186 no debería usarse para determinar la velocidad media de bits del flujo de vídeo de AVC re-ensamblado. El campo de velocidad máxima de bits 188 puede comprender un campo de dieciséis bits que indica la velocidad máxima de bits, en kbits por segundo, del flujo de vídeo de AVC reensamblado. Cuando se fija en 0, la velocidad máxima de bits no está indicada. En particular, cuando el valor del campo de velocidad máxima de bits 188 se fija en cero, no se debería utilizar el campo de velocidad máxima de bits 188 para determinar la velocidad máxima de bits del flujo de vídeo de AVC re-ensamblado.

[0149] El campo de identificador temporal 190 puede comprender un campo de tres bits que indica el valor del id_temporal, correspondiente a la velocidad de tramas del flujo de vídeo de AVC re-ensamblado. Es decir, se puede usar el id_temporal para determinar la velocidad de tramas del flujo de vídeo de AVC re-ensamblado, como se ha expuesto anteriormente. El campo de bit reservado 192 corresponde a un solo bit que está reservado para uso futuro.

[0150] El descriptor de punto de operación 170 también incluye el campo identificador de punto de operación 194 y el campo indicador dependiente del punto de operación 196. El campo identificador de punto de operación 194 puede comprender un campo de diez bits que indica el identificador del punto de operación descrito por el descriptor de punto de operación 170. El campo indicador dependiente del punto de operación 196 es un indicador de un solo bit que indica si se señaliza una dependencia del punto de operación actual con respecto a otro punto de operación. Si el indicador dependiente del punto de operación 196 tiene un valor de uno (o verdadero), se señaliza la dependencia; si el valor del indicador dependiente del punto de operación 196 es cero (o falso), la dependencia no se señaliza.

[0151] Cuando el valor del indicador dependiente del punto de operación 196 es verdadera o uno, el descriptor de punto de operación 170 incluye, además, el campo identificador de punto de operación dependiente 198. Cuando está presente, el campo identificador de punto de operación 198 puede comprender un campo de diez bits que indica el identificador del punto de operación del que depende el descriptor actual. Es decir, cuando el multiplexor 30 determina que el descriptor de punto de operación 170 corresponde a un punto de operación que depende de otro punto de operación, el multiplexor 30 fija el valor del indicador de dependencia de punto de operación en verdadero o uno, y luego señaliza el identificador del punto de operación del cual depende el punto de operación correspondiente al descriptor de punto de operación 170.

[0152] El descriptor de punto de operación 170 también incluye los campos de índice de orden de vista 200 y los campos identificadores de vista 202. Cada uno de los campos de índice de orden de vista 202 puede comprender un campo de diez bits que indica el valor del índice de orden de vista de las unidades de NAL contenidas en el punto de operación actual con un identificador de id_punto_operación, pero no contenidas en el punto de operación con un

5

10

15

20

25

30

35

identificador id_punto_operación_dependiente. Un dispositivo cliente puede volver a ensamblar las unidades de NAL correspondientes a todos los valores señalizados de índice_orden_vista, señalizados en el descriptor de punto de operación 170 por los campos de índice de orden de vista 200. Los campos de índice de orden de vista 200 incluyen los campos de índice de orden de vista para cada una de las vistas a decodificar. Dado un valor de índice_orden_vista, un dispositivo cliente puede extraer las unidades de NAL correspondientes de los flujos elementales porque el descriptor de extensión de MVC indica el rango de los valores del índice de orden de vista en ese flujo elemental y el intervalo abarca el valor de índice_orden_vista señalizado en el descriptor de punto de operación. El punto de operación señalizado en el descriptor de punto de operación 170 es re-ensamblado por las unidades de NAL correspondientes a todos los valores de índice_orden_vista señalizados de los campos de índice de orden de vista 200 y las unidades de NAL contenidas por el punto de operación con identificador de id_punto_operación_dependiente.

[0153] Cada uno de los campos identificadores de vista 202 puede comprender un campo de diez bits que indica el valor del id_vista de las unidades de NAL contenidas en el flujo de bits de vídeo de AVC re-ensamblado. De este modo, los identificadores de vista de cada vista exhibida para un punto de operación se señalizan usando campos identificadores de vistas 202. Es decir, los identificadores de vistas de los campos identificadores de vistas 164 corresponden a las vistas exhibidas. De este modo, las vistas que se decodifican pero que no se exhiben no están señalizadas por los campos identificadores de vistas 202, en el ejemplo de la FIG. 5.

[0154] El descriptor de punto de operación 170 también incluye los campos de bits de cola reservados 204. El descriptor de punto de operación 170 puede incluir bits de cola como relleno, de tal manera que el número de bits en el descriptor de punto de operación 170 sea exactamente divisible entre ocho. Debido a que el número de campos de índice de orden de vista y de campos identificadores de vista puede variar, el número de bits de cola que el multiplexor 30 incluye en el descriptor de punto de operación 170 puede variar en consecuencia. Por ejemplo, el número de bits de cola se puede determinar de acuerdo a la siguiente fórmula

bits de cola = (6 * (núm_vistas_exhibición + núm_vistas_decodificación)) % 8 donde '%' representa el operador de módulo.

[0155] La Tabla 6 a continuación resume un conjunto ejemplar de datos que se pueden incluir en el descriptor ejemplar de punto de operación 170 de la FIG. 6

TABLA 6-üescriptor de punto de operación de MVC

Sintaxis: N° de bits Abreviatura

descriptor op MVC () {

etiqueta_descriptor: 8 uimsbf

longitud_descriptor: 8 uimsbf

idc_perfil: 8 uimsbf

idc_nivel: 8 uimsbf

velocidad de tramas: 16 uimsbf

núm_vistas_exhibición: 10 uimsbf

núm_vistas_decodificación: 10 uimsbf

velocidad_media_bits: 16

velocidad_máxima_bits: 16 uimsbf

id_temporal: 3 uimsbf

bit_reservado: 1 bslbf

id_punto_operación: 10 uimsbf

indicador_dependiente_op: 1 bslbf

if (indicador_dependiente_op)

id_punto_operación_dependiente: 10 10

for(i = 0; i <= núm_vistas_decodificación; i++) {

Sintaxis: N° de bits Abreviatura

índice_orden_vista: 10 uimsbf

}

for(i = 0; i <= núm_vistas_exhibición; i++) {

id_vista: 10 uimsbf

}

for (i = 0 ; i < 6*(núm vistas exhibición + núm vistas decodificación) % 8; i++) {

bit_reservado: 1 bslbf

}

}

5

10

Sintaxis: N° de bits Abreviatura

descriptor_extensión_MVC () {

etiqueta_descriptor: 8 uimsbf

longitud_descriptor: 8 uimsbf

velocidad de tramas: 16 uimsbf

núm_vistas_exhibición: 16 uimsbf

núm_vistas_decodificación: 10 uimsbf

for (i = 0 ; i< núm_vistas_exhibición; i++) {

id_vista: 10 uimsbf

}

velocidad_media_bits: 16 uimsbf

velocidad_máxima_bits: 16 uimsbf

reservado: 4 bslbf

mín_índice_orden_vista: 10 bslbf

máx_índice_orden_vista: 10 bslbf

inicio_id_temporal: 3 bslbf

fin_id_temporal: 3 bslbf

ninguna_unidad_nal_sei_presente: 1 bslbf

reservado: 1 bslbf

}

[0157] El multiplexor 30 (FIG. 2) puede construir descriptores de extensión de MVC 110 de acuerdo a la sintaxis

[0156] Como otra alternativa más, el dispositivo de origen 20 (FIG. 1) señaliza características de un punto de operación usando una estructura de datos distinta a un descriptor de punto de operación. Por ejemplo, el dispositivo de origen 20 puede señalizar un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo receptor para utilizar el punto de operación de MVC, un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para usar el punto de operación de MVC y un valor de velocidad de bits que describe una velocidad de bits del punto de operación de MVC, utilizando un descriptor de extensión de MVC modificado. La Tabla 7 a continuación ilustra un ejemplo de un descriptor de extensión MVC modificado de ese tipo.

Tabla 7-üescriptor de extensión de MVC

5

10

15

20

25

30

35

40

45

50

55

definida por la Tabla 7. En general, la semántica de los elementos sintácticos de la Tabla 7 es la misma que la de los elementos comúnmente designados, descritos con respecto a la Tabla 1 anterior. El ejemplo de la Tabla 7 incluye elementos adicionales además de los de la Tabla 1, a saber, un campo de velocidad de tramas, un campo de número de vistas de visualización, un campo número de vistas de decodificación y campos identificadores de vistas para cada vista de un punto de operación al que corresponde el descriptor de extensión de MVC.

[0158] El campo de velocidad de tramas puede comprender un campo de dieciséis bits que indica la velocidad máxima de tramas, en tramas / 256 segundos del flujo de vídeo de AVC re-ensamblado. El campo del número de vistas de exhibición "núm_vistas_exhibición" puede comprender un campo de diez bits que indica el valor del número de las vistas, destinadas a la salida, del flujo de vídeo de AVC re-ensamblado. El campo del número de vistas de decodificación "núm_vistas_decodificación" puede comprender un campo de diez bits que indica el valor del número de las vistas, necesarias para la decodificación del flujo de vídeo de AVC re-ensamblado. Cada uno de los campos identificadores de vista "id_vista" puede comprender un campo de diez bits que indica el valor del id_vista de las unidades de NAL para una vista correspondiente contenida en el flujo de bits de vídeo de AVC reensamblado.

[0159] En algunos ejemplos, uno o más descriptores de punto de funcionamiento pueden incluir valores que indican un valor máximo del identificador_temporal y un valor de velocidad máxima de tramas de todos los puntos de operación de MVC de un flujo de bits. En algunos ejemplos, el valor del identificador temporal máximo y el valor de la velocidad máxima de tramas de todos los puntos de operación de MVC del flujo de bits se pueden señalizar en un descriptor de punto de operación de MVC.

[0160] La FIG. 7 es un diagrama conceptual que ilustra un patrón ejemplar de predicción de la MVC. En el ejemplo de la FIG. 7, se ilustran ocho vistas (con Identificadores de vista "S0" a "S7") y se ilustran doce ubicaciones temporales ("T0" a "T11") para cada vista. Es decir, cada fila en la FIG. 7 corresponde a una vista, mientras que cada columna indica una ubicación temporal.

[0161] Aunque la MVC tiene una denominada vista de base que es decodificable mediante los decodificadores de la H.264/AVC y el par de vistas estéreo podría tener soporte también por parte de la MVC, la ventaja de MVC es que podría prestar soporte a un ejemplo que usa más de dos vistas como una entrada de vídeo tridimensional y que decodifica este vídeo tridimensional representado por las múltiples vistas. Un representador de un cliente que tiene un decodificador de MVC puede esperar contenido de vídeo tridimensional con múltiples vistas.

[0162] Las tramas en la FIG. 7 se indican en la indicación de cada fila y cada columna en la FIG. 7 usando un bloque sombreado que incluye una letra, que designa si la trama correspondiente está intra-codificada (es decir, una trama-I), o inter-codificada en una dirección (es decir, como una trama-P) o en múltiples direcciones (es decir, como una trama-B). En general, las predicciones se indican mediante flechas, donde la trama a la que se apunta utiliza el objeto desde el que se apunta como referencia de predicción. Por ejemplo, la trama-P de la vista S2 en la ubicación temporal T0 se predice a partir de la trama-I de la vista S0 en la ubicación temporal T0.

[0163] Al igual que con la codificación de vídeo de vista única, las tramas de una secuencia de vídeo de codificación de vídeo multi-vista pueden codificarse predictivamente con respecto a las tramas en diferentes ubicaciones temporales. Por ejemplo, la trama-B de la vista S0 en la ubicación temporal T1 tiene una flecha apuntando a la misma desde la trama-I de la vista S0 en la ubicación temporal T0, lo cual indica que la trama-B se predice a partir de la trama-I. Adicionalmente, sin embargo, en el contexto de la codificación de vídeo multivista, las tramas pueden predecirse entre vistas. Es decir, un componente de vista puede utilizar los componentes de vista en otras vistas como referencia. En la MVC, por ejemplo, la predicción entre vistas se realiza como si el componente de vista en otra vista es una referencia de inter-predicción. Las posibles referencias entre vistas se señalizan en la extensión de la norma MVC del conjunto de parámetros de secuencia (SPS) y pueden ser modificadas por el proceso de construcción de la lista de imágenes de referencia, que habilita el ordenamiento flexible de las referencias de interpredicción o de predicción entre vistas. La Tabla 8 a continuación proporciona una definición ejemplar de un conjunto de parámetros de secuencia de extensión de MVC.

tabla 8

extensión_mvc_conjunto_parámetros_sec() {: C Descriptor

núm_vistas_menos1: 0 ue(v)

for(i = 0; i <= núm_vistas_menos1; i++)

id_vista[i]: 0 ue(v)

for(i = 1; i <= núm_vistas_menos1; i++) {

núm_refs_anclaje_10 [i]: 0 ue(v)

for(j = 0; j < núm_refs_anclaje_10[i]; j++)

ref_anclaje_10[i][j]: 0 ue(v)

núm_refs_anclaje_11 [i]: 0 ue(v)

for(j = 0; j < núm_refs_no_anclaje_10[i]; j++)

ref_anc l aj e_11[i][j]: 0 ue(v)

}

for(i = 1; i <= núm_vistas_menos1; i++) {

núm_refs_no_anclaje_10[i]: 0 ue(v)

for(j = 0; j < núm_refs_no_anclaje_10[i]; j++)

ref_no_anclaje_10[i][j]: 0 ue(v)

núm_refs_no_anclaje 11 [i]: 0 ue(v)

for(j = 0; j < núm_refs_no_anclaje_10[i]; j++)

ref_no_anclaje_l1 [i][j]: 0 ue(v)

}

núm_valores_nivel_señalizados_menos_1: 0 ue(v)

for(i = 0; i<= núm_valores_nivel_señalizados_menos_1; i++) {

idc_nivel [i]: 0 u(8)

núm_ops_aplicables_menos1 [i]: 0 ue(v)

for(j = 0; j <= núm_ops_aplicables_menos1[i]; j++) {

id_temporal_op_aplicable[i][j]: 0 u(3)

op_aplicable_núm_vistas_destino_menos1 [i] [j]: 0 ue(v)

for(k = 0; k <= op_aplicable_núm_vistas_destino_menos1[i][j]; k++)

op_aplicable_id_vista_destino[i][j][k]: 0 ue(v)

op_aplicable_núm_vistas_menos1[i][j]: 0 ue(v)

}

}

}

[0164] La FIG. 7 proporciona varios ejemplos de predicción entre vistas. Las tramas de la vista S1, en el ejemplo de la FIG. 7, se ilustran como predichas a partir de tramas en diferentes ubicaciones temporales de la vista S1, así como predichas entre vistas a partir de tramas de las tramas de las vistas S0 y S2 en las mismas ubicaciones

5 temporales. Por ejemplo, la trama-B de la vista S1 en la ubicación temporal T1 se predice a partir de cada una de las tramas-B de la vista S1 en las ubicaciones temporales T0 y T2, así como las tramas-B de las vistas S0 y S2 en la ubicación temporal T1.

[0165] En el ejemplo de la FIG. 7, la letra "B" mayúscula y la "b" minúscula están concebidas para indicar diferentes 10 relaciones jerárquicas entre las tramas, en lugar de diferentes metodologías de codificación. En general, las tramas

con "B" mayúscula están relativamente más altas en la jerarquía de predicción que las tramas con "b" minúscula. La FIG. 7 también ilustra las variaciones en la jerarquía de predicción utilizando diferentes niveles de sombreado, donde las tramas con una mayor magnitud de sombreado (es decir, relativamente más oscuras) están más altas en la jerarquía de predicción que aquellas tramas que tienen menos sombreado (es decir, relativamente más claras). Por 15 ejemplo, todas las tramas-I en la FIG. 7 se ilustran con sombreado completo, mientras que las tramas-P tienen un sombreado algo más claro, y las tramas-B (y las tramas con b minúscula) tienen diversos niveles de sombreado entre sí, pero siempre más claros que el sombreado de las tramas-P y las tramas-I.

[0166] En general, la jerarquía de predicción se relaciona con índices del orden de vista, en cuanto a que las tramas 20 relativamente más altas en la jerarquía de predicción deberían ser decodificadas antes de la decodificación de

5

10

15

20

25

30

35

40

45

50

55

tramas que están relativamente más bajas en la jerarquía, de tal modo que esas tramas relativamente más altas en la jerarquía se puedan utilizar como tramas de referencia durante la decodificación de las tramas relativamente más bajas en la jerarquía. Un índice de orden de vista es un índice que indica el orden de decodificación de componentes de vista en una unidad de acceso. Los índices de orden de vista están implícitos en la ampliación de MVC del SPS, como se especifica en el anexo H de la H.264/AVC (enmienda de MVC). En el SPS, para cada índice i, se señaliza el correspondiente id_vista. La decodificación de los componentes de vista seguirá el orden ascendente del índice de orden de vista. Si se presentan todas las vistas, entonces los índices de orden de vista están en un orden consecutivo de 0 a núm_vistas_menos_1.

[0167] De esta manera, las tramas utilizadas como tramas de referencia pueden ser decodificadas antes de la decodificación de las tramas que se codifican con referencia a las tramas de referencia. Un índice de orden de vista es un índice que indica el orden de decodificación de componentes de vista en una unidad de acceso. Para cada índice i de orden de vista, se señaliza el id_vista correspondiente. La decodificación de los componentes de vista sigue el orden ascendente de los índices de orden de vista. Si se presentan todas las vistas, entonces el conjunto de índices de orden de vista puede comprender un conjunto consecutivamente ordenado de cero a uno menos que el número total de vistas.

[0168] Para ciertas tramas a niveles iguales de la jerarquía, el orden de decodificación entre ellas puede no importar. Por ejemplo, la trama-I de la vista S0 en la ubicación temporal T0 se utiliza como trama de referencia para la trama-P de la vista S2 en la ubicación temporal T0, que a su vez se utiliza como trama de referencia para la trama-P de la vista S4 en la ubicación temporal T0. En consecuencia, la trama-I de la vista S0 en la ubicación temporal T0 debería decodificarse antes de la trama-P de la vista S2 en la ubicación temporal T0, la cual debería decodificarse antes de la trama-P de la vista S4 en la ubicación temporal T0. Sin embargo, entre las vistas S1 y S3, no importa un orden de decodificación, porque las vistas S1 y S3 no se basan la una en la otra para la predicción, sino que, en cambio, se predicen solo a partir de vistas que están más altas en la jerarquía de predicción. Además, la vista S1 puede decodificarse antes que la vista S4, siempre que la vista S1 sea decodificada después de las vistas S0 y S2.

[0169] De esta manera, puede utilizarse un ordenamiento jerárquico para describir las vistas S0 a S7. Indíquese con la notación SA> SB que la vista SA debería ser decodificada antes que la vista SB. Utilizando esta notación, S0> S2> S4> S6> S7, en el ejemplo de la FIG. 7. También con respecto al ejemplo de la FIG. 7, S0> S1, S2> S1, S2> S3, S4> S3, S4> S5 y S6> S5. Es posible cualquier orden de decodificación para las vistas que no viole estos requisitos. En consecuencia, son posibles muchos órdenes de decodificación diferentes. con solo ciertas limitaciones. A continuación se presentan dos órdenes ejemplares de decodificación, aunque debería entenderse que son posibles muchos otros órdenes de decodificación. En un ejemplo, ilustrado en la Tabla 9 a continuación, las vistas se decodifican lo antes posible.

tabla 9

Identificador vista[i]: de S0 S1 S2 S3 S4 S5 S6 S7

Índice de orden vistas: de 0 2 1 4 3 6 5 7

[0170] El ejemplo de la Tabla 9 reconoce que la vista S1 puede ser decodificada inmediatamente después de que las vistas S0 y S2 hayan sido decodificadas, la vista S3 puede ser decodificada inmediatamente después de que las vistas S2 y S4 se hayan decodificado, y la vista S5 se pueden decodificar inmediatamente después de que las vistas S4 y S6 hayan sido decodificadas.

[0171] La Tabla 10 a continuación proporciona otro orden ejemplar de decodificación en el que el orden de decodificación es tal que cualquier vista que se utilice como referencia para otra vista se decodifica antes de las vistas que no se utilizan como referencia para ninguna otra vista.

tabla 10

Identificador vista[i]: de S0 S1 S2 S3 S4 S5 S6 S7

Índice de orden vistas: de 0 5 1 6 2 7 3 4

[0172] El ejemplo de la Tabla 10 reconoce que las tramas de las vistas S1, S3, S5, y S7 no actúan como tramas de referencia para las tramas de otras vistas y, por tanto, las vistas S1, S3, S5 y S7 puede ser decodificadas después de las tramas de aquellas vistas que se utilizan como tramas de referencia, es decir, la vistas S0, S2, S4 y S6, en el ejemplo de la FIG. 7. Entre sí, las vistas S1, S3, S5 y S7 pueden ser decodificadas en cualquier orden. Por consiguiente, en el ejemplo de la Tabla 10, la vista S7 se decodifica antes de cada una de las vistas S1, S3 y S5.

[0173] Para ser claros, puede haber una relación jerárquica entre las tramas de cada vista, así como las ubicaciones

5

10

15

20

25

30

35

40

45

50

55

60

65

temporales de las tramas de cada vista. Con respecto al ejemplo de la FIG. 7, las tramas en la ubicación temporal T0 son intra-predichas o predichas entre vistas a partir de tramas de otras vistas en la ubicación temporal T0. De manera similar, las tramas en la ubicación temporal T8 son intra-predichas o predichas entre vistas a partir de tramas de otras vistas en la ubicación temporal T8. En consecuencia, con respecto a una jerarquía temporal, las ubicaciones temporales T0 y T8 están en la parte superior de la jerarquía temporal.

[0174] Las tramas en la ubicación temporal T4, en el ejemplo de la FIG. 7, están más abajo en la jerarquía temporal que las tramas de las ubicaciones temporales T0 y T8 porque las tramas de la ubicación temporal T4 son codificadas-B con referencia a las tramas de las ubicaciones temporales T0 y T8. Las tramas en las ubicaciones temporales T2 y T6 están más abajo en la jerarquía temporal que las tramas en la ubicación temporal T4. Finalmente, las tramas en las ubicaciones temporales T1, T3, T5 y T7 están más abajo en la jerarquía temporal que las tramas de las ubicaciones temporales T2 y T6.

[0175] En la MVC, un subconjunto de todo un flujo de bits puede ser extraído para formar un sub-flujo de bits que aún se ajusta a la MVC. Hay muchos posibles sub-flujos de bits que las aplicaciones específicas puedan requerir, sobre la base, por ejemplo, de un servicio proporcionado por un servidor, la capacidad, el apoyo y las capacidades de los decodificadores de uno o más clientes y/o la preferencia de uno o más clientes. Por ejemplo, un cliente podría requerir solo tres vistas, y podría haber dos escenarios. En un ejemplo, un cliente puede requerir una experiencia de exhibición sin fisuras y podría preferir vistas con los valores de id_vista S0, S1 y S2, mientras que otro cliente puede requerir ajustabilidad a escala de las vistas y preferir vistas con los valores de id_vista S0, S2 y S4. Si originalmente se ordenan los id_vista con respecto al ejemplo de la Tabla 9, los valores del índice de orden de vista son {0, 1, 2} y {0, 1, 4} en estos dos ejemplos, respectivamente. Obsérvese que ambos sub-flujos de bits se pueden decodificar como flujos de bits independientes de MVC y pueden disponer de soporte de forma simultánea.

[0176] Puede haber muchos sub-flujos de bits de MVC que son decodificables por los decodificadores de MVC. En teoría, cualquier combinación de vistas que satisface las dos propiedades siguientes puede ser decodificada por un decodificador de MVC compatible con un cierto perfil o nivel: (1) los componentes de vista en cada unidad de acceso se ordenan en un orden creciente del índice de orden de vista y (2) para cada vista en la combinación, sus vistas dependientes también se incluyen en la combinación.

[0177] La FIG. 8 es un diagrama de flujo que ilustra un procedimiento ejemplar para usar una estructura de datos que señaliza características de un punto de operación. Es decir, el procedimiento de la FIG. 8 incluye la construcción de estructuras de datos para cada punto de operación de un flujo de bits de Sistemas de MPEG-2, por un dispositivo de origen, por ejemplo, el dispositivo de origen 20 (FIG. 1). El procedimiento de la FIG. 8 incluye también el uso de estructuras de datos recibidas para seleccionar un punto de operación desde el cual recuperar datos de multimedios a decodificar y exhibir por un dispositivo de destino, tal como el dispositivo de destino 40 (FIG. 1).

[0178] Inicialmente, en el ejemplo de la FIG. 8, el dispositivo de origen 20 determina puntos de operación para un programa (210). Por ejemplo, el dispositivo de origen 20 puede seleccionar varios subconjuntos de vistas de un programa para crear varios puntos de operación que representan dispositivos clientes que tienen diversas capacidades, por ejemplo, capacidades de representación y decodificación. Un administrador puede interactuar con el dispositivo de origen 20, por ejemplo, para seleccionar vistas y crear puntos de operación que representan dispositivos clientes que tienen diversas capacidades de representación y decodificación, o bien diferentes puntos de operación podrían ser creados automáticamente por el dispositivo de origen 20.

[0179] Después de la determinación de los puntos de operación para un programa, el dispositivo de origen 20 puede generar estructuras de datos para cada uno de los puntos de operación en una tabla de mapas de programa (212), por ejemplo, cuando el flujo de bits será difundido como un flujo de transporte de sistemas de MPEG-2. Como alternativa, el dispositivo de origen 20 puede generar las estructuras de datos en un mapa de flujos de programas cuando el flujo de bits se difunda como un flujo de programas de Sistemas de MPEG-2. En cualquier caso, el dispositivo de origen 20 puede generar, para cada punto de operación, una estructura de datos que represente características del punto de operación correspondiente. La estructura de datos puede comprender un descriptor de punto de operación correspondiente a uno de los ejemplos de las FIGs. 4 a 6, por ejemplo. De esta manera, la estructura de datos puede señalizar características de representación, características de decodificación y una velocidad de bits para el punto de operación correspondiente.

[0180] El dispositivo de origen 20 puede emitir entonces las estructuras de datos (214), por ejemplo, dentro de la PMT en el ejemplo de la FIG. 8, a un dispositivo cliente, por ejemplo, el dispositivo de destino 40 (FIG. 1). De esta manera, el dispositivo de origen 20 puede emitir las estructuras de datos como parte del flujo de bits. El dispositivo de origen 20 puede emitir el flujo de bits en forma de un protocolo de difusión, unidifusión, multidifusión, polidifusión u otro protocolo de comunicación por una red, por ejemplo, por una red inalámbrica o cableada, o una emisión por frecuencias de televisión, por ejemplo, según señales conformes a la normas del Comité de Sistemas de Televisión Avanzados (ATSC) o las normas del Comité de Sistemas de Televisión Nacionales (NTSC). Alternativamente, el dispositivo de origen 20 puede codificar el flujo de bits en un medio de almacenamiento legible por ordenador, tal como un DVD-ROM, disco Blu-ray, unidad flash, disco magnético u otro medio de almacenamiento, en cuyo caso el dispositivo de origen 20 puede formar un PSM que incluye las estructuras de datos para los puntos de operación y

5

10

15

20

25

30

35

40

45

50

55

60

65

codificar el PSM en el medio de almacenamiento legible por ordenador.

[0181] El dispositivo de destino 40 puede recibir finalmente la PMT (o el PSM) desde el dispositivo de origen 20 (216). El dispositivo de destino 40 puede entonces seleccionar uno de los puntos de operación basándose en las características de los puntos de operación señalizados por las estructuras de datos incluidas en la PMT o el PSM (218). En general, el dispositivo de destino 40 puede seleccionar un punto de operación para el cual el dispositivo de destino 40 satisface las capacidades de representación y decodificación señalizadas por la estructura de datos correspondiente. Por ejemplo, el dispositivo de destino 40 puede determinar si la salida de vídeo 44 es capaz de representar una serie de vistas indicadas por la estructura de datos como el número de vistas a exhibir, a una velocidad de tramas en conformidad con el valor de las capacidades de representación señalizado por la estructura de datos para el punto de operación. Del mismo modo, el dispositivo de destino 40 puede determinar si el decodificador de vídeo 48 es capaz de decodificar una serie de vistas a decodificar para el punto de operación, según lo señalizado por la estructura de datos de valores de capacidades de decodificación del punto de operación. Además, en algunos ejemplos, el dispositivo de destino 40 puede utilizar la velocidad de bits señalizada en la estructura de datos para seleccionar un punto de operación que sea adecuado para un medio de transporte, por ejemplo, basándose en limitaciones de ancho de banda del medio de transporte desde el cual el dispositivo de destino 40 recibe el flujo de bits.

[0182] Cuando el dispositivo de destino 40 determina que el dispositivo de destino 40 es capaz de representar y decodificar más de un punto de operación, el dispositivo de destino 40 puede seleccionar un punto de operación de la más alta calidad para la decodificación y la representación. Por ejemplo, el dispositivo de destino 40 puede seleccionar un punto de operación que tenga el número de vistas más alto, la velocidad de bits más alta, la velocidad de tramas más alta u otras indicaciones de calidad para un punto de operación, para determinar qué punto de operación seleccionar.

[0183] Después de la selección de un punto de operación, el dispositivo de destino 40 puede recuperar datos para el punto de operación desde el flujo de bits (220). Es decir, el dispositivo de destino 40 puede extraer datos para cada una de las vistas correspondientes al punto de operación a partir del programa incluido en el flujo de bits. En algunos ejemplos, el dispositivo de destino 40 selecciona los datos de uno o más sub-flujos de bits del flujo de bits para extraer datos para el punto de operación. Después de extraer los datos, el dispositivo de destino puede decodificar y exhibir los datos para el punto de operación seleccionado (222). El decodificador de vídeo 48 puede decodificar cada una de las vistas que han de decodificarse para el punto de operación, mientras que la salida de vídeo 44 puede exhibir cada una de las vistas a exhibir para el punto de operación. Las vistas exhibidas pueden no ser necesariamente las vistas que se decodifican, como se ha descrito anteriormente.

[0184] En uno o más ejemplos, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones, como una o más instrucciones o códigos, se pueden almacenar en, o transmitir por, un medio legible por ordenador. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador, tales como medios de almacenamiento de datos o medios de comunicación, incluyendo cualquier medio que facilite la transferencia de un programa informático desde un lugar a otro. Los medios de almacenamiento de datos pueden ser cualquier medio disponible al que se puede acceder desde uno o más ordenadores o uno o más procesadores para recuperar instrucciones, código y/o estructuras de datos para implementar las técnicas descritas en esta divulgación. A modo de ejemplo, y no de manera limitativa, tales medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, memoria flash o cualquier otro medio que pueda usarse para almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador. Además, cualquier conexión recibe adecuadamente la denominación de medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde una sede de la Red, un servidor u otro origen remoto, usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital (DSL) o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas se incluyen en la definición de medio. Debería entenderse, sin embargo, que un medio de almacenamiento legible por ordenador y un medio de almacenamiento de datos no incluyen conexiones, ondas portadoras, señales u otros medios transitorios. Los discos, tal como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde unos discos reproducen usualmente datos de forma magnética, mientras que otros reproducen datos de forma óptica con láser. Las combinaciones de lo anterior se deberían incluir también dentro del alcance de los medios legibles por ordenador.

[0185] Las instrucciones pueden ser ejecutadas por uno o más procesadores, tales como uno o más procesadores de señales digitales (DSP), microprocesadores de propósito general, circuitos integrados específicos de la aplicación (ASIC), formaciones lógicas programables in situ (FPGA) u otros circuitos lógicos equivalentes, integrados o discretos. Por consiguiente, el término "procesador", tal como se usa en el presente documento, puede referirse a cualquiera de las estructuras anteriores o a cualquier otra estructura adecuada para la implementación de las técnicas descritas en el presente documento. Además, en algunos aspectos, la funcionalidad descrita en el presente documento puede proporcionarse dentro de módulos de hardware y/o software dedicados, configurados para la

codificación y la descodificación, o incorporarse en un códec combinado. También, las técnicas podrían implementarse completamente en uno o más circuitos o elementos lógicos.

[0186] Las técnicas de la esta divulgación se pueden implementar en una amplia variedad de dispositivos o 5 aparatos, que incluyen un teléfono inalámbrico, un circuito integrado (CI) o un conjunto de CI (por ejemplo, un

conjunto de chips). En esta divulgación se describen diversos componentes, módulos o unidades para enfatizar aspectos funcionales de dispositivos configurados para realizar las técnicas divulgadas, pero no requieren necesariamente su realización mediante diferentes unidades de hardware. En cambio, como se ha descrito anteriormente, diversas unidades pueden combinarse en una unidad de hardware de códec o proporcionarse 10 mediante un conjunto de unidades de hardware interoperativas, que incluyen uno o más procesadores como los descritos anteriormente, conjuntamente con software y/o firmware adecuados.

[0187] Se han descrito diversos ejemplos. Estos y otros ejemplos están dentro del alcance de las siguientes reivindicaciones.

15

Claims

5

10

15

20

25

30

35

40

45

50

55

60

65

reivindicaciones

Un procedimiento que comprende:

construir, con un dispositivo de origen, una pluralidad de descriptores de puntos de operación de codificación de vídeo multivista (MVC) (114,140), cada uno correspondiente a un punto de operación de MVC, en el que cada descriptor de punto de operación de MVC se inserta en la Tabla de Mapas de Programa (PMT) o los bucles descriptores de Mapas de Flujos de Programa (PSM) de un flujo de bits estándar del sistema de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), en el que cada descriptor de punto de operación de MVC (114, 140) señaliza un valor de capacidad de representación que describe una capacidad de representación que debe satisfacer un dispositivo de recepción para usar el correspondiente punto de operación de MVC, y un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para usar el correspondiente punto de operación de MVC,

en el que el valor de capacidad de representación describe al menos un número de vistas destinadas para representar (150), para el correspondiente punto de operación de MVC, una velocidad de tramas para datos de vídeo (149) del correspondiente punto de operación de MVC, y un valor de identificador temporal (158) para el correspondiente punto de operación de MVC; en el que el valor de la capacidad de decodificación describe al menos un número de vistas a decodificar (152) para el correspondiente punto de operación de MVC, un valor de nivel (148) correspondiente al punto de operación de MVC y un valor de perfil (146) correspondiente al punto de operación de MVC; y

emitir el flujo de bits que comprende la pluralidad de descriptores de puntos de operación de MVC (114, 140).

El procedimiento de la reivindicación 1, en el que la construcción de cada descriptor de punto de operación de MVC comprende construir el descriptor de punto de operación de MVC para hacer que uno o más dispositivos de exhibición bidimensional y dispositivos de exhibición tridimensional adapten el flujo de bits al uno o más dispositivos de exhibición bidimensional y dispositivos de exhibición tridimensional, y para asimilar los medios de transporte de varios anchos de banda al uno o más dispositivos de exhibición bidimensional y dispositivos de exhibición tridimensional.

El procedimiento de la reivindicación 1, en el que la construcción de la pluralidad de descriptores de puntos de operación de MVC comprende construir la pluralidad de descriptores de punto de operación de MVC para señalizar un valor de velocidad de bits que describe una velocidad de bits del correspondiente punto de operación de MVC, en el que el valor de la velocidad de bit describe una velocidad de bit promedia para el correspondiente punto de operación de MVC y la velocidad máxima de bits para el correspondiente punto de operación de MVC.

El procedimiento de la reivindicación 1, en el que la construcción de cada descriptor de punto de operación de MVC comprende:

incluir un valor de velocidad de tramas en el descriptor de punto de operación que describe una velocidad máxima de tramas para datos de vídeo incluidos en un número de vistas para el punto de operación de MVC;

incluir valores de identificador de vista en el descriptor de punto de operación para un número de vistas destinadas a la representación del punto de operación de MVC, en el que cada uno de los valores de identificador de vista corresponde a una de las vistas destinadas a la representación;

incluir valores de identificador de vista en el descriptor de punto de operación para un número de vistas a decodificar para el punto de operación de MVC, en el que cada uno de los valores de identificador de vista corresponde a una de las vistas a decodificar; e

incluir un valor de identificador temporal en el descriptor de punto de operación que corresponde a una velocidad de tramas para un flujo de vídeo ensamblado a partir de datos de vídeo de las vistas para el punto de operación de MVC.

Un aparato que comprende:

medios para construir una pluralidad de descriptores de punto de operación de MVC, cada uno correspondiente a un punto de operación de codificación de vídeo de multivista (MVC), en el que los medios insertan cada descriptor de punto de operación de MVC en los bucles descriptores de la tabla de mapas de programas (PMT) o del mapa de flujos de programa (PSM) de un flujo de bits estándar del sistema de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), en el que cada descriptor de punto de operación de MVC señaliza un valor de capacidad de representación que describe una capacidad de

5

10

15

20

25

30

35

40

45

50

55

60

65

representación que debe satisfacer un dispositivo receptor para utilizar el correspondiente punto de operación de MVC y un valor de capacidad de decodificación que describe una capacidad de decodificación que debe satisfacer el dispositivo receptor para utilizar el correspondiente punto de operación de MVC, en el que el valor de capacidad de representación describe al menos un número de vistas destinadas para representar el correspondiente punto de operación de MVC, una velocidad de tramas para datos de vídeo del correspondiente punto de operación de MVC y un valor de identificador temporal para el correspondiente punto de operación de MVC, en el que el valor de la capacidad de decodificación describe al menos un número de vistas a decodificar para el correspondiente punto de operación de MVC, un valor de nivel correspondiente al punto de operación de MVC y un valor de perfil correspondiente al punto de operación de MVC y

medios para emitir el flujo de bits que comprende la pluralidad de descriptores de puntos de operación de MVC.

El aparato de la reivindicación 5, en el que el medio para construir cada descriptor de MVC comprende además:

medios para incluir un valor de velocidad de tramas en el descriptor de punto de operación que describe una velocidad máxima de tramas para datos de vídeo incluidos en un número de vistas para el punto de operación de MVC;

medios para incluir valores identificadores de vista en el descriptor de punto de operación para una serie de vistas destinadas para la representación del punto de operación de MVC, en el que cada uno de los valores identificadores de vista corresponde a una de las vistas destinadas para la representación;

medios para incluir valores identificadores de vista en el descriptor de punto de operación para un número de vistas a decodificar para el punto de operación de MVC, en el que cada uno de los valores identificadores de vista corresponde a una de las vistas a decodificar; y

medios para incluir un valor de identificador temporal en el descriptor de punto de operación que corresponde a una velocidad de tramas para un flujo de vídeo ensamblado a partir de datos de vídeo de las vistas para el punto de operación de MVC.

El aparato de la reivindicación 5, en el que un multiplexor construye cada descriptor de punto de operación de MVC, y en el que cada punto de operación de MVC corresponde a un subconjunto de un número de vistas del flujo de bits, y en el que para construir cada descriptor de punto de operación de MVC, el multiplexor incluye un valor de velocidad de tramas en el descriptor de punto de operación que describe una velocidad máxima de tramas para los datos de vídeo incluidos en las vistas para el correspondiente punto de operación de MVC, incluye valores identificadores de vista en el descriptor de punto de operación para vistas destinadas para la representación del correspondiente punto de operación de MVC, en el que cada uno de los valores identificadores de vista corresponde a una de las vistas destinadas para la representación, incluye valores identificadores de vista en el descriptor de punto de operación para vistas a decodificar para el correspondiente punto de operación de MVC, en donde cada uno de los valores identificadores de vista corresponde a una de las vistas a decodificar, e incluye un valor identificador temporal en el descriptor de punto de operación que corresponde responde a una velocidad de tramas para un flujo de vídeo ensamblado a partir de los datos de vídeo de las vistas para el correspondiente punto de operación de MVC.

Un procedimiento que comprende:

recibir, con un dispositivo de destino, en bucles de descriptor de una Tabla de Mapas de Programa (PMT) o de un Mapa de Flujos de Programa (PSM) de un flujo de bits estándar del Sistema de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), una pluralidad de descriptores de puntos de operación de codificación de vídeo multivista (MVC), cada uno correspondiente a un punto de operación de MVC, en el que cada descriptor de punto de operación de MVC señaliza un valor de capacidad de representación que describe una capacidad de representación a satisfacer por un dispositivo receptor para utilizar el punto de operación de MVC y un valor de capacidad de decodificación que describe una capacidad de decodificación que el dispositivo receptor debe satisfacer para utilizar el punto de operación de MVC, en el que el valor de capacidad de representación describe al menos un número de vistas destinadas para la representación para el correspondiente punto de operación de MVC, una velocidad de tramas para datos de vídeo del correspondiente punto de operación de MVC y un identificador temporal para los correspondientes puntos de operación de MVC, en el que el valor de capacidad de decodificación describe al menos un número de vistas a decodificar para el correspondiente punto de operación de MVC, un valor de nivel correspondiente al punto de operación de MVC y un valor de perfil correspondiente al punto de operación de MVC;

determinar, para cada descriptor de punto de operación de MVC, si un decodificador de vídeo del dispositivo de destino es capaz de decodificar el número de vistas correspondiente al punto de operación

5

10

15

20

25

30

35

40

45

50

55

60

65

de MVC, basándose en la capacidad de decodificación señalizada por el descriptor de punto de operación de MVC;

determinar, para cada descriptor de punto de operación de MVC, si el dispositivo de destino es capaz de representar las vistas correspondientes al punto de operación de MVC basándose en la capacidad de representación señalizada por el descriptor de punto de operación de MVC;

seleccionar un punto de operación basado en el correspondiente descriptor de punto de operación de MVC, en el que la selección comprende determinar que el decodificador de vídeo es capaz de decodificar y representar vistas correspondientes al punto de operación seleccionado; y

enviar las vistas correspondientes al punto de operación de MVC seleccionado al decodificador de vídeo del dispositivo de destino.

El procedimiento de la reivindicación 8, en el que cada descriptor de punto de operación de MVC comprende un valor de velocidad de tramas que describe una velocidad máxima de tramas para datos de vídeo incluidos en las vistas para el punto de operación de MVC, valores identificadores de vista para un número de vistas destinadas para representación del punto de operación de MVC, en el que cada uno de los valores identificadores de vista corresponde a una de las vistas destinadas para la representación, valores identificadores de vista para un número de vistas a decodificar para el punto de operación de MVC, en el que cada uno de los valores identificadores de vista corresponde a una de las vistas a decodificar, y un valor de identificador temporal que corresponde a una velocidad de tramas para un flujo de vídeo ensamblado a partir de los datos de vídeo de las vistas para el punto de operación de MVC.

El procedimiento de la reivindicación 9, en el que la determinación de si el decodificador de vídeo es capaz de decodificar las vistas comprende determinar si el decodificador de vídeo es capaz de decodificar un número de vistas equivalentes al número de vistas a decodificar a la velocidad de tramas indicada por el valor de la velocidad de tramas.

El procedimiento de la reivindicación 8, en el que el dispositivo de destino está configurado con un número de vistas con soporte que describe un número de vistas con soporte que pueden ser representadas por el dispositivo de destino y un valor de velocidad de tramas que describe una velocidad de tramas de datos de vídeo que pueden ser exhibidos por el dispositivo de destino, en el que la determinación de si el dispositivo de destino es capaz de representar las vistas correspondientes al punto de operación de MVC comprende:

comparar un número de vistas correspondientes al punto de operación de MVC con el número de vistas con soporte; y

comparar una velocidad de tramas de las vistas correspondientes al punto de operación de MVC con el valor de la velocidad de tramas,

en el que enviar las vistas correspondientes al punto de operación de MVC al decodificador de vídeo comprende enviar las vistas correspondientes al punto de operación de MVC al decodificador de vídeo cuando el número de vistas correspondiente al punto de operación de MVC es menor que o igual al número de vistas con soporte y cuando la velocidad de tramas de las vistas correspondientes al punto de operación de MVC es menor que o igual al valor de la velocidad de tramas.

El procedimiento de la reivindicación 11, en el que el número de vistas con soporte es inversamente proporcional al valor de la velocidad de tramas.

Un aparato que comprende:

medios para recibir una pluralidad de descriptores de puntos de funcionamiento de MVC en bucles descriptores de una Tabla de Mapas de Programa (PMT) o un Mapa de Flujos de Programa (PSM) de un flujo de bits estándar del Sistema de MPEG-2 (Grupo de Expertos en Imágenes en Movimiento), correspondiendo cada descriptor de punto de operación de MVC a un punto de operación de MVC, en el que cada descriptor de punto de operación de MVC señaliza un valor de capacidad de representación que describe una capacidad de representación a satisfacer por un dispositivo receptor para usar el punto de operación de MVC y un valor de capacidad de decodificación que describe una capacidad de decodificación a satisfacer por el dispositivo receptor para utilizar el punto de operación de MVC, describiendo el valor de capacidad de representación al menos un número de vistas destinadas para la representación para el correspondiente punto de operación de MVC, una velocidad de tramas para datos de vídeo del correspondiente punto de operación de MVC, un valor de identificador temporal para el correspondiente punto de operación de MVC; describiendo el valor de la capacidad de decodificación al menos un número de vistas a decodificar para el correspondiente punto de operación de MVC, un valor de nivel correspondiente al punto de operación de MVC y un valor de perfil correspondiente al punto de operación de MVC;

medios para determinar, para cada descriptor de punto de operación de MVC, si un decodificador de vídeo del aparato es capaz de decodificar un número de vistas correspondientes al punto de operación de MVC basándose en la capacidad de decodificación señalizada por el descriptor de MVC;

medios para determinar, para cada descriptor de punto de operación de MVC, si el aparato es capaz de representar las vistas correspondientes al punto de operación de MVC basándose en la capacidad de representación señalizada por el descriptor de MVC;

10 medios para seleccionar un punto de operación basado en el correspondiente descriptor de punto de

operación de MVC, en el que la selección comprende determinar que el decodificador de vídeo es capaz de decodificar y representar vistas correspondientes al punto de operación seleccionado; y

medios para enviar las vistas correspondientes al punto de operación de MVC seleccionado al 15 decodificador de vídeo del aparato.
14. Un medio de almacenamiento legible por ordenador que comprende instrucciones que, cuando son ejecutadas, hacen que un procesador de un dispositivo de destino lleve a cabo el procedimiento de cualquiera de las reivindicaciones 8 a 12.

20
15. Un medio de almacenamiento legible por ordenador que comprende instrucciones que, cuando son ejecutadas, hacen que un procesador de un dispositivo de origen lleve a cabo el procedimiento de cualquiera de las reivindicaciones 1 a 4.