ES2865448T3 - Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute - Google Patents

Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute Download PDF

Info

Publication number
ES2865448T3
ES2865448T3 ES15725119T ES15725119T ES2865448T3 ES 2865448 T3 ES2865448 T3 ES 2865448T3 ES 15725119 T ES15725119 T ES 15725119T ES 15725119 T ES15725119 T ES 15725119T ES 2865448 T3 ES2865448 T3 ES 2865448T3
Authority
ES
Spain
Prior art keywords
data
file
segment
corrupted
file segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15725119T
Other languages
English (en)
Inventor
Cédric Thienot
Feuvre Jean Le
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telecom ParisTech
Institut Mines Telecom IMT
Expway SA
Original Assignee
Telecom ParisTech
Institut Mines Telecom IMT
Expway SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telecom ParisTech, Institut Mines Telecom IMT, Expway SA filed Critical Telecom ParisTech
Application granted granted Critical
Publication of ES2865448T3 publication Critical patent/ES2865448T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Un procedimiento para recuperar un archivo, el procedimiento que se implementa en un receptor de datos, el procedimiento que comprende: recibir una porción de un segmento de archivo (SGM) transmitido según un protocolo de multidifusión desde un servicio de entrega de archivos, en el que recibir incluye recibir paquetes de símbolos y generar el segmento de archivo descodificando los paquetes de símbolos recibidos, y cuando los paquetes de símbolos recibidos comprenden símbolos de reparación, procesar los errores de transmisión utilizando los símbolos de reparación recibidos; y recibir una tabla de entrega de archivos, FDT, del servicio de entrega de archivos; caracterizado por que el segmento de archivo se divide en fragmentos de datos (mfrg) que se pueden procesar de forma independiente como el segmento de archivo, la porción de archivo comprende uno o más fragmentos de datos, el procedimiento que además comprende: leer en los datos de ubicación de la tabla de entrega de archivos (tlbi) que indican ubicaciones de los fragmentos de datos en el segmento de archivo recibido; y determinar a partir de los datos de ubicación las ubicaciones de los fragmentos de datos no corruptos en el segmento de archivo recibido.

Description

DESCRIPCIÓN
Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute
ANTECEDENTES DE LA INVENCIÓN
Los aspectos de la presente divulgación pueden relacionarse con la reducción de los efectos de los fallos de transmisión cuando se transmite contenido, por ejemplo de vídeo, en un entorno tal como la Transmisión Continua Adaptativa y Dinámica sobre HTTP (DASH) a través de un entorno de Entrega de Archivos sobre Transporte Unidireccional (FLUTE).
Las redes de comunicación inalámbrica están ampliamente implementadas para proporcionar diversos servicios de comunicación, tales como voz, vídeo, paquetes de datos, mensajería, radiodifusión, etcétera. Estas redes inalámbricas, en general, son redes de acceso múltiple capaces de admitir a múltiples usuarios compartiendo los recursos disponibles de la red.
Una red de comunicación inalámbrica puede incluir varias estaciones base que pueden admitir la comunicación para varios equipos de usuario, también denominados entidades móviles. Un equipo de usuario se puede comunicar con una estación base por medio de un enlace ascendente y de un enlace descendente. El enlace descendente (o enlace directo) se refiere al enlace de comunicación desde la estación base hasta el equipo de usuario, y el enlace ascendente (o enlace inverso) se refiere al enlace de comunicación desde el equipo de usuario hasta la estación base.
La Evolución a Largo Plazo (LTE) del Proyecto de colaboración de tercera generación (3GPP) representa un avance importante en la tecnología celular como una evolución natural del sistema global para comunicaciones móviles (GSM) y el sistema universal de telecomunicaciones móviles (UMTS). La capa física (PHY) de LTE proporciona una manera altamente eficaz de transportar información de datos y de control entre estaciones base y entidades móviles. En aplicaciones anteriores, un procedimiento para facilitar la comunicación de gran ancho de banda para multimedia ha sido la operación de red de frecuencia única (SFN). Las SFN utilizan transmisores de radio, como, por ejemplo, los de las estaciones base, para comunicarse con los equipos de los abonados. En la operación de unidifusión, cada estación base se controla para transmitir señales que transportan información dirigida a uno o más equipos de abonado particulares.
En la operación de radiodifusión, varias estaciones base de un área de radiodifusión pueden transmitir señales de forma sincronizada, transportando información que puede ser recibida y que es accesible por cualquier equipo de abonado en el área de radiodifusión. La generalidad de la operación de radiodifusión permite una mayor eficacia que el servicio de unidifusión en la transmisión de información de interés público general, por ejemplo, radiodifusiones multimedia relacionadas con eventos. A medida que ha aumentado la demanda y la capacidad del sistema para los servicios multimedia relacionados con eventos y otros servicios de radiodifusión, los operadores del sistema han mostrado un interés creciente en aprovechar la operación de radiodifusión en las redes 3GPP.
La transmisión de contenido, como contenido de vídeo, se puede realizar mediante diversos procedimientos en las redes de comunicación. En el caso del contenido de vídeo, por ejemplo, la transmisión de información de vídeo desde una fuente de vídeo a un visualizador se puede realizar mediante transmisiones de unidifusión o transmisiones de multidifusión/radiodifusión. Las transmisiones de unidifusión se dirigen a un dispositivo de recepción específicamente dirigido. Para obtener una transmisión de unidifusión, un dispositivo de destino puede tener un localizador uniforme de recursos (URL) con la dirección de la fuente de vídeo y puede generar un comando GET HTTP que puede enviar a la fuente de vídeo (típicamente un servidor) para facilitar la descarga del archivo de vídeo.
Un procedimiento conocido para la transmisión de vídeo en un entorno de unidifusión es a través de la Transmisión Continua Adaptativa y Dinámica sobre HTTP (DASH). El uso de DASH en unidifusión obtiene el archivo completo. DASH puede convertir el archivo de vídeo en componentes más pequeños llamados segmentos DASH, que se pueden volver a ensamblar en el dispositivo de recepción para visualizar el vídeo deseado.
Las transmisiones de multidifusión o radiodifusión, como en el servicio evolucionado de multidifusión/radiodifusión multimedia (eMBMS), presentan diferentes consideraciones, ya que las transmisiones se envían a múltiples dispositivos de recepción. En estos entornos, los dispositivos de recepción pueden obtener información antes de que el sistema asociado realmente tome medidas para obtener esa información. El dispositivo de recepción puede almacenar esa información recibida en una memoria caché local. Cuando el sistema (típicamente en la capa de aplicación) genera una URL para obtener la información, la URL generada puede apuntar al contenido que ya se encuentra en la memoria caché local, en lugar de en el lado del servidor como ocurre en el entorno de unidifusión.
DASH, en combinación con la Entrega de Archivos sobre Transporte Unidireccional (FLUTE) se puede utilizar en entornos de multidifusión. Según dicha combinación, el contenido de vídeo puede convertirse en segmentos DASH, y pequeños grupos de segmentos DASH se pueden acumular mediante un motor de paquetes FLUTE (FPE), que a su vez puede convertir los segmentos DASH en paquetes FLUTE para su transmisión. La estructura de los segmentos DASH se ajusta al formato de archivo de medios de base ISO (ISOBMFF). Según ISOBMFF, un segmento se divide en cuadros. Un fragmento de película comprende al menos un cuadro de encabezado llamado "moof por "fragmento de película" (movie fragment en inglés), asociado con un cuadro de datos llamado "mdat" por "datos de película" (movie data en inglés), el cuadro moof que especifica la estructura del cuadro mdat.
DASH, y la mayoría de las tecnologías de transmisión continua adaptativa basadas en ISOBMFF, normalmente supone una capa de transporte libre de errores. Sin embargo, las implantaciones como eMBMS pueden depender del Protocolo de datagramas de usuario (UDP) de multidifusión u otras capas de enlace de datos de radiodifusión como DVB-GSE (Radiodifusión de vídeo digital - Encapsulación de flujo genérico) para la entrega de segmentos DASH. Aunque las técnicas de codificación de corrección de errores como FEC (Corrección de Errores hacia Adelante) se utilizan mucho en estos entornos, la pérdida de un paquete completo no se aborda en un receptor de eMBMS/FLUTE/DVB.
La solicitud de patente US 2013/254611 describe un servicio para entregar segmentos de archivo multimedia que incluyen mecanismos de corrección de errores de datos.
En el peor de los casos, cuando se detecta una pérdida, el segmento DASH corrupto se considera perdido y la sesión DASH tendrá una interrupción de reproducción prolongada. Sin embargo, una sesión DASH basada en el protocolo del flujo de transporte (TS) MPEG-2 no sufriría dicha pérdida, ya que el TS está diseñado para entornos con pérdidas, es decir, la pérdida de algunos paquetes TS no corromperá todo el segmento. En el caso de una sesión DASH basada en el formato ISOBMFF, cuando la pérdida solo se encuentra en una parte de datos (cuadro mdat) de un segmento, solo se pierden unas pocas muestras (o incluso algunos bloques de un fragmento de vídeo) y el resto del segmento es utilizable. Por el contrario, cuando la pérdida se encuentra en una parte del encabezado (cuadro moof), el final del segmento que va después del cuadro corrupto no es utilizable. Si el dispositivo de recepción está acoplado a un lector de segmento y, por lo tanto, no procesa el segmento DASH, la información de pérdida debe comunicarse al lector de segmento. Dichas pérdidas se pueden gestionar por el dispositivo de recepción.
Sin embargo, es muy probable que un dispositivo de recepción basado en MSE (Extensión de fuentes de medios), JavaScript y HTML5 no sepa nada sobre el protocolo de entrega subyacente, ya sea HTTP de banda ancha o FLUTE. Además, el dispositivo de recepción podría ser un dispositivo diferente al reproductor multimedia, por ejemplo, un eMBMS DASH conectado a un repetidor Wifi. En ambos casos, puede que no sea deseable que el dispositivo de recepción gestione el reformateo de un segmento corrupto, por razones de complejidad. Además, reformatear un segmento corrupto haría imposible la reparación adicional del segmento por un dispositivo de terceros, puesto que no tendría conocimiento de la pérdida.
Además, hay casos en los que los datos corruptos se encuentran dentro de un cuadro de encabezado moof, lo que hace que el cuadro y, en consecuencia, el resto (cuadro mdat) del fragmento de película, sean inutilizables. Sin embargo, si el segmento no está hecho de un solo fragmento (un solo cuadro moof asociado con un solo cuadro mdat), sino de varios fragmentos, cada uno de los cuales comprende un cuadro moof y un cuadro mdat asociado, algunos otros fragmentos podrían estar intactos después del cuadro corrupto. En caso de que los datos de tamaño en el cuadro moof corrupto estén corruptos, todos los fragmentos (cuadros moof y mdat) que van después del cuadro moof corrupto se perderán puesto que las posiciones en el segmento de los cuadros moof no se pueden determinar.
Por tanto, es deseable gestionar fragmentos parcialmente corruptos. Es deseable además gestionar el caso de un segmento compuesto por múltiples fragmentos con un fragmento parcial o totalmente corrupto, para permitir el procesamiento de fragmentos no corruptos que van después de un fragmento corrupto dentro de un segmento. También es deseable respetar las implantaciones DASH existentes y, por lo tanto, asegurar una compatibilidad con versiones anteriores para evitar alterar o hacer inoperativa la función del equipo de usuario existente que gestiona segmentos corruptos o no corruptos.
BREVE COMPENDIO DE LA INVENCIÓN
La invención se refiere a un procedimiento implementado por un receptor de datos como se define más adelante en la reivindicación 1, un receptor de datos como se define más adelante en la reivindicación 10, un procedimiento implementado por un transmisor de datos, como se define más adelante en la reivindicación 11, y un transmisor de datos como se define más adelante en la reivindicación 14, para permitir el procesamiento de fragmentos de datos no corruptos dentro de un segmento de archivo.
Según una realización, el procedimiento comprende: detectar datos corruptos en los fragmentos de datos; y eliminar uno de los fragmentos de datos del segmento de archivo cuando contiene datos corruptos.
Según una realización, el procedimiento comprende: detectar datos corruptos en los fragmentos de datos recibidos; y cuando uno de los fragmentos de datos contiene datos corruptos, encapsular el fragmento de datos en un cuadro contenedor que comprende datos de carga útil que incluyen la porción de contenido con datos corruptos y datos de encabezado que incluyen datos de ubicación para ubicar los datos corruptos en el segmento de archivo.
Según una realización, el procedimiento comprende: determinar un tipo de cuadro contenedor a partir de los datos de encabezado, el tipo de cuadro contenedor que indica que el cuadro contenedor contiene datos corruptos; determinar los datos de ubicación en los datos de encabezado; determinar a partir de los datos de ubicación en los datos de encabezado las ubicaciones de los datos no corruptos del fragmento de datos en los datos de carga útil; y utilizar los datos no corruptos.
Según una realización, el procedimiento comprende: insertar en los datos de encabezado del cuadro contenedor que contiene los datos corruptos, los datos de ubicación leídos en la tabla de entrega de archivos.
Según una realización, el procedimiento comprende: leer los datos de ubicación en los datos de encabezado del cuadro contenedor, utilizar los datos de ubicación para recuperar los fragmentos de datos en el segmento de archivo; y utilizar los datos en los fragmentos de datos recuperados.
Según una realización, el procedimiento comprende insertar en los datos de encabezado del cuadro contenedor que contiene los datos corruptos, una dirección de ubicación en la que el segmento de archivo está disponible para su descarga.
Según una realización, el segmento de archivo se transmite según un protocolo de red de transmisión continua con tasa de bits adaptativa, como la transmisión continua adaptativa y dinámica sobre HTTP (DASH).
Según una realización, el servicio de entrega de archivos comprende la Entrega de Archivos sobre Transporte Unidireccional (FLUTE).
Según una realización, el contenido se transmite según un protocolo de red de transmisión continua con tasa de bits adaptativa, como la transmisión continua adaptativa y dinámica sobre HTTP (DASH).
BREVE DESCRIPCIÓN DE LAS DISTINTAS VISTAS DE LOS DIBUJOS
El resumen anterior, así como la siguiente descripción detallada de la invención, se comprenderán mejor cuando se lean junto con los dibujos adjuntos. Con el propósito de ilustrar la invención, se muestran en los dibujos realizaciones que son actualmente preferidas. Debe entenderse, sin embargo, que la invención no se limita a las disposiciones e instrumentos exactos que se muestran.
En los dibujos:
la Figura 1 es un diagrama de bloques de un sistema que proporciona un servicio de radiodifusión o multidifusión de datos multimedia a través de una red,
la Figura 2 es un diagrama de bloques de una vista detallada del sistema de la Figura 1,
la Figura 3 es un diagrama de bloques que ilustra elementos de contenido multimedia de ejemplo,
la Figura 4 es un diagrama de bloques que ilustra un segmento multimedia DASH ejemplar,
la Figura 5 es un diagrama de bloques que ilustra un cuadro contenedor que encapsula datos corruptos, según una realización,
la Figura 6 es un diagrama de bloques de un equipo de usuario según otra realización.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
La descripción detallada expuesta a continuación, en relación con los dibujos adjuntos, pretende ser una descripción de diversas configuraciones y no pretende representar las únicas configuraciones en las cuales se pueden llevar a la práctica los conceptos descritos en la presente memoria. La descripción detallada incluye detalles específicos con el propósito de proporcionar un pleno entendimiento de los diversos conceptos. Sin embargo, resultará evidente a los expertos en la técnica que estos conceptos se pueden llevar a la práctica sin estos detalles específicos. En algunos casos, se muestran estructuras y componentes bien conocidos en forma de diagrama de bloques para no complicar dichos conceptos.
En general, esta divulgación se refiere a técnicas relacionadas con servicios de transmisión continua y entrega de archivos de datos multimedia, tales como datos de audio y vídeo, a través de una red. Estas técnicas, que se pueden utilizar junto con la transmisión continua adaptativa y dinámica sobre HTTP (DASH), incluyen datos de vídeo en transmisión continua, que se han encapsulado según el formato de archivo de medios de base ISO (ISOBMFF), utilizando un protocolo de radiodifusión o multidifusión sobre un servicio de entrega de archivos, como el protocolo de Entrega de Archivos sobre Transporte Unidireccional (FLUTE). FLUTE se basa en el protocolo de codificación asíncrona por capas (ALC), que proporciona un transporte fiable y, por lo tanto, FLUTE también puede denominarse FLUTE/ALC.
Los protocolos de entrega de archivos adicionales, que se pueden utilizar en lugar de FLUTE, incluyen FCAST y ALC/LCT sin procesar (por ejemplo, utilizando encabezados ALC y LCT para entregar atributos de archivo como atributos del tipo de archivo, la codificación y la compresión. FCAST se describe en Roca, "FCAST: Scalable Object Delivery for the ALC and n Or M protocols", IETF RMT Working Group, octubre de 2011. AlC se describe en Luby y col., "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, abril de 2010. LCT se describe en Luby y col., "Layered Coding Transport (LCT) Building Block", RFC 5651, octubre de 2009. Otros protocolos de descarga para la radiodifusión de archivos a gran escala incluyen el protocolo de carga del sistema IEEE 802.1 E, que difunde archivos en la capa MAC. En los sistemas de radiodifusión de TV móvil basados en IP, como DVB-H, ATSC-M/H, MBMS 3GPP (servicios de multidifusión y radiodifusión multimedia), BCMCS 3GPP2 (servicio de multidifusión y radiodifusión), los servicios de transmisión continua y entrega de archivos se entregan utilizando diferentes protocolos de transporte. La entrega de servicios de transmisión continua emplea RTP (según el RFC 3550), mientras que los servicios de entrega de archivos incluyen FLUTE/ALC (según el RFC 3926 y el RFC 5775, respectivamente). Los servicios de transmisión continua sobre HTTP adaptativa basados en unidifusión son actualmente la tecnología dominante en Internet para la entrega de vídeo, y se está estandarizando en 3GPP [TS 26.247] y MPEG [ISO/IEC FCD 23001 -6], en general denominado DASH (transmisión continua adaptativa y dinámica sobre HTTP).
La entrega de transmisión continua de radiodifusión también puede utilizar un servicio de entrega de archivos, como el protocolo FLUTE documentado en el RFC 6726. El servicio de entrega de archivos puede operar sobre un protocolo de control de acceso al medio (MAC) de radiodifusión, como el servicio de multidifusión y radiodifusión multimedia mejorado (eMBMS), que se basa en la tecnología LTE, o un protocolo de multidifusión como el IP multidifusión. Tanto la transmisión continua como el contenido de los archivos se transportan mediante un único protocolo de transporte de aplicaciones (por ejemplo, FLUTE). Además, al emplear DASH como la estructura del "archivo" de medios continuo para transportar contenido de transmisión continua en paquetes FLUTE/ALC, la continuidad del servicio desde la radiodifusión a la entrega de unidifusión sencillamente implica una conmutación de transportar segmentos DASH sobre FLUTE/radiodifusión a HTTP/unidifusión.
El formato de archivo de medios de base ISO (ISOBMFF) está diseñado para contener la información temporizada de medios para una presentación en un formato flexible y extensible que facilite el intercambio, la gestión, la edición y la presentación de los medios. El formato ISOBMFF (ISO/IEC 14496-12:2012), que se especifica en la norma MPeG-4 Parte-12, define una estructura general para los archivos de medios basados en el tiempo. Se usa como la base para otros formatos de archivo en la familia, tales como el soporte definido del formato de archivo AVC (ISO/IEC 14496-15) para la compresión de vídeo de la norma AVC H.264/MPEG-4, el formato de archivo 3GPP, el formato de archivo SVC y el formato de archivo MVC. El formato de archivo 3GPP y el formato de archivo MVC son extensiones del formato de archivo AVC. El formato ISOBMFF contiene la temporización, la estructura y la información de medios para las secuencias temporizadas de datos multimedia, tales como las presentaciones audiovisuales. La estructura del archivo, en general, está orientada a objetos. Un archivo puede descomponerse en objetos básicos muy sencillamente y la estructura de los objetos está implícita a partir de su tipo.
Los archivos que se ajustan al formato ISOBMFF (y las extensiones del mismo) pueden formarse como una serie de objetos, llamados "cuadros", que son bloques componentes orientados a objetos definidos por un identificador de tipo único y datos de longitud definidos en el formato ISOBMFF y también contenidos en cuadros, de manera que no sea necesario contener otros datos dentro del archivo y no es necesario que haya datos fuera de los cuadros dentro del archivo. Típicamente, una presentación multimedia está contenida en un archivo y la presentación multimedia está autocontenida. El contenedor de la película (cuadro de película) puede contener los metadatos de los medios, y las tramas de vídeo y audio pueden estar contenidas en el contenedor de datos multimedia y podrían estar en otros archivos. Una representación (secuencia de movimiento) puede estar contenida en varios archivos, también denominados segmentos en DASH. La información de temporización y entramado (posición y tamaño) se encuentra, en general, en el archivo de medios de base ISO y los archivos auxiliares pueden utilizar fundamentalmente cualquier formato. Esta representación puede ser “local” al sistema que contenga la representación, o puede proporcionarse a través de una red u otro mecanismo de suministro de transmisión continua.
La Figura 1 representa un sistema que proporciona servicios de transmisión continua de multidifusión radiodifusión y/o entrega de archivos de datos multimedia MBMS (servicio de multidifusión y radiodifusión multimedia). Este sistema comprende uno o más servidores de contenido CNTP, una o más redes IPN como Internet, uno o más servidores MBMS que implementa(n) un servicio MBMS o eMBMS, enlazado(s) a uno de los servidores CNTP a través de una de las redes IPN, una o más puertas de enlace MGW entre el servidor MBMS y las redes móviles UTRN, y los dispositivos de usuario o cliente UE, conectados cada uno a una de las redes móviles UTRN. Uno de los servidores CNTP transmite contenido multimedia, por ejemplo según MPEG-DASH.
La Figura 2 es un diagrama de bloques detallado ejemplar del sistema de la Figura 1. En este ejemplo, el servidor CNTP comprende una fuente de audio AS y una fuente de vídeo VS. La fuente de audio AS puede comprender, por ejemplo, un micrófono que produce señales eléctricas representativas de datos de audio captados que un codificador de audio AENC va a codificar. De forma alternativa, la fuente de audio AS puede comprender un medio de almacenamiento que almacena datos de audio previamente registrados, un generador de datos de audio tal como un sintetizador informatizado, o cualquier otra fuente de datos de audio. La fuente de vídeo VS puede comprender una cámara de vídeo que produce datos de vídeo que han de ser codificados por el codificador de vídeo VENC, un medio de almacenamiento codificado con datos de vídeo previamente grabados, una unidad de generación de datos de vídeo tal como una fuente de gráficos por ordenador, o cualquier otra fuente de datos de vídeo. El servidor CNTP no está necesariamente acoplado de forma comunicativa al servidor MBMS en todos los ejemplos, pero puede almacenar contenido multimedia en un medio separado que es leído por el servidor MBMS.
Los datos de audio y vídeo sin procesar producidos por las fuentes de audio y vídeo pueden comprender datos analógicos o digitales. Los datos analógicos se pueden digitalizar antes de que el codificador de audio AENC y/o el codificador de vídeo VENC los codifiquen. La fuente de audio AS puede comprender un medio de almacenamiento legible por ordenador que comprende datos de audio almacenados, y la fuente de vídeo VS puede comprender un medio de almacenamiento legible por ordenador que comprende datos de vídeo almacenados. De esta manera, las técnicas descritas en esta divulgación se pueden aplicar a la transmisión continua en directo y en tiempo real de datos de audio y vídeo, o de datos de audio y vídeo archivados y preregistrados.
El codificador de audio AENC en general produce un flujo de datos de audio codificados, mientras que el codificador de vídeo VENC produce un flujo de datos de vídeo codificados. Cada flujo individual de datos (ya sea de audio o vídeo) se denomina un flujo elemental. Un flujo elemental es un componente único, codificado digitalmente (posiblemente comprimido) de una representación. Por ejemplo, la parte de vídeo o audio codificado de la representación puede ser un flujo elemental. Un flujo elemental se puede convertir en un flujo elemental paquetizado (PES) antes de encapsularse dentro de un archivo de vídeo. Los datos de vídeo codificados en general corresponden a flujos de vídeo elementales. De forma similar, los datos de audio corresponden a uno o más flujos elementales respectivos. El codificador de vídeo VENC puede aplicar un procesamiento de compresión a los datos de vídeo Vídeo un procesamiento de compresión según una norma de compresión como la UIT-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 parte 10.
En el ejemplo de la Figura 2, el servidor CNTP comprende una unidad de encapsulación ENCM que recibe flujos elementales que comprenden datos de vídeo codificados del codificador de vídeo VENC y datos de audio codificados del codificador de audio AENC. La unidad de encapsulación ENCM forma las correspondientes unidades de capa de abstracción de red a partir de los flujos elementales. La unidad de encapsulación ENCM puede proporcionar datos para una o más representaciones de contenido multimedia, junto con un archivo de manifiesto (por ejemplo, el MPD) a una interfaz de salida OINT. La interfaz de salida OINT puede comprender una interfaz de red o una interfaz para escribir en un medio de almacenamiento, como una interfaz de bus serie universal (USB), una grabadora de CD o DVD, una interfaz para medios de almacenamiento magnéticos o flash, u otras interfaces para almacenar o transmitir datos multimedia. La unidad de encapsulación ENCM puede proporcionar datos de cada una de las representaciones de un contenido multimedia correspondiente a la interfaz de salida OINT, que puede enviar los datos al servidor MBMS a través de medios de transmisión o almacenamiento de red.
El servidor MBMS puede implementar uno o más protocolos de radiodifusión o multidifusión para radiodifundir o multidifundir datos multimedia. En el ejemplo de la Figura 2, el servidor MBMS puede incluir un medio de almacenamiento que almacena diversos contenidos multimedia MCNT, una unidad de procesamiento de peticiones RQPU 70 y una interfaz de red FSND. En algunos ejemplos, el servidor MBMS puede incluir una pluralidad de interfaces de red, incluida la interfaz de red FSND. Además, cualquiera o todos los rasgos característicos del dispositivo servidor MBMS pueden implementarse en otros dispositivos de una red de distribución de contenido, tales como encaminadores, puentes, dispositivos proxy, conmutadores u otros dispositivos. En algunos ejemplos, los dispositivos intermedios de una red de distribución de contenido pueden almacenar datos de contenido multimedia MCNT en memoria caché e incluir componentes que se ajustan sustancialmente a los del servidor MBMS. En general, la interfaz de red FSND está configurada para enviar y recibir datos a través de la red IPN.
En el ejemplo de DASH, puede haber múltiples representaciones para un contenido multimedia. El manifiesto de dichas representaciones se define en una estructura de datos MPD de Descripción de Presentación de Medios. Una presentación multimedia puede corresponderse con una recopilación de datos estructurados que es accesible para un dispositivo cliente que transmite en continuo sobre HTTP. El dispositivo cliente que transmite en continuo sobre HTTP puede solicitar y descargar la información de datos multimedia para presentar un servicio de transmisión continua a un usuario del dispositivo cliente. La estructura de datos MPD describe las características de codificación y reproducción de cada representación. Además, un dispositivo servidor puede proporcionar datos que describen las características de una radiodifusión o multidifusión, por ejemplo, para proporcionar información suficiente para que un dispositivo cliente reciba la radiodifusión o multidifusión. Por ejemplo, los datos pueden incluir una dirección de multidifusión que los dispositivos cliente pueden utilizar para unirse a la multidifusión.
El contenido multimedia MCNT puede incluir un archivo de manifiesto y una o más representaciones. En algunos ejemplos, las representaciones pueden separarse en conjuntos de adaptación. Es decir, diversos subconjuntos de representaciones pueden incluir respectivos conjuntos comunes de características. El archivo de manifiesto puede incluir datos indicativos de los subconjuntos de representaciones correspondientes a conjuntos de adaptación particulares, así como características comunes para los conjuntos de adaptación. El archivo de manifiesto también puede incluir datos representativos de características individuales, como tasas de bits, para representaciones individuales de los conjuntos de adaptación. De esta manera, un conjunto de adaptación puede proporcionar una adaptación de ancho de banda de red simplificada. Las representaciones en un conjunto de adaptación se pueden indicar utilizando elementos secundarios de un elemento de conjunto de adaptación del archivo de manifiesto.
La unidad de procesamiento de peticiones RQPU está configurada para recibir peticiones de red desde dispositivos cliente UE, para contenido de datos MNCT. Por ejemplo, la unidad de procesamiento de peticiones RQPU puede implementar el protocolo de transferencia de hipertexto (HTTP) versión 1.1, como se describe en RFC 2616, "Hypertext Transfer Protocol-HTTP/1.1", de R. Fielding y col., Network Working Group, IETF, junio de 1999. Es decir, la unidad de procesamiento de peticiones RQPU se puede configurar para recibir peticiones GET HTTP o GET parciales, y proporcionar datos de contenido multimedia MCNT en respuesta a las peticiones. Las peticiones pueden especificar un segmento de una de las representaciones, por ejemplo, utilizando una URL del segmento. En algunos ejemplos, las peticiones también pueden especificar uno o más intervalos de bytes del segmento. En algunos ejemplos, los intervalos de bytes de un segmento se pueden especificar mediante peticiones GET parciales.
La unidad de procesamiento de peticiones RQPU se puede configurar además para atender peticiones HEAD HTTP para proporcionar datos de encabezado de un segmento de una de las representaciones. En cualquier caso, la unidad de procesamiento de las peticiones RQPU se puede configurar para procesar las peticiones para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente UE.
La interfaz de red FSND se puede configurar para recibir los segmentos DASH de la unidad de procesamiento de peticiones RQPU y convertirlos en paquetes FLUTE FP. La interfaz de red FSND puede fragmentar un segmento DASH en uno o más paquetes FLUTE. La conversión en paquetes FLUTE FP implica una codificación de FEC (corrección de errores hacia adelante) para codificar los segmentos DASH con datos redundantes que permiten la corrección de errores de transmisión. Para correlacionar los paquetes FLUTE FP con los segmentos DASH, la interfaz de red FSND puede asignar un Identificador de Objetos de la Transmisión (TOI) para cada segmento. Un segmento se puede considerar como un archivo y la URL del segmento puede ser el mismo que el nombre de un archivo FLUTE identificado por el TOI. La interfaz de red FSND puede generar una instancia de la Tabla de Entrega de Archivos (FDT) para describir los atributos de esos segmentos DASH. Los atributos de los segmentos DASH pueden incluir un nombre de archivo (especificado por, por ejemplo, una URL), un tipo de archivo (por ejemplo, el tipo de medio MIME del archivo), un tamaño del archivo, un compendio de mensajes del archivo (por ejemplo, MD5), información relativa al procesamiento de FEC y un formato de codificación del archivo. La tabla FDT puede transmitirse en uno o más de los paquetes FLUTE FP enviados por la interfaz de red FSND.
El dispositivo cliente UE puede comprender un receptor de archivos FREC, una aplicación web APP, una unidad de desencapsulación DECM y descodificadores y reproductores de contenido tales como descodificadores de audio y vídeo ADEC, VDEC y reproductores de audio y vídeo AP, VP. El receptor de archivos puede comprender un receptor FLUTE y un descodificador de FEC, para implementar un protocolo de entrega de archivos, como el protocolo FLUTE. De esta manera, el dispositivo cliente UE se puede configurar para recuperar datos del contenido multimedia MCNT utilizando radiodifusión o multidifusión a través del protocolo FLUTE. Para utilizar FLUTE como un servicio de entrega de archivos, el servidor MBMS puede insertar en la Tabla de Entrega de Archivos (FDT) atributos que indican uno o más localizadores uniformes de recursos (URL) de unidifusión para el contenido multimedia MCNT al dispositivo cliente UE. El receptor de archivos FREC puede recibir datos, ya sea por radiodifusión, multidifusión o unidifusión, enviados desde el dispositivo servidor MBMS (u otro dispositivo servidor). En particular, el receptor de archivos FREC puede recibir paquetes FLUTE, y proporcionar datos de segmentos recibidos de representaciones a la aplicación web APP. La aplicación web APP puede, a su vez, proporcionar los segmentos DASH a la unidad de desencapsulación DECM. La unidad de desencapsulación DECM puede desencapsular elementos de un archivo de vídeo transmitidos en segmentos de archivo en flujos constituyentes, desempaquetar los flujos para recuperar los datos codificados y enviar los datos codificados al descodificador de audio ADEC, o al descodificador de vídeo VDEC, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como se indica en las cabeceras de los paquetes del flujo. El descodificador de audio ADEC descodifica datos de audio codificados y envía los datos de audio descodificados al reproductor de audio VP, mientras que el descodificador de vídeo VDEC descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de vistas de un flujo al reproductor de vídeo VP.
La aplicación web APP puede comprender un navegador web ejecutado por una unidad de procesamiento basada en hardware del dispositivo cliente UE, o un complemento para dicho navegador web. Las referencias a la aplicación web APP en general deben entenderse que incluyen una aplicación web, como un navegador web, un reproductor de vídeo autónomo o un navegador web que incorpora un complemento de reproducción en el navegador web. La aplicación web APP puede recuperar datos de configuración dentro del dispositivo cliente UE para determinar las capacidades de descodificación de los descodificadores de audio y vídeo ADEC, VDEC y las capacidades de reproducción de los reproductores de audio y vídeo AP, VP.
Los datos de configuración también pueden incluir cualquiera o la totalidad de una preferencia de idioma seleccionada por un usuario del dispositivo cliente UE, una o más perspectivas de cámara correspondientes a las preferencias de profundidad establecidas por el usuario del dispositivo cliente UE, y/o una preferencia de clasificación seleccionada por el usuario del dispositivo cliente UE. La aplicación web APP puede comparar las capacidades de descodificación y reproducción del dispositivo cliente UE con las características de las representaciones indicadas en el archivo de manifiesto. La aplicación web APP puede recuperar inicialmente al menos una porción del archivo de manifiesto para determinar las características de las representaciones. Por ejemplo, la aplicación web APP puede solicitar una porción del archivo de manifiesto que describe las características de uno o más conjuntos de adaptación. La aplicación web APP puede seleccionar un subconjunto de representaciones (por ejemplo, un conjunto de adaptación) que tiene características que se pueden satisfacer mediante las capacidades de codificación y reproducción del dispositivo cliente UE. La aplicación web APP puede entonces determinar las tasas de bits para las representaciones en el conjunto de adaptación, determinar una cantidad de ancho de banda de red actualmente disponible, y recuperar segmentos (o intervalos de bytes) de una de las representaciones que tienen una tasa de bits que se puede satisfacer mediante el ancho de banda de la red.
La aplicación web APP se puede configurar para solicitar y recibir datos de radiodifusión o multidifusión enviados por el servidor MBMS. Por ejemplo, la aplicación web APP se puede configurar para recuperar inicialmente datos para el archivo de manifiesto, que pueden incluir datos para unirse a un grupo de multidifusión (tal como una dirección IP de grupo de multidifusión), o para recibir una radiodifusión (por ejemplo, datos para unirse a un dominio de radiodifusión o VLAN).
A veces, un usuario del dispositivo cliente UE puede interactuar con la aplicación web APP usando interfaces de usuario del dispositivo cliente UE, tal como un teclado, ratón, lápiz óptico, interfaz de pantalla táctil, botones u otras interfaces, para solicitar contenido multimedia como, por ejemplo, el contenido multimedia MCNT. En respuesta a dichas peticiones de un usuario, la aplicación web APP puede seleccionar una de las representaciones basándose, por ejemplo, en las capacidades de descodificación y reproducción del dispositivo cliente UE. Para recuperar datos de la representación seleccionada, la aplicación web APP puede solicitar secuencialmente intervalos de bytes específicos de la representación seleccionada. De esta manera, en lugar de recibir un archivo completo a través de una petición, la aplicación web puede recibir secuencialmente porciones de un archivo a través de múltiples peticiones.
Como se ha indicado anteriormente, las representaciones pueden incluir datos de vídeo de diversas características de codificación y reproducción. Las representaciones de un conjunto de adaptación pueden tener tasas de bits variables, lo que puede permitir la adaptación del ancho de banda. En las técnicas DASH convencionales, esto permite que un dispositivo cliente se adapte a la disponibilidad cambiante de ancho de banda recuperando datos de una representación que tiene una tasa de bits que puede adaptarse mejor a la cantidad actual de ancho de banda disponible.
La Figura 3 es un diagrama de bloques que ilustra elementos de contenido multimedia de ejemplo MCNT. En el ejemplo de la Figura 4, el contenido multimedia MCNT incluye una descripción de presentación multimedia MPD y una pluralidad de representaciones REP. Cada representación REP incluye datos de encabezado HDD opcionales y segmentos SGM. La descripción de presentación multimedia MPD puede comprender una estructura de datos separada de las representaciones REP. En general, la descripción de presentación multimedia MPD puede incluir datos que, en general, describen las características de las representaciones REP, tal como las características de codificación y representación (códec, perfil y nivel, resolución, número de vistas, formato de archivo para segmentos, información del tipo de texto que puede identificar un idioma u otras características del texto a visualizar con la representación, y/o datos de audio que se descodificarán y se presentarán, por ejemplo, por altavoces, información del ángulo de la cámara que puede describir un ángulo de la cámara o la perspectiva de la cámara del mundo real de una escena para representaciones en el conjunto de adaptación, información de clasificación que describe la idoneidad del contenido para públicos en particular, o similares), información de control de movimiento (p. ej., información indicativa de representaciones que incluyen subsecuencias temporales), y/o información para recuperar períodos remotos (p. ej. inserción de publicidad dirigida en el contenido multimedia durante la reproducción). Los períodos remotos también pueden denominarse períodos externos. La descripción de presentación multimedia MPD puede incluir características como se describen en la memoria descriptiva de 3GPP, con la incorporación de alguna o toda la información señalizada descrita en esta divulgación.
Como se ha indicado anteriormente, la descripción de presentación multimedia MPD puede ajustarse a un perfil de MPD en particular. Por tanto, la descripción de presentación multimedia MPD puede incluir información indicativa de un tipo de Extensión Multipropósito de Correo de Internet (MIME) para la descripción de presentación multimedia MPD y/o el contenido multimedia MCNT.
Los datos de encabezado HDD, cuando están presentes, pueden describir características de los segmentos SGM, por ejemplo, ubicaciones temporales de puntos de acceso aleatorio, cuál de los segmentos SGM incluye puntos de acceso aleatorio, desplazamientos de bytes a los puntos de acceso aleatorio dentro de los segmentos SGM, localizadores uniformes de recursos (URL) de segmentos SGM, u otros aspectos de los segmentos SGM. De forma adicional o alternativa, dichas características pueden incluirse completamente dentro de la descripción de presentación multimedia MPD.
Los segmentos SGM incluyen una o más muestras de vídeo codificadas, cada una de las cuales puede incluir tramas o fragmentos de datos de vídeo. Cada una de las muestras de vídeo codificadas de los segmentos SGM puede tener características similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Dichas características pueden describirse mediante datos de la descripción de presentación multimedia MPD. Cada uno de los segmentos SGM puede estar asociado con un identificador uniforme de recursos (URI) único, por ejemplo, un localizador uniforme de recursos (URL). Por tanto, cada uno de los segmentos SGM puede recuperarse de forma independiente utilizando un protocolo de red de transmisión continua, por ejemplo, DASH. De esta manera, un dispositivo de destino, como el dispositivo cliente UE, puede utilizar una petición GET HTTP para recuperar los segmentos SGM.
La Figura 4 es un diagrama de bloques que ilustra un segmento SGM de un archivo multimedia DASH ejemplar. El protocolo DASH se puede utilizar para transportar contenido multimedia de vídeo o audio en segmentos SGM de archivos multimedia DASH. El contenido multimedia de vídeo y audio se puede multiplexar en el mismo segmento de archivo multimedia DASH. Los segmentos SGM del archivo multimedia DASH pueden contener los siguientes campos o cuadros:
Tabla 1
Figure imgf000009_0001
Según el formato ISOBMFF, los cuadros comienzan con un encabezado que describe un tamaño y tipo. El encabezado puede permitir tamaños compactos o extendidos (por ejemplo, 32 o 64 bits) y tipos compactos o extendidos (por ejemplo, identificadores únicos universales completos (UUID) completos o de 32 bits). La mayoría de los cuadros, incluidos los cuadros estándar, pueden utilizar tipos compactos (32 bits). En una configuración, los cuadros del contenedor de datos multimedia mdat pueden ser los únicos cuadros que utilizan el tamaño de 64 bits. El tamaño es el tamaño de todo el cuadro, incluido el encabezado, los campos y los cuadros contenidos. Esto puede facilitar el análisis general del archivo.
Los cuadros de fragmentos de película moof y mdat forman un cuadro de fragmentos de película mfrg, ya que el cuadro mdat puede contener el contenido multimedia de un fragmento de película descrito en el cuadro moof asociado. El cuadro mdat puede contener muestras de vídeo VSPL y muestras de audio ASPL. En la transmisión continua de vídeo, por ejemplo, puede haber solo un par de cuadros moof y mdat en un segmento de archivo.
El cuadro de acceso aleatorio a fragmentos de película mfra puede proporcionar una tabla que puede ayudar al dispositivo cliente UE a encontrar puntos de acceso aleatorio en el segmento SGM del archivo multimedia DASH usando fragmentos de película. Puede contener un cuadro de acceso aleatorio a fragmento de pista tfra para cada pista proporcionada (que puede que no sean todas las pistas). Esto puede ser útil si el segmento SGM anterior del archivo está dañado, o cuando la reproducción comienza en medio de una transmisión continua de vídeo. El cuadro mfra puede colocarse en, o cerca de, el final del segmento de archivo SGM. El último cuadro dentro del cuadro mfra puede proporcionar una copia del campo de longitud.
Uno o más paquetes FLUTE FP pueden dañarse durante el proceso de transmisión. El receptor de archivos FREC puede utilizar técnicas de corrección de errores para intentar recuperar los paquetes dañados. Un ejemplo de estas técnicas que puede implementar el receptor de archivos FREC puede consistir en enviar varias apariciones de cada tabla de entrega de archivos (FDT) y utilizar corrección de errores hacia adelante FEC. Hay varios esquemas de FEC disponibles, incluidos Raptor (descrito en IETF RFC 5053), RaptorQ (descrito en IETF RFC 6330), etc. En cada esquema de FEC, la interfaz de red FSND puede transmitir símbolos de reparación FEC además de los símbolos fuente de FEC. Los símbolos fuente de FEC pueden incluir porciones del segmento de archivo multimedia DASH. Los símbolos de reparación de FEC pueden incluir datos adicionales que se pueden utilizar para reparar los símbolos fuente de FEC dañados. El receptor de archivos FREC puede intentar recuperar los símbolos fuente de FEC dañados utilizando los símbolos de reparación de FEC. En otra configuración, se puede utilizar un esquema de recuperación que evita la codificación y descodificación FEC para reducir el retardo de procesamiento, tal como el FEC Compacto Sin Codificación (descrito en IETF RFC 3695).
Sin embargo, puede suceder que el receptor de archivos FREC no pueda recuperar un segmento SGM del archivo multimedia DASH, o una parte del mismo después de la FEC. Esto, a su vez, puede hacer que el contenido multimedia se congele o se borre durante la reproducción por parte del reproductor AP, VP. Esto puede ser una desventaja de la transmisión continua, basada en DASH; es decir, la pérdida de una parte, incluso un solo byte, de un paquete FLUTE FP puede provocar la pérdida de un segmento SGM del archivo completo. Además, aunque se puede utilizar FEC para mejorar el rendimiento global, es posible que un dispositivo cliente UE todavía no reciba suficientes símbolos para descodificar satisfactoriamente un segmento SGM del archivo multimedia.
Según una realización, el receptor de archivos FREC está configurado para detectar datos corruptos cuando el descodificador de FEC no consigue corregir los errores de transmisión utilizando FEC. El receptor de archivos FREC se configura además para encapsular un cuadro moof o mdat detectado como corrupto en un cuadro contenedor específico. El cuadro corrupto puede estar total, o parcialmente, corrupto. En la Figura 5 se muestra un ejemplo de un pfcb de cuadro contenedor que encapsula datos corruptos. El cuadro contenedor pfcb comprende un encabezado CHD y una carga útil PCD que contiene el cuadro corrupto moof o mdat. El encabezado contiene un identificador de cuadro, un tamaño del bloque, un cuadro pcfb que contiene datos de índice y tamaño para ubicar los datos corruptos CD1, CD2 (y, por lo tanto, datos no corruptos) en el cuadro corrupto. Los datos corruptos CD1, CD2 pueden estar presentes o ausentes en la carga útil PCD, o ser sustituidos por bits de relleno (por ejemplo, un número de "0" o "1" correspondiente al tamaño de los datos corruptos). Si los datos corruptos se encuentran en un cuadro mdat, puede ser posible recuperar muestras de audio o vídeo no corruptas VSPL, ASPL contenidas en el cuadro mdat.
El encabezado CHD del cuadro contenedor pfcb también puede incluir un cuadro de la URL de origen que especifique una URL donde se puede encontrar el segmento SGM del archivo corrupto que contiene el cuadro moof o mdat parcialmente corrupto. La URL en el cuadro ourl se puede utilizar para solicitar el segmento corrupto nuevamente.
El encabezado CHD también puede incluir un recuadro tlbi que especifique los puntos de acceso o índices de todos los fragmentos de película mfrg (incluyendo un cuadro moof y un cuadro mdat) del segmento SGM del archivo que contiene los datos corruptos CD1, CD2. Los puntos de acceso especificados en la casilla tlbi se pueden extraer mediante el receptor FREC de la correspondiente Tabla de Entrega de Archivos FDT FLUTE recibida con el segmento SGM del archivo. Los índices de todos los fragmentos de película mfrg en un segmento SGM transmitido del archivo se pueden insertar en la tabla FDT del segmento mediante el servidor MBMS y, más particularmente, mediante la interfaz de red FSND.
Cada fragmento de película mfrg en un segmento SGM del archivo especifica su tamaño en bytes y, en consecuencia, define la posición del fragmento de película mfrg siguiente. Cuando un fragmento mfrg y, en particular, el tamaño del fragmento está corrupto, ya no es posible determinar la posición de un siguiente fragmento de película mfrg después de un fragmento de película mfrg corrupto en el segmento SGM del archivo corrupto. Gracias a los puntos de acceso especificados en el cuadro tlbi, se pueden recuperar los fragmentos de película mfrg no corruptos que van después de un fragmento de película corrupto en el segmento SGM del archivo corrupto.
Los índices insertados en la tabla FDT permiten que algunos receptores existentes eliminen fragmentos de película corruptos. En los casos en que el receptor actúa como servidor proxy DASH para un reproductor DASH, el receptor puede eliminar cualquier fragmento de película corrupto que contenga errores y crear un nuevo segmento que excluya estos fragmentos corruptos. El nuevo segmento incompleto se puede procesar adicionalmente mediante el reproductor DASH. La adición del cuadro contenedor pfcb que encapsula un fragmento corrupto no alterará este modo de funcionamiento puesto que el cuadro contenedor pfcb no será reconocido por los receptores existentes y, por lo tanto, será rechazado como un fragmento corrupto.
Los analizadores de los lectores del archivo, por ejemplo, la unidad de desencapsulación DECM, que no admiten este cuadro contenedor, no lo reconocerán y lo rechazarán, volviendo al comportamiento actual por medio del cual se pierde un segmento de archivo completo.
El cuadro contenedor pfcb está diseñado para la encapsulación rápida de datos corruptos (adición sencilla de bytes), y para no romper los analizadores existentes que desconocen la existencia de dicho cuadro contenedor. El cuadro contenedor pfcb, que no está presente en los segmentos del archivo original, se inserta típicamente tras la recepción parcial de un archivo. El cuadro contenedor pfcb se puede especificar en SDL (Lenguaje de Descripción de Sintaxis) de la siguiente manera:
aligned(8) class PartialFileContainerBox extends Box(’pfcb’) {
TopLevelBoxIndexBox toplevel; //optional
OriginalSourceURLBox source_url; //optional
PartiallyCorruptedFileBox corrupted_ranges; //mandatory
unsigned int(8) file_data[J; //until end of box
}
donde:
"toplevel" es un cuadro tlbi que especifica índices de cuadros de fragmentos mfrg que están presentes en el segmento SGM del archivo fuente. El cuadro tlbi puede estar ausente.
"source_url" es un cuadro de la URL de origen ourl que especifica la URL original del segmento de archivo antes de que se corrompa. Si está presente, los lectores del archivo pueden utilizarlo para reparar el archivo. Es posible que el cuadro ourl esté ausente.
"corrupted_ranges" es un cuadro pcfb que describe intervalos no válidos en la carga útil PCD. El cuadro pcfb está necesariamente presente en un cuadro pfcb.
"file_data" es la carga útil PCD que contiene el fragmento mfrg corrupto. Los lectores del archivo que conocen el procesamiento parcial del cuadro pueden analizar la carga útil PCD como un archivo ISOBMFF normal con intervalos de bytes potencialmente corruptos especificados por el cuadro pfcb.
El cuadro de intervalos corruptos pcfb se puede especificar en SDL de la siguiente manera:
aligned(8) class PartiallyCorruptedFileBox
extends FulIBoxCpcfb’, versión, flags) {
i f (versión— 1) {
unsigned int(64) source_byte_offset;
} else {
unsigned int(32) source_byte_offset;
}
unsigned int(32) entry_count;
for (i=0; i < entry_count; i++) {
if (version==1) {
unsigned int(64) byte_offset;
} else {
unsigned int(32) byte_offset;
}
unsigned int(32) corrupted_size;
}
}
donde:
"version" especifica una versión de este cuadro.
"flags" especifica el indicador siguiente para este cuadro:
PCFB_SIN_RELLENAR = 0x000001
"source_byte_offset" especifica el desplazamiento de bytes en el archivo fuente del primer byte de la carga útil PCD del cuadro matriz pfcb. Por lo general, es 0 cuando el cuadro encapsula un archivo completo o un segmento de película, pero puede ser diferente en los casos en que el cuadro encapsula solo fragmentos de película corruptos de un segmento de película. Este desplazamiento se utiliza, típicamente, al reconstruir el fragmento de película corrupto. "entry_count" especifica un número de intervalos de bytes corruptos que están presentes en la carga útil PCD del cuadro matriz pfcb.
"byte_offset" especifica un desplazamiento de bytes, comenzando desde el primer byte de la carga útil PCD del cuadro matriz pfcb, del comienzo del intervalo corrupto en la carga útil PCD. Si se especifica la versión 1, se utilizan desplazamientos de datos de 64 bits. De lo contrario, se utilizan desplazamientos de datos de 32 bits. Si se establece PCFB_SIN_RELLENAR, cada uno de los intervalos de bytes corruptos no está presente en la carga útil PCD del cuadro matriz pfcb. De lo contrario, los datos corruptos están en la carga útil PCD del cuadro matriz pfcb.
"corrupted_size" especifica el tamaño del intervalo de datos corruptos en la carga útil PCD.
"para (i = 0; i < entry_count; i +)" indica que hay un " byte_offset " y un " corrupted_size” correspondiente para cada uno de los intervalos de bytes corruptos "entry_count ".
Cuando una carga útil PCD no está rellena, un lector del archivo (por ejemplo, la unidad de desencapsulación DECM) puede rellenar el intervalo de datos corruptos al analizar el archivo, o ajustar su análisis de cuadros y gestión de los desplazamientos de datos.
El cuadro tlbi se utiliza para indicar uno o varios desplazamientos de cuadro de nivel superior (nivel de archivo) en el segmento de archivo original. Este cuadro se puede extraer a partir de la tabla FDT de una sesión FLUTE. Este cuadro permite que un lector de archivos vuelva a sincronizar el análisis del cuadro en caso de que los datos corruptos afecten a uno de los cuadros moov en el segmento de archivo original. El cuadro contenedor tlbi puede especificarse en SDL de la siguiente manera:
al¡gned(8) class TopLevelBoxIndexBox extends FullBox('tlb¡‘, versión, 0) {
unsigned int(32) entry_count;
for (i=0; i < entry_count; i++) {
íf (version==1) {
unsigned int(64) box_offset;
} else {
unsigned int(32) box_offset;
}
}
}
donde:
"version" especifica la versión de este cuadro.
"entry_count" especifica un número de cuadros de fragmentos que están presentes en el segmento de archivo original.
"box_offset" especifica el desplazamiento de bytes, comenzando desde el primer byte de la carga útil PCD del cuadro matriz pfcb, de un cuadro de fragmento mfrg que está presente en el segmento de archivo original. Este desplazamiento se puede utilizar para volver a sincronizar el análisis después de la pérdida de datos. Si se utiliza la versión 1, se utilizan desplazamientos de datos de 64 bits. De lo contrario, se utilizan desplazamientos de datos de 32 bits.
El cuadro ourl se utiliza para indicar la URL de origen del archivo antes de que se corrompa. Típicamente, el receptor del archivo lo inserta en el cuadro pfcb y un lector del archivo puede utilizarlo para reparar el archivo. El cuadro contenedor ourl puede especificarse en SDL de la siguiente manera:
aligned(8) class OriginalSourceURLBox extends FulIBox(‘ourl', 0, 0) {
string url;
}
donde:
"url" especifica la URL de origen de donde se ha recuperado el archivo corrupto. Esto puede identificar la red física o una URL alternativa donde se puede encontrar el archivo.
Según una realización, se puede definir un nuevo tipo de atributo y se puede añadir un nuevo atributo de este tipo de atributo al tipo FileType en el esquema de XML FLUTE de la estructura de la tabla FDT. Este atributo llamado "IndependentUnitLocations" o "RandomAccessLocation" representa una lista no vacía de ubicaciones de bytes, cada una de las cuales es la ubicación del primer byte de una unidad independiente (típicamente las ubicaciones de los cuadros moof). En el caso de un archivo MPEG4, transportará diferentes valores contenidos en el cuadro tlbi. El nuevo tipo de atributo (IndependentUnitLocations-Type o RandomAccessLocation-Type) se puede definir en el esquema XML de la estructura de la tabla FDT de la siguiente manera:
<xs:schema
<xs:attríbute /?ame="lndependentUnitLocat¡ons" type-1ndependentUnitLocations-7ype7>
<xs:simpleType /7ame="lndependentUnitLocat¡ons-Type">
<xs:list itemType="xs:uns¡gnedLong"/>
</xs:simpleType>
</x s:schema>
Se puede definir un nuevo atributo (IndependentUnitLocations) en el esquema XML de la tabla FDT de la siguiente manera: <xs:schema <xs:complexType name="FDT-InstanceType"> <xs:attribute ref="mbms2015: IndependentUnitLocations" use="optional"/> </xs:complexType> </xs:schema> donde "IndependentUnitLocations" se puede sustituir por "RandomAccessLocation".
Una unidad independiente es el fragmento de bytes entre dos entradas consecutivas en la lista IndependentUnitLocations, excepto por la última unidad independiente que va desde la última entrada en la lista hasta el final del archivo (por ejemplo, un segmento de archivo). Cuando el atributo IndependentUnitLocations está presente, significa que el archivo está compuesto de unidades independientes. Un archivo está compuesto de unidades independientes si, después de crear un archivo desde el archivo original eliminando una o más unidades independientes:
a) se pueden procesar las unidades independientes restantes;
b) el archivo que se crea todavía se puede procesar como un archivo del tipo dado, es decir, que cualquier concatenación en orden de cualquier conjunto no vacío de unidades independientes es una unidad de datos válida.
Si se produce una pérdida no recuperable en un archivo, es posible crear un nuevo archivo eliminando las unidades independientes a las que les faltan uno o más bytes. Si se utiliza esta técnica, la aplicación MBMS debe saber que el archivo está incompleto.
Por tanto, las ubicaciones de los cuadros moof de un segmento SGM del archivo se pueden insertar en la tabla FDT en el lado transmitido por la interfaz de red FSND, y recuperarse a partir de la tabla FDT. Si se detectan datos corruptos y se encapsulan en un cuadro contenedor pfcb, en el lado del receptor, las ubicaciones de los cuadros moof en el segmento SGM del archivo se insertan en el cuadro contenedor pfcb.
La lista de datos de ubicación de los cuadros moof en un segmento SGM del archivo puede actualizarse durante una actualización de una tabla FDT para una sola película. Esto permite la recuperación progresiva de los puntos de análisis en el lado del receptor sin tener que esperar a la lista completa de desplazamientos, que solo se conocen una vez que se recibe y se produce todo el segmento de archivo a partir de los paquetes FLUTE. Al construir progresivamente esta lista, es posible combinar el envío de baja latencia del segmento subdividido en fragmentos de película, y técnicas de recuperación de errores habilitadas al encapsular datos corruptos como se describe anteriormente. Por lo tanto, el receptor podrá reenviar el fragmento de película inmediatamente después de recibirlo si no se detectan datos corruptos, o esperar a que la lista actualizada de desplazamientos se recupere de lo contrario, y encapsular el (los) fragmento(s) de película corrupto(s) en un cuadro pfcb que indique (en el cuadro tlbi) los intervalos de bytes corruptos y los desplazamientos de bytes originales de los fragmentos de película en el segmento de película. Cuando las tablas FDT se actualizan a una frecuencia de actualización cercana a la duración de reproducción del fragmento de película, el mecanismo de recuperación de errores no presenta ningún retardo.
En uno o más ejemplos, los sistemas y procedimientos descritos pueden aplicarse a otro contenido distinto del contenido multimedia, transmitido en archivos.
En uno o más ejemplos, las realizaciones pueden referirse a un procedimiento de recuperación de datos de archivo, el procedimiento que comprende:
recuperar una porción de un contenido transmitido según un protocolo de multidifusión a través de un servicio de entrega de archivos;
detectar datos corruptos en la porción del contenido; y
encapsular la porción del contenido multimedia en un cuadro contenedor, el cuadro contenedor que tiene datos de encabezado y datos de carga útil que incluyen la porción del contenido, los datos de encabezado que comprenden datos de ubicación para ubicar los datos corruptos en la porción del contenido multimedia.
Según una realización, el procedimiento comprende recibir el cuadro contenedor, determinar un tipo de cuadro contenedor a partir de los datos de encabezado, el tipo de cuadro contenedor que indica que el cuadro contenedor contiene datos corruptos; determinar los datos de ubicación en los datos de encabezado; determinar a partir de los datos de ubicación en los datos de encabezado las ubicaciones de los datos no corruptos de la porción de contenido en los datos de carga útil; y utilizar los datos no corruptos.
Según una realización, el contenido comprende fragmentos de datos que forman un segmento de archivo, y la porción del contenido que contiene datos corruptos es un fragmento de datos.
Según una realización, el procedimiento comprende insertar en los datos de encabezado del cuadro contenedor que contiene los datos corruptos, atributos de ubicación que indican ubicaciones de los fragmentos de datos en el segmento de archivo.
Según una realización, el procedimiento comprende insertar en los datos de encabezado del cuadro contenedor que contiene los datos corruptos, una dirección de ubicación en la que el segmento de archivo está disponible para su descarga.
Según una realización, el archivo contiene datos transmitidos según un protocolo de red de transmisión continua con tasa de bits adaptativa, como la transmisión continua adaptativa y dinámica sobre HTTP (DASH).
Según una realización, el servicio de entrega de archivos comprende la Entrega de Archivos sobre Transporte Unidireccional (FLUTE), el procedimiento comprende además recibir una tabla de entrega de archivos (FDT) a partir de servicio de entrega de archivos y paquetes de datos que forman un segmento de archivo que comprende fragmentos de datos.
Según una realización, el procedimiento comprende leer en la tabla de entrega de archivos atributos de ubicación que indican ubicaciones de los fragmentos de datos en el segmento de archivo; e insertar los atributos de ubicación que indican las ubicaciones de los fragmentos de datos en los datos de encabezado del cuadro contenedor.
En uno o más ejemplos, los sistemas descritos pueden comprender como se muestra en la Figura 6 un primer dispositivo de usuario UD1 que comprende el receptor de archivos FREC y la aplicación web APP, y un segundo dispositivo de usuario UD2 en comunicación con el dispositivo UD1 y que comprende la unidad de desencapsulación DECM y descodificadores y reproductores de contenido tales como los descodificadores de audio y vídeo ADEC, VDEC y los reproductores de audio y vídeo AP, VP. Por tanto, las realizaciones pueden referirse a un dispositivo de usuario (UD2) configurado para:
recibir un archivo que comprende fragmentos de datos, un fragmento de datos que está encapsulado en un cuadro contenedor que comprende datos de carga útil que incluyen datos corruptos y datos de encabezado que incluyen datos de ubicación para ubicar los datos corruptos y los datos no corruptos en los datos de carga útil; determinar un tipo de cuadro contenedor a partir de los datos de encabezado, el tipo del cuadro contenedor que indica que el cuadro contenedor contiene datos corruptos; determinar los datos de ubicación en los datos de encabezado; localizar los datos no corruptos en los datos de carga útil utilizando los datos de ubicación en los datos de encabezado; y utilizar los datos no corruptos.
Este dispositivo de usuario también se puede configurar para: leer atributos de ubicación en los datos de encabezado del cuadro contenedor; y utilizar los atributos de ubicación para recuperar los fragmentos de datos en el archivo; y utilizar los datos en los fragmentos de datos recuperados.
Este dispositivo de usuario también se puede configurar para leer en los datos de encabezado del cuadro contenedor que contiene los datos corruptos, una dirección de ubicación donde el archivo está disponible para descargar, y solicitar el archivo a la dirección de ubicación.
Este dispositivo de usuario también se puede configurar para recibir archivos transmitidos según un protocolo de red de transmisión continua con tasa de bits adaptativa, tal como la transmisión continua adaptativa y dinámica sobre HTTP (DASH).
Las realizaciones también pueden referirse a un procedimiento implementado por este dispositivo de usuario.
En uno o más ejemplos, las funciones descritas se pueden implementar en hardware, software, firmware o en cualquier combinación de los mismos. Si se implementan en software, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador, como una o más instrucciones o código, y ejecutar mediante una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador que correspondan a un medio tangible, tales como medios de almacenamiento de datos, o medios de comunicación que incluyan cualquier medio que facilite la transferencia de un programa informático de un lugar a otro, por ejemplo, según un protocolo de comunicación. De esta manera, los medios legibles por ordenador pueden corresponder, en general, a medios de almacenamiento tangibles legibles por ordenador que sean no transitorios o a un medio de comunicación tal como una señal o una onda portadora. Los medios de almacenamiento de datos pueden ser cualquier medio disponible al que se pueda acceder desde uno o más ordenadores o uno o más procesadores para recuperar instrucciones, código y/o estructuras de datos para la implementación de las técnicas descritas en la presente divulgación. Un producto de programa informático puede incluir un medio legible por ordenador.
A modo de ejemplo, y no de limitación, dichos medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, memoria flash o cualquier otro medio que se pueda usar para almacenar el código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. Además, cualquier conexión recibe apropiadamente la denominación de medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde un sitio web, un servidor u otro origen remoto usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital (DSL) o unas tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas están incluidos en la definición de medio. Sin embargo, se deberá entender que los medios de almacenamiento legibles por ordenador y los medios de almacenamiento de datos no incluyen conexiones, ondas portadoras, señales u otros medios transitorios, sino que, en cambio, están dirigidos a medios de almacenamiento no transitorio tangibles. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen normalmente los datos magnéticamente, mientras que otros discos reproducen los datos ópticamente con láseres. Las combinaciones de lo anterior también se deben incluir dentro del alcance de los medios legibles por ordenador.
Las instrucciones se pueden ejecutar por uno o más procesadores, tales como uno o más procesadores de señales digitales (DSP), microprocesadores de propósito general, circuitos integrados específicos de la aplicación (ASIC), matrices lógicas programables por campo (FPGA) u otros circuitos lógicos integrados o discretos equivalentes. Por consiguiente, el término "procesador", como se usa en la presente memoria, se puede referir a cualquiera de las estructuras anteriores o a cualquier otra estructura adecuada para la implementación de las técnicas descritas en la presente memoria. Además, en algunos aspectos, la funcionalidad descrita en la presente memoria se puede proporcionar dentro de módulos de hardware y/o de programa informático dedicados configurados para la codificación y la descodificación, o incorporarse en un códec combinado. Además, las técnicas se podrían implementar por completo en uno o más circuitos o elementos lógicos.
Las técnicas de esta divulgación se pueden implementar en una amplia variedad de dispositivos o aparatos, incluyendo un microteléfono inalámbrico, un circuito integrado (CI) o un conjunto de CI (por ejemplo, un conjunto de chips). En la presente divulgación se describen diversos componentes, módulos o unidades para destacar aspectos funcionales de dispositivos configurados para realizar las técnicas divulgadas, pero no se requiere necesariamente su realización mediante diferentes unidades de hardware. En su lugar, como se describe anteriormente, diversas unidades se pueden combinar en una unidad de hardware de códec o proporcionar mediante un grupo de unidades de hardware interoperativas, que incluya uno o más procesadores como se describe anteriormente, junto con software y/o firmware adecuados. Se han descrito diversos ejemplos. Estos y otros ejemplos están dentro del alcance de las siguientes reivindicaciones.

Claims (14)

REIVINDICACIONES
1. Un procedimiento para recuperar un archivo, el procedimiento que se implementa en un receptor de datos, el procedimiento que comprende:
recibir una porción de un segmento de archivo (SGM) transmitido según un protocolo de multidifusión desde un servicio de entrega de archivos, en el que recibir incluye recibir paquetes de símbolos y generar el segmento de archivo descodificando los paquetes de símbolos recibidos, y cuando los paquetes de símbolos recibidos comprenden símbolos de reparación, procesar los errores de transmisión utilizando los símbolos de reparación recibidos; y recibir una tabla de entrega de archivos, FDT, del servicio de entrega de archivos;
caracterizado por que el segmento de archivo se divide en fragmentos de datos (mfrg) que se pueden procesar de forma independiente como el segmento de archivo, la porción de archivo comprende uno o más fragmentos de datos, el procedimiento que además comprende:
leer en los datos de ubicación de la tabla de entrega de archivos (tlbi) que indican ubicaciones de los fragmentos de datos en el segmento de archivo recibido; y
determinar a partir de los datos de ubicación las ubicaciones de los fragmentos de datos no corruptos en el segmento de archivo recibido.
2. El procedimiento de la reivindicación 1 que comprende:
detectar datos corruptos en los fragmentos de datos (mfrg) recibidos; y
eliminar uno de los fragmentos de datos del segmento de archivo (SGM) cuando contiene datos corruptos.
3. El procedimiento de la reivindicación 1 que comprende:
detectar datos corruptos en los fragmentos de datos (mfrg) recibidos; y
cuando uno de los fragmentos de datos contiene datos corruptos, encapsular el fragmento de datos en un cuadro contenedor (pfcb) que comprende datos de carga útil (PCD), que incluyen los datos corruptos, y datos de encabezado (CHD), que incluyen datos de ubicación (tlbi) para ubicar los datos corruptos (CD1, CD2) en el segmento de archivo.
4. El procedimiento de la reivindicación 3 que comprende:
determinar un tipo de cuadro contenedor a partir de los datos de encabezado (CGD), indicar el tipo de cuadro contenedor que el cuadro contenedor contiene datos corruptos;
determinar los datos de ubicación (tlbi) en los datos de encabezado;
determinar a partir de los datos de ubicación en los datos de encabezado las ubicaciones de los datos no corruptos del fragmento de datos (mfrg), en los datos de carga útil (PCD); y
utilizar los datos no corruptos.
5. El procedimiento de una de las reivindicaciones 3 a 4, que comprende insertar en los datos de encabezado (CHD) del cuadro contenedor (pfcb) que contiene los datos corruptos (CD1, CD2), los datos de ubicación (tlbi) leídos en la tabla de entrega de archivos (FDT).
6. El procedimiento de la reivindicación 5 que comprende:
leer los datos de ubicación (tlbi) en los datos de encabezado (CHD) del cuadro contenedor (pfcb),
utilizar los datos de ubicación para recuperar los fragmentos de datos (mfrg) en el segmento de archivo (SGM); y utilizar los datos en los fragmentos de datos recuperados.
7. El procedimiento de una de las reivindicaciones 3 a 6, que comprende insertar en los datos de encabezado (CHD) del cuadro contenedor (pfcb) que contiene los datos corruptos (CD1, CD2), una dirección de ubicación (ourl) donde el segmento de archivo (SGM ) está disponible para descargar.
8. El procedimiento de una de la s reivindicaciones 1 a 7, en el que el contenido se transmite según un protocolo de red de transmisión continua con tasa de bits adaptativa, tal como la transmisión continua adaptativa y dinámica sobre HTTP, DASH.
9. El procedimiento de una de las reivindicaciones 1 a 8, en el que el servicio de entrega de archivos comprende la Entrega de Archivos sobre Transporte Unidireccional, FLUTE.
10. Un receptor de datos (FREC) configurado para implementar el procedimiento de una de las reivindicaciones 1 a 9.
11. Un procedimiento de transmisión de datos, el procedimiento que se implementa mediante un transmisor de datos, el procedimiento que comprende:
transmitir un segmento de archivo (SGM), codificado en paquetes según un protocolo de multidifusión a través de un servicio de entrega de archivos; y
transmitir una tabla de entrega de archivos, FDT;
caracterizado por que el segmento de archivo se divide en fragmentos de datos (mfrg) que se pueden utilizar de forma independiente como segmento de archivo, el procedimiento que además comprende:
insertar datos de ubicación de fragmentos de datos (tlbi) para ubicar los fragmentos de datos del segmento de archivo, en la tabla de entrega de archivos.
12. El procedimiento de la reivindicación 11, en el que el segmento de archivo se transmite según un protocolo de red de transmisión continua con tasa de bits adaptativa, tal como la transmisión continua adaptativa y dinámica sobre HTTP, DASH.
13. El procedimiento de una de las reivindicaciones 11 y 12, en el que el servicio de entrega de archivos comprende la Entrega de Archivos sobre T ransporte Unidireccional, FLUTE.
14. Un transmisor de datos (FSND) configurado para implementar el procedimiento de una de las reivindicaciones 11 a 13.
ES15725119T 2015-02-11 2015-04-24 Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute Active ES2865448T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562114868P 2015-02-11 2015-02-11
PCT/IB2015/052992 WO2016128803A1 (en) 2015-02-11 2015-04-24 Method of handling packet losses in transmissions based on dash standard and flute protocol

Publications (1)

Publication Number Publication Date
ES2865448T3 true ES2865448T3 (es) 2021-10-15

Family

ID=53268846

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15725119T Active ES2865448T3 (es) 2015-02-11 2015-04-24 Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute

Country Status (5)

Country Link
US (1) US10560866B2 (es)
EP (1) EP3257216B1 (es)
KR (1) KR102288815B1 (es)
ES (1) ES2865448T3 (es)
WO (1) WO2016128803A1 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10749930B2 (en) 2015-03-02 2020-08-18 Qualcomm Incorporated Indication for partial segment
US10659507B2 (en) * 2015-03-02 2020-05-19 Qualcomm Incorporated Indication for partial segment
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US10397079B2 (en) * 2016-09-27 2019-08-27 Netscout Systems, Inc. Video delivery performance analysis for EMBMS
US20180103271A1 (en) * 2016-10-10 2018-04-12 Qualcomm Incorporated Systems and methods for signaling missing or corrupted video data
JPWO2018070268A1 (ja) * 2016-10-14 2019-08-08 ソニー株式会社 情報処理装置および方法
US10805650B2 (en) * 2017-03-27 2020-10-13 Qualcomm Incorporated Signaling important video information in network video streaming using mime type parameters
US10484726B2 (en) * 2017-06-02 2019-11-19 Apple Inc. Playlist error tags for delivery and rendering of streamed media
US11146852B2 (en) * 2018-05-11 2021-10-12 Qualcomm Incorporated Signaling missing sections of media data for network streaming in a segment
US11470041B2 (en) * 2019-06-20 2022-10-11 Disney Enterprises, Inc. Software defined network orchestration to manage media flows for broadcast with public cloud networks

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008546231A (ja) 2005-05-13 2008-12-18 クゥアルコム・インコーポレイテッド 帯域外ディレクトリ情報を使用するエラー耐性の改良
JP4264833B2 (ja) * 2005-06-17 2009-05-20 ソニー株式会社 記録装置および方法、プログラム、並びに記録媒体
WO2013020709A1 (en) 2011-08-10 2013-02-14 Telefonaktiebolaget L M Ericsson (Publ) Media stream handling
US20150172348A1 (en) * 2012-01-17 2015-06-18 Telefonaktiebolaget L M Ericsson (Publ) Method for sending respectively receiving a media stream
US20130254611A1 (en) * 2012-03-23 2013-09-26 Qualcomm Incorporated Recovering data in multimedia file segments
US9294226B2 (en) * 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery

Also Published As

Publication number Publication date
KR102288815B1 (ko) 2021-08-11
EP3257216A1 (en) 2017-12-20
EP3257216B1 (en) 2021-01-27
US10560866B2 (en) 2020-02-11
US20180098242A1 (en) 2018-04-05
KR20170117116A (ko) 2017-10-20
WO2016128803A1 (en) 2016-08-18

Similar Documents

Publication Publication Date Title
ES2865448T3 (es) Procedimiento de gestión de pérdidas de paquetes en transmisiones basadas en la norma dash y el protocolo flute
US11805286B2 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
ES2784605T3 (es) Entrega de middleware de métricas de QOE del cliente dash
US9294226B2 (en) Universal object delivery and template-based file delivery
US9350488B2 (en) Content delivery system with allocation of source data and repair data among HTTP servers
ES2716274T3 (es) Transmisión en red de datos de vídeo usando peticiones de rangos de bytes
JP7142626B2 (ja) メディアストリーミングのためのセグメントチャンクの検索およびアクセス
KR101857089B1 (ko) 네트워크를 통해 교환되는 파일들에 대한 에러 처리
ES2764224T3 (es) Robusto funcionamiento en vivo de DASH
ES2818622T3 (es) Entradas de muestra y acceso aleatorio
EP2774347A2 (en) Content delivery system with allocation of source data and repair data among http servers
BR112020022899A2 (pt) sinalizar, em um arquivo de manifesto, seções ausentes de dados de mídia para rede de fluxo contínuo
ES2821382T3 (es) Entradas de muestra y acceso aleatorio
EP2453652A1 (en) Transmission method, receiving method and device for scalable video coding files
WO2016097482A1 (en) Media encapsulating and decapsulating
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data
US11582125B2 (en) Repair mechanism for adaptive bit rate multicast
BR112017027511B1 (pt) Distribuição de middleware de métricas de qoe de cliente dash