ES2965183T3 - Procedimiento y sistema para la distribución de contenido audiovisual en vivo - Google Patents
Procedimiento y sistema para la distribución de contenido audiovisual en vivo Download PDFInfo
- Publication number
- ES2965183T3 ES2965183T3 ES18836386T ES18836386T ES2965183T3 ES 2965183 T3 ES2965183 T3 ES 2965183T3 ES 18836386 T ES18836386 T ES 18836386T ES 18836386 T ES18836386 T ES 18836386T ES 2965183 T3 ES2965183 T3 ES 2965183T3
- Authority
- ES
- Spain
- Prior art keywords
- demulticaster
- controller
- client
- audiovisual content
- live audiovisual
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 52
- 238000006243 chemical reaction Methods 0.000 claims abstract description 14
- 238000004891 communication Methods 0.000 claims description 23
- 230000008439 repair process Effects 0.000 claims description 19
- 230000008901 benefit Effects 0.000 claims description 13
- 101100524346 Xenopus laevis req-a gene Proteins 0.000 description 20
- 230000004044 response Effects 0.000 description 16
- 230000005540 biological transmission Effects 0.000 description 13
- 101100524347 Xenopus laevis req-b gene Proteins 0.000 description 10
- 238000012545 processing Methods 0.000 description 10
- 238000013459 approach Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 8
- 230000001105 regulatory effect Effects 0.000 description 8
- 230000003044 adaptive effect Effects 0.000 description 5
- 239000003795 chemical substances by application Substances 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 3
- WBMKMLWMIQUJDP-STHHAXOLSA-N (4R,4aS,7aR,12bS)-4a,9-dihydroxy-3-prop-2-ynyl-2,4,5,6,7a,13-hexahydro-1H-4,12-methanobenzofuro[3,2-e]isoquinolin-7-one hydrochloride Chemical compound Cl.Oc1ccc2C[C@H]3N(CC#C)CC[C@@]45[C@@H](Oc1c24)C(=O)CC[C@@]35O WBMKMLWMIQUJDP-STHHAXOLSA-N 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- 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/21—Server components or server architectures
- H04N21/218—Source of audio or video content, e.g. local disk arrays
- H04N21/2187—Live feed
-
- 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/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- 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/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- 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/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- 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/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/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
- H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
-
- 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un sistema de entrega de contenido audiovisual en vivo incluye: un cliente (110) que tiene acceso a una red de proveedor (102) a través de una puerta de enlace (140); un equipo de entrega de contenido audiovisual en vivo (120) que comprende un multidifusor para transmitir contenidos audiovisuales en vivo en forma de multidifusión a través de la red del proveedor (102); siendo capaz un demulticaster (150) de realizar una conversión en forma unicast de contenidos audiovisuales en vivo recibidos en forma multicast desde el multicaster; y un controlador (130) que gestiona el enrutamiento de solicitudes para obtener contenidos audiovisuales en vivo. El cliente (110) realiza un procedimiento de descubrimiento con el objetivo de recibir información sobre la posible presencia y disponibilidad del demulticaster (150). Cuando el cliente (110) pretende recibir un contenido audiovisual en vivo dirigido, el cliente (110) envía al controlador (130) una solicitud que proporciona una indicación de presencia y disponibilidad, o no, del demulticaster (150). Luego el controlador (130) decide cómo redirigir al cliente (110) para cumplir con la solicitud, según al menos la indicación de presencia y disponibilidad, o no, del demulticaster (150). (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Procedimiento y sistema para la distribución de contenido audiovisual en vivo
CAMPO TÉCNICO
La presente invención se refiere, en general, a distribuir un contenido audiovisual en vivo a un dispositivo cliente, un dispositivo de pasarela que interconecta una red de área local con una red de proveedor, estando el dispositivo cliente conectado a la red de área local, estando un equipo adaptado para proporcionar el contenido visual en vivo conectado a la red de proveedor.
TÉCNICA RELACIONADA
En el pasado, la mayoría de las tecnologías de emisión en vivo de vídeo se basaban en protocolos de emisión en continuo tales como RTP ("protocolo de transporte en tiempo real", tal como se define en el documento normativo RFC 3550) o RTSP ("protocolo de emisión en continuo en tiempo real", como se define en el documento normativo RFC 2326). Las tecnologías de emisión en continuo actuales se basan casi exclusivamente en el protocolo HTTP ("Protocolo de transferencia de hipertexto", tal como se define en el documento normativo RFC 2616) y están diseñadas para funcionar de manera eficiente en redes HTTP grandes y distribuidas, tales como Internet.
La emisión en continuo con tasa de bits adaptable (ABS) es una técnica de emisión en continuo HTTP popular que se utiliza para emitir en continuo contenidos a través de redes informáticas y HLS ("emisión en vivo HTTP"), que es un protocolo de comunicaciones de emisión en vivo basado en HTTP y desarrollado por Apple Inc., es una implementación particular. HLS funciona dividiendo el flujo AV ("audiovisual") general en una secuencia de pequeñas descargas de archivos basadas en HTTP, cada una de las cuales contiene una parte de un flujo de transporte general potencialmente ilimitado. El contenido AV está disponible en diversas resoluciones y está dividido en fragmentos, en donde un fragmento es una porción del contenido AV, cualquiera que sea la resolución real, que corresponde a un segmento de tiempo del contenido AV. A medida que se reproduce la emisión AV en continuo, un dispositivo cliente que descodifica el contenido AV puede seleccionar entre diferentes versiones alternativas (también denominadascapasorepresentaciones)que contienen el mismo material codificado a diversas resoluciones respectivas (diversas tasas de bits respectivas), permitiendo que la sesión de emisión en continuo se adapte a los recursos de transmisión disponibles de la red y/o a los recursos de procesamiento disponibles del dispositivo cliente. Al inicio de la sesión de emisión en continuo, el dispositivo cliente típicamente descarga una lista de reproducción en forma de archivo de texto con la extensión de archivo "M3U" o "m3u8". Este archivo de texto contiene los metadatos de las diversas versiones alternativas que están disponibles para el contenido AV en cuestión.
La emisión en continuo fluida implementa un enfoque de ABS similar, que es una característica de Internet Information Services (IIS) Media Services, una plataforma integrada de distribución de medios basada en HTTP proporcionada por Microsoft Corp. A diferencia de HLS, donde la emisión AV en continuo se trunca en varios archivos que contienen fragmentos complementados con archivos de lista de reproducción, La emisión en continuo fluida se basa en un único archivo AV truncado en partes, cada parte del archivo contiene un descriptor que indica la capa en cuestión y un tiempo de referencia en el contenido AV. Sin embargo, la base del protocolo y los beneficios son equivalentes.
De manera similar, se puede considerar emisión en continuo dinámica HTTP (HDS) y emisión en continuo adaptable dinámica sobre HTTP de Adobe Systems, una tecnología de emisión en continuo multimedia desarrollada por Moving Picture Experts Group y denominada MPEG DASH, que está relacionada con HDS, HLS y emisión en continuo fluida. A continuación se usan archivos con extensión "mpd".
Las tecnologías de emisión en continuo basadas en HTTP son muy cómodas, ya que HTTP permite atravesar firewalls y garantiza la integridad de los datos basándose en TCP ("Protocolo de control de transmisión", tal como lo define el documento normativo RFC 793). Sin embargo, la naturaleza de unidifusión de HTTP en el contexto de ABS está creando enormes problemas de escalabilidad para los operadores de CDN ("red de distribución de contenido") que les impiden adoptar mecanismos basados en ABS para la emisión en vivo. De hecho, las tecnologías de emisión en continuo basadas en HTTP dependen de transmisiones de unidifusión y, por lo tanto, pueden ser insostenibles en términos de infraestructura de back-end, ya que numerosos usuarios pueden solicitar simultáneamente ver un contenido AV en vivo.
En vista de dichos inconvenientes de las tecnologías de emisión en continuo basadas en HTTP para la distribución de contenido AV en vivo, muchos operadores dependen de tecnologías de emisión en vivo basadas en multidifusión. Esto permite dimensionar la infraestructura de back-end de una forma más rentable. Por consiguiente, ha surgido una mejora con Multidifusión-ABR, denominada M-ABR, como se describe en el documento de patente EP 2704391 A1. Consiste en enviar el archivo de manifiesto, así como las distintas representaciones del contenido AV en vivo, como paquetes IP multidifusión ("Protocolo de Internet", tal como lo define el documento normativo RFC 791) a través de un medio multidifusión o radiodifusión, proporcionando así una importante reducción del consumo de los recursos de la red. En el lado de la red, existe el llamado servidor de multidifusión (denominadomultidifusor)que básicamente adquiere el manifiesto y a continuación los segmentos correspondientes desde un servidor de origen. El multidifusor encapsula los segmentos en paquetes IP de multidifusión usando algún esquema de encapsulación de un protocolo de transporte intermedio. En el lado de la pasarela, existe un llamado demultidifusor que recibe los paquetes IP de multidifusión implementando dicho protocolo de transporte intermedio y extrae la carga útil como un segmento de medios listo para alimentar a un reproductor del dispositivo cliente mediante transmisiones de unidifusión. El reproductor solicita los segmentos al demultidifusor, que actúa como un servidor HTTP desde el punto de vista del dispositivo cliente, de una manera de unidifusión convencional (por ejemplo, MPEG DASH) basándose en el período de duración del segmento y en la calidad/tasa de bits estimada.
Para garantizar que el dispositivo cliente use el demultidifusor como un proxy, el documento de patente EP 2704391 A1 divulga un mecanismo de redirección en el que un controlador CDN desde el cual el dispositivo cliente solicita la distribución del contenido AV en vivo redirige el dispositivo cliente hacia el demultidifusor en la pasarela que interconecta una red de área local (LAN) en la que está ubicado el dispositivo cliente y una red de proveedor en la que están ubicados el controlador CDN y el multidifusor.
El documento de patente US 2002/143951 A1 describe un procedimiento para enviar información de multidifusión a un usuario. Este documento de patente describe agentes, programas de red, que residen en ordenadores habilitados para multidifusión.
El documento de patente US 2009/147718 A1 describe un procedimiento que incluye asignar una conexión de multidifusión a un identificador de recurso uniforme de unidifusión, establecer un estado para una conversión de multidifusión a unidifusión, asignar puertos, recibir paquetes de datos con dirección de multidifusión y convertir los paquetes de datos con dirección de multidifusión en paquetes de datos con direcciones de unidifusión.
Sin embargo, por consideraciones de flexibilidad, sería deseable que el controlador CDN determine dinámicamente si la pasarela que interconecta la LAN en la que está ubicado el dispositivo cliente y la red de proveedor implementa dicho demultidifusor y, si lo hay, si este demultidifusor es capaz de hacerse cargo del dispositivo cliente en cuestión. Es además deseable proporcionar una solución que sea flexible en términos de ubicación efectiva del dispositivo que se considera como el controlador CDN desde el punto de vista del dispositivo cliente, y en particular en la que la ubicación efectiva del dispositivo que se considera como el controlador CDN no tiene consecuencias en la implementación del dispositivo cliente. Es además deseable proporcionar una solución que sea lo suficientemente flexible para soportar redes de proveedor sin capacidad de comunicación de enlace ascendente desde el dispositivo cliente (por ejemplo, red de radiodifusión), así como redes de proveedor con dicha capacidad de comunicación de enlace ascendente.
Es además deseable proporcionar una solución que funcione en el contexto de la emisión en continuo adaptable, permitiendo así a los usuarios beneficiarse de la disponibilidad de diferentes versiones (o representaciones) alternativas del contenido AV en vivo codificado a varias tasas de bits (o resoluciones) respectivas.
También es particularmente deseable proporcionar una solución que sea sencilla y rentable.
RESUMEN DE LA INVENCIÓN
Con ese fin, la presente invención se refiere a un procedimiento, de acuerdo con la reivindicación independiente 1, para distribuir un contenido audiovisual en vivo objetivo a un cliente, realizándose el procedimiento mediante un sistema de distribución de contenido audiovisual en vivo que incluye:
- el cliente ubicado en una red de área local interconectada a una red de proveedor mediante una pasarela que proporciona acceso a la red de proveedor o ubicado en la pasarela que proporciona acceso a la red de proveedor; - un equipo de distribución de contenido audiovisual en vivo que comprende uno o más servidores entre los cuales un multidifusor para transmitir contenidos audiovisuales en vivo en forma de multidifusión por medio de la red de proveedor;
- un demultidifusor en la pasarela que proporciona acceso a la red de proveedor o en cualquier dispositivo ubicado en la red de área local, pudiendo el demultidifusor realizar una conversión en forma de unidifusión de contenidos audiovisuales en vivo recibidos en forma de multidifusión desde el multidifusor;
- un controlador que gestiona el enrutamiento de solicitudes para obtener contenidos audiovisuales en vivo;
El procedimiento comprende:
- el cliente realiza un procedimiento de descubrimiento destinado a recibir, desde la pasarela que da acceso a la red de proveedor y desde cualquier dispositivo ubicado en la red de área local, información sobre la posible presencia y disponibilidad del demultidifusor;
y cuando el cliente pretende recibir el contenido audiovisual en vivo objetivo:
- el cliente envía al controlador una solicitud para obtener el contenido audiovisual en vivo objetivo que proporciona una indicación de la presencia y disponibilidad, o no, del demultidifusor;
- el responsable del tratamiento decide cómo redirigir al cliente para cumplir la solicitud de obtener el contenido audiovisual en vivo objetivo, de acuerdo con al menos con la indicación de presencia y disponibilidad, o no, del demultidifusor.
Así, al recibir en la solicitud la indicación de presencia y disponibilidad, o no, del demultidifusor, el controlador puede determinar si es posible o no hacer que el cliente se beneficie de la conversión de multidifusión a unidifusión. Evita que el controlador intente redirigir al cliente hacia un demultidifusor que no está presente o que está presente pero no disponible (por ejemplo, activo). Evita que el controlador tenga que comprobar por sí mismo si la pasarela u otro dispositivo de la red de área local integra un demultidifusor y si el demultidifusor, si lo hay, está efectivamente activo, lo que consume tiempo y recursos cuando el controlador interactúa con numerosas pasarelas.
La invención también presenta un sistema correspondiente de acuerdo con la reivindicación independiente 17. En las reivindicaciones dependientes se definen realizaciones detalladas adicionales.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Las características de la invención se manifestarán más claramente a partir de la lectura de la siguiente descripción de al menos una realización, estando dicha descripción realizada con referencia a los dibujos adjuntos, entre los cuales:
- La figura 1 representa esquemáticamente un sistema de distribución de contenido AV en vivo de acuerdo con la presente invención;
- Las figuras 2A y 2B representan esquemáticamente intercambios que se producen en el sistema de distribución de contenido AV en vivo de acuerdo con la presente invención;
- La figura 3 representa esquemáticamente una arquitectura de hardware de ejemplo de dispositivos en el sistema de distribución de contenido AV en vivo;
- La figura 4 representa esquemáticamente una primera realización del sistema de distribución de contenido AV en vivo;
- Las figuras 5A y 5B representan esquemáticamente intercambios que se producen en la primera realización del sistema de distribución de contenido AV en vivo;
- La figura 6 representa esquemáticamente una segunda realización del sistema de distribución de contenido AV en vivo;
- La figura 7 representa esquemáticamente los intercambios que se producen en la segunda realización del sistema de distribución de contenido AV en vivo;
- La figura 8 representa esquemáticamente una tercera realización del sistema de distribución de contenido AV en vivo;
- Las figuras 9A y 9B representan esquemáticamente intercambios que se producen en la tercera realización del sistema de distribución de contenido AV en vivo;
- La figura 10 representa esquemáticamente una cuarta realización del sistema de distribución de contenido AV en vivo; y
- La figura 11 representa esquemáticamente intercambios que se producen en la cuarta realización del sistema de distribución de contenido AV en vivo.
DESCRIPCIÓN DETALLADA DE AL MENOS UNA REALIZACIÓN
La figura 1 representa esquemáticamente un sistema de distribución de contenido AV en vivo de acuerdo con la presente invención.
El sistema de distribución de contenido AV en vivo comprende una pasarela GW 140 que interconecta una LAN 101 y una red de proveedor PN 102. La red de proveedor PN 102 es, por ejemplo, una red ISP ("proveedor de servicios de Internet"). La red de proveedor PN 102 es, por ejemplo, una red de radiodifusión por cable o satélite. Por lo tanto, la red de proveedor PN 102 puede permitir transmisiones de enlace descendente y de enlace ascendente, o solo permitir transmisiones de enlace descendente, como se detalla más adelante. En una realización preferida, la LAN 101 y la red de proveedor PN 102 admiten el protocolo IP. La pasarela GW 140 es preferentemente una pasarela residencial.
El sistema de distribución de contenido AV en vivo típicamente comprende una LAN plural, interconectada de esta manera por pasarelas respectivas a la red de proveedor PN 102, para permitir que dispositivos cliente en diferentes ubicaciones geográficas se beneficien de la distribución de contenido AV en vivo.
En el sistema de distribución de contenido AV en vivo, al menos un cliente incluye un reproductor PL 110 o está conectado al mismo. El cliente típicamente está conectado a la LAN 101. El reproductor PL 110 está adaptado y configurado para consumir (por ejemplo, reproducir, grabar) contenidos AV en vivo recibidos por el cliente en forma de unidifusión. Preferentemente, el cliente está adaptado y configurado para comunicarse y recibir contenidos AV en vivo usando HTTP y, por ejemplo, adaptado y configurado para consumir contenido AV en vivo conforme al esquema HAS ("emisión en continuo adaptable HTTP"). Por tanto, el cliente no puede recibir contenidos AV en vivo en forma de multidifusión ni de radiodifusión. Como se detalla más adelante, el reproductor PL 110 es independiente de la infraestructura del sistema de distribución de contenido AV en vivo. Las formas del cliente recibieron datos de contenido AV en vivo destinados a ser consumidos por el reproductor PL 110 de modo que los datos de contenido AV en vivo estén en una forma adecuada para el reproductor PL 110. El cliente realiza intercambios de protocolos para permitir que el reproductor PL 110 reciba dichos datos de contenido AV en vivo. Más adelante se considera, en aras de la simplicidad, que el cliente y el reproductor PL 110 son una sola entidad.
En el sistema de distribución de contenido AV en vivo, un equipo de distribución de contenido CDE 120 está conectado directa o indirectamente a la red de proveedor PN 102. El equipo de distribución de contenido CDE 120 comprende uno o más servidores. El equipo de distribución de contenido CDE 120 comprende al menos un multidifusor. El multidifusor es el encargado de proporcionar por medio de la red de proveedor PN 102 contenidos AV en vivo en forma de multidifusión. Por ejemplo, el multidifusor proporciona diversas representaciones de los contenidos AV en vivo en forma de flujos de multidifusión usando RTP sobre UDP ("Protocolo de datagramas de usuario", tal como se define en el documento normativo RFC 768). Depender de transmisiones de multidifusión por medio de la red de proveedor PN 102 permite reducir el tamaño de la infraestructura de back-end (es decir, los recursos de procesamiento y el ancho de banda necesarios por el equipo de distribución de contenido CDE 120 para realizar la distribución de contenidos AV en vivo) en comparación con una distribución del contenido AV en vivo en una manera de unidifusión.
Aguas arriba del multidifusor puede estar presente un servidor de origen, también conocido comoempaquetador de origen,encargado de empaquetar las diversas representaciones de los contenidos AV en vivo en segmentos, todos alineados (misma duración, mismas imágenes) como un conjunto de archivos multimedia, por ejemplo, conformes al esquema HAS. Aguas arriba del empaquetador de origen puede estar presente un codificador OTT("Over-The-Top")que distribuye las diversas representaciones del contenido AV en vivo (por ejemplo, canal de televisión) al empaquetador de origen, siendo codificada cada representación por el codificador OTT con una tasa de bits/calidad particular.
La pasarela GW 140 u otro dispositivo en la LAN 101 (incluido el cliente) comprende un demultidifusor DM 150. El demultidifusor DM 150 está adaptado y configurado para recibir paquetes IP de multidifusión transmitidos por el multidifusor, posiblemente a través de la pasarela GW 140 cuando el demultidifusor DM 150 está ubicado en otro dispositivo en la LAN 101.
El demultidifusor DM 150 está adaptado y configurado para extraer segmentos de contenido AV en vivo listos para alimentar al reproductor PL 110 usando transmisiones de unidifusión. Cuando el reproductor PL 110 recibe un contenido AV en vivo, el reproductor PL 110 está adaptado y configurado para monitorizar el ancho de banda disponible para recibir el contenido AV en vivo, y además para seleccionar la representación del contenido AV en vivo que coincida con el ancho de banda disponible y preferentemente con los recursos de procesamiento internos disponibles. Por lo tanto, el demultidifusor DM 150 está adaptado y configurado para realizar conversión de multidifusión a unidifusión. Para ello, el demultidifusor DM 150 está adaptado y configurado para gestionar registros de flujos de multidifusión, por ejemplo, implementando el protocolo IGMP ("Protocolo de gestión de grupos de Internet", tal como se define en el documento normativo RFC 3376). Además, el demultidifusor DM 150 sabe mediante configuración previa qué contenido AV en vivo podría recibirse a través de transmisiones de multidifusión, por ejemplo, usando un flujo o canal de multidifusión dedicado predefinido proporcionado por el equipo de distribución de contenido CDE 120 o intercambiando con un servidor de configuración dedicado predefinido del equipo de distribución de contenido CDE 120.
El demultidifusor DM 150 se puede adaptar y configurar además para solicitar, y recibir en respuesta, segmentos de contenidos AV en vivo en forma de unidifusión a un servidor de unidifusión de reparación RUS del equipo de distribución de contenido CDE 120, con el fin de habilitar el demultidifusor DM 150 para recuperar segmentos de contenido AV en vivo perdidos durante las transmisiones de multidifusión. Este aspecto se aborda más adelante.
Las pasarelas y LAN conectadas a la red de proveedor PN 102, tales como la pasarela GW 140 y la LAN 101, pueden incluir dicho demultidifusor, mientras que otras pasarelas u otras LAN conectadas a la red de proveedor P<n>102 pueden no incluir dicho demultidifusor. Además, entre las pasarelas o LAN que incluyen dicho demultidifusor, algunos demultidifusores pueden estar presentes, pero no estar activos, y algunos demultidifusor pueden estar ya quedándose sin memoria y/o recursos de procesamiento. Este aspecto se aborda en detalle más adelante.
En el sistema de distribución de contenido AV en vivo, un controlador CTRL 130 organiza la distribución de contenido AV en vivo, es decir, gestiona el enrutamiento de solicitudes para obtener contenidos audiovisuales en vivo. Dependiendo de la infraestructura del sistema de distribución de contenido AV en vivo, el controlador CTRL 130 puede estar ubicado en la red de proveedor PN 102, o conectado a la misma, o puede estar ubicado en la pasarela GW 140 o en la LAN 101. Cuando se espera que el reproductor PL 110 consuma un contenido AV en vivo (por ejemplo, de acuerdo con una orden del usuario), el reproductor PL 110 contacta con el controlador CTRL 130 para solicitar la distribución del contenido AV en vivo en cuestión. El reproductor PL 110 contacta con el controlador CTRL 130 como si el controlador CTRL 130 fuera un servidor desde el cual se puede distribuir el contenido AV en vivo. El hecho de que el controlador CTRL 130 no sea capaz de distribuir el contenido AV en vivo por sí solo es transparente para el reproductor PL 110. El reproductor PL 110 determina cómo contactar con el controlador CTRL 130 usando una resolución DNS ("sistema de nombres de dominio") o usando la deducción de direcciones a partir de un procedimiento de descubrimiento destinado a detectar la disponibilidad del demultidifusor DM 150 en la pasarela GW 140 o en otro dispositivo en la LAN 101. Este aspecto se aborda en detalle más adelante. Para cumplir con la solicitud de distribución del contenido AV en vivo, el controlador CTRL 130 redirige al reproductor PL 110 a un servidor de unidifusión apropiado (por ejemplo, del equipo de distribución de contenido CDE 120) o al demultidifusor DM 150, de acuerdo con lo que sea factible en vista de la infraestructura del sistema de distribución de contenido AV en vivo y el estado operativo real con el objetivo de optimizar el consumo de recursos en la red de proveedor PN 102. En otras palabras, el controlador decide cómo redirigir al cliente para cumplir las solicitudes de obtención de contenidos AV en vivo objetivo, de acuerdo con al menos la indicación de presencia y disponibilidad, o no, de dicho demultidifusor capaz de proporcionar conversión de multidifusión a unidifusión al cliente. Este aspecto también se aborda en detalle más adelante.
En una realización particular, el demultidifusor DM 150 está instalado en la pasarela GW 140. En otra realización particular, el demultidifusor DM 150 está instalado en un decodificador conectado a la pasarela GW 140. Dicho decodificador está en la LAN 101 y además puede conectarse a la pasarela GW 140 por medio de la LAN 101 o mediante un enlace dedicado.
En una realización particular, el cliente y el reproductor PL 110 están instalados en la pasarela GW 140 o en un decodificador conectado a la misma. Si el demultidifusor DM 150 también está presente en la pasarela GW 140 o en el decodificador conectado a ella, el cliente y el reproductor PL 110 se instalan herméticamente con respecto al demultidifusor DM 150 y, si está presente, al controlador CTRL 130. Esto significa que antes de realizar el procedimiento de descubrimiento, el cliente y el reproductor PL 110 no saben si están ubicados o no en el mismo dispositivo que el demultidifusor DM 150.
Lasfiguras 2Ay2Brepresentan esquemáticamente intercambios que se producen en el sistema de distribución de contenido AV en vivo de acuerdo con la presente invención.
En una etapa 200 en la figura 2A y en una etapa 210 en la figura 2B, el reproductor PL 110 inicia un procedimiento de descubrimiento durante el cual la pasarela GW 140 y cualquier otro dispositivo en la LAN 101 tiene que informar al reproductor PL 110 de si dicha pasarela GW 140 o dicho otro dispositivo en la LAN 101 integra o no un demultidifusor disponible. Cuando el reproductor PL 110 está integrado en un dispositivo distinto de la pasarela GW 140, el procedimiento de descubrimiento se realiza en la LAN 101. Cuando el reproductor PL 110 está alojado en un dispositivo capaz de integrar dicho demultidifusor (tal como la pasarela GW 140), el procedimiento de descubrimiento se realiza además a través de una API ("Interfaz de programación de aplicaciones") del dispositivo que aloja el reproductor PL 110.
Un demultidifusor disponible se refiere a un demultidifusor que, en primer lugar, está presente y que, en segundo lugar, está activo (es decir, en funcionamiento). Un demultidifusor disponible puede denominarse además un demultidifusor que tiene suficiente memoria y/o recursos de procesamiento para hacerse cargo de un contenido AV en vivo suplementario para la conversión de multidifusión a unidifusión.
A continuación, se considerará de manera ilustrativa que el reproductor PL 110 está integrado en un dispositivo distinto de la pasarela GW 140 y que el procedimiento de descubrimiento se realiza únicamente en la LAN 101. Los principios del procedimiento de descubrimiento descritos en el presente documento en el contexto de la LAN 101 se aplicaríanmutatis mutandisen el contexto de la API mencionada anteriormente.
El procedimiento de descubrimiento usa, por ejemplo, un protocolo SDP ("protocolo de descubrimiento de servicios"), tal como el protocolo SSDP ("protocolo simple de descubrimiento de servicios") como también se utiliza en UPnP ("Universal Plug n' Play", tal como se define en el documento normativo ISO /IEC 29341), o la tecnología Zeroconf, tal como Bonjour de Apple o los enfoques de descubrimiento de servicios basados en DNS. Un servidor DNS local ubicado en la pasarela GW 140, por ejemplo, y configurado de antemano posiblemente por el demultidifusor DM 150, cuando está presente, permite la resolución de un nombre de dominio predefinido asociado con dicho demultidifusor DM 150.
Durante el procedimiento de descubrimiento, el reproductor PL 110 sondea la LAN 101 para determinar si hay un demultidifusor presente en la pasarela GW 140 o más generalmente en la LAN 101 y preferentemente si el demultidifusor, si lo hay, está activo o no. Si un dispositivo aloja dicho demultidifusor, dicho dispositivo transmite en respuesta un descriptor que identifica el demultidifusor DM 150 en cuestión. Considerando que la pasarela GW 140 integra el demultidifusor DM 150, la pasarela GW 140 transmite así en respuesta un descriptor que identifica el demultidifusor DM 150. Por tanto, el descriptor indica inherentemente la presencia del demultidifusor DM 150. El descriptor indica además una dirección para contactar con el demultidifusor DM 150 y posiblemente un nombre local del demultidifusor DM 150 que se define mediante la configuración al instalar el demultidifusor DM 150.
Cabe señalar que el término "dirección" usado en el presente documento debe entenderse en su sentido amplio, incluyendo en particular una concatenación de una dirección IP y un número de puerto.
El descriptor puede indicar además si el demultidifusor DM 150 está activo. El descriptor puede indicar además si el demultidifusor DM 150 tiene suficiente memoria y/o recursos de procesamiento para aceptar otra distribución de contenido AV en vivo. Para completar el descriptor con dicha información, el dispositivo que aloja el demultidifusor DM 150 puede solicitar internamente al demultidifusor DM 150 que confirme que está activo, y posiblemente si el demultidifusor DM 150 tiene suficiente memoria y/o recursos de procesamiento para aceptar otra distribución de contenido AV en vivo.
En una realización alternativa preferida, el descriptor sólo indica la presencia del demultidifusor DM 150 y una dirección, tal como una dirección IP y un número de puerto, para contactar con el demultidifusor DM 150. A continuación, el reproductor PL 110 transmite una solicitud dedicada al demultidifusor DM 150 para determinar si el demultidifusor DM 150 está activo o no, usando la dirección proporcionada en el descriptor. Cuando el demultidifusor DM 150 responde a dicha solicitud dedicada, el reproductor Pl 110 concluye que el demultidifusor DM 150 está activo. Al responder, el demultidifusor DM 150 puede indicar si el demultidifusor DM 150 tiene suficiente memoria y/o recursos de procesamiento para aceptar otra distribución de contenido AV en vivo. Si no se recibe respuesta a la solicitud dedicada dentro de un retardo de tiempo de espera predefinido, el reproductor PL 110 concluye que el demultidifusor DM 150 está inactivo.
En una etapa 201 en la figura 2A y en una etapa 211 en la figura 2B, el reproductor PL 110 obtiene una dirección para contactar con el controlador CTRL 130 y transmite al controlador CTRL 130 una solicitud REQ1 que solicita la distribución de un contenido AV en vivo particular. La solicitud REQ1 es, por tanto, un mensaje de unidifusión que identifica el contenido AV en vivo en cuestión. Por ejemplo, la solicitud REQ1 es un mensaje HTTP GET que incluye un URL ("localizador uniforme de recursos") compuesto por un FQDN ("nombre de dominio totalmente cualificado") seguido de una ruta hacia un archivo de texto con una extensión de archivo adecuada (en vista del formato en el que está empaquetado el contenido AV en vivo), tal como:
HTTP GET tv.myISP.com/SportsChannel1.mpd
La solicitud REQ1 incluye además información que indica, tras el descubrimiento, si la pasarela por medio de la cual el reproductor PL 110 accede a la red de proveedor PN 102 integra un demultidifusor capaz de hacerse cargo de la distribución de contenido AV en vivo para el reproductor PL 110. Por ejemplo, reutilizando el ejemplo anterior, la solicitud REQ1 incluye un parámetro en línea que proporciona explícitamente dicha información, de la siguiente manera al indicar la disponibilidad del demultidifusor:
HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=ON
y de la siguiente manera cuando se indica que el demultidifusor no está disponible:
HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=OFF
Otro enfoque preferido es que la solicitud REQ1 incluya implícitamente dicha información. La solicitud REQ1 incluye en cambio un parámetro en línea que proporciona, si lo hay, la dirección del demultidifusor en cuestión o su nombre local. Cuando no se especifica ninguna dirección, no hay demultidifusor disponible y la solicitud REQ1 no incluye ningún parámetro en línea, por ejemplo, de la siguiente manera:
HTTP GET tv.myISP.com/SportsChannel1.mpd
y, de lo contrario, la solicitud REQ1 incluye la dirección o el nombre local de dicho demultidifusor como parámetro en línea, por ejemplo, de la siguiente manera:
HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=192.168.1.100:8000
en donde, en este ejemplo, 192.168.1.100:8000 es la combinación de dirección IP y número de puerto del demultidifusor DM 150.
Este enfoque preferido permite ventajosamente evitar tener solo un nombre y/o dirección local bien establecido para todos los demultidifusores implementados en el sistema de distribución de contenido AV en vivo.
La solicitud REQ1 puede incluir además como parámetro en línea adicional, en caso de que el demultidifusor esté presente, la información FQDN (tv.myISP.com en este ejemplo) de la siguiente manera.
HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=192.168.1.100:8000&FQDN_orig= tv.myISP.com Esto será útil más adelante para el demultidifusor DM 150, por ejemplo, por motivo de control de acceso y para aspectos adicionales que se describen a continuación en una realización detallada. Cabe señalar que este parámetro en línea no es obligatorio. Si no está presente, entonces puede ser añadido por el controlador CTRL 130 al redirigir el reproductor PL 110 al demultidifusor DM 150. Si está presente, es transparente para el controlador CTRL 130, que sólo tiene que copiar los parámetros en línea de la solicitud REQ1 cuando necesita redirigir el reproductor PL 110 hacia el demultidifusor DM 150.
Se considera en la etapa 201 en la figura 2A que la solicitud REQ1 incluye información que indica que un demultidifusor capaz de hacerse cargo de la distribución de contenido AV en vivo para el reproductor PL 110 está presente localmente. Se considera complementariamente en la etapa 211 en la figura 2B que la solicitud REQ1 incluye información que indica que ningún demultidifusor capaz de hacerse cargo de la distribución de contenido AV en vivo para el reproductor PL 110 está presente localmente.
En una etapa 202 en la figura 2A y en una etapa 212 en la figura 2B, el controlador CTRL 130 comprueba si el contenido AV en vivo en cuestión está disponible en cualquier formato. Cuando el controlador CTRL 130 determina que el contenido AV en vivo en cuestión no está disponible de ninguna forma, el controlador CTRL 130 rechaza la solicitud REQ1, por ejemplo, devolviendo un mensaje HTTP ERROR 404.
En la etapa 202 en la figura 2A, el controlador CTRL 130 comprueba si el contenido AV en vivo en cuestión está disponible o no en forma de multidifusión. El controlador CTRL 130 accede, por ejemplo, a un archivo que proporciona una lista de contenidos AV en vivo disponibles en forma de multidifusión. Cuando el controlador CTRL 130 determina que el contenido AV en vivo en cuestión está disponible en forma de multidifusión, el controlador CTRL 130 redirige al reproductor PL 110 hacia el demultidifusor DM 150, como se representa en la figura 2A. Para hacerlo, el controlador CTRL 130 incluye preferentemente en un mensaje de redirección REDIR1 transmitido en respuesta a la solicitud REQ1 la dirección o el nombre local del demultidifusor DM 150 tal como se proporciona como parámetro en línea de la solicitud REQ 1.
Además, cuando la red de proveedor PN 102 permite comunicaciones de enlace ascendente, el controlador CTRL 130 puede incluir en el mensaje de redirección REDIR1, como parámetro en línea la dirección (o URL) de un servidor de distribución de contenido en vivo AV de unidifusión en la red de proveedor PN 102 (por ejemplo, del equipo de distribución de contenido CDE 120). Dicho servidor de distribución de contenido AV en vivo de unidifusión puede ser usado más adelante por el demultidifusor DM 150 para completar segmentos de contenido AV en vivo recibidos en forma de multidifusión mediante segmentos en forma de unidifusión, en particular cuando el demultidifusor DM 150 detecta que falta al menos un contenido AV en vivo entre los segmentos recibidos en forma de multidifusión.
Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR1 es, por ejemplo, el siguiente:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?
FQDN_orig= tv.myISP.com &CDN_unicastServer=<dirección del servidor>
Cuando el controlador CTRL 130 determina que el contenido AV en vivo en cuestión no está disponible en forma de multidifusión, el controlador CTRL 130 redirige al reproductor PL 110 hacia el servidor de distribución de contenido AV en vivo de unidifusión en la red de proveedor PN 102 (por ejemplo, del equipo de distribución de contenido CDE 120), si la infraestructura del sistema de distribución de contenido AV en vivo permite comunicaciones de enlace ascendente desde la pasarela GW 140 y la LAN 101 al equipo de distribución de contenido CDE 120 y si dicho servidor de distribución de contenido AV en vivo de unidifusión existe en la red de proveedor PN 102 (por ejemplo, en el equipo de distribución de contenido CDE 120). De este modo, el reproductor PL 110 es redirigido de la misma manera que si no hubiera ningún demultidifusor presente en la pasarela G<w>140 o cualquier otro dispositivo en la LAN 101, como se representa en la figura 2B.
Cuando el controlador CTRL 130 no es capaz de determinar si el contenido AV en vivo en cuestión está disponible o no en forma de multidifusión, el controlador CTRL 130 permite que el demultidifusor DM 150 realice dicha comprobación al final. En este caso, el controlador CTRL 130 indica preferentemente como parámetro en línea en el mensaje de redirección REDIR1 la dirección (o URL) del servidor de distribución de contenido AV en vivo de unidifusión en cuestión.
Cada parámetro en línea del mensaje de redirección REDIR1 es proporcionado a continuación por el reproductor PL 110 al demultidifusor DM 150 durante la redirección, permitiendo así que el demultidifusor D<m>150 identifique la dirección del servidor de distribución de contenido en vivo AV de unidifusión cuando sea necesario. Este aspecto se aborda en las figuras 9A y 9B en un contexto de una realización de infraestructura particular mostrada en la figura 8, pero el mismo principio también se aplica en un contexto de una realización de infraestructura particular mostrada en la figura 4 (es decir, en la medida en que la red de proveedor PN 102 permita comunicaciones de enlace ascendente).
En una realización particular, el mensaje de redirección REDIR1 que redirige al reproductor PL 110 hacia el demultidifusor DM 150 incluye además otros parámetros en línea, tales como por ejemplo una dirección de un servidor de unidifusión de reparación, si lo hay, y/o direcciones de multidifusión de las diversas representaciones del contenido AV en vivo en cuestión si los conoces el controlador CTRL 130. Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR1 es, por ejemplo, el siguiente:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd? FQDN_orig=tv.myISP.com&CDN_unicastServer=<dirección del servidor> &repair=172.16.254.1:80
en donde 172.16.254.1:80 es la combinación de dirección IP y número de puerto asignado al servidor de unidifusión de reparación en cuestión.
Volviendo ahora a la etapa 212 en la figura 2B, el controlador CTRL 130 comprueba si el contenido AV en vivo en cuestión está disponible o no en forma de unidifusión. El controlador CTRL 130 accede, por ejemplo, a un archivo que proporciona una lista de contenidos AV en vivo disponibles en forma de unidifusión. Cuando el controlador CTRL 130 determina que el contenido AV en vivo en cuestión está disponible en forma de unidifusión, el controlador CTRL 130 redirige al reproductor PL 110 hacia el servidor de distribución de contenido AV en vivo de unidifusión en la red de proveedor PN 102 (por ejemplo, del equipo de distribución de contenido CDE 120), si la infraestructura del sistema de distribución de contenido AV en vivo permite comunicaciones de enlace ascendente desde la LAN 101 al equipo de distribución de contenido CDE 120 y si dicho servidor de distribución de contenido AV en vivo de unidifusión existe en la red de proveedor PN 102 (por ejemplo, en el equipo de distribución de contenido CDE 120). Para hacerlo, el controlador CTRL 130 incluye preferentemente en un mensaje de redirección REDIR1 transmitido en respuesta a la solicitud REQ1 una dirección del servidor de distribución de contenido en vivo AV de unidifusión en cuestión. Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR1 es, por ejemplo, el siguiente:
HTTP REDIRECT 172.16.248.3:80/SportsChannel1.mpd
en donde 172.16.248.3:80 es la combinación de dirección IP y número de puerto del servidor de distribución de contenido en vivo AV de unidifusión en cuestión.
De lo contrario, el controlador CTRL 130 rechaza la solicitud REQ1, por ejemplo, devolviendo un mensaje HTTP ERROR 404.
En una etapa 203 en la figura 2A y en una etapa 213 en la figura 2B, el reproductor PL 110 transmite otra solicitud REQ2 de acuerdo con las instrucciones contenidas en el mensaje de redirección REDIR1. La solicitud REQ2 solicita así la distribución del contenido AV en vivo en cuestión desde otro servidor distinto al solicitado inicialmente por el controlador CTRL 130. En la etapa 203 en la figura 2A, el reproductor PL 110 transmite la solicitud REQ2 al demultidifusor DM 150.
En la etapa 213 en la figura 2B, el reproductor PL 110 transmite la solicitud REQ2 al servidor de distribución de contenido en vivo AV de unidifusión.
En consecuencia, el reproductor PL 110 recibe el contenido AV en vivo en cuestión. O bien se recibe el contenido AV en vivo, en la etapa 205 de la figura 2A, en forma de unidifusión desde el demultidifusor DM 150 que actúa como un relé de transmisiones recibidas desde el equipo de distribución de contenido CDE 120 en una etapa 204; o bien el contenido AV en vivo se recibe en forma de unidifusión desde el servidor de distribución de contenido AV en vivo de unidifusión (por ejemplo, el equipo de distribución de contenido CDE 120), concretamente sin pasar por el demultidifusor DM 150, en una etapa 214 en la figura 2B.
En las etapas 204 y 205, cuando la red de proveedor 102 permite comunicaciones de enlace ascendente, los segmentos de contenido AV en vivo solicitados están presentes en el demultidifusor DM 150 tal como se recibieron previamente en forma de multidifusión desde el multidifusor del equipo de distribución de contenido CDE 120 y el demultidifusor DM 150 puede devolver segmentos de contenido Av en vivo solicitados al reproductor PL 110 o, cuando faltan segmentos, el demultidifusor DM 150 puede solicitar el contenido desde el servidor de distribución de contenido en vivo AV de unidifusión.
Gracias al enfoque descrito anteriormente, el controlador CTRL 130 determina dinámicamente si la pasarela GW 140 o cualquier otro dispositivo en la LAN 101 implementa dicho demultidifusor y, si lo hay, si este demultidifusor es capaz de hacerse cargo del reproductor PL 110 para cumplir con una solicitud de distribución de contenido AV en vivo. De hecho, el demultidifusor puede estar presente pero inactivo, lo que significa que redirigir el reproductor PL 110 hacia el demultidifusor sería en este caso inadecuado ya que implicaría al menos una latencia inútil significativa desde la perspectiva de la QoE ("Calidad de Experiencia") del reproductor PL 110.
El enfoque es flexible en términos de ubicación efectiva del controlador CTRL 130, como se detalla a continuación en realizaciones de infraestructura particulares en las figuras 4, 6, 8 y 10, y dicha ubicación efectiva no tiene consecuencias sobre la implementación del reproductor PL 110 (es decir, el cliente). Además, el enfoque es lo suficientemente flexible para soportar redes de proveedor sin capacidad de comunicación de enlace ascendente desde la pasarela GW 140 y la<l>A<n>101 a través de dichas redes de proveedor (por ejemplo, red de radiodifusión), así como redes de proveedor con dicha capacidad de comunicación de enlace ascendente. Puede observarse además que el enfoque es adecuado para la emisión en continuo adaptable, permitiendo así a los usuarios beneficiarse de la disponibilidad de diferentes versiones (o representaciones) alternativas del contenido AV en vivo codificado a diversas tasas de bits (o resoluciones) respectivas.
La figura 3 representa esquemáticamente una arquitectura de hardware de ejemplo de dispositivos del sistema de distribución de contenido AV en vivo. El demultidifusor DM 150 y/o el controlador CTRL 130 y/o la pasarela GW 140 y/o el reproductor PL 110 y/o cualquier servidor del equipo de distribución de contenido CDE 120 pueden construirse alrededor de dicha arquitectura de hardware de ejemplo. Se considerará de manera ilustrativa que la figura 3 representa la arquitectura de hardware del controlador CTRL 130.
De acuerdo con la arquitectura de hardware de ejemplo mostrada, el controlador CTRL 130 comprende los siguientes componentes interconectados por un bus de comunicaciones 310: un procesador, microprocesador, microcontrolador o CPU ("unidad central de procesamiento") 301; una RAM ("memoria de acceso aleatorio") 302; una ROM ("memoria de solo lectura") 303 o<e>E<p>ROM ("ROM borrable eléctricamente") o memoria Flash; una unidad de disco duro o cualquier otro dispositivo adaptado para leer información almacenada en un medio de almacenamiento no transitorio, tal como un lector de tarjetas SD ("digitales seguras") 304; al menos una interfaz de comunicación COM 305 que permite comunicarse a través de la LAN 101 y/o la red de proveedor PN 102.
La CPU 301 es capaz de ejecutar instrucciones cargadas en la RAM 302 desde la ROM 303 o desde una memoria externa, tal como una tarjeta SD. Después de que se haya encendido el controlador CTRL 130, la CPU 301 es capaz de leer instrucciones de la RAM 302 y ejecutar estas instrucciones. Las instrucciones forman un programa informático que hace que la CPU 301 realice las etapas descritas en el presente documento con respecto al controlador CTRL 130.
Cabe señalar que las etapas descritas en el presente documento pueden implementarse en forma de software mediante la ejecución de un conjunto de instrucciones o programas mediante una máquina informática programare, tal como un PC ("ordenador personal"), un DSP ("Procesador de señales digitales") o un microcontrolador; o bien implementado en forma de hardware mediante una máquina o un componente dedicado, tal como una FPGA ("matriz de puertas programables in situ") o un ASIC ("circuito integrado específico de aplicación"). De manera más general, cualquier dispositivo del sistema de distribución de contenido AV en vivo comprende circuitos electrónicos de procesamiento adaptados y configurados para implementar las etapas relevantes como se describe en el presente documento con respecto al dispositivo en cuestión.
Lafigura 4representa esquemáticamente una primera realización del sistema de distribución de contenido AV en vivo, en el que el controlador CTRL 130 está ubicado en la red de proveedor PN 102 o conectado a la misma, concretamente más allá de la pasarela GW 140 desde el punto de vista del reproductor PL 110. En la figura 4 aparece además un servidor DNS 161 en la red de proveedor PN 102 para resolver nombres de dominio. Además, el equipo de distribución de contenido CDE 120 en la figura 4 muestra el multidifusor o servidor de multidifusión MS 121, así como el servidor de unidifusión de reparación RUS 122 mencionado anteriormente. El servidor de unidifusión de reparación RUS 122 puede estar coubicado con el servidor de multidifusión MS 121, es decir, ubicado físicamente en la misma máquina. El servidor de unidifusión de reparación RUS 122 implementa un mecanismo para recuperar segmentos de contenido AV en vivo faltantes, típicamente a través de un protocolo de comunicación estandarizado seleccionado dependiendo del protocolo de transporte usado para las operaciones de multidifusión (por ejemplo, RTP o FLUTE/ALC). El equipo de distribución de contenido CDE 120 puede comprender otros servidores, como ya se ha mencionado.
De acuerdo con una característica particular, el servidor de unidifusión de reparación RUS 122 obtiene los segmentos del contenido AV en vivo uniendo los diversos flujos de multidifusión suministrados por el servidor de multidifusión MS 121 para las diversas representaciones respectivas del contenido AV en vivo en cuestión. El servidor de unidifusión de reparación RUS 122 memoriza durante una vida útil predefinida paquetes de dichos flujos de multidifusión y atiende solicitudes de reparación desde el demultidifusor<d>M 150 para compensar pérdidas potenciales de segmento. Por ejemplo, el servidor de unidifusión de reparación RUS 122 proporciona servicio de reparación dependiendo del reintento RTP (como se define en el documento normativo RFC 4588) sobre la base de un contador de continuidad en los paquetes RTP transmitidos por el servidor de multidifusión MS 121 que permite una fácil detección de pérdida de datos.
En la figura 4, el demultidifusor DM 150 está integrado en la pasarela GW 140. Como ya se mencionó, el demultidifusor DM 150 puede, en una variante, indistintamente integrarse en otro dispositivo en la LAN 101.
Lasfiguras 5Ay5Brepresentan esquemáticamente intercambios que se producen en la primera realización del sistema de distribución de contenido AV en vivo mostrado en la figura 4.
En una etapa 500 en la figura 5A y en una etapa 510 en la figura 5B, el reproductor PL 110 realiza el procedimiento de descubrimiento en la LAN 101 (y/o a través de API), como ya se describió con respecto a la etapa 200 en la figura 2A y la etapa 210 en la figura 2B.
Para obtener la dirección para contactar con el controlador CTRL 130, el reproductor PL 110 solicita la resolución del nombre de dominio al servidor DNS 161. La dirección para contactar con el servidor DNS 161 ha sido configurada por la pasarela GW 140 en el reproductor PL 110 cuando el reproductor PL 110 se ha registrado con éxito en la LAN 101 gestionada por la pasarela GW 140. Como alternativa, la dirección para contactar con el servidor DNS 161 puede haber sido configurada manualmente por un usuario al instalar el reproductor PL 110. Por tanto, en una etapa 501 en la figura 5A y en una etapa 511 en la figura 5B, el reproductor PL 110 transmite una solicitud REQ0 al servidor DNS 161. La solicitud REQ0 solicita la resolución del FQD<n>del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110, concretamente tv.myISP.com en el ejemplo anterior. El servidor DNS 161 realiza la resolución del nombre de dominio y así recupera la dirección del controlador CTRL 130 en la red de proveedor PN 102. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP: 72.68.18.14.
En una etapa 502 en la figura 5A y en una etapa 512 en la figura 5B, el servidor DNS 161 devuelve al reproductor PL 110 la dirección recuperada del controlador CTRL 130 en un mensaje de respuesta RESP0. De este modo, el reproductor PL 110 puede contactar con el controlador CTRL 130.
En la figura 5A, las etapas 503 a 507 realizadas después son respectivamente idénticas a las etapas 201 a 205 en la figura 2A ya detallada. Y en la figura. 5B, las etapas 513 a 516 realizadas después son respectivamente idénticas a las etapas 211 a 214 en la figura 2B ya detallada.
Al considerar la etapa 506 en la figura 5A en la que el demultidifusor DM 150 obtiene los segmentos del contenido AV en vivo a partir del equipo de distribución de contenido CDE 120, el demultidifusor DM 150 explota el flujo de multidifusión que es suministrado por el servidor de multidifusión MS 121 y que corresponde a la representación de contenido AV en vivo solicitada por el reproductor PL 110. Cuando el demultidifusor DM 150 se enfrenta a una pérdida de segmento, el demultidifusor DM 150 solicita en forma de unidifusión el segmento perdido en cuestión desde el servidor de unidifusión de reparación RUS 122, para alimentar continuamente al reproductor PL 110 con los segmentos de contenido AV en vivo mejorando así la QoE a pesar de las posibles pérdidas de segmentos en los flujos de multidifusión recibidos. Beneficiarse de dicha reparación es posible en la primera realización del sistema de distribución de contenido AV en vivo mostrado en la figura 4 ya que la red de proveedor PN 102 permite estructuralmente comunicaciones de enlace ascendente desde la pasarela GW 140 y la LAN 101 al equipo de distribución de contenido CDE 120. Depender del servidor de reparación RUS 122 es particularmente útil cuando hay pérdidas de paquetes de multidifusión, que normalmente se transmiten usando un protocolo de transporte (tal como UDP) que no tiene mecanismo de retransmisión. Cuando las pérdidas de segmentos se deben a segmentos faltantes entre paquetes de multidifusión sucesivos recibidos correctamente, entonces el demultidifusor DM 150 puede solicitar los segmentos faltantes desde un servidor de distribución de contenido en vivo AV de unidifusión.
Lafigura6 representa esquemáticamente una segunda realización del sistema de distribución de contenido AV en vivo, en donde el controlador CTRL 130 también está ubicado en la pasarela GW 140 o en otro dispositivo en la LAN 101. En la figura 6, el demultidifusor DM 150 está integrado en la pasarela GW 140. Como ya se mencionó, el demultidifusor DM 150 puede, en una variante, indistintamente integrarse en otro dispositivo en la LAN 101. Además, en la figura 6, el controlador CTRL 130 está coubicado con el demultidifusor DM 150, concretamente en la pasarela GW 140. El controlador CTRL 130 puede, en una variante, indistintamente integrarse en otro dispositivo en la LAN 101.
Además, aparece en la figura 6 un servidor DNS local (LDNS) 162 para resolver nombres de dominio. El servidor LDNS 162 está ubicado en la pasarela GW 140 en la figura 6, pero puede estar ubicado en otro dispositivo en la LAN 101. La red de proveedor P<n>102 es un tipo de red de radiodifusión y, por tanto, no se pueden realizar comunicaciones de enlace ascendente desde la LAN 101 ni desde la pasarela Gw 140 hacia el equipo de distribución de contenido CDE. Por lo tanto, los servidores en el equipo de distribución de contenido CDE accesibles mediante la pasarela GW 140 y cualquier otro dispositivo en la LAN 101 sólo pueden ser servidores de multidifusión tales como el servidor de multidifusión MS 121 y sólo para comunicaciones de enlace descendente. Cabe señalar que en dicho contexto, los servidores de red de proveedor de radiodifusión se consideran en el presente documento servidores de multidifusión, ya que cada demultidifusor selecciona qué flujo de contenido AV en vivo (por ejemplo, canal de televisión) recibir y procesar de manera efectiva, lo que por lo tanto se refiere a transmisiones de multidifusión (ya que las transmisiones de radiodifusión darían lugar a que todos los demultidifusores recibieran los mismos datos).
Lafigura 7representa esquemáticamente intercambios que se producen en la segunda realización del sistema de distribución de contenido AV en vivo mostrado en la figura 6.
En una etapa 701, el reproductor PL 110 realiza el procedimiento de descubrimiento en la LAN 101 (y/o a través de API), como ya se describió con respecto a la etapa 200 en la figura 2A.
Para obtener la dirección para contactar con el controlador CTRL 130, el reproductor PL 110 solicita la resolución del nombre de dominio al servidor LDNS 162. La dirección para contactar con el servidor LDNS 162 ha sido configurada por la pasarela GW 140 en el reproductor PL 110 cuando el reproductor PL 110 se ha registrado con éxito en la LAN 101 gestionada por la pasarela GW 140. Como alternativa, la dirección para contactar con el servidor LDNS 162 puede haber sido configurada manualmente por un usuario al instalar el reproductor PL 110, especialmente cuando el servidor LDNS 162 está ubicado en otro dispositivo en la LAN 101. Por tanto, en una etapa 702, el reproductor PL 110 transmite la solicitud REQ0 al servidor LDNS 162. La solicitud REQ0 solicita la resolución del FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110, concretamente tv.myISP.com en el ejemplo anterior. El servidor LDNS 162 realiza la resolución del nombre de dominio y así recupera la dirección del controlador CTRL 130. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP y número de puerto: 192.168.1.100:8001.
La configuración del servidor LDNS 162 para que el servidor LDNS 162 sea capaz de realizar la resolución de nombres de dominio y recuperar la dirección del controlador CTRL 130 es realizada preferentemente por el demultidifusor DM 150 cuando el demultidifusor DM 150 se ha instalado con éxito en la pasarela GW 140, transmitiendo al servidor LDNS 162, en una etapa 700, un mensaje de configuración CONF1 que proporciona una asociación entre el FQDN del URL del contenido AV en vivo en cuestión y la dirección para contactar con el controlador CTRL 130. Por tanto, dicho mensaje es interno a la pasarela GW 140 cuando el demultidifusor DM 150 está alojado en la pasarela GW 140. Como alternativa, el servidor LDNS 162 puede configurarse por cualquier otro medio, incluido manualmente por un usuario al instalar el demultidifusor DM 150 y el controlador CTRL 130.
En una realización particular donde el demultidifusor DM 150 y el controlador CTRL 130 están coubicados en la misma máquina (por ejemplo, la pasarela GW 140), la resolución del nombre de dominio realizada por el servidor LDNS 162 puede conducir a una dirección IP diferente de la usada para contactar con el demultidifusor DM 150, lo que se conoce comosolapamiento de IP.Esto es particularmente útil para facilitar la resolución de conflictos en la asignación de números de puerto con otros componentes de la pasarela GW 140.
En una etapa 703, el servidor LDNS 162 devuelve al reproductor PL 110 la dirección recuperada del controlador CTRL 130 en el mensaje de respuesta RESP0. De este modo, el reproductor PL 110 puede contactar con el controlador CTRL 130.
De acuerdo con una característica variante particular en la que el demultidifusor DM 150 y el controlador CTRL 130 están coubicados en la misma máquina (por ejemplo, la pasarela GW 140), el reproductor PL 110 determina la dirección para contactar con el controlador CTRL 130 sin depender de la resolución de nombres de dominio. Esta situación podría ocurrir cuando no hay un servidor DNS local en la LAN 101, o cuando el controlador CTRL 130 no tiene permiso para configurar dicho servidor DNS local. El reproductor PL 110 es, de acuerdo con esta característica variante particular, consciente por configuración de que el controlador CTRL 130 está coubicado con el demultidifusor DM 150 en la misma máquina (por ejemplo, en la pasarela GW 140). Por tanto, después de haber obtenido la dirección del demultidifusor DM 150 en el procedimiento de descubrimiento, el controlador CTRL 130 deriva la dirección del controlador CTRL 130 a partir de la dirección del demultidifusor DM 150 aplicando una regla de sustitución predefinida en un número de puerto asignado al demultidifusor DM 150. Por ejemplo, el controlador CTRL 130 incrementa en una unidad el número de puerto de la dirección del demultidifusor DM 150 para obtener el número de puerto de la dirección del controlador CTRL 130.
En la figura 7, las etapas 704 a 708 realizadas después son respectivamente idénticas a las etapas 201 a 205 en la figura 2A ya detallada. Cabe señalar aquí que, contrariamente a la figura 5A, el demultidifusor DM 150 no puede beneficiarse aquí de ningún servidor de unidifusión en la etapa 707 ya que no es posible realizar comunicaciones de enlace ascendente en el contexto de la segunda realización del sistema de distribución de contenido AV en vivo en la figura 6.
Lafigura8 representa esquemáticamente una tercera realización del sistema de distribución de contenido AV en vivo, que es una combinación híbrida de la primera y segunda realizaciones descritas anteriormente con respecto a las figuras 4 y 6. En la figura 8, el controlador CTRL 130 también está ubicado en la pasarela GW 140 o en otro dispositivo en la LAN 101. En la figura 8, el demultidifusor DM 150 está integrado en la pasarela GW 140. Como ya se mencionó, el demultidifusor DM 150 puede, en una variante, indistintamente integrarse en otro dispositivo en la LAN 101. Además, en la figura 8, el controlador CTRL 130 está coubicado con el demultidifusor DM 150, concretamente en la pasarela GW 140. El controlador CTRL 130 puede, en una variante, indistintamente integrarse en otro dispositivo en la LAN 101. Sin embargo, en la figura 8, la red de proveedor PN 102 permite comunicaciones de enlace ascendente como en la primera realización de la figura 4. Por tanto, el equipo de distribución de contenido CDE 120 en la figura 6 muestra el multidifusión o servidor de multidifusión MS 121, así como el servidor de unidifusión de reparación RUS 122.
El equipo de distribución de contenido CDE 120 en la figura 6 comprende además un servidor CDNS 123 de red de distribución de contenido. El servidor CDNS 123 no conoce la capacidad de multidifusión del equipo de distribución de contenido CDE 120 y es, por ejemplo, un servidor de terceros a través del cual se puede solicitar contenido AV en vivo en forma de unidifusión. El servidor CDNS 123 puede estar en un dominio de autoridad diferente que el equipo de distribución de contenido CDE 120 y, por tanto, puede estar separado del equipo de distribución de contenido CDE 120. Cabe señalar que, cuando se le contacta para la distribución de contenido AV en vivo, el servidor CDNS 123 puede realizar una redirección hacia otro servidor en la red de proveedor PN 102 para una distribución efectiva de contenido AV en vivo. Además, aparecen en la figura 8 el servidor DNS 161 y el servidor LDNS 162 ya mostrados respectivamente en las figuras 4 y 6. El servidor LDNS 162 está ubicado en la pasarela GW 140 en la figura 8, pero puede estar ubicado en otro dispositivo en la LAN 101.
Lasfiguras 9Ay9Brepresentan esquemáticamente intercambios que se producen en la tercera realización del sistema de distribución de contenido AV en vivo mostrado en la figura 8.
El servidor LDNS 162 está configurado como ya se describió con respecto a la figura 7. Por tanto, el demultidifusor DM 150 puede configurar preferentemente el servidor LDNS 162, en una etapa 900 por medio del mensaje de configuración CONF1, para permitir que el reproductor PL 110 obtenga la dirección para contactar con el controlador CTRL 130 mediante resolución del nombre de dominio. Como se describe con respecto a la figura 7, una variante consiste para el reproductor PL 110 en derivar la dirección (número de puerto) del controlador CTRL 130 a partir de la dirección (número de puerto) del demultidifusor DM 150 obtenida durante el procedimiento de descubrimiento cuando el controlador CTRL 130 y el demultidifusor DM 150 están coubicados en la misma máquina.
En una etapa 901 en la figura 9A y en una etapa 911 en la figura 9B, el reproductor PL 110 realiza el procedimiento de descubrimiento en la LAN 101 (y/o a través de API), como ya se describió con respecto a la etapa 200 en la figura 2A y la etapa 210 en la figura 2B.
En una etapa 902 en la figura 9A y en una etapa 912 en la figura 9B, el reproductor PL 110 transmite la solicitud REQ0 al servidor LDNS 162. La solicitud REQ0 solicita la resolución del FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110, concretamente tv.myISP.com en el ejemplo anterior. El servidor LDNS 162 realiza la resolución del nombre de dominio y así recupera la dirección del controlador CTRL 130. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP y número de puerto: 192.168.1.100:8001.
En una etapa 903 en la figura 9A y en una etapa 913 en la figura 9B, el servidor LDNS 162 devuelve al reproductor PL 110 la dirección recuperada del controlador CTRL 130 en el mensaje de respuesta RESP0. De este modo, el reproductor PL 110 puede contactar con el controlador CTRL 130.
En la figura 9A, las etapas 904 a 906 realizadas después son respectivamente idénticas a las etapas 201 a 203 en la figura 2A ya detallada.
En la figura 9A, las etapas 909a y 909b realizadas después son respectivamente idénticas a las etapas 204 y 205 en la figura 2A ya detallada. Cabe señalar aquí que, al contrario de la figura 7, el demultidifusor DM 150 puede beneficiarse aquí del servidor de unidifusión de reparación RUS 122 y/o del servidor CDNS 123 en la etapa 909b, ya que es posible realizar comunicaciones de enlace ascendente en el contexto de la tercera realización del sistema de distribución de contenido AV en vivo en la figura 8. Para que el demultidifusor DM 150 pueda beneficiarse del servidor CDNS 123, el controlador CTRL 130 incluye en el mensaje de redirección REDIR1 un parámetro en línea que proporciona el FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110. como se indica en la solicitud REQ 1, es decir, tv.myISP.com en el ejemplo anterior. Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR1 es, por ejemplo, el siguiente:
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?FQDN_orig =tv.myISP.com&CDN_unicastServer=tv.myISP.com
Esto es particularmente útil cuando el servidor CDNS 123 es gestionado por un tercero en comparación con el controlador CTRL 130 y el demultidifusor DM 150. El demultidifusor DM 150, que recibe la solicitud r Eq 2 en la etapa 906, puede usar los servicios de un agente de cliente DNS instalado en la misma máquina que el demultidifusor DM 150 y en conjunto con dicho demultidifusor DM 150 para forzar la resolución del nombre de dominio por parte del servidor DNS 161 y evitar que el servidor LDNS 162, si lo hubiera, sea el objetivo de la resolución de nombres de dominio.
A partir del parámetro en línea que proporciona dicho FQDN como se indica en la solicitud REQ 1, el demultidifusor DM 150 solicita la resolución del nombre de dominio y se transmite un mensaje REQ3 en consecuencia en una etapa 907. El servidor DNS 161 procesa la solicitud REQ3, realiza la resolución del nombre de dominio y así recupera la dirección del servidor CDNS 123. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP: 72.36.53.18. A continuación, en una etapa 908, el servidor DNS 161 devuelve al demultidifusor DM 150 la dirección recuperada del servidor CDNS 123 en un mensaje de respuesta RESP3. Por tanto, el demultidifusor DM 150 puede operar esa dirección para contactar con el servidor CDNS 123 cuando sea necesario (por ejemplo, para obtener segmentos de contenido AV en vivo que faltan).
En la figura 9B, una etapa 914 realizada después es idéntica a la etapa 211 en la figura 2B ya detallada. Se considera aquí que el controlador CTRL 130 no tiene información que indique si el contenido AV en vivo solicitado por el reproductor PL 110 está disponible en forma de multidifusión. Incluso aunque cuando están coubicados en la misma máquina (por ejemplo, en la pasarela GW 140), el controlador CTRL 130 y el demultidifusor DM 150 no son conscientes de la presencia del otro. Sería posible hacerlos interactuar, pero mantener la hermeticidad entre ellos simplifica el desarrollo del controlador CTRL 130 ya que dicho controlador CTRL 130 no actúa de manera diferente cuando está ubicado en la pasarela GW 140 o en la red de proveedor PN 102. El controlador CTRL 130 permite entonces que el demultidifusor DM 150 compruebe si el contenido AV en vivo solicitado por el reproductor PL 110 está disponible en forma de multidifusión. Si el contenido AV en vivo solicitado por el reproductor PL 110 está disponible en forma de multidifusión, el intercambio continúa como se representa en la figura 9A. De lo contrario, el demultidifusor DM 150 necesita redirigir el reproductor PL 110 hacia el servidor CDNS 123.
Para redirigir el reproductor PL 110 hacia el servidor CDNS 123, el demultidifusor DM 150 necesita solicitar la resolución del FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110. De hecho, la resolución del nombre de dominio anterior dirigió al reproductor PL 110 hacia el controlador CTRL 130, lo que sería inconveniente en la situación actual ya que conduciría a un bucle infinito. Por tanto, en una etapa 917, el demultidifusor DM 150 transmite una solicitud REQ3 al servidor DNS 161. La solicitud REQ3 solicita la resolución del FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110, concretamente tv.myISP.com en el ejemplo anterior, que debería haber sido proporcionado por el controlador CTRL 130 como parámetro en línea del mensaje de redirección REDIR1 en la etapa 915. El demultidifusor DM 150 puede utilizar servicios de un agente de cliente DNS instalado en la misma máquina que el demultidifusor DM 150 y en conjunto con dicho demultidifusor DM 150 para forzar la resolución por parte del servidor DNS 161 y evitar que el servidor LDNS 162, si lo hay, sea el objetivo de la resolución del nombre de dominio.
El servidor DNS 161 realiza la resolución del nombre de dominio y así recupera la dirección del servidor CDNS 123. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP: 72.36.53.18. A continuación, en una etapa 918, el servidor DNS 161 devuelve al demultidifusor DM 150 la dirección recuperada del servidor CDNS 123 en un mensaje de respuesta RESP3. El demultidifusor DM 150 es así capaz de proporcionar la dirección del servidor CDNS 123 al reproductor PL 110.
En una etapa 919, el demultidifusor DM 150 transmite un mensaje de redirección REDIR2 al reproductor PL 110 en respuesta a la solicitud REQ2. El mensaje de redirección REDIR2 incluye la dirección del servidor CDNS 123 en lugar del FQDN correspondiente. Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR2 es, por ejemplo, el siguiente:
HTTP REDIRECT 72.36.53.18:80/SportsChannel1.mpd
en donde la dirección IP del servidor CDNS 123 va seguida aquí de un número de puerto predeterminado ("80").
En una etapa 920, el reproductor PL 110 transmite otra solicitud REQ4 de acuerdo con las instrucciones contenidas en el mensaje de redirección REDIR2. La solicitud REQ4 solicita así la distribución del contenido AV en vivo en cuestión desde el servidor CDNS 123. En una etapa 921, el reproductor PL 110 recibe el contenido AV en vivo en forma de unidifusión desde el servidor CDNS 123 (es decir, sin pasar por el demultidifusor DM 150).
Lafigura 10representa esquemáticamente una cuarta realización del sistema de distribución de contenido AV en vivo, que se deriva de la tercera realización descrita anteriormente con respecto a la figura 8. En la figura 10, el demultidifusor DM 150 está integrado en la pasarela GW 140. Como ya se mencionó, el demultidifusor DM 150 puede, en una variante, indistintamente integrarse en otro dispositivo en la LAN 101. En la figura 10, el controlador CTRL 130 está ubicado en la red de proveedor PN 102 o conectado a la misma, concretamente más allá de la pasarela GW 140 desde el punto de vista del reproductor PL 110. En la figura 10, el servidor LDNS 162 está presente en la pasarela GW 140, pero puede estar ubicado en otro dispositivo en la LAN 101.
Un problema que plantea dicha configuración radica en la resolución del nombre de dominio, en particular cuando el contenido AV en vivo no está disponible en forma de multidifusión. Cuando el contenido AV en vivo fijado como objetivo por el reproductor PL 110 está disponible en forma de multidifusión, los intercambios se ejecutan como ya se describió con respecto a la figura 9A, excepto que el controlador CTRL 130 está ubicado más allá de la pasarela GW 140 desde el punto de vista del reproductor PL 110. Por tanto, por consideraciones de simplicidad, la figura 11 que se detalla más adelante sólo se centra en una situación en la que el contenido AV en vivo fijado como objetivo por el reproductor PL 110 no está disponible en forma de multidifusión y tiene que proporcionarse en forma de unidifusión desde el servidor CDNS 123, que de todos modos no es consciente de ninguna capacidad de multidifusión a través de la red de proveedor PN 102.
Lafigura 11representa esquemáticamente intercambios que se producen en la cuarta realización del sistema de distribución de contenido AV en vivo mostrado en la figura 10.
El servidor LDNS 162 se configura a través de un mensaje de configuración CONF1 transmitido por el demultidifusor DM 150. La configuración del servidor LDNS 162 para que el servidor LDNS 162 pueda realizar la resolución de nombres de dominio y recuperar la dirección del controlador CTRL 130 la realiza el demultidifusor DM 150 cuando el demultidifusor DM 150 se ha instalado con éxito en la pasarela GW 140, en una etapa 1110, transmitiendo al servidor LDNS 162 un mensaje de configuración CONF1 que proporciona una asociación entre el FQDN del URL del contenido AV en vivo objetivo del reproductor PL 110 y la dirección para contactar con el controlador CTRL 130. Como se mencionó con respecto a la figura 7, esto puede, en una variante, realizarse manualmente.
En una etapa 1111, el reproductor PL 110 realiza el procedimiento de descubrimiento en la LAN 101 (y/o a través de API), como ya se describió con respecto a la etapa 200 en la figura 2A.
En una etapa 1112, el reproductor PL 110 transmite la solicitud REQ0 al servidor LDNS 162. La solicitud REQ0 solicita la resolución del FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110, concretamente tv.myISP.com en el ejemplo anterior. El servidor LDNS 162 realiza la resolución del nombre de dominio y así recupera la dirección del controlador CTRL 130. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP: 72.68.18.14.
En una etapa 1113, el servidor LDNS 162 devuelve al reproductor PL 110 la dirección recuperada del controlador CTRL 130 en el mensaje de respuesta RESP0. De este modo, el reproductor PL 110 puede contactar con el controlador CTRL 130.
En una etapa 1114, el reproductor PL 110 transmite la solicitud REQ1 al controlador CTRL 130 usando la dirección obtenida del servidor LDNS 162. La solicitud REQ1 se forma como ya se describió.
En una etapa 1115, el controlador CTRL 130 no sabe si el contenido AV en vivo fijado como objetivo por el reproductor PL 110 está disponible o no en forma de multidifusión, y transmite en respuesta a la solicitud REQ1 el mensaje de redirección REDIR1. Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR1 es, por ejemplo, similar al siguiente
HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?FQDN_orig =tv.myISP.com&CDN_unicastServer=tv.myISP.com
Al recibir el mensaje de redirección REDIR1, el reproductor PL 110 redirige su solicitud al demultidifusor DM 150 a través de la solicitud REQ2 en una etapa 1116 de acuerdo con el mensaje de redirección REDIR1. Teniendo en cuenta que el demultidifusor DM 150 observa que el contenido AV en vivo fijado como objetivo por el reproductor PL 110 no está disponible en forma de multidifusión, el demultidifusor DM 150 transmite en respuesta a la solicitud REQ2, en una etapa 1119, el mensaje de redirección REDIR2.
En el mensaje de redirección REDIR2, el demultidifusor DM 150 ha reemplazado la dirección (por ejemplo, dirección IP y número de puerto) como se indica en la solicitud REQ2 por la dirección del servidor de unidifusión proporcionada como parámetro en línea (es decir, parámetro en línea "CDN_unicastServer" en el ejemplo anterior) de la solicitud REQ2.
Cabe señalar que hacer referencia al servidor de unidifusión con el FQDN del URL que identifica el contenido AV en vivo fijado como objetivo por el reproductor PL 110, concretamente tv.myISP.com, es particularmente útil cuando el servidor CDNS 123 está gestionado por una autoridad diferente que el controlador CTRL 130 y el demultidifusor DM 150. El demultidifusor DM 150, que recibe la solicitud REQ2 en la etapa 1116, puede usar los servicios de un agente de cliente DNS instalado en la misma máquina que el demultidifusor DM 150 y en conjunto con dicho demultidifusor DM 150 para forzar la resolución de nombres de dominio por parte del servidor DNS 161 y evitar que el servidor LDNS 162, si lo hubiera, sea el objetivo de la resolución de nombres de dominio.
El demultidifusor DM 150 solicita la resolución del nombre de dominio y el mensaje REQ3 se transmite en consecuencia en una etapa 1117. El servidor DNS 161 procesa la solicitud REQ3, realiza la resolución del nombre de dominio y así recupera la dirección del servidor CDNS 123. Por ejemplo, la resolución del nombre de dominio conduce a la siguiente dirección IP: 72.36.53.18. A continuación, en una etapa 1118, el servidor DNS 161 devuelve al demultidifusor DM 150 la dirección recuperada del servidor CDNS 123 en el mensaje de respuesta RESP3.
A continuación, el demultidifusor DM 150 envía el mensaje de redirección REDIR2. Siguiendo con el ejemplo anterior, el mensaje de redirección REDIR2 es, por ejemplo, el siguiente:
HTTP REDIRECT 72.36.53.18:80/SportsChannel1.mpd
Al recibir el mensaje de redirección REDIR2, en una etapa 1120, el reproductor PL 110 transmite la solicitud REQ4 al servidor CDNS 123, solicitando así la distribución del contenido AV en vivo en cuestión desde el servidor CDNS 123. A continuación, en una etapa 1121, el reproductor PL 110 recibe el contenido AV en vivo en forma de unidifusión desde el servidor CDNS 123 (es decir, sin pasar por el demultidifusor DM 150).
Claims (17)
1. Un procedimiento para distribuir un contenido audiovisual en vivo dirigido a un cliente (110), realizándose el procedimiento mediante un sistema de distribución de contenido audiovisual en vivo que incluye:
- el cliente (110) ubicado en una red de área local (101) interconectada a una red de proveedor (102) mediante una pasarela (140) que proporciona acceso a la red de proveedor (102) o ubicado en la pasarela (140) que proporciona acceso a la red de proveedor (102);
- un equipo de distribución de contenido audiovisual en vivo (120) que comprende uno o más servidores entre los cuales un multidifusor para transmitir contenidos audiovisuales en vivo en forma de multidifusión por medio de la red de proveedor (102);
- un demultidifusor (150) en la pasarela (140) que proporciona acceso a la red de proveedor (102) o en cualquier dispositivo ubicado en la red de área local (101), pudiendo el demultidifusor (150) realizar una conversión en forma de unidifusión de contenidos audiovisuales en vivo recibidos en forma de multidifusión desde el multidifusor;
- un controlador (130) que gestiona el enrutamiento de solicitudes para obtener contenidos audiovisuales en vivo;caracterizado por queel procedimiento comprende:
- el cliente (110) realiza un procedimiento de descubrimiento (200; 210; 500; 510; 701; 901; 911; 1111) con el objetivo de recibir, desde la pasarela (140) que proporciona acceso a la red de proveedor (102) y desde cualquier dispositivo conectado a la red de área local (101), información sobre potencial presencia y disponibilidad del demultidifusor (150);
y cuando el cliente (110) pretende recibir el contenido audiovisual en vivo objetivo:
- el cliente (110) envía al controlador (130) una solicitud (201; 211; 503; 513; 704; 904; 914; 1114) para obtener el contenido audiovisual en vivo objetivo que proporciona una indicación de presencia y disponibilidad, o no, del demultidifusor (150);
- el controlador (130) decide cómo redirigir al cliente (110) para cumplir con la solicitud de obtener el contenido audiovisual en vivo objetivo, de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor (150) .
2. El procedimiento de acuerdo con la reivindicación 1, en donde la indicación de presencia y disponibilidad, o no, del demultidifusor (150) se proporciona implícitamente en dicha solicitud para obtener el contenido audiovisual en vivo objetivo, de modo que, en caso de presencia y disponibilidad del demultidifusor (150), la solicitud para obtener el contenido audiovisual en vivo objetivo incluye un parámetro en línea que proporciona una dirección del demultidifusor (150) resultante del procedimiento de descubrimiento.
3. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 y 2, en donde la red de proveedor (102) permite comunicaciones de enlace ascendente desde la pasarela (140) y la red de área local (101) a través de la red de proveedor (102), y el controlador (130) está ubicado en la red de proveedor (102), y en donde el controlador (130) redirige al cliente (110) hacia un servidor de unidifusión (123) del equipo de distribución de contenido audiovisual en vivo cuando el controlador (130) determina que el cliente (110) no puede beneficiarse de la conversión de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor, y en caso contrario redirige al cliente (110) hacia el demultidifusor (150).
4. El procedimiento de acuerdo con la reivindicación 3, en donde el cliente determina una dirección para contactar con el controlador (130) solicitando la resolución del nombre de dominio a un servidor de nombres de dominio (161) ubicado en la red de proveedor (102), concerniendo la resolución del nombre de dominio a un nombre de dominio totalmente cualificado incluido en un localizador uniforme de recursos que identifica el contenido audiovisual en vivo objetivo.
5. El procedimiento de acuerdo con la reivindicación 3 o 4, en donde el demultidifusor (150) recupera segmentos del contenido audiovisual en vivo objetivo, que se pierden en forma de multidifusión, desde un servidor de unidifusión de reparación (122) del equipo de distribución de contenido audiovisual en vivo (120) que recibe el contenido audiovisual en vivo objetivo desde el multidifusor (121).
6. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 3 a 5, en donde cuando se redirige al cliente (110) hacia el demultidifusor (150), el controlador (130) transmite un mensaje de redirección que incluye un parámetro en línea que proporciona el nombre de dominio totalmente cualificado incluido en un localizador uniforme de recursos que se indicó en la solicitud para obtener el contenido audiovisual en vivo objetivo y que identifica el contenido audiovisual en vivo objetivo, y en donde el demultidifusor (150) redirige al cliente (110) hacia un servidor de unidifusión en la red de proveedor (102) cuando el demultidifusor (150) determina que el cliente (110) no puede beneficiarse de la conversión de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor, determinando el demultidifusor (150) una dirección de dicho servidor de unidifusión solicitando resolución del nombre de dominio a un servidor de nombres de dominio (161) ubicado en la red de proveedor (102) usando el parámetro en línea que proporciona dicho nombre de dominio totalmente cualificado.
7. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 y 2, en donde la red de proveedor (102) permite comunicaciones de enlace ascendente desde la pasarela (140) y la red de área local (101) a través de la red de proveedor (102) y el controlador (130) está ubicado en la pasarela (140) o en la red de área local (101), en donde el controlador (140) redirige al cliente (110) hacia un servidor de unidifusión no consciente de multidifusión en la red de proveedor (102) cuando el controlador (130) determina que el cliente (110) no puede beneficiarse de la conversión de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor, y en caso contrario redirige al cliente hacia el demultidifusor (150).
8. El procedimiento de acuerdo con la reivindicación 7, en donde el cliente (110) determina una dirección para contactar con el controlador (130) solicitando la resolución del nombre de dominio a un servidor de nombres de dominio local (162) ubicado en la pasarela (140) o en la red de área local (101), concerniendo la resolución del nombre de dominio a un nombre de dominio totalmente cualificado incluido en un localizador uniforme de recursos que identifica el contenido audiovisual en vivo objetivo.
9. El procedimiento de acuerdo con la reivindicación 8, en donde el controlador (130) ha configurado previamente el servidor de nombres de dominio local (162) para asociar dicho nombre de dominio totalmente cualificado con una dirección del controlador (130).
10. El procedimiento de acuerdo con la reivindicación 7, en donde, estando coubicados el controlador (130) y el demultidifusor (150) en la misma máquina, el cliente (110) determina una dirección para contactar con el controlador (130) derivando dicha dirección para contactar con el controlador (130) a partir de una dirección para contactar con el demultidifusor (150) resultante del procedimiento de descubrimiento.
11. El procedimiento de acuerdo con las reivindicaciones 8 a 10, en donde el demultidifusor (150) recupera segmentos del contenido audiovisual en vivo objetivo, que se pierden en forma de multidifusión, desde un servidor de unidifusión de reparación (122) del equipo de distribución de contenido audiovisual en vivo (120) que recibe el contenido audiovisual en vivo objetivo desde el multidifusor (121).
12. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 8 a 11, en donde cuando se redirige al cliente (110) hacia el demultidifusor (150), el controlador (130) transmite un mensaje de redirección que incluye un parámetro en línea que proporciona el nombre de dominio totalmente cualificado incluido en un localizador uniforme de recursos que se indicó en la solicitud para obtener el contenido audiovisual en vivo objetivo y que identifica el contenido audiovisual en vivo objetivo, y en donde el demultidifusor (150) redirige al cliente (110) hacia un servidor de unidifusión no consciente de multidifusión en la red de proveedor (102) cuando el demultidifusor (150) determina que el cliente (110) no puede beneficiarse de la conversión, de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor, determinando el demultidifusor (150) una dirección de dicho servidor de unidifusión no consciente de multidifusión solicitando resolución del nombre de dominio a un servidor de nombres de dominio (161) ubicado en la red de proveedor (102) usando el parámetro en línea que proporciona dicho nombre de dominio totalmente cualificado .
13. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 y 2, en donde la red de proveedor (102) no permite comunicaciones de enlace ascendente desde la pasarela (140) y la red de área local (101) a través de la red de proveedor (102) y el controlador (130) está ubicado en la pasarela (140) o en la red de área local (101), en donde el controlador (130) rechaza la solicitud para obtener el contenido audiovisual en vivo objetivo cuando el controlador (130) determina que el cliente (110) no puede beneficiarse de la conversión de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor, y en caso contrario redirige al cliente (110) hacia el demultidifusor (150).
14. El procedimiento de acuerdo con la reivindicación 13, en donde el cliente determina una dirección para contactar con el controlador (130) solicitando la resolución del nombre de dominio a un servidor de nombres de dominio local (162) ubicado en la pasarela (140) o en la red de área local (101), concerniendo la resolución del nombre de dominio a un nombre de dominio totalmente cualificado incluido en un localizador uniforme de recursos que identifica el contenido audiovisual en vivo objetivo.
15. El procedimiento de acuerdo con la reivindicación 14, en donde el demultidifusor (150) ha configurado previamente el servidor de nombres de dominio local (162) para asociar dicho nombre de dominio totalmente cualificado con una dirección del controlador (130).
16. El procedimiento de acuerdo con la reivindicación 13, en donde, estando coubicados el controlador (130) y el demultidifusor (150) en la misma máquina, el cliente (110) determina una dirección para contactar con el controlador (130) derivando dicha dirección para contactar con el controlador (130) a partir de una dirección para contactar con el demultidifusor (150) resultante del procedimiento de descubrimiento.
17. Un sistema de distribución de contenido audiovisual en vivo que incluye:
- un cliente (110) ubicado en una red de área local (101) interconectada a una red de proveedor (102) mediante una pasarela (140) configurada para proporcionar acceso a la red de proveedor (102) o ubicada en la pasarela (140) configurada para proporcionar acceso a la red de proveedores (102);
- un equipo de distribución de contenido audiovisual en vivo (120) que comprende uno o más servidores entre los cuales un multidifusor configurado para transmitir contenidos audiovisuales en vivo en forma de multidifusión a través de la red de proveedor (102);
- un demultidifusor (150) en la pasarela (140) configurado para proporcionar acceso a la red de proveedor (102) o en cualquier dispositivo ubicado en la red de área local (101), el demultidifusor (150) configurado para realizar una conversión en forma de unidifusión de contenidos audiovisuales en vivo recibidos en forma de multidifusión desde el multidifusor;
- un controlador (130) configurado para gestionar el enrutamiento de solicitudes para obtener contenidos audiovisuales en vivo;
caracterizado por que:
- el cliente (110) comprende medios para realizar un procedimiento de descubrimiento (200; 210; 500; 510; 701; 901; 911; 1111) con el objetivo de recibir, desde la pasarela (140) que proporciona acceso a la red de proveedor (102) y desde cualquier dispositivo conectado a la red de área local (101), información sobre la potencial presencia y disponibilidad del demultidifusor (150);
- el cliente (110) comprende medios para enviar (201; 211; 503; 513; 704; 904; 914; 1114) al controlador (130), cuando el cliente (110) pretende recibir el contenido audiovisual en vivo objetivo, una solicitud para obtener el contenido audiovisual en vivo objetivo que proporciona una indicación de presencia y disponibilidad, o no, del demultidifusor (150);
- el controlador (130) configurado para decidir cómo redirigir al cliente (110) para cumplir con la solicitud para obtener el contenido audiovisual en vivo objetivo, de acuerdo con al menos la indicación de presencia y disponibilidad, o no, del demultidifusor (150).
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/IB2018/001488 WO2020109834A1 (en) | 2018-11-28 | 2018-11-28 | Method and system for audio-visual live content delivery |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2965183T3 true ES2965183T3 (es) | 2024-04-11 |
Family
ID=65033620
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18836386T Active ES2965183T3 (es) | 2018-11-28 | 2018-11-28 | Procedimiento y sistema para la distribución de contenido audiovisual en vivo |
Country Status (14)
| Country | Link |
|---|---|
| EP (1) | EP3888316B1 (es) |
| JP (1) | JP7312828B2 (es) |
| KR (1) | KR102506107B1 (es) |
| CN (1) | CN113287283B (es) |
| BR (1) | BR112021010392A2 (es) |
| CA (1) | CA3121298A1 (es) |
| DK (1) | DK3888316T3 (es) |
| ES (1) | ES2965183T3 (es) |
| HR (1) | HRP20231623T1 (es) |
| MX (1) | MX2021006191A (es) |
| PL (1) | PL3888316T3 (es) |
| PT (1) | PT3888316T (es) |
| SG (1) | SG11202105599PA (es) |
| WO (1) | WO2020109834A1 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11445000B2 (en) * | 2018-11-30 | 2022-09-13 | British Telecommunications Public Limited Company | Multicast to unicast conversion |
| CN110730053A (zh) * | 2019-09-09 | 2020-01-24 | 晶晨半导体（深圳）有限公司 | 一种基于ts格式和udp传输方式的网络丢包重传方法 |
| CN113840151A (zh) * | 2020-06-24 | 2021-12-24 | 中国电信股份有限公司 | Ott组播网关调度方法、装置和系统、存储介质 |
| EP4002857A1 (en) * | 2020-11-13 | 2022-05-25 | Broadpeak | Method and system for customized audio and/or video content delivery |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020143951A1 (en) * | 2001-03-30 | 2002-10-03 | Eyeball.Com Network Inc. | Method and system for multicast to unicast bridging |
| BRPI0621810A2 (pt) * | 2006-06-27 | 2011-12-20 | Thomson Licensing | Método e aparelho para distribuir dados em difusão seletiva de forma confiável |
| FR2981530B1 (fr) | 2011-10-12 | 2013-12-06 | Broadpeak | Passerelle, et procede, programme d'ordinateur et moyens de stockage correspondants |
| PL2704391T3 (pl) * | 2012-08-27 | 2019-10-31 | Broadpeak | System i sposób dostarczania treści audiowizualnych do urządzenia klienckiego |
| US9402107B2 (en) * | 2013-03-15 | 2016-07-26 | Time Warner Cable Enterprises Llc | Apparatus and methods for delivery of multicast and unicast content in a content delivery network |
| JP6385205B2 (ja) * | 2014-09-01 | 2018-09-05 | キヤノン株式会社 | 通信装置、通信装置の制御方法およびプログラム |
| US10193994B2 (en) * | 2015-06-18 | 2019-01-29 | Qualcomm Incorporated | Signaling cached segments for broadcast |
-
2018
- 2018-11-28 DK DK18836386.5T patent/DK3888316T3/da active
- 2018-11-28 BR BR112021010392-9A patent/BR112021010392A2/pt unknown
- 2018-11-28 WO PCT/IB2018/001488 patent/WO2020109834A1/en unknown
- 2018-11-28 JP JP2021531094A patent/JP7312828B2/ja active Active
- 2018-11-28 PT PT188363865T patent/PT3888316T/pt unknown
- 2018-11-28 CN CN201880100478.8A patent/CN113287283B/zh active Active
- 2018-11-28 KR KR1020217019969A patent/KR102506107B1/ko active IP Right Grant
- 2018-11-28 PL PL18836386.5T patent/PL3888316T3/pl unknown
- 2018-11-28 ES ES18836386T patent/ES2965183T3/es active Active
- 2018-11-28 EP EP18836386.5A patent/EP3888316B1/en active Active
- 2018-11-28 CA CA3121298A patent/CA3121298A1/en active Pending
- 2018-11-28 HR HRP20231623TT patent/HRP20231623T1/hr unknown
- 2018-11-28 MX MX2021006191A patent/MX2021006191A/es unknown
- 2018-11-28 SG SG11202105599PA patent/SG11202105599PA/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| US20210314631A1 (en) | 2021-10-07 |
| CN113287283B (zh) | 2024-03-08 |
| JP2022518107A (ja) | 2022-03-14 |
| CN113287283A (zh) | 2021-08-20 |
| SG11202105599PA (en) | 2021-06-29 |
| WO2020109834A1 (en) | 2020-06-04 |
| JP7312828B2 (ja) | 2023-07-21 |
| KR20210119957A (ko) | 2021-10-06 |
| HRP20231623T1 (hr) | 2024-03-15 |
| MX2021006191A (es) | 2021-09-08 |
| KR102506107B1 (ko) | 2023-03-03 |
| PL3888316T3 (pl) | 2024-03-18 |
| EP3888316A1 (en) | 2021-10-06 |
| EP3888316B1 (en) | 2023-09-13 |
| PT3888316T (pt) | 2023-11-16 |
| BR112021010392A2 (pt) | 2021-08-24 |
| DK3888316T3 (da) | 2023-11-27 |
| CA3121298A1 (en) | 2020-06-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2965183T3 (es) | Procedimiento y sistema para la distribución de contenido audiovisual en vivo | |
| US11924311B2 (en) | Hybrid HTTP and UDP content delivery | |
| EP2897340B1 (en) | Routing proxy for adaptive streaming | |
| ES2736955T3 (es) | Sistema y método para la distribución de un contenido audiovisual a un dispositivo de cliente | |
| ES2586818T3 (es) | Control de flujo de contenido tratado inicialmente en red | |
| BR112015016989B1 (pt) | Suporte à diversidade de transporte e armazenadores deslocados no tempo para fluxo contínuo de mídia através de rede | |
| US20090157893A1 (en) | Personal media relay for rebroadcasting streaming data | |
| RU2791242C2 (ru) | Способ и система доставки аудиовизуального контента в режиме реального времени | |
| US12003788B2 (en) | Method and system for audio-visual live content delivery | |
| ES2877338T3 (es) | Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia | |
| Hammershøj et al. | The Next-Generation Television Broadcasting Test Platform in Copenhagen | |
| ES2928485T3 (es) | Procedimiento para suministrar contenidos de audio y/o vídeo a un reproductor | |
| US20220014826A1 (en) | Adaptive bit rate data casting | |
| CN117459747A (zh) | 一种数据传输方法以及装置 |