ES3037305T3 - Segment types as delimiters and addressable resource identifiers - Google Patents

Abstract

Un dispositivo de ejemplo para procesar datos multimedia está configurado para analizar un flujo de bits que incluye los datos multimedia, formateado según el Formato Común de Aplicación de Medios (CMAF), detectar, durante el análisis, un valor de tipo de archivo (FTYP) para un archivo de pista CMAF del flujo de bits, determinar que el encabezado CMAF del archivo de pista CMAF comience con el valor FTYP y procesar uno o más fragmentos CMAF posteriores al encabezado CMAF del archivo de pista CMAF. El dispositivo también puede configurarse para detectar uno o más valores de tipo de segmento (STYP) en el flujo de bits, determinar que cada uno de estos valores STYP corresponde al inicio de uno de los fragmentos CMAF y procesar cada fragmento CMAF a partir del valor STYP correspondiente. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Tipos de segmentos como delimitadores e identificadores de recursos direccionables

CAMPO TÉCNICO

La presente descripción se refiere al almacenamiento y el transporte de datos multimedia.

ANTECEDENTES

Las capacidades de vídeo digital pueden incorporarse en una amplia variedad de dispositivos, que incluyen televisiones digitales, sistemas de difusión directa digital, sistemas de difusión inalámbrica, asistentes digitales personales(Personal Digital Assistants,PDA), ordenadores portátiles y de sobremesa, cámaras digitales, dispositivos de grabación digital, reproductores multimedia digitales, dispositivos de videojuegos, consolas de videojuegos, radioteléfonos celulares o por satélite, dispositivos de teleconferencia por vídeo, y similares. Los dispositivos de vídeo digitales implementan técnicas de compresión de vídeo, 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 de vídeo avanzada(Advanced Video Coding,AVC), ITU-T H.265 (también conocida como codificación de vídeo de alta eficiencia(High Efficiency Video Coding,HEVC)), y extensiones de dichas normas, para transmitir y recibir información de vídeo digital de forma más eficaz.

Una vez codificados los datos multimedia, los datos multimedia pueden empaquetarse para su transmisión o almacenamiento. Los datos multimedia pueden ensamblarse en un archivo de vídeo según distintas normas, como el formato de archivo multimedia base de la Organización Internacional de Normalización(International Organization for Standardizaron,ISO) y extensiones de este, como AVC.

"CMAF Conformance Checks" de Waqar Zia y col., 118a Reunión del MPEG, 3 a 7 de abril de 2017, Hobart, M40598 de 30 de marzo de 2017, "DASH and CAMF: Referencing Common Segment Formats" de Thomas Stockhammer, 117a Reunión del MPEG, 16 a 20 de enero de 2017, Ginebra, M39926 de 12 de enero de 2017 y el documento US 2012/185607 dan ejemplos del uso de los valores ftyp y styp como marcas para archivos y segmentos en ISOBMFF o DASH.

RESUMEN

En general, la presente descripción describe técnicas para el uso de tipos de datos (por ejemplo, tipos de segmentos y tipos de archivos) como delimitadores, indicadores de tipo e indicadores de entrega. Estas técnicas pueden permitir el uso de estos tipos de datos de manera flexible y sencilla para proporcionar cualquiera o todas estas indicaciones. De esta manera, el contenido generado puede utilizarse en diferentes entornos de entrega y/o consumo, pero también permite su empaquetado, como se analiza en mayor detalle a continuación.

El alcance de la presente invención se define por el alcance de las reivindicaciones adjuntas.

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

BREVE DESCRIPCIÓN DE LOS DIBUJOS

La FIG. 1 es un diagrama de bloques que ilustra un sistema de ejemplo que implementa técnicas para emisión en continuo de datos multimedia a través de una red.

La FIG. 2 es un diagrama de bloques que ilustra un conjunto de componentes de ejemplo de unidad de recuperación de la FIG. 1 en mayor detalle.

La FIG. 3 es un diagrama conceptual que ilustra elementos de un ejemplo de contenido multimedia.

La FIG. 4 es un diagrama de bloques que ilustra elementos de un archivo de vídeo de ejemplo, que puede corresponder a un segmento de una representación.

La FIG. 5 es un diagrama conceptual que ilustra un fragmento de formato de aplicación de medios comunes(Common Media Application Format,CMAF) de ejemplo.

La FIG. 6 es un diagrama conceptual que ilustra una pista CMAF de ejemplo.

La FIG. 7 es un diagrama conceptual que ilustra un fragmento CMAF de ejemplo.

Las FIGS. 8A y 8B son diagramas conceptuales que ilustran bloques CMAF de ejemplo.

La FIG. 9 es un diagrama conceptual que ilustra un sistema de ejemplo según las técnicas de la presente descripción.

La FIG. 10 es un diagrama conceptual que ilustra una descomposición de ejemplo dentro de una aplicación WAVE que utiliza API HTML-5 entre la plataforma, el contenido y la aplicación, cada uno de los cuales puede utilizar datos según las técnicas de la presente descripción.

La FIG. 11 es un diagrama conceptual que ilustra una secuencia de cajas de ejemplo y la contención de un bloque CMAF.

La FIG. 12 es un diagrama de flujo que ilustra un procedimiento de ejemplo para generar un flujo de bits según las técnicas de la presente descripción.

La FIG. 13 es un diagrama de flujo que ilustra un ejemplo de un procedimiento de procesamiento de datos multimedia según las técnicas de la presente descripción.

DESCRIPCIÓN DETALLADA

En general, la presente descripción describe técnicas para el uso de tipos de datos (por ejemplo, tipos de segmentos y/o tipos de archivos) como delimitadores, indicadores de tipo e indicadores de entrega.

La transmisión adaptable dinámica por HTTP(Dynamic Adaptive Streaming,DASH) describe el uso de segmentos como contenedores entregables de datos multimedia (por ejemplo, archivos con localizadores uniformes de recursos(Uniform Resource Locators,URL) únicos). Los segmentos tienen un tipo, descrito mediante un elemento de sintaxis "tipo de segmento" o "styp". Los archivos también tienen un tipo de archivo, descrito mediante un elemento de sintaxis "tipo de archivo" o "ftyp". Dichos elementos de sintaxis pueden formar parte de la información de formato de archivo según, por ejemplo, el formato de archivo multimedia base ISO(ISO Base Media File Format,ISO BMFF) o una extensión de ISO BMFF.

Un archivo conforme a ISO BMFF o una extensión de ISO BMFF puede incluir, además, datos multimedia formateados según el formato de aplicación multimedia Común(Common Media Application Format,CMAF). El contenido CMAF se utiliza en diferentes etapas: en la etapa de preparación de contenido, a nivel de entrega y en la etapa de consumo de contenido (por ejemplo, para una interfaz con un dispositivo receptor, como una interfaz de extensión de fuente de medios(Media Source Extension,MSE)).

En general, las estructuras de datos CMAF se identifican sin un archivo de manifiesto, como una descripción de presentación multimedia(Media Presentation Description,MDP) DASH. Después de la preparación del contenido, generalmente se incluyen delimitadores en flujos/archivos de bytes para identificar las estructuras de datos CMAF. A nivel de entrega, los tipos de objetos entregados deben ser identificables. Como interfaces para los motores de reproducción, tales como MSE, pueden identificarse estructuras de datos para su extracción, por ejemplo, para permitir la reproducción y el cambio entre distintas pistas CMAF. En general, la identificación de las estructuras de datos CMAF debe ser sencilla y seguir la estructura CMAF.

Las técnicas de esta descripción pueden aplicarse a archivos de vídeo según los datos de vídeo encapsulados según cualquiera de los formatos de archivo multimedia base de la ISO, codificación de vídeo escalable(Scalable Video Coding,SVC), codificación de vídeo avanzada(Advanced Video Coding,AVC), proyecto de colaboración de 3a generación(Third Generation Partnership Project,3GPP) y/o codificación de vídeo multivista(Multiview Video Coding,MVC), u otros formatos similares de archivos de vídeo.

En la emisión en continuo HTTP, las operaciones utilizadas con frecuencia incluyen HEAD, GET y GET parcial. La operación HEAD recupera un encabezado de un archivo asociado con un localizador uniforme de recursos(Uniform Resource Locator,URL) dado o con un nombre uniforme de recursos(Uniform Resource Name,URN), sin recuperación de una carga útil asociada con el URL o el URN. La operación GET recupera un archivo completo asociado con un URL o un URN dado. La operación GET parcial recibe un intervalo de bytes como parámetro de entrada y recupera un número continuo de bytes de un archivo, donde el número de bytes corresponde al intervalo de bytes recibido. Así, pueden proporcionarse fragmentos de película para emisión en continuo HTTP, dado que una operación GET parcial puede obtener uno o más fragmentos de película individuales. En un fragmento de película puede haber varios fragmentos de pista de pistas diferentes. En emisión en continuo HTTP, una presentación multimedia puede ser una colección de datos estructurada que es accesible para el cliente. El cliente puede solicitar y descargar información de datos multimedia para presentar un servicio de emisión en continuo a un usuario.

En el ejemplo de emisión en continuo de datos 3GPP utilizando emisión en continuo HTTP, puede haber múltiples representaciones para datos de vídeo y/o audio de contenido multimedia. Como se explica más adelante, diferentes representaciones pueden corresponder a distintas características de codificación (por ejemplo, diferentes perfiles o niveles de una norma de codificación de vídeo), diferentes normas de codificación o extensiones de normas de codificación (como extensiones multivista y/o escalables), o diferentes velocidades binarias. La manifestación de estas representaciones puede definirse en una estructura de datos de descripción de presentación multimedia(Media Presentation Description,MDP). Una presentación multimedia puede corresponder a una colección de datos estructurada que es accesible para un dispositivo cliente de emisión en continuo de HTTP. El dispositivo cliente de emisión en continuo de HTTP puede solicitar y descargar información de datos multimedia para presentar un servicio de emisión en continuo a un usuario del dispositivo cliente. Una presentación multimedia puede describirse en la estructura de datos de MPD, que puede incluir actualizaciones de la MPD.

Una presentación multimedia puede contener una secuencia de uno o más periodos. Cada periodo puede extenderse hasta el inicio del siguiente periodo, o hasta el final de la presentación multimedia, en el caso del último periodo. Cada periodo puede contener una o más representaciones para el mismo contenido multimedia. Una representación puede ser una de una serie de versiones codificadas alternativas de audio, vídeo, texto temporizado u otros datos semejantes. Las representaciones pueden diferir por tipos de codificación, por ejemplo, por velocidad binaria, resolución y/o códec para datos de vídeo y velocidad binaria, lenguaje y/o códec para datos de audio. El término representación puede utilizarse para referirse a una sección de datos de audio o vídeo codificados correspondientes a un periodo determinado del contenido multimedia y codificados de una forma particular.

Las representaciones de un periodo en particular pueden asignarse a un grupo indicado por un atributo en la MPD indicativo de un conjunto de adaptaciones al que pertenecen las representaciones. Las representaciones en el mismo conjunto de adaptaciones se consideran en general alternativas entre sí, de manera que un dispositivo cliente puede cambiar de manera dinámica e ininterrumpida entre estas representaciones, por ejemplo, para realizar una adaptación del ancho de banda. Por ejemplo, cada representación de datos de vídeo para un periodo en particular puede asignarse al mismo conjunto de adaptaciones, de manera que puede seleccionarse cualquiera de las representaciones para decodificación de cara a presentar los datos multimedia, tal como datos de vídeo o datos de audio, del contenido multimedia para el periodo correspondiente. El contenido multimedia dentro de un periodo puede representarse ya sea por una representación del grupo 0, si está presente, o por la combinación de como máximo una representación de cada grupo no cero, en algunos ejemplos. Los datos de temporización para cada representación de un periodo pueden expresarse con respecto al tiempo de inicio del periodo.

Una representación puede incluir uno o más segmentos. Cada representación puede incluir un segmento de inicialización, o cada segmento de una representación puede ser de autoinicialización. Cuando está presente, el segmento de inicialización puede contener información de inicialización para acceder a la representación. En general, el segmento de inicialización no contiene datos multimedia. A un segmento puede hacerse referencia exclusivamente mediante un identificador, como un localizador uniforme de recursos(Uniform Resource Locator,URL), un nombre uniforme de recursos(Uniform Resource Name,URN) o un identificador uniforme de recursos(Uniform Resource Identifier,URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD puede proporcionar también intervalos de bytes en forma de un atributo deintervalo,que puede corresponder a los datos para un segmento dentro de un archivo accesible mediante el URL, el URN o el URI.

Pueden seleccionarse diferentes representaciones para la recuperación sustancialmente simultánea para diferentes tipos de datos multimedia. Por ejemplo, un dispositivo cliente puede seleccionar una representación de audio, una representación de vídeo y una representación de texto temporizado a partir de las cuales recuperar los segmentos. En algunos ejemplos, el dispositivo cliente puede seleccionar conjuntos de adaptación particulares para realizar adaptación de ancho de banda. Es decir, el dispositivo cliente puede seleccionar un conjunto de adaptaciones que incluya representaciones de vídeo, un conjunto de adaptaciones que incluya representaciones de audio y/o un conjunto de adaptaciones que incluya texto temporizado. Alternativamente, el dispositivo cliente puede seleccionar conjuntos de adaptaciones para ciertos tipos de medios (por ejemplo, vídeo), y seleccionar directamente representaciones para otros tipos de medios (por ejemplo, audio y/o texto temporizado).

La FIG. 1 es un diagrama de bloques que ilustra un sistema 10 de ejemplo que implementa técnicas para emisión en continuo de datos multimedia a través de una red. En este ejemplo, el sistema 10 incluye el dispositivo de preparación de contenidos 20, el dispositivo servidor 60 y el dispositivo cliente 40. El dispositivo cliente 40 y el dispositivo servidor 60 están acoplados en comunicación por la red 74, que puede comprender Internet. En algunos ejemplos, el dispositivo de preparación de contenidos 20 y el dispositivo servidor 60 también pueden estar acoplados por la red 74 u otra red, o pueden estar acoplados directamente en comunicación. En algunos ejemplos, el dispositivo de preparación de contenidos 20 y el dispositivo servidor 60 pueden comprender el mismo dispositivo.

El dispositivo de preparación de contenidos 20, en el ejemplo de la FIG. 1, comprende una fuente de audio 22 y una fuente de vídeo 24. La fuente de audio 22 puede comprender, por ejemplo, un micrófono que produce señales eléctricas representativas de datos de audio capturados que serán codificados por el codificador de audio 26. Alternativamente, la fuente 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 computarizado o cualquier otra fuente de datos de audio. La fuente de vídeo 24 puede comprender una cámara de vídeo que produce datos de vídeo que serán 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 tal como una fuente gráfica informática o cualquier otra fuente de datos de vídeo. El dispositivo de preparación de contenidos 20 no está acoplado necesariamente en comunicación al dispositivo servidor 60 en todos los ejemplos, pero puede almacenar contenido multimedia en un medio separado que es leído por el dispositivo servidor 60.

Los datos de audio y vídeo en bruto pueden comprender datos analógicos o digitales. Los datos analógicos pueden ser digitalizados antes de ser codificados por el codificador de audio 26 y/o el codificador de vídeo 28. La fuente de audio 22 puede obtener datos de audio de un participante que habla mientras el participante que habla está hablando, y la fuente de vídeo 24 puede obtener simultáneamente datos de vídeo del participante que habla. En otros ejemplos, la fuente de audio 22 puede comprender un medio de almacenamiento legible por ordenador comprendiendo datos de audio almacenados, y la fuente de vídeo 24 puede comprender un medio de almacenamiento legible por ordenador comprendiendo datos de vídeo almacenados. De este modo, las técnicas descritas en esta descripción pueden aplicarse a emisión en continuo en directo, datos de audio y vídeo en tiempo real o datos de audio y vídeo pregrabados y archivados.

Las tramas de audio que corresponden a tramas de vídeo son generalmente tramas de audio que contienen datos de audio que fueron capturados (o generados) por la fuente de audio 22 al mismo tiempo que los datos de vídeo capturados (o generados) por la fuente de vídeo 24 que está contenida en las tramas de vídeo. Por ejemplo, mientras que el participante que habla produce generalmente datos de audio al hablar, la fuente de audio 22 captura los datos de audio, y la fuente de vídeo 24 captura los datos de vídeo del participante que habla al mismo tiempo, es decir, mientras la fuente de audio 22 está capturando los datos de audio. En este caso, una trama de audio puede corresponderse temporalmente con una o más tramas de vídeo en particular. Por consiguiente, una trama de audio que corresponde a una trama de vídeo corresponde generalmente a una situación donde los datos de datos de audio y vídeo fueron capturados al mismo tiempo y para los que 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.

En algunos ejemplos, el codificador de audio 26 puede codificar una marca de tiempo en cada trama de audio codificada que representa un tiempo donde se grabaron los datos de audio para la trama de audio codificada, y de forma similar, el codificador de vídeo 28 puede codificar una marca de tiempo en cada trama de vídeo codificada que representa un tiempo donde se grabaron los datos de vídeo para la trama de vídeo codificada. En estos ejemplos, una trama de audio que corresponde a una trama de vídeo puede comprender una trama de audio comprendiendo una marca de tiempo y una trama de vídeo comprendiendo la misma marca de tiempo. El dispositivo de preparación de contenidos 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 las marcas de tiempo, o que la fuente de audio 22 y la fuente de vídeo 24 pueden utilizar para asociar los datos de audio y vídeo, respectivamente, con una marca de tiempo.

En algunos ejemplos, la fuente de audio 22 puede enviar datos al codificador de audio 26 que corresponden a un tiempo donde se grabaron los datos de audio, y la fuente de vídeo 24 puede enviar datos al codificador de vídeo 28 que corresponden a un tiempo donde se grabaron los datos de vídeo. En algunos ejemplos, el codificador de audio 26 puede codificar un identificador de secuencias en datos de audio codificados para indicar una ordenación temporal relativa de datos de audio codificados pero sin indicar necesariamente un tiempo absoluto donde se grabaron los datos de audio, y de forma similar, el codificador de vídeo 28 puede utilizar también identificadores de secuencias para indicar una ordenación temporal relativa de datos de vídeo codificados. De forma similar, en algunos ejemplos, un identificador de secuencias puede hacerse corresponder o correlacionarse de otro modo con una marca de tiempo.

El codificador de audio 26 produce generalmente un flujo de datos de audio codificados, mientras que el codificador de vídeo 28 produce un flujo de datos de vídeo codificados. Cada flujo de datos individual (ya sea de audio o de vídeo) puede referirse como flujo elemental. Un flujo elemental es un componente único codificado digitalmente (posiblemente comprimido). Por ejemplo, la parte de vídeo o audio codificados de la representación puede ser un flujo elemental. Un flujo elemental puede convertirse en un flujo elemental empaquetado(Packetized Elemental Stream,PES) antes de ser encapsulado en un archivo de vídeo. Dentro de la misma representación, puede utilizarse un ID de flujo para distinguir los paquetes PES que pertenecen a un flujo elemental de otros. La unidad de datos básica de un flujo elemental es un paquete de un flujo elemental empaquetado(Packetized Elemental Stream,PES). Así, los datos de vídeo codificados corresponden en general a flujos de vídeo elementales. De forma similar, los datos de audio corresponden a uno o más flujos elementales respectivos.

Muchas normas de codificación de vídeo, como ITU-T H.264/AVC y la próxima norma de codificación de vídeo de alta eficiencia(High Efficiency Video Coding,HEVC), definen la sintaxis, la semántica y el proceso de decodificación para flujos binarios libres de errores, cualquiera de los cuales se adecuan a un perfil o un nivel determinado. Las normas de codificación de vídeo normalmente no especifican el codificador, si bien el codificador está a cargo de garantizar que los flujos binarios generados cumplen con las normas para un decodificador. En el contexto de las 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 de flujo binario que se especifica en la norma H.264. Un “nivel” corresponde a las limitaciones del consumo de recursos por el decodificador, como, por ejemplo, la memoria del decodificador y la computación, que están relacionados con la resolución de las imágenes, la velocidad binaria y la velocidad de procesamiento de los bloques. Un perfil puede señalizarse con un valor profile_idc (indicador de perfil), mientras que un nivel puede señalizarse con un valor level_idc (indicador de nivel).

La norma H.264 reconoce, por ejemplo, que, dentro de los límites impuestos por la sintaxis de un perfil dado, sigue siendo posible requerir una gran variación en el rendimiento de los codificadores y decodificadores dependiendo de los valores que toman los elementos de sintaxis en el flujo binario como el tamaño especificado de las imágenes decodificadas. La norma H.264 reconoce además que, en muchas aplicaciones, no resulta práctico ni económico implementar un decodificador capaz de manejar todos los usos hipotéticos de la sintaxis dentro de un perfil determinado. Por consiguiente, la norma H.264 define un “nivel” como un conjunto especificado de restricciones impuesto en los valores de los elementos de sintaxis en el flujo binario. Estas restricciones pueden ser simples límites en los valores. Alternativamente, estas restricciones pueden tomar la forma de restricciones en combinaciones aritméticas de valores (por ejemplo, la anchura de la imagen multiplicada por la altura de la imagen multiplicada por el número de imágenes decodificadas por segundo). La norma H.264 proporciona además las implementaciones individuales que pueden soportar un nivel diferente para cada perfil soportado.

Un decodificador acorde con un perfil soporta comúnmente todas las características definidas en el perfil. Por ejemplo, como característica de codificación, la codificación de imágenes B no está soportada en el perfil de base de H.264/AVC sino que está soportada en otros perfiles de H.264/AVC. Un decodificador conforme a un nivel debe ser capaz de decodificar cualquier flujo binario 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 facilidad de interpretación. Por ejemplo, durante una transmisión de vídeo, es posible negociar y acordar un par de definiciones de perfiles y niveles para toda la sesión de transmisión. Más en concreto, en H.264/AVC, un nivel puede definir limitaciones en el número de macrobloques que es preciso procesar, el tamaño de la memoria intermedia de imágenes decodificadas(Decoded Picture Buffer,DPB), el tamaño de la memoria intermedia de imágenes codificadas(Coded Picture Buffer,CPB), el intervalo del vector de movimiento vertical, el número máximo de vectores de movimiento por dos MBS consecutivos, y si un bloque B puede tener divisiones en submacrobloques de menos de 8x8 píxeles. De este modo, un decodificador puede determinar si el decodificador es capaz de decodificar adecuadamente el flujo binario.

En el ejemplo de la FIG. 1, la unidad de encapsulación 30 del dispositivo de preparación de contenidos 20 recibe flujos elementales comprendiendo datos de vídeo codificados del codificador de vídeo 28 y flujos elementales comprendiendo datos de audio codificados 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 estar ambos interconectados con empaquetadores respectivos para formar paquetes PES a partir de datos codificados. En otros ejemplos más, la unidad de encapsulación 30 puede incluir empaquetadores para formar paquetes PES a partir de datos de audio y vídeo codificados.

El codificador de vídeo 28 puede codificar datos de vídeo de contenido multimedia en diversas formas, para producir diferentes representaciones del contenido multimedia a diversas velocidades binarias y con distintas características, como resoluciones de píxeles, velocidades de trama, conformidad con las diversas normas de codificación, conformidad con varios perfiles y/o niveles de perfiles para diversas normas de codificación, las representaciones que tienen una o múltiples vistas (por ejemplo, para reproducción bidimensional o tridimensional) u otras características semejantes. Una representación, como se utiliza en esta descripción, puede comprender uno de entre datos de audio, datos de vídeo, datos de texto (por ejemplo, para subtítulos cerrados) u otros datos semejantes. La representación puede incluir un flujo elemental, tal como un flujo elemental de audio o un flujo elemental de vídeo. Cada paquete PES puede incluir un stream_id (identificador de flujo) que identifica el flujo elemental al que pertenece el paquete PES. La unidad de encapsulación 30 es responsable de ensamblar los flujos elementales en archivos de vídeo (por ejemplo, segmentos) de varias representaciones.

La unidad de encapsulación 30 recibe paquetes PES para flujos elementales de una representación del codificador de audio 26 y el codificador de vídeo 28 y forma unidades correspondientes de capas de abstracción de red(Network Abstraction Layer,NAL) a partir de los paquetes PES. Los segmentos de vídeo codificados pueden organizarse en unidades NAL, que proporcionan una representación de vídeo “respetuosa con la red” que aborda aplicaciones como videotelefonía, almacenamiento, difusión o emisión en continuo. Las unidades NAL pueden clasificarse en unidades NAL de capa de codificación de vídeo(Video Coding Layer,VCL) y unidades NAL no VCL. Las unidades VCL pueden contener el motor de compresión central y pueden incluir datos en los niveles de bloque, macrobloque y/o fragmento. Otras unidades NAL pueden ser unidades NAL no VCL. En algunos ejemplos, una imagen codificada en una instancia temporal, normalmente presentada como imagen codificada primaria, puede estar contenida en una unidad de acceso, que puede incluir una o más unidades NAL.

Las unidades NAL no VCL pueden incluir unidades NAL de conjuntos de parámetros y unidades NAL SEI, entre otras. Los conjuntos de parámetros pueden contener información de encabezado en el nivel de secuencias (en conjuntos de parámetros en secuencia(Sequence Parameter Set,SPS)) e información de encabezado en el nivel de imágenes que cambian con poca frecuencia (en conjuntos de parámetros de imagen(Picture Parameter Set,PPS)). Con conjuntos de parámetros (por ejemplo, PPS y SPS), la formación que cambia con poca frecuencia no debe repetirse para cada secuencia o imagen, y con ello puede mejorarse la eficacia de codificación. Además, la utilización de conjuntos de parámetros puede permitir una transmisión fuera de banda de la información de encabezado importante, lo que evita la necesidad de transmisiones redundantes para resiliencia frente a errores. En los ejemplos de transmisión fuera de banda, las unidades NAL de conjuntos de parámetros pueden transmitirse en un canal diferente al de otras unidades NAL, como las unidades NAL SEI.

La información mejorada suplementaria(Supplemental Enhancement Information,SEI) puede contener información que no es necesaria para decodificar las muestras de imágenes codificadas de las unidades NAL VCL, pero puede ayudar en procesos relacionados con la decodificación, la visualización, la resiliencia frente a errores y otros fines. Los mensajes SEI pueden estar contenidos en unidades NAL no VCL. Los mensajes SEI son la parte normativa de algunas especificaciones estándar, y por tanto no siempre son obligatorios para la implementación del decodificador según las normas. Los mensajes SEI pueden ser mensajes SEI de nivel de secuencia o mensajes SEI de nivel de imagen. Alguna información de nivel de secuencia puede estar contenida en mensajes SEI, como los mensajes SEI de información de escalabilidad en el ejemplo de SVC y mensajes SEI de información de escalabilidad de vista en MVC. Estos mensajes SEI de ejemplo pueden transportar información, por ejemplo, sobre la extracción de puntos de operación y características de los puntos de operación. Además, la unidad de encapsulación 30 puede formar un archivo de manifiesto, como un descriptor de presentación multimedia(Media Presentation Descriptor,MPD) que describe características de las representaciones. La unidad de encapsulación 30 puede formatear el MPD según el lenguaje de marcado extensible(eXtensible Markup Language,XML).

La unidad de encapsulación 30 puede proporcionar datos para una o más representaciones de contenido multimedia, junto con el archivo de manifiesto (por ejemplo, el MPD) para la interfaz de salida 32. La interfaz de salida 32 puede comprender una interfaz de red o una interfaz para escribir en un medio de almacenamiento, como una interfaz de bus en serie universal(Universal Serial Bus,USB), un grabador de CD o DVD, una interfaz con un medio de almacenamiento magnético o flash u otras interfaces para almacenar y transmitir datos multimedia. La unidad de encapsulación 30 puede proporcionar datos de cada una de las representaciones de contenido multimedia para la interfaz de salida 32, que puede enviar los datos al dispositivo servidor 60 a través de transmisión de red o medios de almacenamiento. En el ejemplo de la FIG. 1, el dispositivo servidor 60 incluye un medio de almacenamiento 62 que almacena varios contenidos multimedia 64, cada uno de los cuales incluye un archivo de manifiesto 66 respectivo y una o más representaciones 68A-68N (representaciones 68). En algunos ejemplos, la interfaz de salida 32 también puede enviar datos directamente a la red 74.

En algunos ejemplos, las representaciones 68 pueden separarse en conjuntos de adaptaciones. Es decir, varios subconjuntos de representaciones 68 pueden incluir conjuntos de características comunes respectivos, tales como códec, perfil y nivel, resolución, número de vistas, formato de archivo para segmentos, información de tipo texto que puede identificar un lenguaje u otras características de texto que se visualizarán con la representación y/o datos de audio para su decodificación y presentación, por ejemplo, por altavoces, información de ángulo de cámara que puede describir un ángulo de cámara o una perspectiva de cámara del mundo real de una escena para representaciones en el conjunto de adaptaciones, información de clasificación que describe la idoneidad del contenido para audiencias concretas, o similares.

El archivo de manifiesto 66 puede incluir datos indicativos de los subconjuntos de representaciones 68 que corresponden a conjuntos de adaptación particulares, así como características comunes para los conjuntos de adaptaciones. El archivo de manifiesto 66 puede incluir también datos representativos de características individuales, como velocidades binarias, para representaciones individuales de conjuntos de adaptaciones. De este modo, un conjunto de adaptaciones puede proporcionar una adaptación del ancho de banda de la red simplificada. Las representaciones en un conjunto de adaptaciones pueden indicarse utilizando elementos secundarios de un elemento del conjunto de adaptaciones del archivo de manifiesto 66.

El dispositivo servidor 60 incluye la unidad de procesamiento de peticiones 70 y la interfaz de red 72. En algunos ejemplos, el dispositivo servidor 60 puede incluir una pluralidad de interfaces de red. Además, cualquiera o la totalidad de las características del dispositivo servidor 60 puede implementarse en otros dispositivos de una red de suministro de contenidos, como encaminadores, puentes, dispositivos proxy, conmutadores u otros dispositivos. En algunos ejemplos, los dispositivos intermedios de una red de suministro de contenidos pueden guardar en la memoria caché datos de contenido multimedia 64, e incluir componentes que se adecuan sustancialmente a los del dispositivo servidor 60. En general, la interfaz de red 72 está configurada para enviar y recibir datos a través de la red 74.

La unidad de procesamiento de peticiones 70 está configurada para recibir peticiones de red de dispositivos clientes, como un dispositivo cliente 40, para datos del medio de almacenamiento 62. Por ejemplo, la unidad de procesamiento de peticiones 70 puede implementar el protocolo de transferencia de hipertexto(Hypertext Transfer Protocol,HTTP) versión 1.1, como se describe en RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1”, de R. Fielding y col., Network Working Group, IETF, junio de 1999. Es decir, la unidad de procesamiento de peticiones 70 puede configurarse para recibir peticiones HTTP GET o GET parciales y proporcionar datos de contenido multimedia 64 en respuesta a las peticiones. Las peticiones pueden especificar un segmento de una de las representaciones 68, por ejemplo, utilizando un URL del segmento. En algunos ejemplos, las peticiones pueden especificar también uno o más intervalos de bytes del segmento, comprendiendo así peticiones GET parciales. La unidad de procesamiento de peticiones 70 puede configurarse además para servir peticiones HTTP h Ea D para proporcionar datos de encabezado de un segmento de una de las representaciones 68. En cualquier caso, la unidad de procesamiento de peticiones 70 puede configurarse para procesar las peticiones para proporcionar datos solicitados a un dispositivo de petición, tal como el dispositivo cliente 40.

De forma adicional o alternativa, la unidad de tratamiento de peticiones 70 puede configurarse para suministrar datos multimedia a través de un protocolo de difusión o multidifusión, como eMBMS. El dispositivo de preparación de contenidos 20 puede crear segmentos y/o subsegmentos DASH sustancialmente de la misma forma que se ha descrito, si bien el dispositivo servidor 60 puede suministrar estos segmentos o subsegmentos utilizando eMBMS u otro protocolo de transporte en red de difusión o multidifusión. Por ejemplo, la unidad de procesamiento de peticiones 70 puede configurarse para recibir una petición para unirse al grupo de multidifusión del dispositivo cliente 40. Es decir, el dispositivo servidor 60 puede avisar de una dirección de protocolo Internet(Internet Protocol,IP) asociada con un grupo de multidifusión a dispositivos clientes, que incluyen el dispositivo cliente 40, asociados con un contenido multimedia particular (por ejemplo, una difusión de un evento en directo). A su vez, el dispositivo cliente 40 puede remitir una petición para unirse al grupo de multidifusión. Esta petición puede propagarse por la red 74, por ejemplo, por encaminadores que componen la red 74, de manera que se hace que los encaminadores dirijan el tráfico directo destinado a la dirección IP asociada con el grupo de multidifusión para suscribir dispositivos clientes, como el dispositivo cliente 40.

Como se ilustra en el ejemplo de la FIG. 1, el contenido multimedia 64 incluye el archivo de manifiesto 66, que puede corresponder a una descripción de presentación multimedia(Media Presentation Description,MPD). El archivo de manifiesto 66 puede contener descripciones de diferentes representaciones 68 alternativas (por ejemplo, servicios de vídeo con diferentes calidades) y la descripción puede incluir, por ejemplo, información de códec, un valor de perfil, un valor de nivel, una velocidad binaria, y otras características descriptivas de las representaciones 68. El dispositivo cliente 40 puede recuperar la MPD de una presentación multimedia para determinar cómo acceder a los segmentos de las representaciones 68.

En particular, la unidad de recuperación 52 puede recuperar datos de configuración (no mostrados) del dispositivo cliente 40 para determinar las capacidades de decodificación de decodificador de vídeo 48 y las capacidades de renderización de la salida de vídeo 44. Los datos de configuración pueden incluir también cualquiera o la totalidad de una preferencia de lenguaje seleccionada por un usuario del dispositivo cliente 40, una o más perspectivas de cámara que corresponden a preferencias de profundidad establecidas por el usuario del dispositivo cliente 40 y/o una preferencia de clasificación seleccionada por el usuario del dispositivo cliente 40. La unidad de recuperación 52 puede comprender, por ejemplo, un navegador web o un cliente multimedia configurado para enviar peticiones HTTP GET y GET parciales. La unidad de recuperación 52 puede corresponder a instrucciones de software ejecutadas por uno o más procesadores o unidades de procesamiento (no mostradas) del dispositivo cliente 40. En algunos ejemplos, parte o la totalidad de la funcionalidad descrita con respecto a la unidad de recuperación 52 puede ser implementada en hardware, o una combinación de hardware, software y/o firmware, donde el hardware requerido puede proporcionarse para ejecutar instrucciones para software o firmware.

La unidad de recuperación 52 puede comparar las capacidades de decodificación y renderización del dispositivo cliente 40 con las características de las representaciones 68 indicadas por la información del archivo de manifiesto 66. La unidad de recuperación 52 puede recuperar inicialmente al menos una parte del archivo de manifiesto 66 para determinar las características de las representaciones 68. Por ejemplo, la unidad de recuperación 52 puede solicitar una parte del archivo de manifiesto 66 que describe las características de uno o más conjuntos de adaptaciones. La unidad de recuperación 52 puede seleccionar un subconjunto de representaciones 68 (por ejemplo, un conjunto de adaptaciones) que tiene características que pueden ser satisfechas por las capacidades de codificación y renderización del dispositivo cliente 40. La unidad de recuperación 52 puede determinar a continuación las velocidades binarias de las representaciones en el conjunto de adaptaciones, determinar una cantidad disponible actualmente de ancho de banda de la red y recuperar segmentos de una de las representaciones que tiene una velocidad binaria que pueda ser satisfecha por el ancho de banda de la red.

En general, las representaciones de velocidad binaria más alta pueden producir mayor calidad de reproducción de vídeo, mientras que las representaciones de velocidad binaria más baja pueden proporcionar reproducción de vídeo con suficiente calidad cuando el ancho de banda disponible de la red disminuye. Por consiguiente, cuando el ancho de banda de la red disponible es relativamente alto, la unidad de recuperación 52 puede recuperar datos de representaciones de velocidades binarias relativamente altas, mientras que cuando el ancho de banda disponible de la red es bajo, la unidad de recuperación 52 puede recuperar datos de representaciones de velocidades binarias relativamente bajas. De este modo, el dispositivo cliente 40 puede enviar datos multimedia por la red 74 a la vez que se adapta también a los cambios en la disponibilidad de ancho de banda de red de la red 74.

De forma adicional o alternativa, la unidad de recuperación 52 puede configurarse para recibir datos según un protocolo de red de difusión o multidifusión, como eMBMS o IP multidifusión. En dichos ejemplos, la unidad de recuperación 52 puede enviar una petición para unirse a un grupo de red de multidifusión asociado con un contenido multimedia en particular. Después de unirse al grupo de multidifusión, la unidad de recuperación 52 puede recibir datos del grupo de multidifusión sin peticiones adicionales enviadas al dispositivo servidor 60 o al dispositivo de preparación de contenidos 20. La unidad de recuperación 52 puede enviar una petición para abandonar el grupo de multidifusión cuando los datos del grupo de multidifusión ya no se necesitan, por ejemplo, para interrumpir la reproducción o para cambiar los canales a un grupo de multidifusión diferente.

La interfaz de red 54 puede recibir y proporcionar datos de segmentos de una representación seleccionada a la unidad de recuperación 52, que puede a su vez proporcionar los segmentos a la unidad de desencapsulación 50. La unidad de desencapsulación 50 puede desencapsular los elementos de un archivo de vídeo en flujos PES constituyentes, desempaquetar los flujos PES para recuperar los datos codificados y enviar los datos codificados al decodificador de audio 46 o al decodificador de vídeo 48, dependiendo de si los datos codificados forman parte de un flujo de audio o de vídeo, por ejemplo, como se indica mediante los encabezados de paquetes PES del flujo. El decodificador de audio 46 decodifica los 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 los 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.

El codificador de vídeo 28, el decodificador de vídeo 48, el codificador de audio 26, el decodificador de audio 46, la unidad de encapsulación 30, la unidad de recuperación 52 y la unidad de desencapsulación 50 pueden implementarse cada uno como cualquiera de una diversidad de circuitos de procesamiento adecuados, según resulte aplicable, tales como uno o más microprocesadores, procesadores de señales digitales(Digital Signal Processors,DSP), circuitos integrados específicos de aplicación(Application Specific Integrated Circuits,ASIC), matrices de puertas programables de campo(Field Programmable Gate Arrays,FPGA), circuitos lógicos discretos, software, hardware, firmware o cualquier combinación de los mismos. Cada uno de los codificadores de vídeo 28 y decodificadores de vídeo 48 puede incluirse en uno o más codificadores o decodificadores, cualquiera de los cuales puede integrarse como parte de un codificador/descodificador de vídeo combinado(Combined Video Encoder/Decoder,CODEC). De forma similar, cada uno de entre el codificador de audio 26 y el decodificador de audio 46 puede estar incluido en uno o más codificadores o decodificadores, cualquiera de los cuales puede estar integrado como parte de un 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, una unidad de encapsulación 30, una unidad de recuperación 52 y/o una unidad de desencapsulación 50 puede comprender un circuito integrado, un microprocesador y/o un dispositivo de comunicación inalámbrica, como un teléfono celular.

El dispositivo cliente 40, el dispositivo servidor 60 y/o el dispositivo de preparación de contenidos 20 pueden configurarse para funcionar según las técnicas de esta descripción. Con fines de ejemplo, la presente descripción describe estas técnicas con respecto al dispositivo cliente 40 y al dispositivo servidor 60. Sin embargo, debe entenderse que el dispositivo de preparación de contenidos 20 puede configurarse para realizar estas técnicas, en lugar (o además) del dispositivo servidor 60.

La unidad de encapsulación 30 puede formar unidades NAL comprendiendo un encabezado que identifica un programa al que pertenece la unidad NAL, así como una carga útil, por ejemplo, datos de audio, datos de vídeo o datos que describen el transporte o flujo de programas al que corresponde la unidad NAL. Por ejemplo, en H.264/AVC, una unidad NAL incluye un encabezado de 1 byte y una carga útil de tamaño variable. Una unidad 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 NAL puede comprender un bloque de datos de vídeo, una pluralidad de bloques, un fragmento de datos de vídeo o una imagen completa de datos de vídeo. La unidad de encapsulación 30 puede recibir datos de vídeo codificados del codificador de vídeo 28 en forma de paquetes PES de flujos elementales. La unidad de encapsulación 30 puede asociar cada flujo elemental con un programa correspondiente.

La unidad de encapsulación 30 puede ensamblar también unidades de acceso de una pluralidad de unidades NAL. En general, una unidad de acceso comprende una o más unidades NAL para representar una trama de datos de vídeo, así como datos de audio que corresponden a la trama cuando dichos datos de audio están disponibles. Una unidad de acceso incluye en general todas las unidades NAL para una instancia de tiempo de salida, por ejemplo, todos los datos de audio y vídeo para una instancia de tiempo. Por ejemplo, si cada vista tiene una velocidad de 20 tramas por segundo (tps), entonces cada instancia de tiempo 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 (la misma instancia de tiempo) pueden renderizarse simultáneamente. En un ejemplo, una unidad de acceso comprende una imagen codificada en una instancia de tiempo, que puede presentarse como una imagen codificada primaria.

Por consiguiente, una unidad de acceso comprende todas las tramas de audio y de vídeo de una instancia temporal común, por ejemplo, todas las vistas que corresponden a un tiempo X. Esta descripción se refiere también a una imagen codificada de una vista en 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 tiempo determinado. Por consiguiente, una unidad de acceso se define como aquella comprendiendo todos los componentes de vistas de una instancia temporal común. El orden de decodificación de las unidades de acceso no tiene que ser necesariamente el mismo que el orden de salida o de visualización.

Una presentación multimedia puede incluir una descripción de presentación multimedia(Media Presentation Description,MPD), que puede contener descripciones de diferentes representaciones alternativas (por ejemplo, servicios de vídeo con diferentes calidades) y la descripción puede incluir, por ejemplo, información de códec, un valor de perfil y un valor de nivel. Una MPD es un ejemplo de un archivo de manifiesto, como el archivo de manifiesto 66. El dispositivo cliente 40 puede recuperar la MPD de una presentación multimedia para determinar cómo acceder a fragmentos de película de varias presentaciones. Los fragmentos de película pueden estar situados en cajas de fragmentos de película (cajas moof) de archivos de vídeo.

El archivo de manifiesto 66 (que puede comprender, por ejemplo, una MPD) puede avisar de la disponibilidad de segmentos de representaciones 68. Es decir, la MPD puede incluir información que indica la hora de reloj en que un primer segmento de una de las representaciones 68 se vuelve disponible, así como información que indica las duraciones de los segmentos en las representaciones 68. De este modo, la unidad de recuperación 52 del dispositivo cliente 40 puede determinar cuándo está disponible cada segmento, basándose en el tiempo de inicio así como en las duraciones de los segmentos que preceden a un segmento en particular.

Una vez que la unidad de encapsulación 30 ha ensamblado las unidades NAL y/o las unidades de acceso en un archivo de vídeo basándose en los datos recibidos, la unidad de encapsulación 30 pasa el archivo de vídeo a la interfaz de salida 32 para su salida. En algunos ejemplos, la unidad de encapsulación 30 puede almacenar el archivo de vídeo localmente o enviar el archivo de vídeo a un servidor remoto a través de la interfaz de salida 32, en vez de enviar el archivo de vídeo directamente al dispositivo cliente 40. La interfaz de salida 32 puede comprender, por ejemplo, un transmisor, un transceptor, un dispositivo para escribir datos en un medio legible por ordenador como, por ejemplo, una unidad óptica, una unidad de medios magnéticos (por ejemplo, disco flexible), un puerto de bus en serie universal(Universal Serial Bus,USB), una interfaz de red u otra interfaz de salida. La interfaz de salida 32 envía el archivo de vídeo a un medio legible por ordenador, como, por ejemplo, una señal de transmisión, un medio magnético, un medio óptico, una memoria, una memoria USB u otro medio legible por ordenador.

La interfaz de red 54 puede recibir una unidad NAL o una unidad de acceso a través de la red 74 y proporcionar la unidad NAL o unidad de acceso a la unidad de desencapsulación 50, a través de la unidad de recuperación 52. La unidad de desencapsulación 50 puede desencapsular un elemento de un archivo de vídeo en flujos PES constituyentes, desempaquetar los flujos PES para recuperar los datos codificados y enviar los datos codificados al decodificador de audio 46 o al decodificador de vídeo 48, dependiendo de si los datos codificados forman parte de un flujo de audio o de vídeo, por ejemplo, como se indica mediante los encabezados de paquetes PES del flujo. El decodificador de audio 46 decodifica los 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 los 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.

Según las técnicas de la presente descripción, la unidad de encapsulación 30 puede utilizar un único tipo de señalización para una variedad de propósitos, por ejemplo, cualquiera o la totalidad de una etapa de preparación de contenido, nivel de suministro y/o una etapa de consumo de contenido. De forma similar, la unidad de recuperación 52 puede utilizar este único tipo de señalización para cualquiera o todos estos fines.

En un ejemplo, el único tipo de señalización es una caja de tipo de archivo (ftyp) que incluye un valor que actúa como un identificador para una o más pistas CMAF. Por lo tanto, la unidad de encapsulación 30 puede establecer un valor para la caja ftyp, y la unidad de recuperación 52 puede leer un valor para la caja ftyp. Además, la unidad de procesamiento de peticiones 70 también puede leer el valor de la caja ftyp. Estos componentes pueden usar el valor de la caja ftyp durante parte o la totalidad de la preparación, entrega y/o consumo de contenido.

Adicionalmente, el único tipo de señalización puede ser una caja de tipo de segmento (styp) que incluye un valor que actúa como un identificador para una o más pistas CMAF. La caja styp puede actuar como un delimitador para identificar límites de fragmentos y/o bloques CMAF, identificadores para estructuras de datos CMAF, identificadores para segmentos DASH (o segmentos para otras tecnologías de transmisión de red) y/o como identificadores para requisitos de procesamiento. Por lo tanto, la unidad de encapsulación 30 puede especificar valores para una o más cajas styp de un segmento para representar cualquiera o todos los límites de fragmentos y/o bloques CMAF del segmento, identificadores para estructuras de datos CMAF del segmento, un identificador para el segmento DASH y/o como identificadores para requisitos de procesamiento para datos multimedia del segmento.

La Tabla 1 a continuación representa “marcas” de ejemplo de valores de tipo según las técnicas de la presente descripción, incluidas las ubicaciones de cada tipo de marca y los requisitos de conformidad de ejemplo:

TABLA 1

Las Tablas 2-6 a continuación representan estructuras de datos de ejemplo adicionales que pueden utilizarse según las técnicas de la presente descripción:

TABLA 2-Fi h r i MAF

TABLA 3-Encabezado CMAF

TABLA 4-Se mento CMAF

TABLA 5-Fra mento CMAF

TABLA 6-Blo ue CMAF

Con respecto a la entrega y el consumo, en algunos ejemplos, ftyp y styp proporcionan indicaciones de la compatibilidad del tipo y cómo puede utilizarse el tipo. La caja puede estar al inicio del objeto y, por lo tanto, ser fácil de encontrar y analizar (por ejemplo, mediante la unidad de recuperación 52 y/o la unidad de desencapsulación 50). Pueden utilizarse múltiples tipos de compatibilidad para señalar diferentes tipos. El tipo de caja también puede exponerse como un tipo de medio de Internet mediante el parámetro de perfiles y, por ejemplo, puede utilizarse en el caso de HTTP (por ejemplo, para la transmisión DASH u otras tecnologías de transmisión HTTP). Esto puede permitir diferentes modos de distribución.

Con respecto al uso de tipos como delimitadores, los valores de tipo pueden delimitar bloques en fragmentos, delimitar fragmentos en segmentos y archivos de pista, y/o delimitar intervalos para proporcionar una interpretación adecuada. El delimitador (por ejemplo, el valor de tipo) también puede representar tipos, para que un elemento de recepción (por ejemplo, la unidad de recuperación 52 y/o la unidad de desencapsulación 50) determine el tipo de datos (por ejemplo, datos multimedia) incluidos en el bloque, fragmento, segmento, archivo de pista o similares. No son necesarios índices de campos posteriores y, por lo tanto, estas técnicas pueden admitir el procesamiento en tiempo real.

La FIG. 2 es un diagrama de bloques que ilustra un conjunto de componentes de ejemplo de unidad de recuperación 52 de la FIG. 1 en mayor detalle. En este ejemplo, la unidad de recuperación 52 incluye una unidad eMBMS de software intermedio 100, un cliente DASH 110 y una aplicación multimedia 112.

En el ejemplo de la FIG. 2, la unidad eMBMS de software intermedio 100 incluye además una unidad eMBMS de recepción 106, una memoria caché 104 y una unidad de servidor 102. En este ejemplo, la unidad eMBMS de recepción 106 está configurada para recibir datos a través de eMBMS, por ejemplo, según el protocolo de suministro de archivos en transporte unidireccional(File Delivery over Unidirectional Transport,FLUTE), descrito en T. Paila y col., “FLUTE-File Delivery over Unidirectional Transport”, Network Working Group, RFC 6726, nov. 2012, disponible en http://tools.ietf.org/html/rfc6726. Es decir, la unidad eMBMS de recepción 106 puede recibir archivos a través de una difusión, por ejemplo, del dispositivo servidor 60, que puede actuar como un b M-SC.

Cuando la unidad eMBMS de software intermedio 100 recibe datos para archivos, la unidad eMBMS de software intermedio almacena los datos recibidos en la memoria caché 104. La memoria caché 104 puede comprender un medio de almacenamiento legible por ordenador, como una memoria flash, un disco duro, una RAM o cualquier otro medio de almacenamiento adecuado.

La unidad de servidor local 102 puede actuar como servidor para el cliente DASH 110. Por ejemplo, la unidad de servidor local 102 puede proporcionar un archivo MPD u otro archivo de manifiesto al cliente DASh 110. La unidad de servidor local 102 puede avisar de los tiempos de disponibilidad para segmentos en el archivo MPD, así como hiperenlaces desde los cuales pueden recuperarse los segmentos. Estos hiperenlaces pueden incluir un prefijo de dirección de anfitrión local que corresponde al dispositivo cliente 40 (por ejemplo, 127.0.0.1 para IPv4). De este modo, el cliente DASH 110 puede solicitar segmentos de la unidad de servidor local 102 utilizando las peticiones HTTP GET o GET parcial. Por ejemplo, para un segmento disponible en el enlace http://127.0.0.1/rep1/seg3, el cliente DASH 110 puede construir una petición HTTP GET que incluya una petición para http:// 127.0.0.1/rep1/seg3, y enviar la solicitud a la unidad de servidor local 102. La unidad de servidor local 102 puede recuperar los datos solicitados de la memoria caché 104 y proporcionar los datos al cliente DASH 110 en respuesta a dichas peticiones.

La FIG. 3 es un diagrama conceptual que ilustra elementos de un ejemplo de contenido multimedia 120. El contenido multimedia 120 puede corresponder al contenido multimedia 64 (FIG. 1) o a otro contenido multimedia almacenado en el medio de almacenamiento 62. En el ejemplo de la FIG. 3, el contenido multimedia 120 incluye la descripción de presentación multimedia(Media Presentation Description,MPD) 122 y una pluralidad de representaciones 124A-124N (representaciones 124). La representación 124A incluye datos de encabezado 126 opcionales y segmentos 128A-128<n>(segmentos 128), mientras que la representación 124N incluye datos de encabezado 130 opcionales y segmentos 132A-132N (segmentos 132). La letra N se usa para designar el último fragmento de película en cada una de las representaciones 124 por comodidad. En algunos ejemplos, pueden existir diferentes números de fragmentos de película entre las representaciones 124.

La MPD 122 puede comprender una estructura de datos separada de las representaciones 124. La MPD 122 puede corresponder al archivo de manifiesto 66 de la FIG. 1. De forma similar, las representaciones 124 pueden corresponder a las representaciones 68 de la FIG. 2. En general, la MPD 122 puede incluir datos que generalmente describen las características de las representaciones 124, como las características de codificación y renderización, los conjuntos de adaptaciones, un perfil al que corresponde la MPD 122, información de tipo texto, información del ángulo de cámara, información de clasificación, información de modo trucado (por ejemplo, información indicativa de representaciones que incluyen subsecuencias temporales)s y/o información para recuperar periodos remotos (por ejemplo, para inserción de publicidad objeto en contenidos multimedia durante la reproducción).

Los datos de encabezado 126, cuando están presentes, pueden describir las características de los segmentos 128, por ejemplo, las posiciones temporales de los puntos de acceso aleatorios(Random Access Points,RAP, también referidos como puntos de acceso al flujo(Stream Access Points,SAP), cuál de los segmentos 128 incluye puntos de acceso aleatorios, desplazamientos de bytes a puntos de acceso aleatorios en los segmentos 128, localizadores uniformes de recursos(Uniform Resource Locator,URL) de los segmentos 128 u otros aspectos de los segmentos 128. Los datos de encabezado 130, cuando están presentes, pueden describir características similares para los segmentos 132. De forma adicional o alternativa, dichas características pueden incluirse completamente en la MPD 122.

Los segmentos 128, 132 incluyen una o más muestras de vídeo codificadas, cada una de las cuales puede incluir tramas o fragmentos de datos de vídeo. Cada una de las muestras de vídeo codificadas de segmentos 128 puede tener características similares, por ejemplo, altura, anchura y requisitos de ancho de banda. Dichas características pueden describirse con datos de MPD 122, aunque dichos datos no se ilustran en el ejemplo de la FIG. 3. La MPD 122 puede incluir características como se describe en la especificación 3GPP, con la adición de cualquiera o de la totalidad de la información señalizada descrita en la presente descripción.

Cada uno de los segmentos 128, 132 puede asociarse con un único localizador uniforme de recursos(Uniform Resource Locator,URL). Así, cada uno de los segmentos 128, 132 puede ser recuperable independientemente utilizando un protocolo de red de emisión en continuo, como DASH. De este modo, un dispositivo de destino, como el dispositivo cliente 40, puede usar una petición HTTP GET para recuperar los segmentos 128 o 132. En algunos ejemplos, el dispositivo cliente 40 puede usar peticiones HTTP GET parciales para recuperar intervalos de bytes específicos de los segmentos 128 o 132.

La FIG. 4 es un diagrama de bloques que ilustra los elementos de un archivo de vídeo 150 de ejemplo, que puede corresponder a un segmento de una representación, como uno de los segmentos 114, 124 de la FIG. 3. Cada uno de los segmentos 128, 132 puede incluir datos que se adecuan sustancialmente a la disposición de datos ilustrados en el ejemplo de la FIG. 4. Puede decirse que el archivo de vídeo 150 encapsula un segmento. Como se describió anteriormente, los archivos de vídeo según el formato de archivo multimedia de base ISO y las extensiones de este almacenan datos en una serie de objetos, referidos como “cajas”. En el ejemplo de la FIG. 4, el archivo de vídeo 150 incluye una caja de tipo de archivo(File Type,FTYP) 152, una caja de película(Movie,MOOV) 154, cajas de índices de segmento (sidx) 162, cajas de fragmentos de película(Movie Fragment,MOOF) 164 y una caja de acceso aleatorio a fragmentos de película(Movie Fragment Random Access,MFRA) 166. Aunque la FIG. 4 representa un ejemplo de un archivo de vídeo, debe entenderse que otros archivos multimedia pueden incluir otros tipos de datos multimedia (por ejemplo, datos de audio, datos de texto temporizado, o similares) que se estructuran de forma similar a los datos de archivo de vídeo 150, según el archivo de formato multimedia de base ISO y sus extensiones.

La caja de tipo de archivo(File Type,FTYP) 152 describe generalmente un tipo de archivo para el archivo de vídeo 150. La caja de tipo de archivo 152 puede incluir datos que identifican una especificación que describe el mejor uso del archivo de vídeo 150. La caja de tipo de archivo 152 puede colocarse alternativamente antes de la caja MOOV 154, las cajas de fragmentos de película 164 y/o la caja MFRA 166.

En algunos ejemplos, un segmento, tal como un archivo de vídeo 150, puede incluir una caja de actualización MPD (no mostrada) antes de la caja FTYP 152. La caja de actualización MPD puede incluir información que indica que una MPD que corresponde a una representación que incluye el archivo de vídeo 150 debe actualizarse, junto con información para actualizar la MPD. Por ejemplo, la caja de actualización MPD puede proporcionar un URI o un URL para usar un recurso para actualizar la MPD. Como otro ejemplo, la caja de actualización MPD puede incluir datos para actualizar la MPD. En algunos ejemplos, la caja de actualización MPD puede seguir inmediatamente a una caja de tipo de segmento(Segment Type,STYP) (no mostrada) del archivo de vídeo 150, donde la caja STYP puede definir un tipo de segmento para el archivo de vídeo 150. La FIG. 7, que se analiza con mayor detalle a continuación, proporciona información adicional con respecto a la caja de actualización de MPD.

La caja MOOV 154, en el ejemplo de la FIG. 4, incluye la caja de encabezado de película(Movie Header,MVHD) 156, la caja de pistas (TRAK) 158 y una o más cajas de extensiones de películas(Movie Extends,MVEX) 160. En general, la caja MVHD 156 puede describir las características generales del archivo de vídeo 150. Por ejemplo, la caja MVHD 156 puede incluir datos que describen cuándo se creó originalmente el archivo de vídeo 150, cuándo se modificó el archivo de vídeo 150 por última vez, un cronograma para el archivo de vídeo 150, una duración de reproducción para el archivo de vídeo 150 u otros datos que describen el archivo de vídeo 150 en general.

La caja TRAK 158 puede incluir datos para una pista de archivo de vídeo 150. La caja TRAK 158 puede incluir una caja de encabezado de pista(Track Header,TKHD) que describe las características de la pista que corresponde a la caja TRAK 158. En algunos ejemplos, la caja TRAK 158 puede incluir imágenes de vídeo codificadas, mientras que, en otros ejemplos, las imágenes de vídeo codificadas de la pista pueden incluirse en fragmentos de película 164, que pueden ser referenciados por datos de la caja TRAK 158 y/o las cajas sidx 162.

En algunos ejemplos, el archivo de vídeo 150 puede incluir más de una pista. Por consiguiente, la caja MOOV 154 puede incluir una serie de cajas TRAK igual al número de pistas en el archivo de vídeo 150. La caja TRA<k>158 puede describir las características de una pista de archivo de vídeo 150 correspondiente. Por ejemplo, la caja TRAK 158 puede describir información temporal y/o espacial para la pista correspondiente. Una caja TRAK similar a la caja TRAK 158 de la caja MOOV 154 puede describir las características de una pista de conjunto de parámetros, cuando la unidad de encapsulación 30 (FIG. 3) incluye una pista de conjunto de parámetros en un archivo de vídeo, como el archivo de vídeo 150. La unidad de encapsulación 30 puede señalar la presencia de mensajes SEI de nivel de secuencia en la pista de conjunto de parámetros dentro de la caja TRAK que describe la pista de conjunto de parámetros.

Las cajas MVEX 160 pueden describir las características de fragmentos de película 164 correspondientes, por ejemplo, para señalar que el archivo de vídeo 150 incluye fragmentos de película 164, además de los datos de vídeo incluidos en la caja MOOV 154, si existieran. En el contexto de la emisión en continuo de datos de vídeo, las imágenes de vídeo codificadas pueden estar incluidas en fragmentos de película 164 más que en la caja MOOV 154. Por consiguiente, todas las muestras de vídeo codificadas pueden estar incluidas en fragmentos de película 164, en vez de en la caja MOOV 154.

La caja MOOV 154 puede incluir una serie de cajas MVEX 160 igual al número de fragmentos de película 164 en el archivo de vídeo 150. Cada una de las cajas MVEX 160 puede describir las características de uno correspondiente de los fragmentos de película 164. Por ejemplo, cada caja MVEX puede incluir una caja de encabezado de extensiones de película(Movie Extends Header,MEHD) que describe una duración temporal para el correspondiente de los fragmentos de película 164.

Como se observa anteriormente, la unidad de encapsulación 30 puede almacenar un conjunto de datos de secuencia en una muestra de vídeo que no incluye datos de vídeo codificados reales. Una muestra de vídeo puede corresponder generalmente a una unidad de acceso, que es una representación de una imagen codificada en una instancia de tiempo específica. En el contexto de AVC, la imagen codificada incluye una o más unidades NAL VCL que contienen la información para construir todos los píxeles de la unidad de acceso y otras unidades NAL no VCL asociadas, como los mensajes SEI. Por consiguiente, la unidad de encapsulación 30 puede incluir un conjunto de datos de secuencia, que puede incluir mensajes SEI de nivel de secuencia, en uno de los fragmentos de película 164. La unidad de encapsulación 30 puede señalar además la presencia de un conjunto de datos de secuencia y/o mensajes SEI de nivel de secuencia como presentes en uno de los fragmentos de película 164 dentro de la una de las cajas MVEX 160 que corresponde al uno de los fragmentos de película 164.

Las cajas SIDX 162 son elementos de archivo de vídeo 150 opcionales. Es decir, los archivos de vídeo según el formato de archivo 3GPP, u otros formatos de archivo, no incluyen necesariamente las cajas SIDX 162. Según el ejemplo del formato de archivo 3GPP, una caja SIDX puede usarse para identificar un subsegmento de un segmento (por ejemplo, un segmento contenido dentro del archivo de vídeo 150). El formato de archivo 3GPP define un subsegmento como “un conjunto autocontenido de una o más cajas de fragmentos de película consecutivas con la caja o cajas de datos multimedia correspondientes y una caja de datos multimedia que contiene datos referenciados por una caja de fragmentos de películas debe seguir a esa caja de fragmentos de película y preceder a la siguiente caja de fragmentos de película que contiene información sobre la misma pista”. El formato de archivo 3GPP también indica que una caja SID<x>“contiene una secuencia de referencias a subsegmentos del (sub)segmento documentado por la caja. Los subsegmentos referenciados son contiguos en el tiempo de presentación. De forma similar, los bytes a los que hace referencia una caja de índices de segmentos son siempre contiguos dentro del segmento. El tamaño referenciado proporciona el recuento del número de bytes en el material referenciado”.

Las cajas SIDX 162 proporcionan generalmente información representativa de uno o más subsegmentos de un segmento incluido en el archivo de vídeo 150. Por ejemplo, dicha información puede incluir los tiempos de reproducción donde empiezan y/o terminan los subsegmentos, los desplazamientos de bytes para los subsegmentos, si los subsegmentos incluyen o no (por ejemplo, si empiezan con) un punto de acceso al flujo(Stream Access Point,SAP), un tipo para el SAP (por ejemplo, si el SAP es o no una imagen de refresco de codificador instantáneo(Instantaneous Decoder Refresh,IDR), una imagen de acceso aleatorio limpio(Clean Random Access,CRA), una imagen de acceso a enlace roto(Broken Link Access,BLA), o similares), una posición del SAP (en términos de tiempo de reproducción y/o desplazamiento de bytes) en el subsegmento, y similares.

Los fragmentos de película 164 pueden incluir una o más imágenes de vídeo codificadas. En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o más grupos de imágenes(Group of Pictures,GOP), cada uno de los cuales puede incluir una serie de imágenes de vídeo codificadas, por ejemplo, tramas o imágenes. Además, como se describió anteriormente, los fragmentos de película 164 pueden incluir conjuntos de datos de secuencias en algunos ejemplos. Cada uno de los fragmentos de película 164 puede incluir una caja de encabezado de fragmentos de película(Movie Fragment Header Box,MFHD, no mostrada en la FIG. 4). La caja MFHD puede describir las características del fragmento de película correspondiente, como un número de secuencia para un fragmento de película. Los fragmentos de película 164 pueden incluirse en orden de número de secuencia en el archivo de vídeo 150. En algunos ejemplos, uno o más de los fragmentos de película 164 pueden estar precedidos por un encabezado CMAF, por ejemplo, según la Tabla 3 como se analizó anteriormente. Además, un segmento CMAf puede incluir uno o más fragmentos CMAF, cada uno de los cuales puede incluir una o más cajas opcionales, una caja de fragmentos de película y una caja de datos multimedia.

La caja MFRA 166 puede describir los puntos de acceso aleatorios dentro de los fragmentos de película 164 del archivo de vídeo 150. Así puede ayudar a realizar modos de trucado, como la realización de búsquedas en posiciones temporales determinadas (por ejemplo, tiempos de reproducción) en un segmento encapsulado por el archivo de vídeo 150. La caja MFRA 166 es generalmente opcional y no es preciso incluirla en los archivos de vídeo, en algunos ejemplos. De forma similar, un dispositivo cliente, como el dispositivo cliente 40, no tiene que hacer referencia necesariamente a la caja MFRA 166 de decodificación de y visualizar correctamente los datos de vídeo del archivo de vídeo 150. La caja MFRA 166 puede incluir una serie de cajas de acceso aleatorio de fragmentos de pista(Track Fragment Random Access,TFRa ) (no mostradas) igual al número de pistas de archivo de vídeo 150, o en algunos ejemplos, igual al número de pistas multimedia (por ejemplo, pistas sin sugerencias) del archivo de vídeo 150.

En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o más puntos de acceso al flujo(Stream Access Points,SAP), como imágenes IDR. De forma similar, la caja MFRA 166 puede proporcionar indicaciones de posiciones en el archivo de vídeo 150 de los SAP. Por consiguiente, una subsecuencia temporal del archivo de vídeo 150 puede formarse a partir de los SAP del archivo de vídeo 150. La subsecuencia temporal puede incluir también otras imágenes, como las tramas P y/o las tramas B que dependen de los SAP. Las tramas y/o fragmentos de la subsecuencia temporal pueden disponerse dentro de los segmentos de manera que las tramas/fragmentos de la subsecuencia temporal que dependen de otras tramas/fragmentos de la subsecuencia puedan decodificarse adecuadamente. Por ejemplo, en la disposición jerárquica de datos, los datos usados para la predicción para otros datos también pueden incluirse en la subsecuencia temporal.

La FIG. 5 es un diagrama conceptual que ilustra un fragmento CMAF de ejemplo 200. El fragmento CMAF 200 de la FIG. 5 puede corresponderse con uno de los fragmentos de película 164 de la FIG. 4. El fragmento CMAF 200 puede adecuarse a la Tabla 5 anterior. Los fragmentos CMAF, tal como el fragmento CMAF 200, pueden ser las unidades de conmutación más pequeñas que son manejadas por la codificación CMAF, la entrega CMAF y los reproductores CMAF.

En el ejemplo de la FIG. 5, el fragmento CMAF 200 incluye cero o más cajas opcionales 202, una caja de fragmentos de película (moof) 204 y una caja de datos multimedia (mdat) 206. Las cajas opcionales 202 están delineadas con una línea discontinua para indicar que las casillas opcionales 202 son opcionales. Las cajas opcionales 202 de la FIG. 5 puede incluir ninguno, cualquiera o todos de una caja de tipo de segmento, una caja de tiempo de referencia del productor y/o una caja o cajas de mensaje de evento DASH.

La caja MDAT 206 incluye muestras de medios de acceso aleatorio 208A-208C (muestras de medios de acceso aleatorio 208), que pueden corresponder a uno o más flujos de vídeo codificados(Coded Video Streams,CVS). Un tiempo de decodificación 210 de una primera muestra, por ejemplo, una primera muestra ordinal, de la caja MDAT 206 (por ejemplo, la muestra de medios de acceso aleatorio 208A) puede indicarse mediante una caja de tiempo de decodificación de fragmentos de pista(Track Fragment Decode Time,tfdt), que puede incluirse en la caja moof 204. En particular, la caja tfdt puede incluirse en una caja de fragmentos de pista (traf) de la caja moof 204, y puede indicar un tiempo de decodificación de medios base de fragmentos de pista.

En algunos ejemplos, los fragmentos CMAF, tal como el fragmento CMAF 200, se adecuan a las siguientes restricciones:

1. Cada Fragmento CMAF, en combinación con su Encabezado CMAF asociado, contendrá suficientes metadatos para ser decodificados, descifrados y mostrados cuando se acceda a ellos de forma independiente. Además de las restricciones especificadas de Pista CMAF y Perfil de Medios, una Pista CMAF no es conforme si un Fragmento CMAF no puede decodificarse cuando se procesa con su Encabezado CMAF asociado. Por ejemplo, si se utilizan grupos de muestras y descripciones de grupos de muestras para señalizar cambios en la clave de cifrado, es necesario que haya una SampleGroupDescriptionBox y una SampleToGroupBox en la TrackFragmentBox para que el fragmento CMAF sea accesible y descifrable al azar.

2. La MovieFragmentBox del Fragmento CMAF puede estar precedida por otras cajas, incluidas una o más SegmentTypeBox, ProducerReferenceTimeBox y/o DASHEventMessageBox(es). (Véase 7.4.5 y el Anexo E. de ISO/IEC 23000-19 para más información sobre los Mensajes de Eventos).

3. Cada Fragmento CMAF en una Pista CMAF debe tener una duración de al menos un segundo, con la posible excepción del primer y último Fragmento de la Pista.

La FIG. 6 es un diagrama conceptual que ilustra una pista CMAF de ejemplo 220. En este ejemplo, la pista CMAF 220 incluye el encabezado CMAF 222 y los fragmentos CMAF 230A, 230B (fragmentos C<m>A<f>230). Cada uno de los fragmentos CMAF 230 incluye un conjunto respectivo de cero o más cajas opcionales, una caja moof y una caja mdat. Por ejemplo, el fragmento CMAF 230a incluye cajas opcionales 224A, caja moof 226A y caja mdat 228A, mientras que el fragmento CMAF 230B incluye cajas opcionales 224B, caja moof 226B y caja mdat 228B. De esta manera, cada uno de los fragmentos CMAF 230 puede incluir generalmente elementos similares a los elementos del fragmento CMAF 200 de la FIG. 5. La pista CMAF 220 de la FIG. 6 también puede incluirse dentro de un archivo de vídeo, tal como el archivo de vídeo 150 de la FIG. 4, donde el encabezado CMAF 222 puede corresponder a la caja ftyp 152 y la caja moov 154 de la FIG. 4, y los fragmentos CMAF 230 pueden comenzar al principio de los fragmentos de película 164 de la FIG. 4. La pista C<m>A<f>200 generalmente puede adecuarse a la Tabla 2 anterior.

Según las técnicas de la presente descripción, el encabezado CMAF 222 puede incluir un valor ftyp en NL 0, como se analizó anteriormente, y como se muestra en el ejemplo de la Tabla 3. Es decir, el dispositivo de preparación de contenido 20 de la FIG. 1 puede establecer el valor ftyp, al menos en parte, para indicar el inicio del encabezado CMAF 222. De forma similar, el dispositivo cliente 40 de la FIG. 1 (por ejemplo, la unidad de recuperación 52 de la FIG. 1) puede determinar la ubicación del encabezado CMAF 222 analizando un flujo de bits que incluye la pista CMAF 220 y detectando el valor ftyp. En respuesta, la unidad de recuperación 52 puede determinar que los fragmentos CMAF 230 siguen el encabezado CMAF 222 (por ejemplo, la caja ftyp 152 y la caja moov 154 de la FIG. 4), potencialmente también después de que una o más cajas sidx intermedias, tales como las cajas sidx 162 (FIG. 4).

Además, cada uno de los fragmentos CMAF 230 puede incluir valores de styp representativos de si los fragmentos CMAF 230 corresponden solo a fragmentos CMAF, segmentos CMAF o bloques CMAF, por ejemplo, en cajas moof correspondientes 226A, 226B (cajas moof 226). Por lo tanto, la unidad de recuperación 52 puede determinar si uno de los fragmentos CMAF 230 es solo un fragmento CMAF, un bloque CMAF o un segmento CMAF, según los valores para el styp de los respectivos fragmentos CMAF en las respectivas cajas moof 226.

Por ejemplo, el dispositivo de preparación de contenido 20 (FIG. 1) puede asignar un valor de “cmfl” al elemento styp de una de las cajas moof 226 de uno correspondiente de los fragmentos CMAF 230 para indicar que uno de los fragmentos CMAF 230 incluye un bloque CMAF, un valor de “cmff” para indicar que uno de los fragmentos CMAF 230 es solo un fragmento CMAF, o un valor de “cmfs” para indicar que el uno de los fragmentos CMAF 230 está incluido en un segmento CMAF. De forma similar, la unidad de recuperación 52 puede determinar que uno de los fragmentos CMAF 230 incluye un bloque CMAF cuando un elemento styp de la una de las cajas moof 226 tiene un valor de “cmfl”, que el fragmento CMAF es solo un fragmento CMAF cuando el elemento styp de la una de las cajas moof 226 tiene un valor de “cmff”, o que el fragmento CMAF se incluye en un segmento CMAF cuando el elemento styp de la una de las cajas moof 226 tiene un valor de “cmfs”.

La FIG. 7 es un diagrama conceptual que ilustra un segmento CMAF de ejemplo 240. El segmento CMAF 240 de la FIG. 7 puede incluirse dentro de un archivo de pista CMAF, siguiendo a un encabezado CMAF, por ejemplo, como se muestra en la FIG. 6. El segmento CMAF 240 puede adecuarse a la Tabla 4 anterior.

En el ejemplo de la FIG. 7, el segmento CMAF 240 incluye dos fragmentos CMAF 250A, 250B de ejemplo (fragmentos CMAF 250). Cada uno de los fragmentos CMAF 250 incluye un conjunto respectivo de cero o más cajas opcionales, una caja moof y una caja mdat. Por ejemplo, el fragmento CMAF 250A incluye cajas opcionales 244A, caja moof 246A y caja mdat 248A, mientras que el fragmento CMAF 250B incluye cajas opcionales 244B, caja moof 246B y caja mdat 248B. De esta manera, cada uno de los fragmentos CMAF 250 puede incluir generalmente elementos similares a los elementos del fragmento CMAF 200 de la FIG. 5. El segmento CMAF 240 de la FIG. 7 puede incluirse dentro de un archivo de vídeo, tal como el archivo de vídeo 150 de la FIG. 4, donde los fragmentos CMAF 250 pueden comenzar al principio de los fragmentos de película 164 de la FIG. 4.

Según las técnicas de la presente descripción, el dispositivo de preparación de contenido 20 (FIG. 1) puede asignar un valor de “cmfs” a un valor styp de la caja moof 246A del fragmento CMAF 250A para indicar que el fragmento CMAF 250A está incluido dentro y representa el inicio del segmento CMAF 240. De forma similar, la unidad de recuperación 52 de la FIG. 1 puede determinar que el fragmento CMAF 250A representa el inicio del segmento CMAF 240 en respuesta a la determinación de que un valor de styp de la caja moof 246A del fragmento CMAF 250A tiene un valor de “cmfs”.

Las FIGS. 8A y 8B son diagramas conceptuales que ilustran fragmentos CMAF y bloques CMAF de ejemplo. En particular, la FIG. 8A ilustra solo un ejemplo de un fragmento CMAF 260. Es decir, el fragmento CMAF 260 incluye la caja moof 262, la caja mdat 264 y las muestras de secuencias de vídeo codificadas 266A-266L (muestras de secuencias de vídeo codificadas 266). La FIG. 8B ilustra un ejemplo de un fragmento CMAF 270 que incluye bloques CMAF 272A-272D (bloques CMAF 272). Cada uno de los bloques CMAF 272 puede adecuarse a la Tabla 6 anterior. Es decir, en este ejemplo, cada uno de los bloques CMAF 272 incluye una respectiva caja moof 274A-274D (cajas moof 274), cajas mdat 276A-276D (cajas mdat 276) y respectivas muestras de secuencias de vídeo codificadas 278a -278L (muestras de secuencias de vídeo codificadas 276).

Los bloques CMAF 272, como se muestra, pueden incluirse dentro del fragmento CMAF 270, que puede incluirse dentro de pistas CMAF y/o segmentos CMAF, como se analizó anteriormente. En un ejemplo, los bloques CMAF son las unidades atómicas más pequeñas que son manejadas por la codificación CMAF, la entrega CMAF y los Reproductores CMAF. Al dividir el fragmento CMAF 270 en bloques CMAF 272, por ejemplo, como se muestra en la FIG. 8B, los datos multimedia de las muestras de secuencias de vídeo codificadas 278 pueden emitirse con más frecuencia que los datos multimedia de las muestras de secuencias de vídeo codificadas 266 de la FIG. 8A. Es decir, el dispositivo de preparación de contenido 20 de la FIG. 1, por ejemplo, puede emitir cada uno de los bloques CMAF 272 en los respectivos tiempos de salida del codificador 280A-280D (tiempos de salida del codificador 280). Por el contrario, el dispositivo de preparación de contenido 20 puede emitir todo el fragmento CMAF 260 en el tiempo de salida del codificador 268. De esta manera, el uso de bloques CMAF, como los bloques CMAF 272, puede reducir la latencia de transporte de datos multimedia para un servicio de transmisión.

Los bloques CMAF 272 pueden etiquetarse como que tienen valores de styp de “cmfl” en las respectivas cajas moof 274, según las técnicas de la presente descripción. Es decir, el dispositivo de preparación de contenido 20 puede especificar el valor de “cmfl” en las respectivas cajas moof 274. De forma similar, la unidad de recuperación 52 puede determinar que el fragmento CMAF 270 incluye bloques CMAF 272 basándose en el valor de “cmfl” en las respectivas cajas moof 274. La unidad de recuperación 52 también puede determinar el inicio de cada uno de los bloques CMAF 272 analizando el fragmento CMAF 270 y detectando el valor de “cmfl” para los valores de styp de las respectivas cajas moof 274.

En algunos ejemplos, los bloques CMAF pueden adecuarse a cumplir con las siguientes restricciones:

1. Un Fragmento CMAF incluirá uno o más segmentos de Medios Base ISO [ISOBMFF, 8.16] cada uno de los cuales contienen un MovieFragmentBox, seguido de una o más MediaDataBox que contienen las muestras a las que hace referencia.

2. Un fragmento CMAF contendrá un MovieFragmentHeaderBox restringida como se especifica en 7.5.14 de ISO/IEC 23000-19.

3. Cada TrackFragmentBox contendrá un TrackFragmentBaseMediaDecodeTimeBox.

4. Todas las muestras de medios en un Fragmento CMAF se direccionarán mediante compensaciones de bytes en la TrackRunBox que son relativas al primer byte de la MovieFragmentBox (véase [ISOBMFF] 8.8.4).

5. La MovieFragmentBox del Bloque CMAF puede estar precedida por otras cajas, incluidas una SegmentTypeBox, una o más ProducerReferenceTimeBox y/o DASHEventMessageBox(es). (Véase 7.4.5 y el Anexo E. para más información sobre los mensajes de eventos).

La FIG. 9 es un diagrama conceptual que ilustra un sistema de ejemplo 300 según las técnicas de la presente descripción. En este ejemplo, el sistema 300 se divide en cuatro partes lógicas: una parte de manifiesto, una parte de oferta de contenido, una parte de entrega y una parte de plataformas y jugadores. La parte de manifiesto y la parte de oferta de contenidos pueden corresponder generalmente al dispositivo de preparación de contenido 20 de la FIG. 1, la parte de suministro puede corresponder al dispositivo servidor 60 de la FIG. 1, y la parte de plataformas y jugadores puede corresponder al dispositivo cliente 40 de la FIG. 1.

En el ejemplo de la FIG. 9, la parte de manifiesto del sistema 300 incluye DASH MPD 302, la lista de reproducción M3U8 de transmisión en vivo HTTP(HTTP Live Streaming, HLS)304 y una aplicación 306. DASH Mp D 302 hace referencia al contenido CMAF 308, que se incluye en la parte de oferta de contenido del sistema 300. El contenido CMAF 308 se proporciona a una red de entrega de contenidos(Content Delivery Network,CDN) 310, que proporciona servicios de difusión y/o multidifusión como parte de la parte de entrega del sistema 300. Varias plataformas y reproductores de la parte de plataformas y reproductores del sistema 300 pueden recibir datos multimedia de la CDN 310, tal como un reproductor de transmisión en vivo HTTP(HTTP Live Streaming,HLS) independiente 312, un dispositivo 314 para recibir HLS como una etiqueta de vídeo HTML-5, un reproductor DASH independiente 316, un dispositivo 318 para recibir DASH como una etiqueta de vídeo HTML-5 y/o un reproductor de tipo 3 basado en HTML-5 MSE 320. Las técnicas de esta descripción generalmente pueden admitir un tipo de señalización para dispositivos configurados según cualquiera o todos estos casos de uso de ejemplo.

La FIG. 10 es un diagrama conceptual que ilustra un ejemplo de descomposición 330 dentro de una aplicación WAVE 336 que utiliza interfaces de programación de aplicaciones(Application Programming Interfaces,API) HTML-5 338 entre la plataforma 332, el contenido 334 y la aplicación 336, cada uno de los cuales puede utilizar datos según las técnicas de la presente descripción. La plataforma de dispositivos WAVE 334 puede tener un conjunto de capacidades que son accesibles para la aplicación 336 a través de las API HTML-5 338 y capacidades de códec detalladas. El contenido WAVE 332 puede reproducirse en la plataforma del dispositivo WAVE 334 dentro de la aplicación WAVE 336. La aplicación WAVE 336 puede utilizar las capacidades del dispositivo de plataforma WAVE 334 para servicios multimedia.

La FIG. 11 es un diagrama conceptual que ilustra una secuencia de caja de ejemplo y la contención de un bloque CMAF 350. En este ejemplo, las cajas inferiores indican la contención en la caja anterior. Es decir, el bloque CMAF incluye la caja de tipos de segmento ('styp') 352, el evento de tiempo de referencia del productor ('prft') ('emsg') 354, la caja de fragmentos de película ('moof') 356 y la caja de datos de medios ('mdat'). La caja moof 356, a su vez, incluye la caja de encabezados de fragmentos de película ('mfhd') 360, la caja de encabezados específica de protección ('pssh') 362 y la caja de fragmentos de pista ('traf') 364. La secuencia de cajas contenidas en la caja traf 364 como se muestra en la FIG. 11 es un ejemplo. En este ejemplo, la caja traf 364 incluye la caja de encabezados de fragmentos de pista ('tfhd') 370, la caja de ejecución de fragmentos de pista ('trun') 372, la caja de cifrado de muestra ('senc') 374, la caja de tamaños de información auxiliar de muestra ('saiz') 376, la caja de compensaciones de información auxiliar de muestra ('saio') 378, la caja de muestra a grupo ('sbgp') 380 y la caja de descripciones de grupo de muestra ('sgpd') 382. Las cajas que se muestran con contornos discontinuos, como la caja styp 352, prtf emsg 354 y la caja pssh 362, pueden ser opcionales. Se requieren condicionalmente ciertas cajas de la caja traf 364 como se muestra en la fila inferior cuando se utiliza el cifrado, en algunos ejemplos.

Cualquier Bloque CMAF o Fragmento CMAF que contenga las muestras iniciales de un Fragmento CMAF debe adecuarse a la marca 'cmff de Segmento CMAF y la marca debe señalizarse en el 'styp'.

Los Encabezados CMAF, los Fragmentos CMAF y los Bloques CMAF pueden empaquetarse y referenciarse como Objetos Multimedia Direccionables CMAF para su almacenamiento y entrega, como se describe en la Sección 6.7 del Modelo de Objetos Multimedia CMAF. Cada Objeto Multimedia Direccionable CMAF puede ser referenciado como un Recurso por una especificación externa, por ejemplo, MPEG DASH.

El Encabezado CMAF, los Bloques CMAF y los Fragmentos CMAF pueden ponerse a disposición como Recursos Direccionables CMAF mediante medios de transformación simples, por ejemplo:

• Directamente,

• Concatenando Fragmentos CMAF y enviando como Segmento CMAF, y/o

• Concatenando el Encabezado CMAF con todos los Fragmentos CMAF, posiblemente añadiendo una SegmentIndexBox.

En el modo de fragmento CMAF, un encabezado CMAF puede estar disponible como un objeto direccionable. En este modo, el Fragmento CMAF puede ponerse a disposición directamente como un Objeto de Medios direccionable CMAF.

En el modo de segmento CMAF, los segmentos CMAF pueden utilizarse como se analizó anteriormente, por ejemplo, con respecto a la Tabla 4 y la FIG. 7. Un segmento CMAF puede definirse como un Objeto de Medios Direccionable CMAF que contiene uno o más Fragmentos CMAF completos en orden de presentación. En algunos ejemplos:

1. Un Segmento CMAF puede contener las Muestras de cada Fragmento CMAF divididas en múltiples fragmentos de película secuenciados en orden de decodificación.

2. Un segmento CMAF puede incluir una SegmentTypeBox que precede a la primera MovieFragmentBox de cada fragmento CMAF. La SegmentTypeBox PUEDE incluir la marca 'cmfs' de Segmento CMAF y cualquier compatible_brands enumerada en la FileTypeBox del Encabezado CMAF de la Pista CMAF.

En el modo de bloque CMAF, el Encabezado CMAF puede estar disponible como un objeto direccionable. Cada Fragmento CMAF, en este modo, puede incluirse en uno o más Bloques CMAF. El Bloque CMAF puede ponerse a disposición directamente como un Objeto de Medios Direccionable CMAF. El CMAF inicial puede incluir dos marcas de Segmento CMAF, 'cmff y cmfl', para señalizar la compatibilidad con la parte inicial del Fragmento CMAF, así como con el bloque CMAF. Los Bloques CMAF no iniciales pueden incluir la marca de Segmento CMAF 'cmfl' para señalizar la compatibilidad con este formato de segmento.

Un archivo de pista CMAF puede ser un Objeto de Medios Direccionable CMAF definido para que sea una Pista CMAF almacenada como una sola pista en un archivo ISO BMFF, siendo el primer fragmento CMAF baseMediaDecodeTime igual a cero. El Encabezado CMAF y todos los Fragmentos CMAF pueden incluirse en un único Archivo de Pista CMAF. En algunos ejemplos, un archivo de pista CMAF se adecua a las siguientes restricciones:

1. Pueden estar presentes cajas adicionales, como SegmentIndexBoxes, entre el Encabezado CMAF y el primer Fragmento CMAF.

2. Si existen SegmentIndexBoxes, cada subsegmento al que se haga referencia en la SegmentIndexBox será un único Fragmento CMAF contenido en el Archivo de Pista CMAF.

3. Las cajas emsg y prtf contenidas en los Fragmentos CMAF se mantienen en el archivo de pista. Si se mantiene una emsg o prtf para un Fragmento CMAF, la SegmentIndexBox hará referencia al inicio del fragmento CMAF, es decir, el primero de prtf o cualquier emsg.

4. Un Archivo de Pista CMAF de vídeo puede contener una lista de edición de desplazamiento para ajustar el tiempo de presentación más temprano de la primera muestra presentada a baseMediaDecodeTime de cero restando cualquier retraso de composición agregado por el uso de una v0 TrackRunBox mediante valores de desplazamiento de composición positivos para reordenar fotogramas de vídeo desde el orden de decodificación hasta el orden de presentación. Véase 7.5.12 de ISO/IEC 23000-19.

5. Puede utilizarse una v1 TrackRunBox mediante desplazamientos de composición negativos para ajustar el tiempo de composición de la Muestra de vídeo presentada más temprana en cada Fragmento CMAF a su BaseMediaDecodeTime, y la Muestra de vídeo más temprana en el Archivo de Pista CMAF a cero, sin usar una lista de edición de desplazamiento.

La FIG. 12 es un diagrama de flujo que ilustra un procedimiento de ejemplo para generar un flujo de bits según las técnicas de la presente descripción. El procedimiento de la FIG. 12 se explica con respecto al dispositivo de preparación de contenido 20 (FIG. 1). Sin embargo, debe entenderse que pueden configurarse otros dispositivos para realizar este procedimiento o uno similar. Por ejemplo, el dispositivo servidor 60 puede realizar algunas o todas las etapas del procedimiento de la FIG. 12.

Inicialmente, el codificador de audio 26 y el codificador de vídeo 28 (FIG. 1) codifican datos multimedia, tales como datos de audio o vídeo, respectivamente, para formar muestras codificadas de datos multimedia. La unidad de encapsulación 30 (FIG. 1) a continuación recibe las muestras codificadas de datos multimedia y genera un flujo de bits que incluye las muestras codificadas formateadas según CMAF según las técnicas de la presente descripción. En particular, la unidad de encapsulación 30 genera un encabezado CMAF de un archivo de pista CMAF (400). La unidad de encapsulación 30 puede generar el encabezado CMAF según la Tabla 3 anterior. Por ejemplo, la unidad de encapsulación 30 puede establecer un valor de tipo de archivo (ftyp) del encabezado CMAF al comienzo del encabezado CMAF (402). La unidad de encapsulación 30 también puede generar una caja de película (moov) del encabezado CMAF, por ejemplo, incluyendo los elementos de la caja moov 154 de la FIG. 4.

A continuación, la unidad de encapsulación 30 puede encapsular las muestras de medios codificadas en respectivos fragmentos CMAF (404). En diversos ejemplos, los fragmentos CMAF pueden corresponder solo a fragmentos CMAF, fragmentos CMAF incluidos en segmentos CMAF o fragmentos CMAF que incluyen bloques CMAF. Por consiguiente, la unidad de encapsulación 30 puede establecer valores de tipo de segmento (styp) al inicio de los fragmentos CMAF, para indicar inicios de los fragmentos CMAF y tipos para los fragmentos CMAF (por ejemplo, solo fragmentos CMAF, segmentos CMAF o bloques CMAF). Como se señaló anteriormente, el valor “cmfs” puede representar un segmento CMAF, el valor “cmff” puede representar solo un fragmento CMAF, y el valor “cmfl” puede representar un bloque CMAF. La unidad de encapsulación 30 puede establecer los valores de styp en respectivas cajas moof de los fragmentos CMAF.

A continuación, la unidad de encapsulación 30 puede generar un flujo de bits (408) que incluye el encabezado CMAF y fragmentos CMAF, y enviar el flujo de bits a un dispositivo cliente (410), tal como el dispositivo cliente 40 (FIG. 1). En algunos ejemplos, el dispositivo de preparación de contenido 20 puede enviar el flujo de bits al dispositivo servidor 60, que a continuación puede enviar el flujo de bits al dispositivo cliente 40.

De este modo, el procedimiento de la FIG. 12 representa un ejemplo de un procedimiento para generar un flujo de bits, incluyendo el procedimiento generar, mediante un procesador implementado en circuitos, un encabezado de formato de aplicación multimedia común(Common Media Application Format,CMAF) de un archivo de pista CMAF; establecer, mediante el procesador, un valor para un valor de tipo de archivo(File Type,FTYP) del encabezado CMAF que indique el inicio del encabezado CMAF; encapsular, mediante el procesador, una o más muestras de datos de medios en uno o más fragmentos CMAF que siguen al encabezado CMAF del archivo de pista CMAF; y generar, mediante el procesador, un flujo de bits que incluye el encabezado CMAF y el archivo de pista CMAF, el uno o más fragmentos CMAF que siguen al encabezado CMA<f>en el archivo de pista CMAF.

La FIG. 13 es un diagrama de flujo que ilustra un ejemplo de un procedimiento de procesamiento de datos multimedia según las técnicas de la presente descripción. El procedimiento de la FIG. 13 se explica con respecto al dispositivo cliente 40 de la FIG. 1. Sin embargo, debe entenderse que pueden configurarse otros dispositivos para realizar este procedimiento o uno similar según las técnicas de la presente descripción.

Inicialmente, la unidad de recuperación 52 (FIG. 1) del dispositivo cliente 40 analiza un flujo de bits que incluye un archivo de pista CMAF (420). Debe entenderse que la unidad de recuperación 52 puede solicitar inicialmente el flujo de bits, por ejemplo, del dispositivo servidor 60 o del dispositivo de preparación de contenido 20 (FIG. 1). Mientras se analiza el flujo de bits, la unidad de recuperación 52 puede detectar un valor de tipo de archivo (ftyp) del archivo de pista CMAF (422). Como se muestra en la Tabla 3 anterior, el valor ftyp puede estar al comienzo de un encabezado CMAF del archivo de pista CMAF. Por consiguiente, la unidad de recuperación 52 puede determinar que el encabezado CMAF comienza con el valor ftyp (424). La unidad de recuperación 52 puede determinar, además, que el resto del encabezado CMAF (por ejemplo, una caja moov) sigue al valor ftyp.

La unidad de recuperación 52 puede, por lo tanto, determinar que uno o más fragmentos CMAF del archivo de pista CMAF siguen al encabezado CMAF (y a cualquier caja sidx, si las hay, por ejemplo, como se muestra en la Tabla 2 anterior y en la FIG. 4). En particular, la unidad de recuperación 52 puede continuar analizando el flujo de bits que sigue al encabezado CMAF y detectar uno o más valores de tipo de segmento (styp) que siguen al encabezado CMAF (426). La unidad de recuperación 52 puede detectar los valores de styp en las respectivas cajas moof de los fragmentos CMAF. Según las técnicas de la presente descripción, la unidad de recuperación 52 puede determinar que cada uno de los valores de styp representa el inicio de un fragmento CMAF correspondiente. Además, la unidad de recuperación 52 puede determinar tipos para los fragmentos CMAF a partir de los respectivos valores de styp. Como se analizó anteriormente, en algunos ejemplos, el valor “cmfs” para styp puede representar un segmento CMAF, el valor “cmff” para styp puede representar solo un fragmento CMAF, y el valor “cmfl” para styp puede representar un bloque CMAF.

Por lo tanto, la unidad de recuperación 52 puede procesar los fragmentos CMAF correspondientes comenzando en los respectivos valores de styp según los valores de styp (428). Por ejemplo, la unidad de recuperación 52 puede determinar si un fragmento CMAF sigue solo al valor de styp, si deben esperarse uno o más fragmentos CMAF como parte de un segmento CMAF (por ejemplo, como se muestra en la FIG. 7), o si el fragmento CMAF incluye uno o más bloques CMAF (por ejemplo, como se muestra en la FIG. 8B).

De este modo, el procedimiento de la FIG. 13 representa un ejemplo de un procedimiento de procesamiento de datos multimedia, incluyendo el procedimiento analizar, mediante un procesador implementado en circuitos, un flujo de bits que incluye datos formateados según el formato de aplicación multimedia común(Common Media Application Format,CMAF), detectar, mediante el procesador y durante el análisis, un valor de tipo de archivo(File Type,FTYP) para un archivo de pista CMAF del flujo de bits, determinar, mediante el procesador, que un encabezado CMAF del archivo de pista CMAF comienza con el valor de FTYP, y procesar, mediante el procesador, uno o más fragmentos CMAF que siguen al encabezado CMAF del archivo de pista CMAF.

En uno o más ejemplos, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinación de estos. Si se implementan en software, las funciones pueden almacenarse o transmitirse como una o más instrucciones o código en un medio legible por ordenador y ejecutarse por una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador, que corresponden a un medio tangible tal como medios de almacenamiento de datos, o medios de comunicación que incluyen cualquier medio que facilite la transferencia de un programa informático de un lugar a otro, por ejemplo, según un protocolo de comunicación. De esta manera, los medios legibles por ordenador por lo general pueden corresponder a (1) un medio de almacenamiento tangible legible por ordenador que no sea transitorio o (2) un medio de comunicación tal como una señal u onda portadora. El medio de almacenamiento de datos puede ser cualquier medio disponible al que puedan acceder uno o más ordenadores o uno o más procesadores para recuperar instrucciones, código y/o estructuras de datos para la implementación de las técnicas descritas en esta descripción. Un producto de programa informático puede incluir un medio legible por ordenador.

A modo de ejemplo, y sin limitación, dichos medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, memoria flash o cualquier otro medio que se pueda usar para almacenar el código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. Además, a cualquier conexión se la denomina correctamente medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde un sitio web, un servidor u otra fuente remota usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital(Digital Subscriber Line,DSL) o tecnologías inalámbricas como infrarrojos, radio y microondas, a continuación, el cable coaxial, el cable de fibra óptica, el par trenzado, el DSL o las tecnologías inalámbricas como infrarrojos, radio y microondas se incluyen en la definición de medio. Debería entenderse, sin embargo, que los medios de almacenamiento legibles por ordenador y los medios de almacenamiento de datos no incluyen conexiones, ondas portadoras, señales u otros medios transitorios, sino que están dirigidos a medios de almacenamiento tangibles no transitorios. Disco, como se usa en esta invención, incluye disco compacto(Compact Disc,CD), disco láser, disco óptico, disco versátil digital(Digital Versatile Disc,DVD), disquete y disco Blu-Ray, donde unos discos generalmente reproducen datos magnéticamente, mientras que otros discos reproducen datos ópticamente con láseres. Las combinaciones de lo anterior también deben incluirse dentro el alcance de los medios legibles por ordenador.

Las instrucciones pueden ser ejecutadas por uno o más procesadores, como uno o más procesadores de señales digitales(Digital Signal Processor,DSP), microprocesadores de uso genérico, circuitos integrados específicos de aplicaciones(Application Specific Integrated Circuit,ASIC), matrices lógicas programables de campo(Field Programmable Gate Array,FPGA) u otros circuitos lógicos discretos o integrados equivalentes. En consecuencia, el término "procesador", como se usa en esta invención, se puede referir a cualquiera de las estructuras anteriores o a cualquier otra estructura adecuada para la implementación de las técnicas descritas en esta invención. Además, en algunos aspectos, la funcionalidad descrita en esta invención puede proporcionarse en módulos dedicados de hardware y/o software configurados para codificación o decodificación, o incorporados en un códec combinado. Además, las técnicas se podrían implementar completamente en uno o más circuitos o elementos lógicos.

Las técnicas de la presente descripción se pueden implementar en una amplia variedad de dispositivos o aparatos, incluyendo un microteléfono inalámbrico, un circuito integrado(Integrated Circuit,IC) o un conjunto de IC (por ejemplo, un conjunto de chips). En la presente descripción, se describen varios componentes, módulos o unidades para enfatizar los aspectos funcionales de los dispositivos configurados para realizar las técnicas descritas, pero no necesariamente requieren su realización a través de diferentes unidades de hardware. Más bien, como se ha descrito anteriormente, varias unidades se pueden combinar en una unidad de hardware de códec o proporcionar por medio de una colección de unidades de hardware interoperativos, que incluyen uno o más procesadores como se ha descrito anteriormente, junto con software y/o firmware adecuados.

Se han descrito varios ejemplos. Estos y otros ejemplos están dentro del alcance de las siguientes reivindicaciones.

Claims (6)

REIVINDICACIONES

1. Un procedimiento de procesamiento de datos multimedia, comprendiendo el procedimiento:

analizar, mediante un procesador implementado en circuitos, un flujo de bits que incluye datos formateados según el formato de aplicación multimedia común, CMAF, incluyendo el flujo de bits un archivo de pista CMAF comprendiendo un encabezado CMAF (222) que incluye una caja de tipo de archivo, FTYP, al inicio del encabezado CMAF (222), y uno o más fragmentos CMAf (230A, 230B) ubicados en el flujo de bits después del encabezado C<m>A<f>(222);

detectar, mediante el procesador y durante el análisis, el valor FTYP para el archivo de pista CMAF del flujo de bits;

determinar, mediante el procesador, la ubicación del encabezado CMAF (222) del archivo de pista CMAF mediante el valor FTYP;

determinar, mediante el procesador, que uno o más fragmentos CMAF (230A, 230B) siguen al encabezado CMAF (222); y

procesar, mediante el procesador, uno o más fragmentos CMAF (230A, 230B) del archivo de pista CMAF,

donde el procesamiento del uno o más fragmentos CMAF (230A, 230B) comprende:

detectar uno o más valores de tipo de segmento, STYP, en el flujo de bits, donde el valor de STYP tiene un valor “cmff” representativo de los fragmentos CMAF (230A, 230B) que contienen las muestras iniciales del fragmento C<m>A<f>;

determinar que cada uno de los uno o más valores de STYP corresponde a un inicio de uno respectivo de los fragmentos C<m>AF (230A, 230B); y

procesar cada uno de los fragmentos CMAF (230A, 230B) a partir del valor de STYP correspondiente.

2. El procedimiento según la reivindicación 1, donde procesar el uno o más fragmentos CMAF (230A, 230B) comprende determinar que los datos que siguen al encabezado CMAF (222) representan el uno o más fragmentos Cm A f (230A, 230B) en respuesta a la detección del valor de FTYP.

3. Un procedimiento de generación de un flujo de datos que incluye datos multimedia, comprendiendo el procedimiento:

generar, mediante un procesador implementado en circuitos, un encabezado (222) de formato de aplicación multimedia común, C<m>A<f>, de un archivo de pista CMAF;

establecer, mediante el procesador, un valor para un valor de tipo de archivo, FTYP, del encabezado CMAF (222) que indica el inicio del encabezado CMAF (222);

encapsular, mediante el procesador, una o más muestras de datos multimedia en uno o más fragmentos CMAF (230A, 230B) que siguen al encabezado CMAF (222) del archivo de pista CMAF; y

generar, mediante el procesador, un flujo de bits que incluye el encabezado CMAF (222) y el uno o más fragmentos CMAF (230A, 230B), siguiendo el uno o más fragmentos CMAF (230A, 230B) al encabezado CMAF (222) en el archivo de pista CMAF, comprendiendo además:

determinar tipos para cada uno de los fragmentos CMAF (230A, 230B); y

establecer el valor de tipo de segmento, STYP, de “cmff” para cada uno de los fragmentos CMAF (230A, 230B) que contienen las muestras iniciales del fragmento CMAF, estando los valores de STYP al inicio de los fragmentos CMAF correspondientes (230A, 230B).

4. Un medio de almacenamiento legible por ordenador que tiene almacenadas en el mismo instrucciones que, cuando se ejecutan, hacen que un procesador realice el procedimiento según cualquiera de las anteriores reivindicaciones de procedimiento.

5. Un dispositivo para el procesamiento de datos multimedia, comprendiendo el dispositivo:

medios para analizar un flujo de bits que incluye datos formateados según el formato de aplicación multimedia común, CMAF, incluyendo el flujo de bits un archivo de pistas CMAF comprendiendo un encabezado CMAF (222) que incluye una caja de tipo de archivo, FTYP, al inicio del encabezado CMAF (222), y uno o más fragmentos Cm Af (230A, 230B) ubicados en el flujo de bits después del encabezado CMAF (222); medios para detectar, durante el análisis, el valor FTYP para el archivo de pista CMAF del flujo de bits; medios para determinar la ubicación del encabezado CMAF (222) del archivo de pista CMAF mediante el valor FTYP;

medios para determinar que uno o más fragmentos CMAF (230A, 230B) siguen al encabezado CMAF (222); y medios para procesar uno o más fragmentos CMAF (230A, 230B) del archivo de pista CMAF,

donde el procesamiento del uno o más fragmentos CMAF (230A, 230B) comprende:

detectar uno o más valores de tipo de segmento, STYP, en el flujo de bits, donde el valor de STYP tiene un valor “cmff” representativo de los fragmentos CMAF (230A, 230B) que contienen las muestras iniciales del fragmento C<m>A<f>;

determinar que cada uno de los uno o más valores de STYP corresponde a un inicio de uno respectivo de los fragmentos Cm AF (230A, 230B); y

procesar cada uno de los fragmentos CMAF (230A, 230B) a partir del valor de STYP correspondiente.

6. Un dispositivo para generar un flujo de datos que incluye datos multimedia, comprendiendo el dispositivo:

medios para generar un encabezado de formato de aplicación multimedia común, CMAF, (222) de un archivo de pista<c>M<a>F;

medios para establecer un valor para un valor de tipo de archivo, FTYP, del encabezado CMAF (222) que indica el inicio del encabezado CMAF (222);

medios para encapsular una o más muestras de datos multimedia en uno o más fragmentos CMAF (230A, 230B) que siguen al encabezado CMAF (2220) del archivo de pista CMAF;

medios para generar un flujo de bits que incluye el encabezado CMAF (222) y el uno o más fragmentos CMAF (230A, 230B), el uno o más fragmentos CMAF (230A, 230B) que siguen al encabezado CMAF (222) en el archivo de pista C<m>A<f>;

medios para determinar los tipos para cada uno de los fragmentos CMAF (230A, 230B); y

medios para establecer el valor de tipo de segmento, STYP, de “cmff” para cada uno de los fragmentos CMAF (230A, 230B) que contienen las muestras iniciales del fragmento CMAF.