ES2710702T3 - Temporización en vivo para la transmisión continua dinámica adaptativa sobre el HTTP (DASH) - Google Patents

Abstract

Un procedimiento para recibir información para la transmisión continua de datos de medios, utilizando la transmisión continua dinámica adaptativa, del Grupo de Expertos en Imágenes en Movimiento, sobre el HTTP, DASH de MPEG, el procedimiento que comprende: recibir (154), por un dispositivo cliente (40, 134), una descripción de presentación de medios (104), MPD, para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen (130), y en donde los datos indican un procedimiento de sincronización mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, y en donde el procedimiento de sincronización indicado por la MPD comprende el HTTP, en donde la MPD incluye datos indicativos de direcciones de red para uno o más servidores del HTTP, y en donde la sincronización del reloj comprende solicitar una hora de al menos uno de los servidores del HTTP; sincronizar (166) el reloj del dispositivo cliente con las horas del reloj de pared usando el procedimiento indicado por la MPD, y en donde sincronizar el reloj comprende enviar una solicitud OBTENER del HTTP a al menos uno de los servidores del HTTP y recibir, en respuesta a la solicitud OBTENER del HTTP, un valor de sello cronológico bien formateado que se formatea de acuerdo a uno entre el protocolo de hora de red, NTP, y el Lenguaje de Marcado Extensible, XML, y un código de hora de la organización internacional para la estandarización, ISO; y solicitar (168) datos del contenido de medios desde el dispositivo de origen usando el reloj sincronizado; y en donde la MPD incluye datos que indican que el dispositivo cliente ha de recuperar un segmento del contenido de medios una primera vez y que un dispositivo cliente independiente ha de recuperar el segmento una segunda vez, diferente a la primera vez, y en donde la solicitud de datos comprende solicitar el segmento en o después de la primera vez.

Description

DESCRIPCION

Temporizacion en vivo para la transmision continua dinamica adaptativa sobre el HTTP (DASH)

CAMPO TECNICO

[0001] Esta divulgacion se refiere al transporte de datos de medios codificados, tales como los datos de video.

ANTECEDENTES

[0002] Las capacidades de video digital pueden incorporarse a una amplia gama de dispositivos, incluidos televisores digitales, sistemas de difusion directa digital, sistemas de difusion inalambrica, asistentes digitales personales (PDA), ordenadores portatiles o de sobremesa, camaras digitales, dispositivos de grabacion digitales, reproductores de medios digitales, dispositivos de videojuegos, consolas de videojuegos, telefonos celulares o de radio por satelite, dispositivos de videoconferencia y similares. Los dispositivos de video digital implementan tecnicas de compresion de video, tales como las descritas en las normas definidas por MPEG-2, MPEG-4, ITU-T H.263 o ITU-T H.264/MPEG-4, Parte 10, Codificacion Avanzada de Video (AVC), ITU-T H.265/MPEG-H, Parte 2, Codificacion de Video de Alta Eficacia (HEVC), VP8, VP9 y ampliaciones de dichas normas, para transmitir, recibir y almacenar informacion de video digital mas eficazmente.

[0003] Las tecnicas de compresion de video realizan prediccion espacial y/o prediccion temporal para reducir o eliminar la redundancia inherente a las secuencias de video. Para la codificacion de video basada en bloques, una trama o un fragmento de video pueden dividirse en macrobloques. Cada macrobloque se puede dividir aun mas. Los macrobloques en una trama o un fragmento intracodificados (I) se codifican mediante prediccion espacial con respecto a los macrobloques contiguos. Los macrobloques en una trama o fragmento intercodificados (P o B) pueden utilizar prediccion espacial con respecto a los macrobloques contiguos en la misma trama o fragmento, o prediccion temporal con respecto a otras tramas de referencia.

[0004] Despues de que se hayan codificado los datos de video, los datos de video pueden agruparse en paquetes para su transmision o almacenamiento. Los datos de video pueden reunirse en un fichero de video conforme a cualquiera entre varias normas, tales como el formato de ficheros de medios basicos de la Organizacion Internacional de Normalizacion (ISO) y extensiones del mismo, tales como el formato de fichero de la AVC o el formato de fichero de la HEVC, o al Flujo de Transporte de MPEG-2 u otros formatos de encapsulacion.

SUMARIO

[0005] En general, esta divulgacion describe tecnicas relacionadas con la senalizacion de informacion cronologica para la transmision continua en vivo utilizando, por ejemplo, la transmision continua dinamica adaptativa sobre el HTTP (DASH). Al realizar la transmision continua en vivo, el contenido de medios solo puede prepararse para su transmision despues de que el contenido haya sido recibido (por ejemplo, grabado) y codificado. De acuerdo a las tecnicas de esta divulgacion, un dispositivo de origen puede anunciar los momentos, en la hora de reloj de pared, en los cuales estaran disponibles los segmentos de contenido de medios. El dispositivo de origen puede garantizar que un segmento este completamente formado a la hora de reloj de pared anunciada. Ademas, el dispositivo de origen puede anunciar un procedimiento de sincronizacion mediante el cual los dispositivos clientes pueden sincronizar sus relojes locales con las horas de reloj de pared, por ejemplo, para garantizar que el cliente y el dispositivo de origen funcionen sobre la misma base cronologica. Por ejemplo, el dispositivo de origen puede anunciar el protocolo de hora de red (NTP), el protocolo de temporizacion del protocolo de transferencia de hipertexto (HTTP) (HTP), las cabeceras de fecha del HTTP o las API RESTFUL, utilizando, por ejemplo, el protocolo HTTP como protocolo de sincronizacion. El dispositivo de origen tambien puede anunciar direcciones de red para servidores de sincronizacion de hora. El dispositivo de origen puede anunciar esta informacion de sincronizacion cronologica en un fichero de manifiesto, tal como una descripcion de presentacion de medios (MPD).

[0006] En un ejemplo, un procedimiento de recepcion de informacion para la transmision continua de datos de medios incluye recibir, por parte de un dispositivo cliente, una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, sincronizando el reloj del dispositivo cliente con las horas de reloj de pared usando el procedimiento indicado por la MPD, y solicitando datos del contenido de medios desde el dispositivo de origen usando el reloj sincronizado.

[0007] En otro ejemplo, un dispositivo cliente para recibir informacion para la transmision continua de datos de medios incluye un reloj, y uno o mas procesadores configurados para recibir una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un formato de fichero de procedimiento de sincronizacion o el formato de fichero de la HEVC, o el flujo de transporte de MPEG-2 u otros formatos de encapsulacion. Se reclama atencion al documento US 2012/259994 A1 que describe, en un ejemplo, un dispositivo que incluye una o mas unidades de procesamiento configuradas para enviar, a traves de una red, una solicitud para recuperar al menos una parte del contenido de medios, en donde el contenido de medios es conforme a la transmision continua dinamica adaptativa sobre el HTTP (DASH), y en donde la solicitud comprende una solicitud para que la al menos una parte sea entregada de acuerdo a un servicio de entrega de ficheros y, en respuesta a la solicitud, para recibir datos de transmision continua para la al menos una parte del contenido de medios, de acuerdo al servicio de entrega de ficheros a traves de la red. El dispositivo puede rellenar previamente una memoria cache del navegador con los datos recibidos, de manera que un navegador pueda, en efecto, transmitir continuamente datos utilizando el servicio de entrega de ficheros. El dispositivo puede recuperar inicialmente datos del contenido de medios utilizando la unidifusion, hasta que se alcance un punto de conmutacion de los datos recibidos mediante el servicio de entrega de ficheros. El documento "Adaptive HTTP Streaming: Complete Proposal [Transmision continua adaptativa del HTTP: Propuesta completa]", BORRADOR 3GPP; S4-AHI170_CR_ADAPTIVEHTTPSTREAMING-FULL, 24 de febrero de 2010 (2010-02-24) divulga el uso de varios protocolos en la DASH (por ejemplo, NTP y SNTP) para la sincronizacion con reloj de pared.

SUMARIO

[0008] De acuerdo a la presente invencion, se proporcionan procedimientos, un dispositivo cliente y un medio de almacenamiento legible por ordenador, como se estipula, respectivamente, en las reivindicaciones independientes. Los modos de realizacion preferidos de la invencion se describen en las reivindicaciones dependientes.

[0009] En general, esta divulgacion describe tecnicas relacionadas con la senalizacion de informacion cronologica para la transmision continua en vivo utilizando, por ejemplo, la transmision continua dinamica adaptativa sobre el HTTP (DASH). Al realizar la transmision continua en vivo, el contenido de medios solo puede prepararse para su transmision despues de que el contenido haya sido recibido (por ejemplo, grabado) y codificado. De acuerdo a las tecnicas de esta divulgacion, un dispositivo de origen puede anunciar los momentos, en la hora de reloj de pared, en los cuales estaran disponibles los segmentos de contenido de medios. El dispositivo de origen puede garantizar que un segmento este completamente formado a la hora de reloj de pared anunciada. Ademas, el dispositivo de origen puede anunciar un procedimiento de sincronizacion mediante el cual los dispositivos clientes pueden sincronizar sus relojes locales con las horas de reloj de pared, por ejemplo, para garantizar que el cliente y el dispositivo de origen funcionen sobre la misma base cronologica. Por ejemplo, el dispositivo de origen puede anunciar el protocolo de hora de red (NTP), el protocolo de temporizacion del protocolo de transferencia de hipertexto (HTTP) (HTP), las cabeceras de fecha del HTTP o las API RESTFUL, utilizando, por ejemplo, el protocolo HTTP como protocolo de sincronizacion. El dispositivo de origen tambien puede anunciar direcciones de red para servidores de sincronizacion de hora. El dispositivo de origen puede anunciar esta informacion de sincronizacion cronologica en un fichero de manifiesto, tal como una descripcion de presentacion de medios (MPD).

[0010] En un ejemplo, un procedimiento de recepcion de informacion para la transmision continua de datos de medios incluye recibir, por parte de un dispositivo cliente, una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, sincronizando el reloj del dispositivo cliente con las horas de reloj de pared usando el procedimiento indicado por la MPD, y solicitando datos del contenido de medios desde el dispositivo de origen usando el reloj sincronizado.

[0011] En otro ejemplo, un dispositivo cliente para recibir informacion para la transmision continua de datos de medios incluye un reloj, y uno o mas procesadores configurados para recibir una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las cuales el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con el reloj, sincronizar el reloj con las horas de reloj de pared utilizando el procedimiento indicado por la MPD y solicitar datos del contenido de medios desde el dispositivo de origen utilizando el reloj sincronizado.

[0012] En otro ejemplo, un medio de almacenamiento legible por ordenador ha almacenado en el mismo instrucciones que, cuando se ejecutan, hacen que un procesador de un dispositivo cliente reciba una descripcion de presentacion de medios (MPD) para el contenido de medios, en donde la MPD incluye datos indicativos de las horas de reloj de pared en las cuales el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, sincronizar el reloj del dispositivo cliente con las horas de reloj de pared utilizando el procedimiento indicado por la MPD, y solicitar datos del contenido de medios desde el dispositivo de origen utilizando el reloj sincronizado.

[0013] En otro ejemplo, un procedimiento de senalizacion de informacion para la transmision continua de datos de medios incluye generar datos para una descripcion de presentacion de medios (MPD) para el contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que un dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en el que los datos generados indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, y enviar la MPD al dispositivo cliente.

[0014] En otro ejemplo, un procedimiento de senalizacion de informacion para la transmision continua de datos de medios incluye generar datos para una descripcion de presentacion de medios (MPD) para el contenido de medios, en donde la MPD indica mas de un procedimiento por el cual un dispositivo cliente puede sincronizar las horas de reloj de pared con un reloj del dispositivo de origen. En un ejemplo, el dispositivo cliente puede seleccionar uno o mas procedimientos adecuados para sincronizar con la hora del reloj de pared. Por ejemplo, al escoger varios procedimientos, la sincronizacion con la hora del reloj de pared puede ser mas precisa.

[0015] Los detalles de uno o mas ejemplos se exponen en los dibujos adjuntos y en la siguiente descripcion. Otras caracteristicas, objetos y ventajas resultaran evidentes a partir de la descripcion y de los dibujos, y a partir de las reivindicaciones.

BREVE DESCRIPCION DE LOS DIBUJOS

[0016]

La figura 1 es un diagrama de bloques que ilustra un sistema ejemplar que implementa tecnicas para transmitir por flujo datos de medios a traves de una red.

La figura 2 es un diagrama conceptual que ilustra elementos de contenido ejemplar de multimedios.

La figura 3 es un diagrama conceptual que ilustra un sistema que incluye varios dispositivos que pueden implementar las tecnicas de esta divulgacion.

La figura 4 es un diagrama de flujo que ilustra un procedimiento ejemplar para sincronizar un reloj local de un dispositivo cliente con una hora de reloj de pared y recuperar un segmento utilizando el reloj sincronizado.

DESCRIPCION DETALLADA

[0017] En general, esta divulgacion describe tecnicas para permitir una sincronizacion precisa entre un cliente y un servidor en un entorno para la transmision continua de datos de medios, tal como un entorno de transmision continua dinamica adaptativa sobre el HTTP (DASH). Estas tecnicas se pueden usar para prestar soporte a la Transmision Continua en Vivo del HTTP (HLS). Aunque generalmente se exponen con respecto a DASH y HLS, las tecnicas de esta divulgacion pueden ser aplicables a otros protocolos de transmision continua en red. La DASH se especifica en el documento ISO / IEC 23009-1:2012, "Information Technology - Dynamic adaptive streaming over HTTP (DASH) -Part 1: Media presentation description and segment formats" ["Tecnologia de la informacion - Transmision continua adaptativa dinamica sobre el HTTP (DASH) - Parte 1: Descripcion de presentacion de medios y formatos de segmento", 1 de abril de 2012, disponible en http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip. Las correcciones de errores, las enmiendas y los agregados adicionales pueden estar disponibles para la norma ISO / IEC 23009-1 y las mismas tecnologias pueden aplicarse a cualquiera de estas extensiones.

[0018] En la transmision continua del HTTP, las operaciones de uso frecuente incluyen OBTENER y OBTENER parcial. La operacion OBTENER recupera un fichero completo asociado a un localizador uniforme de recursos (URL) o a un nombre uniforme de recursos (URN) dado. La operacion OBTENER parcial recibe una gama de octetos como parametro de entrada y recupera un numero continuo de octetos de un fichero, donde el numero de octetos corresponde a la gama de octetos recibida. Por lo tanto, se pueden proporcionar fragmentos de pelicula para la transmision continua del HTTP, porque una operacion OBTENER parcial puede obtener uno o mas fragmentos de pelicula individuales. Observese que, en un fragmento de pelicula, puede haber varios fragmentos de pista de diferentes pistas. En la transmision continua del HTTP, una presentacion de medios puede ser una recopilacion de datos estructurada que es accesible para el cliente. El cliente puede solicitar y descargar la informacion de datos de medios para presentar un servicio de transmision continua a un usuario.

[0019] En el ejemplo de la transmision continua de datos del 3GPP utilizando la transmision continua del HTTP, puede haber multiples representaciones de los datos de video y/o audio del contenido de multimedios. Como se explica mas adelante, diferentes representaciones dentro de un conjunto de adaptaciones pueden corresponder a diferentes caracteristicas de codificacion (por ejemplo, diferentes perfiles o niveles de una norma de codificacion de video), diferentes normas de codificacion o extensiones de normas de codificacion (tales como extensiones de multiples vistas y / o ajustables a escala), o diferentes tasas de bits. Los diferentes conjuntos de adaptacion pueden contener diferentes componentes de origen, por ejemplo, diferentes idiomas de audio o diferentes vistas de video. El manifiesto de dichos conjuntos de adaptacion, conteniendo cada uno una o multiples representaciones, se puede definir en una estructura de datos de Descripcion de Presentacion de Medios (MPD). Una presentacion de medios puede corresponder a una recopilacion de datos estructurada que es accesible para un dispositivo cliente de transmision continua del HTTP. El dispositivo cliente de transmision continua del HTTP puede solicitar y descargar informacion de datos de medios para presentar un servicio de transmision continua a un usuario del dispositivo cliente. Una presentacion de medios se puede describir en la estructura de datos de la MPD, que puede incluir actualizaciones de la MPD.

[0020] Una presentacion de medios puede contener una secuencia de uno o mas periodos. Los periodos pueden estar definidos mediante un elemento de Periodo en la MPD. Cada periodo puede tener un atributo de inicio en la MPD. La MPD puede incluir un atributo de InstantelnicioDisponibilidady un atributo de inicio para cada periodo. Para presentaciones de medios de tipo "dinamico" (usadas habitualmente para servicios en vivo), la suma del atributo de inicio del periodo y del atributo InstantelnicioDisponibilidad de la MPD y la duracion del segmento de medios pueden especificar el tiempo de disponibilidad del periodo en formato UTC (Hora Universal Coordinada), en particular, el primer segmento de medios de cada representacion en el periodo correspondiente. Para presentaciones de medios de tipo estatico (normalmente se usa para servicios a pedido), el atributo de inicio del primer periodo puede ser 0. Para cualquier otro periodo, el atributo de inicio puede especificar un desplazamiento temporal entre el instante de inicio del periodo correspondiente con respecto al instante de inicio del primer periodo. Cada periodo puede extenderse hasta el inicio del siguiente periodo, o hasta el final de la presentacion de medios en el caso del ultimo periodo. Los instantes de inicio de periodo pueden ser precisos. Pueden reflejar la temporizacion real resultante de la reproduccion de los medios de todos los periodos anteriores.

[0021] Cada periodo puede contener uno o mas conjuntos de adaptaciones, y cada uno de los conjuntos de adaptacion puede contener una o mas representaciones para el mismo contenido de medios. Una representacion puede ser una entre varias versiones codificadas alternativas de datos de audio o video. Las representaciones pueden variar segun los tipos de codificacion, por ejemplo, segun la tasa de bits, la resolucion y/o el codec para los datos de video y la tasa de bits, el lenguaje y/o el codec para los datos de audio. El termino representacion se puede usar para referirse a una seccion de datos de audio o video codificados, correspondientes a un periodo particular del contenido de multimedios y codificados de una manera particular.

[0022] Los conjuntos de adaptacion de un periodo particular se pueden asignar a un grupo indicado por un atributo de grupo en la MPD. Los conjuntos de adaptacion en el mismo grupo en general se consideran alternativas entre si. Por ejemplo, cada conjunto de adaptacion de datos de video para un periodo determinado se puede asignar a un mismo grupo, de tal manera que se pueda seleccionar cualquiera de los conjuntos de adaptacion para la decodificacion, con el fin de visualizar datos de video del contenido multimedia para el periodo correspondiente. El contenido de medios dentro de un periodo se puede representar mediante un conjunto de adaptacion del grupo 0, si esta presente, o la combinacion de a lo sumo un conjunto de adaptacion de cada grupo distinto de cero, en algunos ejemplos. Los datos de temporizacion para cada representacion de un periodo pueden expresarse con respecto al momento de inicio del periodo.

[0023] Una representacion puede incluir uno o mas segmentos. Cada representacion puede incluir un segmento de inicializacion, o cada segmento de una representacion puede ser auto-inicializador. Cuando esta presente, el segmento de inicializacion puede contener informacion de inicializacion para acceder a la representacion. En general, el segmento de inicializacion no contiene datos de medios. Un segmento puede ser mencionado unicamente por un identificador, tal como un localizador uniforme de recursos (URL), un nombre uniforme de recursos (URN) o un identificador uniforme de recursos (URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD tambien puede proporcionar gamas de octetos en forma de un atributo de gama, que puede corresponder a los datos para un segmento dentro de un fichero accesible por el URL, el URN o el URI.

[0024] Cada representacion tambien puede incluir uno o mas componentes de medios, donde cada componente de medios puede corresponder a una version codificada de un tipo individual de medios, tal como audio, video o texto cronometrado (por ejemplo, para los subtitulos cerrados). Los componentes de medios pueden tener continuidad temporal entre fronteras de segmentos de medios consecutivos dentro de una representacion.

[0025] En general, un dispositivo cliente de DASH puede acceder y descargar una MPD desde un dispositivo servidor de DASH. Es decir, el dispositivo cliente de DASH puede recuperar la MPD para usarla al iniciar una sesion en vivo. En funcion de esta MPD, y para cada Representacion seleccionada, el dispositivo cliente de DASH puede tomar varias decisiones, incluida la determinacion de cual es el mas reciente segmento disponible en el dispositivo servidor, la determinacion de la hora de inicio de disponibilidad de segmento del siguiente segmento y, posiblemente, segmentos futuros, la determinacion de cuando iniciar la reproduccion del segmento y desde que linea cronologica en el segmento, y la determinacion de cuando obtener / capturar una nueva MPD. Una vez que se desempena el servicio, el dispositivo cliente puede rastrear la deriva entre el servicio en vivo y su propio desempeno, que debe ser detectado y compensado.

[0026] La transmision continua en vivo del HTTP (HLS) intenta resolver estas cuestiones de la siguiente manera. Para cada segmento que queda disponible, el dispositivo servidor publica una nueva MPD. El dispositivo cliente, despues de incorporarse al servicio, recupera la ultima MPD, analiza la lista de reproduccion y luego puede acceder al segmento mas reciente. Luego, el dispositivo cliente comienza a reproducir el segmento y se configura bajo la expectativa de que, al reproducir el segmento desde el principio, puede acceder continuamente al segmento siguiente en el tiempo. Antes de capturar un nuevo segmento (o requerir que se capture uno), el dispositivo cliente captura una nueva MPD que proporciona la ubicacion de donde obtener el segmento mas reciente.

[0027] SmoothStreaming intenta resolver estas cuestiones de la siguiente manera. Para cada segmento que queda disponible, el dispositivo servidor publica un nuevo manifiesto equivalente a una MPD. El cliente, despues de incorporarse al servicio, recupera el ultimo manifiesto, analiza el mas reciente segmento disponible obteniendo el atributo "@r" de la LineaCronologicaSegmento del mas reciente elemento S. Esto proporciona la informacion que indica donde obtener el segmento mas reciente. Luego, el dispositivo cliente comienza a reproducir el segmento y se configura bajo la expectativa de que, al reproducir el segmento desde el principio, puede acceder continuamente al segmento siguiente en el tiempo siempre que la proxima solicitud no sea anterior al momento resultante de anadir la duracion del segmento a la hora de la ultima solicitud. Por lo tanto, el cliente continua construyendo Segmentos basandose en el mas reciente elemento LineaCronologicaSegmento.S, sin capturar un nuevo manifiesto hasta que reciba una senal dentro de la banda en cuanto a que el manifiesto actual ya no es utilizable. En este momento (es decir, en respuesta a la senal de que el manifiesto actual ya no es utilizable), el dispositivo cliente solicita un nuevo manifiesto.

[0028] Esta divulgacion reconoce que las soluciones propuestas de HLS y SmoothStreaming pueden tropezar con problemas similares. Por ejemplo, tanto HLS como SmoothStreaming actualizan la MPD / la lista de reproduccion / el manifiesto en el dispositivo servidor con cada segmento recien disponible. Esto significa que se requiere que el dispositivo cliente capture la MPD / la lista de reproduccion / el manifiesto y use la informacion en la MPD / la lista de reproduccion / el manifiesto toda vez que se incorpore a una sesion en vivo. En otras palabras, incorporarse significa capturar MPD / lista de reproduccion / manifiesto, y la MPD / la lista de reproduccion / el manifiesto debe ser la MPD / la lista de reproduccion / el manifiesto mas reciente. Por lo tanto, incluso si se usan plantillas, el servidor necesita actualizar la MPD / la lista de reproduccion / el manifiesto para asimilar un cambio en el recuento de "@r". Esta contabilidad debe hacerse para cada Representacion. La renovacion de MPD / lista de reproduccion / manifiesto es especialmente critica en los casos en que la MPD / la lista de reproduccion / el manifiesto se distribuye mediante FLUTE (Entrega de ficheros sobre transporte unidireccional) o debe insertarse sin solicitud en memorias cache. En este caso, a lo largo de cada segmento nuevo, se debe insertar sin solicitud una nueva MPD / una nueva lista de reproduccion / un nuevo manifiesto.

[0029] Como otro ejemplo, el dispositivo cliente no tiene informacion en cuanto a que hora esta disponible / publicado el siguiente segmento en el dispositivo servidor. Es decir, el dispositivo cliente se configura bajo la expectativa de que el proximo segmento sea publicado, a mas tardar, despues del tiempo de duracion del segmento. Esto se puede verificar actualizando la MPD / lista de reproduccion antes de capturar un nuevo segmento, que es necesario para la HLS. Ademas, el cliente no tiene informacion en cuanto a si se puede reproducir cualquier tiempo de presentacion posterior al tiempo de presentacion mas temprano del mas reciente segmento disponible, para poder acercarse a la vanguardia en vivo sin necesidad de realmacenar de forma temporal posteriormente. Como un hecho del modelo de temporizacion holgada, y al no tener el cliente informacion sobre cuando queda disponible el proximo segmento, el dispositivo cliente debe configurarse bajo el supuesto de que se puede reproducir el tiempo de presentacion mas temprano.

[0030] Ademas, el dispositivo cliente no tiene informacion en cuanto a si esta sincronizada la reproduccion por otros dispositivos clientes que descargan el mismo segmento. Ademas, el dispositivo cliente necesita capturar una nueva MPD al incorporarse al servicio para obtener la informacion mas reciente. Esta "captura" requiere al menos un tiempo de viaje de ida y vuelta de captura de MPD, lo que puede imponer un retraso entre la solicitud para iniciar la sesion en vivo y el momento en que el dispositivo cliente puede comenzar la reproduccion.

[0031] La razon principal de las cuestiones mencionadas anteriormente es que las tecnicas existentes de HLS y SmoothStreaming no proporcionan informacion sobre el calendario exacto de la MPD y la creacion del segmento de medios. Como ejemplo, si se opera en segmentos de 10 segundos, el cliente tiene poca informacion en cuanto a si la MPD / la lista de reproduccion / el manifiesto se acababa de publicar o si se publicara poco despues. Por lo tanto, la temporizacion aun puede estar desviada en hasta 10-epsilon segundos, con epsilon arbitrariamente pequeno pero mayor que 0. Ademas, estas tecnicas de HLS y SmoothStreaming requieren la actualizacion de la MPD / la lista de reproduccion / el manifiesto con frecuencia, con cada segmento recien generado y publicado. No hay ningun reloj de referencia disponible para el cliente que permita una reproduccion que este mas cerca de la vanguardia en vivo o que permita la reproduccion sincronizada con otros clientes en las tecnicas de HLS y SmoothStreaming.

[0032] Las tecnicas de DASH del Grupo de Expertos en Imagenes en Movimiento (MPEG) y de DASH-264 / AVC de DASH-IF tambien intentan abordar esta cuestion. Por ejemplo, en estas tecnicas, se pueden usar unas plantillas basadas en numeros. MPEG-DASH intenta abordar las debilidades mencionadas anteriormente. Es decir, MPEG-DASH intenta operar mas cerca de la vanguardia en vivo, sincronizar la reproduccion de los clientes que estan consumiendo la misma presentacion de medios, evitar las actualizaciones periodicas de la MPD en el servidor y las capturas del cliente, y evitar capturar la MPD en tiempo real al incorporarse al servicio.

[0033] En particular, MPEG-DASH usa una hora de reloj de pared documentada en la MPD, lo que configura la presentacion de medios en vivo. MPEG-DASH supone que la MPD se genera de tal manera que el proceso de generacion de la MPD si tiene acceso a un reloj preciso. Esto permite que los dispositivos clientes que estan sincronizados con la hora de reloj de pared por cualquier medio operen mas cerca de la vanguardia en vivo. Especificamente, la siguiente informacion esta disponible en la MPD cuando se usan representaciones basadas en plantillas numericas y se usa el atributo @duracion:

• MPD@horaInicioDisponibilidad: la hora de inicio es el ancla para la MPD en la hora de reloj de pared. El valor se indica como AST.

• MPD@mfnimoPeriodoActualizaci6n: el periodo minimo de actualizacion de la MPD. El valor se indica como MUP.

• MPD@retrasoPresentacionSugerido: retraso de presentacion sugerido como delta para el tiempo de inicio de disponibilidad del segmento. El valor se indica como SPD.

• MPD@minTiempoAlmacenamientoTemporal: tiempo minimo de almacenamiento temporal, utilizado junto con el atributo @anchodebanda de cada Representacion. El valor se indica como MBT.

• MPD@profundidadAlmacenTemporalDesv^oCronol6gico: profundidad del almacen temporal de desvio cronologico de la presentacion de medios. El valor se indica como TSB.

• Inicio@periodo: la hora de inicio del periodo en relacion con la hora de inicio de disponibilidad de la MPD. El valor se indica como PS.

• NumeroInicio@PlantillaSegmento: numero del primer segmento en el Periodo. El valor se indica como SSN. • Duracion@PlantillaSegmento: la duracion de un segmento en unidades de tiempo. El valor dividido entre el valor de @escalacronologica se indica como d.

[0034] Se supone que el dispositivo cliente capturo la MPD en el momento de captura FT.

[0035] Suponiendo ahora que la hora de reloj de pared en el cliente se indique en WT, entonces el dispositivo cliente puede obtener la siguiente informacion:

• la direccion del mas reciente segmento disponible en el servidor que requiere el numero de segmento mas reciente indicado como LSN

• la hora de inicio de disponibilidad de segmento del siguiente segmento con numero LSN+1 y cualquier otro segmento SN, indicado como SAST(SN). Tengase en cuenta que SN comienza con 1.

• El tiempo de presentacion de medios dentro del segmento que se sincroniza mas cerca de la vanguardia en vivo MPTL.

• El tiempo de presentacion de medios dentro del segmento que se sincroniza con otros clientes, MPTS.

• El momento en que se ha de capturar una nueva MPD en funcion del tiempo de presentacion actual.

[0036] Un ejemplo de las tecnicas de MPEG-DASH se explica a continuacion. En este ejemplo, sea la MPD incluyente de la siguiente informacion:

[0037] Supongamos ademas que un dispositivo cliente captura la MPD y que la hora de reloj de pared es NTP = "2011-12-25T12: 30: 27". Este valor se indica como FT, en este ejemplo.

[0038] El dispositivo cliente obtiene luego el numero de segmento mas reciente. Es decir, el dispositivo cliente obtiene el Periodo mas reciente como el Periodo para el cual AST+PS <= NTP. Si NTP > = AST + PS + d; entonces al menos un segmento dentro de este Periodo esta disponible, y el dispositivo cliente obtiene el numero de segmento mas reciente (LSN) disponible en el cliente segun:

LSN = floor (N T P -(A S T P S ) - d ) id ) SSN = floor (15/2) 22 = 29 (1)

[0039] Por lo tanto, el URL resultante, en este ejemplo, se obtiene como http://www.ejemplo.com/audio/fr/29.mp4.

[0040] El dispositivo cliente luego obtiene la hora de inicio de disponibilidad de segmento (SAST) para un segmento con el numero SN segun:

SAST(SN) = AST PST ( SN - SSN 1 ) * d (2)

[0041] Esto significa que, en este ejemplo, para SN=30, el SAST(SN=30) = 2011-12-25T12: 30: 28.

[0042] El dispositivo cliente luego planifica la reproduccion basandose en la informacion disponible en la MPD. El dispositivo cliente determina el tiempo de presentacion de medios en el Periodo para cada Representacion como el valor del tiempo de presentacion en los segmentos de medios, menos el valor de @desvfoCronol6gicoPresentaci6n, si esta presente, para cada Representacion. Cada segmento con numero de segmento SN incluye un tiempo de presentacion mas temprano, indicado por EPT(SN).

[0043] Al ofrecer una MPD, en MPEG-DASH, se garantiza que:

1. Cada segmento en este Periodo esta disponible antes de su mas temprano tiempo de presentacion, es decir, para todos los SN, EPT (SN) >= SAST (SN) - (AST PST).

2. Si cada segmento con numero de segmento SN se entrega a partir de SAST (SN), por un canal de tasa de bits constante, con tasa de bits igual al valor del atributo @anchodebanda, entonces cada tiempo de presentacion PT esta disponible en el cliente mas reciente en el momento PT (AST PST) MBT.

3. Un tiempo de reproduccion MPTS (PT) recomendado para un tiempo de presentacion cuando se opera en sincronia con otros clientes es MPTS(PT) = (AST PST) PT SPD.

4. Cada segmento en este Periodo esta disponible al menos hasta SAST(SN) TSB d.

[0044] Utilizando esta informacion, el dispositivo cliente puede comenzar a planificar la reproduccion, teniendo en cuenta la informacion en la MPD, asi como la velocidad de descarga. Un tiempo de reproduccion adecuado es POT (PT) = MPTS (PT), si el atributo @retardoPresentacionSugerido esta presente. Si @retardoPresentacionSugerido no esta presente, entonces un tiempo de reproduccion adecuado tiene en cuenta las anteriores restricciones primera, segunda y cuarta, es decir, los tiempos de disponibilidad del segmento en el servidor, asi como la variabilidad de la tasa de bits del flujo de medios.

[0045] El dispositivo cliente usa la MPD para construir segmentos mientras la MPD sea valida. En particular, el dispositivo cliente usa la MPD para construir segmentos hasta el momento de medios FT + MUP. Es decir, el maximo numero de segmento (GSN) que se puede construir es:

GSN = ceil ( F T M U P - (A S T P S )- d )! d ) SSN = ceil (45/2) 22 = 45 (3) [0046] Deberia entenderse que el segmento mas reciente puede ser mas corto que los otros segmentos. Antes de capturar cualquier dato mas alla del segmento numero 45, en el ejemplo anterior, el dispositivo cliente necesita capturar una nueva MPD, de acuerdo a MPEG-DASH.

[0047] De manera mas general, para usar el mismo concepto con diferentes esquemas de sincronizacion y direccionamiento en DASH, se introducen los siguientes valores de acuerdo a ISO / IEC 23009-1:

• la posicion del segmento en el Periodo indicado como k con k = 1,2, ...

• la hora de inicio de la MPD del segmento en la posicion k, denominada MST(k)

• la duracion de la MPD de un segmento en la posicion k, denominada MD(k).

[0048] Suponiendo ahora que la hora de reloj de pared en el dispositivo cliente se indica como WT, el dispositivo cliente puede obtener la siguiente informacion:

1. El mas reciente Periodo disponible en el servidor, indicado por su momento de inicio de periodo PST * 2. La hora de inicio de disponibilidad de segmento de cualquier segmento en la posicion k dentro del Periodo, indicada como SAST(k).

3. La posicion del mas reciente segmento que esta disponible en el servidor en el Periodo, mencionada como k *

4. La direccion del mas reciente segmento que esta disponible en el servidor

5. El momento en el que capturar una nueva MPD en funcion del tiempo de presentacion actual o, mas especificamente, la posicion de segmento mas grande k ’ dentro de este Periodo que puede ser construido por esta MPD.

6. El tiempo de presentacion de medios dentro de la Representacion que se sincroniza mas cerca de la vanguardia en vivo, MPTL.

7. El tiempo de presentacion de medios dentro de la Representacion que se sincroniza con otros clientes, MPTS.

[0049] Usando estos tiempos, el dispositivo cliente puede obtener los valores anteriores segun:

1. El mas reciente Periodo se obtiene como el Periodo para el cual PST <= NTP.

2. El momento de inicio de disponibilidad de segmento se obtiene segun

SSST(k) ~ AST + PST + MST(k) + MD(k) (4)

3. Dentro de este Periodo, el mas reciente segmento disponible en el dispositivo cliente es el segmento en la posicion k * que da como resultado el maximo valor para SAST(k*) y, al mismo tiempo, es mas pequeno que NTP.

4. La direccion del mas reciente segmento se obtiene utilizando la informacion de posicion k* y luego se puede obtener la direccion del segmento. La direccion del segmento depende del procedimiento de direccionamiento.

5. Dentro de este Periodo, la maxima posicion de segmento k que puede ser construida por esta MPD es la que da como resultado el maximo valor para SAST(k) y al mismo tiempo es mas pequena que FT + MUP.

[0050] El dispositivo cliente puede obtener tiempos de la MPD utilizando estos datos. Por ejemplo, si el atributo @duracion esta presente y el valor, dividido entre el valor de @escalacronologica, se indica como d, entonces el dispositivo cliente, utilizando tecnicas de DASH convencionales, obtiene los tiempos de la MPD como:

• MD(k) = d

• MST(k) = (k -1) *d

[0051] En el caso de que la informacion de base del Segmento contenga un elemento de LineaCronologicaSegmento con elementos N^s S, indizados con s = 1, ..., N^s, entonces (en DASH segun ISO / IEC 23009-1):

• f[s] es el valor de @t del s-esimo elemento S dividido entre el valor del atributo @escalacronologica,

• d[s] es el valor de @d del s-esimo elemento S, dividido entre el valor del atributo @escalacronologica,

• r[s] es el valor de @r del s-esimo elemento S (a menos que el valor de @r sea -1, lo que significa que el valor es desconocido y que se puede usar @d hasta que la informacion actualizada este disponible)

[0052] Por lo tanto, el dispositivo cliente puede obtener la duracion de la MPD y los tiempos de inicio de la siguiente manera:

• k=0

• para s = 1,... N^s

o k = k 1

O MST(k) = t[s]

O MD(k) = d[s]

o para j = 1 , ..., r[s]

■ k = k 1

■ MST(k) = MST(k-1) d[s]

■ MD(k) = d[s]

[0053] En DASH, segun ISO / IEC 23009-1, el procedimiento de direccionamiento es independiente del uso de la generacion de la lfnea cronologica. La interpretacion de @numeroInicio depende del procedimiento de direccionamiento. Si la Representacion contiene o hereda uno o mas elementos de la ListaSegmentos, proporcionando un conjunto de uno o mas URL explfcitos para los Segmentos de Medios, entonces el dispositivo cliente determina la posicion del primer segmento en la lista de segmentos usando @numeroInicio. La lista de segmentos proporciona luego los URL explfcitos. Si la Representacion contiene o hereda un elemento de PlantillaSegmento con $Numero$, entonces el URL del segmento de medios en la posicion k se obtiene al reemplazar el identificador $ Numero$ por (k-1) @numeroInicio en la cadena de medios@PlantillaSegmento. Si la Representacion contiene o hereda un elemento de PlantillaSegmento con $Tiempo$, entonces el dispositivo cliente obtiene el URL del Segmento de Medios en la posicion k reemplazando el identificador de $Tiempo$ por MST(k) (desnormalizado con el valor si el atributo @escalacronologica) en la cadena de medios@PlantillaSegmento.

[0054] Ademas, en DASH segun ISO / IEC 23009-1, el dispositivo cliente planifica la reproduccion en funcion de la informacion disponible en la MPD. El dispositivo cliente determina el tiempo de presentacion de medios en un Perfodo para cada Representacion como el valor del tiempo de presentacion en los segmentos de medios, menos el valor del @desvfoCronologicoPresentacion, si esta presente, para cada Representacion. Cada segmento en la posicion k ha asignado un momento mas temprano de presentacion de medios EPT(k).

[0055] Al ofrecer una MPD, DASH, de acuerdo a ISO / IEC 23009-1, garantiza que:

1. Cada segmento en este Perfodo esta disponible antes de su mas temprano momento de presentacion y su duracion, es decir, para todo k,

SAST(k) EPT(k) + (AST PST) M D(k) (5)

2. Si cada segmento con numero de segmento k se entrega a partir de SAST(k) por un canal de tasa de bits constante, con una tasa de bits igual al valor del atributo @anchodebanda, entonces cada momento de presentacion PT esta disponible en el cliente, a mas tardar, en el momento PT + (AST PST) + MBT + MD(k)

3. Un tiempo de reproduccion recomendado MPTS(PT) para un momento de presentacion cuando se opera en sincronfa con otros clientes es MPTS(PT) = (AST + PST) + PT + SPD.

4. Cada segmento en este Perfodo esta disponible al menos hasta SAST(k) + TSB + MD(k).

[0056] Utilizando esta informacion, el dispositivo cliente puede comenzar a planificar la reproduccion, teniendo en cuenta la informacion en la MPD, asf como la velocidad de descarga. Un tiempo de reproduccion adecuado es POT(PT) = MPTS(PT), si el atributo @retardoPresentacionSugerido esta presente. Si el atributo @retardoPresentacionSugerido no esta presente, entonces un tiempo de reproduccion adecuado tiene en cuenta las restricciones primera, segunda y cuarta, es decir, los tiempos de disponibilidad del segmento en el servidor, asf como la variabilidad de la tasa de bits del flujo de medios.

[0057] Segun DASH, de acuerdo a ISO / IEC 23009-1, el dispositivo cliente puede usar la MPD para construir y solicitar segmentos hasta el momento de medios FT + MUP y la posicion de segmento mas grande k que puede ser construida por esta MPD es la que da como resultado el maximo valor para SAST(k ) y al mismo tiempo es mas pequena que FT + MUP. El segmento mas reciente puede ser mas corto que los otros.

[0058] En el caso de que se use la construccion de plantilla con @duracion o con LmeacronologicaSegmento.S@r = "- 1", el enfoque de DASH segun ISO / IEC 23009-1 puede proporcionar varias ventajas en comparacion con el enfoque de HLS y SmoothStreaming, tales como

1. La MPD no tiene que actualizarse en el dispositivo servidor siempre que la construccion del segmento pueda continuar. Mientras el dispositivo cliente registre el tiempo de captura de la MPD, el dispositivo cliente puede descargar la MPD por adelantado (o mantenerla en el almacen temporal) para varios servicios diferentes.

2. Ademas, en un entorno de multidifusion, la MPD puede distribuirse solo una vez o al menos con una frecuencia mucho menor que cada segundo.

3. El dispositivo cliente tiene informacion que indica exactamente la hora en que el siguiente segmento esta disponible / publicado en el dispositivo servidor. Esto permite un funcionamiento mas cercano a la vanguardia en vivo ya que el dispositivo cliente solicita el segmento tan pronto como el segmento queda disponible.

4. El dispositivo cliente puede ubicar la reproduccion del primer segmento que el dispositivo cliente descarga con precision. El dispositivo cliente puede incluso iniciar la reproduccion en el centro del segmento para permitir un funcionamiento mas cercano a la vanguardia en vivo.

5. El dispositivo cliente puede sincronizar su reproduccion con otros dispositivos clientes.

6. El funcionamiento del dispositivo servidor es sencillo, es decir, no se requiere ningun dispositivo servidor dedicado

[0059] A pesar de estas ventajas potenciales, el control de temporizacion mas estricto tambien puede dar lugar a algunas cuestiones que pueden requerir un analisis mas detallado. Por ejemplo, segun DASH conforme a ISO / IEC 23009-1,

1. El dispositivo servidor y el dispositivo cliente deben tener una sincronizacion precisa de la UTC. No hay ningun requisito en cuanto a como implementar esto, pero aun requiere la implementacion de una norma de temporizacion globalmente exacta en ambos extremos. Entre otras, existen las siguientes opciones:

a. Protocolo de hora de red (NTP): http://www.ntp.org

b. Protocolo de hora del HTTP (HTP): http://www.clevervest.com/htp/

c. Sincronia de hora del HTTP (HTS): http://netsecure.alcpress.com/htp/

d. Sistema de localizacion global (GPS)

e. Cabeceras de fecha del HTTP

f. Senalizacion directa en la MPD con una API RESTFUL

g. Senalizacion directa en la MPD

2. El dispositivo servidor puede quedar sobrecargado, ya que todos los dispositivos cliente pueden acceder al segmento al mismo tiempo, ya que se expone explicitamente el momento de disponibilidad del segmento.

[0060] Esta divulgacion tiene como objetivo permitir una sincronizacion precisa entre los dispositivos clientes y los dispositivos servidores en un entorno de DASH.

[0061] La figura 1 es un diagrama de bloques que ilustra un sistema ejemplar 10 que implementa tecnicas para transmitir por flujo datos de medios por una red. En este ejemplo, el sistema 10 incluye el dispositivo de preparacion de contenido 20, el dispositivo servidor 60 y el dispositivo cliente 40. El dispositivo cliente 40 y el dispositivo servidor 60 estan acoplados comunicativamente por la red 74, que puede comprender Internet. En algunos ejemplos, el dispositivo de preparacion de contenido 20 y el dispositivo servidor 60 tambien pueden estar acoplados por la red 74 u otra red, o pueden estar acoplados comunicativamente de manera directa. En algunos ejemplos, el dispositivo de preparacion de contenido 20 y el dispositivo servidor 60 pueden comprender el mismo dispositivo.

[0062] El dispositivo de preparacion de contenido 20, en el ejemplo de la figura 1, comprende el origen de audio 22 y el origen de video 24. El origen de audio 22 puede comprender, por ejemplo, un microfono que produce senales electricas representativas de los datos de audio capturados que han de ser codificados por el codificador de audio 26. Como alternativa, el origen de audio 22 puede comprender un medio de almacenamiento que almacena datos de audio previamente grabados, un generador de datos de audio, tal como un sintetizador informatizado, o cualquier otro origen de datos de audio. El origen de video 24 puede comprender una camara de video que produce datos de video a ser codificados por el codificador de video 28, un medio de almacenamiento codificado con datos de video grabados previamente, una unidad de generacion de datos de video, tal como un origen de graficos de ordenador, o cualquier otro origen de datos de video. El dispositivo de preparacion de contenido 20 no esta necesariamente acoplado comunicativamente al dispositivo servidor 60 en todos los ejemplos, pero puede almacenar contenido de multimedios en un medio independiente que es lefdo por el dispositivo servidor 60.

[0063] Los datos de audio y vfdeo en bruto pueden comprender datos analogicos o digitales. Los datos analogicos pueden digitalizarse antes de ser codificados por el codificador de audio 26 y / o el codificador de vfdeo 28. El origen de audio 22 puede obtener datos de audio desde un orador participante mientras el orador participante esta hablando, y el origen de vfdeo 24 puede obtener simultaneamente datos de vfdeo del orador participante. En otros ejemplos, el origen de audio 22 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de audio almacenados, y el origen de vfdeo 24 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de vfdeo almacenados. De esta manera, las tecnicas descritas en esta divulgacion pueden aplicarse a datos de audio y vfdeo en vivo, de flujo de transmision en tiempo real, o a datos de audio y vfdeo archivados y pregrabados.

[0064] Las tramas de audio que corresponden a tramas de vfdeo son generalmente tramas de audio que contienen datos de audio que fueron capturados por el origen de audio 22 contemporaneamente con los datos de vfdeo capturados por el origen de vfdeo 24, que estan contenidos dentro de las tramas de vfdeo. Por ejemplo, mientras un orador participante produce generalmente datos de audio hablando, el origen de audio 22 captura los datos de audio y el origen de vfdeo 24 captura los datos de vfdeo del orador participante al mismo tiempo, es decir, mientras el origen de audio 22 esta capturando los datos de audio. Por lo tanto, una trama de audio puede corresponder temporalmente a una o mas tramas de vfdeo particulares. Por consiguiente, una trama de audio correspondiente a una trama de vfdeo corresponde generalmente a una situacion en la que se capturaron datos de audio y datos de vfdeo al mismo tiempo, y para la cual una trama de audio y una trama de vfdeo comprenden respectivamente, los datos de audio y los datos de vfdeo que fueron capturados al mismo tiempo.

[0065] En algunos ejemplos, el codificador de audio 26 puede codificar un sello cronologico en cada trama de audio codificada, que representa un momento en que se registraron los datos de audio para la trama de audio codificada y, de manera similar, el codificador de vfdeo 28 puede codificar un sello cronologico en cada trama de vfdeo codificada, que representa un momento en el que se grabaron los datos de vfdeo para la trama de vfdeo codificada. En dichos ejemplos, una trama de audio correspondiente a una trama de vfdeo puede comprender una trama de audio que comprende un sello cronologico y una trama de vfdeo que comprende el mismo sello cronologico. El dispositivo de preparacion de contenido 20 puede incluir un reloj interno a partir del cual el codificador de audio 26 y / o el codificador de vfdeo 28 pueden generar los sellos cronologicos, o que el origen de audio 22 y el origen de vfdeo 24 pueden utilizar para asociar datos de audio y vfdeo, respectivamente, a un sello cronologico.

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

[0067] El codificador de audio 26 generalmente produce un flujo de datos de audio codificados, mientras que el codificador de vfdeo 28 produce un flujo de datos de vfdeo codificados. Cada flujo de datos individual (ya sea audio o vfdeo) puede denominarse un flujo elemental. Un flujo elemental es un componente unico, codificado digitalmente (posiblemente comprimido) de una representacion. Por ejemplo, la parte de vfdeo o audio codificado de la representacion puede ser un flujo elemental. Un flujo elemental se puede convertir en un flujo elemental por paquetes (PES) antes de ser encapsulado dentro de un fichero de vfdeo. Dentro de la misma representacion, se puede usar un Identificador de flujo para distinguir los paquetes de PES que pertenecen a un flujo elemental de los de otro. La unidad basica de datos de un flujo elemental es un paquete de flujo elemental por paquetes (PES). Por lo tanto, los datos de vfdeo codificados generalmente corresponden a flujos de vfdeo elementales. De forma similar, los datos de audio corresponden a uno o mas flujos elementales respectivos.

[0068] Muchas normas de codificacion de vfdeo, tales como ITU-T H.264 / AVC y la inminente norma de codificacion de vfdeo de alta eficacia (HEVC), definen la sintaxis, la semantica y el proceso de decodificacion para flujos de bits sin errores, cualquiera de los cuales puede ajustarse a un determinado perfil o nivel. Las normas de codificacion de vfdeo habitualmente no especifican el codificador, pero el codificador tiene la tarea de garantizar que los flujos de bits generados sean compatibles con normas para un decodificador. En el contexto de las normas de codificacion de vfdeo, un "perfil" corresponde a un subconjunto de algoritmos, caracterfsticas o herramientas y restricciones que se les aplican. Segun lo definido por la norma H.264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits que esta especificada por la norma H.264. Un "nivel" corresponde a las limitaciones del consumo de recursos del decodificador, tales como, por ejemplo, memoria de decodificador y calculo, que estan relacionados con la resolucion de las imagenes, la velocidad de bits y la velocidad de procesamiento de bloques. Un perfil puede ser senalizado con un valor de idc_perfil (indicador de perfil), mientras que un nivel puede ser senalizado con un valor de idc_nivel (indicador de nivel).

[0069] La norma H.264, por ejemplo, reconoce que, dentro de los limites impuestos por la sintaxis de un perfil dado, todavia es posible requerir una gran variacion en el rendimiento de los codificadores y decodificadores, segun los valores tomados por los elementos sintacticos en el flujo de bits, tales como el tamano especificado de las imagenes decodificadas. La norma H.264 reconoce ademas que, en muchas aplicaciones, no es ni practico ni economico implementar un decodificador capaz de tratar todos los usos hipoteticos de la sintaxis dentro de un perfil particular. En consecuencia, la norma H.264 define un "nivel" como un conjunto especificado de restricciones impuestas a los valores de los elementos sintacticos en el flujo de bits. Estas restricciones pueden ser simples limitaciones de valores. Como alternativa, estas restricciones pueden adoptar la forma de restricciones sobre combinaciones aritmeticas de valores (por ejemplo, el ancho de imagen multiplicado por la altura de imagen multiplicada por el numero de imagenes decodificadas por segundo). La norma H.264 provee ademas que implementaciones individuales puedan dar soporte a un nivel diferente para cada perfil con soporte.

[0070] Un decodificador conforme a un perfil generalmente presta soporte a todas las caracteristicas definidas en el perfil. Por ejemplo, como una caracteristica de codificacion, la codificacion de imagenes B no tiene soporte en el perfil de linea de base de la H.264 / AVC, pero tiene soporte en otros perfiles de la H.264 / AVC. Un decodificador conforme a un nivel deberia ser capaz de decodificar cualquier flujo de bits que no requiera recursos mas alla de las limitaciones definidas en el nivel. Las definiciones de perfiles y niveles pueden ser utiles para la interpretabilidad. Por ejemplo, durante la transmision de video, se pueden negociar y acordar un par de definiciones de perfil y nivel para una sesion de transmision completa. Mas especificamente, en la H.264 / AVC, un nivel puede definir limitaciones en el numero de macrobloques que necesitan ser procesados, el tamano del almacenamiento intermedio de imagenes decodificadas (DPB), el tamano del almacenamiento intermedio de imagenes codificadas (CPB), el rango vectorial de movimiento vertical, el numero maximo de vectores de movimiento por dos MB consecutivos, y si un bloque B puede tener particiones de sub-macrobloque inferiores a 8x8 pixeles. De esta manera, un decodificador puede determinar si el decodificador es capaz de decodificar adecuadamente el flujo de bits.

[0071] En el ejemplo de la figura 1, la unidad de encapsulacion 30 del dispositivo de preparacion de contenido 20 recibe flujos elementales que comprenden datos de video codificados desde el codificador de video 28 y flujos elementales que comprenden datos de audio codificados desde el codificador de audio 26. En algunos ejemplos, el codificador de video 28 y el codificador de audio 26 pueden incluir, cada uno, empaquetadores para formar paquetes de PES a partir de datos codificados. En otros ejemplos, el codificador de video 28 y el codificador de audio 26 pueden interactuar, cada uno, con los empaquetadores respectivos para formar paquetes de PES a partir de datos codificados. En otros ejemplos mas, la unidad de encapsulacion 30 puede incluir empaquetadores para formar paquetes de PES a partir de datos de audio y video codificados.

[0072] El codificador de video 28 puede codificar datos de video de contenido de multimedios en varias formas, para producir diferentes representaciones del contenido de multimedios a varias velocidades de bits y con varias caracteristicas, tales como resoluciones de pixeles, velocidades de tramas, conformidad con varias normas de codificacion, conformidad con varios perfiles y / o niveles de perfiles para varias normas de codificacion, representaciones que tienen una o varias vistas (por ejemplo, para reproduccion bidimensional o tridimensional), u otras caracteristicas similares. Una representacion, como se usa en esta descripcion, puede comprender una combinacion de datos de audio y datos de video, por ejemplo, uno o mas flujos elementales de audio y uno o mas flujos elementales de video. Cada paquete de PES incluye un id_flujo que identifica el flujo elemental al que pertenece el paquete de PES. La unidad de encapsulacion 30 es responsable de ensamblar flujos elementales en ficheros de video de varias representaciones.

[0073] La unidad de encapsulacion 30 recibe paquetes de PES para flujos elementales de una representacion desde el codificador de audio 26 y el codificador de video 28 y forma las correspondientes unidades de capa de abstraccion de red (NAL) a partir de los paquetes de PES. En el ejemplo de la H.264/AVC (Codificacion Avanzada de Video), los segmentos de video codificados estan organizados en unidades de NAL, que proporcionan una representacion de video "amigable con las redes" que aborda aplicaciones tales como la videotelefonia, el almacenamiento, la difusion o la transmision por flujo. Las unidades de NAL pueden clasificarse en unidades de NAL de la capa de codificacion de video (VCL) y unidades de NAL no de la VCL. Las unidades de VCL pueden contener el motor de compresion central y pueden incluir datos a nivel de bloque, macrobloque y / o fragmento. Otras unidades de NAL pueden ser unidades de NAL no de VCL. En algunos ejemplos, una imagen codificada en una instancia de tiempo, normalmente presentada como una imagen codificada primaria, puede estar contenida en una unidad de acceso, que puede incluir una o mas unidades de NAL.

[0074] Las unidades de NAL que no son de VCL pueden incluir unidades de NAL del conjunto de parametros y unidades de NAL de SEI, entre otras. Los conjuntos de parametros contienen informacion de cabecera a nivel de secuencia (en conjuntos de parametros de secuencia (SPS)) y la informacion de cabecera a nivel de imagen, que cambia raramente (en conjuntos de parametros de imagen (PPS)). Con los conjuntos de parametros (por ejemplo, PPS y SPS), la informacion que cambia con poca frecuencia no necesita ser repetida para cada secuencia o imagen, por lo que la eficacia de la codificacion puede mejorarse. Ademas, el uso de conjuntos de parametros puede permitir la transmision fuera de banda de la informacion de cabecera importante, evitando la necesidad de transmisiones redundantes, para la capacidad de recuperacion de errores. En los ejemplos de transmision fuera de banda, las unidades de NAL del conjunto de parametros pueden transmitirse en un canal diferente al de otras unidades de NAL, tales como las unidades de NAL de SEI.

[0075] La informacion de mejora suplementaria (SEI) puede contener informacion que no es necesaria para decodificar las muestras de imagenes codificadas a partir de las unidades de NAL de VCL, pero puede ayudar en los procesos relacionados con la decodificacion, visualizacion, resistencia a errores y otros fines. Los mensajes de SEI pueden estar contenidos en las unidades de NAL no de VCL. Los mensajes de SEI son la parte normativa de algunas especificaciones estandar y, por lo tanto, no siempre son obligatorios para la implementacion de decodificadores compatibles con las normas. Los mensajes de SEI pueden ser mensajes de SEI a nivel de secuencia o mensajes de SEI a nivel de imagen. Parte de la informacion a nivel de secuencia puede estar contenida en los mensajes de SEI, tales como los mensajes de SEI de informacion de ajustabilidad a escala en el ejemplo de la SVC y los mensajes de SEI de informacion de ajustabilidad a escala de vistas en la MVC. Estos mensajes ejemplares de SEI pueden transmitir informacion, por ejemplo, sobre extraccion de puntos de operacion y caracteristicas de los puntos de operacion. Ademas, la unidad de encapsulacion 30 puede formar un fichero de manifiesto, tal como un descriptor de presentacion de medios (MPD) que describe las caracteristicas de las representaciones. La unidad de encapsulacion 30 puede formatear el MPD de acuerdo al lenguaje de marcado extensible (XML).

[0076] La unidad de encapsulacion 30 puede proporcionar datos para una o mas representaciones de contenido de multimedios, junto con el fichero de manifiesto (por ejemplo, el MPD), para la interfaz de salida 32. La interfaz de salida 32 puede comprender una interfaz de red o una interfaz para escribir en un medio de almacenamiento, tal como una interfaz del bus universal en serie (USB), una escritora o grabadora de CD o DVD, una interfaz para medios de almacenamiento magneticos o flash, u otras interfaces para almacenamiento o transmision de datos de medios. La unidad de encapsulacion 30 puede proporcionar datos de cada una de las representaciones de contenido de multimedios a la interfaz de salida 32, que puede enviar los datos al dispositivo servidor 60 mediante transmision por red o medios de almacenamiento. En el ejemplo de la figura 1, el dispositivo servidor 60 incluye un medio de almacenamiento 62 que almacena diversos contenidos de multimedios 64, cada uno de los cuales incluye un respectivo fichero de manifiesto 66 y una o mas representaciones 68A a 68N (representaciones 68). En algunos ejemplos, la interfaz de salida 32 tambien puede enviar datos directamente a la red 74.

[0077] En algunos ejemplos, las representaciones 68 se pueden separar en conjuntos de adaptacion. Como se ha senalado anteriormente, en algunos casos, un conjunto de adaptacion tambien puede denominarse "grupo de representacion". Es decir, varios subconjuntos de representaciones 68 pueden incluir respectivos conjuntos comunes de caracteristicas, tales como codec, perfil y nivel, resolucion, numero de vistas, formato de fichero para segmentos, informacion de tipo de texto que pueda identificar un idioma u otras caracteristicas del texto a exhibir con la representacion y / o los datos de audio a decodificar y presentar, por ejemplo, por altavoces, informacion del angulo de la camara que puede describir un angulo de camara o la perspectiva de camara del mundo real de una escena para representaciones en el conjunto de adaptacion, informacion de calificacion que describe la idoneidad del contenido para audiencias particulares, o similares.

[0078] El fichero de manifiesto 66 puede incluir datos indicativos de los subconjuntos de representaciones 68 correspondientes a conjuntos de adaptacion particulares, asi como caracteristicas comunes para los conjuntos de adaptacion. El fichero de manifiesto 66 tambien puede incluir datos representativos de caracteristicas individuales, tales como las tasas de bits, para representaciones individuales de conjuntos de adaptacion. De esta manera, un conjunto de adaptacion puede proveer una adaptacion simplificada del ancho de banda de red. Las representaciones en un conjunto de adaptacion pueden indicarse utilizando elementos dependientes de un elemento de conjunto de adaptacion del fichero de manifiesto 66.

[0079] El dispositivo servidor 60 incluye la unidad de procesamiento de solicitudes 70 y la interfaz de red 72. En algunos ejemplos, el dispositivo servidor 60 puede incluir una pluralidad de interfaces de red. Ademas, cualquiera de, o todas, las caracteristicas del dispositivo servidor 60 pueden implementarse en otros dispositivos de una red de entrega de contenido, tales como encaminadores, puentes, dispositivos delegados, conmutadores u otros dispositivos. En algunos ejemplos, los dispositivos intermedios de una red de entrega de contenido pueden almacenar en memoria cache datos del contenido de multimedios 64, e incluir componentes esencialmente conformes a los del dispositivo servidor 60. En general, la interfaz de red 72 esta configurada para enviar y recibir datos a traves de la red 74.

[0080] La unidad de procesamiento de solicitudes 70 esta configurada para recibir solicitudes de red, desde dispositivos clientes tales como el dispositivo cliente 40, de datos del medio de almacenamiento 62. Por ejemplo, la unidad de procesamiento de solicitudes 70 puede implementar el protocolo de transferencia de hipertexto (HTTP) version 1.1, como se describe en RFC 2616, "Protocolo de transferencia de hipertexto - HTTP / 1.1", por R. Fielding et al, Network Working Group, IETF, junio de 1999. Es decir, la unidad de procesamiento de solicitudes 70 puede configurarse para recibir solicitudes OBTENER u OBTENER parcial del HTTP y proporcionar datos de contenido de multimedios 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 tambien pueden especificar uno o mas rangos de octetos del segmento, comprendiendo asi solicitudes OBTENER parciales. La unidad de procesamiento de solicitudes 70 puede configurarse ademas para atender solicitudes CABECERA del 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 puede configurarse para procesar las solicitudes para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente 40.

[0081] Adicional o alternativamente, la unidad de procesamiento de solicitudes 70 puede configurarse para entregar datos de medios mediante un protocolo de difusion o multidifusion, tal como el eMBMS. El dispositivo de preparacion de contenido 20 puede crear segmentos y / o subsegmentos de DASH, esencialmente de la misma manera que se ha descrito, pero el dispositivo servidor 60 puede entregar estos segmentos o subsegmentos usando el eMBMS u otro protocolo de transporte de red de difusion o multidifusion. Por ejemplo, la unidad de procesamiento de solicitudes 70 puede configurarse para recibir una solicitud de incorporacion a grupo de multidifusion desde el dispositivo cliente 40. Es decir, el dispositivo servidor 60 puede anunciar una direccion del protocolo de Internet (IP), asociada a un grupo de multidifusion, a dispositivos clientes, incluido el dispositivo cliente 40, asociados a contenido de medios particulares (por ejemplo, una difusion de un suceso en vivo). El dispositivo cliente 40, a su vez, puede despachar una solicitud para incorporarse al grupo de multidifusion. Esta solicitud se puede propagar por toda la red 74, por ejemplo, los encaminadores que componen la red 74, de manera tal que provoque que los encaminadores dirijan el trafico, destinado a la direccion de IP asociada al grupo de multidifusion, a los dispositivos clientes abonados, tales como el dispositivo cliente 40.

[0082] Como se ilustra en el ejemplo de la figura 1, el contenido de multimedios 64 incluye el fichero de manifiesto 66, que puede corresponder a una descripcion de presentacion de medios (MPD). El fichero de manifiesto 66 puede contener descripciones de diferentes representaciones alternativas 68 (por ejemplo, servicios de video con diferentes calidades) y la descripcion puede incluir, por ejemplo, informacion de codec, un valor de perfil, un valor de nivel, una tasa de bits y otras caracteristicas descriptivas de las representaciones 68. El dispositivo cliente 40 puede recuperar la MPD de una presentacion de medios para determinar como acceder a segmentos de las representaciones 68.

[0083] En particular, la unidad de recuperacion 52 puede recuperar datos de configuracion (no mostrados) del dispositivo cliente 40 para determinar las capacidades de decodificacion del decodificador de video 48 y las capacidades de representacion de la salida de video 44. Los datos de configuracion tambien pueden incluir cualquiera de, o todas, las preferencias de idioma seleccionadas por un usuario del dispositivo cliente 40, una o mas perspectivas de camara correspondientes a las preferencias de profundidad establecidas por el usuario del dispositivo cliente 40 y / o una preferencia de calificacion seleccionada por el usuario del dispositivo cliente 40. La unidad de recuperacion 52 puede comprender, por ejemplo, un navegador de la Red o un cliente de medios configurado para presentar solicitudes OBTENER y OBTENER parcial del HTTP. La unidad de recuperacion 52 puede corresponder a instrucciones de software ejecutadas por uno o mas procesadores o unidades de procesamiento (no mostradas) del dispositivo cliente 40. En algunos ejemplos, toda, o partes de, la funcionalidad descrita con respecto a la unidad de recuperacion 52 se puede(n) implementar en hardware, o una combinacion de hardware, software y / o firmware, donde se pueda proporcionar el hardware necesario para ejecutar las instrucciones del software o firmware.

[0084] La unidad de recuperacion 52 puede comparar las capacidades de decodificacion y representacion del dispositivo cliente 40 con las caracteristicas de las representaciones 68 indicadas por la informacion del fichero de manifiesto 66. La unidad de recuperacion 52 puede recuperar inicialmente al menos una parte del fichero de manifiesto 66 para determinar las caracteristicas de las representaciones 68. Por ejemplo, la unidad de recuperacion 52 puede solicitar una parte del fichero de manifiesto 66 que describa las caracteristicas de uno o mas conjuntos de adaptacion, de acuerdo a las tecnicas de esta divulgacion. La unidad de recuperacion 52 puede seleccionar un subconjunto de representaciones 68 (por ejemplo, un conjunto de adaptacion) que tenga caracteristicas que pueden ser satisfechas por las capacidades de codificacion y representacion del dispositivo cliente 40. La unidad de recuperacion 52 puede entonces determinar las tasas de bits para las representaciones en el conjunto de adaptacion, determinar una cantidad de ancho de banda de red actualmente disponible y recuperar segmentos de una de las representaciones que tengan una tasa de bits que pueda ser satisfecha por el ancho de banda de la red.

[0085] En general, las representaciones de tasas de bits mas altas pueden producir una reproduccion de video de mayor calidad, mientras que las representaciones de tasas de bits mas bajas pueden proporcionar una reproduccion de video de calidad suficiente cuando disminuye el ancho de banda de red disponible. En consecuencia, cuando el ancho de banda de red disponible es relativamente alto, la unidad de recuperacion 52 puede recuperar datos desde representaciones de tasa de bits relativamente alta, mientras que cuando el ancho de banda de red disponible es bajo, la unidad de recuperacion 52 puede recuperar datos desde representaciones de tasa de bits relativamente baja. De esta manera, el dispositivo cliente 40 puede transmitir por flujo datos de multimedios a traves de la red 74 a la vez que se adapta a la cambiante disponibilidad de ancho de banda de red de la red 74.

[0086] Adicional o alternativamente, la unidad de recuperacion 52 puede configurarse para recibir datos de acuerdo a un protocolo de red de difusion o multidifusion, tal como el eMBMS o el IP multidifundido. En tales ejemplos, la unidad de recuperacion 52 puede presentar una solicitud para incorporarse a un grupo de red de multidifusion asociado a contenido de medios particulares. Despues de incorporarse al grupo de multidifusion, la unidad de recuperacion 52 puede recibir datos del grupo de multidifusion sin solicitudes adicionales emitidas al dispositivo servidor 60 o al dispositivo de preparacion de contenido 20. La unidad de recuperacion 52 puede presentar una solicitud para abandonar el grupo de multidifusion cuando ya no se necesitan datos del grupo de multidifusion, por ejemplo, para detener la reproduccion o para cambiar canales a un grupo de multidifusion diferente.

[0087] La interfaz de red 54 puede recibir y proporcionar datos de segmentos de una representacion seleccionada a la unidad de recuperacion 52, que a su vez puede proporcionar los segmentos a la unidad de desencapsulacion 50. La unidad de desencapsulacion 50 puede desencapsular elementos de un fichero de video en flujos PES constituyentes, desempaquetar los flujos PES para recuperar datos codificados y enviar los datos codificados al decodificador de audio 46 o bien al decodificador de video 48, en funcion de si los datos codificados son parte de un flujo de audio o video, por ejemplo, como lo indican los encabezados de paquetes de PES del flujo. El decodificador de audio 46 decodifica datos de audio codificados y envia los datos de audio decodificados a la salida de audio 42, mientras que el decodificador de video 48 decodifica datos de video codificados y envia los datos de video decodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de video 44.

[0088] El codificador de video 28, el decodificador de video 48, el codificador de audio 26, el decodificador de audio 46, la unidad de encapsulacion 30, la unidad de recuperacion 52 y la unidad de desencapsulacion 50 pueden, cada uno, implementarse como cualquiera entre una variedad de circuitos de procesamiento adecuados, segun corresponda, tales como uno o mas microprocesadores, procesadores de senales digitales (DSP), circuitos integrados especificos de la aplicacion (ASIC), formaciones de compuertas programables en el terreno (FPGA), circuitos logicos discretos, software, hardware, firmware o cualquier combinacion de los mismos. Tanto el codificador de video 28 como el decodificador de video 48 pueden estar incluidos en uno o mas codificadores o decodificadores, cada uno de los cuales puede estar integrado como parte de un codificador/decodificador (codec) de video combinado. Asimismo, cada uno entre el codificador de audio 26 y el decodificador de audio 46 puede incluirse en uno o mas codificadores o decodificadores, cualquiera de los cuales puede integrarse como parte de un codificador/decodificador (CODEC) combinado. Un aparato que incluye un codificador de video 28, un decodificador de video 48, un codificador de audio 26, un decodificador de audio 46, una unidad de encapsulacion 30, una unidad de recuperacion 52 y / o una unidad de desencapsulacion 50 puede comprender un circuito integrado, un microprocesador y / o un dispositivo de comunicacion inalambrica, tal como un telefono celular.

[0089] El dispositivo cliente 40, el dispositivo servidor 60 y / o el dispositivo de preparacion de contenido 20 pueden configurarse para funcionar de acuerdo a las tecnicas de esta divulgacion. Con fines de ejemplo, esta divulgacion describe estas tecnicas con respecto al dispositivo cliente 40 y al dispositivo servidor 60. Sin embargo, deberia entenderse que el dispositivo de preparacion de contenido 20 puede configurarse para realizar estas tecnicas, en lugar del dispositivo servidor 60.

[0090] En general, el dispositivo cliente 40 y el dispositivo servidor 60 pueden configurarse para funcionar de acuerdo a DASH de acuerdo a ISO / IEC 23009-1. Sin embargo, el dispositivo cliente 40 y el dispositivo servidor 60 pueden configurarse de acuerdo a las tecnicas de esta divulgacion para permitir una sincronizacion precisa entre el dispositivo cliente 40 y el dispositivo servidor 60. Por ejemplo, el dispositivo servidor 60 puede configurarse para senalizar datos adicionales en la MPD (por ejemplo, el fichero de manifiesto 66) para dar soporte a la sincronizacion entre el dispositivo cliente 40 y el dispositivo servidor 60. En varios ejemplos (que pueden usarse solos o en cualquier combinacion), el dispositivo servidor 60 puede:

1. Senalizar informacion adicional por el NTP agregando servidores preferidos,

2. Senalizar dispositivos servidores que se recomienda utilizar para el protocolo de hora del HTTP,

3. Senalizar un dispositivo servidor del HTTP que responda con la hora exacta en funcion de una solicitud especifica. Se utilizan diferentes procedimientos, y / o

4. Anadir la hora directamente en la MPD

[0091] Por lo tanto, el dispositivo cliente 40 y el dispositivo servidor 60 pueden configurarse para funcionar de acuerdo a la norma ISO / IEC 23009-1, con la siguiente modificacion en la Tabla 3 de la misma (donde la adicion se indica usando texto subrayado):

Tabla 3 de ISO / IEC 23009-1

[0092] Es decir, la Tabla 3 de la norma ISO / IEC 23009-1 puede modificarse, de acuerdo a las tecnicas de esta divulgacion, para incluir un atributo adicional TemporizacionUTC que especifica informacion sobre una forma recomendada de obtener una sincronizacion con la hora de reloj de pared, como se usa en la MPD correspondiente (por ejemplo, fichero de manifiesto 66). Del mismo modo, las MPD, tales como el fichero de manifiesto 66 de la figura 1, pueden incluir dicho atributo TemporizacionUTC. Por consiguiente, la unidad de encapsulacion 30 puede formar el fichero de manifiesto 66 para incluir el atributo TemporizacionUTC como se ha definido anteriormente, el dispositivo servidor 60 puede proporcionar el fichero de manifiesto 66 al dispositivo cliente 40 que incluye el atributo TemporizacionUTC, y el dispositivo cliente 40 y el dispositivo servidor 60 pueden usar el atributo TemporizacionUTC para coordinar como se puede obtener la hora de reloj de pared.

[0093] La Tabla 3 de la norma ISO / IEC 23009-1 tambien puede modificarse para incluir la adicion que se indica a continuacion en texto subrayado:

<xs:attribute name="id" type="xs:string7>

<xs:attribute name="profiles" type="xs:string" use="required,7>

<xs:attribute rLame="type" type="PresentationType" default="static7>

<xs:attribute namc-"avadabilityStartTimc" ty p e—" x s: d a t c T im e"/>

<xs:attribute name="availabilityEndTime” type="xs:dateTime"/>

<xs:attribute name-'mediaPresentationDuration" t y p c - " xs: d li r a t io n"/>

<xs:attribute name="minimumUpdatePeriod" type="xs:duration"/>

<xs:attribute name="minBufferTime" type="xs:duration" use="required"/>

<xs:attributc namc="timcShiftBuffcrDcpth" typc="xs:duration"/>

<xs:attribute name="suggestedPresentationDelay" type="xs:duration"/>

<xs:attributc namc="maxScgmcntDuration" typc="xs:duration"/>

<xs:attribute name-'maxSubsegmentDuration" type-'xs:duration^-7>

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

</xs:complcxTypc>

<!-- Presentation Type enumeration —>

<xs:simplcTypc namc="PrcscntationTypc">

<xs: restriction base-'xs:string">

<xs:enumeration value "static"/ --<xs:enumeration valuc="dynamic"/>

</xs:rcstriction>

</xs:simplcTypc>

[0094] Es decir, la norma ISO / IEC 23009-1 puede modificarse para incluir el elemento '< xs:element name ="Temporizaci6nllTC" type="TipoDescriptor" minOcurr="0" maxOcurrs= "ilimitado"/> .

[0095] Ademas, la norma ISO / IEC 23009-1 puede modificarse para incluir las siguientes secciones:

5.8.4.10 Descriptor de temporizaci6n de UTC

[0096] Para el elemento Temporizaci6nlTC, el autor de la Presentaci6n de Medios proporciona informaci6n adicional en cuanto a c6mo el cliente puede obtener adecuadamente la sincronizaci6n precisa en cuanto a c6mo se sincroniza la Presentaci6n de Medios con la hora de reloj de pared. Se pueden especificar varios esquemas y se recomienda al cliente que utilice el ordenamiento como una preferencia por parte del autor de la Presentaci6n de Medios. Sin embargo, el cliente puede elegir cualquier procedimiento, teniendo que afrontar, potencialmente, una precisi6n reducida. El cliente tambien puede elegir multiples procedimientos para aumentar la fiabilidad y / o la precisi6n.

5.8.5.X Esquemas de temporizaci6n de UTC de DASH

[0097] DASH define varios procedimientos en cuanto a c6mo obtener informaci6n adicional sobre la sincronizaci6n de temporizaci6n para la presentaci6n de medios. La tabla X a continuaci6n muestra diferentes procedimientos de temporizaci6n.

T l X - Dif r n r imi n m riz i n T

[0098] La siguiente MPD representa un ejemplo de una MPD implementada de acuerdo a las adiciones anteriores a la norma ISO / IEC 23009-1:

[0099] De esta manera, cualquiera de los procedimientos especificados en la Temporizacion de UTC de lo que antecede se puede usar para sincronizar la hora con UTC (tal como una hora de reloj de pared).

[0100] Mas en particular, en el ejemplo de la figura 1, el dispositivo cliente 40 incluye el reloj 56. El reloj 56 representa un ejemplo de un reloj local. De acuerdo a las tecnicas de esta divulgacion, el dispositivo cliente 40 (y, en particular, la unidad de recuperacion 52) puede determinar las horas de reloj de pared en las cuales estaran disponibles los segmentos de contenido de medios. Ademas, el dispositivo cliente 40 puede sincronizar el reloj 56 utilizando las tecnicas de esta divulgacion. Es decir, el fichero de manifiesto 66 (por ejemplo, un fichero de MPD) puede incluir informacion que indique un procedimiento de sincronizacion mediante el cual los dispositivos clientes, tales como el dispositivo cliente 40, han de sincronizar los relojes locales con la hora de reloj de pared, por ejemplo, la hora de UTC. El dispositivo cliente 40 puede recuperar el fichero de manifiesto 66 y determinar el procedimiento de sincronizacion a partir del fichero de manifiesto 66. La informacion del fichero de manifiesto 66 puede indicar ademas una o mas direcciones de red de servidores desde los cuales el dispositivo cliente 40 puede recuperar las horas exactas de reloj de pared. Por lo tanto, el dispositivo cliente 40 puede solicitar horas de uno o mas de los servidores utilizando el procedimiento de sincronizacion (por ejemplo, un protocolo de sincronizacion del tiempo basado en la red, tal como NTP, HTP o HTTP). La unidad de recuperacion 52 puede entonces solicitar un segmento cuando la hora actual, segun lo indicado por el reloj 56, este en o despues de la hora de reloj de pared indicada en el fichero de manifiesto 66 para el segmento.

[0101] En ciertos entornos, una red de entrega de contenido (CDN) (no mostrada en la figura 1) puede configurarse para hacer que el dispositivo cliente no acceda a los Segmentos exactamente en el momento en que los segmentos queden disponibles, o la CDN puede configurarse para hacer que solo un subconjunto de dispositivos clientes acceda a los segmentos exactamente en los momentos de disponibilidad de segmento. El dispositivo servidor 60 puede corresponder a un dispositivo servidor de una CDN. Las razones de esto pueden ser que algunos clientes rellenan las memorias cache de vanguardia (es decir, sus solicitudes se encaminan al servidor de origen), mientras que otros se retrasan deliberadamente para servir a aquellos exclusivamente desde la memoria cache. En otros ejemplos, la CDN puede priorizar ciertos dispositivos clientes, por ejemplo, aquellos que intentan funcionar mas cerca de la vanguardia en vivo, cualquiera puede priorizar a la baja otros dispositivos clientes.

[0102] En otros ejemplos mas, la CDN puede permitir el acceso a ciertas Representaciones de manera priorizada, de modo que la propagacion de solicitudes entre los dispositivos clientes tambien pueda depender de la Representacion elegida. En un nivel alto, los siguientes aspectos pueden implementarse en la norma ISO / IEC 23009­ 1 para prestar soporte a la difusion de las solicitudes:

• Agregar senales a la MPD para iniciar la propagacion de solicitudes de segmentos.

o Los dispositivos clientes, basandose en alguna identificacion unica (por ejemplo, una direccion de MAC o una direccion de IP o un senuelo especifico que se esta fijando, o cualquier otro identificador unico, posiblemente tambien basandose en una solicitud), se asignan al azar a un determinado tipo de receptor. La identificacion tambien puede incluir medios tales que ciertos clientes tengan prioridad.

o Sobre la base de esta identificacion, un cliente puede planificar las solicitudes de segmentos en los momentos de inicio de disponibilidad, o con algun retraso. El retraso es una variable aleatoria extraida de alguna distribucion.

o La distribucion puede distribuirse uniformemente en algun intervalo de tiempo, o puede ser cualquier otra distribucion.

• La senal tambien se puede agregar para cada Representacion, ya que, por ejemplo, puede haber preferencia para que algunas Representaciones sean accesibles mas rapido.

[0103] La unidad de encapsulacion 30 puede formar unidades de NAL que comprenden una cabecera que identifica un programa al cual pertenece la NAL, asi como una carga util, por ejemplo, datos de audio, datos de video o datos que describen el flujo de transporte o de programa al cual corresponde la unidad de NAL. Por ejemplo, en la norma H.264/AVC, una unidad de NAL incluye una cabecera de 1 octeto y una carga util de tamano variable. Una unidad de NAL que incluye datos de video en su carga util puede comprender diversos niveles de granularidad de datos de video. Por ejemplo, una unidad de NAL puede comprender un bloque de datos de video, una pluralidad de bloques, un fragmento de datos de video o una imagen completa de datos de video. La unidad de encapsulacion 30 puede recibir datos de video codificados desde el codificador de video 28 en forma de paquetes de PES de flujos elementales. La unidad de encapsulacion 30 puede asociar cada flujo elemental a un programa correspondiente.

[0104] La unidad de encapsulacion 30 tambien puede ensamblar unidades de acceso a partir de una pluralidad de unidades de NAL. En general, una unidad de acceso puede comprender una o mas unidades de NAL para representar una trama de datos de video, asi como datos de audio correspondientes a la trama cuando dichos datos de audio esten disponibles. Una unidad de acceso generalmente incluye todas las unidades de NAL para una instancia de hora de salida, por ejemplo, todos los datos de audio y video para una instancia de hora. Por ejemplo, si cada vista tiene una velocidad de tramas de 20 tramas por segundo (fps), entonces cada instancia de hora puede corresponder a un intervalo de tiempo de 0,05 segundos. Durante este intervalo de tiempo, las tramas especificas para todas las vistas de la misma unidad de acceso (la misma instancia de hora) se pueden representar simultaneamente. En un ejemplo, una unidad de acceso puede comprender una imagen codificada en una instancia de hora, que puede presentarse como una imagen codificada primaria. Por consiguiente, una unidad de acceso puede comprender todas las tramas de audio y video de una instancia temporal comun, por ejemplo, todas las vistas correspondientes al momento X. Esta divulgacion tambien se refiere a una imagen codificada de una vista particular como un "componente de vista". Es decir, un componente de vista puede comprender una imagen (o trama) codificada para una vista particular en un momento particular. Por consiguiente, se puede definir que una unidad de acceso comprenda todos los componentes de vista de una instancia temporal comun. El orden de decodificacion de las unidades de acceso puede no ser necesariamente el mismo que el orden de salida o de visualizacion.

[0105] Una presentacion de medios puede incluir una descripcion de presentacion de medios (MPD), que puede contener descripciones de diferentes representaciones alternativas (por ejemplo, servicios de video con diferentes calidades) y la descripcion puede incluir, por ejemplo, informacion de codec, un valor de perfil y un valor de nivel. Una MPD es un ejemplo de un fichero de manifiesto, tal como el fichero de manifiesto 66. El dispositivo cliente 40 puede recuperar la MPD de una presentacion de medios para determinar como acceder a fragmentos de pelicula de varias presentaciones. Los fragmentos de peliculas pueden ubicarse en cuadros de fragmentos de peliculas (cuadros moof) de ficheros de video.

[0106] El codificador de video 28, el decodificador de video 48, el codificador de audio 26, el decodificador de audio 46, la unidad de encapsulacion 30 y la unidad de desencapsulacion 50 pueden, cada uno, implementarse como cualquiera entre una diversidad de circuitos de procesamiento adecuados, segun corresponda, tales como uno o mas microprocesadores, procesadores de senales digitales (DSP), circuitos integrados especificos de la aplicacion (ASIC), formaciones de compuertas programables en el terreno (FPGA), circuitos logicos discretos, software, hardware, firmware o cualquier combinacion de los mismos. Tanto el codificador de video 28 como el decodificador de video 48 pueden estar incluidos en uno o mas codificadores o decodificadores, cada uno de los cuales puede estar integrado como parte de un codificador/decodificador (codec) de video combinado. Asimismo, cada uno entre el codificador de audio 26 y el decodificador de audio 46 puede incluirse en uno o mas codificadores o decodificadores, cualquiera de los cuales puede integrarse como parte de un codificador/decodificador (CODEC) combinado. Un aparato que incluye un codificador de video 28, un decodificador de video 48, un codificador de audio 26, un decodificador de audio 46, una unidad de encapsulacion 30 y / o una unidad de desencapsulacion 50 puede comprender un circuito integrado, un microprocesador y / o un dispositivo de comunicacion inalambrica, tal como un telefono celular.

[0107] Despues de que la unidad de encapsulacion 30 haya ensamblado las unidades de NAL y / o las unidades de acceso en un fichero de video, basandose en los datos recibidos, la unidad de encapsulacion 30 pasa el fichero de video a la interfaz de salida 32 para su salida. En algunos ejemplos, la unidad de encapsulacion 30 puede almacenar el fichero de video localmente o enviar el fichero de video a un servidor remoto a traves de la interfaz de salida 32, en lugar de enviar el fichero de video 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 optica, una unidad de medios magneticos (por ejemplo, una unidad de disquete), un puerto de bus en serie universal (USB), una interfaz de red u otra interfaz de salida. La interfaz de salida 32 emite el fichero de video a un medio legible por ordenador 34, tal como, por ejemplo, una senal de transmision, un medio magnetico, un medio optico, una memoria, una unidad flash u otro medio legible por ordenador.

[0108] La interfaz de red 54 puede recibir una unidad de NAL o unidad de acceso a traves de la red 74 y proporcionar la unidad de NAL o la unidad de acceso a la unidad de desencapsulacion 50, mediante la unidad de recuperacion 52. La unidad de desencapsulacion 50 puede desencapsular un elemento de un fichero de video en flujos PES constituyentes, desempaquetar los flujos PES para recuperar datos codificados y enviar los datos codificados al decodificador de audio 46 o al decodificador de video 48, en funcion de si los datos codificados son parte de un flujo de audio o video, por ejemplo, segun lo indicado por los encabezados de paquetes de PES del flujo. El decodificador de audio 46 decodifica datos de audio codificados y envia los datos de audio decodificados a la salida de audio 42, mientras que el decodificador de video 48 decodifica datos de video codificados y envia los datos de video decodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de video 44.

[0109] La figura 2 es un diagrama conceptual que ilustra elementos del contenido ejemplar de multimedios 102. El contenido de multimedios 102 puede corresponder al contenido de multimedios 64 (figura 1), o a otro contenido de multimedios almacenado en el medio de almacenamiento 62. En el ejemplo de la figura 2, el contenido de multimedios 102 incluye una descripcion de presentacion de medios (MPD) 104 y una pluralidad de representaciones 110 a 120. La representacion 110 incluye datos de cabecera optativos 112 y segmentos 114A a 114N (segmentos 114), mientras que la representacion 120 incluye datos de cabecera optativos 122 y segmentos 124A a 124N (segmentos 124). La letra N se usa para designar el ultimo fragmento de pelicula en cada una de las representaciones 110, 120, por comodidad. En algunos ejemplos, puede haber diferentes numeros de fragmentos de peliculas entre las representaciones 110, 120.

[0110] La MPD 104 puede comprender una estructura de datos independiente de las representaciones 110 a 120. La MPD 104 puede corresponder al fichero de manifiesto 66 de la figura 1. Del mismo modo, las representaciones 110 a 120 pueden corresponder a las representaciones 68 de la figura 1. En general, la MPD 104 puede incluir datos que generalmente describen caracteristicas de las representaciones 110 a 120, tales como las caracteristicas de codificacion y representacion, los conjuntos de adaptacion, un perfil al que corresponde la MPD 104, la informacion del tipo de texto, la informacion del angulo de la camara, la informacion de calificacion, la informacion de modalidad trucada (por ejemplo, informacion indicativa de representaciones que incluyen sub-secuencias temporales) y / o informacion para recuperar periodos remotos (por ejemplo, para la insercion de anuncios pre-destinados en contenido de medios durante la reproduccion). De acuerdo a las tecnicas de esta divulgacion, la MPD 104 puede incluir informacion de TemporizacionUTC, como se ha expuesto anteriormente con respecto a la figura 1.

[0111] Los datos de cabecera 112, cuando estan presentes, pueden describir las caracteristicas de los segmentos 114, por ejemplo, las ubicaciones temporales de los puntos de acceso aleatorio (RAP, tambien denominados puntos de acceso de flujo (SAP)), cual de los segmentos 114 incluye puntos de acceso aleatorios, desplazamientos en octetos a puntos de acceso aleatorio dentro de los segmentos 114, localizadores uniformes de recursos (URL) de los segmentos 114 u otros aspectos de los segmentos 114. Los datos de cabecera 122, cuando estan presentes, pueden describir caracteristicas similares para los segmentos 124. Adicional o alternativamente, tales caracteristicas pueden estar completamente incluidas dentro de la MPD 104.

[0112] Los segmentos 114, 124 incluyen una o mas muestras de video codificadas, cada una de las cuales puede incluir tramas o fragmentos de datos de video. Cada una de las muestras de video codificadas de los segmentos 114 puede tener caracteristicas similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Tales caracteristicas pueden ser descritas por datos de la MPD 104, aunque tales datos no se ilustran en el ejemplo de la figura 2. La MPD 104 puede incluir caracteristicas segun lo descrito por la Especificacion del 3GPP, con la adicion de cualquier, o toda la, informacion senalizada descrita en esta divulgacion.

[0113] Cada uno de los segmentos 114, 124 puede asociarse a un unico localizador uniforme de recursos (URL). Por lo tanto, cada uno de los segmentos 114, 124 puede ser recuperable independientemente usando un protocolo de red de transmision por flujo, tal como DASH. De esta manera, un dispositivo de destino, tal como el dispositivo cliente 40, puede usar una solicitud OBTENER del HTTP para recuperar los segmentos 114 o 124. En algunos ejemplos, el dispositivo cliente 40 puede usar solicitudes OBTENER parciales del HTTP para recuperar gamas de octetos especificos de los segmentos 114 o 124.

[0114] La figura 3 es un diagrama conceptual que ilustra un sistema 138 que incluye diversos dispositivos que pueden implementar las tecnicas de esta divulgacion. En este ejemplo, el sistema 138 incluye el dispositivo de origen 130, el dispositivo servidor de sincronizacion horaria (sincronia) 132 y una pluralidad de dispositivos clientes que incluyen el dispositivo cliente 134A y el dispositivo cliente 134B (dispositivos clientes 134). Estos dispositivos estan interconectados a traves de la red 136, que puede corresponder a Internet. En general, el dispositivo de origen 130 puede corresponder a uno cualquiera entre, o a una combinacion de, el dispositivo de preparacion de contenido 20 y el dispositivo servidor 60 de la figura 1, los dispositivos clientes 134 pueden incluir componentes esencialmente similares a los del dispositivo cliente 40 de la figura 1 y la red 136 puede corresponder a la red 74 de la figura 1. La funcionalidad atribuida al dispositivo servidor de sincronizacion horaria 132 puede ser realizada por el dispositivo de origen 130, pero se ilustra por separado con fines de exposicion.

[0115] De acuerdo a las tecnicas de esta divulgacion, el dispositivo de origen 130 puede construir un fichero de manifiesto, tal como una descripcion de presentacion de medios (MPD), que indica las horas de reloj de pared en las que los dispositivos clientes 134 pueden recuperar datos de contenido de medios, por ejemplo, segmentos. La MPD puede indicar ademas un procedimiento de sincronizacion mediante el cual los dispositivos clientes 134 han de sincronizar los relojes locales respectivos con las horas de reloj de pared. Por ejemplo, el dispositivo de origen 130 puede proporcionar una direccion del protocolo de Internet (IP) o un nombre de dominio para el dispositivo servidor de sincronizacion horaria 132 en la MPD, junto con una indicacion del procedimiento de sincronizacion. De esta manera, los dispositivos clientes 134 pueden usar el procedimiento de sincronizacion para solicitar una hora actual desde el dispositivo servidor de sincronizacion horaria 132, para sincronizar los relojes locales con las horas de reloj de pared. Los procedimientos de sincronizacion horaria pueden incluir, por ejemplo, el protocolo de hora de red (NTP), el protocolo de hora de precision (PTP), el protocolo horario del protocolo de transferencia de hipertexto (HTTP) (HTP) o el propio HTTP.

[0116] Como se ha explicado anteriormente, el dispositivo de origen 130 puede proporcionar una MPD a los dispositivos clientes 134A, 134B que incluye informacion de una manera recomendada para sincronizar los relojes locales de los dispositivos clientes 134A, 134B con la hora de reloj de pared para la correspondiente presentacion de medios. La Tabla 3 de ISO / IEC 23009-1, incluidas las modificaciones ejemplares analizadas anteriormente, representa un elemento ejemplar, TemporizacionUTC, que se puede usar para senalizar dicha informacion. Por lo tanto, los dispositivos clientes 134A, 134B pueden usar esta informacion senalizada para interactuar con el dispositivo servidor de sincronizacion horaria 132, con el fin de sincronizar sus respectivos relojes locales con horas de reloj de pared. Ademas, el dispositivo de origen 130 puede sincronizar su reloj local con el dispositivo servidor de sincronizacion horaria 132, en algunos ejemplos.

[0117] Cuando se usa el HTTP para sincronizar un reloj local, los dispositivos clientes 134 pueden enviar una solicitud CABECERA del HTTP al dispositivo servidor de sincronizacion horaria 132. La solicitud CABECERA del HTTP puede ser conforme a la RFC 2616, que define HTTP / 1.1. En respuesta a la solicitud CABECERA de HTTP, el dispositivo servidor de sincronizacion horaria 132 puede enviar una respuesta que incluya informacion de fecha, por ejemplo, una fecha y una hora. Alternativamente, los dispositivos clientes pueden enviar una solicitud OBTENER del HTTP al dispositivo servidor de sincronizacion horaria 132 de conformidad con la RFC 2616. En respuesta, el dispositivo servidor de sincronizacion horaria 132 puede enviar un valor de sello cronologico bien formateado, por ejemplo, un valor de sello cronologico formateado segun el NTP o el Lenguaje de Marcado Extensible (XML) o segun un sello cronologico del NTP o un codigo horario de la ISO.

[0118] Ademas, o como alternativa, el dispositivo de origen 130 puede senalizar una indicacion en una MPD en cuanto a que diferentes dispositivos clientes han de recuperar un segmento particular de datos de medios en diferentes momentos. Esto puede evitar escenarios en los que una gran cantidad de dispositivos clientes recuperan el mismo segmento esencialmente al mismo tiempo. Por ejemplo, la indicacion puede hacer que el dispositivo cliente 134A recupere un segmento en particular en un momento diferente al del dispositivo cliente 134B. Por lo tanto, el dispositivo cliente 134A puede recuperar el segmento una primera vez, como se indica en la MPD, y el dispositivo cliente 134B puede recuperar el segmento en un segundo momento diferente al de la primera vez, nuevamente como se indica en la MPD. En particular, los dispositivos clientes 134A, 134B pueden emitir solicitudes del segmento en diferentes momentos.

[0119] Aunque solo un dispositivo servidor de sincronizacion horaria 132 se muestra en el ejemplo de la figura 3, deberia entenderse que pueden proporcionarse multiples dispositivos servidores de sincronizacion horaria, y que el dispositivo de origen 130 puede indicar direcciones de cada uno de los dispositivos servidores de sincronizacion horaria en una MPD.

[0120] El dispositivo servidor de sincronizacion horaria 132 puede configurarse como un servidor del NTP. De acuerdo al NTP, el dispositivo servidor de sincronizacion horaria 132 puede representar un reloj de referencia o un reloj de estrato inferior que esta acoplado comunicativamente a un reloj de referencia. Los dispositivos clientes 134A, 134B pueden configurarse para enviar solicitudes al dispositivo servidor de sincronizacion horaria 132 y a un dispositivo servidor de sincronizacion horaria adicional; un cliente del NTP puede, por ejemplo, enviar solicitudes a tres servidores diferentes del NTP. De acuerdo al NTP, los dispositivos clientes 134A, 134B pueden determinar un sello cronologico en el que se envia una solicitud al dispositivo servidor de sincronizacion horaria 132, un sello cronologico de recepcion de la solicitud, un sello cronologico en el que se envia un paquete de respuesta desde el dispositivo servidor de sincronizacion horaria 132 en respuesta a la solicitud, y un sello cronologico en el que se recibe el paquete de respuesta. Los dispositivos clientes 134A, 134B pueden usar estos sellos cronologicos para determinar la hora real y ajustar sus relojes internos en consecuencia. En algunos ejemplos, los dispositivos clientes 134A, 134B pueden repetir periodicamente el procedimiento del NTP para reajustar sus relojes internos, para prevenir o contrarrestar la deriva horaria.

[0121] Adicional o alternativamente, el dispositivo servidor de sincronizacion horaria 132 puede configurarse como un servidor del HTTP. De acuerdo al HTP, el dispositivo servidor de sincronizacion horaria 132 puede proporcionar informacion de fecha y hora en las cabeceras de paquetes del HTTP. En particular, los dispositivos clientes 134A, 134B pueden recibir paquetes desde el dispositivo servidor de sincronizacion horaria 132 y / o uno o mas servidores adicionales del HTTP. Los dispositivos clientes 134A, 134B pueden calcular el promedio de las horas recibidas desde uno o mas dispositivos servidores de sincronizacion horaria, incluido el dispositivo servidor de sincronizacion horaria 132, para obtener una hora actual (excluyendo potencialmente ciertas horas recibidas desde los dispositivos servidores de sincronizacion horaria, por ejemplo, horas fuera de una desviacion estandar del promedio de todas las horas recibidas). Los dispositivos clientes 134A, 134B tambien pueden agregar el tiempo requerido para realizar los calculos de los promedios y las desviaciones estandar. Los dispositivos clientes 134A, 134B pueden entonces ajustar sus relojes internos de acuerdo a la hora calculada.

[0122] En algunos ejemplos, el dispositivo servidor de sincronizacion horaria 132 y el dispositivo de origen 130 pueden integrarse funcionalmente en el mismo dispositivo. Por ejemplo, en respuesta a una solicitud de una MPD, el dispositivo de origen 130 puede enviar la MPD, asi como un sello cronologico bien formateado, tal como un sello cronologico del NTP o del XML. Alternativamente, el dispositivo servidor de sincronizacion horaria 132 puede proporcionarse por separado del dispositivo de origen 130, como se muestra en el ejemplo de la figura 3, pero el dispositivo de origen 130 tambien puede actuar como un dispositivo servidor de sincronizacion horaria, por ejemplo, al proporcionar el valor de sello cronologico bien formateado y / o al actuar como servidor para un protocolo de sincronizacion horaria, tal como el NTP, el HTP, el HTTP u otros protocolos similares. Del mismo modo, el dispositivo servidor de sincronizacion horaria 132, independientemente del dispositivo de origen 130, puede configurarse para proporcionar un sello cronologico bien formateado, tal como un sello cronologico del NTP o del XML, en respuesta a una solicitud OBTENER del HTTP. Por ejemplo, los dispositivos clientes 134A, 134B pueden emitir una solicitud OBTENER del HTTP, dirigida a un URL en particular y, en respuesta, el dispositivo servidor de sincronizacion horaria 132 puede enviar un sello cronologico bien formateado, por ejemplo, formateado de acuerdo al NTP o al XML.

[0123] De esta manera, los dispositivos clientes 134A, 134B representan ejemplos de un dispositivo cliente para recibir informacion para la transmision continua de datos de medios, incluido un reloj y uno o mas procesadores configurados para recibir una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de las horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con el reloj, sincronizar el reloj con las horas de reloj de pared usando el procedimiento indicado por la MPD, y solicitar datos del contenido de medios desde el dispositivo de origen, usando el reloj sincronizado. La MPD puede incluir datos que indiquen que el dispositivo cliente 134A, por ejemplo, ha de recuperar un segmento del contenido de medios una primera vez y que el dispositivo cliente 134B, en este ejemplo, ha de recuperar el segmento en una segunda vez diferente a la primera vez.

[0124] Del mismo modo, el dispositivo de origen 130 representa un ejemplo de un dispositivo de origen para la senalizacion de informacion para la transmision continua de datos de medios, incluyendo uno o mas procesadores configurados para generar datos para una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que un dispositivo cliente (por ejemplo, uno de los dispositivos clientes 134A, 134B) puede recuperar datos del contenido de medios desde el dispositivo de origen, y en donde los datos generados indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente y enviar la MPD al dispositivo cliente.

[0125] La figura 4 es un diagrama de flujo que ilustra un procedimiento ejemplar para sincronizar un reloj local de un dispositivo cliente con una hora de reloj de pared y recuperar un segmento utilizando el reloj sincronizado. El procedimiento de la figura 4 se describe con respecto al dispositivo de origen 130, el dispositivo cliente 134A y el dispositivo servidor de sincronizacion horaria 132 de la figura 3. Sin embargo, deberia entenderse que otros dispositivos (por ejemplo, el dispositivo cliente 40, el dispositivo servidor 60 y / o el dispositivo de preparacion de contenido 20 de la Figura 1, y / o el dispositivo cliente 134B de la Figura 3) pueden configurarse para realizar este o un procedimiento esencialmente similar. Ademas, ciertas etapas del procedimiento de la figura 4 puede realizarse en ordenes alternativas o en paralelo, y pueden ser realizadas por otros dispositivos (por ejemplo, las etapas atribuidos al dispositivo servidor de sincronizacion horaria 132 pueden ser realizadas por el dispositivo de origen 130).

[0126] Inicialmente, el dispositivo de origen 130 puede generar una descripcion de presentacion de medios (MPD) para el contenido de medios (por ejemplo, una presentacion de medios), donde la MPD incluye informacion que indica informacion de sincronizacion horaria (150). Por ejemplo, el dispositivo de origen 130 puede incluir informacion en la MPD, indicativa de un procedimiento de sincronizacion (por ejemplo, del NTP, HTP o HTTP) y direcciones para uno o mas servidores de sincronizacion horaria, tales como el dispositivo servidor de sincronizacion horaria 132. La informacion de sincronizacion horaria puede corresponder al elemento TemporizacionUTC descrito anteriormente con respecto a la version modificada de la Tabla 3 de la norma ISO / IEC 23009-1. Ademas, la MPD puede anunciar horas de reloj de pared en las cuales los segmentos del contenido multimedia estaran disponibles para su recuperacion. En algunos ejemplos, estas horas de reloj de pared pueden ser diferentes para diferentes dispositivos clientes. Por ejemplo, un segmento puede estar disponible una primera vez para el dispositivo cliente 134A, pero una segunda vez diferente para el dispositivo cliente 134B. Es decir, la MPD puede indicar una primera vez cuando el dispositivo cliente 134A puede recuperar el segmento, y una segunda vez diferente cuando el dispositivo cliente 134B puede recuperar el segmento.

[0127] El dispositivo cliente 134A puede solicitar luego la MPD para el contenido de medios (152). En general, el dispositivo cliente 134A puede solicitar un fichero de manifiesto para el contenido de medios. Una MPD es un ejemplo de un fichero de manifiesto, aunque otros tipos de ficheros de manifiesto se pueden usar en otros ejemplos. El dispositivo de origen 130 puede recibir la solicitud de la MPD (154) y luego enviar la MPD al dispositivo cliente 134A (156) en respuesta a la solicitud.

[0128] El dispositivo cliente 134A puede usar la MPD para determinar un procedimiento de sincronizacion horaria (158). Por ejemplo, el dispositivo cliente 134A puede determinar si se sincroniza un reloj local usando el NTP, el HTP, el HTTP u otro procedimiento de sincronizacion horaria usando la MPD. El dispositivo cliente 134A tambien puede determinar una direccion de un dispositivo servidor de sincronizacion horaria, tal como el dispositivo servidor de sincronizacion horaria 132, a partir de la MPD. El dispositivo cliente 134A puede entonces solicitar una hora al dispositivo servidor de sincronizacion horaria 132 (160). El dispositivo servidor de sincronizacion horaria 132 puede recibir la solicitud (162) y, en respuesta a la solicitud, enviar una indicacion de la hora actual al dispositivo cliente 134A (164). El dispositivo cliente 134A puede sincronizar luego su reloj local con la hora recibida (166). Por ejemplo, el dispositivo cliente 134A puede reiniciar la hora de su reloj local directamente, o puede accionar el reloj local a una velocidad mayor o menor para alcanzar la hora indicada. En algunos ejemplos, el dispositivo cliente 134A puede solicitar horas de una pluralidad de diferentes servidores de sincronizacion horaria, y combinar las horas recibidas desde estos servidores (por ejemplo, mediante el promedio) para determinar una hora actual real, y sincronizarse con esta hora determinada, en lugar de la hora indicada por un servidor particular. Ademas, el dispositivo cliente 134A puede calcular los tiempos de procesamiento y agregar estos tiempos de procesamiento a la hora indicada al reiniciar el reloj local.

[0129] Despues de reiniciar el reloj local, el dispositivo cliente 134A puede determinar una hora de reloj de pared en la cual un segmento del contenido de medios estara disponible, a partir de la MPD. El dispositivo cliente 134A puede entonces solicitar un segmento en la hora indicada en la MPD, es decir, la hora en que la MPD indica que el segmento esta disponible para su recuperacion (168). El dispositivo cliente 134A puede formar una solicitud OBTENER u OBTENER parcial del HTTP para el segmento, o una parte del mismo. El dispositivo de origen 130 puede recibir la solicitud del segmento (170) y enviar el segmento solicitado (o parte del mismo) al dispositivo cliente 134A (172) en respuesta a la solicitud. Despues de recibir el segmento, el dispositivo cliente 134A puede decodificar y representar datos de medios del segmento (174). Antes de decodificar y representar, el dispositivo cliente 134A puede almacenar temporalmente el segmento recibido, hasta que los datos del segmento esten listos para su decodificacion y presentacion.

[0130] De esta manera, la figura 4 representa un ejemplo de un procedimiento para recibir informacion para la transmision continua de datos de medios, incluyendo el procedimiento recibir, por un dispositivo cliente, una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, sincronizando el reloj del dispositivo cliente con las horas de reloj de pared usando el procedimiento indicado por la MPD, y solicitando datos del contenido de medios desde el dispositivo de origen usando el reloj sincronizado.

[0131] Ademas, la figura 4 representa un ejemplo de un procedimiento de senalizacion de informacion para la transmision continua de datos de medios, comprendiendo el procedimiento generar datos para una descripcion de presentacion de medios (MPD) para contenido de medios, en donde la MPD incluye datos indicativos de las horas de reloj de pared en las que un dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo fuente, y en donde los datos generados indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, y enviar la MPD al dispositivo cliente.

[0132] En uno o mas ejemplos, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinacion de los mismos. Si se implementan en software, las funciones pueden almacenarse en, y transmitirse por, un medio legible por ordenador, como una o mas instrucciones o codigo, y ejecutarse 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 tal como medios de almacenamiento de datos o medios de comunicacion que incluyan cualquier medio que facilite la transferencia de un programa informatico desde un lugar a otro, por ejemplo, de acuerdo a un protocolo de comunicacion. 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 (2) un medio de comunicacion tal como una senal o una onda portadora. Los medios de almacenamiento de datos pueden ser medios disponibles cualesquiera a los que se pueda acceder desde uno o mas ordenadores o uno o mas procesadores para recuperar instrucciones, codigo y/o estructuras de datos para la implementacion de las tecnicas descritas en esta divulgacion. Un producto de programa informatico puede incluir un medio legible por ordenador.

[0133] A modo de ejemplo, y no de manera limitativa, tales medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco optico, almacenamiento de disco magnetico u otros dispositivos de almacenamiento magnetico, memoria flash o cualquier otro medio que pueda usarse para almacenar codigo de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador. Asimismo, cualquier conexion recibe debidamente la denominacion de medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde una sede de la Red, un servidor u otro origen remoto usando un cable coaxial, un cable de fibra optica, un par trenzado, una linea de abonado digital (DSL) o tecnologias inalambricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra optica, el par trenzado, la DSL o las tecnologias inalambricas tales como infrarrojos, radio y microondas se incluyen en la definicion de medio. Sin embargo, deberia entenderse que los medios de almacenamiento legibles por ordenador y los medios de almacenamiento de datos no incluyen conexiones, ondas portadoras, senales u otros medios transitorios, sino que, en cambio, estan orientados a medios de almacenamiento tangibles no transitorios. Los discos, como se usan en el presente documento, incluyen un disco compacto (CD), un disco laser, un disco optico, un disco versatil digital (DVD), un disco flexible y un disco Blu-ray, donde algunos discos reproducen usualmente los datos magneticamente, mientras que otros discos reproducen los datos opticamente con laseres. Las combinaciones de lo anterior tambien deberian incluirse dentro del alcance de los medios legibles por ordenador.

[0134] Las instrucciones pueden ser ejecutadas por uno o mas procesadores, tales como uno o mas procesadores de senales digitales (DSP), microprocesadores de proposito general, circuitos integrados especificos de la aplicacion (ASIC), formaciones de compuertas programables in situ (FPGA) u otros circuitos logicos, integrados o discretos, equivalentes. En consecuencia, el termino "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 implementacion de las tecnicas descritas en el presente documento. Ademas, en algunos aspectos, la funcionalidad descrita en el presente documento se puede proporcionar dentro de modulos de hardware y/o software dedicados, configurados para la codificacion y la decodificacion, o incorporados en un codec combinado. Ademas, las tecnicas se podrian implementar totalmente en uno o mas circuitos o elementos logicos.

[0135] Las tecnicas de la presente divulgacion se pueden implementar en una amplia variedad de dispositivos o aparatos, incluidos un equipo manual inalambrico, un circuito integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chips). Diversos componentes, modulos o unidades se describen en esta divulgacion para enfatizar aspectos funcionales de dispositivos configurados para realizar las tecnicas divulgadas, pero no requieren necesariamente su realizacion mediante diferentes unidades de hardware. En cambio, como se ha descrito anteriormente, diversas unidades se pueden combinar en una unidad de hardware de codec, o ser proporcionadas por un grupo de unidades de hardware interoperativas, incluyendo uno o mas procesadores, como se ha descrito anteriormente, conjuntamente con software y/o firmware adecuados.

[0136] Se han descrito diversos ejemplos. Estos y otros ejemplos estan dentro del alcance de las siguientes reivindicaciones.

Claims (1)

1. REIVINDICACIONES

   Un procedimiento para recibir informacion para la transmision continua de datos de medios, utilizando la transmision continua dinamica adaptativa, del Grupo de Expertos en Imagenes en Movimiento, sobre el HTTP, DASH de MPEG, el procedimiento que comprende:

   recibir (154), por un dispositivo cliente (40, 134), una descripcion de presentacion de medios (104), MPD, para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen (130), y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj del dispositivo cliente, y en donde el procedimiento de sincronizacion indicado por la MPD comprende el HTTP, en donde la MPD incluye datos indicativos de direcciones de red para uno o mas servidores del HTTP, y en donde la sincronizacion del reloj comprende solicitar una hora de al menos uno de los servidores del HTTP;

   sincronizar (166) el reloj del dispositivo cliente con las horas del reloj de pared usando el procedimiento indicado por la MPD, y en donde sincronizar el reloj comprende enviar una solicitud OBTENER del HTTP a al menos uno de los servidores del HTTP y recibir, en respuesta a la solicitud OBTENER del HTTP, un valor de sello cronologico bien formateado que se formatea de acuerdo a uno entre el protocolo de hora de red, NTP, y el Lenguaje de Marcado Extensible, XML, y un codigo de hora de la organizacion internacional para la estandarizacion, ISO; y

   solicitar (168) datos del contenido de medios desde el dispositivo de origen usando el reloj sincronizado; y

   en donde la MPD incluye datos que indican que el dispositivo cliente ha de recuperar un segmento del contenido de medios una primera vez y que un dispositivo cliente independiente ha de recuperar el segmento una segunda vez, diferente a la primera vez, y en donde la solicitud de datos comprende solicitar el segmento en o despues de la primera vez.

   Un dispositivo cliente (40, 134) para recibir informacion para la transmision continua de datos de medios utilizando la transmision continua adaptativa dinamica, del Grupo de Expertos en Imagenes en Movimiento, sobre el HTTP, DASH de MPEG, el dispositivo cliente que comprende:

   un reloj (56); y

   uno o mas procesadores configurados para recibir una descripcion de presentacion de medios (104), MPD, para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que el dispositivo cliente puede recuperar datos del contenido de medios desde un dispositivo de origen, y en donde los datos indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con el reloj, sincronizar el reloj con las horas del reloj de pared utilizando el procedimiento indicado por la MPD, y solicitar datos del contenido de medios al dispositivo de origen que utiliza el reloj sincronizado, y en el que el procedimiento de sincronizacion indicado por la MPD comprende el HTTP, en el que la MPD incluye datos indicativos de direcciones de red para uno o mas servidores del HTTP, y en donde la sincronizacion del reloj comprende solicitar una hora de al menos uno de los servidores del HTTP, y en donde la sincronizacion del reloj comprende enviar una solicitud OBTENER del HTTP a al menos uno de los servidores del HTTP y recibir, en respuesta a la solicitud OBTENER del HTTP, un valor de sello cronologico bien formateado que se formatea de acuerdo a uno entre el protocolo de hora de red, NTP, y el Lenguaje de Marcado Extensible, XML, y un codigo de hora de la organizacion internacional para la estandarizacion, ISO; y

   en donde la MPD incluye datos que indican que el dispositivo cliente ha de recuperar un segmento del contenido de medios una primera vez y que un dispositivo cliente independiente ha de recuperar el segmento una segunda vez, diferente a la primera vez, y en donde la solicitud de datos comprende solicitar el segmento en o despues de la primera vez.

   Un medio de almacenamiento legible por ordenador que tiene instrucciones almacenadas en el mismo que, cuando son ejecutadas, hacen que un procesador de un dispositivo cliente lleve a cabo las etapas de procedimiento de la reivindicacion 1.

   Un procedimiento de senalizacion de informacion para la transmision continua de datos de medios utilizando la transmision continua dinamica adaptativa, del Grupo de Expertos en Imagenes en Movimiento, sobre el HTTP, MPEG DASH, el procedimiento que comprende:

   generar (150) datos para una descripcion de presentacion de medios (104), MPD, para contenido de medios, en donde la MPD incluye datos indicativos de horas de reloj de pared en las que un dispositivo cliente (40, 134) puede recuperar datos del contenido de medios desde un dispositivo de origen (130), y en donde los datos generados indican un procedimiento de sincronizacion mediante el cual el dispositivo cliente ha de sincronizar las horas de reloj de pared con un reloj (56) del dispositivo cliente; y emitir (156) la MPD; y

   en donde el procedimiento de sincronizacion indicado por la MPD comprende el HTTP, en donde la MPD incluye datos indicativos de direcciones de red para uno o mas servidores del HTTP, y en donde la sincronizacion del reloj comprende solicitar en el dispositivo cliente una hora desde al menos uno de los servidores del HTTP, y en donde sincronizar el reloj comprende enviar en el dispositivo cliente una solicitud OBTENER del HTTP a al menos uno de los servidores del HTTP y recibir en el dispositivo cliente, en respuesta a la solicitud OBTENER del HTTP, un valor de sello cronologico bien formateado que esta formateado de acuerdo a uno entre el protocolo de hora de red, NTP, y el Lenguaje de Marcado Extensible, XML, y un codigo de hora de la organizacion internacional para la estandarizacion, ISO; y

   en donde el dispositivo cliente comprende un primer dispositivo cliente, y en donde generar los datos para la MPD comprende generar los datos para la MPD de modo que los datos indiquen que el primer dispositivo cliente ha de recuperar un segmento del contenido de medios una primera vez y que un segundo dispositivo cliente ha de recuperar el segmento en una segunda vez diferente a la primera vez, y en donde enviar la MPD comprende enviar la MPD al primer dispositivo cliente y al segundo dispositivo cliente.

   El procedimiento segun la reivindicacion 4, que comprende ademas:

   recibir una solicitud de un segmento del contenido de medios despues de una hora de reloj de pared para el segmento, como lo indica la MPD; y

   enviar el segmento al dispositivo cliente en respuesta a la solicitud.

   El procedimiento segun la reivindicacion 5, que comprende ademas:

   recibir una primera solicitud del segmento desde el primer dispositivo cliente en, o despues de, la primera vez;

   enviar datos para el segmento al primer dispositivo cliente en respuesta a la primera solicitud; recibir una segunda solicitud del segmento desde el segundo dispositivo cliente en o despues de la segunda vez; y

   enviar los datos para el segmento al segundo dispositivo cliente en respuesta a la segunda solicitud; y en donde generar los datos comprende generar valores especificos por la primera vez y por la segunda vez; o

   que comprende ademas determinar una primera prioridad para el primer dispositivo cliente y una segunda prioridad para el segundo dispositivo cliente, en donde generar los datos comprende generar los datos basandose en la primera prioridad y la segunda prioridad.