ES2784605T3 - Entrega de middleware de métricas de QOE del cliente dash - Google Patents

Abstract

Un procedimiento para generar informes de medición de calidad de experiencia, QoE, DASH, con el procedimiento que comprende, mediante una unidad de middleware de un dispositivo cliente MBMS: recibir (380) datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor; generar (382) informes de recepción de MBMS que cubren la recepción de los datos de los medios de acuerdo con las directivas de informes recibidas; entregar (384) al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente DASH; recibir (386) informes DASH QoE que incluyen métricas de QoE de la aplicación objetivo; y proporcionar contenidos (388) del informe de recepción MBMS y los informes DASH QoE a un servidor de informes de recepción.

Description

DESCRIPCIÓN

Entrega de middleware de métricas de QOE del cliente dash

[0001] Esta solicitud reivindica el beneficio de la solicitud provisional de Estados Unidos n.° 62/182 267, presentada el 19 de junio de 2015.

CAMPO TÉCNICO

[0002] Esta divulgación se refiere al transporte de datos multimedia.

ANTECEDENTES

[0003] Las capacidades de vídeo digital se pueden incorporar a una amplia gama de dispositivos, incluyendo televisores digitales, sistemas de radiodifusión directa digital, sistemas de radiodifusión inalámbrica, asistentes digitales personales (PDA), ordenadores portátiles o de escritorio, cámaras digitales, dispositivos de grabación digitales, reproductores de medios digitales, dispositivos de videojuegos, consolas de videojuegos, teléfonos celulares o de radio por satélite, dispositivos de videoconferencia y similares. Además, los dispositivos servidor (como los servidores de red, los dispositivos de redes de entrega de contenido (CDN) y similares) pueden transmitir datos multimedia a los dispositivos cliente (como ordenadores personales, descodificadores, dispositivos móviles como ordenadores portátiles, teléfonos celulares, etc. y similares), por ejemplo, mediante transmisión o protocolos de red bajo pedido. Los dispositivos de vídeo digital implementan técnicas de compresión de vídeo, tales como las descritas en los estándares definidos por MPEG-2, Mp Eg -4, ITU-T H.263, ITU-T H.264/MPEG-4, parte 10, Codificación de vídeo avanzada (AVC), ITU-T H.265 (también conocida como codificación de vídeo de alta eficiencia (HEVC)), y ampliaciones de dichos estándares, para transmitir y recibir información de vídeo digital más eficientemente.

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

[0005] Los datos, tales como los datos multimedia que incluyen datos de vídeo, audio y texto temporizado, se pueden entregar en una variedad de procedimientos de transporte. Uno de estos procedimientos son los servicios de radiodifusión/multidifusión de multimedia (MBMS) en las redes del Proyecto de Asociación de Tercera Generación (3GPP). MBMS, por ejemplo, permite la prestación de servicios de interés para un gran número de suscriptores que utilizan un único canal de entrega.

[0006] Los informes de calidad de experiencia (QoE) de los clientes de vídeo son cruciales para supervisar el rendimiento de entrega en un sistema y para medir la calidad de la visualización de los usuarios finales. MBMS, por ejemplo, proporciona procedimientos para medir la calidad del transporte y la QoE del usuario a través de su marco de informes de recepción. Los procedimientos de entrega de vídeo también pueden incluir sus propios informes de medición de calidad que crean 2 puntos de informes diferentes en un dispositivo final. Vale la pena agregar los dos tipos de informes (MBMS y tipos de clientes de vídeo) para garantizar que los informes consolidados, que cubren múltiples aspectos del rendimiento de entrega de contenido, estén fácilmente disponibles para los proveedores de servicios. El documento WO 2015/027370 A1 enseña a un equipo de usuario que proporciona información sobre una calidad de recepción en una aplicación en el terminal de usuario durante una transmisión de transmisión continua eMBMS o una descarga de archivos a través de HTTP DASH. El documento US 2014/201323 A1 divulga un sistema de transmisión continua de medios que puede hacer que un cliente del servicio de aplicaciones recupere datos multimedia de una unidad de middleware de radiodifusión.

BREVE EXPLICACIÓN

[0007] En general, esta divulgación describe técnicas relacionadas con la entrega de transmisión continua adaptiva dinámica a través de métricas de calidad de experiencia del cliente (QoE) de HTTP (DASH) a un servidor de informes mediante una unidad de middleware. Es decir, un dispositivo cliente puede incluir un cliente DASH (por ejemplo, una unidad dentro del dispositivo cliente, como una unidad de hardware dedicada o un módulo de software, como una extensión de navegador web) que implementa DASH para la recuperación de datos multimedia, y un unidad de middleware que recibe datos multimedia mediante un servicio de radiodifusión o multidifusión, como Servicios de radiodifusión/multidifusión de multimedia (MBMS) o MBMS (eMBMS) mejorados. La unidad de middleware también actúa como un servidor proxy con respecto al cliente DASH, ya que la unidad de middleware almacena en caché los datos multimedia recibidos y proporciona los datos de media al cliente DASH en respuesta a las peticiones del dispositivo cliente. Además, la unidad de middleware puede recibir informes de métricas DASH QoE del dispositivo cliente y entregar estos informes de métricas DASH QoE a un servidor de informes en nombre del cliente DASH.

[0008] En un ejemplo, un procedimiento de generación de informes de medición de calidad se realiza mediante una unidad de middleware de un dispositivo cliente e incluye recibir datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor, generar informes de recepción que cubren la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas, entregar al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente, recibir informes de calidad de experiencia (QoE) de la aplicación objetivo y proporcionar contenidos de los informes de QoE a un servidor de informes de recepción. Nuevamente, en este ejemplo, los informes de recepción incluyen el contenido de los informes de QoE, pero en otros ejemplos, estos informes pueden entregarse por separado y/o a servidores de informes separados.

[0009] En otro ejemplo, un dispositivo para generar informes de medición de calidad incluye uno o más procesadores basados en hardware implementados usando circuitos digitales, estando los procesadores configurados para ejecutar una unidad de middleware y una aplicación objetivo para los datos multimedia. La unidad de middleware está configurada para recibir datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor, generar informes de recepción que cubran la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas, entregar al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente, recibir informes de calidad de experiencia (QoE) de la aplicación objetivo y proporcionar el contenido de los informes de QoE a un servidor de informes de recepción.

[0010] En otro ejemplo, un dispositivo para la generación de informes de medición de calidad incluye medios para recibir datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor, medios para generar informes de recepción que cubren la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas, medios para suministrar al menos parte de los datos multimedia a una aplicación objetivo del dispositivo, medios para recibir informes de calidad de experiencia (QoE) de la aplicación objetivo, y medios para proporcionar contenidos de los informes de QoE a un servidor de informes de recepción.

[0011] En otro ejemplo, un medio de almacenamiento legible por ordenador ha almacenado instrucciones en el mismo que, al ejecutarse, hacen que un procesador de un dispositivo cliente reciba datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor, genere informes de recepción que cubren la recepción de la datos multimedia de acuerdo con las directivas de informes recibidas, entregue al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente, reciba informes de calidad de experiencia (QoE) de la aplicación objetivo y proporcione el contenido de los informes de QoE a un servidor de informes de recepción.

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

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0013]

La FIG. 1 es un diagrama conceptual que ilustra un sistema que utiliza técnicas de informes convencionales.

La FIG. 2 es un diagrama conceptual que ilustra un sistema de ejemplo de acuerdo con las técnicas de esta divulgación.

La FIG. 3 es un diagrama conceptual que ilustra otro sistema de ejemplo de acuerdo con las técnicas de esta divulgación.

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

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

La FIG. 6 es un diagrama conceptual que ilustra elementos de contenido a modo de ejemplo de multimedia.

La FIG. 7 es un diagrama de bloques que ilustra elementos de un archivo de vídeo de ejemplo.

La FIG. 8 es un diagrama conceptual que ilustra datos de ejemplo que pueden incluirse en un archivo de manifiesto, como una descripción de presentación de medios (MPD) de DASH, de acuerdo con las técnicas de esta divulgación.

La FIG. 9 es un diagrama conceptual que ilustra un ejemplo de modificación de una descripción de procedimientos de entrega asociados (AMPD) de acuerdo con las técnicas de esta divulgación.

La FIG. 10 es un diagrama conceptual que ilustra un esquema alternativo para una ADPD de acuerdo con las técnicas de esta divulgación.

La FIG. 11A es un diagrama conceptual que ilustra un ejemplo de las técnicas de esta divulgación.

La FIG. 11B es un diagrama conceptual que ilustra un ejemplo de comportamiento con recepción de unidifusión/radiodifusión paralela.

La FIG. 12 es un diagrama conceptual que ilustra un ejemplo de comportamiento con múltiples clientes DASH.

La FIG. 13 es un diagrama de flujo que ilustra un procedimiento de ejemplo de acuerdo con las técnicas de esta divulgación.

La FIG. 14 es un diagrama de flujo que ilustra otro procedimiento de ejemplo de acuerdo con las técnicas de esta divulgación.

La FIG. 15 es un diagrama de bloques que ilustra ejemplos de un dispositivo servidor y un dispositivo cliente configurados de acuerdo con las técnicas de esta divulgación.

DESCRIPCIÓN DETALLADA

[0014] En general, esta divulgación describe las técnicas para informar sobre métricas de calidad de experiencia (QoE) a uno o más servidores. En particular, estas técnicas pueden aplicarse cuando un dispositivo cliente (también denominado equipo de usuario (UE)) incluye una unidad de middleware que permite que una aplicación de transmisión acceda a la radiodifusión de contenido a través de una red LTE. El middleware también actúa como el servidor http para el contenido de radiodifusión servido a la aplicación de transmisión (la aplicación de transmisión puede ser una transmisión adaptiva dinámica por cliente HTTP (DASH)) ejecutada por el dispositivo cliente. Mientras que convencionalmente, el cliente DASH informaría sobre las métricas de QoE a un servidor, las técnicas de esta divulgación permiten que la unidad de middleware dé instrucciones al cliente DASH para que informe sobre las métricas de QoE al middleware en lugar de, o además de, informar al servidor de métricas DASH QoE. El middleware incluirá a continuación el informe de medición DASH QoE dentro o adjuntado a un informe de recepción MBMS. Las técnicas de esta divulgación en general se dirigen a la unidad de middleware que recibe las métricas de QoE de la aplicación de transmisión continua y proporciona las métricas de QoE al servidor de informes de recepción principalmente, y opcionalmente al servidor DASH QoE.

[0015] La FIG. 1 es un diagrama conceptual que ilustra un sistema 100 que utiliza técnicas de informes convencionales. En este ejemplo, el sistema 100 incluye el equipo de usuario (UE) 106, que incluye un cliente de dispositivo de servicio de multidifusión (MSDC) 112, que es un ejemplo de una unidad de middleware y un cliente DASH 108. UE 106 representa un ejemplo de un dispositivo cliente, como un ordenador personal, teléfono celular, ordenador portátil, tablet, descodificador o similar. MSDC 112 también puede denominarse unidad de middleware del Servicio de multidifusión de radiodifusión de multimedia (MBMS) y unidad de middleware del Servicio de multidifusión de radiodifusión de multimedia (eMBMS) mejorado.

[0016] En este ejemplo, un servidor de aprovisionamiento y servicio de multidifusión de radiodifusión centro de aprovisionamiento (BMSC) 104 entrega anuncios de servicio 118 a MSDC 112 del UE 106. Los anuncios de servicio 118 incluyen, por ejemplo, un archivo de manifiesto (como una descripción de presentación de medios (MPD) 122), un protocolo de descripción de sesión (SDP) y/o una descripción de procedimiento de entrega asociado (ADPD). La unidad de informe de recepción 114 del MSDC 112 recopila estadísticas de recepción de acuerdo con las métricas especificadas en el fragmento SDP en un anuncio de servicio 118 y las directivas de informe de recepción en el fragmento ADPD en el anuncio de servicio 118.

[0017] El DASH MPD 122 también puede especificar las métricas para el cliente DASH 108 a recopilar. Por lo tanto, el cliente DASH 108 incluye la unidad DASH QoE 110, que recopila las métricas especificadas (también descritas como medidas) 116 y carga las métricas de QoE 116 en el servidor 102 de recopilación de métricas de calidad DASH. Por lo tanto, en este ejemplo, hay dos puntos de recopilación diferentes, el primero (servidor 102 de recopilación de métricas de calidad DASH) para las métricas de QoE y el segundo (servidor de aprovisionamiento y BMSC 104) para las métricas 120 de informes de recepción de MBMS.

[0018] La FIG. 2 es un diagrama conceptual que ilustra un sistema de ejemplo 100' de acuerdo con una o más técnicas de esta divulgación. De acuerdo con las técnicas de esta divulgación, el cliente DASH 108' del UE 106', en el ejemplo de la FIG. 2, carga métricas DASH QoE 116' a MSDC 112' de UE 106'. En particular, el servidor de aprovisionamiento y BMSC 104 envía el anuncio de servicio 118', que incluye MPD y segmentos 122' en este ejemplo. MSDC 112' envía MPD y segmentos 122' al cliente DASH 108. La MPD incluye directivas de informes DASH. De acuerdo con las técnicas de esta divulgación, DASH QoE 110' envía métricas Da Sh QoE 116' a MSDC 112', de acuerdo con la MPD. Por lo tanto, MSDC 112' puede recopilar el informe de mediciones DASH QoE 116', y la unidad de informe de recepción 114' puede incluir el informe de mediciones DASH QoE en un informe de recepción correspondiente 120' (que puede recopilarse y comunicarse de acuerdo con el estándar 3GPP MBMS).

[0019] Por ejemplo, MSDC 112' puede modificar una sección MPD en métricas para ser cargado, para permitir desplazamiento de mediciones DASH QoE a un servidor HTTP recibido por MSDC 112'. El middleware ya puede modificar la MPD (por ejemplo, MSDC 112') para apuntar las URL de segmento en la MPD a un servidor HTTP local alojado por MSDC 112'. MSDC 112' también puede configurarse para aceptar comandos HTTP POST relacionados con la recopilación de DASH QoE de, por ejemplo, el cliente DASH 108'. Además, MSDC 112' puede incorporar archivos de registro DASH QoE en los informes de recepción correspondientes 120'. En este ejemplo, el UE 106' no necesita informar sobre los informes DASH QoE al servidor de recopilación de métricas de calidad DASH 102'. En cambio, el UE 106' puede simplemente enviar los informes de métricas DASH QoE 116' junto con los informes de recepción de MBMS al servidor de aprovisionamiento y BMSC 104'. Posteriormente, BMSC 104' puede enviar los informes DASH QoE al servidor de recopilación de métricas de calidad DASH 102'.

[0020] La FIG. 3 es un diagrama conceptual que ilustra otro sistema de ejemplo 100", de acuerdo con las técnicas de esta divulgación. En general, este ejemplo es similar al ejemplo de la FIG. 2, excepto que en el ejemplo de la FIG. 3, el UE 106" informa sobre las medidas de QoE 116" al servidor de recopilación de métricas de calidad DASH 102" además de proporcionar al servidor y BMSC 104" informes de recepción MBMS 120". Es decir, en este ejemplo, el servidor de aprovisionamiento y BMSC 104 envía el anuncio de servicio 118" al UE 106, y MSDC 112" del UE 106 extrae y reenvía MPD y los segmentos 122" al cliente DASH 108. La unidad DASH QoE 110" informa sobre las métricas DASH QoE 116" al m Sd C 112". Además, uno o ambos de DASH QoE 110" y/o MSDC 112" envían un duplicado, un proxy o un informe adicional de DASH QoE al servidor de recopilación de métricas de calidad DASH 102, como se explica con mayor detalle a continuación.

[0021] Las métricas de QoE pueden variar basándose en el servidor al que se informa sobre las métricas. Además, las métricas sobre las que se informa pueden depender de qué, en este ejemplo, se utilice el estándar DASH (por ejemplo, 3GP-DASH vs. MPEG-DASH). En 3GP-DASH, por ejemplo, el cliente DASH 108 puede informar sobre el rendimiento medio, el retardo inicial de reproducción y la información MPD, además de una lista de transacciones de petición/respuesta HTTP, una lista de eventos de cambio de representación, un nivel de memoria intermedia y/o una lista de reproducción. En MPEG-DASH, por otro lado, entre las métricas sobre las que se informa puede incluirse una lista de conexiones TCP, además de una lista de transacciones de petición/respuesta HTTP, una lista de eventos de cambio de representación, un nivel de memoria intermedia y/o una lista de reproducción.

[0022] La Sección 10.6 de 3GP-DASH 26.247 versión d00 especifica que el protocolo de informe de calidad incluye: el formato de informe basado en XML definido en la Sección 10.6.2 de 3GP-DASH y el protocolo de informe definido en la Sección 10.6.3 de 3GP-DASH. Además, 3GP-DASH especifica el tipo MIME de un informe QoE con formato XML como "application/3gpdash-qoe-report+xml", como se define en el anexo J del mismo.

[0023] Se supone en este ejemplo que un proveedor de contenidos y/u operador desean que se cargue un informe al servidor de recopilación de métricas de calidad DASH 102". Por lo tanto, en este ejemplo, el cliente DASH 108" (en particular, DASH QoE 110") puede publicar un informe directamente en MSDC 112" (publicar en una ubicación de localhost) y MSDC 112" puede duplicar el informe al servidor de recopilación de métricas de calidad DASH 102" (flecha B en la FIG. 3, con alternativa duplicada, denominado "informe DASH QoE proxy/duplicado 116"B). De forma alternativa, en lugar de que DASH QoE 110" informe sobre las métricas DASH QoE al MSDC 112" directamente, MSDC 112" puede interceptar el informe de medición en su camino al servidor de recopilación de métricas de calidad DASH 102" (flecha B en la FIG. 3, con alternativa proxy) denominado "informe DASH QoE proxy/duplicado 116"B".

[0024] De forma adicional o alternativa, el cliente DASH 108" puede emitir múltiples informes: uno para MSDC 112" y otro para el servidor de recopilación de métricas de calidad DASH 102" (flecha A en la FIG. 3, que se denomina "informe DASH QoE 116"A duplicado/distinto). Los informes pueden ser para diferentes métricas o para las mismas métricas basándose en las mismas o diferentes directivas de recopilación y carga.

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

[0026] Una presentación de medios puede contener una secuencia de uno o más períodos. Cada período puede contener una o más representaciones para el mismo contenido de medios. Una representación puede ser una de un número de versiones codificadas alternativas de datos de audio o vídeo. Las representaciones pueden diferir según el tipo de codificación, por ejemplo, según la velocidad de transmisión de bits, la resolución y/o el códec para los datos de vídeo y la velocidad de transmisión de bits, el idioma y/o el códec para los datos de audio. El término representación se puede usar para referirse a una sección de datos de audio o vídeo codificados correspondientes a un período en particular del contenido multimedia y codificados de una forma en particular.

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

[0028] Una representación puede incluir uno o más segmentos. Cada representación puede incluir un segmento de inicialización, o cada segmento de una representación puede ser autoinicializador. Cuando está presente, el segmento de inicialización puede contener información de inicialización para acceder a la representación. En general, el segmento de inicialización no contiene datos multimedia. Un segmento se puede referenciar de forma única mediante un identificador, tal como un localizador uniforme de recursos (URL), un nombre uniforme de recurso (URN) o un identificador uniforme de recurso (URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD también puede proporcionar gamas de bytes en forma de un atributo de rango, que puede corresponder a los datos para un segmento dentro de un archivo accesible mediante el URL, el URN o el URI.

[0029] Se pueden seleccionar diferentes representaciones para una recuperación sustancialmente simultánea para diferentes tipos de datos multimedia. Por ejemplo, un dispositivo cliente puede seleccionar una representación de audio, una representación de vídeo y una representación de texto temporizado a partir de las cuales se pueden recuperar segmentos. En algunos ejemplos, el dispositivo cliente puede seleccionar conjuntos de adaptación en particular para realizar una adaptación de ancho de banda. Es decir, el dispositivo cliente puede seleccionar un conjunto de adaptación que incluye representaciones de vídeo, un conjunto de adaptación que incluye representaciones de audio y/o un conjunto de adaptación que incluye texto temporizado. De forma alternativa, el dispositivo cliente puede seleccionar conjuntos de adaptación para determinados tipos de medios (por ejemplo, vídeo) y seleccionar directamente representaciones para otros tipos de medios (por ejemplo, audio y/o texto temporizado).

[0030] La FIG. 4 es un diagrama de bloques que ilustra un sistema 130 de ejemplo que implementa técnicas para transmitir de forma continua datos multimedia por una red. En este ejemplo, el sistema 130 incluye un dispositivo de preparación de contenido 140, un dispositivo servidor 160 y un dispositivo cliente 180. El dispositivo cliente 180 y el dispositivo servidor 160 están acoplados de forma comunicativa por una red 174, que puede comprender Internet. En algunos ejemplos, el dispositivo de preparación de contenido 140 y el dispositivo servidor 160 también pueden estar acoplados por la red 174 u otra red, o pueden estar directamente acoplados de forma comunicativa. En algunos ejemplos, el dispositivo de preparación de contenido 140 y el dispositivo servidor 160 pueden comprender el mismo dispositivo.

[0031] El dispositivo de preparación de contenido 140, en el ejemplo de la FIG. 4, comprende la fuente de audio 142 y la fuente de vídeo 144. La fuente de audio 142 puede comprender, por ejemplo, un micrófono que produce señales eléctricas representativas de datos de audio captado que el codificador de audio 146 va a codificar. De forma alternativa, la fuente de audio 142 puede comprender un medio de almacenamiento que almacena datos de audio previamente registrados, un generador de datos de audio tal como un sintetizador informatizado, o cualquier otra fuente de datos de audio. La fuente de vídeo 144 puede comprender una cámara de vídeo que produce datos de vídeo que el codificador de vídeo 148 va a codificar, un medio de almacenamiento codificado con datos de vídeo previamente registrados, una unidad de generación de datos de vídeo, tal como una fuente de gráficos de ordenador, o cualquier otra fuente de datos de vídeo. El dispositivo de preparación de contenido 140 no está necesariamente acoplado de forma comunicativa al dispositivo servidor 160 en todos los ejemplos, pero puede almacenar contenido multimedia en un medio separado que el dispositivo servidor 160 lee.

[0032] Los datos de audio y de vídeo sin procesar pueden comprender datos analógicos o digitales. Los datos analógicos se pueden digitalizar antes de que el codificador de audio 146 y/o el codificador de vídeo 148 los codifiquen. La fuente de audio 142 puede obtener datos de audio a partir de un participante que habla mientras el participante que habla está hablando, y la fuente de vídeo 144 puede obtener simultáneamente datos de vídeo del participante que habla. En otros ejemplos, la fuente de audio 142 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de audio almacenados, y la fuente de vídeo 144 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de vídeo almacenados. De esta manera, las técnicas descritas en esta divulgación se pueden aplicar a datos de audio y vídeo en tiempo real, de transmisión en directo y en continuo, o a datos de audio y vídeo archivados y pre-registrados.

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

[0034] En algunos ejemplos, el codificador de audio 146 puede codificar un sello horario en cada trama de audio codificada, que representa una hora en que se registraron los datos de audio para la trama de audio codificada y, de manera similar, el codificador de vídeo 148 puede codificar un sello horario en cada trama de vídeo codificado, que representa una hora en la que se registraron los datos de vídeo para la trama de vídeo codificada. En dichos ejemplos, una trama de audio correspondiente a una trama de vídeo puede comprender una trama de audio que comprende una marca de hora y una trama de vídeo que comprende la misma marca de hora. El dispositivo de preparación de contenido 140 puede incluir un reloj interno a partir del cual el codificador de audio 146 y/o el codificador de vídeo 148 pueden generar las marcas de hora, o que la fuente de audio 142 y la fuente de vídeo 144 pueden usar para asociar datos de audio y vídeo, respectivamente, a una marca de hora.

[0035] En algunos ejemplos, la fuente de audio 142 puede enviar datos al codificador de audio 146 correspondientes a una hora en la que se registraron los datos de audio, y la fuente de vídeo 144 puede enviar datos al codificador de vídeo 148, correspondientes a una hora en la que se registraron los datos de vídeo. En algunos ejemplos, el codificador de audio 146 puede codificar un identificador de secuencia en unos datos de audio codificados para indicar un orden temporal relativo de los datos de audio codificados, pero sin indicar necesariamente una hora absoluta a la que se han registrado los datos de audio y, de forma similar, el codificador de vídeo 148 también puede usar identificadores de secuencia para indicar un orden temporal relativo de los datos de vídeo codificados. De forma similar, en algunos ejemplos, un identificador de secuencia se puede asociar a, o correlacionar de otro modo con, una marca de tiempo.

[0036] El codificador de audio 146 produce en general un flujo de datos de audio codificados, mientras que el codificador de vídeo 148 produce un flujo de datos de vídeo codificados. Cada flujo de datos individual (ya sea de audio o vídeo) se puede denominar flujo elemental. Un flujo elemental es un componente único codificado digitalmente (y posiblemente comprimido) de una representación. Por ejemplo, la parte de vídeo o audio codificado de la representación puede ser un flujo elemental. Un flujo elemental se puede convertir en un flujo elemental paquetizado (PES) antes de encapsularse dentro de un archivo de vídeo. Dentro de la misma representación, se puede usar un ID de flujo para distinguir los paquetes PES que pertenecen a un flujo elemental de los otros. La unidad básica de datos de un flujo elemental es un paquete de flujo elemental paquetizado (PES). Por tanto, los datos de vídeo codificados corresponden en general a flujos de vídeo elementales. De forma similar, los datos de audio corresponden a uno o más flujos elementales respectivos.

[0037] Muchas normas de codificación de vídeo, tales como ITU-T H.264/AVC y la inminente norma de codificación de vídeo de alta eficiencia (HEVC), definen la sintaxis, la semántica y el proceso de descodificación para flujos de bits sin errores, cualquiera de los cuales puede ajustarse a un determinado perfil o nivel. Los estándares de codificación de vídeo típicamente no especifican el codificador, pero el codificador se ocupa de garantizar que los flujos de bits generados cumplan los estándares para un descodificador. En el contexto de las normas de codificación de vídeo, un "perfil" corresponde a un subconjunto de algoritmos, características o herramientas y restricciones que se les aplican. Según lo definido por la norma H.264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits que está especificada por la norma H.264. Un "nivel" corresponde a las limitaciones del consumo de recursos del descodificador, tales como, por ejemplo, memoria de descodificador y cálculo, que están relacionados con la resolución de las imágenes, la velocidad de transmisión de bits y la velocidad de procesamiento de bloques. Un perfil se puede señalizar con un valor idc de perfil (indicador de perfil), mientras que un nivel se puede señalizar con un valor level_idc (indicador de nivel).

[0038] La norma H.264, por ejemplo, reconoce que, dentro de los límites impuestos por la sintaxis de un perfil dado, todavía es posible requerir una gran variación en el rendimiento de los codificadores y descodificadores dependiendo de los valores tomados por los elementos sintácticos en el flujo de bits, tales como el tamaño especificado de las imágenes descodificadas. El estándar H.264 reconoce además que, en muchas aplicaciones, no es ni práctico ni económico implementar un descodificador capaz de tratar todos los usos hipotéticos de la sintaxis dentro de un perfil en particular. Por consiguiente, la norma H.264 define un "nivel" como un conjunto especificado de restricciones impuestas a los valores de los elementos sintácticos en el flujo de bits. Estas restricciones pueden ser simples limitaciones de valores. De forma alternativa, estas restricciones pueden adoptar la forma de restricciones sobre combinaciones aritméticas de valores (por ejemplo, la anchura de la imagen multiplicada por la altura de la imagen multiplicada por el número de imágenes descodificadas por segundo). El estándar H.264 establece además que las implementaciones individuales pueden admitir un nivel diferente para cada perfil admitido.

[0039] Un descodificador conforme a un perfil soporta ordinariamente todas las características definidas en el perfil. Por ejemplo, como característica de codificación, la codificación de imágenes B no está admitida en el perfil de línea de base de H.264/AVC, pero está admitida en otros perfiles de H.264/AVC. Un descodificador que se ajusta a un nivel deberá ser capaz de descodificar cualquier flujo de bits que no requiere recursos fuera de las limitaciones definidas en el nivel. Las definiciones de perfiles y niveles pueden ser útiles para la interpretabilidad. Por ejemplo, durante la transmisión de vídeo, se pueden negociar y acordar un par de definiciones de perfil y nivel para una sesión de transmisión completa. Más específicamente, en el ejemplo de H.264/AVC, un nivel puede definir limitaciones en el número de macrobloques que es necesario procesar, el tamaño de la memoria intermedia de imágenes descodificadas (DPB), el tamaño de la memoria intermedia de imágenes codificadas (CPB), el rango de vectores de movimiento vertical, el número máximo de vectores de movimiento para cada dos MB consecutivos y si un bloque B puede tener divisiones de submacrobloque inferiores a 8x8 píxeles. De esta manera, un descodificador puede determinar si el descodificador es capaz de descodificar apropiadamente el flujo de bits.

[0040] En el ejemplo de la FIG. 4, la unidad de encapsulación 150 del dispositivo de preparación de contenido 140 recibe flujos elementales que comprenden datos de vídeo codificados desde el codificador de vídeo 148 y flujos elementales que comprenden datos de audio codificados desde el codificador de audio 146. En algunos ejemplos, el codificador de vídeo 148 y el codificador de audio 146 pueden incluir, cada uno, paquetizadores para formar paquetes PES a partir de datos codificados. En otros ejemplos, el codificador de vídeo 148 y el codificador de audio 146 pueden interactuar, cada uno, con los paquetizadores respectivos para formar paquetes PES a partir de datos codificados. En otros ejemplos más, la unidad de encapsulación 150 puede incluir paquetizadores para formar paquetes PES a partir de datos de audio y de vídeo codificados.

[0041] El codificador de vídeo 148 puede codificar datos de vídeo de contenido multimedia de varias formas, para producir diferentes representaciones del contenido multimedia en diversas velocidades de transmisión de bits y con diversas características, tales como resoluciones de píxeles, velocidades de trama, en conformidad con diversas normas de codificación, en conformidad con diversos perfiles y/o niveles de perfiles para diversas normas de codificación, representaciones que tengan una o múltiples visualizaciones (por ejemplo, para reproducción bidimensional o tridimensional), u otras de dichas características. Una representación, como se usa en esta divulgación, puede comprender uno de datos de audio, datos de vídeo, datos de texto (por ejemplo, para subtítulos cerrados) u otros datos de este tipo. La representación puede incluir un flujo elemental, tal como un flujo elemental de audio o un flujo elemental de vídeo. Cada paquete PES puede incluir un identificador stream_id que identifica el flujo elemental al que pertenece el paquete PES. La unidad de encapsulación 150 es responsable de ensamblar flujos elementales en archivos de vídeo (por ejemplo, segmentos) de diversas representaciones.

[0042] La unidad de encapsulación 150 recibe paquetes PES para flujos elementales de una representación desde el codificador de audio 146 y el codificador de vídeo 148 y forma las correspondientes unidades de capa de abstracción de red (NAL) a partir de los paquetes PES. En el ejemplo de la H.264/AVC (Codificación de Vídeo Avanzada), los segmentos de vídeo codificados están organizados en unidades de NAL, que proporcionan una representación de vídeo "favorecedora para redes" que aborda aplicaciones tales como la videotelefonía, el almacenamiento, la radiodifusión o la transmisión continua. Las unidades NAL se pueden clasificar en unidades NAL de capa de codificación de vídeo (VCL) y unidades NAL no VCL. Las unidades VCL pueden contener el motor de compresión central y pueden incluir datos a nivel de bloque, macrobloque y/o fragmento. Otras unidades NAL pueden ser unidades NAL no 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 más unidades NAL.

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

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

[0045] La unidad de encapsulación 150 puede proporcionar datos para una o más representaciones de contenido multimedia, junto con el archivo de manifiesto (por ejemplo, la MPD), para la interfaz de salida 152. La interfaz de salida 152 puede comprender una interfaz de red o una interfaz para escribir en un medio de almacenamiento, tal como una interfaz de bus serie universal (USB), un grabador o copiador de CD o DVD, una interfaz para medios de almacenamiento magnéticos o flash, u otras interfaces para almacenar o transmitir datos multimedia. La unidad de encapsulación 150 puede proporcionar datos de cada una de las representaciones de contenido multimedia a la interfaz de salida 152, que puede enviar los datos al dispositivo servidor 160 por medio de transmisión por red o medios de almacenamiento. En el ejemplo de la FIG. 4, el dispositivo servidor 160 incluye un medio de almacenamiento 162 que almacena diversos contenidos multimedia 164, incluyendo cada uno un respectivo archivo de manifiesto 166 y una o más representaciones 168A-168N (representaciones 168). En algunos ejemplos, la interfaz de salida 152 también puede enviar datos directamente a la red 174.

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

[0047] El archivo de manifiesto 166 puede incluir datos indicativos de los subconjuntos de representaciones 168 correspondientes a conjuntos de adaptación particulares, así como características comunes para los conjuntos de adaptación. El archivo de manifiesto 166 también puede incluir datos representativos de características individuales, tales como las velocidades de transmisión de bits, para representaciones individuales de conjuntos de adaptación. De esta manera, un conjunto de adaptación puede hacer posible una adaptación simplificada del ancho de banda de red. Las representaciones de un conjunto de adaptación se pueden indicar usando elementos hijo de un elemento del conjunto de adaptación del archivo de manifiesto 166.

[0048] El dispositivo servidor 160 incluye la unidad de procesamiento de peticiones 170 y la interfaz de red 172. En algunos ejemplos, el dispositivo servidor 160 puede incluir una pluralidad de interfaces de red. Además, una cualquiera o todas las características del dispositivo servidor 160 se pueden implementar en otros dispositivos de una red de entrega de contenido, tales como encaminadores, puentes, dispositivos proxy, conmutadores u otros dispositivos. En algunos ejemplos, los dispositivos intermedios de una red de entrega de contenido pueden almacenar en memoria caché datos de contenido multimedia 164, e incluir componentes que se ajustan sustancialmente a los del dispositivo servidor 160. En general, la interfaz de red 172 está configurada para enviar y recibir datos por medio de la red 174.

[0049] La unidad de procesamiento de peticiones 170 está configurada para recibir peticiones de red desde dispositivos clientes, tales como el dispositivo cliente 180, para datos del medio de almacenamiento 162. Por ejemplo, la unidad de procesamiento de peticiones 170 puede implementar el protocolo de transferencia de hipertexto (HTTP) versión 1,1, como se describe en RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1,", de R. Fielding et al., grupo de trabajo en red, IETF, junio de 1999. Es decir, la unidad de procesamiento de peticiones 170 puede estar configurada para recibir peticiones GET o GET parciales HTTP y proporcionar datos de contenido multimedia 164 como respuesta a las peticiones. Las peticiones pueden especificar un segmento de una de las representaciones 168, por ejemplo, usando un URL del segmento. En algunos ejemplos, las peticiones también pueden especificar uno o más rangos de bytes del segmento, comprendiendo por lo tanto peticiones GET parciales. La unidad de procesamiento de peticiones 170 puede estar configurada además para atender peticiones HEAD HTTP para proporcionar datos de cabecera de un segmento de una de las representaciones 168. En cualquier caso, la unidad de procesamiento de peticiones 170 puede estar configurada para procesar las peticiones para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente 180.

[0050] De forma adicional o alternativa, la unidad de procesamiento de peticiones 170 puede estar configurada para entregar datos multimedia por medio de un protocolo de radiodifusión o multidifusión, tal como el eMBMS. El dispositivo de preparación de contenido 140 puede crear segmentos y/o subsegmentos DASH, sustancialmente de la misma manera que se ha descrito, pero el dispositivo servidor 160 puede entregar estos segmentos o subsegmentos usando el eMBMS u otro protocolo de transporte de red de radiodifusión o multidifusión. Por ejemplo, la unidad de procesamiento de peticiones 170 puede estar configurada para recibir una petición para unirse a un grupo de multidifusión desde el dispositivo cliente 180. Es decir, el dispositivo servidor 160 puede comunicar una dirección de protocolo de Internet (IP), asociada a un grupo de multidifusión a unos dispositivos cliente, que incluyen el dispositivo cliente 180, asociados a un contenido de medios en particular (por ejemplo, radiodifusión de un acontecimiento en directo). El dispositivo cliente 180, a su vez, puede presentar una petición para unirse al grupo de multidifusión. Esta petición se puede propagar por toda la red 174, por ejemplo, los encaminadores que componen la red 174, de modo que se hace que los encaminadores dirijan el tráfico destinado a la dirección IP asociada al grupo de multidifusión a los dispositivos cliente abonados, tales como el dispositivo cliente 180.

[0051] Como se ilustra en el ejemplo de la FIG. 4, el contenido multimedia 164 incluye el archivo de manifiesto 166, que puede corresponder a una descripción de presentación de medios (MPD). En el caso de una MPD, correspondiente al estándar DASH, el archivo de manifiesto 166 también puede incluir una directiva sobre las métricas que un cliente puede recopilar y comunicar a un servidor específico. El archivo de manifiesto 166 puede contener descripciones de diferentes representaciones alternativas 168 (por ejemplo, servicios de vídeo con diferentes calidades) y la descripción puede incluir, por ejemplo, información de códec, un valor de perfil, un valor de nivel, una velocidad de transmisión de bits y otras características descriptivas de las representaciones 168. El dispositivo cliente 180 puede recuperar la MPD de una presentación de medios para determinar cómo acceder a segmentos de las representaciones 168.

[0052] En particular, la unidad de recuperación 192 puede recuperar datos de configuración (no mostrados) del dispositivo cliente 180 para determinar las capacidades de descodificación del descodificador de vídeo 188 y las capacidades de representación de la salida de vídeo 184. Los datos de configuración también pueden incluir cualquiera o todas las preferencias de idioma seleccionadas por un usuario del dispositivo cliente 180, una o más perspectivas de cámara correspondientes a las preferencias de profundidad establecidas por el usuario del dispositivo cliente 180 y/o una preferencia de calificación seleccionada por el usuario del dispositivo cliente 180. La unidad de recuperación 192 puede comprender, por ejemplo, un navegador web o un cliente de medios configurados para presentar peticiones GET y GET parcial HTTP. La unidad de recuperación 192 puede corresponder a unas instrucciones de software ejecutadas por uno o más procesadores o unidades de procesamiento (no mostrados) del dispositivo cliente 180. En algunos ejemplos, la totalidad o unas partes de la funcionalidad descrita con respecto a la unidad de recuperación 192 se pueden implementar en hardware, o una combinación de hardware, software y/o firmware, donde se puede proporcionar el hardware requerido para ejecutar instrucciones para software o firmware.

[0053] La unidad de recuperación 192 puede comparar las capacidades de descodificación y representación del dispositivo cliente 180 con las características de las representaciones 168 indicadas por la información del archivo de manifiesto 166. La unidad de recuperación 192 puede recuperar inicialmente al menos una parte del archivo de manifiesto 166 para determinar las características de las representaciones 168. Por ejemplo, la unidad de recuperación 192 puede solicitar una parte del archivo de manifiesto 166 que describe las características de uno o más conjuntos de adaptación. La unidad de recuperación 192 puede seleccionar un subconjunto de representaciones 168 (por ejemplo, un conjunto de adaptación) que tiene características que se pueden satisfacer mediante las capacidades de codificación y representación del dispositivo cliente 180. La unidad de recuperación 192 puede, a continuación, determinar las velocidades de transmisión de bits para las representaciones del conjunto de adaptación, determinar una cantidad actualmente disponible de ancho de banda de red y recuperar segmentos de una de las representaciones que tiene una velocidad de transmisión de bits que se puede satisfacer mediante el ancho de banda de red.

[0054] En general, las representaciones de velocidades de transmisión de bits más altas pueden producir una reproducción de vídeo de mayor calidad, mientras que las representaciones de velocidades de transmisión de bits más bajas pueden proporcionar una reproducción de vídeo de calidad suficiente cuando disminuya el ancho de banda de red disponible. En consecuencia, cuando el ancho de banda de red disponible es relativamente alto, la unidad de recuperación 192 puede recuperar datos de representaciones de velocidad de transmisión de bits relativamente alta, mientras que cuando el ancho de banda de red disponible es bajo, la unidad de recuperación 192 puede recuperar datos de representaciones de velocidad de transmisión de bits relativamente baja. De esta manera, el dispositivo cliente 180 puede transmitir en continuo datos multimedia a través de la red 174 mientras que también se adapta a la disponibilidad cambiante de ancho de banda de red de la red 174.

[0055] De forma adicional o alternativa, la unidad de recuperación 192 puede estar configurada para recibir datos de acuerdo con un protocolo de red de radiodifusión o multidifusión, tal como la multidifusión MBMS, eMBMS o IP. En dichos ejemplos, la unidad de recuperación 192 puede presentar una petición para unirse a un grupo de red de multidifusión asociado a un contenido de medios en particular. Después de unirse al grupo de multidifusión, la unidad de recuperación 192 puede recibir datos del grupo de multidifusión sin peticiones adicionales emitidas al dispositivo servidor 160 o al dispositivo de preparación de contenido 140. La unidad de recuperación 192 puede presentar una petición para abandonar el grupo de multidifusión cuando ya no se necesitan datos del grupo de multidifusión, por ejemplo, para parar la reproducción o para cambiar canales a un grupo de multidifusión diferente.

[0056] De acuerdo con las técnicas de esta divulgación, la unidad de recuperación 192 puede incluir una aplicación de transmisión continua (por ejemplo, un cliente DASH) y una unidad de middleware. La unidad de middleware puede configurarse para recibir mediciones de calidad de experiencia (QoE) del cliente DASH y entregar las mediciones de QoE, junto con los informes de recepción de eMBMS, por ejemplo, al dispositivo servidor 160. Es decir, el dispositivo cliente 180 puede corresponder al UE 106', 106" de las FIGS. 2, 3, y el dispositivo servidor 160 puede corresponder al servidor de aprovisionamiento y BMSC 104', 104" de las FIGS. 2, 3. Aunque no se muestra en la FIG. 4, en algunos ejemplos, el sistema 130 puede incluir adicionalmente un servidor de recopilación de métricas de calidad DASH, al que el cliente DASH y/o la unidad de middleware pueden informar sobre las medidas de DASH QoE, como se analizó con respecto a la FIG. 3 anteriormente.

[0057] La interfaz de red 194 puede recibir y proporcionar datos de segmentos de una representación seleccionada a la unidad de recuperación 192, que a su vez puede proporcionar los segmentos a la unidad de desencapsulación 190. La unidad de desencapsulación 190 puede desencapsular elementos de un archivo de vídeo en flujos PES constituyentes, despaquetizar los flujos PES para recuperar datos codificados y enviar los datos codificados al descodificador de audio 186 o bien al descodificador de vídeo 188, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como lo indican las cabeceras de paquetes PES del flujo. El descodificador de audio 186 descodifica datos de audio codificados y envía los datos de audio descodificados a la salida de audio 182, mientras que el descodificador de vídeo 188 descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de visualizaciones de un flujo, a la salida de vídeo 184.

[0058] Cada uno del codificador de vídeo 148, el descodificador de vídeo 188, el codificador de audio 146, el descodificador de audio 186, la unidad de encapsulación 150, la unidad de recuperación 192, la unidad de procesamiento de peticiones 170 y la unidad de desencapsulación 190 se puede implementar como cualquiera de una variedad de circuitos de procesamiento fijos y/o programables adecuados, según corresponda, tales como uno o más microprocesadores, procesadores de señales digitales (DSP), circuitos integrados específicos de la aplicación (ASIC), matrices de puertas programables in situ (FPGA), circuitos lógicos discretos, software, hardware, firmware o cualquier combinación de los mismos. Tanto el codificador de vídeo 148 como el descodificador de vídeo 188 pueden estar incluidos en uno o más codificadores o descodificadores, ambos de los cuales pueden estar integrados como parte de un codificador/descodificador (CÓDEC) de vídeo combinado. Asimismo, tanto el codificador de audio 146 como el descodificador de audio 186 pueden estar incluidos en uno o más codificadores o descodificadores, ambos de los cuales puede estar integrado como parte de un CÓDEC combinado. Un aparato que incluye un codificador de vídeo 148, un descodificador de vídeo 188, un codificador de audio 146, un descodificador de audio 186, una unidad de encapsulación 150, una unidad de recuperación 192, una unidad de procesamiento de peticiones 170 y/o una unidad de desencapsulación 190 puede comprender un circuito integrado, un microprocesador y/o un dispositivo de comunicación inalámbrica, tal como un teléfono móvil.

[0059] El dispositivo cliente 180, el dispositivo servidor 160 y/o el dispositivo de preparación de contenido 140 pueden estar configurados para funcionar de acuerdo con las técnicas de esta divulgación. Con propósitos ejemplificativos, esta divulgación describe estas técnicas con respecto al dispositivo cliente 180 y al dispositivo servidor 160. Sin embargo, se deberá entender que el dispositivo de preparación de contenido 140 puede estar configurado para realizar estas técnicas, en lugar (o además) del dispositivo servidor 160.

[0060] La unidad de encapsulación 150 puede formar unidades NAL que comprenden una cabecera que identifica un programa al que pertenece la unidad NAL, así como una carga útil, por ejemplo, datos de audio, datos de vídeo o datos que describen el flujo de transporte o de programa al que corresponde la unidad NAL. Por ejemplo, en H.264/AVC, una unidad NAL incluye una cabecera de 1 byte y una carga útil de tamaño variable. Una unidad NAL que incluye datos de vídeo en su carga útil puede comprender diversos niveles de granularidad de datos de vídeo. Por ejemplo, una unidad NAL puede comprender un bloque de datos de vídeo, una pluralidad de bloques, un fragmento de datos de vídeo o una imagen completa de datos de vídeo. La unidad de encapsulación 150 puede recibir datos de vídeo codificados desde el codificador de vídeo 148 en forma de paquetes PES de flujos elementales. La unidad de encapsulación 150 puede asociar cada flujo elemental a un programa correspondiente.

[0061] La unidad de encapsulación 150 también puede ensamblar unidades de acceso de una pluralidad de unidades NAL. En general, una unidad de acceso puede comprender una o más unidades NAL para representar una trama de datos de vídeo, así como datos de audio correspondientes a la trama cuando dichos datos de audio están disponibles. Una unidad de acceso incluye en general todas las unidades NAL para una instancia de tiempo de salida, por ejemplo, todos los datos de audio y vídeo para una instancia de tiempo. Por ejemplo, si cada visualización tiene una frecuencia de tramas de 20 tramas por segundo (fps), cada instancia de tiempo puede corresponder a un intervalo de tiempo de 0,05 segundos. Durante este intervalo de tiempo, las tramas específicas para todas las visualizaciones de la misma unidad de acceso (la misma instancia de tiempo) se pueden representar simultáneamente. En un ejemplo, una unidad de acceso puede comprender una imagen codificada en una instancia de tiempo, que se puede presentar como una imagen codificada primaria.

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

[0063] Una presentación de medios puede incluir una descripción de presentación de medios (MPD), que puede contener descripciones de diferentes representaciones alternativas (por ejemplo, servicios de vídeo con diferentes calidades) y la descripción puede incluir, por ejemplo, información de códec, un valor de perfil y un valor de nivel. Una MPD es un ejemplo de archivo de manifiesto, tal como el archivo de manifiesto 166. El dispositivo cliente 180 puede recuperar la MPD de una presentación de medios para determinar cómo acceder a fragmentos de película de diversas presentaciones. Los fragmentos de película pueden estar situados en cuadros de fragmento de película (cuadros moof) de archivos de vídeo.

[0064] El archivo de manifiesto 166 (que puede comprender, por ejemplo, una MPD) puede comunicar la disponibilidad de segmentos de representaciones 168. Es decir, la MPD puede incluir información que indica la hora de reloj de tiempo real a la cual un primer segmento de una de las representaciones 168 queda disponible, así como información que indica las duraciones de los segmentos dentro de las representaciones 168. De esta manera, la unidad de recuperación 192 del dispositivo cliente 180 puede determinar cuándo está disponible cada segmento, basándose en el tiempo de inicio, así como de las duraciones de los segmentos que preceden a un segmento en particular.

[0065] Después de que la unidad de encapsulación 150 haya ensamblado las unidades NAL y/o las unidades de acceso en un archivo de vídeo, basándose en los datos recibidos, la unidad de encapsulación 150 pasa el archivo de vídeo a la interfaz de salida 152 para su envío. En algunos ejemplos, la unidad de encapsulación 150 puede almacenar el archivo de vídeo localmente o enviar el archivo de vídeo a un servidor remoto por medio de la interfaz de salida 152, en lugar de enviar el archivo de vídeo directamente al dispositivo cliente 180. La interfaz de salida 152 puede comprender, por ejemplo, un transmisor, un transceptor, un dispositivo para escribir datos en un medio legible por ordenador tal como, por ejemplo, una unidad óptica, una unidad de medios magnéticos (por ejemplo, una unidad de disquetes), un puerto de bus serie universal (USB), una interfaz de red u otra interfaz de salida. La interfaz de salida 152 facilita el archivo de vídeo a un medio legible por ordenador, tal como, por ejemplo, una señal de transmisión, un medio magnético, un medio óptico, una memoria, una unidad flash u otro medio legible por ordenador.

[0066] La interfaz de red 194 puede recibir una unidad NAL o unidad de acceso por medio de la red 174 y proporcionar la unidad NAL o la unidad de acceso a la unidad de desencapsulación 190, por medio de la unidad de recuperación 192. La unidad de desencapsulación 190 puede desencapsular un elemento de un archivo de vídeo en flujos PES constituyentes, desempaquetar los flujos PES para recuperar datos codificados y enviar los datos codificados al descodificador de audio 186 o al descodificador de vídeo 188, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como se indica en las cabeceras de paquetes PES del flujo. El descodificador de audio 186 descodifica datos de audio codificados y envía los datos de audio descodificados a la salida de audio 182, mientras que el descodificador de vídeo 188 descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de visualizaciones de un flujo, a la salida de vídeo 184.

[0067] La MPD incluye un elemento de métricas que contiene las métricas para ser recopiladas, y los parámetros de carga. Los parámetros de carga incluyen un elemento de informe que puede ampliarse mediante el uso de valores específicos de reporting@schemeIdUri. La Sección 10.5 de 3GP-DASH 26.246 versión d00 especifica que la URN que se utilizará para el Reporting@schemeIdUri será "urn:3GPP:ns:PSS:DASH:QM10." 3GP-DASH también define la semántica de la información del esquema para el esquema de informes de calidad 3GP-DASH de la siguiente manera:

[0068] La FIG. 5 es un diagrama de bloques que ilustra con mayor detalle un ejemplo de conjunto de componentes de la unidad de recuperación 192 de la FIG. 4. En este ejemplo, la unidad de recuperación 192 incluye la unidad de middleware eMBMS 200, el cliente DASH 212 y la aplicación de medios 214, la unidad de middleware eMBMS 200 en general puede corresponder a MSDC 112', 112" de las FIGS. 2, 3, mientras que el cliente DASH 212 puede corresponder al cliente DASH 108', 108" de las FIGS. 2, 3.

[0069] En este ejemplo, la unidad de middleware eMBMS 200 incluye además la unidad de recepción eMBMS 206, la memoria caché 204, el servidor proxy / local 202, y la unidad de informes de recepción 210. En este ejemplo, la unidad de recepción 206 eMBMS está configurada para recibir datos a través de eMBMS, por ejemplo, de acuerdo con la entrega de archivos sobre transporte unidireccional (FLUTE), descrita en T. Paila et al., "FLUTE-File Delivery over Unidirectional Transport,", grupo de trabajo en red, RFC 6726, noviembre de 2012, disponible en tools.ietf.org/html/rfc6726, o Protocolo de entrega de objetos en tiempo real sobre transporte unidireccional (ROUTE). Es decir, la unidad de recepción eMBMS 206 puede recibir archivos vía radiodifusión desde, por ejemplo, el dispositivo servidor 160 de la FIG. 4, que puede actuar como un BM-SC.

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

[0071] El servidor proxy/local 202 puede actuar como un servidor HTTP para el cliente DASH 212. Por ejemplo, el middleware puede modificar el archivo MPD u otro archivo de manifiesto para el cliente DASH 212. Middleware 200 anunciaría tiempos de disponibilidad ajustados para segmentos en el archivo MPD, así como hipervínculos desde los cuales los segmentos pueden recuperarse localmente. Estos hipervínculos pueden incluir un prefijo de dirección de localhost correspondiente al dispositivo cliente 180 de la FIG. 4 (por ejemplo, 127.0.0.1 para IPv4). De esta manera, el cliente DASH 212 puede solicitar segmentos del servidor HTTP local 202 utilizando HTTP GET o peticiones GET parciales. Por ejemplo, para un segmento disponible en el enlace http://127.0.0.1/rep1/seg3, el cliente DASH 212 puede construir una petición HTTP GET que incluya una petición para http://127.0.0.1/rep1/seg3, y enviar la petición al servidor proxy/local 202. El servidor proxy/local 202 puede recuperar los datos solicitados de la memoria caché 204 y proporcionar los datos al cliente DASH 212 en respuesta a tales peticiones. De forma alternativa, la unidad de middleware eMBMS 200 no necesita modificar las URL en la MPD y actuar como un proxy. Las peticiones dirigidas para el servidor DASH 170 son interceptadas por la unidad de middleware eMBMS 200 y atendidas desde la caché local.

[0072] De acuerdo con las técnicas esta divulgación, el servidor proxy/servidor loca1HTTP 202 también incluye la unidad de recepción de métricas DASH QoE 208. La unidad receptora de métricas DASH QoE 208 en general está configurada para interceptar (en el caso del proxy, tenga en cuenta que el servidor proxy/local 202 puede permitir opcionalmente informes a través de un servidor de medición DASH) o recibir (cuando actúa como un servidor local) informes DASH del cliente DASH, por ejemplo, aceptando comandos de publicación HTTP. A continuación, el informe se envía a la unidad de informe de recepción 210, que a continuación puede informar sobre las métricas DASH QoE en nombre del cliente DASH 212 a un dispositivo servidor y/o puede incluir el informe de medición DASH QoE en un informe de recepción. Por ejemplo, las métricas DASH QoE pueden recibir métricas de QoE del cliente DASH 212. Es decir, el servidor proxy/local 202 puede configurarse para recibir comandos HTTP POST del cliente DASH 212, incluidas las métricas DASH QoE de acuerdo con una descripción de presentación de medios (MPD) u otro archivo de manifiesto. Además, la unidad de informe de recepción 210 informa sobre la recepción de acuerdo con, por ejemplo, eMBMS. En algunos ejemplos, la unidad de informes de recepción 210 envía un informe único que incluye tanto métricas DASH QoE como informes de recepción eMBMS. En otros ejemplos, la unidad de informes de recepción 210 envía informes separados para los informes de recepción de eMBMS y las métricas DASH QoE.

[0073] Después de recibir un informe de medición DASH QoE desde el cliente DASH 212, la unidad de comunicación de recepción 210 puede informar de las métricas DASH QoE a un dispositivo servidor, junto con informes de recepción relativos a un protocolo por el cual la unidad de middleware eMBMS 200 informa sobre la recepción de archivos encapsulando los datos DASH. Además, en algunos ejemplos, una o ambas unidades de middleware eMBMS 200 y/o el cliente DASH 212 pueden configurarse para informar también sobre las métricas DASH QoE a un servidor de métricas DASH dedicado, como se analizó con respecto a la FIG. 3 anteriormente.

[0074] El dispositivo servidor 160 (FIG. 1) puede incluir también una función de BMSC que entrega un anuncio de servicio a la unidad de middleware eMBMS 200. Como parte de esta invención, el anuncio de servicio puede incluir además directivas sobre el tipo y el contenido del informe de medición DASH QoE deseado. Por ejemplo, el fragmento del procedimiento de entrega asociado (ADP) del anuncio del servicio puede incluir nuevos campos y elementos que describen las métricas deseadas para el informe DASH QoE, así como otros parámetros. Un ejemplo de implementación se describe más adelante en las Figuras 9 y 10 a continuación. En un sentido más general, las directivas de recopilación de DASH QoE se pueden entregar a través de otros medios, por ejemplo, OMA DM, un archivo de configuración, el propio MPD original o cualquier otro medio.

[0075] A continuación, la unidad de middleware EMBMS 200 comunica las directivas anteriores al cliente DASH 212. Un procedimiento para comunicar estas directivas es que la unidad de middleware eMBMS 200 puede modificar la MPD alojado localmente (excepto en el caso en que la MPD original lleva las directivas, en cuyo caso la unidad de middleware eMBMS 200 no necesita modificar la MPD) para reflejar los parámetros de recopilación de métricas obtenido del servidor 160 de la FIG. 4.

[0076] En otro ejemplo, la unidad de middleware eMBMS 200 puede modificar la MPD para recopilar las métricas deseadas o un superconjunto de las métricas, y para siempre informar a la unidad de middleware eMBMS 200. La unidad de middleware e MBMS 200 puede entonces reducir las métricas al conjunto solicitado por el servidor 160 e informar con la probabilidad solicitada por el servidor 160.

[0077] En otro ejemplo, el servidor 160 da instrucciones a la unidad de middleware eMBMS 200 para recopilar informes de recepción de acuerdo con las directivas de recopilación que incluyen una probabilidad de recopilación de informes de recepción (parámetro samplingPercentage en el fragmento ADP actual). La directiva de recopilación de DASH QoE enviada a la unidad de middleware eMBMS 200 puede incluir a continuación una probabilidad de recopilación independiente o una probabilidad de recopilación condicional. La probabilidad de recopilación relativa indica la recopilación condicional de las mediciones DASH QoE solo cuando se recopilan informes de recepción, por ejemplo, si el parámetro de porcentaje de muestreo de informes de recepción es del 50 % y el de la probabilidad de recopilación condicional es del 50 % también, entonces los informes de recepción se recopilan para el 50 % de las sesiones y los informes de medición DASH se recopilan para el 50 % de las sesiones donde los informes de recepción están activos. La probabilidad absoluta de recopilación resultante para las mediciones DASH QoE es entonces del 25 %.

[0078] La FIG. 6 es un diagrama conceptual que ilustra elementos del contenido multimedia 220 de ejemplo. El contenido multimedia 220 puede corresponder al contenido multimedia 164 (FIG. 4), o a otro contenido multimedia almacenado en el medio de almacenamiento 162. En el ejemplo de la FIG. 6, el contenido multimedia 220 incluye una descripción de presentación de medios (MPD) 222 y una pluralidad de representaciones 224A-224N (representaciones 224). La representación 224A incluye datos de cabecera 226 y segmentos 228A-228N (segmentos 228) opcionales, mientras que la representación 224N incluye datos de cabecera 230 y segmentos 232A-232N (segmentos 232) opcionales. La letra N se usa para designar, por razones de conveniencia, el último fragmento de película en cada una de las representaciones 224. En algunos ejemplos, puede haber diferentes números de fragmentos de películas entre las representaciones 224.

[0079] La MPD 222 puede comprender una estructura de datos separada de las representaciones 224. La MPD 222 puede corresponder al archivo de manifiesto 166 de la FIG. 4. Del mismo modo, las representaciones 224 pueden corresponder a las representaciones 168 de la FIG. 4. En general, la MPD 222 puede incluir datos que en general describen características de las representaciones 224, tales como características de codificación y representación, conjuntos de adaptación, un perfil al que corresponde la MPD 222, información de tipo de texto, información de ángulo de cámara, información de calificación, la información de modo truco (por ejemplo, información indicativa de representaciones que incluyen subsecuencias temporales) y/o información para recuperar períodos remotos (por ejemplo, para inserción de publicidad dirigida en el contenido de medios durante la reproducción).

[0080] Los datos de cabecera 226, cuando están presentes, pueden describir características de los segmentos 228, por ejemplo, ubicaciones temporales de puntos de acceso aleatorio (RAP, también denominados puntos de acceso de flujo (SAP)), cuáles de los segmentos 228 incluyen puntos de acceso aleatorio, desplazamientos de bytes a puntos de acceso aleatorio dentro de los segmentos 228, localizadores uniformes de recursos (URL) de los segmentos 228 u otros aspectos de los segmentos 228. Los datos de cabecera 230, cuando están presentes, pueden describir características similares para los segmentos 232. De forma adicional o alternativa, dichas características pueden estar incluidas por completo dentro de la MPD 222.

[0081] Los segmentos 228, 232 incluyen una o más muestras de vídeo codificadas, cada una de las cuales puede incluir tramas o fragmentos de datos de vídeo. Cada una de las muestras de vídeo codificadas de los segmentos 228 puede tener características similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Dichas características pueden describirse por datos de la MPD 222, aunque dichos datos no se ilustren en el ejemplo de la FIG. 6. La MPD 222 puede incluir características como se describen en la especificación 3GPP, con la adición de cualquiera o toda la información señalizada descrita en esta divulgación.

[0082] Cada uno de los segmentos 228, 232 puede estar asociado a un único localizador uniforme de recursos (URL). Por tanto, cada uno de los segmentos 228, 232 puede ser independientemente recuperable usando un protocolo de red de transmisión continua, tal como DASH. De esta manera, un dispositivo de destino, tal como el dispositivo cliente 180 de la FIG. 4, puede usar una petición HTTP GET para recuperar los segmentos 228 o 232. En algunos ejemplos, el dispositivo cliente 180 puede usar peticiones GET parciales HTTP para recuperar rangos de bytes específicos de los segmentos 228 o 232.

[0083] De acuerdo con las técnicas de esta divulgación, MPD 222 puede incluir datos que especifican métricas para ser comunicados a un dispositivo servidor. Por ejemplo, MPD 222 puede incluir datos que se ajusten a los descritos con respecto a la FIG. 8 a continuación.

[0084] La FIG. 7 es un diagrama de bloques que ilustra elementos de un archivo de vídeo 250 de ejemplo, que puede corresponder a un segmento de una representación, tal como uno de los segmentos 228, 232 de la FIG. 6. Cada uno de los segmentos 228, 232 puede incluir datos que se ajustan sustancialmente a la disposición de datos ilustrada en el ejemplo de la FIG. 7. Se puede decir que el archivo de vídeo 250 encapsula un segmento. Como se ha descrito anteriormente, los archivos de vídeo, de acuerdo al formato de archivo de medios de base de la ISO, y las ampliaciones del mismo, almacenan los datos en una serie de objetos, denominados "cuadros". En el ejemplo de la FIG. 7, el archivo de vídeo 250 incluye el cuadro de tipo de archivo (FTYP) 252, el cuadro de película (MOOV) 254, los cuadros de índices de segmento (sidx) 262, los cuadros de fragmento de película (MOOF) 164 y el cuadro de acceso aleatorio de fragmento de película (MFRA) 266. Aunque la FIG. 7 representa un ejemplo de archivo de vídeo, se deberá entender que otros archivos de medios pueden incluir otros tipos de datos multimedia (por ejemplo, datos de audio, datos de texto temporizado o similares) que están estructurados de forma similar a los datos del archivo de vídeo 250, de acuerdo con el formato de archivo de medios de base ISO y sus ampliaciones.

[0085] El cuadro de tipo de archivo (FTYP) 252 describe en general un tipo de archivo para el archivo de vídeo 250. El cuadro de tipo de archivo 252 puede incluir datos que identifican una especificación que describe un mejor uso para el archivo de vídeo 250. El cuadro de tipo de archivo 252 puede estar colocado de forma alternativa antes del cuadro MOOV 254, los cuadros de fragmento de película 164 y/o el cuadro MFRA 266.

[0086] En algunos ejemplos, un segmento, tal como el archivo de vídeo 250, puede incluir un cuadro de actualización de MPD (no mostrado) antes del cuadro FTYP 252. El cuadro de actualización de MPD puede incluir información que indica que se va a actualizar una MPD correspondiente a una representación que incluye el archivo de vídeo 250, junto con información para actualizar la MPD. Por ejemplo, el cuadro de actualización de MPD puede proporcionar un URI o URL para un recurso que se va a usar para actualizar la MPD. Como otro ejemplo, el cuadro de actualización de MPD puede incluir datos para actualizar la MPD. En algunos ejemplos, el cuadro de actualización de MPD puede seguir inmediatamente a un cuadro de tipo de segmento (STYP) (no mostrado) del archivo de vídeo 250, donde el cuadro STYP puede definir un tipo de segmento para el archivo de vídeo 250. La FIG. 7, analizada con mayor detalle a continuación, proporciona información adicional con respecto al cuadro de actualización de MPD.

[0087] El cuadro MOOV 254, en el ejemplo de la FIG. 7, incluye el cuadro de cabecera de película (MVHD) 256, el cuadro de pista (TRAK) 258 y uno o más cuadros de extensión de película (MVEX) 260. En general, el cuadro MVHD 256 puede describir características generales del archivo de vídeo 250. Por ejemplo, el cuadro MVHD 256 puede incluir datos que describen cuándo se creó originalmente el archivo de vídeo 250, cuándo se modificó por última vez el archivo de vídeo 250, una escala de tiempo para el archivo de vídeo 250, una duración de reproducción para el archivo de vídeo 250 u otros datos que describen en general el archivo de vídeo 250.

[0088] El cuadro TRAK 258 puede incluir datos para una pista del archivo de vídeo 250. El cuadro TRAK 258 puede incluir un cuadro de cabecera de pista (TKHD) que describe las características de la pista correspondiente al cuadro TRAK 258. En algunos ejemplos, el cuadro TRAK 258 puede incluir imágenes de vídeo codificadas, mientras que, en otros ejemplos, los cuadros de vídeo codificado de la pista pueden estar incluidos en fragmentos de película 264, a los cuales se puede hacer referencia mediante unos datos del cuadro TRAK 258 y/o los cuadros SIDX 262.

[0089] En algunos ejemplos, el archivo de vídeo 250 puede incluir más de una pista. Por consiguiente, el cuadro MOOV 254 puede incluir un número de cuadros TRAK igual al número de pistas del archivo de vídeo 250. El cuadro TRAK 258 puede describir las características de una pista correspondiente del archivo de vídeo 250. Por ejemplo, el cuadro TRAK 258 puede describir información temporal y/o espacial para la pista correspondiente. Un cuadro TRAK similar al cuadro TRAK 258 del cuadro MOOV 254 puede describir características de una pista de conjunto de parámetros, cuando la unidad de encapsulación 150 (FIG. 6) incluye una pista de conjunto de parámetros en un archivo de vídeo, tal como el archivo de vídeo 250. La unidad de encapsulación 150 puede señalizar la presencia de mensajes SEI de nivel de secuencia en la pista de conjunto de parámetros dentro del cuadro TRAK que describe la pista de conjunto de parámetros.

[0090] Los cuadros MVEX 260 pueden describir las características de los fragmentos de película 264 correspondientes, por ejemplo, para señalar que el archivo de vídeo 250 incluye fragmentos de película 264, además de los datos de vídeo incluidos en el cuadro MOOV 254, si corresponde. En el contexto de la transmisión continua de datos de vídeo, las imágenes de vídeo codificadas pueden estar incluidas en los fragmentos de película 264 en lugar de en el cuadro MOOV 254. En consecuencia, todas las muestras de vídeo codificadas pueden estar incluidas en fragmentos de película 264, en lugar de en el cuadro MOOV 254.

[0091] El cuadro MOOV 254 puede incluir un número de cuadros MVEX 260 igual al número de los fragmentos de película 264 en el archivo de vídeo 250. Cada uno de los cuadros MVEX 260 puede describir características de uno correspondiente de los fragmentos de película 264. Por ejemplo, cada cuadro MVEX puede incluir un cuadro de cabecera de ampliación de película (MEHD) que describe una duración temporal para el uno correspondiente de los fragmentos de película 264.

[0092] Como se señaló anteriormente, la unidad de encapsulación 150 de la FIG. 4 puede almacenar un conjunto de datos de secuencia en una muestra de vídeo que no incluya datos reales de vídeo codificados. Una muestra de vídeo puede corresponder en general a una unidad de acceso, que es una representación de una imagen codificada en una instancia de tiempo específica. En el contexto de la AVC, la imagen codificada incluye una o más unidades NAL VCL que contienen la información para construir todos los píxeles de la unidad de acceso y otras unidades NAL no VCL asociadas, tales como mensajes SEI. Por consiguiente, la unidad de encapsulación 150 puede incluir un conjunto de datos de secuencia, que puede incluir mensajes SEI de nivel de secuencia, en uno de los fragmentos de película 264. La unidad de encapsulación 150 puede señalizar además la presencia de un conjunto de datos de secuencia y/o de mensajes SEI de nivel de secuencia con la presencia de estos en uno de los fragmentos de película 264 dentro de uno de los cuadros MVEX 260 correspondiente al uno de los fragmentos de película 264.

[0093] Los cuadros SIDX 262 son elementos opcionales del archivo de vídeo 250. Es decir, los archivos de vídeo que se ajustan al formato de archivo 3GPP u otros formatos de archivo de este tipo, no incluyen necesariamente cuadros SIDX 262. De acuerdo con el ejemplo del formato de archivo 3GPP, se puede usar un cuadro SIDX para identificar un subsegmento de un segmento (por ejemplo, un segmento contenido dentro del archivo de vídeo 250). El formato de archivo 3GPP define un subsegmento como "un conjunto autónomo de uno o más cuadros de fragmento de película consecutivos con un(os) cuadro(s) de datos multimedia correspondiente(s), y un cuadro de datos multimedia que contiene datos a los que se hace referencia mediante un cuadro de fragmento de película debe seguir ese cuadro de fragmento de película y preceder al siguiente cuadro de fragmento de película que contiene información sobre la misma pista". El formato de archivo 3GPP también indica que un cuadro SIDX "contiene una secuencia de referencias a subsegmentos del (sub)segmento documentado por el cuadro. Los subsegmentos a los que se hace referencia son contiguos en el tiempo de presentación. De forma similar, los bytes a los que un cuadro de índice de segmento hace referencia siempre son contiguos dentro del segmento. El tamaño al que se hace referencia da el recuento del número de bytes en el material al que se hace referencia".

[0094] Los cuadros SIDX 262 en general proporcionan información representativa de uno o más subsegmentos de un segmento incluido en el archivo de vídeo 250. Por ejemplo, dicha información puede incluir tiempos de reproducción en los que comienzan y/o terminan los subsegmentos, desplazamientos de bytes para los subsegmentos, si los subsegmentos incluyen (por ejemplo, comienzan con) un punto de acceso de flujo (SAP), un tipo para el SAP (por ejemplo, si el SAP es una imagen de actualización de descodificador instantánea (IDR), una imagen de acceso aleatorio limpio (CRA), una imagen de acceso de enlace roto (BLA) o similares), una posición del SAP (en términos de tiempo de reproducción y/o desplazamiento de bytes) en el subsegmento y similares.

[0095] Los fragmentos de película 264 pueden incluir una o más imágenes de vídeo codificadas. En algunos ejemplos, los fragmentos de película 264 pueden incluir uno o más grupos de imágenes (GOP), cada uno de los cuales puede incluir un número de imágenes de vídeo codificadas, por ejemplo, tramas o imágenes. Además, como se describe anteriormente, los fragmentos de película 264 pueden incluir conjuntos de datos de secuencia en algunos ejemplos. Cada uno de los fragmentos de película 264 puede incluir un cuadro de cabecera de fragmento de película (MFHD, no mostrado en la FIG. 7). El cuadro MFHD puede describir características del fragmento de película correspondiente, tales como un número de secuencia para el fragmento de película. Los fragmentos de película 264 pueden estar incluidos en orden de número de secuencia en el archivo de vídeo 250.

[0096] El cuadro MFRA 266 puede describir los puntos de acceso aleatorios dentro de los fragmentos de película 264 del archivo de vídeo 250. Esto puede ayudar a realizar modos de truco, tales como realizar búsquedas hasta ubicaciones temporales en particular (es decir, tiempos de reproducción) dentro de segmento encapsulado por el archivo de vídeo 250. El cuadro MFRA 266 en general es opcional y no necesita estar incluida en los archivos de vídeo, en algunos ejemplos. Del mismo modo, un dispositivo cliente, tal como el dispositivo cliente 180 de la FIG. 4, no tiene necesariamente que hacer referencia al cuadro MFRA 266 para descodificar y visualizar correctamente los datos de vídeo del archivo de vídeo 250. El cuadro MFRA 266 puede incluir un número de cuadros de acceso aleatorio de fragmento de pista (TFRA) (no mostrados) igual al número de pistas del archivo de vídeo 250 o, en algunos ejemplos, igual al número de pistas de medios (por ejemplo, pistas no de indicaciones) del archivo de vídeo 250.

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

[0098] La FIG. 8 es un diagrama conceptual que ilustra datos de ejemplo 280 que pueden incluirse en un archivo de manifiesto, tal como una descripción de presentación de medios (MPD) de DASH, de acuerdo con las técnicas de esta divulgación. En este ejemplo, la MPD puede incluir uno o más elementos de métricas 282 en el cuadro MPDtype. El 3GP-DASH existente limita el soporte a una aparición del elemento de métricas.

[0099] Además, la MPD incluye una lista de atributos MetricsType 284, que especifica las métricas 286 para recopilar (y también puede incluir parámetros de recopilaciones, por ejemplo, entre paréntesis). La lista de atributos de MetricsType 284 también puede incluir uno o más elementos de informe 288. Cada elemento de informe puede incluir un atributo que especifica un SchemIdURI 290, que puede ser un nombre de recurso uniforme (URN) como se define en 3GP-DASH. Este elemento SchemeIdURI 290 puede incluir datos estructurados agregados como elementos de extensión o atributos en un espacio de nombres separado. El valor del elemento SchemeIdURI 290 puede especificar un identificador de un servidor al que informar

[0100] Además, la MPD incluye cero o más elementos de rango 292 para el elemento MetricsType. Cada elemento de rango 292 en general incluye datos que indican cuándo recopilar métricas de QoE. Si se omite el elemento de rango 292, una unidad de cliente/middleware DASH puede determinar que métricas se recopilan para toda la sesión. El elemento de rango 292 en este ejemplo incluye el elemento de hora de inicio 289 y el elemento de duración 291. Cuando se transmite de forma continua contenido de medios en vivo, el elemento de hora de inicio 289 puede especificar una hora de inicio relativa a la hora de inicio de disponibilidad para el contenido de medios. El elemento de duración 291 puede especificar una duración en el tiempo de reproducción para el rango para el cual se informarán las métricas.

[0101] Por lo tanto, los elementos de métricas 282 pueden definirse en el nivel raíz MPD. Los posibles valores del SchemeIdURI 290 de informes no están definidos en MPEG DASH. En general, SchemeIdURI 290 puede ser un localizador de recursos uniforme (URL), un nombre de recurso uniforme (URN) u otro valor identificador. Un valor específico para 3GPP se define en 3GP-DASH 26.247. El elemento de valor 285 del elemento de informe 288 en la lista de atributos se usa para una lista de parámetros. El elemento de ID 287 del elemento de informe 288 identifica esquemas de informe equivalentes por los cuales solo uno de los múltiples schemeIdURI de informes necesita ser considerado si múltiples de tales elementos tienen la misma ID.

[0102] La sección 10.5 de 3GP-DASH 26.247 versión d00 especifica una sintaxis XML (lenguaje de marcado extensible) de la información del esquema para el esquema de informes de calidad 3GP-DASH de la siguiente manera:

<?xml version="1.0"?>

<xs: schema

targetNamespace="urn:3GPP:ns:PSS: AdaptiveHTTPStreaming:2009:qm" attributeFormDefault="unqualified"

elementFormDefault="qualified"

xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009:qm">

<xs:annotation>

<xs:appinfo>3GPP DASH Quality Reporting</xs:appinfo>

<xs:documentation xml:lang="en">

This Schema defines the quality reporting scheme information for 3GPP DASH. </xs: documentation>

</xs:annotation>

<xs:element name="ThreeGPQualityReporting"

type=" SimpleQualityReportingType"/>

<xs:complexType name="SimpleQualityReportingType">

<xs:attribute name="apn" type="xs:string" use="optional"/>

<xs:attribute name="format" type="FormatType" use="optional"/>

<xs:attribute name="samplePercentage" type="xs:double" use="optional"/> <xs:attribute name="reportingServer" type="xs:anyURI" use="required"/> <xs:attribute name="reportingInterval" type="xs:unsignedlnt" use="optional"/> </xs:complexType>

<xs:simpleType name="FormatType">

<xs:restriction base="xs:string">

<xs:enumeration value="uncompressed" />

<xs:enumeration value="gzip" />

</xs:restriction>

</xs:simpleType>

</xs: schema>

[0103] El elemento ''xmlns=''urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009:qm'V especifica un espacio de nombre separado.

[0104] Como se señaló anteriormente, la MPD de acuerdo con esta divulgación permite la definición de múltiples elementos de métricas. Si se define más de un elemento de métricas, entonces el cliente DASH (por ejemplo, el cliente DASH 212 de la FIG. 5) puede crear un informe de métricas distinto para cada elemento de métricas de la MPD. Esto es contrario a la especificación 3GP-DASH existente, que establece: "Como máximo, un elemento de métricas debe estar presente en la MPD". Además, la especificación 3GP-DASH puede modificarse de acuerdo con esta divulgación, de modo que la especificación exige que los clientes DASH generen un informe de métricas por elemento de métricas de la MPD.

[0105] La FIG. 9 es un diagrama conceptual que ilustra una modificación de ejemplo 294 a una descripción de procedimiento de entrega asociado (ADPD) de acuerdo con las técnicas de esta divulgación. De acuerdo con las técnicas de esta divulgación, la modificación 294 de la ADPD puede proporcionar:

• Un indicador 296A que indica si se deben recopilar los informes DASH QoE.

a) De forma alternativa: Los atributos DASH QoE pueden agregarse dentro de un elemento; si el elemento está presente, la recopilación de DASH QoE está activa. En este caso, no se necesita el indicador de recopilación 296A.

• Si el indicador 296A anterior se establece en verdadero, entonces se puede agregar cualquiera o todos los siguientes atributos condicionales como parte de la modificación 294:

a) Un indicador 296B que indica si DASH QoE debe comprimirse.

b) Una lista de métricas 296C para recopilar.

■ De forma alternativa, estas métricas podrían especificarse en los datos del protocolo de descripción de sesión (SDP).

c) Un indicador 296D que indica si la recopilación de DASH QoE debe sincronizarse con los informes de recepción.

d) Datos de porcentaje de muestreo DASH QoE opcionales 296E.

[0106] Además, la modificación 294 a la ADPD puede incluir un indicador (no mostrado) que indica al middleware si la información de métricas existente en la MPD debe descartarse/suprimirse.

[0107] La FIG. 10 es un diagrama conceptual que ilustra un esquema alternativo para una ADPD, de acuerdo con las técnicas de esta divulgación. En este ejemplo, el elemento de tipo de procedimiento de informe 300 de la ADPD incluye un elemento DASHQoEProcedure adicional 302. La presencia de este elemento DASHQoEProcedure adicional 302 activa la recopilación de mediciones DASH QoE, especificadas en el elemento de métricas DASH 304, como parte de los informes de recepción. El elemento de métricas DASH 304, encerrado en un círculo en la FIG. 10, podría hacerse obligatorio para garantizar que se definan algunas métricas.

[0108] Como se indicó anteriormente, puede haber un indicador, tal como el indicador de sincronización DASH QoE 306, que indica si la recopilación de DASH QoE debe sincronizarse con los informes de recepción. Los comportamientos de sincronización se pueden definir de la siguiente manera, de acuerdo con el valor del indicador de sincronización DASH QoE 306:

• Escenario 1: El indicador de sincronización DASH QoE 306 se establece en verdadero, no se incluye ningún otro porcentaje de muestreo para DASH QoE => si RR está activo, recopile la medición DASH QoE.

• Escenario 2: el indicador de sincronización DASH QoE 306 se establece en verdadero, se incluye un porcentaje de muestreo condicional 308 para DASH QoE. Esto implica que si RR está activo, el middleware debe recopilar las medidas DASH QoE de acuerdo con la probabilidad condicional indicada.

a) Ejemplo: La recepción que informa sobre el porcentaje de muestreo es 50 %; el porcentaje de muestreo DASH QoE es del 50 %, a continuación se recopila el 50 % del tiempo de los informes de recepción; cuando se recopilan informes de recepción, los informes DASH QoE se recopilan el 50 % del tiempo (la probabilidad resultante de recopilación será del 25 % para los informes de medición DASH QoE).

• Escenario 3: el indicador de sincronización se establece en falso, se incluye un porcentaje de muestreo para DASH QoE (o el valor predeterminado es 100 %). Esto implica que, independientemente de la actividad de RR, el middleware debe recopilar las medidas DASH QoE a la probabilidad indicada. En esta alternativa, los informes de recepción entregados al servidor de informes de recepción pueden incluir solo métricas DASH QoE.

[0109] A continuación se describen ejemplos de agregación de informes de recepción e informes de medición DASH QoE. En algunos ejemplos, los informes de recepción de eMBMS y los informes de medición DASH QoE se agregan en un único archivo de registro utilizando el procedimiento existente que utiliza el formato de archivo de múltiples partes/mixto.

[0110] En un primer ejemplo, el tipo de contenido de los informes de recepción puede usarse para diferenciar los dos tipos de informes, por ejemplo, texto/xml para archivos de registro de informes de recepción y texto/xml-DASH para informes DASH. De acuerdo con este primer ejemplo, el informe puede formatearse como se muestra a continuación:

POST/reporting/reception/

directory

Content-Length: xxx

Content-Type: multipart/mixed; boundary=frontier

Host: w.x.y.z:port

Connection: Keep-Alive

--frontier

Content-Type: text/xml

LOG (eMBMS RR)

--frontier

Content-Type: text/xml-DASH

LOG (DASH QoE Measurement report)

--frontier

etc.

[0111] En un segundo ejemplo, se puede usar el mismo tipo de contenido de texto/xml. El receptor puede reconocer el tipo de informe a través de la parte de la cabecera del archivo xml. De acuerdo con este segundo ejemplo, el informe puede formatearse como se muestra a continuación:

POST/reporting/reception/ directory

Content-Length: xxx

Content-Type: multipart/mixed; boundary=frontier

Host: w.x.y.z:port

Connection: Keep-Alive

--frontier

Content-Type: text/xml

LOG (eMBMS RR)

--frontier

Content-Type: text/xml

LOG (DASH QoE Measurement report)

--frontier

etc.

[0112] En otro ejemplo más, los informes de medición DASH se pueden incorporar dentro de los informes de recepción de eMBMS como nuevos elementos del esquema de informes de recepción de MBMS.

[0113] En un ejemplo, se supone que el indicador de sincronización está activado. Se puede recomendar que el indicador de sincronización siempre se establezca en 1 (es decir, activado). En algunas implementaciones, el atributo/elemento de indicador de sincronización puede no ser parte del esquema con el supuesto de que las mediciones DASH QoE siempre se recopilan en sincronización con los informes de recepción de eMBMS. La medición DASH QoE a través de la publicación del informe de recepción solo puede estar activa si el informe de recepción está activo. Con el indicador de sincronización activado, un informe de recepción agregado puede contener solo informes de recepción de eMBMS o una combinación de informes de recepción de eMBMS e informes de medición DASH QoE.

[0114] En un ejemplo, una lista de atributos de métricas imita una lista de directivas proporcionadas en la ADPD. Los elementos SchemeIDURI se pueden completar de la siguiente manera:

• Indicador de compresión (sigue la directiva de compresión ADPD).

• Porcentaje de muestreo (por ejemplo, 100 %, para recibir siempre el informe en el middleware; el middleware puede decidir si mantener el informe o descartarlo según el porcentaje de muestreo ADPD y las directivas de sincronización).

• Publicar URL (que puede apuntar al servidor HTTP de middleware, por ejemplo, el servidor proxy/local 202 de la FIG. 5).

• Los intervalos pueden ser opcionales (pueden establecerse en intervalos más pequeños para garantizar que el middleware obtenga informes más pequeños y frecuentes; los informes más frecuentes pueden proporcionar solidez en caso de fallos del cliente DASH y/o middleware).

[0115] En un ejemplo, el elemento de rango puede excluirse, de modo que siempre haya un informe DASH QoE para la sesión completa. De forma alternativa, el elemento Rango puede incluirse para especificar un período de tiempo para el cual se informarán las métricas de QoE.

[0116] La unidad de middleware (por ejemplo, la unidad de middleware 200 de la FIG. 5) puede modificar la MPD pasada al cliente DASH de modo que el cliente DASH siempre genere informes de medición DASH QoE que a continuación se publican en el middleware. Sin embargo, la unidad de middleware puede configurarse para determinar probabilísticamente si se debe informar sobre las métricas DASH QoE recibidas. Es decir, las métricas DASH QoE se pueden informar de acuerdo con la misma probabilidad especificada en la ADPD. Por lo tanto, en algunos casos, el informe DASH QoE recibido por la unidad de middleware del cliente DASH puede descartarse, sin ser comunicado al servidor (es decir, en los casos en que se determina que no se informará la recepción de acuerdo con la probabilidad ADPD).

[0117] La FIG. 11A es un diagrama conceptual que ilustra un ejemplo de rendimiento de las técnicas de esta divulgación. En este ejemplo, se supone que el indicador de sincronización descrito anteriormente está activado (es decir, tiene un valor de "verdadero"). El proceso de ejemplo puede ser el siguiente:

• Se genera un informe de medición DASH al final de cada sesión de visualización DASH.

• Según la especificación eMBMS de 3GPP, el middleware eMBMS toma una decisión de registro al final de una sesión de recepción/visualización.

• Al final de la sesión eMBMS, el middleware ha recopilado registros de informes de recepción:

a) Suponga que la decisión de registro del middleware es registrar. El middleware incorpora cualquier informe de medición DASH recibido en el informe de recepción de eMBMS utilizando el formato de archivo MIME de múltiples partes. El informe de recepción de eMBMS, en forma de archivo MIME de múltiples partes mixto, se carga utilizando el período de aleatorización especificado en la ADPD.

b) Suponga que la decisión de registro de middleware es no registrar. En este caso, el informe de recepción recopilado en el middleware se descarta. Cualquier informe recibido posteriormente del cliente DASH para la sesión también se descarta.

[0118] De forma alternativa, se pueden generar periódicamente informes de calidad DASH QoE. Esto puede proporcionar una mejor fiabilidad en caso de fallos del cliente DASH. Los informes aún pueden estar incorporados en el archivo de informe de recepción MIME de múltiples partes. Un posible problema es que la decisión de registrar aún no se ha tomado, por lo que la unidad de middleware puede tener que descartar informes en un momento posterior basándose en la decisión de registro de informes de recepción.

[0119] En un ejemplo alternativo, se supone que el indicador de sincronización está desactivado. El informe de medición DASH QoE a través de la publicación del informe de recepción puede estar activo independientemente de si la decisión es registrar para realizar el informe de recepción de eMBMS. El informe de recepción agregado puede contener solo informes de recepción de eMBMS, una combinación de informes de recepción de eMBMS e informes de medición DASH QoE, o solo informes de medición DASH QoE. Esto está en contraste con cuando el indicador de sincronización está activado donde un archivo de informe de recepción cargado siempre contiene un informe de recepción 3GPP.

[0120] Haciendo referencia nuevamente al ejemplo de la FIG. 8, la MPD puede ser el mismo cuando el indicador Sync está desactivado que cuando el indicador Sync está activado como se analizó anteriormente. Sin embargo, el cliente DASH siempre puede recopilar el informe de métricas DASH QoE, y la unidad de middleware puede determinar si se incluye el informe de métricas DASH QoE en un archivo de registro para los informes de recepción.

[0121] La FIG. 11B es un diagrama conceptual que ilustra un ejemplo de comportamiento con recepción de unidifusión/radiodifusión paralela de acuerdo con las técnicas de esta divulgación. La unidad de middleware 200 puede servir segmentos de clientes registrados eMBMS recibidos a través de eMBMS y cambiar a unidifusión (diseño MooD) si el servicio eMBMS ya no está disponible. En este caso, eMBMS puede agregar informes de recepción e informes de medición DASH QoE a lo largo de la duración de la sesión donde el servicio está activo. Se espera que la unidad de middleware 200 mantenga activa la sesión FLUTE incluso si el UE cambia a unidifusión. Es decir, la unidad de middleware 200 puede continuar recopilando el informe de recepción durante todo el período de pérdida de contenido de radiodifusión.

[0122] La FIG. 12 es un diagrama conceptual que ilustra un ejemplo de comportamiento con múltiples clientes DASH. Por ejemplo, en el caso de arquitecturas softAP, múltiples clientes DASH pueden consumir contenido eMBMS de un middleware común. En tales ejemplos, el middleware puede recopilar todos los informes de mediciones DASH durante y hasta poco después de que finalice la sesión. El middleware puede incorporar todos los informes de medición DASH en un informe de recepción común, que puede incluir la especificación de identificadores para los respectivos clientes DASH (por ejemplo, en un campo clientID en el informe de medición DASH).

[0123] La FIG. 13 es un diagrama de flujo que ilustra un ejemplo de procedimiento de acuerdo con las técnicas de esta divulgación. Los pasos del procedimiento de ejemplo de la FIG. 13 se describen como realizados por la unidad de middleware 200 y el cliente DASH 212 de la FIG. 5, respectivamente. Debe entenderse que este o un procedimiento similar podría ser realizado por otros conjuntos de middleware y clientes DASH, tales como, por ejemplo, MSDC 112', 112" y el cliente DASH 108', 108" de las FIGS. 2 y 3.

[0124] Inicialmente, la unidad de middleware 200 recibe una ADPD que incluye un elemento de informe DASH (350). Como se analizó anteriormente, el elemento de informe DASH puede incluir uno o más de un indicador que indica si se debe informar sobre las métricas DASH, las métricas DASH sobre las que informar, si los informes sobre métricas DASH se deben sincronizar con los informes de recepción MBMS y/o un porcentaje de muestreo DASH QoE si el informe de métricas DASH no está sincronizado con los informes de recepción MBMS.

[0125] Suponiendo que la ADPD indica que las métricas DASH se incluirán en los informes de recepción de MBMS, la unidad de middleware 200 puede actualizar un archivo de manifiesto, tal como un DASH MPD, para identificar la unidad de middleware 200 como el objetivo para el informe de métricas DASH (352). Por ejemplo, la unidad de middleware 200 puede especificar una dirección de localhost como la dirección de un servidor de informes de recepción de métricas DASH en el archivo de manifiesto. La unidad de middleware 200 puede enviar además el archivo de manifiesto, por ejemplo, el DASH MPD, al cliente DASH 212 (354). El cliente DASH 212 también puede recibir la MPD de la unidad de middleware 200 (356).

[0126] Posteriormente, la unidad de middleware 200 puede recibir datos multimedia (358), por ejemplo, de acuerdo con una radiodifusión o multidifusión MBMS o eMBMS. La unidad de middleware 200 puede almacenar en caché los datos multimedia recibidos (360), por ejemplo, en la memoria caché 204. A continuación, el cliente DASH 212 puede solicitar todos o una parte de los datos multimedia recibidos de la unidad de middleware 200 (362). En respuesta a la petición, la unidad de middleware 200 puede enviar los datos multimedia solicitados al cliente DASH 212 (364).

[0127] A continuación, el cliente DASH 212 puede recibir los datos multimedia (366). El cliente DASH 212 también puede informar sobre las métricas DASH para la recepción de datos multimedia a la unidad de middleware 200 (368), por ejemplo, de acuerdo con el archivo de manifiesto recibido de la unidad de middleware 200. Aunque no se muestra en la FIG. 13, debe entenderse que el cliente DASH 212 también puede procesar los datos multimedia recibidos, por ejemplo, entregando los datos multimedia recibidos a la aplicación de medios 214.

[0128] La unidad de middleware 200 puede recibir el informe de métricas DASH del cliente DASH 212 (370). Por ejemplo, la unidad de middleware 200 puede recibir un envío HTTP POST que incluye las métricas DASH del cliente DASH 212. En el ejemplo de la FIG. 13, la unidad de middleware 200 genera un informe de recepción de MBMS que incluye las métricas DASH (372). De esta manera, la unidad de middleware 200 puede generar un informe de recepción que cubra la recepción de datos multimedia de acuerdo con las directivas de informes de una ADPD recibido desde un dispositivo servidor, que también incluye informes DASH QoE recibidos del cliente DASH 212. Sin embargo, en otros ejemplos, la unidad de middleware 200 puede entregar los informes de recepción MBMS y los informes DASH QoE por separado, y en algunos casos a servidores de informes separados. En el ejemplo de la FIG. 13, sin embargo, la unidad de middleware 200 envía el informe de recepción, incluidas las métricas DASH recibidas del cliente DASH 212, a un servidor multimedia desde el que se recibieron los datos multimedia (374).

[0129] En un ejemplo, la unidad de middleware 200 asigna diferentes tipos MIME de múltiples partes al informe de recepción de MBMS y las métricas DASH, para diferenciar entre estos dos informes. Es decir, la unidad de middleware 200 puede asignar un primer valor de tipo MIME de múltiples partes al informe de recepción de MBMS y un segundo valor de tipo MIME de múltiples partes diferente a las métricas DASH. De esta manera, el servidor de informes de recepción al que la unidad de middleware 200 entrega los informes de recepción puede diferenciar el informe de recepción de MBMS de las métricas DASH utilizando los tipos MIME de múltiples partes.

[0130] De esta manera, el procedimiento de la FIG. 13 representa un ejemplo de un procedimiento, realizado por una unidad de middleware de un dispositivo cliente, que incluye recibir datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor, generar informes de recepción que cubren la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas, entregar al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente, recibir informes de calidad de experiencia (QoE) de la aplicación objetivo y proporcionar contenido de los informes de QoE a un servidor de informes de recepción. Nuevamente, en este ejemplo, los informes de recepción incluyen el contenido de los informes de QoE, pero en otros ejemplos, estos informes pueden entregarse por separado y/o a servidores de informes separados.

[0131] La FIG. 14 es un diagrama de flujo que ilustra otro procedimiento de ejemplo de acuerdo con las técnicas de esta divulgación. El procedimiento de la FIG. 14 se describe con respecto a la unidad de middleware 200, aunque debe entenderse que otros dispositivos, tales como MSDC 112', 112" de las FIGS. 2 y 3, pueden configurarse para realizar este o un procedimiento similar.

[0132] Inicialmente en este ejemplo, la unidad de middleware 200 recibe datos multimedia a través de radiodifusión o multidifusión (380), por ejemplo, de acuerdo con MBMS o eMBMS. Aunque no se muestra en la FIG. 14, debe entenderse que antes de recibir los datos multimedia, la unidad de middleware 200 puede suscribirse a un servicio MBMS o eMBMS particular. Además, la unidad de middleware 200 puede recibir una ADPD que incluye directivas de informes, tales como cuándo generar informes de recepción, qué información incluir en los informes de recepción y similares. Además, la ADPD puede, de acuerdo con las técnicas de esta divulgación, incluir datos que indiquen si los informes DASH QoE deben incluirse en los informes de recepción o enviarse por separado, y si los informes DASH QoE deben enviarse por separado, una dirección de red de un servidor de informes de métricas DASH QoE.

[0133] A continuación, la unidad de middleware 200, en este ejemplo, genera un informe de recepción que cubre la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas (382) de la ADPD. En general, los informes de recepción se envían después de un tiempo de retroceso y un período de aleatorización. Este retardo asegurará que el middleware pueda recibir los informes de mediciones DASH QoE generados por el cliente DASH. En cualquier caso, debe entenderse que la publicación del informe de recepción no necesita realizarse inmediatamente después de recibir los datos de los medios, sino que podría retardarse, si es necesario, hasta después de recibir un informe de métricas DASH QoE, como se analiza a continuación.

[0134] La unidad de middleware 200 también entrega los datos multimedia a una aplicación objetivo (384), por ejemplo, un cliente DASH, tal como el cliente DASH 212 de la FIG. 5. En particular, la unidad de middleware 200 puede almacenar en caché los datos multimedia recibidos, por ejemplo, en la memoria caché 204, y esperar una petición de los datos multimedia, o partes de los mismos, del cliente DASH 212. La unidad de middleware 200 puede enviar los datos multimedia solicitados al cliente DASH 212 en respuesta a tales peticiones. Las peticiones pueden comprender HTTP GET o peticiones GET parciales (es decir, peticiones GET que especifican rangos de bytes de una URL objetivo). Además, antes de entregar los datos multimedia al cliente DASH 212, la unidad de middleware 200 puede enviar un archivo de manifiesto, como una MPD, al cliente DASH 212. El archivo de manifiesto puede indicar que los informes de métricas DASH QoE se entregarán a la unidad de middleware 200, así como otra información de archivo de manifiesto, como las URL de los archivos multimedia, las horas del reloj de pared que indican cuándo estarán disponibles los archivos multimedia, y similares. Además, la unidad de middleware 200 puede modificar el archivo de manifiesto para identificar la unidad de middleware 200 como el servidor al que el cliente DASH 212 debe enviar informes de métricas DASH QoE.

[0135] En este ejemplo, después de entregar los datos multimedia a la aplicación objetivo, la unidad de middleware 200 recibe un informe de QoE de la aplicación objetivo (386). Por ejemplo, la unidad de middleware 200 puede recibir un informe DASH QoE del cliente DASH 212. El informe DASH QoE puede incluir datos que representan valores para varias métricas DASH solicitadas, como rendimiento medio, retardo inicial de reproducción e información MPD, además de una lista de transacciones de petición/respuesta HTTP, una lista de eventos de cambio de representación, un nivel de memoria intermedia, una lista de conexiones TCP, una lista de eventos de cambio de representación, un nivel de memoria intermedia y/o una lista de reproducción.

[0136] A continuación, la unidad de middleware 200 puede proporcionar el contenido del informe DASH QoE al servidor de informes de recepción (388), por ejemplo, según lo indicado por la ADPD. En un ejemplo, la unidad de middleware 200 puede entregar el informe de recepción MBMS o eMBMS y el contenido del informe DASH QoE por separado. En otros ejemplos, la unidad de middleware 200 puede entregar el informe de recepción MBMS/eMBMS y el contenido del informe DASH QoE juntos, por ejemplo, en un solo documento (por ejemplo, un solo archivo u otro conjunto de datos). En algunos ejemplos, cuando estos informes se entregan juntos, la unidad de middleware 200 puede identificar los informes utilizando distintos tipos MIME de múltiples partes, por ejemplo, un primer tipo MIME de múltiples partes para el informe de recepción MBMS y un segundo tipo MIME de múltiples partes diferente para el informe DASH QoE.

[0137] De esta manera, el procedimiento de la FIG. 14 representa un ejemplo de un procedimiento, realizado por una unidad de middleware de un dispositivo cliente, que incluye recibir datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor, generar informes de recepción que cubren la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas, entregar al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente, recibir informes de calidad de experiencia (QoE) de la aplicación objetivo y proporcionar contenido de los informes de QoE a un servidor de informes de recepción. Nuevamente, en este ejemplo, los informes de recepción incluyen el contenido de los informes de QoE, pero en otros ejemplos, estos informes pueden entregarse por separado y/o a servidores de informes separados. De forma alternativa, la unidad de middleware 200 puede usar cabeceras XML distintas para distinguir el informe de recepción MBMS del informe DASH QoE.

[0138] La FIG. 15 es un diagrama de bloques que ilustra ejemplos de un dispositivo servidor 400 y un dispositivo cliente 410 configurados de acuerdo con las técnicas de esta divulgación. El dispositivo servidor 400 puede corresponder al servidor de aprovisionamiento y BMSC 104 de las FIGS. 2 o 3, al dispositivo servidor 160, y/o al dispositivo de preparación de contenido 140 de la FIG. 4. El dispositivo cliente 410 puede corresponder al UE 106 de las FIGS. 2 o 3 y/o al dispositivo cliente 180 de la FIG. 4. Por lo tanto, el dispositivo cliente 410 representa un ejemplo de equipo de usuario (UE), como un ordenador personal, un dispositivo móvil como un teléfono celular, una tablet o un ordenador portátil, un descodificador o similar.

[0139] En este ejemplo, el dispositivo cliente 410 incluye el cliente DASH 412 y la unidad de middleware 414. El cliente DASH 412 puede corresponder al cliente DASH 108' de la FIG. 2, al cliente dAs H 108" de la FIG. 3, o al cliente DASH 212 de la unidad de recuperación 192 en la FIG. 5. La unidad de middleware 414 puede corresponder al MSDC 112' de la FIG. 2, al MSDC 112" de la FIG. 3, o al middleware eMBMS 200 de la unidad de recuperación 192 en la FIG. 5. El cliente DASH 412 puede representar, por ejemplo, un complemento basado en software para un navegador web ejecutado por el dispositivo cliente 410.

[0140] La unidad de middleware 414 y el cliente DASH 412 pueden implementarse en hardware, software, firmware o una combinación de los mismos. Cuando se implementa en software o firmware, se espera que también se proporcione el hardware necesario, como medios legibles por ordenador y una o más unidades de procesamiento. En general, las unidades de procesamiento se implementan utilizando circuitos lógicos digitales fijos o programables, como uno o más ASIC, DSP, FPGA, microprocesadores o similares.

[0141] De acuerdo con las técnicas de esta divulgación, la unidad de middleware 414 puede configurarse para recibir datos multimedia a través de radiodifusión o multidifusión desde el dispositivo servidor 400, generar informes de recepción que cubran la recepción de los datos multimedia de acuerdo con las directivas de informes recibidas, entregar al menos parte de los datos multimedia al cliente DASH 412 (que representa un ejemplo de una aplicación objetivo en este ejemplo) del dispositivo cliente 410, recibir informes de calidad de experiencia (QoE) del cliente DASH 412 y proporcionar el contenido de los informes QoE a un servidor de informes de recepción. El servidor de informes de recepción puede corresponder al dispositivo servidor 400, o un dispositivo servidor separado (no mostrado).

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

[0143] A modo de ejemplo, y no de limitación, dichos medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, memoria flash o cualquier otro medio que se pueda usar para almacenar un código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. Además, cualquier conexión recibe apropiadamente la denominación de medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde un sitio web, un servidor u otra fuente remota usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital (DSL) o unas tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas están incluidos en la definición de medio. Sin embargo, se deberá entender que los medios de almacenamiento legibles por ordenador y los medios de almacenamiento de datos no incluyen conexiones, ondas portadoras, señales u otros medios transitorios, sino que, en cambio, están dirigidos a medios de almacenamiento no transitorio tangibles. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen habitualmente los datos magnéticamente, mientras que otros discos reproducen los datos ópticamente con láseres. Las combinaciones de lo anterior también se deben incluir dentro del alcance de los medios legibles por ordenador.

[0144] Las instrucciones se pueden ejecutar por uno o más procesadores, tales como uno o más procesadores digitales de señales (DSP), microprocesadores de propósito general, circuitos integrados específicos de la aplicación (ASIC), matrices lógicas programables in situ (FPGA) u otros circuitos lógicos discretos o integrados equivalentes. En consecuencia, el término "procesador", como se usa en el presente documento, se puede referir a cualquiera de las estructuras anteriores o a cualquier otra estructura adecuada para la implementación de las técnicas descritas en el presente documento. Además, en algunos aspectos, la funcionalidad descrita en el presente documento se puede proporcionar dentro de módulos de hardware y/o de software dedicados configurados para codificar y descodificar, o incorporar en un códec combinado. Asimismo, las técnicas se podrían implementar por completo en uno o más circuitos o elementos lógicos.

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

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

Claims (15)

REIVINDICACIONES

1. Un procedimiento para generar informes de medición de calidad de experiencia, QoE, DASH, con el procedimiento que comprende, mediante una unidad de middleware de un dispositivo cliente MBMS:

recibir (380) datos multimedia a través de radiodifusión o multidifusión desde un dispositivo servidor; generar (382) informes de recepción de MBMS que cubren la recepción de los datos de los medios de acuerdo con las directivas de informes recibidas;

entregar (384) al menos parte de los datos multimedia a una aplicación objetivo del dispositivo cliente DASH; recibir (386) informes DASH QoE que incluyen métricas de QoE de la aplicación objetivo; y proporcionar contenidos (388) del informe de recepción MBMS y los informes DASH QoE a un servidor de informes de recepción.

2. El procedimiento según la reivindicación 1, donde el servidor de informes de recepción es el mismo que el dispositivo servidor.

3. El procedimiento según la reivindicación 1, que comprende además señalar, a la aplicación objetivo, una dirección de localhost del dispositivo cliente como una dirección de destino a la que la aplicación objetivo debe enviar las métricas de QoE.

4. El procedimiento según la reivindicación 3, en el que recibir las métricas de QoE comprende recibir un envío HTTP POST del informe de medición de QoE a la dirección de localhost especificada desde la aplicación objetivo.

5. El procedimiento según la reivindicación 1, que comprende además enviar, a la aplicación objetivo, un archivo de manifiesto para los datos multimedia que incluye datos que indican las métricas de QoE que se comunicarán.

6. El procedimiento según la reivindicación 5, que comprende además modificar una versión original del archivo de manifiesto para que los datos multimedia incluyan los datos que indican las métricas de QoE que se proporcionarán al dispositivo servidor.

7. El procedimiento según la reivindicación 6, que comprende además recibir los datos que indican las métricas de QoE que se proporcionarán al dispositivo servidor desde el dispositivo servidor.

8. El procedimiento según la reivindicación 5, en el que el archivo de manifiesto incluye una pluralidad de elementos de métricas, con cada uno de la pluralidad de elementos de métricas que incluye métricas de atributo respectivas que se proporcionarán al dispositivo servidor.

9. El procedimiento según la reivindicación 1, que comprende además recibir datos que indican que se debe informar sobre las métricas de QoE al servidor de informes de recepción.

10. El procedimiento según la reivindicación 9, en el que recibir los datos comprende además recibir datos que indican al menos uno de si las métricas de QoE deben comprimirse, la lista de métricas de QoE sobre las que informar, si los informes de métricas de QoE deben sincronizarse con los informes de recepción para la radiodifusión o multidifusión, o un porcentaje de muestreo DASH QoE representativo de una probabilidad condicional para la cual se debe informar sobre las métricas de QoE.

11. El procedimiento según la reivindicación 9, en el que recibir los datos comprende recibir los datos en una descripción de procedimiento de entrega asociado, ADPD.

12. El procedimiento según la reivindicación 1, en el que proporcionar las métricas de QoE comprende enviar un único documento al dispositivo servidor, con el documento único que incluye las métricas de QoE y los datos de informes de recepción, y en el que enviar el único documento comprende:

establecer un primer valor para un tipo MIME de múltiples partes de las métricas de QoE en el documento único; y

establecer un segundo valor diferente para el tipo MIME de múltiples partes de los datos de informes de recepción en el documento único, o en el que proporcionar las métricas de QoE comprende enviar un único documento al dispositivo servidor, con el documento único que incluye las métricas de QoE y los datos de informes de recepción, y en el que el envío del documento único comprende:

establecer una primera cabecera de lenguaje de marcado extensible, XML, de las métricas de QoE en el documento único; y

establecer una segunda cabecera XML diferente de los datos de informes de recepción en el documento único, o en el que la aplicación objetivo comprende una primera aplicación objetivo, en el que recibir las métricas de QoE comprende recibir un primer conjunto de métricas de QoE de la primera aplicación objetivo, con el procedimiento adicional que comprende:

recibir una pluralidad de métricas de QoE, incluido el primer conjunto de métricas de QoE, de una pluralidad de aplicaciones objetivo, incluida la primera aplicación objetivo,

en el que proporcionar las métricas de QoE comprende enviar un informe que incluye la pluralidad de métricas de QoE al servidor de informes de recepción.

13. El procedimiento según la reivindicación 1, que comprende además:

enviar instrucciones a la aplicación objetivo para informar sobre las métricas de QoE para todos los datos recibidos; y

descartar al menos algunos de los informes basándose en una probabilidad de recopilación.

14. Un dispositivo cliente para generar informes de medición de calidad, con el dispositivo que comprende:

medios dispuestos para realizar las etapas de cualquiera de las reivindicaciones 1 a 13.

15. Un medio de almacenamiento legible por ordenador que tiene instrucciones almacenadas en el mismo que, al ejecutarse, hacen que un procesador de un dispositivo cliente realice los pasos de cualquiera de las reivindicaciones 1 a 13.