ES2878022T3 - Procedimiento y aparato para transmisión de paquetes que soporta descarga y streaming - Google Patents

Abstract

Un procedimiento de transmisión de contenidos de medios usando un protocolo de transporte de medios de MPEG, MMTP, comprendiendo el procedimiento: transmitir un paquete (900) de transporte que incluye un encabezado de paquete de MMTP, un encabezado de carga útil, y datos de carga útil que comprenden datos generados a partir de la al menos una MPU, en el que el encabezado de paquete de MMTP comprende información (904) que indica un tipo de los datos en los datos de carga útil de entre una pluralidad de tipos de carga útil, y en el que la pluralidad de tipos de carga útil comprende un primer tipo de carga útil que indica que los datos de carga útil incluyen datos de fragmentos con aviso de medios de una unidad de procesamiento de medios, MPU, que comprende datos de medios de los contenidos de medios, un segundo tipo de carga útil que indica que los datos de carga útil incluyen al menos un mensaje de señalización, un tercer tipo de carga útil que indica que los datos de carga útil incluyen un objeto genérico, tal como una MPU completa o un objeto de otro tipo, y un cuarto tipo de carga útil que indica que los datos de carga útil incluyen un símbolo de reparación.

Description

DESCRIPCIÓN

Procedimiento y aparato para transmisión de paquetes que soporta descarga y streaming

Campo técnico

La presente solicitud se refiere en general a la transmisión de datos de medios y, más específicamente, a un protocolo de transmisión de paquetes que soporta tanto descarga como streaming.

Técnica antecedente

El transporte de medios de Grupo de Expertos en Imágenes en Movimiento (MPEG) (MMT) es un estándar o formato contenedor digital que especifica tecnologías para el suministro de datos de medios codificados para servicio multimedia sobre entornos de red de IP (Protocolo de Internet) heterogéneos. Los datos de medios codificados suministrados incluyen tanto datos de medios audiovisuales que requieren decodificación sincronizada y presentación de una unidad específica de datos en un tiempo designado, a saber datos temporizados, como otros tipos de datos que se decodifican y presentan en un tiempo arbitrario en base al contexto de servicio o interacción por el usuario, a saber datos no temporizados.

Se ha introducido un nuevo modo de paquetización, un modo de Suministro de Archivos Genéricos (GFD), en la función de suministro de MMT. Sin embargo, la integración de ese modo en MMTP y con los modos de carga útil existentes no se ha optimizado.

Por consiguiente, hay una necesidad de aparatos y procedimientos mejorados para la transmisión de datos de medios.

El documento US 2013/094545 se refiere a un aparato y un procedimiento para transmitir datos multimedia en una red híbrida aplicando un MMT.

""Text of ISO/IEC DIS 23008-1 MPEG Media Transport", 104. MPEG MEETING;22-4-2013 - 26-4-2013: INCHEON; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11) no. N13516, 10 de mayo de 2013 (2013-05­ 10) se refiere a una memoria descriptiva de MMT así como a una memoria descriptiva de un protocolo de MMT.

Divulgación de la invención

Problema técnico

La invención se presenta en el conjunto adjunto de reivindicaciones; los ejemplos adicionales denominados realizaciones en la descripción son ejemplos ilustrativos.

Antes de emprender la DESCRIPCIÓN DETALLADA a continuación, puede ser ventajoso establecer definiciones de ciertas palabras y expresiones usadas a lo largo de este documento de patente: los términos "incluyen" y "comprenden", así como derivados de los mismos, significan inclusión sin limitación; el término "o", es inclusivo, que significa y/o; las expresiones "asociado con" y "asociado con el mismo", así como derivados de los mismos, pueden significar incluir, estar incluido dentro de, interconectarse con, contener, estar contenido dentro de, conectarse a o con, acoplarse a o con, ser comunicable con, cooperar con, intercalar, yuxtaponer, estar próximo a, estar vinculado a o con, tener, tener una propiedad de, o similar; y el término "controlador" significa cualquier dispositivo, sistema o parte del mismo que controla al menos una operación, tal dispositivo puede ser implementado en hardware, firmware o software, o alguna combinación de al menos dos de los mismos. Debe anotarse que la funcionalidad asociada con cualquier controlador particular puede estar centralizada o distribuida, ya sea de manera local o remota. Las definiciones para ciertas palabras y expresiones se proporcionan a lo largo de este documento de patente, los expertos normales en la técnica deben entender que en muchos, si no en la mayoría de los casos, tales definiciones se aplican a usos anteriores, así como futuros de tales palabras y expresiones definidas.

Breve descripción de los dibujos

Para un entendimiento más completo de la presente divulgación y sus ventajas, se hace ahora referencia a la siguiente descripción tomada en conjunto con los dibujos adjuntos, en los cuales números de referencia similares representan partes similares:

La Figura 1 ilustra un ejemplo de un sistema de transmisión en el cual se pueden implementar diversas realizaciones de la presente divulgación;

La Figura 2 ilustra un Paquete de MMT y la estructura lógica del Paquete de MMT de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 3 ilustra un ejemplo de temporización proporcionada por un documento de información de presentación para presentación de MPUs de diferentes recursos de acuerdo con una realización ilustrativa de la presente divulgación;

La Figura 4 ilustra una estructura ejemplar para un encabezado de carga útil en modo de streaming de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 5 ilustra una estructura ejemplar para un encabezado de unidad de fragmentos de medios (MFU) temporizado de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 6 ilustra una estructura ejemplar para un encabezado de MFU no temporizado de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 7 ilustra una estructura ejemplar para un encabezado de mensaje de señalización de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 8 ilustra una estructura ejemplar para una estructura de paquetes en modo de GFD de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 9 ilustra una estructura ejemplar para un paquete de MMTP de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 10 ilustra una estructura ejemplar para extensión de encabezado de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 11 ilustra un diagrama ejemplar de paquetización de datos de medios temporizados de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 12 ilustra un diagrama ejemplar de paquetización de datos de medios no temporizados de acuerdo con diversas realizaciones de la presente divulgación;

La Figura 13 ilustra un proceso para procesar un paquete de transporte en una entidad receptora de acuerdo con una realización ilustrativa de la presente divulgación;

La Figura 14 ilustra un proceso para generar un paquete de transporte en una entidad emisora de acuerdo con una realización ilustrativa de la presente divulgación; y

La Figura 15 ilustra un dispositivo electrónico de ejemplo en el cual se pueden implementar diversas realizaciones de la presente divulgación.

Modo de la invención

Las Figuras 1 hasta 15, discutidas a continuación, y las diversas realizaciones usadas para describir los principios de la presente divulgación en este documento de patente son solo a modo de ilustración y no deben interpretarse de ninguna forma para limitar el ámbito de la divulgación. Los expertos en la técnica entenderán que los principios de la presente divulgación pueden implementarse en cualquier sistema o dispositivo dispuesto de manera adecuada.

La codificación de MMT y suministro de medios se discuten en el siguiente documento y descripción de estándares: MPEG-H Systems, Text of ISO/IEC 2nd CD 23008-1 MPEG Media Transport, que se incorpora por la presente en la presente divulgación como si se estableciera completamente en la presente memoria. MMT define tres áreas funcionales que incluyen encapsulación, suministro, y señalización. El área funcional de encapsulación define la estructura lógica de contenido de medios, el paquete de MMT, y las unidades de datos de formato que van a ser procesadas por una entidad compatible con m Mt . El paquete de MMT especifica componentes que incluyen contenido de medios y la relación entre el contenido de medios para proporcionar información necesaria para el suministro adaptable. El formato de las unidades de datos se define para encapsular los medios codificados ya sea para que se almacenen o transporten como una carga útil de un protocolo de suministro, y se conviertan fácilmente entre almacenamiento y transporte. El área funcional de suministro define el protocolo de capa de aplicación y el formato de la carga útil. El protocolo de capa de aplicación proporciona características mejoradas, incluyendo multiplexación, para el suministro del paquete de MMT en comparación con los protocolos de capa de aplicación convencionales para el suministro de multimedia. El formato de carga útil se define para transportar datos de medios codificados que son agnósticos del tipo de medio o procedimiento de codificación específico. El área funcional de señalización define el formato de mensajes para gestionar el suministro y consumo de paquetes de MMT. Los mensajes para gestión de consumo se usan para señalizar la estructura del paquete de MMT y los mensajes para la gestión de suministro se usan para señalizar la estructura de formato de carga útil y configuración del protocolo.

MMT define una nueva estructura para el suministro de multimedia continua en tiempo tal como audio, vídeo y otro contenido estático tales como artilugios, archivos etc. MMT especifica un protocolo (es decir, MMTP) para el suministro de un paquete de MMT a una entidad receptora. El MMTP señaliza el tiempo de transmisión del paquete de MMTP como parte del encabezado de protocolo. Este tiempo habilita a la entidad receptora realizar la eliminación de variación rápida al examinar el tiempo de transmisión y tiempo de recepción de cada paquete de MMT entrante.

Realizaciones de la presente divulgación reconocen que se ha introducido un nuevo modo de paquetización, el modo de GFD, en la función de suministro de MMT. GFD habilita la transmisión de cualquier archivo genérico. Realizaciones de la presente divulgación reconocen que actualmente MMT define otros 4 modos de paquetización: el modo de unidad de procesamiento de medios (MPU), el modo de Fragmento de MPU, modo de Mensaje de Señalización, y modo de corrección de errores de reenvío (FEC). El modo de MPU suministra una MPU completa y deja la fragmentación a la capa de transporte. El modo de Fragmento de MPU está optimizado para el suministro de MPU y la paquetización se realiza de una manera con aviso de medios, informando al cliente receptor sobre el tipo y características de fragmento de MPU. Los modos de FEC y señalización son para suministrar paquetes de reparación de FEC y mensajes de señalización, respectivamente. El paquete de reparación de FEC transporta conjunto segmentado de flujo de reparación de FEC que se puede usar para recuperar uno o más paquetes de origen perdidos.

Realización de la presente divulgación reconocen que el modo de MPU puede verse como un subcaso del modo de GFD, dado que la MPU completa se suministra como un objeto y sin ninguna paquetización con aviso de medios. La información sobre la MPU puede ser suministrada completamente como parte de los metadatos del objeto en el modo de GFD. Por consiguiente, realizaciones de la presente divulgación proporcionan la eliminación del modo de MPU y renombrar el modo de Fragmento de MPU al modo de MPU para desambiguación. Como resultado, una MPU puede ser suministrada ya sea como un objeto genérico usando el modo de GFD o como un conjunto de fragmentos independientes usando este modo de MPU.

Realizaciones de la presente divulgación reconocen que actualmente el formato de carga útil de un paquete se divide en múltiples capas. Se necesita un encabezado de carga útil principal para cada formato de carga útil y tiene un mapeo uno a uno con el encabezado de protocolo de MMTP. Realizaciones de la presente divulgación reconocen fusionar este encabezado de carga útil genérico con el encabezado de protocolo de MMTP y hacer que los encabezados de carga útil restantes dependan del tipo de carga útil. Por ejemplo, la fragmentación y agregación también son dependientes del tipo de carga útil, ya que algunos tipos de carga útil, por ejemplo FEC y GFD, no requieren agregación ni fragmentación. Realizaciones de la presente divulgación proporcionan además un tipo de carga útil para los mensajes de señalización que habilitan una fácil identificación de mensajes de señalización y actualizaciones. El formato de carga útil también habilitará la agregación y fragmentación de mensajes de señalización.

La Figura 1 ilustra un ejemplo de un sistema 100 de transmisión en el cual se pueden implementar diversas realizaciones de la presente divulgación. En la realización ilustrada, el sistema 100 inalámbrico incluye una entidad 101 emisora, una red 105, entidades receptoras, 110-116, puntos de transmisión inalámbrica (por ejemplo, un Nodo B Evolucionado (eNB), Nodo B), tales como una estación base (BS) 102, estación base (BS) 103, y otras estaciones base o estaciones de retransmisión similares (no se muestran). La entidad 101 emisora está en comunicación con la estación 102 base y estación 103 base a través de la red 105 que puede ser, por ejemplo, el Internet, una red de radiodifusión de medios, o un sistema de comunicación basado en IP. Las entidades 110-116 receptoras están en comunicación con la entidad 101 emisora a través de la red 105 y/o estaciones 102 y 103 base. Por ejemplo, las entidades 110-116 receptoras pueden recibir datos de medios para descargar y hacer streaming desde la entidad 101 emisora. En diversas realizaciones, la entidad 101 emisora puede generar y enviar paquetes de MMTP y una o más de las entidades 110-116 receptoras pueden recibir y procesar los paquetes de MMTP de acuerdo con las enseñanzas de la presente divulgación.

La estación 102 base proporciona acceso inalámbrico (a través de estación 101 base) a la red 105 a una primera pluralidad de entidades receptoras (por ejemplo, equipo de usuario, teléfono móvil, estación móvil, estación de suscriptor) dentro del área 120 de cobertura de la estación 102 base. La primera pluralidad de entidades receptoras incluyen el equipo 111 de usuario, que puede estar ubicado en un pequeño negocio (SB); equipo 112 de usuario, que puede estar ubicado en una empresa (E); equipo 113 de usuario, que puede estar ubicado en un punto de conexión WiFi (HS); equipo 114 de usuario, que puede estar ubicado en una primera residencia (R); equipo 115 de usuario, que puede estar ubicado en una segunda residencia (R); y equipo 116 de usuario, que puede ser un dispositivo móvil (M), tal como un teléfono celular, un ordenador portable con capacidad para comunicación inalámbrica, un PDA con capacidad para comunicación inalámbrica, un ordenador tipo tableta, o similar.

La estación 103 base proporciona acceso inalámbrico a la red 105 a una segunda pluralidad de equipos de usuario dentro del área 125 de cobertura de la estación 103 base. La segunda pluralidad de equipos de usuario incluye equipo 115 de usuario y equipo 116 de usuario. En una realización ejemplar, las estaciones 101-103 base pueden comunicarse entre sí y con el equipo 111-116 de usuario usando técnicas de OFDM u OFDMA.

Aunque solo se representan seis equipos de usuario en la Figura 1, se entiende que el sistema 100 puede proporcionar acceso inalámbrico de banda ancha y de red a equipo de usuario adicional. Se nota que el equipo 115 de usuario y equipo 116 de usuario están ubicados en los bordes tanto del área 120 de cobertura como del área 125 de cobertura. El equipo 115 de usuario y el equipo 116 de usuario cada uno se comunica tanto con la estación 102 base como con estación 103 base y se puede decir que están operando en modo de traspaso, como conocen los expertos en la técnica.

El equipo 111-116 de usuario puede acceder a voz de datos de medios, datos, vídeo, videoconferencia, y/u otros servicios a través de la red 105. En una realización ejemplar, uno o más de los equipos 111-116 de usuario pueden estar asociados con un punto de acceso (AP) de una WLAN WiFi. El equipo 116 de usuario puede ser cualquiera de un número de dispositivos móviles, incluyendo un ordenador portable con capacidad inalámbrica, asistente de datos personales, ordenador portátil, dispositivo de mano, u otro dispositivo con capacidad inalámbrica. El equipo 114 y 115 de usuario puede ser, por ejemplo, un ordenador personal (PC) con capacidad inalámbrica, un ordenador portable, una pasarela, u otro dispositivo.

La Figura 2 ilustra un Paquete 200 de MMT y la estructura lógica del paquete 200 de MMT de acuerdo con diversas realizaciones de la presente divulgación. Como se ilustra, el paquete 200 de MMT incluye la presentación de uno o más documentos 205 de información y uno o más recursos 210 que pueden tener características 215 de transporte asociadas. Un recurso 210 es una colección de una o más unidades de procesamiento de medios (MPUs) 220 que comparten una misma identificación (ID) de recurso. Un recurso 210 incluye datos de medios codificados tales como audio o vídeo, o una página web. Los datos de medios pueden ser ya sea temporizados o no temporizados.

Los documentos 205 de información de presentación (PI) incluyen información que especifica la relación espacial y temporal entre los recursos 210 para consumo. La combinación de lenguaje de marcado de hipertexto (HTML) y documentos de información de composición (CI) son ejemplos de documentos 205 de PI. Un documento 205 de PI también se puede usar para determinar un orden de suministro de recursos 210 en un paquete 200. Se suministra un documento 205 de PI ya sea como uno o más mensajes o como un documento completo. En el caso de suministro de radiodifusión, los proveedores de servicios pueden hacer circular los documentos 205 de información de presentación de manera secuencial y determinar una frecuencia a la cual va a ser realizada la circulación.

Un recurso 210 es cualquier dato multimedia que va a ser usado para construir una presentación multimedia. Como se discutió anteriormente, un recurso 210 es una agrupación lógica de MPUs que comparten una misma ID de recurso para transportar datos de medios codificados. Los datos de medios codificados de un recurso 210 pueden ser ya sea datos temporizados o datos no temporizados. Los datos temporizados son datos de medios codificados que tienen una línea de tiempo inherente y pueden requerir una decodificación y presentación sincronizadas de las unidades de datos en un momento designado. Los datos no temporizados son otros tipos de datos que se pueden decodificar en un momento arbitrario en base al contexto de un servicio o indicaciones del usuario.

Las MPUs 220 de un único recurso 210 tienen ya sea medios temporizados o no temporizados. Dos MPUs 220 del mismo recurso 210 que transportan datos de medios temporizados pueden no tener superposición en su tiempo de presentación. En ausencia de una indicación de presentación, las MPUs 220 del mismo recurso 210 pueden reproducirse secuencialmente de acuerdo con sus números de secuencia. Cualquier tipo de datos de medios que puedan ser consumidos individualmente por el motor de presentación de una entidad receptora de MMT puede considerarse como un recurso 210 individual. Ejemplos de tipos de datos de medios que pueden considerarse como un recurso 210 individual son tipos de datos de medios de audio, vídeo, o una página web.

Una MPU 220 es un ítem de datos de medios que puede ser procesado por una entidad de MMT y consumido por un motor de presentación independientemente de otras MPUs 220. El procesamiento de una MPU 220 por una entidad de MMT incluye encapsulación/desencapsulación y paquetización/despaquetización. El consumo de una MPU 220 incluye procesamiento de medios (por ejemplo, codificación/decodificación) y presentación. Para propósitos de paquetización, una MPU 220 puede estar fragmentada en unidades de datos que pueden ser más pequeñas que una unidad de acceso (AU). La sintaxis y semántica de MPU no son dependientes del tipo de datos de medios transportados en la MPU.

Una MPU 220 puede incluir una porción de datos formateados de acuerdo con otros estándares, por ejemplo codificación de vídeo avanzada (AVC) MPEG-4 o flujo de transporte (TS) MPEG-2. Para cualquier recurso con identificación de recurso (asset_id) 'X' que dependa de un recurso con asset_id 'Y', la m-ésima MPU del recurso con asset_id 'X' y la n-ésima MPU del recurso con asset_id 'Y' no se superponen siempre que 'm' no sea igual a 'n', (es decir ninguna muestra en la m-ésima MPU de Recurso con asset_id 'X' está dentro del intervalo de tiempo definido por los límites de muestra de la n-ésima MPU de Recurso con asset_id 'Y'. Adicionalmente, si la casilla de índice de segmento ('sidx') está presente, los intervalos de medios definidos por la casilla 'sidx' no se superponen, (es decir ninguna muestra de medios en el k-ésimo intervalo de medios (definido por la casilla 'sidx') en una MPU está dentro del intervalo de tiempo definido por los límites de muestra del j-ésimo intervalo de tiempo de medios (definido por la casilla 'sidx') para 'j' diferente de 'k'. En ausencia de una casilla 'sidx', la concatenación de la j-ésima MPU de la MPU de Recurso con asset_id 'Y' con la j-ésima MPU del recurso con asset_id 'X' sin metadatos de MPU, da como resultado una MPU válida. Cuando una casilla 'sidx' está presente la concatenación del k-ésimo intervalo de medios (definido por la casilla 'sidx') de la j-ésima MPU de recurso con asset_id 'Y' con el k-ésimo intervalo de medios (definido por la casilla 'sidx') de la j- ésima MPU de recurso con asset_id 'X' después de los metadatos de la MPU con asset_id 'Y' da como resultado una MPU válida.

Una única MPU incluye un número entero de AUs o datos no temporizados. En otras palabras, para datos temporizados, una única AU no se fragmenta en múltiples MPUs. Para datos no temporizados, una única MPU incluye uno o más ítems de datos no temporizados para ser consumidos por el motor de presentación. Una MPU se identifica mediante una asset_id asociada y un número de secuencia.

Una MPU que incluye medios temporizados incluye al menos un punto de acceso de flujo (SAP) como se define en el Anexo I de ISO/IEC 14496-12, que se incorpora por referencia en la presente memoria. La primera unidad de acceso de una MPU es un SAP para procesamiento por una entidad de MMT. Para los medios temporizados, esto implica que el orden de decodificación de la primera AU en la carga útil de MPU es '0'. Para la MPU que incluye datos formateados de acuerdo con otros estándares, la carga útil de MPU inicia con la información necesaria para el procesamiento de tal formato. Por ejemplo, si una MPU incluye datos de vídeo, la carga útil de MPU incluye uno o más grupos de imágenes y la información de configuración de decodificador requerida para procesarlas. En otro ejemplo, si una MPU incluye paquetes de TS MPEG-2, la carga útil de MPU puede iniciar con paquetes de TS incluyendo la tabla de asociación de programas (PAT), tabla de mapa de programas (PMT) para los paquetes de TS restantes o subsecuentes. Para los datos de medios temporizados, la duración de presentación, el orden de decodificación, y el orden de presentación de cada AU se señalizan como parte de los metadatos de MPU. La MPU no tiene un tiempo de presentación inicial. El tiempo de presentación de la primera AU en una MPU se describe por el documento de PI. El documento de PI incluye información que especifica el tiempo de presentación inicial de cada MPU.

La Figura 3 ilustra un ejemplo de temporización proporcionada por un documento de PI para la presentación de MPUs de diferentes recursos de acuerdo con una realización ilustrativa de la presente divulgación. En este ejemplo ilustrativo, el documento de PI especifica que la entidad receptora de MMT presentará MPU #1 de Recurso #1 y de Recurso #2 simultáneamente. En un momento posterior, está programada MPU #1 de Recurso #3 para ser presentada. Finalmente, la MPU #2 de Recurso #1 y Recurso #2 van a ser presentadas en sincronización. El tiempo de presentación especificado para una MPU define el tiempo de presentación de la primera AU de esa MPU. Una MPU que contiene datos de medios no temporizados puede designar un ítem de datos como el punto de entrada.

Las MFUs habilitan la fragmentación con aviso de medios de una MPU con propósitos de transporte. Esto permite que una entidad emisora de MMT realice la fragmentación de MPUs con consideración del consumo en el extremo receptor. Una MFU incluye una unidad de datos de medios, que puede ser más pequeña que una AU para datos de medios temporizados, y los datos de medios incluidos puede ser procesados por el decodificador de medios. Una MFU incluye un encabezado de MFU que incluye información sobre los límites de los datos de medios transportados. La sintaxis y semántica de MFU son independientes del tipo de datos de medios transportados en la MFU. Si el tamaño de una MFU es mayor que el tamaño de una trama de capa de enlace, una MFU puede ser fragmentada en múltiples tramas de capa de enlace. Una MFU incluye un identificador para distinguir una MFU de otra en la misma MPU así como información de relación entre las MFUs dentro de una única AU de una manera que es agnóstica al formato de medios codificado. La relación de dependencia entre las MFUs en una única AU se describe como son las prioridades relativas de MFUs. La información puede ser usada por capas de suministro subyacentes para suministro mejorado. Por ejemplo, la capa de suministro puede omitir el suministro de MFUs descartables para soportar QoS bajo ciertas circunstancias, por ejemplo ancho de banda insuficiente en ciertos enlaces en la red.

De acuerdo con las diversas realizaciones de la presente divulgación, una carga útil de MMT es una carga útil genérica usada para empaquetar y transportar recursos, objetos genéricos, y otra información para consumo de un paquete de MMT usando el protocolo de MMT (MMTP). La carga útil de MMT puede ser usada para empaquetar MPUs, objetos genéricos, y mensajes de señalización. La carga útil de MMT puede transportar uno o más fragmentos de MPUs, uno o más mensajes de señalización, uno o más objetos genéricos (incluyendo MPUs completas), uno o más símbolos de reparación, etc. El tipo de la carga útil es indicado por el campo de tipo (o tipo de objeto) en el encabezado de paquete de MMTP, como se discutirá en mayor detalle con la discusión de la Figura 9 a continuación. Para cada tipo de carga útil, se define una única unidad de datos para suministro, así como un encabezado de carga útil específico de tipo. Por ejemplo, un fragmento de una MPU (por ejemplo una MFU) se considera como una única unidad de datos cuando la carga útil de MMT transporta fragmentos de MPU. El protocolo de MMT puede agregar múltiples unidades de datos con el mismo tipo de datos en una única carga útil. También puede fragmentar una única unidad de datos en múltiples paquetes.

La carga útil de MMT consiste en un encabezado de carga útil y datos de carga útil. Algunos tipos de datos pueden permitir la fragmentación y agregación, en cuyo caso, una única unidad de datos se divide en múltiples fragmentos o un conjunto de unidades de datos se suministran en un único paquete. Cada unidad de datos puede tener su propio encabezado de carga útil dependiendo del tipo de la carga útil. Para los tipos que no requieren un encabezado específico de tipo de carga útil no está presente ningún encabezado de tipo de carga útil y los datos de carga útil siguen al encabezado de MMTP. Algunos campos del paquete de MMTP se interpretan de manera diferente en base al tipo de carga útil. La semántica de estos campos está definida por el tipo de carga útil en uso.

La Figura 4 ilustra una estructura ejemplar para un encabezado 400 de carga útil en modo de streaming de acuerdo con diversas realizaciones de la presente divulgación.

El suministro de MPUs a receptores de MMT usando el protocolo de MMT requiere que tenga lugar un procedimiento de paquetización y despaquetización en el remitente y receptor, respectivamente, para habilitar el suministro de MPUs grandes. El modo de suministro de MPU considera una MPU completa o subpartes específicas de una única MPU como unidades de datos de suministro independientes para paquetización o agregación para facilitar grandes variaciones de tamaño de MPUs. El modo de streaming de formato de carga útil de MMTP (por ejemplo, modo de MPU) permite la fragmentación de únicas unidades de datos de suministro en múltiples cargas útiles de MMTP para soportar el suministro de MPU con un tamaño grande. El modo de streaming también permite la agregación de múltiples unidades de datos de suministro con el mismo tipo en una única carga útil de MMTp , para atender unidades de datos más pequeñas. El procedimiento de paquetización puede transformar una MPU en un conjunto de cargas útiles de MMTP que luego se transportan en cada paquete de MMTP cuando está fragmentado. En la entidad receptora se realiza el despaquetización para recuperar los datos de MPU originales.

En el tipo de carga útil 0x00, la MPU está fragmentada de una manera con aviso de medios permitiendo que la capa de transporte identifique la naturaleza y prioridad del fragmento que es transportado. Un fragmento de una MPU puede ser, por ejemplo, metadatos de MPU, o unos metadatos de Fragmentos de Película, una MFU, o un ítem de datos no temporizado. Este modo de streaming también es usado para el suministro de mensajes de señalización o símbolos de recuperación.

En esta realización ejemplar, la semántica de encabezado 400 de carga útil en modo de streaming y longitud de cada campo del encabezado 400 de carga útil en modo de streaming se proporcionan como sigue: el campo 402 de longitud tiene una longitud de 16 bits y este campo indica el tamaño de carga útil completa incluyendo este campo; el campo 404 de Tipo de Unidad de Datos (DU_type) de suministro puede ser 5 bits de longitud y puede indicar el tipo de unidad de datos de suministro de la carga útil, por ejemplo, como se proporciona en la Tabla 1 a continuación.

Tabla 1

[Tabla 1]

Continuando con los campos del encabezado 400 de carga útil en modo de streaming, el campo 406 de aggregation_flag (A) puede ser 1 bit de longitud y cuando se establece en '1' indica que está presente más de 1 unidad de datos de suministro en la carga útil que el campo 408 de f_i es ignorado; el campo 408 de indicador de fragmentación (f_i) puede ser 2 bits de longitud y puede indicar que el indicador de fragmentación contiene información sobre fragmentación de unidad de datos en la carga útil, por ejemplo, como se ilustra en la Tabla 2 a continuación.

Tabla 2

[Tabla 2]

El valor de este campo 408 puede establecerse en '00' cuando el valor del campo 'A' se establece en '1'.

Continuando con los campos del encabezado 400 de carga útil en modo de streaming, el campo 410 counter (recuento) puede ser 16 bits, indica un número de carga útil que contiene fragmentos de la misma unidad de datos de suministro que suceden a esta carga útil de MMT si el aggregation_flag se establece en '0', e indica el número de unidades de datos de suministro agregadas en esta carga útil si aggregation_flag se establece en '1'. El campo 412 de DU_length puede ser 16 bits de longitud y el campo indica la longitud de los datos que siguen a este campo 412. Cuando aggregation_flag se establece en '0', este campo 412 puede no estar presente. Cuando aggregation_flag se establece en '1', este campo 412 puede aparecer tantas veces como el valor del campo 410 'counter' y preceder cada unidad de datos agregados. El campo 414 de DU_Header es el encabezado de la unidad de datos, que depende del tipo de unidad de datos de suministro, como se discutirá con mayor detalle a continuación. Cuando aggregation_flag se establece en '1', este campo 414 puede aparecer tantas veces como el valor del campo 410 'contador' y preceder cada unidad de datos de suministro agregada. Cuando aggregation_flag se establece en '0', este campo 414 puede aparecer cuando el valor del campo 408 de 'f_i' es '01'.

La Figura 5 ilustra una estructura ejemplar para un encabezado 500 de MFU de medios temporizados de acuerdo con diversas realizaciones de la presente divulgación. El encabezado 500 de MFU de medios temporizados es un ejemplo de encabezado de unidad de datos de suministro, tal como se incluye en el DU_header 414 en la Figura 4, para datos de medios temporizados.

En esta realización ejemplar, la semántica y longitud de cada campo del encabezado 500 de MFU de medios temporizados se proporcionan como sigue: el campo 502 de movie_fragment_sequence_number puede ser 32 bits de longitud e incluye el número de secuencia del fragmento de película al cual pertenecen los datos de medios de esta MFY; el campo 504 de sample_number puede ser 32 bits de longitud e incluye el número de muestra de la muestra a la cual pertenecen los datos de medios de la MFU; el campo 506 de desplazamiento puede ser 16 bits de longitud e incluye el desplazamiento de los datos de medios de esta MFU dentro de la muestra referenciada; el campo 508 subsample_priority puede ser 8 bits de longitud y proporciona la prioridad de los datos de medios transportados por esta MFU en comparación con otros datos de medios de la misma MPU. Por ejemplo, el valor de subsample_priority puede estar entre 0 y 455, indicando los valores más altos una prioridad más alta. Adicionalmente, el campo 510 de dependency_counter puede ser 8 bits de longitud e indica el número de unidades de datos que dependen de su procesamiento de medios sobre los datos de medios en esta MFU.

La Figura 6 ilustra una estructura ejemplar para un encabezado 600 de MFU no temporizado de acuerdo con diversas realizaciones de la presente divulgación. El encabezado 600 de MFU no temporizado es un ejemplo de encabezado de unidad de datos de suministro, tal como se incluye en el DU_header 414 en la Figura 4, para datos de medios no temporizados.

En esta realización ejemplar, la semántica y longitud de cada campo del encabezado 600 de MFU no temporizado se proporcionan como sigue: el campo 602 de Item_ID puede ser 32 bits de longitud e incluye el identificador del ítem que se transporta como parte de esta MFU. Para los tipos de archivo (FTs) 0 y 1, puede no estar disponible ningún encabezado de DU adicional. El campo de identificador de objeto del encabezado de MMTP puede establecerse en el MPU_sequence_number de la MPU desde la cual se extrae la unidad de datos. El indicador de punto de acceso aleatorio (r A p ) se puede establecer para marcar unidades de datos de valor de FT 0 y 1 y para MFUs que contienen una muestra de sincronización o un fragmento de la misma, en el caso de medios temporizados, y para el ítem principal de MPUs de no temporizadas.

La Figura 7 ilustra una estructura ejemplar para un encabezado 700 de mensaje de señalización de acuerdo con diversas realizaciones de la presente divulgación. El encabezado 700 de mensaje de señalización es un ejemplo de encabezado de unidad de datos de suministro, tal como se incluye en el DU_header 414 en la Figura 4, para un mensaje de señalización.

En esta realización ejemplar, la semántica y longitud de cada campo del encabezado 700 de mensaje de señalización se proporcionan como sigue: el campo 702 de message_id puede ser 16 bits de longitud e indica el tipo de mensaje de señalización; el campo de versión puede ser 8 bits de longitud e indica el número de versión del mensaje de señalización; el campo reservado (RES) puede ser 8 bits de longitud y está reservado para uso futuro y puede establecerse en 0.

MMTP también soporta el transporte de archivos y recursos genéricos y usa el tipo de carga útil 1. Un recurso genérico consiste en uno o más archivos que están agrupados lógicamente y que comparten algunas características en común para una aplicación, por ejemplo Segmentos de una Representación de Streaming Adaptativa Dinámica sobre HTTP (DASH), una secuencia de MpUs, etc.

En el modo de tipo de carga útil de GFD, un recurso genérico se suministra a través de MMTP usando el tipo de carga útil de GFD. GFD requiere una descripción de sesión de GFD que se discute a continuación para describir el contenido de recurso genérico y características de suministro. Realizaciones de la presente divulgación proporcionan el establecimiento de sesión de GFD sobre el protocolo de MMTP. Cuando se suministra dentro de MMTP, la sesión de GFD puede mapearse exactamente en un flujo de packet_id.

Cada archivo suministrado dentro de una sesión de GFD requiere la asociación de información de suministro de transporte. Esto incluye, pero no se limita a información tal como la duración de transferencia. Cada archivo suministrado dentro de una sesión de GFD también puede tener parámetros específicos de contenido asociados tales como nombre, identificación, y/o ubicación del archivo, tipo de medios, tamaño del archivo, codificación del archivo o resumen de mensaje del archivo. En alineación con el protocolo HTTP/1.1 como se define en IETF RFC2616, que se incorpora por referencia en la presente memoria, cada archivo dentro de un recurso genérico puede tener asignada cualquier metainformación sobre la entidad-cuerpo, es decir el archivo suministrado. Detalles adicionales de la operación de GFD se discuten a continuación. Los archivos suministrados en una sesión de GFD pueden tener que ser puestos a disposición para una aplicación, por ejemplo a través de un caché de proxy o por otros medios. Luego cada objeto se suministra a través de la sesión de GFD.

Antes de que un receptor pueda establecer una sesión de GFD, el receptor puede necesitar obtener suficiente información, tal como, por ejemplo, información de acceso a sesión e información de sesión de GFD. La información de acceso a sesión para la sesión de GFD, cuando se opera en MMT, se define en 23008-1, que se ha incorporado por referencia en la presente memoria. La información de sesión de GFD se describe con mayor detalle a continuación. La Descripción de Sesión de GFD podría estar en una forma tal como el Protocolo de Descripción de Sesión (SDP) como se define en RFC4566, metadatos de XML como se define en RFC3023, o encabezados de HTTP/MIME como se define en RFC2616, etc., cada uno de estos documentos de estándares de RFC se incorpora expresamente por referencia en la presente memoria.

Información de Sesión de GFD: el protocolo de GFD suministra archivos. En el modo de GFD, a cada archivo se le asigna un parámetro Identificador de Objeto de Transmisión (TOI) y un parámetro de punto de código (CP). El parámetro TOI proporciona que el objeto está asociado con un identificador único dentro del ámbito de una sesión de GFD. Cada objeto está asociado con un punto de código. Un punto de código resume propiedades de objetos específicos y de suministro de objetos. Los paquetes con el mismo TOI pueden tener el mismo valor en el punto de código.

La tabla de GFD proporciona una lista de puntos de código. A cada punto de código se le asigna dinámicamente un valor de punto de código. La semántica de la Tabla de GFD se proporciona en la Tabla 3 a continuación.

Tabla 3

[Tabla 3]

Un punto de código puede incluir la longitud máxima de transferencia de cualquier objeto suministrado con esta señalización de punto de código. Además, un punto de código puede incluir cualquiera de la siguiente información: la longitud de transferencia real de los objetos, cualquier información que pueda estar presente en el encabezado de entidad como se define en RFC2616, sección 7.1, incorporada por referencia en la presente memoria, una plantilla de ubicación de contenido como se describe a continuación usando el parámetro TOI y packet_id, si está presente; e información específica sobre el contenido, por ejemplo cómo se empaqueta el contenido, etc. El TOI y packet_id se pueden usar para generar la ubicación contenido para cada TOI y packet_id. Si tal plantilla está presente, el procesamiento como se describe a continuación con respecto a la plantilla de ubicación de contenido puede usarse para generar la ubicación de contenido y el valor del URI puede tratarse como el campo de ubicación de contenido en el encabezado de entidad. Dentro de una sesión, se pueden definir como máximo 256 puntos de código. La definición de puntos de código se puede configurar dinámicamente en la Descripción de Sesión de GFD. Se proporciona un ejemplo de la semántica para el punto de código en la Tabla 4 a continuación.

^{Tabla 4} [Tabla 4]

Un punto de código puede incluir un atributo de @contentLocationTemplate. El valor de atributo de @contentLocationTemplate puede contener uno o más de los identificadores que se enumeran en la Tabla 5 a continuación. En cada URL, los identificadores de la Tabla 5 pueden ser reemplazados por el parámetro de sustitución definido en la Tabla 5. La coincidencia de identificadores es sensible a mayúsculas y minúsculas. Si el URL contiene símbolos $ sin escape que no encierran un identificador válido entonces el resultado de formación de URL es indefinido. El formato del identificador también se especifica en la Tabla 5 a continuación.

Tabla 5

[Tabla 5]

Cada identificador puede ser sufijo, dentro de los caracteres '$' adjuntos que siguen a este prototipo: "%0[width]d". El parámetro "width" es un entero sin signo que proporciona el número mínimo de caracteres que van a ser impresos. Si el valor que va a ser impreso es más corto que este número, el resultado puede rellenarse con ceros. El valor puede no ser truncado incluso si el resultado es mayor. La @contentLocationTemplate se puede escribir de tal manera que la aplicación del proceso de sustitución dé como resultado URIs válidos. Las cadenas fuera de identificadores solo pueden contener caracteres que son permitidos dentro de los URLs de acuerdo con RFC 3986, que se incorpora por referencia en la presente memoria.

Operación de GFD: el modo de GFD de MMTP suministra archivos regulares. Cuando se suministran archivos regulares, el objeto representa un archivo. Si el punto de código definido en la descripción de Sesión de GFD contiene campos de encabezado de entidad o campos de encabezado de entidad que se pueden generar, entonces todos estos campos de encabezado de entidad pueden aplicarse al archivo suministrado.

La Figura 8 ilustra una estructura ejemplar para una estructura 800 de paquetes en modo de GFD de acuerdo con diversas realizaciones de la presente divulgación. Los paquetes 800 de carga útil enviados usando MMTP pueden incluir un encabezado 802 a 818 de carga útil de GFD y una Carga útil 820 de GFD como se ilustra en la Figura 8. En algunos casos especiales un remitente de GFD puede necesitar producir paquetes que no contienen ninguna carga útil. Esto puede ser requerido, por ejemplo, para señalizar el extremo de una sesión. El encabezado 802 a 818 de carga útil de GFD tiene un tamaño variable. En el encabezado 802 a 818 de carga útil de GFD, todos los campos enteros se transportan en formato "big-endian" o "network order", es decir, el byte (octeto) más significativo primero. Los bits designados como "padding" o "reserved" (r) se establecen en 0 por los remitentes e ignorados por los receptores. A menos que se indique otra cosa, las constantes numéricas en estos ejemplos están en forma decimal (base 10).

En esta realización ejemplar, la semántica y longitud de cada campo de la estructura 800 de paquetes en modo de GFD se proporcionan como sigue: el campo 802 de longitud incluye 16 bits e indica el tamaño de carga útil completa incluyendo este campo; el campo 804 S puede ser 1 bit de longitud e indica el número de palabras completas de 32 bits en el campo TOI (el campo TOI es 32*S 16*H bits en el campo 802 de longitud, por ejemplo, la longitud es ya sea 0 bits, 16 bits, 32 bits, o 48 bits); el campo 806 H puede ser 1 bit de longitud y permite que las longitudes de campo TOI sean múltiplos de media palabra (16 bits), mientras que asegura que la longitud agregada de los campos de start_offset y TOI es un múltiplo de 32 bits; el campo 808 L puede ser 1 bit de longitud e indica si este es el último paquete suministrado para este objeto; el campo 810 B puede ser 1 bit de longitud e indica si este paquete contiene el último byte del objeto; el campo 812 de punto de código (CP) puede ser 8 bits de longitud e incluye un identificador opaco que se pasa al decodificador de carga útil de paquete para transmitir información sobre la carga útil de paquete. El mapeo entre el punto de código y el códec real se define en una base por sesión y se comunica fuera de banda como parte de la información de descripción de sesión. El campo 814 de Metadatos (M) de Objeto puede ser 1 bit de longitud y este indicador indica si los metadatos de objeto se proporcionan como parte de la carga útil o no. Cuando se establece en 1, la carga útil es entidad de MIME, donde el encabezado puede contener al menos el tipo de contenido y los encabezados de ubicación de contenido. El campo reservado (RES) puede ser 3 bits de longitud y se establece en 0; el campo 818 de start_offset (16+32*O+16*H) indica la ubicación de los datos de carga útil actual en el objeto; y el campo 820 de carga útil de GFD incluye la carga útil de GFD.

El identificador de objeto se puede establecer en un identificador único del objeto genérico que está siendo suministrado. El mapeo entre el identificador de objeto y la información de objeto (tal como URL y tipo de MIME) se puede hacer de manera explícita o implícita. Por ejemplo, una secuencia de segmentos de DASH puede usar el índice de segmento como el identificador de objeto y un identificador de representación numérica como la packet_id. Este mapeo también se puede realizar usando un mensaje de señalización.

Para la Carga útil 820 de GFD, los bytes del objeto se referencian de tal manera que el byte 0 es el comienzo del objeto y el byte T-1 es el último byte del objeto con T la longitud de transferencia del objeto. Los datos transportados en la carga útil de un paquete de MMTP pueden consistir en una porción consecutiva del objeto que inicia desde el comienzo del byte X y que termina en el comienzo del byte X Y donde X es el valor de campo de start_offset en el encabezado de paquete de GFD y Y es la longitud de la carga útil en bytes. Y puede no transportarse en el paquete pero la trama puede ser proporcionada por el protocolo de transporte subyacente.

El protocolo de MMT (MMTP) es un protocolo de transporte de capa de aplicación diseñado para suministrar de manera eficiente y fiable paquetes de MMT. MMTP puede ser usado para el suministro tanto de datos de medios temporizados como no temporizados. Soporta varias características, tales como multiplexación de medios, cálculo de variación rápida de red, que son esenciales para suministrar contenido compuesto por diversos tipos de datos de medios codificados. MMTP puede ejecutarse por encima de los protocolos existentes, por ejemplo Protocolo de Datagramas de Usuario (UDP) e IP. En la presente divulgación, se requiere un carro específico de los datos con formato diferente al formato de carga útil de MMT. Un único paquete de MMTP puede transportar exactamente una carga útil de MMT. MMTP supone que la entidad emisora realiza control de congestión y de este modo la función de control de congestión no se especifica en esta memoria descriptiva. Esto se debe a que MMTP se ejecuta por encima de UDP/IP y será usado por una amplia variedad de aplicaciones esta función se deja a implementación de entidades emisoras.

MMTP soporta la multiplexación de diferentes recursos sobre un único flujo de paquetes de MMT. MMTP suministra múltiples tipos de datos en el orden de consumo en la entidad receptora para ayudar a la sincronización entre diferentes tipos de datos de medios sin introducir un gran retraso o requerir un gran búfer. MMTP también soporta la multiplexación de datos de medios y mensajes de señalización dentro de un único flujo de paquetes. Una única carga útil de MMT se puede transportar en solo un paquete de MMT.

El protocolo de MMT define dos modos de paquetización, el modo de GFD y el modo de MPU. El modo de GFD (por ejemplo, modo de descarga) define un modo que empaqueta datos de medios en base al tamaño de la carga útil que va a ser transportada y el modo de MPU (por ejemplo, modo de streaming) define un modo que empaqueta datos de medios en base al tipo de datos que van a ser transportados en la carga útil. El protocolo de MMT soporta el uso mixto de paquetes con dos modos diferentes en una única sesión de suministro. Un único flujo de paquetes de paquetes de MMT puede estar compuesto arbitrariamente de cargas útiles con dos tipos. MMTP proporciona la estructura y definiciones para calcular y eliminar la variación rápida introducida por la red de suministro subyacente, de tal manera que se pueda lograr un retraso constante para el flujo de datos. Al usar el campo de marca de tiempo en el encabezado de paquete, la variación rápida se puede calcular con precisión sin requerir ninguna información ni protocolos de señalización adicionales.

La Figura 9 ilustra una estructura ejemplar para un paquete 900 de MMTP de acuerdo con diversas realizaciones de la presente divulgación. En esta realización ejemplar, la semántica y longitud de cada campo del paquete 900 de MMTP se proporcionan como sigue: campo 902 de versión (V) puede ser 2 bits de longitud e indica el número de versión del protocolo. Este campo 902 puede establecerse en '00' para cumplir con esta memoria descriptiva. El campo de tipo (tipo de objeto) 904 es 6 bits. Este campo 904 indica el tipo de carga útil, es decir, el modo. En un ejemplo, se puede proporcionar al menos uno de los valores de tipo de carga útil en la Tabla 6 a continuación. Para la indicación de fragmentación y agregación la unidad de datos de cada tipo de carga útil se puede proporcionar en la Tabla 6 a continuación.

Tabla 6

[Tabla 6]

Continuando con la semántica y longitud de cada campo del paquete 900 de MMTP, el campo 906 de FEC_type (FEC) puede ser 2 bits de longitud e indica el tipo de esquema de f Ec usado para proteger los paquetes de MMT. Un ejemplo de valores y descripciones asociadas para este campo 906 se puede enumerar en la Tabla 7 a continuación.

Tabla 7

[Tabla 7]

Continuando con la semántica y longitud de cada campo del paquete 900 de MMTP, el campo 908 reservado (RES) puede ser 3 bits de longitud y está reservado para uso futuro; el campo 910 de packet_counter_flag (C) puede ser 1 bit de longitud y un '1' indica que el campo de packet_counter está presente; el campo 912 de RAP_flag (R) puede ser 1 bit de longitud y, cuando se establece en '1', indica que la carga útil contiene un punto de acceso aleatorio al flujo de datos de ese tipo de datos, el campo 914 de extension_flag (X) puede ser 1 bit de longitud y un '1' indica que el campo de header_extension está presente, el último campo 916 (L) puede ser 1 bit de longitud y un '1' indica que el último de los paquetes con mismo valor del campo de object_identifier; el campo 918 de packet_id puede ser 16 bits de longitud e incluye un valor entero asignado a cada recurso para distinguir paquetes de un recurso de otro. Se asignan valores separados a los mensajes de señalización y flujos de reparación de FEC. La packet_id es única a lo largo de la vida útil de la sesión de suministro y para todos los flujos de MMT suministrados por la misma entidad emisora de MMT. El mapeo entre la packet_id y la asset_id es señalizado por la Tabla de Paquetes de MMT como parte de un mensaje de señalización. Para la Capa de Aplicación - Corrección de Errores de Reenvío (AL-FEC), el mapeo entre packet_id y el flujo de reparación de FEC se proporciona en el mensaje de AL-FEC. La packet_id es única para todos los flujos de paquetes de MMT suministrados por la misma entidad emisora de MMT.

Continuando con la semántica y longitud de cada campo del paquete 900 de MMTP, el campo 920 object_identifier puede ser 32 bits de longitud e incluye un identificador del objeto de capa de aplicación de la carga útil actual que se extrae. La semántica exacta y uso de este campo 920 pueden depender del tipo de la carga útil. El campo 922 de packet_sequence_number puede ser 32 bits de longitud e incluye un valor entero que está dentro del ámbito por la packet_id e inicia a partir de un valor arbitrario incrementado en uno para cada paquete de MMT. Este valor se ajusta a '0' después de que se alcanza su valor máximo. El campo 924 de marca de tiempo puede ser 32 bits de longitud y especifica la instancia de tiempo del suministro de paquete de MMT. El tiempo de NTP se usa en la marca de tiempo como se especifica como el "formato corto" en la cláusula 6 de IETF RFC5905, NTP versión 4, que se incorpora por referencia en la presente memoria. Esta marca de tiempo especifica el tiempo en el primer bit de paquete de MMT. El campo 926 de packet_counter puede ser 32 bits de longitud e incluye un valor entero para recontar el paquete de MMT. El valor se incrementa mediante el envío de un paquete de MMT y es diferente del valor packet_id. Este campo 926 inicia a partir de un valor arbitrario incrementado en uno por cada paquete de MMT enviado. El valor del campo 926 se ajusta a '0' después de su valor máximo.

El campo 928 de encabezado de extensión incluye información definida por usuario. El mecanismo de extensión de encabezado se proporciona para permitir extensiones registradas al formato de carga útil para habilitar aplicaciones y tipos de medios que requieren información adicional para ser transportada en el encabezado de formato de carga útil. El mecanismo de extensión de encabezado está diseñado de tal manera que se puede descartar sin afectar el procesamiento correcto de la carga útil de MMT. El encabezado de extensión en el campo 928 puede tener el formato como se ilustra en la Figura 10, que ilustra una estructura ejemplar para la extensión 1000 de encabezado de acuerdo con diversas realizaciones de la presente divulgación.

Continuando con la semántica y longitud de cada campo del paquete 900 de MMTP, el campo 930 de datos de carga útil incluye los datos de carga útil; y el campo 932 de ID de carga útil de FEC de origen puede ser 2 bits de longitud y puede usarse sólo cuando el valor de tipo de FEC se establece en '1'. Un paquete de MMT con tipo de FEC = 1 puede usarse para protección de AL-FEC y después de protección de AL-FEC este campo puede agregarse al paquete de MMT.

En estas realizaciones ilustrativas, la presente divulgación proporciona una estructura armonizada para MMTP con dos capas que habilitan la indicación de partes específicas de una MPU para suministro fragmentado. Como una primera capa, el tipo de carga útil (por ejemplo, modo de descarga, modo de streaming, modo de GPU, modo de MPU, etc.) se señaliza por campo de tipo (o tipo de objeto) en el Encabezado de MMTP. Como la segunda capa, el tipo de unidad de datos de suministro se señaliza por el campo de DU_type en el encabezado de carga útil en modo de MPU. Por consiguiente, las realizaciones de la presente divulgación proporcionan un protocolo de transmisión que soporta tanto descarga como streaming en el mismo protocolo integrando el modo de g Pu y modo de MPU dentro del MMTP.

La Figura 11 ilustra un diagrama 1100 ejemplar de paquetización de datos de medios temporizados de acuerdo con diversas realizaciones de la presente divulgación. La paquetización de una MPU que contiene medios temporizados se puede realizar en un modo con aviso de formato de MPU y/o agnóstico de formato de MPU. En el modo agnóstico de formato de MPU, la MPU se empaqueta en unidades de datos de igual tamaño (excepto por la última unidad de datos, cuyo tamaño puede diferir) o un tamaño predefinido de acuerdo con el tamaño de MTU de la red de suministro subyacente usando GFD. En otras palabras, la paquetización del modo agnóstico de formato de MPU solo puede considerar el tamaño de datos que van a ser transportados en el paquete. El campo de tipo para el encabezado de paquete de MMTP se establece en 0x00 para indicar que la paquetización es modo agnóstico de formato.

En el modo con aviso de formato de MPU el procedimiento de paquetización tiene en cuenta los límites de diferentes tipos de datos en MPU para generar paquetes usando el modo de MPU. Los paquetes resultantes transportan unidades de datos de suministro ya sea de metadatos de MPU, metadatos de fragmentos de película, o MFU. Los paquetes resultantes no pueden transportar más de dos tipos diferentes de unidades de datos de suministro. A la unidad de datos de suministro de metadatos de MPU se le asigna el DU_type 0x01. Los metadatos de MPU incluyen la casilla 'ftyp' (tipo de archivo), la casilla 'mmpu' (una MPU), la casilla 'moov' (Película), y cualquier otra casilla que se aplique a toda la MPU. La casilla 'ftyp' contiene un tipo de un archivo, la casilla 'mmpu' contiene una configuración de una MPU, y la casilla 'moov' contiene información de configuración de códec. La unidad de datos de suministro de metadatos de fragmento de película consiste en la casilla 'moof (fragmento de película) y el encabezado de casilla 'mdat' (datos de medios) (excluyendo cualquier dato de medios) y se le asigna el DU_type 0x02. La casilla 'mdat' contiene datos de medios e información de control de los datos de medios, y la casilla 'moof' contiene información de encabezado de los datos de medios. Los datos de medios, MFUs en casilla mdat de MPU, se dividen luego en múltiples unidades de datos de suministro de MFU en una forma con aviso de formato. Esto se puede realizar, por ejemplo, con la ayuda de la pista de indicios de MMT. La MFU puede incluir 1) solo datos de medios, 2) datos de medios con un número de secuencia, y 3) datos de medios con alguna información de control. A cada MFU se le antepone el encabezado de MFU, que tiene la sintaxis y semántica. El encabezado de MFU es seguido por los datos de medios de la MFU.

La Figura 12 ilustra un diagrama 1200 ejemplar de paquetización de datos de medios no temporizados de acuerdo con diversas realizaciones de la presente divulgación. La paquetización de datos de medios no temporizados también se puede realizar en dos modos diferentes. En el modo agnóstico de formato de MPU, la MPU se empaqueta en unidades de datos de suministro de igual tamaño (excepto la última unidad de datos, cuyo tamaño puede diferir) o un tamaño predefinido de acuerdo con el tamaño de MTU de la red de suministro subyacente usando modo de GFD. El campo de tipo de paquete de MMTP se establece en 0x00 para indicar que la paquetización es genérica. En el modo agnóstico de formato, la MPU se empaqueta en el paquete que contiene unidades de datos de suministro ya sea de metadatos de MPU o MFU usando el modo de MPU. Los metadatos de MPU contienen la casilla 'ftyp', la casilla 'moov', la casilla 'meta' y cualquier otra casilla que se aplique a toda la MPU. Cada unidad de datos de suministro de MFU contiene un único ítem de los medios no temporizados. Cada ítem de los datos no temporizados se usa luego para construir una MFU. La MFU consiste en un encabezado de MFU y los datos de MFU no temporizados.

El procedimiento de despaquetización se realiza en el receptor de MMT para obtener la MPU transmitida. El procedimiento de despaquetización puede operar en uno de los siguientes modos, dependiendo de las necesidades de aplicación: un modo de MPU, un modo de fragmentos, y un modo de unidad de medios. En el modo de MPU, el descargador de carga útil regenera la MPU completa antes de reenviar la MPU a la aplicación. Este modo es apropiado para el suministro crítico sin tiempo, es decir el tiempo de presentación de la MPU como se indica por la CI está lo suficientemente atrasado con el tiempo de suministro de la MPU. En el modo de fragmento, el descargador de carga útil regenera un fragmento completo que incluye los metadatos de fragmento y la casilla 'mdat' con muestras de medios antes de reenviarlo a la aplicación. Este modo no se aplica a los medios no temporizados. Este modo es adecuado para aplicaciones sensibles al retraso donde el presupuesto de tiempo de suministro es limitado pero es lo suficientemente grande como para recuperar un fragmento completo. En el modo de unidad de medios, el descargador de carga útil extrae y reenvía unidades de medios lo más rápido posible a la aplicación. Este modo es aplicable para aplicaciones de medios de muy bajo retraso. En este modo, no se requiere la recuperación de la MPU. El procesamiento de los datos de medios de fragmentos no es requerido pero se puede realizar para resincronizar. Este modo tolera el suministro fuera de orden de los metadatos de fragmento, que pueden generarse después de que se generen las unidades de medios. Este modo se aplica tanto a los medios temporizados como a no temporizados.

Usando los números de secuencia de MFU, el receptor puede detectar paquetes faltantes y aplicar cualquier procedimiento de corrección de errores tal como FEC o ARQ para recuperar los paquetes faltantes. El tipo de carga útil puede ser usado por el remitente para determinar la importancia de la carga útil para la aplicación y para aplicar medidas adecuadas de resiliencia a errores.

Cada sesión de suministro de GFD puede tener un GFDT que es local para la sesión dada. Un archivo que se suministra dentro de la sesión de GFD, pero que no se describe en el GFDT no se considera un 'file' perteneciente a la sesión de suministro de GFD. Un objeto que se recibe con un punto de código no mapeado debe ser ignorado por un receptor de GFD.

Los archivos en la sesión de GFD pueden tener que ser proporcionados a una aplicación, por ejemplo en un documento de información de composición o una descripción de presentación de medios, como se define en ISO/IEC 23009-1, que se incorpora por referencia en la presente memoria, puede hacer referencia a los archivos suministrados usando MMTP como objetos de GFD. Se puede hacer referencia al archivo a través del URI proporcionado o derivado de la ubicación de contenido, ya sea proporcionado en banda o como parte de la descripción de sesión de GFD. En ciertos casos, los archivos tienen un tiempo de inicio de disponibilidad en la aplicación. En este caso la sesión de GFD puede suministrar los archivos de tal manera que el último paquete del objeto se suministre de tal manera que esté disponible más tarde en el receptor en el tiempo de inicio de disponibilidad como se anuncia en la aplicación. Las aplicaciones suministradas a través del modo de GFD pueden imponer requisitos adicionales y más estrictos sobre el envío de los archivos dentro de una sesión de GFD.

Dentro de una sesión, un remitente (por ejemplo, entidad 101 emisora) transmite una secuencia de paquetes dentro de la sesión. Pueden suministrarse varios objetos dentro de la misma sesión de GFD. Si va a ser suministrado más de un objeto dentro de una sesión, entonces el remitente puede usar el campo TOI. En este escenario, cada objeto puede ser identificado por un TOI único dentro de la sesión, y el remitente puede usar TOI correspondiente para todos los paquetes que pertenecen al mismo objeto. El mapeo entre TOIs y archivos transportados en una sesión se describe en la descripción de sesión de GFD así como en los campos de encabezado de entidad si se aplica el suministro en modo de entidad.

Puede usarse el encabezado de GFD, como se discutió anteriormente. El encabezado de paquete de GFD incluye un campo de punto de código que se puede usar para comunicar a un receptor las configuraciones de la información que se establece para la sesión y que incluso puede variar durante una sesión. El mapeo entre configuraciones y valores de puntos de código se comunica en la descripción de sesión de GFD.

Por ejemplo, dejar que T > 0 sea la longitud de transferencia de cualquier objeto en bytes, los datos transportados en la carga útil de un paquete consisten en una porción consecutiva del objeto. Entonces para cualquier X arbitraria y cualquier Y > 0 arbitraria en tanto que X Y sea como máximo T se puede generar un paquete. Bajo este criterio puede cumplirse lo siguiente: (A) los datos transportados en la carga útil de un paquete pueden consistir en una porción consecutiva del objeto que inicia desde el comienzo del byte X hasta el comienzo del byte X Y; (B) el campo de start_offset en el encabezado de paquete de GFD puede establecerse en X y los datos de carga útil pueden agregarse al paquete a enviar; y (C) si X Y es idéntico a T, el indicador de encabezado de paquete B puede establecerse en 1, si no el indicador de encabezado de paquete B puede establecerse en 0.

El siguiente procedimiento ejemplar puede ser usado por un remitente para suministrar un objeto para generar paquetes que contienen start_offset y datos de carga útil correspondientes. Primero, el remitente establece el recuento de desplazamiento de bytes X en 0. Luego, para los siguientes paquetes que van a ser suministrados establece la longitud en bytes de una carga útil en un valor fijo Y, que es a) razonable para una carga útil de paquete (por ejemplo, asegurar de que el tamaño total de paquete no exceda la MTU), b) de tal manera que la suma de X e Y sea como máximo T, y c) de tal manera que sea adecuado para los datos de carga útil incluidos en el paquete. El remitente luego genera un paquete de acuerdo con las reglas a-c desde arriba. Luego si X Y es igual a T, el remitente establece el indicador de encabezado de paquete B en 1, sino el remitente establece el indicador de encabezado de paquete B en 0, incrementa X = X Y y retorna a generar el paquete de acuerdo con las reglas a-c.

El orden de suministro de paquetes puede ser arbitrario, pero el remitente puede realizar suministro en ausencia de otras restricciones de suministro con un número de start_offset creciente. La longitud de transferencia puede ser desconocida antes de enviar piezas anteriores de los datos. En esta situación, T se puede determinar más tarde. Sin embargo, esto no afecta el proceso de envío anterior. Se pueden enviar paquetes adicionales siguiendo las reglas en (A)-(C) desde arriba. En esta situación, el indicador B solo puede establecerse para el paquete que contiene la última porción del objeto.

La Descripción de Sesión de GFD contiene uno o múltiples puntos de código identificados por diferentes valores de puntos de código. Tras la recepción de cada paquete, el receptor (por ejemplo, una o más de entidades 110-116 receptoras) puede proceder con las siguientes etapas. Primero, el receptor analiza de manera sintáctica el encabezado de paquete y verifica que sea un encabezado válido. Si no es válido, entonces el paquete puede descartarse sin procesamiento adicional. En segundo lugar, el receptor analiza de manera sintáctica el valor de punto de código y verifica que la descripción de sesión de GFD contiene un punto de código coincidente. Si no es válido, entonces el paquete puede descartarse sin procesamiento adicional. En tercer lugar, el receptor procesa el resto del paquete, lo cual incluye interpretar los otros campos de encabezado de manera apropiada y usar el source_offset y los datos de carga útil para reconstruir el objeto correspondiente como sigue: a) el receptor puede determinar a partir de cuál objeto fue generado un paquete recibido por la información de sesión, y si está presente, por el TOI transportado en el encabezado de carga útil; b) tras recepción del primer paquete para un objeto, el receptor usa la Longitud Máxima de Transferencia recibida como parte de la Información de Transmisión de Objeto para determinar la longitud máxima T' del objeto; c) el receptor asigna espacio para los bytes T' que el objeto puede requerir; d) el receptor calcula la longitud de la carga útil, Y, restando la longitud de encabezado de paquete de la longitud total del paquete recibido; e) el receptor asigna un conjunto Booleano RECEIVED[0..T'-1] con todas las entradas T inicializadas en falso para rastrear los símbolos de objeto recibidos. El receptor sigue recibiendo paquetes para el bloque de objetos en tanto que haya al menos una entrada en RECEIVED todavía establecida como falsa o hasta que la aplicación decida renunciar a este objeto. f) para cada paquete recibido para el objeto (incluyendo el primer paquete), las etapas a seguir para ayudar a recuperar el objeto son como sigue: i) dejar que X sea el valor del campo de source_offset en el encabezado de paquete de GFD del paquete y dejar que Y sea la longitud de la carga útil, Y, calculada restando la longitud de encabezado de paquete de la longitud total del paquete recibido; ii) el receptor copia los datos en el lugar apropiado dentro del espacio reservado para el objeto y establece RECEIVED[X ... X+Y-1] = verdadero; iii) si todas las entradas T de RECEIVED son verdaderas, entonces el receptor ha recuperado todo el objeto; y g) una vez que el receptor recibe un paquete con el indicador B establecido en 1, puede determinar la longitud de transferencia T del objeto como X+Y del paquete correspondiente y ajustar el conjunto Booleano RECEIVED[0..T'-1] a RECEIVED[0..T-1].

CodePoint de GFD: la información sobre los archivos suministrados usando el modo de GFD se indica en la Tabla de MP si el asset_scheme_code se establece en "GeneralFile". Los objetos genéricos que son suministrados usando el modo de GFD pueden agruparse en conjunto como un flujo de MMTP identificado por el packet_id. Los paquetes que transportan objetos genéricos usando el modo de GFD pueden marcarse con el tipo 1 en el campo de tipo de encabezado de paquete de MMTP. La tabla de GFD define uno o múltiples puntos de código. La tabla de puntos de código se puede proporcionar en la Tabla 8 a continuación.

[Tabla 8]

Aunque diversas realizaciones descritas en la presente memoria discuten la comunicación de datos de MMT, se nota que las diversas realizaciones de la presente no están limitadas a comunicaciones de MMT. Por ejemplo, las determinaciones de retraso fijo y tamaño de búfer pueden aplicarse a cualquier tipo adecuado de suministro de contenido de datos o medios y/o cualquier tipo adecuado de sistema de transmisión de acuerdo con los principios de la presente divulgación.

La Figura 13 ilustra un proceso para procesar un paquete de transporte en una entidad receptora de acuerdo con una realización ilustrativa de la presente divulgación. Por ejemplo, el proceso representado en la Figura 13 puede ser realizado por algunas o todas las entidades 110-116 receptoras en la Figura 1. El proceso también puede ser implementado por el dispositivo 1500 electrónico en la Figura 15.

El proceso comienza con la entidad receptora que recibe un paquete de transporte (etapa 1305). La entidad receptora identifica entonces un tipo de carga útil de un campo que indica el tipo de carga útil en el encabezado de paquete (etapa 1310). Por ejemplo, en la etapa 1310, la entidad receptora puede analizar de manera sintáctica el encabezado de paquete e identificar el valor en el campo de tipo de objeto, tal como campo 904 en la Figura 9, e identificar el tipo de carga útil correspondiente de acuerdo con la Tabla 6. Si el tipo de carga útil es el modo genérico, la entidad receptora procesa los datos de carga útil en modo genérico (etapa 1315).

Si el tipo de carga útil es el modo de streaming, la entidad receptora identifica un tipo de unidad de datos de suministro de un campo que indica el tipo de unidad de datos de suministro en un encabezado de carga útil en modo de streaming (etapa 1320). Por ejemplo, en la etapa 1320, la entidad receptora puede identificar el tipo de unidad de datos de suministro de los datos de DU en el paquete de transporte tal como el tipo de datos en la carga útil de MMT.

Por ejemplo, la entidad receptora puede analizar de manera sintáctica el encabezado de carga útil en modo de streaming, tal como se ilustra en la Figura 4, para identificar el valor en el campo 404 de DU_type para identificar el tipo de unidad de datos de suministro de acuerdo con la Tabla 1. Por ejemplo, los datos de DU pueden incluir uno de: una MPU completa, metadatos de MPU, metadatos de fragmentos de película, una MFU temporizada, una MFU no temporizada, un mensaje de señalización, o símbolos de recuperación en base al valor incluido en el campo de tipo de DU.

Después de esto, la entidad receptora identifica información acerca de si están presentes MFUs en el paquete de transporte a partir de un campo indicador de fragmentación en el encabezado de carga útil en modo de streaming (etapa 1325). Por ejemplo, en la etapa 1325, el paquete de transporte incluye uno o más fragmentos de una MPU dispuestos como MFUs. El paquete de transporte puede incluir una pluralidad de unidades de datos de suministro, incluyendo cada unidad de datos de suministro un encabezado de Du y datos de DU. La entidad receptora puede determinar si los datos de DU incluyen: uno o más encabezados de unidad de datos de suministro y unidades de datos de suministro completas, un encabezado de unidad de datos de suministro y un primer fragmento de una unidad de datos de suministro, un fragmento de la unidad de datos de suministro que no es ni la primera ni la última parte, o un último fragmento de la unidad de datos de suministro en base al valor en el campo indicador de fragmentación de acuerdo con la Tabla 2.

La entidad receptora luego procesa los datos de DU (etapa 1330). Por ejemplo, en la etapa 1330, la entidad receptora puede procesar los datos de DU de acuerdo con el tipo de unidad de datos de suministro identificada. La entidad receptora puede procesar y decodificar los datos de DU para mostrar los medios a través de una interfaz de usuario al usuario asociado con la entidad receptora.

La Figura 14 ilustra un proceso para generar un paquete de transporte en una entidad emisora de acuerdo con una realización ilustrativa de la presente divulgación. Por ejemplo, el proceso representado en la Figura 14 puede ser realizado por la entidad 101 emisora en la Figura 1. El proceso también puede ser implementado por el dispositivo 1500 electrónico en la Figura 15.

El proceso comienza con la entidad emisora generando un paquete de transporte (etapa 1405). Por ejemplo, en la etapa 1405, la entidad emisora puede generar el paquete para incluir la descarga o streaming de datos. La entidad emisora puede incluir una pluralidad de unidades de datos de suministro incluyendo cada unidad de datos de suministro un encabezado de DU y datos de DU.

La entidad emisora incluye entonces un identificador de un tipo de carga útil en un campo que indica el tipo de carga útil en un encabezado de paquete para el paquete de transporte (etapa 1410). Por ejemplo, en la etapa 1410, la entidad emisora puede incluir un valor que corresponde al tipo de objeto, tal como en la Tabla 6, en un campo de tipo del encabezado de paquete, tal como en el campo 904 en la Figura 9.

La entidad emisora determina entonces si el tipo de carga útil es un tipo de carga útil en modo de streaming (etapa 1415). Si el tipo de carga útil es un tipo diferente al modo de streaming, por ejemplo, el modo genérico (GFD), la entidad emisora genera entonces el paquete de transporte de acuerdo con el tiempo de carga útil y procede a la etapa 1430 para enviar el paquete de transporte generado.

Sin embargo, si el tipo de carga útil es un tipo de carga útil en modo de streaming, la entidad emisora incluye un identificador de un tipo de unidad de datos de suministro en un campo que indica el tipo de unidad de datos de suministro en un encabezado de carga útil en modo de streaming (etapa 1420). Por ejemplo, en la etapa 1420, la entidad emisora puede incluir un valor de correspondiente al tipo de unidad de datos de suministro para el paquete en un campo en el encabezado de carga útil en modo de streaming, tal como se ilustra por el campo 404 de DU_type del encabezado de carga útil en modo de streaming en la Figura 4 de acuerdo con la Tabla 1 de tipos de unidades de datos de suministro. Por ejemplo, el campo de tipo de DU puede indicar que los datos de DU incluyen uno de: una MPU completa, metadatos de MPU, metadatos de fragmentos de película, una MFU temporizada, una MFU no temporizada, un mensaje de señalización, o símbolos de recuperación en base al valor incluido.

Después de esto, la entidad emisora incluye un identificador de información sobre si están presentes MFUs en el paquete en un campo indicador de fragmentación en el encabezado de carga útil en modo de streaming (etapa 1425). Por ejemplo, en la etapa 1425, el paquete de transporte puede incluir uno o más fragmentos de una MPU dispuestos como MFUs. La entidad emisora puede indicar que los datos de DU incluyen: uno o más encabezados de unidad de datos de suministro y unidades de datos de suministro completas, un encabezado de unidad de datos de suministro y un primer fragmento de una unidad de datos de suministro, un fragmento de la unidad de datos de suministro que no es ni la primera ni la última parte, o un último fragmento de la unidad de datos de suministro en base a un valor incluido en el campo indicador de fragmentación de acuerdo con la Tabla 2.

La entidad emisora envía entonces el paquete de transporte generado (etapa 1430). Por ejemplo, en la etapa 1430, la entidad emisora puede enviar el paquete de transporte a una entidad receptora para recibir y procesar el paquete de transporte, por ejemplo, de acuerdo con el proceso ilustrado en la Figura 13.

Aunque las Figuras 13 y 14 ilustran ejemplos de procesos para procesar y generar paquetes de transporte mediante entidades receptoras y emisoras, respectivamente, se podrían hacer diversos cambios en las Figuras 13 y 14. Por ejemplo, aunque se muestran como una serie de etapas, diversas etapas en cada figura podría superponerse, producirse en paralelo, producirse en un orden diferente, o producirse múltiples veces.

La Figura 15 ilustra un dispositivo 1500 electrónico de ejemplo en el cual se pueden implementar diversas realizaciones de la presente divulgación. En este ejemplo, el dispositivo 1500 electrónico incluye un controlador 1504, una memoria 1506, un almacenamiento 1508 persistente, una unidad 1510 de comunicaciones, una unidad 1512 de entrada/salida (E/S), y una pantalla 1514. En estos ejemplos ilustrativos, el dispositivo 1500 electrónico es también un ejemplo de la entidad 101 emisora y/o la entidad 110 receptora en la Figura 1.

El controlador 1504 es cualquier dispositivo, sistema o parte del mismo que controla al menos una operación, tal dispositivo puede ser implementado en hardware, firmware o software, o alguna combinación de al menos dos de los mismos. Por ejemplo, el controlador 1504 puede incluir una unidad de procesamiento de hardware, circuitería de procesamiento, codificación de medios y/o decodificación de hardware y/o software, y/o programa de software configurado para controlar operaciones del dispositivo 1500 electrónico. Por ejemplo, el controlador 1504 procesa instrucciones para software que pueden cargarse en la memoria 1506. El controlador 1504 puede incluir un número de procesadores, un núcleo multiprocesador, o algún otro tipo de procesador, dependiendo de la implementación particular. Adicionalmente, el controlador 1504 puede ser implementado usando un número de sistemas de procesadores heterogéneos en los cuales está presente un procesador principal con procesadores secundarios en un único chip. Como otro ejemplo ilustrativo, el controlador 1504 puede incluir un sistema multiprocesador simétrico que contiene múltiples procesadores del mismo tipo.

La memoria 1506 y almacenamiento 1508 persistente son ejemplos de dispositivos 1516 de almacenamiento. Un dispositivo de almacenamiento es cualquier pieza de hardware que sea capaz de almacenar información, tal como, por ejemplo, sin limitación, datos, código de programa en forma funcional, y/u otra información adecuada ya sea en una base temporal y/o una base permanente. La memoria 1506, en estos ejemplos, puede ser, por ejemplo, una memoria de acceso aleatorio o cualquier otro dispositivo de almacenamiento volátil o no volátil adecuado. Por ejemplo, el almacenamiento 1508 persistente puede contener uno o más componentes o dispositivos. El almacenamiento 1508 persistente puede ser un disco duro, una memoria flash, un disco óptico, o alguna combinación de los anteriores. Los medios usados por el almacenamiento 1508 persistente también pueden ser extraíbles. Por ejemplo, se puede usar un disco duro extraíble para almacenamiento 1508 persistente.

La unidad 1510 de comunicaciones proporciona comunicaciones con otros sistemas o dispositivos de procesamiento de datos. En estos ejemplos, la unidad 1510 de comunicaciones puede incluir un transmisor, receptor, y/o transceptor inalámbricos (celular, WiFi, etc.), una tarjeta de interfaz de red y/o cualquier otro hardware adecuado para enviar y/o recibir comunicaciones sobre un medio de comunicaciones físico o inalámbrico. La unidad 1510 de comunicaciones puede proporcionar comunicaciones a través del uso de cualquiera o ambos enlaces de comunicaciones físicos e inalámbricos.

La unidad 1512 de entrada/salida permite la entrada y salida de datos con otros dispositivos que pueden estar conectados a o una parte del dispositivo 1500 electrónico. Por ejemplo, la unidad 1512 de entrada/salida puede incluir un panel táctil para recibir entradas táctiles de usuario, un micrófono para recibir entradas de audio, un altavoz para proporcionar salidas de audio, y/o un motor para proporcionar salidas hápticas. La unidad 1512 de entrada/salida es un ejemplo de una interfaz de usuario para proporcionar y suministrar datos de medios (por ejemplo, datos de audio) a un usuario del dispositivo 1500 electrónico. En otro ejemplo, la unidad 1512 de entrada/salida puede proporcionar una conexión para la entrada de usuario a través de un teclado, un ratón, altavoz externo, micrófono externo, y/o algún otro dispositivo de entrada/salida adecuado. Adicionalmente, la unidad 1512 de entrada/salida puede enviar salida a una impresora. La pantalla 1514 proporciona un mecanismo para mostrar información a un usuario y es un ejemplo de una interfaz de usuario para proporcionar y suministrar datos de medios (por ejemplo, datos de imagen y/o vídeo) a un usuario del dispositivo 1500 electrónico.

El código de programa para un sistema operativo, aplicaciones, u otros programas puede estar ubicado en los dispositivos 1516 de almacenamiento, que están en comunicación con el controlador 1504 a través del sistema 1502 de bus. En algunas realizaciones, el código de programa está en una forma funcional en el almacenamiento 1508 persistente. Estas instrucciones pueden ser cargadas en la memoria 1506 para procesamiento por el controlador 1504. Los procesos de las diferentes realizaciones pueden ser realizados por el controlador 1504 usando instrucciones implementadas por ordenador, que pueden estar ubicadas en la memoria 1506. Por ejemplo, el controlador 1504 puede realizar procesos para uno o más de los módulos y/o dispositivos descritos anteriormente.

En algunas realizaciones, diversas funciones descritas anteriormente son implementadas o soportadas por un producto de programa de ordenador que se forma a partir de código de programa legible por ordenador y que está incorporado en un medio legible por ordenador. El código de programa para el producto de programa de ordenador puede estar ubicado en una forma funcional en un dispositivo de almacenamiento legible por ordenador que es selectivamente extraíble y puede ser cargado en o transferido a un dispositivo 1500 electrónico para procesamiento por el controlador 1504. En algunas realizaciones ilustrativas, el código de programa puede descargarse sobre una red al almacenamiento 1508 persistente desde otro dispositivo o sistema de procesamiento de datos para uso dentro del dispositivo 1500 electrónico. Por ejemplo, el código de programa almacenado en un medio de almacenamiento legible por ordenador en un sistema de procesamiento de datos de servidor puede ser descargado sobre una red desde el servidor al dispositivo 1500 electrónico. El sistema de procesamiento de datos que proporciona código de programa puede ser un ordenador servidor, un ordenador cliente, o algún otro dispositivo capaz de almacenar y transmitir código de programa.

Aunque la presente divulgación ha sido descrita con una realización ejemplar, se pueden sugerir diversos cambios y modificaciones a un experto en la técnica. Está previsto que la presente divulgación abarque tales cambios y modificaciones que caen dentro del ámbito de las reivindicaciones adjuntas.

Claims (11)

REIVINDICACIONES

1. Un procedimiento de transmisión de contenidos de medios usando un protocolo de transporte de medios de MPEG, MMTP, comprendiendo el procedimiento:

transmitir un paquete (900) de transporte que incluye un encabezado de paquete de MMTP, un encabezado de carga útil, y datos de carga útil que comprenden datos generados a partir de la al menos una MPU, en el que el encabezado de paquete de MMTP comprende información (904) que indica un tipo de los datos en los datos de carga útil de entre una pluralidad de tipos de carga útil, y

en el que la pluralidad de tipos de carga útil comprende un primer tipo de carga útil que indica que los datos de carga útil incluyen datos de fragmentos con aviso de medios de una unidad de procesamiento de medios, MPU, que comprende datos de medios de los contenidos de medios, un segundo tipo de carga útil que indica que los datos de carga útil incluyen al menos un mensaje de señalización, un tercer tipo de carga útil que indica que los datos de carga útil incluyen un objeto genérico, tal como una MPU completa o un objeto de otro tipo, y un cuarto tipo de carga útil que indica que los datos de carga útil incluyen un símbolo de reparación.

2. El procedimiento de la reivindicación 1, en el que, si la información (904) indica el primer tipo de carga útil, el encabezado (400) de carga útil comprende un campo (404) de tipo de fragmento, un primer campo (406), y un segundo campo (410),

indicando el campo (404) de tipo de fragmento un tipo de fragmento de los datos en los datos de carga útil de entre una pluralidad de tipos de fragmentos, incluyendo el primer campo (406) un valor que indica si se incluye más de 1 MPU en los datos de carga útil, e incluyendo el segundo campo (410) un valor que indica un número de al menos una carga útil que contiene al menos un fragmento de una misma MPU que sigue a los datos de carga útil.

3. El procedimiento de la reivindicación 2, en el que, la pluralidad de tipos de fragmentos comprende un primer tipo de fragmento que indica que los datos de carga útil incluyen metadatos de la MPU, un segundo tipo de fragmento que indica que los datos de carga útil incluyen metadatos de un fragmento de película, y un tercer tipo de fragmento que indica que los datos de carga útil incluyen al menos una MFU,

en el que el campo (404) de tipo de fragmento indica uno de metadatos de la MPU, metadatos de un fragmento de película, y una MFU que comprende unos datos de medios temporizados o no temporizados,

en el que los metadatos de la MPU comprenden una casilla ftyp que incluye un tipo de un archivo, una casilla mmpu que incluye una configuración de la MPU, y una casilla moovque incluye información de configuración de códec, y

en el que los metadatos del fragmento de película comprenden una casilla moof que incluye información de encabezado de datos de medios y una porción de una casilla mdat.

4. Un procedimiento de recepción de contenidos de medios usando un protocolo de transporte de medios de MPEG, MMTP, comprendiendo el procedimiento:

recibir un paquete (900) de transporte que incluye un encabezado de paquete de MMTP, un encabezado de carga útil, y datos de carga útil;

configurar datos de medios de los contenidos de medios en base al paquete de transporte recibido, en el que el encabezado de paquete de MMTP comprende información (904) que indica un tipo de los datos en los datos de carga útil de entre una pluralidad de tipos de carga útil, y

en el que la pluralidad de tipos de carga útil comprende un primer tipo de carga útil que indica que los datos de carga útil incluyen datos de fragmentos con aviso de medios de una unidad de procesamiento de medios, MPU, que comprende datos de medios de los contenidos de medios, un segundo tipo de carga útil que indica que los datos de carga útil incluyen al menos un mensaje de señalización, un tercer tipo de carga útil que indica que los datos de carga útil incluyen un objeto genérico, tal como una MPU completa o un objeto de otro tipo, y un cuarto tipo de carga útil que indica que los datos de carga útil incluyen un símbolo de reparación.

5. El procedimiento de la reivindicación 4, en el que, si la información (904) indica el primer tipo de carga útil, el encabezado (400) de carga útil comprende un campo (404) de tipo de fragmento, un primer campo (406), y un segundo campo (410),

indicando el campo (404) de tipo de fragmento un tipo de fragmento de los datos en los datos de carga útil de entre una pluralidad de tipos de fragmentos, incluyendo el primer campo (406) un valor que indica si se incluye más de 1 MPU en los datos de carga útil, e incluyendo el segundo campo (410) un valor que indica un número de al menos una carga útil que contiene al menos un fragmento de una misma MPU que sigue a los datos de carga útil.

6. El procedimiento de la reivindicación 5, en el que, la pluralidad de tipos de fragmentos comprende un primer tipo de fragmento que indica que los datos de carga útil incluyen metadatos de la MPU, un segundo tipo de fragmento que indica que los datos de carga útil incluyen metadatos de un fragmento de película, y un tercer tipo de fragmento que indica que los datos de carga útil incluyen al menos una MFU,

en el que el campo (404) de tipo de fragmento indica uno de metadatos de la MPU, metadatos de un fragmento de película, y una MFU que comprende unos datos de medios temporizados o no temporizados,

en el que los metadatos de la MPU comprenden una casilla ftyp que incluye un tipo de un archivo, una casilla mmpu que incluye una configuración de la MPU, y una casilla moov que incluye información de configuración de códec, y

en el que los metadatos del fragmento de película comprenden una casilla moof que incluye información de encabezado de datos de medios y una porción de una casilla mdat.

7. Un aparato de transmisión de contenidos de medios usando un protocolo de transporte de medios de MPEG, MMTP, comprendiendo el aparato:

un transmisor adaptado para transmitir un paquete (900) de transporte que incluye un encabezado de paquete de MMTP, un encabezado de carga útil, y datos de carga útil que comprenden datos generados a partir de la al menos una MPU,

en el que el encabezado de paquete de MMTP comprende información (904) que indica un tipo de los datos en los datos de carga útil de entre una pluralidad de tipos de carga útil, y

en el que la pluralidad de tipos de carga útil comprende un primer tipo de carga útil que indica que los datos de carga útil incluyen datos de fragmentos con aviso de medios de una unidad de procesamiento de medios, MPU, que comprende datos de medios de los contenidos de medios, un segundo tipo de carga útil que indica que los datos de carga útil incluyen al menos un mensaje de señalización, un tercer tipo de carga útil que indica que los datos de carga útil incluyen un objeto genérico, tal como una MPU completa o un objeto de otro tipo, y un cuarto tipo de carga útil que indica que los datos de carga útil incluyen un símbolo de reparación.

8. El aparato de la reivindicación 7, en el que, si la información (904) indica el primer tipo de carga útil, el encabezado (400) de carga útil comprende un campo (404) de tipo de fragmento, un primer campo (406), y un segundo campo (410),

indicando el campo (404) de tipo de fragmento un tipo de fragmento de los datos en los datos de carga útil de entre una pluralidad de tipos de fragmentos, incluyendo el primer campo (406) un valor que indica si se incluye más de 1 MPU en los datos de carga útil, e incluyendo el segundo campo (4 l0) un valor que indica un número de al menos una carga útil que contiene al menos un fragmento de una misma MPU que sigue a los datos de carga útil.

9. El aparato de la reivindicación 8, en el que, la pluralidad de tipos de fragmentos comprende un primer tipo de fragmento que indica que los datos de carga útil incluyen metadatos de la MPU, un segundo tipo de fragmento que indica que los datos de carga útil incluyen metadatos de un fragmento de película, y un tercer tipo de fragmento que indica que los datos de carga útil incluyen al menos una MFU,

en el que el campo (404) de tipo de fragmento indica uno de metadatos de la MPU, metadatos de un fragmento de película, y una MFU que comprende unos datos de medios temporizados o no temporizados,

en el que los metadatos de la MPU comprenden una casilla ftyp que incluye un tipo de un archivo, una casilla mmpu que incluye una configuración de la MPU, y una casilla moov que incluye información de configuración de códec, y

en el que los metadatos del fragmento de película comprenden una casilla moof que incluye información de encabezado de datos de medios y una porción de una casilla mdat.

10. Un aparato de recepción de contenidos de medios usando un protocolo de transporte de medios de MPEG, MMTP, comprendiendo el aparato:

un receptor adaptado para recibir un paquete (900) de transporte que incluye un encabezado de paquete de MMTP, un encabezado de carga útil y datos de carga útil;

un procesador adaptado para configurar datos de medios de los contenidos de medios en base al paquete de transporte recibido,

en el que el encabezado de paquete de MMTP comprende información (904) que indica un tipo de los datos en los datos de carga útil de entre una pluralidad de tipos de carga útil, y

en el que la pluralidad de tipos de carga útil comprende un primer tipo de carga útil que indica que los datos de carga útil incluyen datos de fragmentos con aviso de medios de una unidad de procesamiento de medios, MPU, que comprende datos de medios de los contenidos de medios, un segundo tipo de carga útil que indica que los datos de carga útil incluyen al menos un mensaje de señalización, un tercer tipo de carga útil que indica que los datos de carga útil incluyen un objeto genérico tal como una MPU completa o un objeto de otro tipo, y un cuarto tipo de carga útil que indica que los datos de carga útil incluyen un símbolo de reparación.

11. El aparato de la reivindicación 10, en el que, si la información (904) indica el primer tipo de carga útil, el encabezado (400) de carga útil comprende un campo (404) de tipo de fragmento, un primer campo (406), y un segundo campo (410),

indicando el campo (404) de tipo de fragmento un tipo de fragmento de los datos en los datos de carga útil de entre una pluralidad de tipos de fragmentos, incluyendo el primer campo (406) un valor que indica si se incluye más de 1 MPU en los datos de carga útil, e incluyendo el segundo campo (410) un valor que indica un número de al menos una carga útil que contiene al menos un fragmento de una misma MPU que sigue a los datos de carga útil, preferentemente en el que la pluralidad de tipos de fragmentos comprende un primer tipo de fragmento que indica que los datos de carga útil incluyen metadatos de la MPU, un segundo tipo de fragmento que indica que los datos de carga útil incluyen metadatos de un fragmento de película, y un tercer tipo de fragmento que indica que los datos de carga útil incluyen al menos una MFU, el campo (404) de tipo de fragmento indica uno de metadatos de la MPU, metadatos de un fragmento de película, y una MFU que comprende unos datos de medios temporizados o no temporizados, los metadatos de la MPU comprenden una casilla ftyp que incluye un tipo de un archivo, una casilla mmpu que incluye una configuración de la MPU, y una casilla moov que incluye información de configuración de códec, y los metadatos del fragmento de película comprenden una casilla moof que incluye información de encabezado de datos de medios y una porción de una casilla mdat.