ES2854936T3

ES2854936T3 - Recuperación y acceso a trozos de segmento para transmisión de medios

Info

Publication number: ES2854936T3
Application number: ES17757592T
Authority: ES
Inventors: Thomas Stockhammer
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2016-07-28
Filing date: 2017-07-28
Publication date: 2021-09-23
Anticipated expiration: 2037-07-28
Also published as: TWI780063B; CN109479158B; BR112019001323A2; CA3029026A1; JP7142626B2; KR20190031490A; US20230283863A1; JP2019523600A; US20180035176A1; EP3491827B1; KR102454839B1; CN109479158A; WO2018022984A1; EP3491827A1; TW201806397A; US11617019B2

Abstract

Un procedimiento de recuperación de datos de medios, comprendiendo el procedimiento: recibir (306) un archivo de manifiesto que incluye un atributo que indica un número de trozos de segmento disponibles para un segmento de una representación de datos de medios, en el que el atributo se incluye en un elemento S de un elemento SegmentTimeline de una descripción de presentación de medios, MPD, y en el que el segmento comprende un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único; determinar (310) un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento; y enviar (312) una solicitud que especifica el identificador para el uno de los trozos a un dispositivo servidor.

Description

DESCRIPCIÓN

Recuperación y acceso a trozos de segmento para transmisión de medios

[0001] La presente solicitud reivindica el beneficio de la solicitud provisional de EE. UU. n.° 62/368,099, presentada el 28 de julio de 2016.

CAMPO TÉCNICO

[0002] La presente divulgación se refiere al transporte de datos de medios codificados.

ANTECEDENTES

[0003] Las capacidades de vídeo digital se pueden incorporar a una amplia gama de dispositivos, incluyendo televisores digitales, sistemas de radiodifusión directa digital, sistemas de radiodifusión inalámbrica, asistentes personales digitales (PDA), ordenadores portátiles o de escritorio, cámaras digitales, dispositivos de grabación digitales, reproductores de medios digitales, dispositivos de videojuegos, consolas de videojuegos, teléfonos de radio celulares o por satélite, dispositivos de videoconferencia y similares. Los dispositivos de vídeo digital implementan técnicas de compresión de vídeo, tales como las descritas en los estándares definidos por MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, parte 10, Codificación de vídeo avanzada (AVC), ITU-T H.265 (también denominada Codificación de vídeo de alta eficiencia (HEVC)), y ampliaciones de dichos estándares, para transmitir y recibir información de vídeo digital más eficazmente.

[0004] Después de que se hayan codificado los datos de vídeo, los datos de vídeo se pueden agrupar en paquetes para su transmisión o almacenamiento. Los datos de vídeo se pueden ensamblar en un archivo de vídeo que se ajusta a cualquiera de una variedad de estándares, tales como el formato de archivo de medios de base de la Organización Internacional de Normalización (ISO) y ampliaciones del mismo, tales como la AVC.

BREVE EXPLICACIÓN

[0005] En general, la presente divulgación describe técnicas para usar trozos de segmento. Las técnicas de la presente divulgación incluyen, por ejemplo, la señalización de varios trozos disponibles para un segmento completo. Las técnicas de la presente divulgación también incluyen esquemas de direccionamiento (por ejemplo, esquemas de nomenclatura) para direccionar los trozos, por ejemplo, para solicitar la recuperación de los trozos.

[0006] En un ejemplo, un procedimiento para recuperar datos de medios incluye recibir un archivo de manifiesto que incluye datos que indican varios trozos de segmento disponibles para un segmento de una representación de datos de medios, comprendiendo el segmento un archivo de medios recuperable de forma independiente que tiene un localizador de recursos uniforme (URL) único, determinar un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento y enviar una solicitud que especifica el identificador para el uno de los trozos a un dispositivo de servidor.

[0007] En otro ejemplo, un dispositivo para recuperar datos de medios incluye uno o más procesadores implementados en circuitos y configurados para recibir un archivo de manifiesto que incluye datos que indican varios trozos de segmento disponibles para un segmento de una representación de datos de medios, comprendiendo el segmento un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único, determinar un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento y enviar una solicitud especificando el identificador para uno de los trozos a un dispositivo servidor.

[0008] En otro ejemplo, un dispositivo para recuperar datos de medios incluye medios para recibir un archivo de manifiesto que incluye datos que indican varios trozos de segmento disponibles para un segmento de una representación de datos de medios, comprendiendo el segmento un archivo de medios recuperable de forma independiente que tiene un localizador de recursos uniforme (URL) único, medios para determinar un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento, y medios para enviar una solicitud que especifica el identificador para el uno de los trozos a un dispositivo servidor.

[0009] En otro ejemplo, un medio de almacenamiento legible por ordenador tiene almacenadas en el mismo instrucciones que, cuando se ejecutan, hacen que un procesador reciba un archivo de manifiesto que incluye datos que indican varios trozos de segmento disponibles para un segmento de una representación de datos de medios, comprendiendo el segmento un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único, determine un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento, y envíe una solicitud especificando el identificador para el uno de los trozos a un dispositivo servidor.

[0010] Los detalles de uno o más ejemplos se exponen en los dibujos adjuntos y la siguiente descripción. Otros rasgos característicos, objetivos y ventajas resultarán evidentes a partir de la descripción y los dibujos, y a partir de las reivindicaciones.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0011]

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

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

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

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 ejemplos de ofertas de segmentos regulares y ofertas con segmentos más cortos.

La FIG. 6 es un diagrama conceptual que ilustra direcciones de localizador de recursos uniforme (URL) para segmentos disponibles por medio de ofertas de segmentos regulares y ofertas con segmentos más cortos.

La FIG. 7 es un diagrama conceptual que ilustra un conjunto de ejemplo de datos que se pueden señalizar de acuerdo con las técnicas de la presente divulgación.

La FIG. 8 ilustra un ejemplo de técnicas para usar numeración jerárquica para los segmentos de acuerdo con las técnicas de la presente divulgación.

La FIG. 9 ilustra otro ejemplo de técnicas para usar numeración jerárquica para los segmentos de acuerdo con las técnicas de la presente divulgación.

La FIG. 10 es un diagrama de flujo que ilustra un procedimiento de ejemplo de transporte (envío y recepción) de datos de medios de acuerdo con las técnicas de la presente divulgación.

DESCRIPCIÓN DETALLADA

[0012] En general, la presente divulgación describe técnicas para usar secuencias de segmentos, por ejemplo, segmentos que incluyen datos para duraciones de reproducción relativamente cortas en comparación con los segmentos convencionales. Es decir, uno o más segmentos pueden carecer de un punto de acceso aleatorio (RAP). Por tanto, en lugar de un único segmento que tiene datos para una duración de reproducción de N segundos (u otra unidad de tiempo, tal como microsegundos, milisegundos o similares), teniendo el único segmento un RAP y estando asociado con un tiempo de inicio de disponibilidad de segmento (SAST), se puede proporcionar una pluralidad de segmentos que tienen datos para la duración de reproducción de N segundos, incluyendo solo uno de la pluralidad de segmentos un RAP, y estando asociado cada uno de la pluralidad de segmentos con los respectivos SAST. Usando dichos segmentos más cortos, la reproducción puede comenzar más rápido que usando segmentos más largos convencionales.

[0013] Se pueden usar diversas opciones para proporcionar una solución usando segmentos más cortos, solos o en combinación. Por ejemplo, se pueden anunciar duraciones precisas para líneas de tiempo de segmento para trozos de segmento. Sin embargo, anunciar duraciones precisas puede ser una solución excesivamente innecesaria y puede requerir muchas actualizaciones del archivo de manifiesto (por ejemplo, descripción de presentación de medios (MPD)). Se puede usar un esquema de direccionamiento jerárquico. Sin embargo, es incierto si hay tiempo suficiente para usar el esquema de direccionamiento jerárquico.

[0014] Las técnicas de la presente divulgación se pueden aplicar a archivos de medios (tales como archivos de vídeo) conformes a los datos de medios encapsulados de acuerdo con cualquiera de entre el formato de archivo de medios de base ISO, el formato de archivo de Codificación de vídeo escalable (SVC), el formato de archivo de Codificación de vídeo avanzada (AVC), el formato de archivo del Proyecto de colaboración de tercera generación (3GPP) y/o el formato de archivo de Codificación de vídeo multivista (MVC) u otros formatos similares de archivo de vídeo.

[0015] En la transmisión continua de HTTP, las operaciones usadas con frecuencia incluyen HEAD, GET y GET parcial. La operación HEAD recupera una cabecera de un archivo asociado a un localizador de recursos uniforme (URL) o a un nombre de recursos uniforme (URN) dados, sin recuperar una carga útil asociada al URL o al URN. La operación GET recupera un archivo completo asociado a un URL o URN dados. La operación GET parcial recibe un intervalo de bytes como un 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. Por tanto, se pueden proporcionar fragmentos de película para la transmisión continua de HTTP, porque una operación GET parcial puede obtener uno o más fragmentos de película individuales. En un fragmento de película, pueden existir varios fragmentos de pista de diferentes pistas. En la transmisión continua de HTTP, una presentación de medios puede ser una recopilación de datos estructurados que es accesible para el cliente. El cliente puede solicitar y descargar la información de datos de medios para presentar un servicio de transmisión continua a un usuario.

[0016] En el ejemplo de transmisión continua de datos 3GPP usando transmisión continua de HTTP, pueden existir múltiples representaciones para datos de vídeo y/o audio de contenido multimedia. Como se explica a continuación, diferentes representaciones pueden corresponder a diferentes características de codificación (por ejemplo, diferentes perfiles o niveles de un estándar de codificación de vídeo), diferentes estándares de codificación o ampliaciones de estándares de codificación (tales como ampliaciones multivista y/o escalables), o diferentes tasas de bits. El manifiesto de dichas representaciones se puede definir en una estructura de datos de Descripción de presentación de medios (MPD). Una presentación de medios puede corresponder a un grupo de datos estructurado que es accesible para un dispositivo cliente de transmisión continua de HTTP. El dispositivo cliente de transmisión continua de HTTP puede solicitar y descargar información de datos de medios para presentar un servicio de transmisión continua a un usuario del dispositivo cliente. Una presentación de medios se puede describir en la estructura de datos de MPD, que puede incluir actualizaciones de la MPD.

[0017] Una presentación de medios puede contener una secuencia de uno o más períodos. Cada período se puede extender hasta el inicio del siguiente período, o hasta el final de la presentación de medios en el caso del último período. Cada período puede contener una o más representaciones para el mismo contenido de medios. Una representación puede ser una de varias versiones codificadas alternativas de audio, vídeo, texto temporizado u otros datos de ese tipo. Las representaciones pueden diferir según el tipo de codificación, por ejemplo, según la tasa de bits, la resolución y/o el códec para los datos de vídeo y la tasa de bits, el idioma y/o el códec para los datos de audio. El término representación se puede usar para referirse a una sección de datos de audio o vídeo codificados correspondientes a un período en particular del contenido multimedia y codificados de una forma en particular.

[0018] Las representaciones de un período en particular se pueden asignar a un grupo indicado en la MPD por un atributo indicativo de un conjunto de adaptación al que pertenecen las representaciones. Las representaciones en el mismo conjunto de adaptación en general se consideran alternativas entre sí, en que un dispositivo cliente puede conmutar entre estas representaciones de dinámicamente y sin interrupciones, por ejemplo, para realizar una adaptación de ancho de banda. Por ejemplo, cada representación de datos de vídeo para un período particular se puede asignar al mismo conjunto de adaptación, de modo que cualquiera de las representaciones se puede seleccionar para descodificar para presentar datos de medios, tales como datos de vídeo o datos de audio, del contenido multimedia para el período correspondiente. El contenido de medios dentro de un período se puede representar por una representación del grupo 0, si está presente, o la combinación de como máximo una representación de cada grupo distinto de cero, en algunos ejemplos. Los datos de temporización para cada representación de un período se pueden expresar con respecto al tiempo de inicio del período.

[0019] 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 autoinicializador. 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 de medios. Un segmento se puede referenciar de forma única por un identificador, tal como un localizador de recursos uniforme (URL), un nombre de recursos uniforme (URN) o un identificador de recursos uniforme (URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD también puede proporcionar intervalos de bytes en forma de un atributo intervalo, que puede corresponder a los datos para un segmento dentro de un archivo accesible por el URL, el URN o el URI.

[0020] Se pueden seleccionar diferentes representaciones para una recuperación sustancialmente simultánea para diferentes tipos de datos de medios. 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 se pueden recuperar segmentos. En algunos ejemplos, el dispositivo cliente puede seleccionar conjuntos de adaptación particulares para realizar una adaptación de ancho de banda. Es decir, el dispositivo cliente puede seleccionar un conjunto de adaptación que incluye representaciones de vídeo, un conjunto de adaptación que incluye representaciones de audio y/o un conjunto de adaptación que incluye texto temporizado. De forma alternativa, el dispositivo cliente puede seleccionar conjuntos de adaptación para determinados tipos de medios (por ejemplo, vídeo) y seleccionar directamente representaciones para otros tipos de medios (por ejemplo, audio y/o texto temporizado).

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

[0022] El dispositivo de preparación de contenido 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 captados que se van a codificar por el codificador de audio 26. De forma alternativa, la fuente de audio 22 puede comprender un medio de almacenamiento que almacena datos de audio previamente registrados, un generador de datos de audio tal como un sintetizador informatizado, 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 se van a codificar por el codificador de vídeo 28, un medio de almacenamiento codificado con datos de vídeo previamente registrados, una unidad de generación de datos de vídeo, tal como una fuente de gráficos de ordenador, o cualquier otra fuente de datos de vídeo. El dispositivo de preparación de contenido 20 no está necesariamente acoplado de forma comunicativa al dispositivo servidor 60 en todos los ejemplos, pero puede almacenar contenido multimedia en un medio separado que se lee por el dispositivo servidor 60.

[0023] Los datos de audio y vídeo no procesados pueden comprender datos analógicos o digitales. Los datos analógicos se pueden digitalizar antes de codificarse por el codificador de audio 26 y/o el codificador de vídeo 28. La fuente de audio 22 puede obtener datos de audio a partir 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 que comprende datos de audio almacenados, y la fuente de vídeo 24 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de vídeo almacenados. De esta manera, las técnicas descritas en la presente divulgación se pueden aplicar a la transmisión continua en directo y en tiempo real de datos de audio y vídeo, o de datos de audio y vídeo archivados y registrados previamente.

[0024] Las tramas de audio que corresponden a tramas de vídeo son en general tramas de audio que contienen datos de audio que la fuente de audio 22 ha captado (o generado) al mismo tiempo que datos de vídeo, que la fuente de vídeo 24 ha captado (o generado), que están contenidos dentro de las tramas de vídeo. Por ejemplo, mientras un participante que habla en general produce, al hablar, datos de audio, la fuente de audio 22 capta los datos de audio, y la fuente de vídeo 24 capta los datos de vídeo del participante que habla al mismo tiempo, es decir, mientras la fuente de audio 22 está captando los datos de audio. Así pues, una trama de audio puede corresponder temporalmente a una o más tramas de vídeo en particular. Por consiguiente, una trama de audio correspondiente a una trama de vídeo corresponde en general a una situación en la que se han captado datos de audio y datos de vídeo al mismo tiempo, y para la que una trama de audio y una trama de vídeo comprenden, respectivamente, los datos de audio y los datos de vídeo que se han captado al mismo tiempo.

[0025] En algunos ejemplos, el codificador de audio 26 puede codificar una marca de tiempo en cada trama de audio codificada, que representa un tiempo en el que se han registrado 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 en el que se han registrado los datos de vídeo para la trama de vídeo codificada. En dichos ejemplos, una trama de audio correspondiente a una trama de vídeo puede comprender una trama de audio que comprende una marca de tiempo y una trama de vídeo que comprende la misma marca de tiempo. El dispositivo de preparación de contenido 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 usar para asociar datos de audio y vídeo, respectivamente, a una marca de tiempo.

[0026] En algunos ejemplos, la fuente de audio 22 puede enviar datos al codificador de audio 26, correspondientes a un tiempo en el que se han registrado los datos de audio, y la fuente de vídeo 24 puede enviar datos al codificador de vídeo 28, correspondientes a un tiempo en el que se han registrado los datos de vídeo. En algunos ejemplos, el codificador de audio 26 puede codificar un identificador de secuencia en los datos de audio codificados para indicar un orden temporal relativo de los datos de audio codificados, pero sin indicar necesariamente un tiempo absoluto en el que se han registrado los datos de audio y, de forma similar, el codificador de vídeo 28 también puede usar identificadores de secuencia para indicar un orden temporal relativo de los datos de vídeo codificados. De forma similar, en algunos ejemplos, un identificador de secuencia se puede asignar a, o de otro modo correlacionar con, una marca de tiempo.

[0027] El codificador de audio 26, en general, produce 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 vídeo) se puede denominar flujo elemental. Un flujo elemental es un componente único codificado digitalmente (y posiblemente comprimido) de una representación. Por ejemplo, la parte de vídeo o audio codificado de la representación puede ser un flujo elemental. Un flujo elemental se puede convertir en un flujo elemental paquetizado (PES) antes de encapsularse dentro de un archivo de vídeo. Dentro de la misma representación, se puede usar un ID de flujo para distinguir los paquetes PES que pertenecen a un flujo elemental de los otros. La unidad básica de datos de un flujo elemental es un paquete de flujo elemental paquetizado (PES). Por tanto, 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.

[0028] Muchos estándares de codificación de vídeo, tales como ITU-T H.264/AVC y el próximo estándar de Codificación de vídeo de alta eficacia (HEVC), definen la sintaxis, la semántica y el proceso de descodificación para flujos de bits sin errores, cualquiera de los cuales se ajusta a un determinado perfil o nivel. Los estándares de codificación de vídeo típicamente no especifican el codificador, pero el codificador se ocupa de garantizar que los flujos de bits generados cumplan los estándares para un descodificador. En el contexto de los estándares de codificación de vídeo, un "perfil" corresponde a un subconjunto de algoritmos, rasgos característicos o herramientas y restricciones que se les aplican. Como se define en el estándar H.264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits especificada por el estándar H.264. Un "nivel" corresponde a las limitaciones del consumo de recursos del descodificador, tales como, por ejemplo, memoria y cálculo del descodificador, que se relacionan con la resolución de las imágenes, la tasa de bits y la velocidad de procesamiento de bloques. Un perfil se puede señalizar con un valor idc de perfil (indicador de perfil), mientras que un nivel se puede señalizar con un valor level_idc (indicador de nivel).

[0029] El estándar H.264, por ejemplo, reconoce que, dentro de los límites impuestos por la sintaxis de un perfil dado, todavía es posible requerir una gran variación del rendimiento de los codificadores y descodificadores, dependiendo de los valores adoptados por los elementos de sintaxis en el flujo de bits, tales como el tamaño especificado de las imágenes descodificadas. El estándar H.264 reconoce, además, que, en muchas aplicaciones, no es ni práctico ni económico implementar un descodificador capaz de encargarse de todos los usos hipotéticos de la sintaxis dentro de un perfil en particular. Por consiguiente, el estándar H.264 define un "nivel" como un conjunto especificado de restricciones impuestas a los valores de los elementos de sintaxis en el flujo de bits. Estas restricciones pueden ser simples límites sobre los valores. De forma alternativa, estas restricciones pueden adoptar la forma de restricciones sobre 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 descodificadas por segundo). El estándar H.264 establece, además, que las implementaciones individuales pueden admitir un nivel diferente para cada perfil admitido.

[0030] Un descodificador que se ajusta a un perfil normalmente admite todos los rasgos característicos definidos en el perfil. Por ejemplo, como rasgo característico de codificación, la codificación de imágenes B no se admite en el perfil de valores de referencia de H.264/AVC, pero se admite en otros perfiles de H.264/AVC. Un descodificador que se ajusta a un nivel deberá ser capaz de descodificar cualquier flujo de bits que no requiere recursos fuera de las limitaciones definidas en el nivel. Las definiciones de perfiles y niveles pueden ser útiles para la interpretabilidad. Por ejemplo, durante la transmisión de vídeo, se pueden negociar y acordar un par de definiciones de perfil y nivel para una sesión de transmisión completa. Más específicamente, en H.264/AVC, un nivel puede definir limitaciones en el número de macrobloques que es necesario procesar, el tamaño del búfer de imágenes descodificadas (DPB), el tamaño del búfer de imágenes codificadas (CPB), el intervalo de vectores de movimiento vertical, el número máximo de vectores de movimiento para cada dos MB consecutivos y si un bloque B puede tener divisiones de submacrobloque inferiores a 8x8 píxeles. De esta manera, un descodificador puede determinar si el descodificador es capaz de descodificar apropiadamente el flujo de bits.

[0031] En el ejemplo de la FIG. 1, la unidad de encapsulación 30 del dispositivo de preparación de contenido 20 recibe flujos elementales que comprenden datos de vídeo codificados desde el codificador de vídeo 28 y flujos elementales que comprenden datos de audio codificados desde el codificador de audio 26. En algunos ejemplos, el codificador de vídeo 28 y el codificador de audio 26 pueden incluir, cada uno, paquetizadores para formar paquetes PES a partir de datos codificados. En otros ejemplos, el codificador de vídeo 28 y el codificador de audio 26 pueden interactuar, cada uno, con los paquetizadores respectivos para formar paquetes PES a partir de datos codificados. En todavía otros ejemplos, la unidad de encapsulación 30 puede incluir paquetizadores para formar paquetes PES a partir de datos de audio y de vídeo codificados.

[0032] El codificador de vídeo 28 puede codificar datos de vídeo de contenido multimedia en una variedad de formas, para producir diferentes representaciones del contenido multimedia a diversas tasas de bits y con diversas características, tales como resoluciones de píxeles, velocidades de tramas, conformidad con diversos estándares de codificación, conformidad con diversos perfiles y/o niveles de perfiles para diversos estándares de codificación, representaciones que tienen una o múltiples vistas (por ejemplo, para reproducción bidimensional o tridimensional), u otras características de ese tipo. Una representación, como se usa en la presente divulgación, puede comprender uno de datos de audio, datos de vídeo, datos de texto (por ejemplo, para subtítulos cerrados) u otros datos de este tipo. 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 que identifica el flujo elemental al que pertenece el paquete PES. La unidad de encapsulación 30 es responsable de ensamblar flujos elementales en archivos de vídeo (por ejemplo, segmentos) de diversas representaciones.

[0033] La unidad de encapsulación 30 recibe paquetes PES para flujos elementales de una representación desde el codificador de audio 26 y el codificador de vídeo 28 y forma las correspondientes unidades de capa de abstracción de red (NAL) a partir de los paquetes PES. En el ejemplo de la H.264/AVC (Codificación de vídeo avanzada), los segmentos de vídeo codificados se organizan en unidades de NAL, lo que proporciona una representación de vídeo "apta para redes" dirigida a aplicaciones tales como la videotelefonía, el almacenamiento, la radiodifusión o la transmisión continua. Las unidades de NAL se pueden clasificar en unidades de NAL de Capa de codificación de vídeo (VCL) y unidades de NAL no VCL. Las unidades de VCL pueden contener el motor de compresión central y pueden incluir datos a nivel de bloque, macrobloque y/o fragmento. Otras unidades de NAL pueden ser unidades de NAL no VCL. En algunos ejemplos, una imagen codificada en una instancia de tiempo, normalmente presentada como una imagen codificada principal, puede estar contenida en una unidad de acceso, que puede incluir una o más unidades de NAL.

[0034] Las unidades de NAL no VCL pueden incluir unidades de NAL de conjuntos de parámetros y unidades de SEI NAL, entre otras. Los conjuntos de parámetros pueden contener información de cabecera a nivel de secuencia (en conjuntos de parámetros de secuencia (SPS)) e información de cabecera a nivel de imagen que cambia ocasionalmente (en conjuntos de parámetros de imagen (PPS)). Con los conjuntos de parámetros (por ejemplo, PPS y SPS), la información que cambia ocasionalmente no necesita repetirse para cada secuencia o imagen, de ahí que pueda mejorarse la eficacia de la codificación. Además, el uso de conjuntos de parámetros puede permitir la transmisión fuera de banda de la información de cabecera importante, evitando la necesidad de transmisiones redundantes para la resistencia a los errores. En los ejemplos de transmisión fuera de banda, las unidades de NAL de conjuntos de parámetros se pueden transmitir en un canal diferente al de otras unidades de NAL, tales como las unidades de SEI NAL.

[0035] La Información de mejora complementaria (SEI) puede contener información que no es necesaria para descodificar las muestras de imágenes codificadas a partir de las unidades de VCL NAL, pero puede ayudar en los procesos relacionados con la descodificación, visualización, resistencia a los errores y otros propósitos. Los mensajes de SEI se pueden incluir en unidades de NAL no VCL. Los mensajes de SEI son la parte normativa de algunas memorias descriptivas habituales y, por tanto, no siempre son obligatorios para la implementación de descodificadores conforme a los estándares. Los mensajes de SEI pueden ser mensajes de SEI a nivel de secuencia o mensajes de SEI a nivel de imagen. Parte de la información a nivel de secuencia se puede incluir en mensajes de SEI, tales como mensajes de SEI de información de escalabilidad en el ejemplo de SVC y mensajes de SEI de información de escalabilidad de la vista en MVC. Estos ejemplos de mensajes de SEI pueden transportar información, por ejemplo, sobre extracción de puntos de funcionamiento y características de los puntos de funcionamiento. Además, la unidad de encapsulación 30 puede formar un archivo de manifiesto, tal como una descripción de presentación de medios (MPD) que describe características de las representaciones. La unidad de encapsulación 30 puede formatear la MPD de acuerdo con un lenguaje de marcado extensible (XML).

[0036] 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, la MPD), a 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, tal como una interfaz de bus serie universal (USB), una grabadora o copiadora de CD o DVD, una interfaz para medios de almacenamiento magnéticos o flash, u otras interfaces para almacenar o transmitir datos de medios. La unidad de encapsulación 30 puede proporcionar datos de cada una de las representaciones de contenido multimedia a la interfaz de salida 32, que puede enviar los datos al dispositivo servidor 60 por medio de transmisión por red o de medios de almacenamiento. En el ejemplo de la FIG. 1, el dispositivo servidor 60 incluye un medio de almacenamiento 62 que almacena diversos contenidos multimedia 64, incluyendo cada uno un respectivo archivo de manifiesto 66 y una o más representaciones 68A a 68N (representaciones 68). En algunos ejemplos, la interfaz de salida 32 también puede enviar datos directamente a la red 74.

[0037] En algunos ejemplos, las representaciones 68 se pueden separar en conjuntos de adaptación. Es decir, diversos subconjuntos de representaciones 68 pueden incluir respectivos conjuntos comunes de características, tales como códec, perfil y nivel, resolución, número de vistas, formato de archivo para segmentos, información de tipo de texto que puede identificar un idioma u otras características de un texto que se va a visualizar con la representación y/o datos de audio que se van a descodificar y presentar, por ejemplo, mediante altavoces, información de ángulo de cámara que puede describir un ángulo de cámara o una perspectiva de cámara real de una escena para representaciones del conjunto de adaptación, información de calificación que describe la idoneidad del contenido para audiencias en particular, o similares.

[0038] El archivo de manifiesto 66 puede incluir datos indicativos de los subconjuntos de representaciones 68 correspondientes a conjuntos de adaptación en particular, así como características comunes para los conjuntos de adaptación. El archivo de manifiesto 66 también puede incluir datos representativos de características individuales, tales como las tasas de bits, para representaciones individuales de conjuntos de adaptación. De esta manera, un conjunto de adaptación puede proporcionar una adaptación simplificada del ancho de banda de red. Las representaciones de un conjunto de adaptación se pueden indicar usando elementos hijo de un elemento del conjunto de adaptación del archivo de manifiesto 66.

[0039] El dispositivo servidor 60 incluye una unidad de procesamiento de solicitudes 70 y una interfaz de red 72. En algunos ejemplos, el dispositivo servidor 60 puede incluir una pluralidad de interfaces de red. Además, uno cualquiera o todos los rasgos característicos del dispositivo servidor 60 se pueden implementar en otros dispositivos de una red de entrega de contenido, tales como encaminadores, puentes, dispositivos proxy, conmutadores u otros dispositivos.

En algunos ejemplos, los dispositivos intermedios de una red de entrega de contenido pueden almacenar en memoria caché datos de contenido multimedia 64, e incluir componentes que se ajustan sustancialmente a los del dispositivo servidor 60. En general, la interfaz de red 72 se configura para enviar y recibir datos por medio de la red 74.

[0040] La unidad de procesamiento de solicitudes 70 se configura para recibir peticiones de red desde dispositivos cliente, tales como el dispositivo cliente 40, para datos del medio de almacenamiento 62. Por ejemplo, la unidad de procesamiento de solicitudes 70 puede implementar el protocolo de transferencia de hipertexto (HTTP) versión 1.1, como se describe en RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1", por R. Fielding et al., Network Working Group, IETF, junio de 1999. Es decir, la unidad de procesamiento de solicitudes 70 se puede configurar para recibir solicitudes GET o GET parciales de HTTP y proporcionar datos de contenido multimedia 64 en respuesta a las solicitudes. Las solicitudes pueden especificar un segmento de una de las representaciones 68, por ejemplo, usando un URL del segmento. En algunos ejemplos, las solicitudes también pueden especificar uno o más intervalos de bytes del segmento, comprendiendo por tanto solicitudes GET parciales. La unidad de procesamiento de solicitudes 70 se puede configurar, además, para prestar servicio a solicitudes HEAD HTTP para proporcionar datos de cabecera de un segmento de una de las representaciones 68. En cualquier caso, la unidad de procesamiento de solicitudes 70 se puede configurar para procesar las solicitudes para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente 40.

[0041] De forma adicional o alternativa, la unidad de procesamiento de solicitudes 70 se puede configurar para entregar datos de medios por medio de un protocolo de radiodifusión o multidifusión, tal como el eMBMS. El dispositivo de preparación de contenido 20 puede crear segmentos y/o subsegmentos DASH, sustancialmente de la misma forma que se ha descrito, pero el dispositivo servidor 60 puede entregar estos segmentos o subsegmentos usando eMBMS u otro protocolo de transporte de red de radiodifusión o multidifusión. Por ejemplo, la unidad de procesamiento de solicitudes 70 se puede configurar para recibir una solicitud para unirse a un grupo de multidifusión desde el dispositivo cliente 40. Es decir, el dispositivo servidor 60 puede anunciar una dirección de protocolo de Internet (IP), asociada a un grupo de multidifusión a unos dispositivos cliente, incluyendo el dispositivo cliente 40, asociados a un contenido de medios en particular (por ejemplo, radiodifusión de un acontecimiento en directo). El dispositivo cliente 40, a su vez, puede presentar una solicitud para unirse al grupo de multidifusión. Esta solicitud se puede propagar por toda la red 74, por ejemplo, los encaminadores que componen la red 74, de modo que se hace que los encaminadores dirijan el tráfico destinado a la dirección IP asociada al grupo de multidifusión a los dispositivos cliente abonados, tales como el dispositivo cliente 40.

[0042] 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 de medios (MPD). El archivo de manifiesto 66 puede contener descripciones de diferentes representaciones alternativas 68 (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 tasa de bits y otras características descriptivas de las representaciones 68. El dispositivo cliente 40 puede recuperar la MPD de una presentación de medios para determinar cómo acceder a segmentos de las representaciones 68.

[0043] 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 descodificación del descodificador de vídeo 48 y las capacidades de representación de la salida de vídeo 44. Los datos de configuración también pueden incluir cualquiera o todas las preferencias de idioma seleccionadas por un usuario del dispositivo cliente 40, una o más perspectivas de cámara correspondientes a las preferencias de profundidad establecidas por el usuario del dispositivo cliente 40 y/o una preferencia de calificació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 de medios configurados para enviar solicitudes GET y GET parciales de HTTP. La unidad de recuperación 52 puede corresponder a unas instrucciones de software ejecutadas por uno o más procesadores o unidades de procesamiento (no mostrados) del dispositivo cliente 40. En algunos ejemplos, la totalidad o partes de la funcionalidad descrita con respecto a la unidad de recuperación 52 se pueden implementar en hardware, o una combinación de hardware, software y/o firmware, donde se puede proporcionar el hardware requerido para ejecutar instrucciones para software o firmware.

[0044] La unidad de recuperación 52 puede comparar las capacidades de descodificación y representació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 adaptación. La unidad de recuperación 52 puede seleccionar un subconjunto de representaciones 68 (por ejemplo, un conjunto de adaptación) que tiene características que se pueden satisfacer mediante las capacidades de codificación y representación del dispositivo cliente 40. La unidad de recuperación 52 puede, a continuación, determinar las tasas de bits para las representaciones del conjunto de adaptación, determinar una cantidad actualmente disponible de ancho de banda de red y recuperar segmentos de una de las representaciones que tiene una tasa de bits que se puede satisfacer por el ancho de banda de red.

[0045] En general, las representaciones de tasas de bits mayores pueden producir una reproducción de vídeo de mayor calidad, mientras que las representaciones de tasas de bits menores pueden proporcionar una reproducción de vídeo de calidad suficiente cuando el ancho de banda de red disponible se reduce. En consecuencia, cuando el ancho de banda de red disponible es relativamente alto, la unidad de recuperación 52 puede recuperar datos de representaciones de tasas de bits relativamente altas, mientras que cuando el ancho de banda de red disponible es bajo, la unidad de recuperación 52 puede recuperar datos de representaciones de tasas de bits relativamente bajas. De esta manera, el dispositivo cliente 40 puede realizar la transmisión continua de datos de medios a través de la red 74 mientras que también se adapta a la disponibilidad cambiante de ancho de banda de red de la red 74.

[0046] De forma adicional o alternativa, la unidad de recuperación 52 se puede configurar para recibir datos de acuerdo con un protocolo de red de radiodifusión o multidifusión, tal como la multidifusión eMBMS o IP. En dichos ejemplos, la unidad de recuperación 52 puede enviar una solicitud para unirse a un grupo de red de multidifusión asociado a un contenido de medios 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 solicitudes adicionales emitidas al dispositivo servidor 60 o al dispositivo de preparación de contenido 20. La unidad de recuperación 52 puede enviar una solicitud para abandonar el grupo de multidifusión cuando ya no se necesitan datos del grupo de multidifusión, por ejemplo, para detener la reproducción o para cambiar canales a un grupo de multidifusión diferente.

[0047] 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 a su vez puede proporcionar los segmentos a la unidad de desencapsulación 50. La unidad de desencapsulación 50 puede desencapsular elementos de un archivo de vídeo en flujos PES constituyentes, desempaquetar los flujos PES para recuperar datos codificados y enviar los datos codificados al descodificador de audio 46 o bien al descodificador de vídeo 48, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como lo indican las cabeceras de paquetes PES del flujo. El descodificador de audio 46 descodifica datos de audio codificados y envía los datos de audio descodificados a la salida de audio 42, mientras que el descodificador de vídeo 48 descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de vídeo 44.

[0048] El codificador de vídeo 28, el descodificador de vídeo 48, el codificador de audio 26, el descodificador de audio 46, la unidad de encapsulación 30, la unidad de recuperación 52 y la unidad de desencapsulación 50 se pueden implementar cada uno como cualquiera de una variedad de circuitos de procesamiento adecuados, según corresponda, tales como uno o más microprocesadores, procesadores de señales digitales (DSP), circuitos integrados específicos de la aplicación (ASIC), matrices de puertas programables por campo (FPGA), circuitos de lógica discreta, software, hardware, firmware o cualquier combinación de los mismos. Tanto el codificador de vídeo 28 como el descodificador de vídeo 48 se pueden incluir en uno o más codificadores o descodificadores, que se pueden integrar como parte de un codificador/descodificador (CÓDEC) de vídeo combinado. Asimismo, tanto el codificador de audio 26 como el descodificador de audio 46 se pueden incluir en uno o más codificadores o descodificadores, que se pueden integrar como parte de un CÓDEC combinado. Un aparato que incluye un codificador de vídeo 28, un descodificador de vídeo 48, un codificador de audio 26, un descodificador 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, tal como un teléfono móvil.

[0049] El dispositivo cliente 40, el dispositivo servidor 60 y/o el dispositivo de preparación de contenido 20 se pueden configurar para funcionar de acuerdo con las técnicas de la presente divulgación. Con propósitos de ejemplo, la presente divulgación describe estas técnicas con respecto al dispositivo cliente 40 y al dispositivo servidor 60. Sin embargo, se deberá entender que el dispositivo de preparación de contenido 20 se puede configurar para realizar estas técnicas, en lugar (o, además) del dispositivo servidor 60.

[0050] La unidad de encapsulación 30 puede formar unidades NAL que comprenden una cabecera que identifica un programa al cual pertenece la unidad NAL, así como una carga útil, por ejemplo, datos de audio, datos de vídeo o datos que describen el flujo de transporte o de programa al cual corresponde la unidad NAL. Por ejemplo, en H.264/AVC, una unidad NAL incluye una cabecera 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 desde el codificador de vídeo 28 en forma de paquetes PES de flujos elementales. La unidad de encapsulación 30 puede asociar cada flujo elemental a un programa correspondiente.

[0051] La unidad de encapsulación 30 también puede ensamblar unidades de acceso desde una pluralidad de unidades NAL. En general, una unidad de acceso puede comprender una o más unidades NAL para representar una trama de datos de vídeo, así como datos de audio correspondientes a la trama cuando dichos datos de audio están disponibles. Una unidad de acceso 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 visualización tiene una tasa de tramas de 20 tramas por segundo (fps), 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) se pueden representar simultáneamente. En un ejemplo, una unidad de acceso puede comprender una imagen codificada en una instancia de tiempo, que se puede presentar como una imagen codificada principal.

[0052] En consecuencia, una unidad de acceso puede comprender todas las tramas de audio y vídeo de una instancia temporal común, por ejemplo, todas las vistas correspondientes al tiempo X. La presente divulgación también se refiere a una imagen codificada de una vista particular como un "componente de vista". Es decir, un componente de vista puede comprender una imagen (o trama) codificada para una vista en particular en un tiempo en particular. Por consiguiente, se puede definir una unidad de acceso que comprende todos los componentes de vista de una instancia temporal común. El orden de descodificación de las unidades de acceso no necesita ser el mismo que el orden de salida o de visualización.

[0053] Una presentación de medios puede incluir una descripción de presentación de medios (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 archivo de manifiesto, tal como el archivo de manifiesto 66. El dispositivo cliente 40 puede recuperar la MPD de una presentación de medios para determinar cómo acceder a fragmentos de película de diversas presentaciones. Los fragmentos de película se pueden localizar en cuadros de fragmento de película (cuadros moof) de archivos de vídeo.

[0054] El archivo de manifiesto 66 (que puede comprender, por ejemplo, una MPD) puede anunciar la disponibilidad de segmentos de representaciones 68. Es decir, la MPD puede incluir información que indica el tiempo de reloj en el cual un primer segmento de una de las representaciones 68 queda disponible, así como información que indica las duraciones de los segmentos dentro de las representaciones 68. De esta manera, la unidad de recuperación 52 del dispositivo cliente 40 puede determinar cuándo está disponible cada segmento, en base al tiempo de inicio, así como a las duraciones de los segmentos que preceden a un segmento en particular.

[0055] Después de que la unidad de encapsulación 30 haya ensamblado las unidades NAL y/o las unidades de acceso en un archivo de vídeo, en base a los datos recibidos, la unidad de encapsulación 30 pasa el archivo de vídeo a la interfaz de salida 32 para su envío. 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 por medio de la interfaz de salida 32, en lugar 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 tal como, por ejemplo, una unidad óptica, una unidad de medios magnéticos (por ejemplo, una unidad de disquetes), un puerto de bus serie universal (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, tal como, por ejemplo, una señal de transmisión, un medio magnético, un medio óptico, una memoria, una unidad flash u otro medio legible por ordenador.

[0056] La interfaz de red 54 puede recibir una unidad NAL o unidad de acceso por medio de la red 74 y proporcionar la unidad NAL o la unidad de acceso a la unidad de desencapsulación 50, por medio 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 descodificador de audio 46 o al descodificador de vídeo 48, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como se indica en las cabeceras de paquetes PES del flujo. El descodificador de audio 46 descodifica datos de audio codificados y envía los datos de audio descodificados a la salida de audio 42, mientras que el descodificador de vídeo 48 descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de vídeo 44.

[0057] De acuerdo con las técnicas de la presente divulgación, el archivo de manifiesto 66 se puede modificar para incluir un atributo que señaliza una serie de "trozos" para los cuales están disponibles segmentos de cualquiera o todas las representaciones 68. Por ejemplo, el archivo de manifiesto 66 puede representar una MPD que incluye un atributo "@k" como se analiza con mayor detalle a continuación. Además, la unidad de recuperación 52 y/o la unidad de procesamiento de solicitudes 70 se pueden configurar de acuerdo con las técnicas de la presente divulgación para direccionar trozos de segmento. En particular, el esquema de direccionamiento puede incluir, por ejemplo, el uso de una plantilla de numeración simple ("$Number$") para trozos de segmentos, o un esquema de direccionamiento jerárquico que incluye al menos dos partes. La primera parte puede corresponder a números de segmento completos para los segmentos correspondientes o a información de temporización de los segmentos correspondientes. La información de temporización puede indicar, por ejemplo, un tiempo de reproducción en el que debe comenzar a reproducirse el segmento correspondiente. La segunda parte puede corresponder a identificadores numéricos ordinales de los trozos. Por ejemplo, el esquema de direccionamiento jerárquico puede usar un formato "$Number$.$ChunkNumber$" o un formato "$Time$.$ChunkNumber$".

[0058] De esta manera, el dispositivo cliente 40 representa un ejemplo de un dispositivo para recuperar datos de medios que incluye uno o más procesadores implementados en circuitos y configurados para recibir un archivo de manifiesto que incluye datos que indican un número de trozos de segmento disponibles para un segmento de una representación de datos de medios, comprendiendo el segmento un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único, determinar un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento y enviar una solicitud especificando el identificador para el uno de los trozos a un dispositivo servidor.

[0059] La FIG. 2 es un diagrama de bloques que ilustra con mayor detalle un conjunto de componentes de ejemplo de la unidad de recuperación 52 de la FIG. 1. En este ejemplo, la unidad de recuperación 52 incluye la unidad de middleware eMBMS 100, el cliente de DASH 110 y la aplicación de medios 112.

[0060] En este ejemplo, la unidad de middleware eMBMS 100 incluye, además, la unidad de recepción de eMBMS 106, la memoria caché 104 y la unidad de servidor 102. En este ejemplo, la unidad de recepción de eMBMS 106 se configura para recibir datos por medio de eMBMS, por ejemplo, de acuerdo con la entrega de archivos sobre transporte unidireccional (FLUTE), descrita en T. Paila et al., "FLUTE-File Delivery over Unidirectional Transport", Grupo de trabajo de red, RFC 6726, noviembre de 2012, disponible en http://tools.ietf.org/html/rfc6726. Es decir, la unidad de recepción de eMBMS 106 puede recibir archivos por medio de radiodifusión desde, por ejemplo, el dispositivo servidor 60, que puede actuar como un BM-SC.

[0061] Dado que la unidad de middleware de eMBMS 100 recibe los datos de los archivos, la unidad de middleware de eMBMS puede almacenar los datos recibidos en la memoria caché 104. La memoria caché 104 puede comprender un medio de almacenamiento legible por ordenador, tal como memoria flash, un disco duro, RAM o cualquier otro medio de almacenamiento adecuado.

[0062] La unidad de servidor local 102 puede actuar como un servidor para el cliente de DASH 110. Por ejemplo, la unidad de servidor local 102 puede proporcionar un archivo MPD u otro archivo de manifiesto al cliente de DASH 110. La unidad de servidor local 102 anunciaría tiempos de disponibilidad para segmentos en el archivo MPD, así como hipervínculos desde los cuales se pueden recuperar los segmentos. Estos hipervínculos pueden incluir un prefijo de dirección de localhost correspondiente al dispositivo cliente 40 (por ejemplo, 127.0.0.1 para IPv4). De esta manera, el cliente de DASH 110 puede solicitar segmentos de la unidad de servidor local 102 usando solicitudes GET o GET parciales de HTTP. Por ejemplo, para un segmento disponible en el enlace http://127.0.0.1/rep1/seg3, el cliente de DASH 110 puede construir una solicitud GET de HTTP que incluya una solicitud 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 de DASH 110 en respuesta a dichas peticiones.

[0063] El cliente de DASH 110 se puede configurar de acuerdo con las técnicas de la presente divulgación para solicitar segmentos del servidor proxy 102 usando las convenciones de nomenclatura de la presente divulgación. Asimismo, el cliente de DASH 110 se puede configurar para determinar los nombres de los segmentos usando un archivo de manifiesto recibido del servidor proxy 102, donde el archivo de manifiesto puede indicar un número de "trozos" disponibles para cada segmento completo, por ejemplo, en forma de un atributo "@k" como se analiza con mayor detalle a continuación. De forma similar, el servidor proxy 102 también se puede configurar de acuerdo con las técnicas de la presente divulgación.

[0064] Por ejemplo, el cliente de DASH 110 y el servidor proxy 102 se pueden configurar para denominar trozos de segmento usando una plantilla $Number$ simple. De forma alternativa, el cliente de DASH 110 y el servidor proxy 102 se pueden configurar para denominar trozos de segmento de acuerdo con un esquema de nomenclatura (o direccionamiento) jerárquico, que puede incluir dos partes. La primera parte puede corresponder a números de segmento completos para los segmentos correspondientes o a información de temporización de los segmentos correspondientes. La información de temporización puede indicar, por ejemplo, un tiempo de reproducción en el que debe comenzar a reproducirse el segmento correspondiente. La segunda parte puede corresponder a un identificador ordinal para un trozo de un segmento completo particular.

[0065] La FIG. 3 es un diagrama conceptual que ilustra elementos del contenido multimedia 120 de ejemplo. 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 una descripción de presentación de medios (MPD) 122 y una pluralidad de representaciones 124A-124N (representaciones 124). La representación 124A incluye datos de cabecera 126 y segmentos 128A a 128N (segmentos 128) opcionales, mientras que la representación 124N incluye datos de cabecera 130 y segmentos 132A- 132N (segmentos 132) opcionales. La letra N se usa para designar, por razones de conveniencia, el último fragmento de película en cada una de las representaciones 124. En algunos ejemplos, puede haber diferentes números de fragmentos de películas entre las representaciones 124.

[0066] 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. Del mismo modo, las representaciones 124 pueden corresponder a las representaciones 68 de la FIG. 2. En general, la MPD 122 puede incluir datos que en general describen características de las representaciones 124, tales como características de codificación y representación, conjuntos de adaptación, un perfil al que corresponde la MPD 122, información de tipo de texto, información de ángulo de cámara, información de calificación, la información de modo truco (por ejemplo, información indicativa de representaciones que incluyen subsecuencias temporales) y/o información para recuperar períodos remotos (por ejemplo, para inserción de publicidad dirigida en el contenido de medios durante la reproducción).

[0067] Los datos de cabecera 126, cuando están presentes, pueden describir características de los segmentos 128, por ejemplo, localizaciones temporales de puntos de acceso aleatorio (RAP, también denominados puntos de acceso de flujo (SAP)), cuáles de los segmentos 128 incluyen puntos de acceso aleatorio, desplazamientos de bytes a puntos de acceso aleatorio dentro de los segmentos 128, localizadores de recursos uniformes (URL) de los segmentos 128 u otros aspectos de los segmentos 128. Los datos de cabecera 130, cuando están presentes, pueden describir características similares para los segmentos 132. Adicionalmente o de forma alternativa, dichas características se pueden incluir por completo dentro de la MPD 122.

[0068] 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 los segmentos 128 puede tener características similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Dichas características se pueden describir por datos de la MPD 122, aunque dichos datos no se ilustren en el ejemplo de la FIG. 3. La MPD 122 puede incluir características como se describen en la especificación 3GPP, con la adición de cualquiera o toda la información señalizada descrita en la presente divulgación.

[0069] Cada uno de los segmentos 128, 132 se puede asociar a un único localizador de recursos uniforme (URL). Por tanto, cada uno de los segmentos 128, 132 puede ser independientemente recuperable usando un protocolo de red de transmisión continua, tal como DASH. De esta manera, un dispositivo de destino, tal como el dispositivo cliente 40, puede usar una solicitud GET de HTTP para recuperar los segmentos 128 o 132. En algunos ejemplos, el dispositivo cliente 40 puede usar solicitudes GET parciales de HTTP para recuperar intervalos de bytes específicos de los segmentos 128 o 132.

[0070] De acuerdo con las técnicas de la presente divulgación, la MPD 122 puede incluir un atributo que señaliza un número de trozos de segmento disponibles para un segmento particular. Por ejemplo, la MPD 122 puede incluir un elemento "@k", como se analiza con mayor detalle a continuación. La MPD 122 puede señalizar además un esquema de nomenclatura (o esquema de direccionamiento) que se va a usar para direccionar trozos de segmento. Dicho esquema de nomenclatura/direccionamiento se puede basar en información ordinal y/o información de temporización, como se analiza con mayor detalle a continuación.

[0071] La FIG. 4 es un diagrama de bloques que ilustra elementos de un archivo de vídeo 150 de ejemplo, que puede corresponder a un segmento de una representación, tal como uno de los segmentos 114, 124 de la FIG. 3. Cada uno de los segmentos 128, 132 puede incluir datos que se ajustan sustancialmente a la disposición de datos ilustrada en el ejemplo de la FIG. 4. Se puede decir que el archivo de vídeo 150 encapsula un segmento. Como se ha descrito anteriormente, los archivos de vídeo, de acuerdo con el formato de archivo de medios basado en ISO, y las ampliaciones del mismo, almacenan los datos en una serie de objetos, denominados "cajas". En el ejemplo de la FIG.

4, el archivo de vídeo 150 incluye la caja de tipo de archivo (FTYP) 152, la caja de película (MOOV) 154, las cajas de índices de segmento (sidx) 162, las cajas de fragmento de película (MOOF) 164 y la caja de acceso aleatorio de fragmento de película (MFRA) 166. Aunque la FIG. 4 representa un ejemplo de archivo de vídeo, se deberá entender que otros archivos de medios pueden incluir otros tipos de datos de medios (por ejemplo, datos de audio, datos de texto temporizado o similares) que se estructuran de forma similar a los datos del archivo de vídeo 150, de acuerdo con el formato de archivo de medios basado en ISO y sus ampliaciones.

[0072] La caja de tipo de archivo (FTYP) 152 describe en general 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 un mejor uso para el archivo de vídeo 150. La caja de tipo de archivo 152 se puede colocar de forma alternativa antes de la caja MOOV 154, las cajas de fragmento de película 164 y/o la caja MFRA 166.

[0073] En algunos ejemplos, un segmento, tal como el archivo de vídeo 150, puede incluir una caja de actualización de MPD (no mostrada) antes de la caja FTYP 152. La caja de actualización de MPD puede incluir información que indica que se va a actualizar una MPD correspondiente a una representación que incluye el archivo de vídeo 150, junto con información para actualizar la MPD. Por ejemplo, la caja de actualización de MPD puede proporcionar un URI o URL para un recurso que se va a usar para actualizar la MPD. Como otro ejemplo, la caja de actualización de MPD puede incluir datos para actualizar la MPD. En algunos ejemplos, la caja de actualización de MPD puede seguir inmediatamente a una caja de tipo de segmento (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, analizada con mayor detalle a continuación, proporciona información adicional con respecto a la caja de actualización de MPD.

[0074] La caja de MOOV 154, en el ejemplo de la FIG. 4, incluye la caja de cabecera de película (MVHD) 156, la caja de pista (TRAK) 158 y una o más cajas de ampliación de película (MVEX) 160. En general, la caja de MVHD 156 puede describir características generales del archivo de vídeo 150. Por ejemplo, la caja de MVHD 156 puede incluir datos que describen cuándo se creó inicialmente el archivo de vídeo 150, cuándo se modificó por última vez el archivo de vídeo 150, una escala de tiempo 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 en general el archivo de vídeo 150.

[0075] La caja de TRAK 158 puede incluir datos para una pista del archivo de vídeo 150. La caja de TRAK 158 puede incluir una caja de cabecera de pista (TKHD) que describe las características de la pista correspondiente a la caja de TRAK 158. En algunos ejemplos, la caja de TRAK 158 puede incluir imágenes de vídeo codificadas, mientras que, en otros ejemplos, las imágenes de vídeo codificado de la pista se pueden incluir en fragmentos de película 164, a los cuales se puede hacer referencia mediante los datos de la caja de TRAK 158 y/o de las cajas de SIDX 162.

[0076] En algunos ejemplos, el archivo de vídeo 150 puede incluir más de una pista. Por consiguiente, la caja de MOOV 154 puede incluir un número de cajas de TRAK igual al número de pistas del archivo de vídeo 150. La caja de TRAK 158 puede describir las características de una pista correspondiente del archivo de vídeo 150. Por ejemplo, la caja de TRAK 158 puede describir información temporal y/o espacial para la pista correspondiente. Una caja de TRAK similar a la caja de TRAK 158 de la caja de MOOV 154 puede describir 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, tal como el archivo de vídeo 150. La unidad de encapsulación 30 puede señalizar la presencia de mensajes de SEI a nivel de secuencia en la pista de conjunto de parámetros dentro de la caja de TRAK que describe la pista de conjunto de parámetros.

[0077] Las cajas de MVEX 160 pueden describir características de correspondientes fragmentos de película 164, por ejemplo, para señalizar que el archivo de vídeo 150 incluye fragmentos de película 164, además de los datos de vídeo incluidos dentro de la caja de MOOV 154, si los hubiera. En el contexto de la transmisión continua de datos de vídeo, las imágenes de vídeo codificadas se pueden incluir en los fragmentos de película 164 en lugar de en la caja de MOOV 154. En consecuencia, todas las muestras de vídeo codificadas se pueden incluir en fragmentos de película 164, en lugar de en la caja de MOOV 154.

[0078] La caja de MOOV 154 puede incluir un número de cajas de MVEX 160 igual al número de fragmentos de película 164 del archivo de vídeo 150. Cada una de las cajas de MVEX 160 puede describir características de uno correspondiente de los fragmentos de película 164. Por ejemplo, cada caja de MVEX puede incluir una caja de cabecera de ampliación de película (MEHD) que describe una duración temporal para el uno correspondiente de los fragmentos de película 164.

[0079] Como se indica 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 en general 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 la AVC, la imagen codificada incluye una o más unidades de VCL NAL que contienen la información para construir todos los píxeles de la unidad de acceso y otras unidades de NAL no VCL asociadas, tales como mensajes de SEI. Por consiguiente, la unidad de encapsulación 30 puede incluir un conjunto de datos de secuencia, que puede incluir mensajes de SEI a nivel de secuencia, en uno de los fragmentos de película 164. La unidad de encapsulación 30 puede señalizar, además, la presencia de un conjunto de datos de secuencia y/o de mensajes de SEI a nivel de secuencia con la presencia de estos en uno de los fragmentos de película 164 dentro de una de las cajas de MVEX 160 correspondiente al uno de los fragmentos de película 164.

[0080] Las cajas de SIDX 162 son elementos opcionales del archivo de vídeo 150. Es decir, los archivos de vídeo que se ajustan al formato de archivo 3GPP u otros formatos de archivo de este tipo, no incluyen necesariamente cajas de SIDX 162. De acuerdo con el ejemplo del formato de archivo 3GPP, se puede usar una caja de SIDX 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 autónomo de una o más cajas de fragmento de película consecutivas con un(as) caja(s) de datos de medios correspondiente(s), y una caja de datos de medios que contiene datos a los que se hace referencia mediante una caja de fragmento de película debe seguir a esa caja de fragmento de película y preceder a la siguiente caja de fragmento de película que contiene información sobre la misma pista". El formato de archivo 3GPP también indica que una caja de SIDX "contiene una secuencia de referencias a subsegmentos del (sub)segmento documentado por la caja. Los subsegmentos a los que se hace referencia son contiguos en el tiempo de presentación. De forma similar, los bytes a los que una caja de índice de segmento hace referencia siempre son contiguos dentro del segmento. El tamaño al que se hace referencia da el recuento del número de bytes en el material al que se hace referencia".

[0081] Las cajas de SIDX 162 en general proporcionan 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 tiempos de reproducción en los que comienzan y/o terminan los subsegmentos, desplazamientos de bytes para los subsegmentos, si los subsegmentos incluyen (por ejemplo, comienzan con) un punto de acceso de flujo (SAP), un tipo para el SAP (por ejemplo, si el SAP es una imagen de actualización de descodificador instantánea (IDR), una imagen de acceso aleatorio limpio (CRA), una imagen de acceso de enlace roto (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.

[0082] 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 (GOP), cada uno de los cuales puede incluir varias imágenes de vídeo codificadas, por ejemplo, tramas o imágenes. Así mismo, como se describe anteriormente, los fragmentos de película 164 pueden incluir conjuntos de datos de secuencia en algunos ejemplos. Cada uno de los fragmentos de película 164 puede incluir una caja de cabecera de fragmento de película (MFHD, no mostrada en la FIG. 4). La caja MFHD puede describir características del fragmento de película correspondiente, tales como un número de secuencia para el fragmento de película. Los fragmentos de película 164 se pueden incluir por orden de número de secuencia en el archivo de vídeo 150.

[0083] La caja de MFRA 166 puede describir puntos de acceso aleatorio dentro de fragmentos de película 164 del archivo de vídeo 150. Esto puede ayudar a realizar modos truco, tales como realizar búsquedas hasta localizaciones temporales en particular (es decir, tiempos de reproducción) dentro de un segmento encapsulado por el archivo de vídeo 150. La caja de MFRA 166 en general es opcional y no necesita estar incluida en los archivos de vídeo, en algunos ejemplos. Del mismo modo, un dispositivo cliente, tal como el dispositivo cliente 40, no tiene necesariamente que hacer referencia a la caja de MFRA 166 para descodificar y visualizar correctamente los datos de vídeo del archivo de vídeo 150. La caja de MFRA 166 puede incluir un número de cajas de acceso aleatorio de fragmento de pista (TFRA) (no mostradas) igual al número de pistas del archivo de vídeo 150 o, en algunos ejemplos, igual al número de pistas de medios (por ejemplo, pistas sin indicaciones) del archivo de vídeo 150.

[0084] En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o más puntos de acceso de flujo (SAP), tales como imágenes IDR. Del mismo modo, la caja de MFRA 166 puede proporcionar indicaciones de localizaciones dentro del archivo de vídeo 150 de los SAP. En consecuencia, se puede formar una subsecuencia temporal del archivo de vídeo 150 a partir de los SAP del archivo de vídeo 150. La subsecuencia temporal también puede incluir otras imágenes, tales como tramas P y/o tramas B que dependen de los SAP. Las tramas y/o fragmentos de la subsecuencia temporal se pueden disponer dentro de los segmentos de modo que las tramas/fragmentos de la subsecuencia temporal que dependen de otras tramas/fragmentos de la subsecuencia se pueden descodificar apropiadamente. Por ejemplo, en la disposición jerárquica de los datos, los datos usados para la predicción de otros datos también se pueden incluir en la subsecuencia temporal.

[0085] La FIG. 5 es un diagrama conceptual que ilustra ejemplos de ofertas de segmentos regulares y ofertas con segmentos más cortos. Es decir, la FIG. 5 ilustra una oferta de segmento regular de ejemplo 180 y una oferta de ejemplo con segmentos más cortos 190. Como se muestra en la FIG. 5, los segmentos más cortos pueden reducir el retardo de inicio de la reproducción.

[0086] En las ofertas de DASH regulares, tales como la oferta de segmento regular 180, se ofrecen los segmentos 182A, 182B, 182C para permitir la conmutación, el acceso aleatorio y la entrega con la misma granularidad. Los segmentos 182A, 182B, 182C incluyen respectivos puntos de acceso aleatorio (RAP) 184A, 184B, 184C, que permiten la conmutación de flujo de bits, por ejemplo, la conmutación entre representaciones. Como el generador de contenido (por ejemplo, el dispositivo de preparación de contenido 20 de la FIG. 1) puede necesitar generar segmentos completos 182A, 182B, 182C antes de la publicación, los tiempos de inicio de disponibilidad de segmento (SAST) para los segmentos 182A, 182B, 182C solo están disponibles una vez que se genera uno completo respectivo de los segmentos 182A, 182B, 182C. La oferta con segmentos más cortos 190 incluye los segmentos 192A-192K, y solo los segmentos 192A, 192G incluyen los respectivos RAP 194A, 194B. Con dichos segmentos más cortos, la disponibilidad de segmento puede ser más temprana y el retardo general se puede reducir.

[0087] Sin embargo, tanto para la oferta de segmento regular 180 como para la oferta con segmentos más cortos 190, el SAST, así como los URL de dirección de segmento, se deben generar y señalizar en el MPD de una manera compacta, sin actualizaciones frecuentes de MPD ni restricciones innecesarias en la codificación. Se pueden usar duraciones precisas con líneas de tiempo de segmento para los segmentos más pequeños (consulte la FIG. 6 a continuación), pero esto puede dar como resultado muchas actualizaciones de MPD, así como una señalización compleja y posiblemente una señalización ambigua. Debido a las cadenas de predicción en el vídeo, no se puede determinar la duración exacta de la presentación (y por lo tanto, la dirección).

[0088] La FIG. 6 es un diagrama conceptual que ilustra direcciones de localizador uniforme de recursos (URL) para segmentos disponibles por medio de la oferta de segmento regular 200 y la oferta con segmentos más cortos 210. En este ejemplo, la oferta de segmento regular 200 incluye los segmentos 202A, 202B, 202C, cada uno de los cuales incluye los respectivos RAP 204A, 204B, 204C. La oferta con segmentos más cortos 210 incluye los segmentos 212A-212K, y solo los segmentos 212A y 212 G incluyen los RAP 214A, 214B, respectivamente.

[0089] Como se muestra en la FIG. 6, el uso de ofertas de segmentos más cortos puede dificultar la determinación de las duraciones de las presentaciones de los segmentos más cortos y, por lo tanto, las direcciones de URL de los segmentos también pueden ser difíciles de determinar. Por lo tanto, el direccionamiento $Time$ con duraciones de segmento precisas puede no ser práctico.

[0090] La FIG. 7 es un diagrama conceptual que ilustra conjuntos de ejemplo de datos que se pueden señalizar de acuerdo con las técnicas de la presente divulgación. La FIG. 7 ilustra una oferta de segmento regular de ejemplo 220 y una oferta con secuencias de segmento y atributos $Number$ 230. La oferta de segmento regular 220 incluye los segmentos 222A, 222B, 222C, cada uno de los cuales incluye los respectivos RAP 224A, 224B, 224C. En este ejemplo, la oferta con secuencias de segmento y atributos $Number$ 230 incluye los segmentos 232A-232P, y los segmentos 232A, 232G, 232L incluyen los respectivos RAP 234A, 234B, 234C.

[0091] Las técnicas de la presente divulgación en general implican señalizar un atributo en un archivo de manifiesto, tal como un archivo de descripción de presentación multimedia (MPD), que especifica un número de segmentos incluidos en una secuencia de segmentos. Por ejemplo, para archivos de MPD, se puede añadir un atributo "@k" a un elemento S del SegmentTimeline en el archivo de MPD.

[0092] Como se muestra en el ejemplo de la FIG. 7, se señalizan atributos para ofertas con secuencias de segmento y atributos $Number$ 230. En particular, en el ejemplo de oferta con secuencias de segmento y atributos $Number$ 230 en la FIG. 7, el conjunto de atributos se señaliza como: media="http://ab.com/$Time$_$SubNumber$.m4s", S (t=1000; d=1000; k=6), S (t=2010; d=1000; k=5; r=1)

[0093] El dispositivo cliente 40 de la FIG. 1 simplemente puede incrementar los números de segmento usando la plantilla $Number$, como se muestra en la FIG. 7. Es decir, el dispositivo cliente 40 de la FIG. 1 puede direccionar (por ejemplo, especificar en una solicitud, tal como una solicitud GET o GET parcial de HTTP) cada uno de los segmentos más cortos incrementando los números de segmento en "1". En el ejemplo de la FIG. 7, por ejemplo, el segmento 222A de la oferta de segmento regular 220 corresponde a los segmentos 232A-232F de la oferta con segmentos más cortos 230, el segmento 222B de la oferta de segmento regular 220 corresponde a los segmentos 232G-232K de la oferta con segmentos más cortos 230 y el segmento 222C de la oferta de segmento regular 220 corresponde a los segmentos 232L-232P de la oferta con segmentos más cortos 230.

[0094] Los segmentos 232A-232P se nombran de acuerdo con un esquema de nomenclatura incremental, en este ejemplo, donde el nombre de un segmento corresponde a un número seguido de ".m4s". Por ejemplo, el segmento 232A se denomina "2.m4s", el segmento 232B se denomina "3.m4s", y así sucesivamente. El dispositivo de cliente 40 (y en particular, la unidad de recuperación 52) de la FIG. 1 puede especificar un identificador para uno deseado de los segmentos 232A-232P usando el nombre de segmento correspondiente. Por ejemplo, para recuperar el segmento 232A, el dispositivo cliente 40 puede enviar una solicitud especificando la URL: "ab.com/2.m4s" al dispositivo servidor 60. Este esquema de nomenclatura de segmento (o esquema de direccionamiento) funciona bien para determinados casos de uso, porque los números de segmento simplemente se incrementan en 1. Por tanto, esto sería útil, por ejemplo, para el Comité de sistemas de televisión avanzados (ATSC) con Entrega de objetos en tiempo real a través de transporte unidireccional (ROUTE). Este esquema tampoco requiere actualizaciones de un esquema de plantillas en DASH.

[0095] Para otros casos de uso, esta sencilla señalización basada en números puede no ser suficiente. El motivo es que no funciona con $Time$, o un caso de uso en el que se proporciona una oferta regular junto con una oferta de baja latencia, es que los números de segmento divergen. En base a estos análisis y al $Time$, una numeración jerárquica tanto para señalización basada en $Number$ y basada en $Time$ puede resultar beneficiosa.

[0096] La FIG. 8 ilustra un ejemplo de técnicas para usar numeración jerárquica para los segmentos de acuerdo con las técnicas de la presente divulgación. En este ejemplo, la oferta de segmento regular 240 incluye los segmentos 242A, 242B, 242C, cada uno de los cuales incluye un RAP 244A, 244B, 244C respectivo. La oferta con secuencias de segmento 250, en este ejemplo, incluye segmentos identificados jerárquicamente, es decir, segmentos 252A-252P, y los segmentos 252A, 252g , 252L incluyen los respectivos RAP 254A, 254B, 254C.

[0097] En el ejemplo de la FIG. 8, los segmentos más cortos 252A-252P se direccionan usando un esquema de señalización jerárquica. En particular, en el ejemplo de la FIG. 8, el segmento 242A de la oferta de segmento regular 240 corresponde a los segmentos 252A-252F (denominados "2_1.m4s" a "2_6.m4s" en este ejemplo) de la oferta con secuencias de segmento 250, el segmento 242B de oferta regular 240 corresponde a los segmentos 252G-252K (denominados "3_1.m4s" a "3_5.m4s" en este ejemplo) de la oferta con secuencias de segmento 250, y el segmento 242C de la oferta regular 240 corresponde a los segmentos 252L-252P (denominados "4_1.m4s" a "4_5.m4s" en este ejemplo) de la oferta con secuencias de segmento 250. Los segmentos 242A, 242B, 242C se denominan respectivamente "2.m4s", "3.m4s" y "4.m4s" en este ejemplo. De esta manera, se puede decir que el esquema de nomenclatura es jerárquico, ya que los segmentos 252A-252P se nombran en una forma de dos partes: una primera parte representa el nombre de uno correspondiente de los segmentos 242A-242C, y una segunda parte representa un orden relativo de los segmentos 252A-252P dentro de la secuencia de segmentos correspondiente al mismo de los segmentos 242A-242C.

[0098] Por tanto, cada uno de los segmentos 242A-242C de la oferta de segmento regular 240 puede tener una secuencia de segmento correspondiente de la oferta con secuencias de segmento 250. Los segmentos 252A-252P se pueden direccionar solicitando (por ejemplo, usando solicitudes de GET o GET parciales de HTTP) una URL que especifique la URL de base seguida de "M_N.m4s", donde "M" representa el nombre del correspondiente de los segmentos 242A-242C, y "N" representa un identificador ordinal de un segmento en la secuencia de segmento correspondiente al uno de los segmentos 242A-242C. Por tanto, para recuperar el segmento 252J, el dispositivo cliente 40 puede determinar que el segmento 252J corresponde al segmento 242B, y es el cuarto segmento de la secuencia de segmentos. En consecuencia, el dispositivo cliente 40 puede enviar una solicitud que especifique "ab.com/3_4.m4s" para recuperar el segmento 252J.

[0099] La señalización jerárquica de esta manera puede permitir el despliegue de segmentos de diferentes tamaños en una única MPD, así como una conmutación sencilla. La señalización jerárquica de esta manera también puede evitar la necesidad de una señalización precisa de las duraciones de los segmentos en una secuencia de segmentos.

[0100] La FIG. 9 ilustra otro ejemplo de técnicas para usar numeración jerárquica para los segmentos de acuerdo con las técnicas de la presente divulgación. En este ejemplo, en lugar de direccionar segmentos por número de segmento, los segmentos de la oferta regular se pueden direccionar por información representativa de la duración. En este ejemplo, la oferta de segmento regular 260 incluye los segmentos 262A-262C, cada uno de los cuales incluye los respectivos RAP 264A, 264B, 264C. Los segmentos 262A-262C se nombran de acuerdo con la duración del segmento respectivo, más las duraciones acumuladas de los segmentos anteriores. En este ejemplo, el segmento 262A tiene una duración de 1010 y el segmento 262B tiene una duración de 1000. Además, el segmento 262A sigue a uno o más segmentos que tienen una duración total del segmento de 1000. Por tanto, el segmento 262A se denomina "1000.m4s", el segmento 262B se denomina "2010.m4s" (1000+1010) y el segmento 262C se denomina "3010.m4s" (2010+1000).

[0101] La oferta con secuencias de segmento 270 incluye segmentos más cortos 272A-272P. Sin embargo, en este ejemplo, los segmentos 272A-272P se pueden direccionar por un componente de duración y un componente de subnúmero. El componente de duración puede representar el nombre del uno correspondiente de los segmentos 262A-262C en la oferta de segmento regular 260, como se analiza anteriormente. El componente de subnúmero puede representar un número de segmento para el uno de los segmentos 272A-272P de oferta con secuencias de segmento 270.

[0102] Por tanto, en el ejemplo de la FIG. 9, el segmento 262A (denominado "1000.m4s") de la oferta de segmento regular 260 corresponde a los segmentos 272A-272F (denominados respectivamente "1000_1.m4s" a "1000_6.m4s") de la oferta con secuencias de segmento 270, el segmento 262B (denominado "2010.m4s") de la oferta de segmento regular 260 corresponde a los segmentos 272G-272K (denominados respectivamente "2010_1.m4s" a "2010_5.m4s") de la oferta con secuencias de segmento 270, y el segmento 262C (denominado "3010.m4s") de la oferta de segmento regular 260 corresponde a los segmentos 272L-272P (denominados respectivamente "3010_1.m4s" a "3010_5.m4s") de la oferta con secuencias de segmento 270.

[0103] En consecuencia, el dispositivo cliente 40 puede determinar los nombres de los segmentos 262A-262C en base a las duraciones acumuladas de estos segmentos, como se analiza anteriormente. Además, el dispositivo de cliente 40 puede determinar nombres/identificadores de los segmentos 272A-272P determinando un nombre para uno correspondiente de los segmentos 262A-262C, y a continuación determinando una posición del uno de los segmentos 272A-272P dentro de una secuencia de segmentos correspondientes al uno de los segmentos 262A-262C. Por ejemplo, el dispositivo cliente 40 de la FIG. 1 puede determinar que el nombre para el segmento 272J es "2010_4.m4s", determinando que el nombre del segmento correspondiente 262b en la oferta de segmento regular 260 es "2010.m4s" y determinando que el segmento 272J es el cuarto segmento de la secuencia de segmentos correspondiente al segmento 262B. Para solicitar el segmento 272J, el dispositivo de cliente 40 puede, por tanto, enviar una solicitud de GET o GET parcial de HTTP que especifique "ab.com/2010_4.m4s" como un URL del segmento 272J.

[0104] Una ventaja potencial del ejemplo de la FIG. 9 es que el tiempo de presentación más temprano de una secuencia de segmento siguiente (por ejemplo, una secuencia de segmento correspondiente al segmento 262B) en la misma representación se puede derivar de la suma de la presentación más temprana de la secuencia de segmento actual (1000) y la duración del segmento resultante de la concatenación de todos los segmentos de medios en una secuencia de segmentos. En el caso de ISO BMFF, esto se puede conseguir sumando los recorridos de las pistas de los segmentos en la secuencia de segmentos.

[0105] De esta manera, el dispositivo de cliente 40 puede direccionar segmentos de una oferta de segmento más corta usando un esquema de denominación de dos partes que incluye una primera parte y una segunda parte. La primera parte puede representar números de segmento de los segmentos correspondientes 242A-242C de la oferta de segmento regular 240 (según el ejemplo de la FIG. 8) o información de temporización para los segmentos correspondientes 262A-262C de la oferta de segmento regular 260 (según el ejemplo de la FIG. 9). La información de temporización puede indicar, por ejemplo, un tiempo de reproducción en el que debe comenzar a reproducirse el segmento correspondiente. La segunda parte puede representar incrementos numéricos simples (según los ejemplos de las FIGS. 8 y 9). En particular, los esquemas de nomenclatura de dos partes se pueden denominar "$Number$.$Chunk$" y "$Time$.$Chunk$", respectivamente. De forma alternativa, los esquemas de nomenclatura de dos partes se pueden denominar "$Number$.$ChunkNumber$" y "$Time$.$ChunkNumber$", respectivamente.

[0106] En consecuencia, los dispositivos que usan DASH (tales como el dispositivo cliente 40, el dispositivo servidor 60 y el dispositivo de preparación de contenido 20 de la FIG. 1) se pueden configurar para usar las técnicas de la presente divulgación para procesar (por ejemplo, formar o analizar e interpretar) un archivo de manifiesto que incluye los datos analizados en el presente documento, tales como un atributo (por ejemplo, un atributo "@k") que indica un número de "trozos" de segmento disponibles en una oferta de segmento más corto, así como para direccionar segmentos de acuerdo con algunas o todas las técnicas analizadas en el presente documento usando el atributo del archivo de manifiesto mencionado anteriormente.

[0107] Con respecto al ejemplo de DASH como se especifica en ISO/IEC 23009-1, la sección 5.3.9.4.4 de DASH se puede modificar como se muestra a continuación, donde el texto está rodeado por símbolos de adición de inicio y finalización "||+>||" y "||+<||" representan adiciones y texto rodeado por los símbolos de eliminación de inicio y finalización "->" y ||-<||" representan eliminaciones, otras partes permanecen sin cambios.

5.3.9.4.4 Construcción de URL de segmento basado en plantillas

[0108] El atributo SegmentTemplate@media, el atributo SegmentTemplate@index, el atributo de SegmentTemplate@initialization y el atributo SegmentTemplate@bitstreamSwitching contienen cada uno una cadena que puede contener uno o más de los identificadores enumerados en la Tabla 16.

[0109] En cada URL, los identificadores de la Tabla 16 se sustituirán por el parámetro de sustitución definido en la Tabla 16. La coincidencia de identificadores distingue entre mayúsculas y minúsculas. Si el URL contiene símbolos $ no codificados adecuadamente que no incluyen un identificador válido, entonces el resultado de la formación del URL no está definido. En este caso, se espera que el cliente de DASH ignore todo el elemento de Representación que lo contiene y el procesamiento del MPD continúa como si este elemento de Representación no estuviera presente. El formato del identificador también se especifica en la Tabla 16.

[0110] Cada identificador puede tener un sufijo, dentro de los caracteres '$' de cierre, con una etiqueta de formato adicional alineada con la etiqueta de formato printf como se define en IEEE 1003.1-2008 [10] después de este prototipo:

%0[width]d

[0111] El parámetro width es un entero sin signo que proporciona el número mínimo de caracteres que se van a imprimir. Si el valor a imprimir es más corto que este número, el resultado se rellenará con ceros. El valor no se trunca incluso si el resultado es mayor.

[0112] La presentación de medios se redactará de tal manera que la aplicación del proceso de sustitución dé como resultado URL de segmento válidos.

[0113] Las cadenas fuera de los identificadores solo deben contener caracteres permitidos dentro de los URL de acuerdo con RFC 3986.

TABLA 16-Identificadores para plantillas de URL

[0114] 5.3.9.6 Cambio de SegmentTimeline (cambio de SISSI ||+>||6 ||+<||ll->||5||-<||)

5.3.9.6.1 General

[0115] El elemento SegmentTimeline expresa el tiempo de presentación más temprano y la duración de la presentación (en unidades basadas en el atributo @timescale) para cada segmento en la representación. El uso es una alternativa a proporcionar el atributo @duration y proporciona tres rasgos característicos adicionales:

• la especificación de duraciones de segmento arbitrarias,

• la especificación de duraciones de segmento precisas para un flujo de medios donde la duración expresa la duración de la presentación del segmento, y

• la señalización de discontinuidades de la línea de tiempo de la presentación de medios para la cual no hay datos de segmento presentes en una representación específica.

• la capacidad de señalizar secuencias de segmentos. Para obtener más detalles, consulte 5.3.9.6.4. Las secuencias de segmentos solo se usarán si el perfil en uso lo permite explícitamente.

[0116] Por motivos de compacidad, la sintaxis de este elemento incluye la compresión de longitud de ejecución para expresar una secuencia de segmentos que tienen una duración constante.

[0117] El elemento SegmentTimeline contendrá una lista de S elementos, cada uno de los cuales describe una secuencia de segmentos contiguos de idéntica duración de MPD. El elemento S contiene un atributo @d obligatorio que especifica la duración de MPD, un atributo de recuento de repetición @r opcional que especifica el número de segmentos contiguos con una duración de MPD idéntica menos uno y un atributo de tiempo @t opcional. El valor del atributo @t menos el valor de @presentationTimeOffset especifica el tiempo de inicio de MPD del primer segmento de la serie.

[0118] El atributo @r tiene un valor predeterminado de cero (es decir, un único segmento en la serie) cuando no está presente. Por ejemplo, un recuento repetido de tres significa que hay cuatro segmentos contiguos, cada uno con la misma duración de MPD. El valor del atributo @r del elemento S se puede establecer en un valor negativo que indica que se promete que la duración indicada en @d se repetirá hasta el S@t del siguiente elemento S o si es el último elemento S en el elemento SegmentTimeline hasta el final del período o la siguiente actualización de la MPD, es decir, se trata de la misma forma que el atributo @duration durante un período completo.

[0119] Cualquier valor de @d no excederá el valor de MPD@maxSegmentDuration.

[0120] El orden textual de los elementos S dentro del elemento SegmentTimeline coincidirá con el orden de numeración (y por lo tanto de tiempo) de los correspondientes segmentos de medios.

[0121] Cuando SegmentTemplate está en uso y el identificador $Time$ está presente en SegmentTemplate@media, entonces:

• Si hay presente una caja de índice de segmento ('sidx'), entonces los valores del SegmentTimeline describirán la temporización precisa de cada segmento de medios. Específicamente, estos valores reflejarán la información proporcionada en la caja de índice de segmento ('sidx'), es decir:

o el valor de @timescale será idéntico al valor del campo timescale en la primera caja de 'sidx',

o el valor de S@t será idéntico al valor del early_presentation_time en la primera caja de 'sidx' del segmento de medios descrito en S,

o el valor de S@d será idéntico a la suma de los valores de todos los campos Subsegment_duration en la primera caja de 'sidx' del segmento de medios descrito en S.

o Si no hay presente una caja de índice de segmento ('sidx'), entonces la derivación del tiempo de presentación más temprano se basará en datos internos de medios. Los detalles dependen del formato de segmento en uso y se pueden aplicar restricciones adicionales sobre el formato de segmento.

o El URL de segmento para un segmento multimedia se obtiene sustituyendo el identificador $Time$ por el tiempo de presentación más temprano obtenido de SegmentTimeline.

[0122] NOTA Dado que el tiempo de presentación más temprano del siguiente segmento de medios en la misma representación se puede derivar del segmento de medios real, por ejemplo, mediante el uso del índice de segmento, el URL de segmento se puede generar sin leer la MPD actualizada que contiene la actualización de SegmentTimeline.

[0123] La semántica de los atributos y elementos para SegmentTimeline se proporciona en 5.3.9.6.2, Tabla 17. La sintaxis de XML del SegmentTimeline se proporciona en 5.3.9.6.3.

5.3.9.6.2 Semántica

[0124]

Tabla 17 - Semántica del elemento SegmentTimeline

5.3.9.6.3 Sintaxis de XML

[0125]

<!— Segment Timeline — >

<xs:complexType name="SegmentTimelineType">

<xs:sequence>

<xs:element name="S" minOccurs="1" maxOccurs="unbounded" >

<xs:complexType>

<xs:attribute name="t" type="xs:unsignedLong"/>

<xs:attribute name="n" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="d" type="xs:unsignedLong" use="required"/>

||+>||<xs:attribute name="k" type="xs:unsignedLong" default="1"/>||+<||

<xs:attribute name="r" type="xs:int" use="optional" default="0"/>

<xs: any Attribute namespace="##other" processContent s="lax"/>

</xs:complexType>

</xs:element>

<xs:any namespace="##other" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##other" processContents = "lax"/>

</xs:complexType>

||+>||5.3.9.6.4 Secuencias de segmentos

[0126] Las secuencias de segmentos en SegmentTimeline se pueden señalizar con la inclusión de un atributo @k en el elemento S de SegmentTimeline. El @k solo estará presente si se cumplen la totalidad de los siguientes requisitos:

• el esquema de direccionamiento para la representación asociada usa una plantilla de segmento con $Number$ o plantillas jerárquicas y subnumeración como se define en 5.3.9.6.5,

• el perfil permite explícitamente el uso de secuencias de segmentos.

[0127] Si @k está presente y es mayor que 1, entonces especifica que la secuencia descrita por @d es precisa en temporización, pero contiene @k segmentos.

[0128] La duración de la MPD del segmento se determina como el valor de @d dividido por el valor de @k y determina el tiempo de inicio de la MPD y, por lo tanto, el tiempo de inicio de disponibilidad de segmento. Se debe observar que no se requiere que la duración de la MPD de los segmentos coincida exactamente con la duración de medios de los segmentos.

[0129] La concatenación de todos los segmentos en una secuencia de segmentos tendrá una duración de segmento precisa de acuerdo con el valor de @d.

5.3.9.6.5 Plantillas jerárquicas y subnumeración

[0130] Si la plantilla de segmento contiene un valor $SubNumber$ y se usa una señalización de SegmentTimeline con secuencia de segmento, entonces

• si $Time$ está presente, $Time$ se sustituye por el tiempo de presentación más temprano de la secuencia de segmentos para todos los segmentos en la secuencia de segmentos,

• si $Number$ está presente, $Number$ se sustituye por el número de la secuencia de segmentos, es decir, por el número como si cada secuencia de segmento en SegmentTimeline se tratara como un único segmento,

• y en ambos casos $SubNumber$ se sustituye por el número de segmento de la secuencia de segmentos, siendo 1 el número del primer segmento de la secuencia.

[0131] NOTA El tiempo de presentación más temprano de la siguiente secuencia de segmentos en la misma representación se puede derivar a partir de la suma de la presentación más temprana de la secuencia de segmentos actual y la duración del segmento resultante de la concatenación de todos los segmentos de medios en una secuencia de segmentos. En el caso de ISO BMFF, esto se puede conseguir sumando los recorridos de las pistas de los segmentos en la secuencia de segmentos. ||+<||

[0132] La FIG. 10 es un diagrama de flujo que ilustra un procedimiento de ejemplo de transporte (envío y recepción) de datos de medios de acuerdo con las técnicas de la presente divulgación. El procedimiento de la FIG. 10 se describe como realizado por el dispositivo servidor 60 y el dispositivo cliente 40 de la FIG. 1. Sin embargo, se debe entender que dispositivos adicionales o alternativos se pueden configurar para realizar este procedimiento o uno similar. Por ejemplo, el dispositivo de preparación de contenido 20 puede realizar partes del procedimiento atribuidas al dispositivo servidor junto con, o en lugar de, el dispositivo servidor 60.

[0133] Inicialmente, el dispositivo servidor 60 puede determinar la disponibilidad de trozos de segmentos de datos de medios (300). Por ejemplo, el dispositivo servidor 60 puede determinar un número de trozos para cada uno de una pluralidad de segmentos de una representación o conjunto de adaptación de los datos de medios. El dispositivo servidor 60 puede especificar entonces los datos de disponibilidad en un archivo de manifiesto (302), tal como una descripción de presentación multimedia (MPD). Por ejemplo, como se analiza anteriormente, el dispositivo servidor 60 puede señalizar un elemento "@k" de un elemento S en un elemento de SegmentTimeline del archivo de manifiesto. El elemento @k puede representar un número de segmentos incluidos en una secuencia de segmentos. Dicho número de segmentos se puede entender como trozos de un segmento, y la secuencia de segmentos puede corresponder a una secuencia de trozos para el segmento correspondiente. El dispositivo servidor 60 puede enviar entonces el archivo de manifiesto al dispositivo cliente 40 (304), por ejemplo, en respuesta a una solicitud del dispositivo cliente 40 para el archivo de manifiesto.

[0134] El dispositivo cliente 40 puede recibir el archivo de manifiesto (306). El dispositivo cliente 40 puede determinar entonces los datos de disponibilidad de trozos (308) del archivo de manifiesto. Por ejemplo, la unidad de recuperación 52 (FIG. 1) del dispositivo cliente 40 puede extraer el elemento "@k" del archivo de manifiesto, para determinar un número de trozos en un segmento. El dispositivo cliente 40 puede determinar entonces un identificador para un trozo usando los datos de disponibilidad para los trozos (310). Por ejemplo, como se analiza anteriormente con respecto a las FIGS. 8 y 9, el dispositivo cliente 40 puede determinar un identificador de dos partes para un trozo: una primera parte que representa un nombre de un segmento correspondiente en una oferta de segmento regular (que puede ser un identificador ordinal o un identificador basado en duraciones, como se analiza anteriormente), y una segunda parte que representa un identificador ordinal del trozo en una secuencia de trozos correspondientes al segmento (como también se analiza anteriormente).

[0135] Después de determinar un identificador para recuperar un trozo, el dispositivo cliente 40 puede enviar una solicitud especificando el identificador para el trozo (312). Por ejemplo, el dispositivo cliente 40 puede construir una solicitud GET o GET parcial de HTTP que especifique el identificador para el trozo como parte de un URL para la solicitud. El dispositivo cliente 40 puede enviar entonces la solicitud al dispositivo servidor 60.

[0136] El dispositivo servidor 60 puede recibir entonces la solicitud (314). El dispositivo servidor 60 puede determinar el trozo solicitado usando el identificador (316) como se especifica en la solicitud, por ejemplo, un URL para el trozo. El dispositivo servidor 60 puede enviar a continuación el trozo solicitado (318) al dispositivo cliente 40.

[0137] El dispositivo cliente 40 puede, a su vez, recibir el trozo (320) y descodificar y presentar los datos multimedia del trozo (322). Por ejemplo, la unidad de desencapsulación 50 (que, alternativamente, se puede denominar unidad de procesamiento o análisis de archivos) puede extraer datos de medios codificados del trozo y enviar los datos de medios codificados al descodificador de audio 46 o al descodificador de vídeo 48, dependiendo del tipo de datos de medios. El descodificador de audio 46/descodificador de vídeo 48 puede descodificar los datos de medios y enviar datos multimedia descodificados a la salida de audio 42/salida de vídeo 44 para su presentación.

[0138] De esta manera, el procedimiento de la FIG. 10 representa un ejemplo de un procedimiento que incluye recibir un archivo de manifiesto que incluye datos que indican un número de trozos de segmento disponibles para un segmento de una representación de datos multimedia, comprendiendo el segmento un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único, determinar un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento y enviar una solicitud que especifica el identificador para el uno de los trozos a un dispositivo servidor.

[0139] En uno o más ejemplos, las funciones descritas se pueden implementar en hardware, software, firmware o en cualquier combinación de los mismos. Si se implementan en software, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador como una o más instrucciones o código, y ejecutar mediante una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador que correspondan a un medio tangible, tales como medios de almacenamiento de datos, o medios de comunicación que incluyan cualquier medio que facilite la transferencia de un programa informático de un lugar a otro, por ejemplo, de acuerdo con un protocolo de comunicación. De esta manera, los medios legibles por ordenador pueden corresponder, en general, a (1) medios de almacenamiento tangibles legibles por ordenador que sean no transitorios o a (2) un medio de comunicación tal como una señal o una onda portadora. Los medios de almacenamiento de datos pueden ser medios disponibles cualesquiera a los que se puede acceder desde uno o más ordenadores o uno o más procesadores para recuperar instrucciones, código y/o estructuras de datos para la implementación de las técnicas descritas en la presente divulgación. Un producto de programa informático puede incluir un medio legible por ordenador.

[0140] A modo de ejemplo, y no de 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, cualquier conexión recibe apropiadamente la denominación de 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 (DSL) o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas se incluyen en la definición de medio. Sin embargo, se deberá entender 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, en cambio, están dirigidos a medios de almacenamiento no transitorios tangibles. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen normalmente datos de forma magnética y otros discos reproducen los datos de forma óptica con láseres. Las combinaciones de lo anterior también se deben incluir dentro del alcance de los medios legibles por ordenador.

[0141] Las instrucciones se pueden ejecutar por uno o más procesadores, tales como uno o más procesadores de señales digitales (DSP), microprocesadores de propósito general, circuitos integrados específicos de la aplicación (ASIC), matrices lógicas programables por campo (FPGA) u otros circuitos lógicos integrados o discretos equivalentes. En consecuencia, el término "procesador", como se usa en el presente documento, 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 el presente documento. Además, en algunos aspectos, la funcionalidad descrita en el presente documento se puede proporcionar dentro de módulos de hardware y/o software dedicados configurados para la codificación y la descodificación, o incorporarse en un códec combinado. Además, las técnicas se podrían implementar por completo en uno o más circuitos o elementos lógicos.

[0142] Las técnicas de la presente divulgación se pueden implementar en una amplia variedad de dispositivos o aparatos, incluyendo un teléfono inalámbrico, un circuito integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chips). En esta divulgación se describen diversos componentes, módulos o unidades para destacar aspectos funcionales de dispositivos configurados para realizar las técnicas divulgadas, pero no se requiere necesariamente su realización mediante diferentes unidades de hardware. En su lugar, como se describe anteriormente, diversas unidades se pueden combinar en una unidad de hardware de códec o proporcionar por un grupo de unidades de hardware interoperativas, que incluya uno o más procesadores como se describe anteriormente, junto con software y/o firmware adecuados.

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

Claims

REIVINDICACIONES

1. Un procedimiento de recuperación de datos de medios, comprendiendo el procedimiento:

recibir (306) un archivo de manifiesto que incluye un atributo que indica un número de trozos de segmento disponibles para un segmento de una representación de datos de medios, en el que el atributo se incluye en un elemento S de un elemento SegmentTimeline de una descripción de presentación de medios, MPD, y en el que el segmento comprende un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único;

determinar (310) un identificador para uno de los trozos usando los datos que indican el número de trozos disponibles para el segmento; y

enviar (312) una solicitud que especifica el identificador para el uno de los trozos a un dispositivo servidor.

2. El procedimiento de la reivindicación 1, en el que el atributo que indica el número de trozos de segmento es un atributo @k.

3. El procedimiento de la reivindicación 1, en el que determinar (310) el identificador para uno de los trozos comprende determinar el identificador de acuerdo con una plantilla $Number$ para los trozos de segmento.

4. El procedimiento de la reivindicación 1, en el que determinar (310) el identificador para el uno de los trozos comprende determinar el identificador de acuerdo con un esquema de direccionamiento jerárquico.

5. El procedimiento de la reivindicación 4, en el que el esquema de direccionamiento jerárquico especifica una primera parte y una segunda parte para el identificador.

6. El procedimiento de la reivindicación 5, en el que la primera parte especifica un identificador numérico para el segmento o información de temporización para el segmento.

7. El procedimiento de la reivindicación 5, en el que la primera parte especifica información de temporización para el segmento y en el que la información de temporización indica un tiempo de reproducción en el que el segmento debe comenzar a reproducirse.

8. El procedimiento de la reivindicación 5, en el que la segunda parte especifica un identificador ordinal del uno de los trozos.

9. El procedimiento de la reivindicación 1, en el que:

enviar la solicitud comprende el envío de una solicitud GET de HTTP o una solicitud GET parcial de HTTP; o

se ofrecen trozos de segmento como una secuencia de segmentos que comprende múltiples segmentos que tienen URL respectivos, comprendiendo el además el procedimiento determinar los URL de acuerdo con una plantilla de URL.

10. El procedimiento de la reivindicación 1, en el que:

el archivo de manifiesto no expresa la duración exacta del segmento para los trozos de segmento; o determinar el identificador comprende determinar el identificador sin determinar las duraciones de los trozos de segmento.

11. El procedimiento de la reivindicación 1, que comprende además:

determinar tiempos de inicio de disponibilidad de segmento para los trozos de segmento usando datos del archivo de manifiesto que indican un tiempo de inicio para el segmento, una duración del segmento y el número de trozos de segmento; o

determinar un valor de duración para el segmento a partir del archivo de manifiesto; y dividir el valor de duración por el número de trozos de segmento para determinar valores de duración de los trozos de segmento.

12. Un procedimiento de envío de datos de medios, comprendiendo el procedimiento:

generar (302) un archivo de manifiesto que incluye un atributo que indica un número de trozos de segmento disponibles para un segmento de una representación de datos de medios, en el que el atributo se incluye en un elemento S de un elemento SegmentTimeline de una descripción de presentación multimedia, MPD, y en el que el segmento comprende un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único;

enviar (304) el archivo de manifiesto a un dispositivo cliente;

recibir (314) una solicitud que especifica un identificador para uno de los trozos del dispositivo cliente; y enviar (316) el uno solicitado de los trozos indicados por el identificador al dispositivo cliente en respuesta a la solicitud.

13. Un medio de almacenamiento legible por ordenador que tiene almacenadas en el mismo instrucciones que, cuando se ejecutan, hacen que un procesador lleve a cabo el procedimiento de una cualquiera de las reivindicaciones 1 a 11 o la reivindicación 13.

14. Un dispositivo (40) para recuperar datos de medios, comprendiendo el dispositivo uno o más procesadores implementados en circuitos y configurados para:

15. Un dispositivo servidor (60) para enviar datos multimedia, comprendiendo el dispositivo servidor:

una memoria configurada para almacenar un archivo de manifiesto y los datos de medios; y

uno o más procesadores implementados en circuitos y configurados para:

generar (302) el archivo de manifiesto para incluir un atributo que indica un número de trozos de segmento disponibles para un segmento de una representación de datos de medios, en el que el atributo se incluye en un elemento S de un elemento SegmentTimeline de una descripción de presentación de medios, MPD, y en el que el segmento comprende un archivo de medios recuperable de forma independiente que tiene un localizador uniforme de recursos (URL) único;

enviar (304) el archivo de manifiesto a un dispositivo cliente; y

recibir (314) una solicitud que especifica un identificador para uno de los trozos del dispositivo cliente; y

enviar (316) el uno solicitado de los trozos indicados por el identificador al dispositivo cliente en respuesta a la solicitud.