ES2842589T3 - Transmisión de flujos por multidifusión - Google Patents

Transmisión de flujos por multidifusión Download PDF

Info

Publication number
ES2842589T3
ES2842589T3 ES15714258T ES15714258T ES2842589T3 ES 2842589 T3 ES2842589 T3 ES 2842589T3 ES 15714258 T ES15714258 T ES 15714258T ES 15714258 T ES15714258 T ES 15714258T ES 2842589 T3 ES2842589 T3 ES 2842589T3
Authority
ES
Spain
Prior art keywords
multicast
video stream
unicast
content
chunk
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
ES15714258T
Other languages
English (en)
Inventor
Ian Crabtree
Michael Nilsson
Rory Turnbull
Stephen Appleby
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.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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 British Telecommunications PLC filed Critical British Telecommunications PLC
Application granted granted Critical
Publication of ES2842589T3 publication Critical patent/ES2842589T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Método de gestión de distribución de vídeo por multidifusión que comprende: recibir un flujo de vídeo de multidifusión en una pluralidad de dispositivos de cliente desde un servidor; transmitir regularmente desde cada uno de los dispositivos de cliente, mientras un flujo de vídeo de multidifusión está siendo recibido, un primer mensaje al servidor como respuesta a la recepción del flujo de vídeo de multidifusión, en el que el primer mensaje es un mensaje de solicitud HTTP HEAD para actualizaciones de un archivo de manifiesto asociado al flujo de vídeo; determinar el número de dispositivos de cliente que reciben el flujo de vídeo de multidifusión basándose en los primeros mensajes transmitidos regularmente; recibir un flujo de vídeo de unidifusión en una pluralidad de dispositivos de cliente desde el servidor; transmitir regularmente desde cada uno de los dispositivos de cliente que reciben un flujo de vídeo de unidifusión, mientras un flujo de vídeo de unidifusión está siendo recibido, un segundo mensaje al servidor como respuesta a la recepción del flujo de vídeo de unidifusión, siendo el segundo mensaje una solicitud HTTP GET y siendo diferente con respecto al primer mensaje; determinar el número de dispositivos de cliente que reciben el flujo de vídeo de unidifusión basándose en los segundos mensajes transmitidos; y gestionar la distribución de vídeo por multidifusión en función de una comparación de los números determinados para decidir si usar multidifusión o unidifusión para distribuir el flujo de vídeo.

Description

DESCRIPCIÓN
Transmisión de flujos por multidifusión
Campo de la invención
La presente invención se refiere al campo de la transmisión de vídeo en flujo por multidifusión.
Antecedentes de la invención
En la actualidad la televisión en vivo distribuida sobre redes IP usa una de dos tecnologías de conexión en red bastante diferentes: una basada en la multidifusión y la otra basada en la unidifusión. Con la transmisión por multidifusión, se envía sin solicitud previa (push) desde un servidor de contenido a múltiples nodos de red simultáneamente un único flujo multidifusión que lleva el contenido, de manera que esos nodos de red duplican el contenido y lo reenvían a todos los nodos o clientes subsiguientes según se requiera. Con la transmisión por unidifusión, se recuperan del servidor con solicitud previa (pulí) múltiples flujos de contenido, uno para cada dispositivo que consume el contenido, típicamente usando HTTP sobre TCP y una tecnología de Velocidad de Bits Adaptativa.
La multidifusión hace un uso eficiente de la red cuando distribuye el mismo contenido al mismo tiempo a muchos dispositivos finales, pero, normalmente, requiere una asignación continua de recursos de la red con independencia de la cuantía del visionado. Además, muchos dispositivos finales, tales como algunas tabletas y teléfonos inteligentes, en la actualidad no admiten la multidifusión.
La unidifusión adolece de tener que enviar múltiples copias del mismo contenido a través de la red, pero no requiere una asignación de recursos de la red que es independiente del uso. Por otra parte, la unidifusión tiene la capacidad de distribuir a todos los dispositivos finales, e incluso en presencia de un caudal bajo o variable de la red hacia el dispositivo final, lo cual se produce con frecuencia para dispositivos conectados, por ejemplo, mediante tecnología inalámbrica.
La solicitud de patente US 2013/0024582 describe un sistema y un método para conmutar dinámicamente entre la distribución de contenido de medios por unidifusión y por multidifusión como respuesta a cambios de la demanda concurrente de acceso al contenido de medios. Además, los números de secuencia incluidos en los cuadros de vídeo se usan para la alineación entre contenido de flujo unidifusión y multidifusión.
El documento WO 2012/074874 A1 divulga decisiones de conmutación de multidifusión/unidifusión basadas en mensajes de incorporación.
Sumario de la invención
Según un aspecto de la presente invención, se proporciona un método de gestión de la distribución de vídeo por multidifusión de acuerdo con las reivindicaciones adjuntas.
Breve descripción de los dibujos
Para entender mejor la presente invención, a continuación, se hará referencia, únicamente a título de ejemplo, a los dibujos adjuntos, en los cuales:
la figura 1 es un diagrama de red en un ejemplo de la presente invención;
la figura 2 es un diagrama de un sistema que muestra de manera más detallada el generador de contenido y el servidor de contenido;
la figura 3 es un diagrama de flujo que resume las etapas principales de un ejemplo de la invención;
la figura 4 ilustra cómo se llevan fragmentos de un flujo de transporte a través de paquetes IP usando el RTP; la figura 5 muestra el formato de un encabezamiento UDP;
la figura 6 muestra el formato de un encabezamiento RTP;
la figura 7 muestra el formato correspondiente a un formato de encabezamiento de carga útil RTP en un ejemplo de la presente invención;
la figura 8 muestra el formato de un paquete IP completo en un ejemplo de la presente invención.
Descripción de formas de realización preferidas
La presente invención se describe en la presente memoria en referencia a ejemplos particulares. No obstante, la invención no se limita a dichos ejemplos.
Ejemplos de la presente invención presentan un método para proporcionar retroalimentación en relación con la recepción de un flujo de vídeo multidifusión. El mecanismo de retroalimentación permite determinar el número de clientes que están recibiendo a través de multidifusión, lo cual, a continuación, se puede usar para gestionar la distribución por multidifusión, incluyendo decisiones de conmutación entre multidifusión y unidifusión. Se distribuye contenido de vídeo a través de un flujo multidifusión desde un servidor de contenido a una pluralidad de dispositivos de cliente. Los dispositivos del cliente están configurados, cada uno de ellos, para responder a intervalos regulares mientras reciben el flujo de vídeo multidifusión transmitiendo un mensaje de solicitud HTTP HEAD al servidor de contenido. La solicitud HTTP HEAD se refiere a metadatos relativos a un archivo de manifiesto asociado al flujo de vídeo. El número de dispositivos de cliente que reciben el flujo de vídeo multidifusión se determina basándose en el número de solicitudes HEAD recibidas en el servidor de contenido. A continuación, la distribución de vídeo multidifusión se puede gestionar de manera correspondiente, y la misma también puede tener en cuenta el número de clientes de unidifusión que están solicitando el flujo de unidifusión correspondiente al flujo de multidifusión.
La figura 1 muestra un sistema 100 que comprende un generador de contenido 102 que se comunica con un servidor de contenido 104. El generador de contenido es responsable de recibir contenido de vídeo sin comprimir, tal como TV en vivo, y de codificar y empaquetar el contenido de vídeo para su traslado al servidor de contenido 104. El servidor de contenido 104 es responsable de almacenar el contenido de vídeo recibido, y, en caso de distribución por unidifusión, se recupera con solicitud previa el contenido del servidor, mientras que, para la distribución por multidifusión, el contenido se envía sin solicitud previa desde el servidor a clientes configurados de manera adecuada y conectados a través de la red 106. En este ejemplo se muestran tres clientes 108, 110 y 112. Los clientes pueden ser clientes convencionales de transmisión de flujos con Velocidad de Bits Adaptativa HTTP, adaptados para admitir, por ejemplo, MPEG DASH o la Transmisión de Flujo en Vivo HTTP (HLS) de Apple. Los clientes están adaptados para descubrir contenido, solicitar y procesar archivos de manifiesto, solicitar fragmentos de contenido por unidifusión, y procesar dichos fragmentos para su visionado. Aunque el contenido se puede distribuir a través de la red 106 directamente a estos clientes, la distribución se puede realizar por medio de un proxy local para cada cliente, lo cual presenta ciertas ventajas.
El servidor de contenido 104 incluye, también, un mecanismo para conmutar entre métodos de distribución por unidifusión y por multidifusión, y para generar un flujo de multidifusión, durante la distribución de cualquier contenido codificado dado, tal como una película o programa de TV.
El generador de contenido 102 y el servidor de contenido 104 se muestran de manera más detallada en la figura 2. El funcionamiento y los componentes del generador de contenido 102 y el servidor de contenido 104 se describirán en referencia al diagrama de flujo de la figura 3, que esboza el método general.
Tal como se muestra en la figura 2, el generador de contenido 102 comprende un codificador de vídeo 206, un codificador de audio 208, un módulo de segmentación 210, un módulo de empaquetamiento 212 y una interfaz de salida 214. El generador de contenido 102 recibe contenido de vídeo sin comprimir que comprende un flujo de vídeo sin comprimir 202 y un flujo de audio sin comprimir. Específicamente, el codificador de vídeo 206 coge el flujo de vídeo sin comprimir 202, y codifica el vídeo para generar un flujo de vídeo codificado. En este ejemplo, el método de codificación de vídeo usado es acorde a la norma ITU H.264, aunque la invención no se limita a dicha norma, y podrían usarse en su lugar otros métodos de codificación. De manera similar, el codificador de audio 208 coge el flujo de audio sin comprimir 204, y codifica el audio para generar un flujo de audio codificado. En este ejemplo, el método de codificación de audio es el MPEG-4 h E AAC v2, aunque la invención no se limita a dicha norma, y podrían usarse en su lugar otros métodos de codificación. El flujo de vídeo sin comprimir se puede codificar con múltiples velocidades de bits (habitualmente el flujo de audio sin comprimir asociado se codifica solamente con una velocidad de bits, aunque también se puede codificar con múltiples velocidades de bits), generando así un flujo codificado para cada velocidad de bits. El flujo de vídeo codificado comprende una pluralidad de cuadros o imágenes, que, a su vez, se pueden reunir en grupos de imágenes o GOP. Esta primera etapa de codificación del contenido de vídeo se muestra en la etapa 300 de la figura 3.
A continuación, en la etapa 302, el flujo de vídeo codificado y el flujo de audio codificado (o cada uno de los flujos de vídeo y audio codificados si el contenido se codificó con múltiples velocidades de bits) se segmentan con el módulo de segmentación 210 en segmentos o fragmentos discretos de vídeo y audio. Está previsto que cada fragmento sea equivalente a entre 2 y 15 segundos en cuanto a espacio de tiempo del vídeo/audio sin comprimir, aunque podrían usarse espacios de tiempo mayores o menores. Aunque el módulo de segmentación 210 se muestra de manera que actúa después de los codificadores 206 y 208, la segmentación se puede llevar a cabo sobre los flujos de vídeo y audio comprimidos antes de su codificación. De este modo, el vídeo y el audio sin comprimir en primer lugar se pueden segmentar, y, a continuación, los segmentos sin comprimir resultantes se pueden codificar para generar los segmentos codificados de vídeo y audio.
El módulo de segmentación 210 puede seleccionar el espacio de tiempo de los segmentos teniendo en cuenta requisitos del servicio. Por ejemplo, segmentos más cortos permiten que la conmutación entre flujos se produzca de manera más rápida, entre flujos tanto de unidifusión como de multidifusión, o entre diferentes velocidades de bits codificadas. No obstante, los segmentos más largos son procesados más fácilmente por los componentes del sistema, particularmente por los nodos de la CDN (Red de Distribución de Contenido), pero podrían provocar conmutaciones más lentas entre modos de distribución y pueden introducir una mayor latencia de extremo a extremo para servicios en vivo.
En la etapa 304, los segmentos de vídeo y audio son gestionados por el módulo de empaquetamiento 212. En este ejemplo, la salida del módulo de empaquetamiento 212 está en un formato denominado multiplexado, tal como el Flujo de Transporte MPEG-2 que se especifica en la IS 13818-1. Normalmente, los flujos de transporte MPEG-2 se usan para la distribución de televisión digital en tiempo real. El módulo de empaquetamiento también podría dar salida en un formato denominado no multiplexado, tal como el Formato de Archivo de Medios de Base ISO, que se especifica en la IS 14496-12. En su lugar también se podría dar salida a fragmentos MP4.
El flujo de transporte MPEG-2 comprende una serie de paquetes de flujo de transporte. Cada paquete del flujo de transporte lleva 184 bytes de datos de carga útil, con un prefijo de un encabezamiento de 4 bytes. Los segmentos codificados de vídeo y audio se llevan en las cargas útiles del flujo de transporte, donde cada carga útil lleva habitualmente un único tipo de medios - por ejemplo, audio, vídeo o datos de subtítulos. Típicamente, se necesitarán varios paquetes del flujo de transporte para llevar cada segmento de audio y vídeo. El número preciso de paquetes del flujo de transporte necesarios dependerá del espacio de tiempo de cada segmento de audio y vídeo creado por el módulo de segmentación 210. De este modo, el módulo de empaquetamiento 112 dará salida a múltiples fragmentos del flujo de transporte para llevar los segmentos respectivos de vídeo y audio, y comprendiendo cada fragmento del flujo de transporte uno o más paquetes de flujo de transporte. Si se usan fragmentos MP4, entonces podrían usarse varios fragmentos MP4 para llevar los mismos segmentos.
Un experto en la materia apreciará que las funciones llevadas a cabo por los codificadores, el módulo de segmentación y el módulo de empaquetamiento pueden ser llevadas a cabo por un único módulo codificador de vídeo general, configurado de manera adecuada.
Los fragmentos del flujo de transporte se trasladan a la interfaz de salida 214, donde, a su vez, se distribuyen al servidor de contenido 120 en la etapa 306.
Además, el generador de contenido 102 también genera un archivo de manifiesto, que describe el contenido codificado (en este ejemplo los fragmentos del flujo de transporte), y cómo puede obtenerse el mismo, y también traslada este al servidor de contenido 104. En el MPEG-DASh , manifiesto se refiere a una MPD, Descripción de Presentación de Medios. La tecnología de transmisión adaptativa de vídeo en flujo de Apple, HLS (Transmisión de Flujo en Vivo HTTP), proporciona un manifiesto en forma de un archivo de lista de reproducción (archivo .m3u).
Tal como se describirá posteriormente, el archivo de manifiesto puede ser modificado por el servidor de contenido en un ejemplo de la invención para señalar una conmutación a multidifusión desde unidifusión. El archivo de manifiesto describe las velocidades de bits disponibles para cada fragmento de flujo de transporte, y dónde está ubicado cada uno de ellos (una dirección de la ubicación en la que está almacenado el fragmento en el servidor de contenido 104). El archivo de manifiesto es usado por un cliente para la transmisión en flujo por unidifusión.
El servidor de contenido 120 recibe el contenido codificado en fragmentos, en una interfaz de entrada 222, en forma de fragmentos de flujo de transporte, y todo archivo de manifiesto asociado, desde el generador de contenido 102. El servidor de contenido 104 comprende una interfaz de entrada 222, unos medios de almacenamiento de datos 224 para almacenar contenido de vídeo, un generador de flujos de multidifusión 230, un módulo lógico de conmutación 232, y una interfaz de salida 234. Los medios de almacenamiento de datos 224 pueden formar parte de un servidor web convencional, el cual puede prestar servicio a fragmentos individuales del flujo de transporte como respuesta a solicitudes de unidifusión por medio de la interfaz de salida 234. El contenido proporcionado por unidifusión es “recuperado con solicitud previa” de manera eficaz desde el servidor web a petición de los clientes.
Los fragmentos del flujo de transporte y el archivo de manifiesto se trasladan desde la interfaz de entrada 222 a los medios de almacenamiento de datos 224, donde los mismos son almacenados. Los medios de almacenamiento de datos 224 pueden almacenar múltiples archivos de manifiesto 228, uno para cada elemento diferenciado de vídeo, y contenido de vídeo 226 (en forma de fragmentos de flujo de transporte). Tal como ha sugerido anteriormente, puede haber múltiples versiones del mismo contenido de vídeo, cada una de ellas codificada a velocidades de bits diferentes, que se reflejan en un archivo de manifiesto asociado.
El generador de flujos de multidifusión 230 es responsable de generar flujos de multidifusión, los cuales, típicamente, llevarán múltiples fragmentos de flujo de transporte. Los flujos de multidifusión son “enviados sin solicitud previa” a los clientes.
Un cliente puede iniciar una transmisión de flujo por unidifusión en primer lugar presentando una solicitud al servidor de contenido 104 en relación con el archivo de manifiesto adecuado asociado a contenido deseado. Después de la recepción del archivo de manifiesto, el cliente puede presentar solicitudes específicas de fragmentos codificados, los fragmentos del flujo de transporte, usando la información de ubicación asociada a cada fragmento encontrada en el manifiesto. Las solicitudes adoptan la forma de solicitudes HTTP para cada fragmento y son gestionadas por el servidor de contenido 104, y, específicamente, el componente del servidor web. Los fragmentos del flujo de transporte son empaquetados por el servidor web como paquetes TCP/IP convencional y son distribuidos al cliente a través de la red. De este modo, el mecanismo de distribución es un mecanismo fiable. El cliente también puede solicitar archivos de manifiesto actualizados según se requiera desde el servidor de contenido 104. El proceso se describirá de forma más detallada posteriormente.
El módulo lógico de conmutación 232 en el servidor de contenido 104 determina si poner a disposición los fragmentos del flujo de transporte para su distribución por multidifusión así como unidifusión, y cuando sea necesario, ordenará al generador de flujos de multidifusión 230 que genere un flujo de multidifusión y que señalice que el flujo de multidifusión está disponible. Esto último se puede realizar mediante una actualización adecuada en el archivo de manifiesto según se describirá más adelante.
El módulo lógico de conmutación 232, para cada flujo de contenido codificado, determina cuál de los fragmentos codificados, en caso de que hubiera alguno, se debe de poner a disposición mediante distribución por multidifusión, así como mediante distribución por unidifusión. Por ejemplo, en un momento determinado el módulo lógico de conmutación 232 puede determinar que todos los fragmentos de contenido para un contenido dado se pongan a disposición únicamente mediante unidifusión; y en un instante de tiempo posterior, puede determinar que el contenido (o un flujo específico codificado con una velocidad de bits particular) debe ponerse a disposición adicionalmente mediante multidifusión; y en un instante de tiempo todavía posterior, puede determinar que todos los fragmentos de contenido se pongan a disposición nuevamente solo mediante unidifusión.
La decisión sobre cuándo conmutar a multidifusión desde unidifusión podría basarse en el número de clientes que solicitan un contenido particular. Si la red solamente permite un único flujo de multidifusión, entonces podría seleccionarse el contenido más popular para la distribución por multidifusión con el fin de reducir el ancho de banda total usado en la red. No obstante, puede que no sea tan sencillo, en la medida en la que el contenido puede estar codificado con velocidades de bits diferentes, y la velocidad que puede soportar el cliente también podría variar, con lo que la decisión de conmutación puede ser más complicada. No obstante, es importante, por ello, que el módulo lógico de conmutación 232 sepa en todo momento cuántos clientes están recibiendo qué contenido mediante unidifusión, y cuál mediante multidifusión para poder tomar una decisión de conmutación adecuada.
Cuando el módulo lógico de conmutación determina que parte del contenido almacenado debería ponerse a disposición mediante distribución por multidifusión, el servidor de contenido 104 modifica el archivo de manifiesto para indicar, también, la posibilidad de distribución por multidifusión y cómo recibir el flujo de multidifusión. El servidor de contenido transmite entonces el contenido codificado en un flujo de multidifusión que ha sido indicado por el módulo lógico de conmutación para la distribución por multidifusión.
En sistemas conocidos, la transmisión de vídeo en flujo por multidifusión funciona mediante la codificación del contenido y el empaquetamiento del contenido codificado en paquetes de flujo de transporte antes de usar un mecanismo de distribución tal como el RTP sobre IP No obstante, este planteamiento no se presta a una conmutación hacia y desde una unidifusión portadora de vídeo, donde hay una necesidad de sincronización precisa entre el contenido codificado para evitar una alteración de la reproducción del contenido.
En ejemplos de esta invención, el contenido se ha dividido en segmentos de espacio de tiempo predeterminado, y se lleva en fragmentos de flujo de transporte, según se ha descrito anteriormente. A continuación, los fragmentos de flujo de transporte se encapsulan usando un protocolo de transporte, tal como el RTP (protocolo de transporte en tiempo real). Específicamente, los fragmentos del flujo de transporte se llevan en los paquetes, específicamente en cargas útiles RTP, encapsulándose los paquetes RTP con el uso del UDP (protocolo de datagrama de usuario) en un paquete IP para una transmisión de multidifusión.
La figura 4 ilustra el formato de los fragmentos del flujo de transporte y los paquetes RTP en los que se llevan para un flujo de multidifusión. Se muestran tres fragmentos de flujo de transporte 400, 402 y 404, llevando cada uno de ellos el contenido segmentado según se ha descrito anteriormente. Cada fragmento del flujo de transporte comprende múltiples paquetes de flujo de transporte 410, donde cada paquete de flujo de transporte tiene un encabezamiento asociado 412 y una carga útil 414. Los paquetes del flujo de transporte se llevan en la carga útil 420 de un paquete RTP Cada fragmento nuevo del flujo de transporte comenzará en una carga útil RTP nueva, evitándose así la situación en la que una carga útil RTP podría llevar el final de un fragmento del flujo de transporte y el inicio del siguiente. El paquete RTP incluye un encabezamiento RTP convencional 422. El paquete RTP, que comprende el encabezamiento RTP 422 y la carga útil RTP 420, se encapsula usando el UDP en un paquete IP 430, y, por lo tanto, se muestra un encabezamiento UDP 424 y un encabezamiento IP 426. En efecto, la carga útil RTP 420 y el encabezamiento RTP 422 forman la carga útil del paquete UDP, y la carga útil UDP y el encabezamiento UDP 424 forman, a su vez, la carga útil del paquete IP 430.
Con fines ilustrativos, si el contenido es un flujo de vídeo de 1Mbit/s, y está segmentado en fragmentos de 2 segundos, cada fragmento contendrá 2Mbits o 250Kbytes. Por lo tanto, cada fragmento se llevaría sobre aproximadamente 190 cargas útiles RTP que contienen, cada una de ellas, hasta siete paquetes de Flujo de Transporte de 188 bytes.
En la figura 5, se muestra más detalladamente el formato del encabezamiento UDP 424.
En la figura 6, se muestra más detalladamente el formato del encabezamiento RTP 422.
En un ejemplo de la invención, se propone el uso de encabezamientos RTP adicionales para ayudar a identificar límites de fragmentos en el flujo de multidifusión. Esto lo necesita el cliente receptor para identificar fragmentos individuales, con el fin de poder llevar a cabo claramente una conmutación entre los fragmentos distribuidos por unidifusión y los correspondientes distribuidos por multidifusión. En un ejemplo de la invención, se propone el uso de cierto marcaje adicional para indicar qué cargas útiles RTP están llevando qué fragmentos, y dónde se sitúan los límites de los fragmentos. En la práctica, cada fragmento del flujo de transporte se llevará a través de muchas cargas útiles RTP, y, por lo tanto, los límites de los fragmentos aparecerán después de muchas cargas útiles RTP (consúltese más arriba en donde un ejemplo de un fragmento de 2 segundos requiere aproximadamente 190 cargas útiles RTP). En la solución más sencilla, el paquete RTP que lleva el final de un fragmento puede marcarse para indicar el final del fragmento.
No obstante, la distribución por multidifusión se lleva a cabo habitualmente usando el RTP/UDP, como en este ejemplo, y la misma, por lo tanto, es poco fiable: puede que algunos paquetes transmitidos por el servidor de contenido 104 no sean recibidos por el cliente. Sin embargo, habitualmente con la distribución por multidifusión, se usa un servidor de retransmisión para retransmitir paquetes perdidos, según solicite el cliente, usando una transmisión TCP fiable. Sigue habiendo posibilidad de fallos de todos modos, ya que pérdidas en la retransmisión pueden dar como resultado la distribución de datos de multidifusión perdidos al cliente, aunque distribuidos demasiado tarde para ser descodificados de forma útil.
Por lo tanto, para el flujo de multidifusión se requiere cierta resiliencia en la señalización de en qué paquetes finaliza un fragmento, ya que el marcador de paquete individual podría residir en uno de los paquetes de multidifusión perdidos. La solución propuesta consiste en incluir información adicional en cada paquete RTP del flujo de multidifusión, proporcionando información sobre el número del fragmento, así como el límite del fragmento mediante el uso de un encabezamiento modificado. La información adicional se puede llevar en el Formato de Encabezamiento de Carga Útil RTP.
En esta aplicación, la información adicional incluye dos parámetros numéricos adicionales, un parámetro CHUNK_INDEX y un parámetro CHUNK_OFFSET. El parámetro CHUNK_INDEX y el parámetro CHUNK_OFFSET se muestran ambos en el formato del encabezamiento de carga útil RTP de la figura 7. Puede usarse cualquiera de ellos, de manera individual o combinados, para indicar qué fragmentos están presentes en qué carga útil RTP.
El parámetro CHUNK_INDEX es un número de secuencia que identifica qué fragmentos se están llevando en qué paquetes, y también indica límites de los fragmentos. El CHUNK_INDEX se usa también para emparejar fragmentos en el flujo de multidifusión con los fragmentos en un flujo de unidifusión asociado.
En la unidifusión, los fragmentos están asociados, en el archivo de manifiesto, a un URL para acceder al archivo, pero, además, en algunos casos, están asociados adicionalmente a un parámetro numérico, por ejemplo, el parámetro EXT-X- MEDIA-SEQUENCE usado por la HLS de Apple. En esta invención, cada fragmento de unidifusión está asociado a un parámetro numérico determinado mediante análisis del archivo de manifiesto. Este parámetro numérico es igual al valor numérico explícito en el archivo de manifiesto, derivado, por ejemplo, del parámetro EXT-X- MEDIA-SEQUENCE, si hay presencia de un valor numérico explícito. De lo contrario, este parámetro numérico se deriva del URL del fragmento, siendo igual este parámetro numérico a la parte del sufijo de nombre de archivo numérico del URL del fragmento, donde el URL está compuesto en su totalidad por la concatenación de una ruta de archivo, un nombre de archivo raíz, y un sufijo de nombre de archivo numérico.
Este valor numérico asociado a un fragmento se corresponde de manera unívoca con el valor del parámetro CHUNK_INDEX asociado al fragmento cuando el mismo se transmite por multidifusión. Uno de los ejemplos de dicho mapeo unívoco es el uso del valor numérico como valor de CHUNK_INDEX.
El siguiente es un manifiesto HLS de ejemplo - EXT-X-MEDIA-SEQUENCE indica el valor asociado al primer fragmento en el archivo (2680), y, por lo tanto, los valores restantes se derivan de este primer valor (2681 y 2682). Obsérvese que estos valores son congruentes con los valores que pueden derivarse del sufijo numérico del archivo correspondiente (que, en el ejemplo de abajo, son, también, 2680, 2681 y 2682):
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680
#EXTINF:7.975,
https://priv.example.com/fileSequence2680.ts
#EXTINF:7.941,
https://priv.example.com/fileSequence2681.ts
#EXTINF:7.975,
https://priv.example.com/fileSequence2682.ts
De este modo, este valor numérico actúa como una especie de número de secuencia en la unidifusión, y, en el flujo de multidifusión, la asignación del valor CHUNK_INDEX sigue también la misma convención, de manera que a un paquete que lleva un fragmento o parte de un fragmento se le asigna un CHUNK_INDEX igual al número de secuencia asignado al fragmento de unidifusión equivalente. El servidor de contenido 104 marca el encabezamiento de carga útil de cada paquete con este CHUNK_INDEX.
Con fines ilustrativos, si el número de secuencia del fragmento es 2680 en unidifusión, entonces todos los paquetes usados para llevar ese fragmento se marcan con un CHUNK_INDEX de 2680 para flujo de multidifusión. A continuación, cuando se procese el siguiente fragmento, que tiene un número de secuencia de 2681 en unidifusión, los paquetes que lleven ese fragmento tienen un CHUNK_INDEX de 2681.
Volvamos ahora al parámetro CHUNK_OFFSET. En un primer ejemplo, el parámetro CHUNK_OFFSET adopta un valor numérico que se incrementa en uno con cada paquete de un fragmento dado y se fija a cero en el primer paquete de un fragmento nuevo. En este caso, el parámetro CHUNK_OFFSET puede usarse entonces para identificar límites de fragmentos, no solamente identificando paquetes con el valor cero como el primero de un fragmento, sino también en caso de que dicho paquete se pierda, identificando un límite de fragmento mediante una disminución en el valor de CHUNK_OFFSEt . Con fines ilustrativos, el CHUNK_OFFSET correspondiente al primer paquete que lleva un fragmento se puede fijar a 0, y, a continuación, el segundo paquete que está llevando parte del mismo fragmento tendrá un CHUNK_OFFSET fijado a 1, y un tercer paquete que lleva la parte final del mismo fragmento tendrá un CHUNK_OFFSET fijado a 2. A continuación, el siguiente paquete después de ese, que está llevando un fragmento nuevo, tendrá el c Hu NK_OFFSET de nuevo fijado a 0, o cualquier valor inferior a 2. De este modo, el inicio de un fragmento nuevo lo señaliza o bien un parámetro CHUNK_OFFSET de 0 o bien simplemente una disminución con respecto a un parámetro CHUNK_OFFSET previo.
En un segundo ejemplo, el parámetro CHUNK_OFFSET se puede usar para indicar el número total de bytes de datos en las cargas útiles de todos los paquetes precedentes que llevan un fragmento dado. Por lo tanto, el primer paquete de un fragmento llevaría el valor de 0, y los paquetes sucesivos llevarían valores que aumentan de forma creciente y monótona. Como en el primer ejemplo, los límites de fragmentos del contenido se pueden identificar con un CHUNK_OFFSET igual a cero, o con un valor disminuido de CHUNK_OFFSET.
El uso del CHUNK_INDEX con el parámetro CHUNK_OFFSET hace frente al problema improbable de que se pierda precisamente el número de paquetes que lleva un único fragmento, lo cual significaría que solamente el parámetro CHUNK_OFFSET seguiría incrementándose tal como se espera. El CHUNK_INDEX actúa como un número de secuencia para el fragmento, y resaltaría los fragmentos ausentes, al mismo tiempo que proporcionando sincronización con los fragmentos del flujo de unidifusión.
En el ejemplo en el que el CHUNK_OFFSET indica los bytes totales de datos llevados en las cargas útiles de los paquetes anteriores para un fragmento dado se obtienen ventajas adicionales. En particular, si el flujo de multidifusión se usa para distribuir contenido codificado en el Formato de Archivo de Medios de Base ISO, y no hay ningún servicio de retransmisión para paquetes perdidos durante la transmisión de multidifusión, o si la retransmisión falla. Para paquetes basados en flujos de transporte, el cliente puede gestionar cualesquiera paquetes perdidos buscando el inicio del siguiente fragmento del flujo de transporte con el uso, por ejemplo, del CHUNK_INDEX. No obstante, si el contenido está en el Formato de Archivo de Medios de Base ISO, entonces esto no es tan sencillo, en la medida en la que el contenido de vídeo codificado está empaquetado y requiere de una tabla de índices con valores de desplazamiento con respecto al inicio del fragmento para su desempaquetado. De este modo, si se pierden algunos datos, entonces, a no ser que se conozca la cantidad de datos perdidos, los datos que suceden a los datos perdidos no se pueden usar como valores de desplazamiento ya no son válidos. Al fijar el parámetro CHUNK_OFFSET de manera que indique el número de bytes de contenido referente a un fragmento hasta el momento, la pérdida de un paquete no da como resultado una cantidad desconocida de información perdida, sino que, por el contrario, puede deducirse la cantidad exacta de información perdida, y los desplazamientos en la tabla de índices siguen siendo utilizables para procesar los paquetes sucesivos del fragmento de contenido.
El marcaje y la generación de los paquetes IP para transmisión de multidifusión los gestiona el generador de flujos de multidifusión 230, y se llevan a cabo en la etapa 308. Al flujo de multidifusión resultante se le da salida por medio de la interfaz de salida 234, donde el mismo se puede distribuir a la red.
El marcaje en el nivel correspondiente al nivel de transporte de los fragmentos de vídeo garantiza que el sistema es tolerante a cualesquiera cambios en las especificaciones de vídeo. Por ejemplo, usando este método todavía pueden determinarse límites de fragmentos incluso si se usa un nuevo formato de vídeo/audio.
De manera más general, el mareaje de los límites de fragmentos en el nivel de transporte evita la necesidad de un procesado más profundo en los datos de los fragmentos, y, por lo tanto, no requiere conocimiento alguno de las especificaciones de los flujos de vídeo y audio, y no requiere conocimiento alguno del formato del contenedor de transporte, tal como el Flujo de Transporte MPEG-2. Por lo tanto, soporta formatos de vídeo y audio adicionales y nuevos. Además, en caso de que el audio y/o el vídeo estén cifrados, la conmutación entre distribución por unidifusión y por multidifusión se puede llevar a cabo sin fisuras y sin la necesidad de que el cliente, u otro dispositivo de procesado, tenga conocimiento de la clave de descifrado.
Ahora se explorará el proceso de iniciar un flujo de unidifusión, y, a continuación, cambiar un flujo de multidifusión, en referencia a uno de los clientes.
El procesado comienza con el cliente presentando una solicitud inicial del archivo de manifiesto asociado al contenido del servidor de contenido 104. El servidor de contenido 104 devuelve el archivo de manifiesto, que contiene información que identifica la ubicación, en los medios de almacenamiento de datos 224, del contenido codificado.
A continuación, el cliente comienza a solicitar fragmentos de contenido codificados por medio de unidifusión en forma de solicitudes HTTP de fragmentos específicos según se expone en el manifiesto del servidor de contenido 104, o, más específicamente, los medios de almacenamiento 224 (o el servidor web). De este modo, el cliente efectivamente recupera con solicitud previa el contenido del servidor web que aloja el contenido codificado. En este ejemplo, los fragmentos solicitados son los fragmentos individuales del flujo de transporte.
El cliente también puede presentar solicitudes regulares de un manifiesto actualizado proveniente del servidor de contenido 104. El servidor de contenido 104 puede actualizar el archivo de manifiesto asociado a cualquier contenido dado cuando recibe fragmentos adicionales de flujo de transporte correspondientes a ese contenido. Se crea un manifiesto actualizado para reflejar estos fragmentos adicionales recibidos del generador de contenido 102, y el mismo se proporciona al cliente cuando así se solicite.
Después de un tiempo, el módulo lógico de conmutación puede decidir poner también a disposición por multidifusión el contenido que se ha recuperado en ese momento por unidifusión. Obsérvese que el contenido permanecerá disponible para unidifusión desde los medios de almacenamiento de datos 224, ya que puede haber clientes que no puedan recibir multidifusión o que no estén configurados para ello. El servidor de contenido 104 actualiza el manifiesto con un indicador de una conmutación a multidifusión. En el caso de un archivo de manifiesto .m3u8, el indicador podría tener la siguiente forma:
#EXT-X-SWITCH: udp://239.1.2.3:4321
Donde EXT-X-SWITCH indica que se produce una conmutación de algún tipo, y udp://239.1.2.3.4:4321 indica que se trata de multidifusión, proporcionando la dirección de multidifusión 239.1.2.3, número de puerto 4321.
Al mismo tiempo, el generador de flujos de multidifusión 230 comenzará a generar un flujo de multidifusión según se ha descrito anteriormente con encabezamientos especiales de paquetes de la capa de transporte que identifican límites de fragmentos. Sobre la base de este indicador en el manifiesto anterior, la interfaz de salida emite el flujo de multidifusión resultante en el puerto 4321, con la dirección 239.1.2.3.
Con el tiempo, el cliente solicitará este manifiesto actualizado que incluye el indicador de conmutación. No obstante, si es importante señalizar inmediatamente la conmutación a multidifusión, entonces, en cuanto se haya actualizado el manifiesto, el servidor de contenido 104 puede incluir un Mensaje de Evento en los fragmentos de contenido que se distribuyan a través de unidifusión para señalizar una actualización en el manifiesto. A continuación, el cliente puede presentar una solicitud del manifiesto actualizado.
En la ISO/IEC 23009-1 se definen mensajes de eventos para archivos MP4, y los mismos se llevan en la caja de Mensaje de Evento (“emsg”).
Se definen mensajes de eventos para Flujos de Transporte en la ISO/IEC 13818-1:2013 Amd.4, donde se define que se usan Paquetes de Transporte con un valor de PID 0x0004 para el transporte de datos de información de transmisión adaptativa de flujos, cuyo formato de la carga útil es el mismo que el correspondiente a archivos MP4 y, por lo tanto, se especifica también en la ISO/IEC 23009-1.
Tras leer el archivo de manifiesto actualizado, el cliente sabrá que hay disponible un grupo de multidifusión, e intentará incorporarse al mismo emitiendo una solicitud de incorporación IGMP.
El cliente habrá leído y conocerá el número de secuencia de fragmento o índice del fragmento de unidifusión en curso que se ha distribuido, e inspeccionará el flujo de multidifusión que está corriendo en ese momento en relación con el parámetro CHUNK_INDEX con el fin de identificar el(los) fragmento(s) subsiguiente(s) a distribuir desde esta fuente.
Cuando el cliente se incorpora por primera vez a un flujo de multidifusión, puede que los primeros datos que reciba no sean del inicio de un fragmento. El cliente necesita identificar un punto en el flujo de multidifusión que se corresponda con un punto en los datos de unidifusión que ya ha recibido. Uno de estos puntos es el inicio de un fragmento, identificado en esta invención, según se ha descrito anteriormente, mediante la observación o bien de una reducción en el valor del parámetro CHUNK_OFFSET o bien un cambio en el parámetro CHUNK_INDEX. El cliente identifica el mismo punto en los datos de unidifusión que ha recibido por un cambio similar en el parámetro numérico asociado a los fragmentos de unidifusión con respecto al cambio del valor del parámetro CHUNK_INDEX en la multidifusión. El cliente procesa fragmentos de unidifusión hasta el punto identificado, y, a continuación, procesa fragmentos de multidifusión a partir de ese mismo punto en el adelante.
En el flujo de multidifusión puede usarse un parámetro para indicar que el flujo de multidifusión está a punto de finalizar y que debería iniciarse una solicitud del manifiesto en relación con el flujo de unidifusión.
Una de las maneras de señalizar que la distribución por multidifusión ya no estará disponible en poco tiempo consiste en señalizar esto en el encabezamiento de carga útil RTP Esto se podría señalizar como una bandera de un bit en cada paquete RTP, la cual, cuando se fija a “1”, indica que este fragmento del contenido es el último que se va a distribuir por multidifusión; o se podría señalizar como un valor numérico de múltiples bits que indique el número de fragmentos, incluyendo el correspondiente en curso, que se distribuirá por multidifusión, de manera que el valor de 0 indique que el final de la distribución por multidifusión no es inminente.
Cuando el cliente está recibiendo contenido a través de unidifusión, presenta solicitudes HTTP GET regulares al servidor de contenido en relación con actualizaciones del manifiesto. Estas solicitudes pueden ser capturadas por el módulo lógico de conmutación a través de registros HTTP, y se pueden usar para ayudar a determinar si se debe realizar una conmutación entre unidifusión y multidifusión y cuándo hacerlo. No obstante, cuando se distribuye por medio de multidifusión, el cliente no presenta solicitudes regulares, ya que toda la información requerida por el cliente para conmutar de vuelta a la unidifusión se incorpora en forma de paquetes marcadores en el flujo de multidifusión.
Por lo tanto, en otro ejemplo de la invención, el cliente está configurado para presentar solicitudes HTTP “HEAD” regulares al servidor de contenido 104 en relación con actualizaciones del archivo de manifiesto. En general, una solicitud HEAD devuelve metadatos asociados a un archivo solicitado, en este caso el archivo de manifiesto. Aunque el archivo de manifiesto no se necesita realmente durante un flujo de multidifusión, el hecho de obligar al cliente a presentar solicitudes HEAD a intervalos regulares mientras está recibiendo un flujo de multidifusión proporciona retroalimentación al servidor de contenido 104 de que el cliente está recibiendo activamente el flujo de multidifusión. De este modo, el módulo lógico de conmutación puede determinar cuántos clientes de la red está recibiendo activamente cualquier contenido dado a través de un canal de multidifusión.
Comparando el número de solicitudes HEAD con el número de solicitudes GET (presentadas por clientes receptores de unidifusión para solicitar fragmentos específicos de contenido) en el servidor de contenido 104, el módulo lógico de conmutación 232 puede determinar en cualquier momento cuántos clientes están recibiendo qué contenido, y si usar la multidifusión o la unidifusión. A la luz de esta información, el módulo lógico de conmutación 232 puede elegir adecuadamente multidifusión o unidifusión para un contenido particular.
El hecho de obligar a los clientes receptores a enviar solicitudes HEAD en lugar de solicitudes GET permite que el servidor de contenido diferencie fácilmente entre retroalimentación de unidifusión (GET) y retroalimentación de multidifusión (HEAD).
Además, otra de las ventajas principales de este planteamiento es que es independiente de cualquier módulo lógico de multidifusión de nivel inferior. Por ejemplo, incluso con una que llevase un recuento de las incorporaciones IGMP para un flujo de multidifusión, no hay forma alguna de deducir qué clientes están consumiendo todavía el contenido. Los clientes pueden abandonar explícitamente el grupo de multidifusión, pero también pueden dejar de escuchar simplemente. Este planteamiento proporciona una solución.
Mientras que los ejemplos anteriores se han descrito en relación con la transmisión en flujo de contenido directamente a un cliente usando unidifusión o multidifusión, uno de los ejemplos alternativos propone el uso de un proxy de cliente. Un proxy de cliente podría residir en un rúter o concentrador configurado adecuadamente y local con respecto al cliente, el cual puede proporcionar un servicio proxy a más de un cliente. La finalidad principal de un proxy del cliente es recibir datos de fragmentos de contenido mediante multidifusión, almacenarlos localmente, y anunciarlos a los clientes como disponibles por unidifusión desde el proxy de cliente. Esto permitiría el uso de la distribución por multidifusión para distribuciones para el proxy del cliente, lográndose las ventajas de eficiencia de red de la distribución por multidifusión, y permite una futura distribución a clientes que podrían no soportar la multidifusión y/o que estén conectados al proxy usando una tecnología que no resulte suficientemente adecuada para distribuir datos por multidifusión (tal como la WiFi).
En general, cabe señalar en la presente que, aunque lo anterior describe ejemplos de la invención, hay diversas variaciones y modificaciones que se pueden aplicar a los ejemplos descritos sin apartarse con respecto al alcance de la presente invención según se define en las reivindicaciones adjuntas. Un experto en la materia reconocerá modificaciones sobre los ejemplos descritos.

Claims (2)

REIVINDICACIONES
1. Método de gestión de distribución de vídeo por multidifusión que comprende:
recibir un flujo de vídeo de multidifusión en una pluralidad de dispositivos de cliente desde un servidor; transmitir regularmente desde cada uno de los dispositivos de cliente, mientras un flujo de vídeo de multidifusión está siendo recibido, un primer mensaje al servidor como respuesta a la recepción del flujo de vídeo de multidifusión, en el que el primer mensaje es un mensaje de solicitud HTTP HEAD para actualizaciones de un archivo de manifiesto asociado al flujo de vídeo;
determinar el número de dispositivos de cliente que reciben el flujo de vídeo de multidifusión basándose en los primeros mensajes transmitidos regularmente;
recibir un flujo de vídeo de unidifusión en una pluralidad de dispositivos de cliente desde el servidor; transmitir regularmente desde cada uno de los dispositivos de cliente que reciben un flujo de vídeo de unidifusión, mientras un flujo de vídeo de unidifusión está siendo recibido, un segundo mensaje al servidor como respuesta a la recepción del flujo de vídeo de unidifusión, siendo el segundo mensaje una solicitud HTTP GET y siendo diferente con respecto al primer mensaje;
determinar el número de dispositivos de cliente que reciben el flujo de vídeo de unidifusión basándose en los segundos mensajes transmitidos; y
gestionar la distribución de vídeo por multidifusión en función de una comparación de los números determinados para decidir si usar multidifusión o unidifusión para distribuir el flujo de vídeo.
2. Método según cualquier reivindicación anterior, en el que la gestión comprende determinar si se continúa con la transmisión del flujo de vídeo por multidifusión.
ES15714258T 2014-03-31 2015-03-24 Transmisión de flujos por multidifusión Active ES2842589T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP14250067 2014-03-31
PCT/GB2015/050875 WO2015150737A1 (en) 2014-03-31 2015-03-24 Multicast streaming

Publications (1)

Publication Number Publication Date
ES2842589T3 true ES2842589T3 (es) 2021-07-14

Family

ID=50489032

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15714258T Active ES2842589T3 (es) 2014-03-31 2015-03-24 Transmisión de flujos por multidifusión

Country Status (5)

Country Link
US (1) US10659502B2 (es)
EP (1) EP3127334B1 (es)
CN (1) CN106233735B (es)
ES (1) ES2842589T3 (es)
WO (1) WO2015150737A1 (es)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3403409A1 (en) 2016-01-15 2018-11-21 VID SCALE, Inc. Scalable coding based video distribution
US20170374581A1 (en) * 2016-06-23 2017-12-28 Huawei Technologies Co., Ltd. System and method for delivering unicast and broadcast traffic in a communication network
WO2018164355A1 (ko) * 2017-03-10 2018-09-13 엘지전자 주식회사 멀티캐스트 신호 송수신 방법 및 장치
US11089341B2 (en) 2018-05-11 2021-08-10 Prowire Sport Llc System and method for capturing and distributing a live audio stream of a live event in real-time
US11606407B2 (en) * 2018-07-05 2023-03-14 Prowire Sport Limited System and method for capturing and distributing live audio streams of a live event
US11659222B2 (en) 2018-08-14 2023-05-23 Comcast Cable Communications, Llc Adaptive multicast streaming
CN111372103B (zh) * 2018-12-26 2023-05-26 中兴通讯股份有限公司 一种组播方法、装置、设备和计算机存储介质
US10743041B1 (en) 2019-01-31 2020-08-11 DISH Technologies L.L.C. Systems and methods for facilitating adaptive content splicing
EP3932082A1 (en) * 2019-02-27 2022-01-05 British Telecommunications public limited company Multicast assisted delivery
US11638049B2 (en) 2019-10-16 2023-04-25 Dish Network L.L.C. Systems and methods for content item recognition and adaptive packet transmission
US10880351B1 (en) 2019-10-16 2020-12-29 Dish Network L.L.C. Systems and methods for adapting content items to endpoint media devices
US11303943B2 (en) 2019-10-16 2022-04-12 Dish Network L.L.C. Systems and methods for facilitating adaptive content items for delivery in a packet stream
US11057687B2 (en) 2019-11-14 2021-07-06 Wurl Inc. Auxiliary information in manifests
US11218525B2 (en) 2020-01-21 2022-01-04 Dish Network L.L.C. Systems and methods for adapting content delivery based on endpoint communications
US11245946B2 (en) 2020-01-21 2022-02-08 Dish Network L.L.C. Systems and methods for adapting content items to secured endpoint media device data
US11012737B1 (en) 2020-04-27 2021-05-18 Dish Network L.L.C. Systems and methods for audio adaptation of content items to endpoint media devices
GB2598295B (en) 2020-08-19 2023-02-22 British Telecomm Content delivery
US11108839B1 (en) * 2021-02-04 2021-08-31 Nice Ltd. Method and system for providing elastic media forking infrastructure to cloud distributed real-time applications

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1175025B1 (en) * 2000-02-02 2007-10-31 NTT DoCoMo, Inc. Wireless base station, method of selecting wireless base station, method of multicasting, and wireless terminal
US20040268233A1 (en) * 2002-06-27 2004-12-30 Oki Electric Industry Co., Ltd. Information processing apparatus and information processing method
JP4428934B2 (ja) * 2003-03-24 2010-03-10 富士通株式会社 映像選択サーバ、映像配信システム、および映像選択方法
US7643480B2 (en) 2004-01-22 2010-01-05 Hain-Ching Liu Method and system for reliably and efficiently transporting data over a network
US9197857B2 (en) 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
WO2006072825A1 (en) * 2005-01-07 2006-07-13 Nortel Networks Limited Systems and methods for distributing content in wireless networks
US20070168523A1 (en) * 2005-04-11 2007-07-19 Roundbox, Inc. Multicast-unicast adapter
US20070083667A1 (en) * 2005-09-09 2007-04-12 Smiths Detection Inc. Method and system for multicast delivery of multimedia content on demand
EP1961156A4 (en) * 2005-12-14 2013-04-03 Ericsson Telefon Ab L M ARRANGEMENT AND METHOD IN A MOBILE TELECOMMUNICATION SYSTEM
US7889732B2 (en) * 2005-12-22 2011-02-15 Alcatel-Lucent Usa, Inc. Method for converting between unicast sessions and a multicast session
JP4287448B2 (ja) * 2006-06-16 2009-07-01 株式会社東芝 通信装置、通信端末装置、通信システム、方法およびプログラム
US20090052450A1 (en) * 2007-08-22 2009-02-26 Mockett Gregory P Apparatus, system, and method for video delivery using dual multicast streams with one being delayed
US8752100B2 (en) * 2008-08-29 2014-06-10 At&T Intellectual Property Ii, Lp Systems and methods for distributing video on demand
US20100281108A1 (en) * 2009-05-01 2010-11-04 Cohen Ronald H Provision of Content Correlated with Events
EP2600539B1 (en) * 2010-07-26 2019-01-16 Electronics And Telecommunications Research Institute Method for transmitting control signals using an uplink
US9716920B2 (en) * 2010-08-05 2017-07-25 Qualcomm Incorporated Signaling attributes for network-streamed video data
US20120140645A1 (en) * 2010-12-03 2012-06-07 General Instrument Corporation Method and apparatus for distributing video
US9510061B2 (en) 2010-12-03 2016-11-29 Arris Enterprises, Inc. Method and apparatus for distributing video
US8532171B1 (en) * 2010-12-23 2013-09-10 Juniper Networks, Inc. Multiple stream adaptive bit rate system
WO2012096372A1 (ja) 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US8819264B2 (en) * 2011-07-18 2014-08-26 Verizon Patent And Licensing Inc. Systems and methods for dynamically switching between unicast and multicast delivery of media content in a wireless network
US9826502B2 (en) * 2011-07-25 2017-11-21 Qualcomm Incorporated Managing handoff triggering between unicast and multicast services
US8443408B2 (en) * 2011-09-12 2013-05-14 Rogers Communications Inc. Method and system for managing bandwidth
CN102387140B (zh) * 2011-10-18 2015-01-21 华为技术有限公司 无线局域网络中开展多媒体业务的方法、装置及系统
US8879458B2 (en) * 2012-04-23 2014-11-04 Hewlett-Packard Development Company, L.P. Transmission in a network with active and sleeping clients
US8831001B2 (en) 2012-06-24 2014-09-09 Audiocodes Ltd. Device, system, and method of voice-over-IP communication
WO2014058366A1 (en) * 2012-10-11 2014-04-17 Telefonaktiebolaget L M Ericsson (Publ) Methods and nodes for balancing load on channels
CN104737514B (zh) 2012-10-23 2018-08-17 瑞典爱立信有限公司 用于分布媒体内容服务的方法和设备
US20140254456A1 (en) * 2013-03-08 2014-09-11 Electronics And Telecommunications Research Institute Method for counting terminals for multicast/broadcast service
EP2785006A1 (en) * 2013-03-28 2014-10-01 British Telecommunications public limited company Content delivery system and method
US9674251B2 (en) * 2013-06-17 2017-06-06 Qualcomm Incorporated Mediating content delivery via one or more services

Also Published As

Publication number Publication date
CN106233735B (zh) 2020-10-02
EP3127334A1 (en) 2017-02-08
EP3127334B1 (en) 2020-10-21
US10659502B2 (en) 2020-05-19
WO2015150737A1 (en) 2015-10-08
CN106233735A (zh) 2016-12-14
US20170118263A1 (en) 2017-04-27

Similar Documents

Publication Publication Date Title
ES2842589T3 (es) Transmisión de flujos por multidifusión
US11805286B2 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
ES2848116T3 (es) Transmisión basada en formato de archivo con formatos DASH basados en LCT
US20170127147A1 (en) Multicast streaming
TWI623226B (zh) 用於儲存媒體片段之基於目錄限制之系統及方法
RU2639725C2 (ru) Способ и устройство для приемопередачи данных для системы передачи мультимедиа
JP6606240B2 (ja) 放送システムにおけるマルチメディアデータの転送装置及び方法
JP2017153127A (ja) メディアコンテンツ復号装置
WO2015107787A1 (ja) 通信装置、通信データ生成方法、および通信データ処理方法
US20110087794A1 (en) System and Method to Support Different Ingest and Delivery Schemes for a Content Delivery Network
US11284135B2 (en) Communication apparatus, communication data generation method, and communication data processing method
WO2018133601A1 (zh) 一种流媒体传输方法、装置、服务器及终端
US20110082943A1 (en) P2p network system and data transmitting and receiving method thereof
CN105191324B (zh) 通信设备、通信数据生成方法、以及通信数据处理方法
KR102176404B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
KR101855327B1 (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법
KR20180039604A (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법