MX2014012361A - Metodos y sistemas para transmultiplexar en tiempo real de contenido multimedia para flujo continuo de datos. - Google Patents

Metodos y sistemas para transmultiplexar en tiempo real de contenido multimedia para flujo continuo de datos.

Info

Publication number
MX2014012361A
MX2014012361A MX2014012361A MX2014012361A MX2014012361A MX 2014012361 A MX2014012361 A MX 2014012361A MX 2014012361 A MX2014012361 A MX 2014012361A MX 2014012361 A MX2014012361 A MX 2014012361A MX 2014012361 A MX2014012361 A MX 2014012361A
Authority
MX
Mexico
Prior art keywords
client
request
format
source
content
Prior art date
Application number
MX2014012361A
Other languages
English (en)
Other versions
MX353807B (es
Inventor
Robert Myers
Parasuram Ranganathan
Ivan Chvets
Krzysztof Pakulski
Original Assignee
Seawell Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Seawell Networks Inc filed Critical Seawell Networks Inc
Publication of MX2014012361A publication Critical patent/MX2014012361A/es
Publication of MX353807B publication Critical patent/MX353807B/es

Links

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/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/643—Communication protocols
    • H04N21/64322—IP
    • 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/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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H04N21/2221—Secondary servers, e.g. proxy server, cable television Head-end being a cable television head-end
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

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

Abstract

Sistemas y métodos para proporcionar un proxy de traslación inversa completa para contenido multimedia para flujo continuo de datos, el cual puede emplear rastreo o transmultiplexión de sesión o ambos; el sistema descrito se puede integrar de manera continúa en un ambiente de corriente adaptable existente; el sistema puede transmultiplexar cada solicitud de un cliente en un formato de entrega soportado por un servidor de contenido origen, y viceversa, sin considerar el formato de entrega específico utilizado por el cliente o el servidor; por el contrario, el sistema además puede transmultiplexar el contenido solicitado en el formato de entrega utilizado por el cliente; un modelo de sesión sin estado puede vincular cada solicitud de un usuario final específico para una pieza de contenido específica a una sesión de flujo continuo de datos de cliente identificada particular.

Description

METODOS Y SISTEMAS PARA TRANSMULTIPLEXA EN TIEMPO REAL DE CONTENIDO MULTIMEDIA PARA FLUJO CONTINUO DE DATOS CAMPO DE LA INVENCION Las modalidades descritas se refieren al campo de medios en corriente, y en particular a la corriente en tiempo real o sobre demanda de contenido de audio y video.
ANTECEDENTES DE LA INVENCION El mercado para servicio multimedia "Por encima de lo superior" (OTT) se está volviendo cada vez más complejo. Muchos productores de contenido están abarcando el denominado enfoque de tres pantallas para contenido de video OTT (por ejemplo, televisión, Internet, dispositivo móvil, etc.). Los fabricantes de dispositivos están integrando capacidades de corriente directamente en los productos respectivos. Los jugadores de la industria tradicional están luchando por ganar o conservar su sector del mercado, mientras que surgen nuevos competidores.
Están surgiendo nuevos estándares para estos diversos servicios. Sin embargo, algo común generalmente aceptado es el uso de la corriente adaptable basada en HTTP. HTTP o protocolo de transferencia de hipertexto es un estándar ampliamente utilizado en la Web mundial. Su prevalecencia lo hace conveniente para uso en una variedad de dispositivos y, en particular, en una variedad de ambientes de red. Por consiguiente, la corriente adaptable basada en HTTP, la cual apalanca HTTP, es vista como una forma conveniente para asegurar la Calidad de Experiencia Aceptable (QoE) para los usuarios finales, mientras que se brinda la capacidad para ver el mismo contenido en cualquier dispositivo sobre cualquier red.
Un número de las soluciones actuales de la corriente adaptable basada en HTTP para contenido multimedia (por ejemplo, video y audio) proporciona una buena QoE incluso cuando los dispositivos están en un ambiente con ancho de banda dinámicamente variable. En particular, muchas soluciones de corriente adaptable generalmente hoy en dia utilizan múltiples codificaciones o alternativamente codificaciones escalables del mismo contenido, el cual puede ser entregado de acuerdo con el ambiente de ancho de banda actual.
Sin embargo, cada una de las soluciones de corriente dispares generalmente utiliza un enfoque diferente para formateo de contenido, recuperación del cliente y protocolos de reproducción, y los algoritmos asociados para seleccionar tasas de transferencia de bits. Aunque puede haber cosas en común, tal como en el formato de codificación de contenido subyacente, estos enfoques pueden no ser inmediatamente compatibles. Además, la arquitectura de red (por ejemplo, servidores, dispositivos, software) utilizados para entrega de contenido en corriente puede diferir.
Dada la existencia de múltiples estándares en competición, los productores de contenido se están enfrentando con el problema de seleccionar uno o más estándares mutuamente incompatibles de utilizar y soportar. Por ejemplo, dispositivos tales como el iPhone, iPod e iPad de Apple únicamente soportan la solución de corriente de Apple. Sin embargo, la solución de Apple no es directamente soportada por dispositivos basados en Microsoft Windows. Por el contrario, el enfoque de Flujo Continuo de Datos Suave de Microsoft no es directamente soportado en dispositivos Apple. Este dilema únicamente se ve exacerbado cuando el productor de contenido desea soportar otros dispositivos, tales como aquellos basados en el sistema operativo Google Android.
Diversas organizaciones están desarrollando estándares para corriente adaptable basada en HTTP, pero cada una de estas a final de cuentas pudiera tener sus propias idiosincrasias particulares dependiendo de su aplicación objetivo. Por ejemplo, MPEG está desarrollando DASH (Corriente Adaptable Dinámica a través de HTTP), 3GPP ha definido su propio enfoque, W3C está desarrollando fragmentos de medios.
Dado este ambiente, los productores de contenido ya sea que puedan soportar todas las diversas permutaciones de estándares y dispositivos, o corran el riesgo de algunas combinaciones no soportadas.
BREVE DESCRIPCION DE LA INVENCIÓN En un primer aspecto amplio, se proporciona un sistema para entregar un producto de contenido multimedia para flujo continuo de datos desde un servidor origen a un dispositivo cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el sistema comprende: un módulo de mapeo configurado para recibir una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos utilizando un formato de entrega de cliente, determinar que la solicitud del cliente está en el formato de entrega de cliente y generar una solicitud intermedia en el formato de entrega origen que corresponda a la solicitud del cliente; un módulo de cliente intermedio configurado para transmitir la solicitud intermedia al servidor y recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondientes a la parte solicitada del producto de contenido multimedia para flujo continuo de datos, en donde el subconjunto es recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen; un módulo de conversión de contenedor configurado para desempacar el subconjunto del formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente permanecen codificados en el formato de codificación origen, y un módulo de servidor intermedio configurado para transmitir al cliente el producto de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente utilizando el formato de entrega de cliente.
En algunos casos, el módulo de conversión de contenedor empaca los productos de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente reensamblando la primera pluralidad de fragmentos de contenido en una segunda pluralidad de fragmentos de contenido, en donde la segunda pluralidad de fragmentos de contenido tiene duraciones diferentes a la primera pluralidad b de fragmentos de contenido.
En algunos casos, el módulo de mapeo puede determinar gue el servidor origen está configurado para transmitir utilizando el formato de entrega origen transmitiendo una o más solicitudes utilizando formatos de entrega predeterminados y determinando si se recibió una respuesta exitosa. El módulo de mapeo puede determinar gue la solicitud de cliente está en el formato de entrega de cliente comparando la solicitud de cliente con una pluralidad de patrones de solicitud predeterminados.
El servidor intermedio además puede comprender un módulo de administración de sesión configurado para iniciar una sesión de flujo continuo de datos cuando se recibe la solicitud del cliente.
El módulo de administración de sesión además se puede configurar para determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando solicitudes de fragmentos del cliente.
En otro amplio aspecto, se proporciona un método para entregar un producto de contenido multimedia para flujo continuo de datos desde un servidor origen a un cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen. El método comprende: recibir una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos utilizando un formato de entrega de cliente; determinar que la solicitud del cliente está en el formato de entrega de cliente; generar una solicitud intermedia correspondiente a la solicitud de cliente, en donde la solicitud origen está en el formato de entrega origen; transmitir la solicitud intermedia al servidor; recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondientes a la parte solicitada del producto de contenido multimedia para flujo continuo de datos; en donde el subconjunto es recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen; desempacar el subconjunto del formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente permanecen codificados en el formato de codificación origen; y transmitir el producto de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente al cliente utilizando el formato de entrega de cliente.
El empaque se puede ejecutar reensamblando la primera pluralidad de fragmentos de contenido en una segunda pluralidad de fragmentos de contenido, en donde la segunda pluralidad de fragmentos de contenido tiene duraciones diferentes a la primera pluralidad de fragmentos de contenido.
El método además puede comprender, determinar que el servidor origen está configurado para transmitir utilizando el formato de entrega origen transmitiendo una o más solicitudes utilizando formatos de entrega predeterminados y determinando si se recibió una respuesta exitosa.
El método también puede comprender, determinar que la solicitud del cliente está en el formato de entrega de cliente comparando la solicitud del cliente con una pluralidad de patrones de solicitud predeterminados.
El método además también puede comprender, iniciar una sesión de flujo continuo de datos cuando se recibe la solicitud del cliente.
El método además puede también comprender, determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando solicitudes de fragmento desde el cliente.
En otro aspecto amplio, se proporciona un sistema para entregar un producto de contenido multimedia para flujo continuo de datos desde un servidor origen a un dispositivos de cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el sistema comprende: un módulo de mapeo configurado para recibir al menos una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos y generar una solicitud intermedia gue corresponda al menos a una solicitud de cliente; un módulo de administración de sesión configurado para iniciar una sesión de flujo continuo de datos cuando se recibe al menos una solicitud de cliente, el módulo de administración de sesión además está configurado para determinar un estado de sesión del cliente para la sesión de flujo continuo de datos onitoreando al menos una solicitud de cliente; un módulo de cliente intermedio configurado para transmitir la solicitud intermedia al servidor y recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondiente a la parte solicitada del producto de contenido multimedia para flujo continuo de datos; un módulo de servidor intermedio configurado para transmitir el producto de contenido multimedia para flujo continuo de datos al cliente.
El servidor origen puede tener un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, en donde el módulo de mapeo se puede configurar para recibir la solicitud de cliente utilizando un formato de entrega de cliente y determinar que la solicitud de cliente está en el formato de entrega de cliente, en donde la solicitud intermedia puede estar en el formato de entrega origen, en donde el subconjunto de la primera pluralidad de fragmentos de contenido puede ser recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen, y el sistema además puede comprender un módulo de conversión de contenedor configurado para desempacar el subconjunto desde el formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente pueden permanecer codificados en el formato de codificación origen, en donde el módulo de servidor intermedio se puede configurar para transmitir al cliente el producto de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente utilizando del formato de entrega de cliente.
El módulo de administración de sesión además se puede configurar para identificar el estado de todas las sesiones de cliente abiertas. El módulo de administración de sesión además se puede configurar para marcar el estado de sesión como inactivo después de un periodo de tiempo fuera predeterminado. El módulo de administración de sesión además se puede configurar para marcar el estado de la sesión como activo cuando se recibe una solicitud de fragmento adicional asociada con la sesión de cliente.
Al menos una solicitud de cliente puede comprender una pluralidad de solicitudes de cliente, y en donde el estado de la sesión se puede determinar con base en una temporización de la pluralidad de solicitudes de cliente.
Cuando la temporización puede indicar que la pluralidad de solicitudes de cliente son para fragmentos que están fuera de secuencia, entonces se puede determinar una operación de búsqueda. Cuando la temporización puede indicar que un tiempo transcurrido real excede un tiempo de reproducción de fragmentos solicitados en la pluralidad de solicitudes de cliente, entonces se puede determinar una operación de reproducción no estándar.
En otro amplio aspecto, se proporciona un método para entregar un producto de contenido multimedia para flujo continuo de datos desde un servidor origen a un dispositivo de cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el sistema comprende: recibir al menos una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos; generar una solicitud intermedia que corresponde al menos a una solicitud de cliente; iniciar una sesión de flujo continuo de datos cuando se recibe al menos una solicitud de cliente; determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando al menos una solicitud de cliente; transmitir la solicitud intermedia al servidor; recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondiente a la parte solicitada del producto de contenido multimedia para flujo continuo de datos, y transmitir al cliente el producto de contenido multimedia para flujo continuo de datos.
El servidor origen puede tener un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, en donde la solicitud del cliente puede ser recibida utilizando un formato de entrega de cliente, en donde la solicitud intermedia puede ser en el formato de entrega origen, en donde el subconjunto de la primera pluralidad de fragmentos de contenido puede ser recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen, el método además puede comprender desempacar el subconjunto del formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto gue están empacados en el formato de contenedor de cliente pueden permanecer codificados en el formato de codificación origen, y en donde el producto de contenido multimedia para flujo continuo de datos puede ser transmitido al cliente en el formato de contenedor de cliente utilizando el formato de entrega de cliente.
El método además puede comprender, identificar el estado de todas las sesiones de cliente abiertas. El método además puede comprender marcar el estado de sesión como inactivo después de un periodo de tiempo fuera predeterminado. El método además puede comprender, marcar el estado de sesión como activo cuando se recibe una solicitud de fragmento adicional asociada con la sesión de cliente.
Al menos una solicitud de cliente puede comprender una pluralidad de solicitudes de cliente, y en donde el estado de la sesión se puede determinar con base en una temporización de la pluralidad de solicitudes de cliente.
Cuando la temporización indica que la pluralidad de solicitudes de cliente son para fragmentos que están fuera de secuencia, entonces se puede determinar una operación de búsqueda. Cuando la temporización indica que un tiempo transcurrido real excede un tiempo de reproducción de fragmentos solicitados en la pluralidad de solicitudes de cliente, entonces se puede determinar una operación de reproducción no estándar.
Aspectos y ventajas adicionales de las modalidades aquí escritas aparecerán en la siguiente descripción tomada junto con los dibujos acompañantes.
BREVE DESCRIPCION DE LAS FIGURAS Para un mejor entendimiento de las modalidades de los sistemas y métodos aqui descritos, y para mostrar de manera más clara la forma en que se puede llevar a cabo, se hará referencia, a manera de ejemplo, a los dibujos acompañantes en los cuales: La figura 1 ilustra una red ejemplar con la capacidad para transmitir y recibir contenido multimedia; La figura 2 ilustra un sistema de flujo continuo de datos de la téenica anterior; La figura 3 ilustra otro sistema de flujo continuo de datos de la técnica anterior; La figura 4 ilustra un sistema de flujo continuo de datos simplificado de acuerdo con algunas modalidades; La figura 5 ilustra un diagrama en bloques del sistema simplificado ejemplar de un servidor intermedio, parte de un sistema de flujo continuo de datos ejemplar; La figura 6 ilustra un flujo de llamada simplificado para el sistema de la figura 5; La figura 7 ilustra un fragmento de audio y video ejemplar mapeando sobre un eje de tiempo; La figura 8 ilustra un diagrama de estado ejemplar que puede ser utilizado por el módulo de administración de sesión de un servidor intermedio; La figura 9 ilustra un flujo de llamada detallado ejemplar para el servidor intermedio de la figura 5; La figura 10 ilustra un flujo de llamada ejemplar para aceptar una solicitud de manifiesto inicial; La figura 11 ilustra un flujo de llamada ejemplar para una solicitud de manifiesto inicial rechazada; La figura 12 ilustra un flujo de llamada ejemplar para una solicitud de manifiesto inicial que contiene una dirección de servidor origen inválida; La figura 13 ilustra un flujo de llamada ejemplar para una solicitud de fragmento valida; La figura 14 ilustra un flujo de llamada ejemplo para una solicitud de fragmento invalida; y La figura 15 ilustra un flujo de llamada ejemplar para una solicitud de fragmento de contenido que contiene un identificador de sesión invalido (UUID).
Se apreciará que por simplicidad y claridad de la ilustración, los elementos mostrados en las figuras no necesariamente han sido dibujados a escala. Por ejemplo, las dimensiones de algunos de los elementos se pueden exagerar con relación a otros elementos por claridad. Además, donde se considera apropiado, los números.de referencia se pueden repetir entre las figuras para indicar elementos correspondientes o análogos.
DESCRIPCION DETALLADA DE LA INVENCION Se apreciará que se establecen numerosos detalles específicos para proporcionar un completo entendimiento de las modalidades ejemplares aquí descritas. Sin embargo, aquellos expertos en la téenica entenderán que las modalidades aquí descritas se pueden practicar sin estos detalles específicos.
En otros casos, métodos, procedimientos y componentes muy conocidos no se han descrito a detalle para no oscurecer las modalidades aquí descritas.
Las modalidades de los métodos, sistemas y dispositivos aquí descritos se pueden implementar en hardware o software o una combinación de ambos. Sin embargo, de preferencia, estas modalidades son implementadas en programas de computadora que se ejecutan en computadoras programables, cada una comprendiendo al menos un procesador, un sistema de almacenamiento de datos (incluyendo memoria volátil y no volátil y/o elementos de almacenamiento), al menos un dispositivo de entrada, y al menos un dispositivo de salida. Por ejemplo y sin limitación, las computadoras programables pueden ser servidores de red. Se aplica un código de programa para ingresar datos a fin de ejecutar las funciones aquí descritas y generar información de salida. La información de salida se aplica a uno o más dispositivos de salida en forma conocida.
Cada programa de preferencia es implementado en un procedimiento de alto nivel o un lenguaje de escritura y/o programación orientado al objeto para comunicarse con un sistema de computadora. Sin embargo, los programas pueden ser implementados en un lenguaje de ensamble o máquina, si asi se desea. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado. Cada programa de computadora de preferencia está almacenado en un medio de almacenamiento o un dispositivo (por ejemplo, ROM o disco óptico) legible por una computadora programadle de propósito general o especial, para configurar y operar la computadora cuando el medio de almacenamiento o dispositivo es leído por la computadora para ejecutar los procedimientos aquí descritos. El sistema inventivo también se puede considerar para ser implementado como un medio de almacenamiento legible por computadora no transitorio, configurado con un programa de computadora, donde el medio de almacenamiento así configurado ocasiona que una computadora opere en una manera específica y predefinida para ejecutar las funciones aquí descritas.
Además, los métodos, sistemas y dispositivos de las modalidades descritas tienen la capacidad para ser distribuidos en un producto de programa de computadora que comprende un medio legible por computadora no transitorio físico que porta instrucciones utilizables por la computadora para uno o más procesadores. El medio puede ser proporcionado en diversas formas, incluyendo uno o más diskettes, discos compactos, cintas, chips, medios de almacenamiento magnéticos y electrónicos, y similar. Las instrucciones utilizables por la computadora también pueden ser en diversas formas, incluyendo un código compilado y no compilado.
En el presente existe una variedad de estándares dispares para corriente adaptable basada en HTTP. La tabla 1 establece las diversas propiedades de cinco estándares ejempiares.
TABLA 1 Tal como se muestra en la Tabla 1, cada uno de estos estándares utiliza HTTP como sü protocolo de transporte, y cada uno puede utilizar el estándar MP-4 AVC (es decir H.264) como el codeo de video (es decir, formato de codificación).
Sin embargo, más allá de estas partes comunes, los estándares ilustrados divergen significativamente en términos de esguemas de formateo y entrega de archivos (es decir, formatos de entrega). Se apreciará gue las modalidades descritas pueden ser utilizadas con otros protocolos de transporte y codees de video.
Desde la perspectiva del productor de contenido, la entrega del mismo contenido a múltiples reproductores introduce una complejidad progresivamente mayor a medida que se soportan más dispositivos y estándares. Afortunadamente, debido a que cada uno de los estándares puede soportar el mismo formato de codificación de H.264 (MPEG-4 AVC), un Productor de Contenido solamente necesita codificar el contenido una vez para cada una de las tasas de transferencia de bits que va a ser soportada. Sin embargo, los archivos de contenido pueden necesitar ser recreados y almacenados múltiples veces para soportar los diferentes formatos de contenedor. En particular, cuando se crean los archivos de contenido, el contenido de audio y video codificado generalmente es "multiplexado" en el formato apropiado para un reproductor o estándar especifico.
Además, el contenido en cada uno de los formatos dispares puede requerir ser entregado por servidores específicos que entiendan los formatos de entrega respectivos .
TABLA 2 Almacenamiento e Impacto de Archivo de Soluciones para flujo continuo de datos multi-adaptables.
Haciendo referencia ahora a la tabla 2, se muestra el impacto del almacenamiento al soportar tres formatos de entrega mayores para un ejemplo de video de 10 minutos. Aunque cada uno de los formatos de entrega puede tener una pequeña diferencia en cabecera, se asumió que era la misma en este ejemplo para propósitos de simplicidad.
Se puede observar en la tabla 2 que, aún cuando el formato de codificación puede ser idéntico entre las tres soluciones, el uso de diferentes formatos de entrega, y la diferencia en los formatos de contenedor que esto puede conllevar, para cada uno de los estándares soportados triplica de manera efectiva el espacio de almacenamiento requerido. Por ejemplo, los fragmentos de Apple solamente tienen 10 segundos de duración y por lo tanto es un número más grande de archivos. Por consiguiente, cada formato de entrega soportado adicional puede representar un incremento concomitante en el espacio de almacenamiento requerido. Esto también puede tener como resultado costos incrementados del ancho de banda para entregar el contenido entre servidores origen y servidores de caché ubicados en los bordes de las redes de entrega de contenido.
Los estándares ejemplares antes mostrados generalmente utilizan el mismo enfoque fundamental de agrupar contenido en fragmentos multimedia temporalmente alineados, con un cliente inteligente que determinará cuales fragmentos recuperar a fin de reproducir el contenido. Sin embargo, el enfoque real y el formato de entrega utilizado para recuperar el contenido difieren en cada estándar.
En los enfoques utilizados por los estándares de Adobe y Microsoft, el modelo está basado en un cliente que realiza una solicitud URL de marca propia. La solicitud URL de marca propia es recibida por un módulo de servidor que interpreta la solicitud y recupera los datos apropiados del archivo apropiado que contiene el contenido solicitado.
El módulo de servidor puede ser un enchufe a un servidor HTTP existente, tal como Microsoft IIS o Apache. Por consiguiente, si el productor de contenido desea entregar contenido a dispositivos utilizando cada uno de los diferentes formatos de entrega, se puede requerir que el productor de contenido opere diferentes servidores corriendo cada uno de los diferentes accesorios. De igual manera, se puede necesitar que el productor de contenido soporte diferentes infraestructuras de red para cada estándar soportado, junto con todos los costos asociados de administrar múltiples redes superpuestas.
Además de los diferentes enfoques de servidor, cada uno de los enfoques de cliente individuales ha sido desarrollado con sus propios algoritmos particulares para seleccionar una tasa de transferencia de bits deseada y cuándo ajustar la tasa de transferencia de bits en respuesta a las condiciones de red cambiantes. Cada uno de estos clientes se puede sintonizar para comportarse de manera diferente en diferentes condiciones.
Como resultado de esto, cada estándar tiene "mejores prácticas" asociadas para la creación de contenido que está vinculada a estos algoritmos de cliente. Por ejemplo, Microsoft recomienda utilizar duraciones de fragmento de 2-5 segundos, mientras que Apple recomienda utilizar duraciones de fragmento de 10 segundos. Adobe tiene múltiples recomendaciones para duración dependiendo del despliegue objetivo.
Agregándose a esta complejidad está el problema de los perfiles de codee en los formatos de codificación. En particular, algunos dispositivos solo pueden soportar un subconjunto de los perfiles definidos por el estándar codee H.264 (MPEG-4 AVC). La selección y soporte de estos perfiles se puede dejar en el productor de contenido. Como resultado, el productor de contenido simplemente puede recodificar y multiplexar contenido para cada dispositivo de cliente y tipo de reproductor, componiendo adicionalmente los problemas de procesamiento, almacenamiento y administración de contenido.
El concepto de transcodificación se entenderá como el proceso de recodificar un archivo o corriente de medio desde un codee a otro. Un concepto relacionado es que la transclasificación, la cual puede ser el proceso de cambiar los parámetros de codificación de un archivo o corriente multimedia, utilizando el mismo codee, para producir uno o más archivos o corrientes codificadas de salida a diferentes tasas de transferencia de bits (típicamente tasas de transferencia de bits inferiores que el contenido fuente).
Se han desarrollado téenicas de transclasificación específicas para reducir los requerimientos de computación en comparación con un proceso completo de decodificación y recodificación. Estas téenicas de transclasificación principalmente desarrolladas como una manera para permitir la variación de la tasa de trasferencia de bits de una corriente de video a medida que ésta es entregada al cliente con base en las condiciones de la red, con el objetivo de mejorar la calidad de la experiencia. Dichas técnicas pueden apalancar decisiones tomadas durante el proceso de codificación original (por ejemplo, reutilización de información del vector de movimiento, etc.). Sin embargo, algunas de estas técnicas pueden estar limitadas a que solo puedan soportar diferentes parámetros de cuantificación en el proceso de recodificación, mientras que no permitan otros cambios más flexibles, tal como un cambio en la resolución especial. Los enfoques de corriente adaptable basados en HTTP recientes han disminuido la necesidad de enfoques de transclasificación puros.
En contraste a la transcodificación y transclasificación, se describe aquí el proceso de transmultiplexión, el cual comprende cambiar los formatos de contenedor para cumplir con la necesidad de un cliente o reproductor especifico, al mismo tiempo que se conserva el contenido subyacente en su forma originalmente codificada. Los requerimientos computacionales para ejecutar la transmultiplexión pueden ser órdenes de magnitud inferiores a lo que se requiere para transclasificación o transcodificación. Estos se debe a que la transmultiplexión puede omitir el procesamiento del contenido al nivel de compresión de video (codee).
Con las soluciones de flujo continuo de datos adaptable basado en HTTP ahora todo soportando generalmente el codee H.264, y con los bajos requerimientos de computación asociados, se puede emplear la transmultiplexión para permitir que un solo conjunto de archivos de contenido sea utilizado para soportar cualquiera de la amplia variedad de enfoques de flujo continuo de datos adaptable basado en HTTP generalmente empleados, sin transcodificación o transclasificación adicional.
En la práctica, la transmultiplexión puede involucrar un conjunto de servicios que puede tomar contenido existente, sin considerar el formato de entrega original, y crear dinámicamente el conjunto de archivos apropiado (por ejemplo, fragmentos de manifiesto y contenido) para entrega a un cliente especifico utilizando el formato de entrega deseado del cliente.
En una red de entrega de contenido (CDN), la transmultiplexión se puede ejecutar "en el vuelo" o "sobre demanda" siempre que se localice el módulo de transmultiplexión. En algunos casos el módulo de transmultiplexión puede estar ubicado cerca de un servidor origen (es decir, el servidor de contenido original). En otros casos, el módulo de transmultiplexión puede estar en alguna otra parte en una red (por ejemplo, en la nube). Finalmente, en algunos casos, el módulo de transmultiplexión puede estar ubicado en o cerca de un nodo de borde de un CDN. Puede haber beneficios adicionales asociados con la ejecución de la transmultiplexión en el vuelo en un nodo de borde.
Típicamente, la naturaleza sin estado de un servidor Web genérico limita la naturaleza de los servicios que pueden ser proporcionados en un nodo de borde de un CDN. Es decir, un servidor Web genérico puede carecer de la capacidad para rastrear cada solicitud de un cliente particular y asociarla con solicitudes pasadas o futuras para un producto de contenido particular. Esta falta de capacidad para rastrear el estado de una sesión de flujo continuo de datos limita la capacidad para proporcionar servicios específicos de la sesión.
Aquí se describe un modelo de sesión de estado que puede vincular cada solicitud de un usuario final específico para una pieza de contenido específica a una sesión de flujo continuo de datos de cliente identificada particular.
En algunas modalidades, este rastreo de sesión de estado puede ser proporcionado creando archivos de manifiesto de contenido que son específicos para cada sesión (por ejemplo, comprendiendo un identificador de sesión único), de manera que todas las solicitudes futuras para manifiestos o fragmentos se pueden identificar como parte de la misma sesión. La capacidad para identificar y rastrear una sesión puede facilitar servicios adicionales y modelos de despliegue, tal como la restricción de altas tasas de transferencia de bits, por ejemplo, corrientes de calidad superior) a clientes en un punto de precio diferente, o la restricción del tiempo de reproducción con base en la suscripción o tipo de pago. Esta capacidad se puede proporcionar a través del uso de políticas las cuales pueden estar basadas en un número de parámetros.
Las políticas se pueden aplicar sobre una base por sesión. Las políticas por sesión, tales como la limitación de la velocidad, pueden explotar la capacidad para asignar un ancho de banda total máximo para un grupo de usuarios (por ejemplo, todos los usuarios para www.example. . Al adaptar la velocidad a cada usuario individual, el ancho de banda disponible para el grupo se puede distribuir de manera justa entre todos los usuarios concurrentes. Políticas tales como límites de tiempo o cantidad descargada también se pueden aplicar sobre una base por sesión. Además, los usuarios pueden ser agrupados con base en los contextos de sesión tal como el tipo de reproductor, URL objetivo, tipo de red, etc.
La combinación de rastreo de sesión y transmultiplexión en el vuelo permite la creación de manifiestos y fragmentos de contenido que pueden ser específicos para un dispositivo o reproductor de cliente particular, y el uso de formato de entrega preferido del cliente. Por consiguiente, cada sesión puede ser única, ofreciendo una QoE diferente optimizada para esa sesión particular.
Aquí se describe un sistema proxy de traslación inversa completa que puede emplear el rastreo o transmultiplexión de sesión, o ambos. El sistema descrito se puede integrar perfectamente en un ambiente de flujo continuo de datos adaptable existente. En particular, el sistema no requiere que el contenido origen esté en un formato de entrega específico. El sistema puede transmultiplexar o "trasladar" cada solicitud desde un cliente a un formato de entrega soportado por un servidor de contenido origen, y viceversa, sin considerar el formato de entrega específico utilizado ya sea por el cliente o el servidor. Por ejemplo, si un servidor origen desplegado por un productor de contenido utiliza el formato de entrega de Flujo Continuo de Datos Suave de Microsoft, el sistema puede recuperar el contenido solicitado utilizando protocolos de Flujo Continuo de Datos Suave nativos, sin considerar el formato de entrega utilizado por el cliente solicitante. Por el contrario, el sistema puede transmultiplexar el contenido solicitado en el formato de entrega utilizado por el cliente. Por lo tanto, los productores de contenido pueden retener y apalancar todas sus inversiones existentes en codificadores, sistemas de administración de contenido y servidores origen. Para un CDN el cual puede servir a muchos productores de contenido, el sistema descrito se puede desplegar en lugar de múltiples nodos de borde paralelos, los cuales, de otra manera serian requeridos para reportar cada uno de los diferentes estándares de corriente.
Haciendo referencia ahora a la figura 1, se ilustra un sistema ejemplar 100 para transmitir y recibir presentaciones multimedia de flujo continuo de datos. El sistema 100 comprende una red 110, uno o más servidores origen 120 y 120', un servidor proxy del lado del servidor 130, un servidor proxy intermedio 150, uno o más servidores de borde 160 y 160' y uno o más dispositivos de cliente 190 y 190'.
La red 110 puede ser una red de datos comprendida de una o más redes privadas y públicas, tal como la Internet.
El servidor origen 120 puede ser un servidor de red equipado con almacenamiento de datos para almacenar contenido multimedia, tal como archivos de audio y video en el formato MPEG-4 AVC memoria y un procesador configurado para proporcionar el contenido multimedia utilizando un protocolo de corriente adaptable basado en HTTP. En una modalidad, el servidor origen 120 se puede configurar para proporcionar el contenido multimedia utilizando el formato de entrega de Flujo Continuo de Datos Suave de Microsoft. En otras modalidades, el servidor origen 120 se puede configurar para proporcionar el contenido multimedia utilizando otro formato de entrega, tal como aquellos desarrollados por Adobe o Apple.
El servidor origen 120' generalmente puede ser análogo al servidor origen 120, excepto que éste puede utilizar un formato de entrega diferente para corriente adaptable basada en HTTP que el servidor origen 120.
El servidor de borde 160 puede ser un servidor de red o aparato equipado con almacenamiento de datos para almacenar en caché el contenido multimedia, memoria y un procesador configurado para proporcionar un servicio de transmultiplexión y proxy de traslación inversa, tal como aquí se describe. Cada servidor de borde 160 puede estar ubicado generalmente cerca de uno o más dispositivos de cliente 190 y 190', ya sea geográficamente o en términos de red (es decir, dentro de relativamente pocos saltos de red).
El servidor proxy del lado del servidor 130 y el servidor proxy intermedio 150 generalmente pueden ser análogos al servidor de borde 160, excepto que estos pueden estar en una posición diferente en la red. Por ejemplo, el servidor proxy del lado del servidor 130 puede estar colocado cerca del servidor origen 120 y el servidor proxy intermedio 150 puede estar colocado dentro de la red 110 (por ejemplo, dentro de la "nube").
Los dispositivos de cliente 190 y 190' pueden ser un dispositivo de reproducción multimedia habilitado por red, tal como una computadora personal, computadora de tableta, teléfono inteligente, televisión habilitada por red o reproductor multimedia, o similar. Cada dispositivo de cliente 190 o 190' generalmente comprende una memoria y procesador que se pueden configurar para recuperar contenido multimedia sobre una red utilizando un formato de entrega de flujo continuo de datos (por ejemplo, flujo continuo de datos adaptable basado en HTTP) y para decodificar el contenido para reproducción a un usuario. El dispositivo de cliente 190' generalmente es análogo al dispositivo de cliente 190, excepto que éste puede estar configurado para utilizar un formato de entrega diferente que el dispositivo de cliente 190.
Por ejemplo, en una modalidad, el dispositivo de cliente 190 se puede configurar para recuperar el contenido multimedia utilizando el formato de entrega de Flujo Continuo de Datos Suave de Microsoft. En otras modalidades, el dispositivo de cliente 190 se puede configurar para recuperar el contenido multimedia utilizando otro formato de entrega, tal como aquellos desarrollados por Adobe o Apple.
Haciendo referencia ahora a la figura 2, se ilustra un sistema de flujo continuo de datos de la téenica anterior 200. El sistema de flujo continuo de datos 200 comprende un servidor origen 220, un dispositivo de c-liente 290 y un servidor caché 240. El servidor origen 220 generalmente puede ser análogo al servidor origen 120. De manera similar, el dispositivo de cliente 290 generalmente puede ser análogo al dispositivo de cliente 190 o 190'.
El servidor caché 240 puede ser un servidor caché o proxy inverso, que comprende almacenamiento de datos, memoria y un procesador configurado para proporcionar servicio proxy inverso. Generalmente, un proxy inverso comprende un servidor HTTP para recibir solicitudes desde un cliente, tal como el dispositivo de cliente 290. El proxy inverso también comprende un cliente HTTP para transmitir las solicitudes a un servidor corriente arriba, tal como el -servidor origen 220. Cuando se recibe una respuesta de solicitud, el proxy inverso puede reenviar los datos de respuesta al dispositivo de cliente 290 y, opcionalmente, poner en caché los datos de respuesta localmente. Si en un momento posterior el proxy inverso recibe otra solicitud idéntica (por ejemplo, para el mismo contenido), el proxy inverso inmediatamente puede responder con datos de respuesta localmente en caché. Por consiguiente, el proxy inverso puede mitigar la carga de dar servicio a un número grande de clientes que de otra manera se comunicarían con el servidor origen 220 directamente.
En el sistema de flujo continuo de datos 200, cada uno del servidor origen 220, servidor caché 240 y dispositivo de cliente 290 se comunica utilizando el mismo formato de entrega de flujo continuo de datos, etiquetado "Protocolo X". El Protocolo X puede ser cualquiera de los formatos de entrega de flujo continuo de datos adaptable basado en HTTP conocidos.
Haciendo referencia ahora a la figura 3, se ilustra otro sistema de flujo continuo de datos 300, que comprende el servidor origen 320, servidor caché 340 y dispositivo de cliente 390. Cada elemento del sistema de flujo continuo de datos 300 generalmente es análogo a su contraparte en el sistema de flujo continuo de datos 200. Sin embargo, mientras que el servidor origen 320 esté configurado para comunicarse utilizando el formato de entrega de Protocolo X, tanto el servidor caché 340 como el dispositivo de cliente 390 están configurados para comunicarse utilizando solamente un formato de entrega de "Protocolo Y" diferente.
Por consiguiente, cuando el dispositivo de cliente 390 intenta transmitir una solicitud en el formato de entrega de cliente al servidor origen 320 (ya sea directamente o a través del servidor caché 340), el servidor origen 320 puede responder con un error, debido al formato de entrega no reconocido.
Haciendo referencia ahora a la figura 4, se ilustra un sistema de flujo continuo de datos simplificado ejemplar 400. El sistema de flujo continuo de datos 400 comprende un servidor origen 420 y un dispositivo de cliente 490, los cuales generalmente son análogos al servidor origen 320 y el dispositivo de cliente 390, respectivamente. El sistema de flujo continuo de datos 400 además comprende un servidor intermedio 460.
El servidor intermedio 460 puede comprender un dispositivo de almacenamiento de datos, una memoria y un procesador configurado para proporcionar servicio proxy de traslación inversa tal como aquí se describe.
Tal como se ilustra, el dispositivo de cliente genera una solicitud de contenido y transmite la solicitud al servidor intermedio 460 utilizando el Protocolo Y (es decir, el formato de entrega de cliente). El servidor intermedio 460 identifica el formato de entrega de la solicitud de contenido e intenta reenviar la solicitud de contenido al servidor origen 420 utilizando el formato de entrega de Protocolo Y. si el servidor intermedio 460 determina que el servidor origen 420 no soporta el formato de entrega de cliente, entonces el servidor intermedio 460 traslada la solicitud de contenido a otro formato de entrega (por ejemplo, Protocolo X), el cual es soportado por el servidor origen 420.
El servidor intermedio 460 entonces puede recuperar el contenido de respuesta solicitado desde el servidor origen 420 y trasladar el contenido de respuesta de regreso al formato de entrega de cliente para entrega al dispositivo de cliente 490.
Por consiguiente, tanto el servidor origen 420 como el cliente 490 se pueden comunicar utilizando sus formatos de entrega soportados respectivos. Además, en algunas modalidades, el servidor intermedio 460 puede almacenar (por ejemplo, caché) el contenido recuperado en el formato de entrega origen, el formato de entrega de cliente, o ambos, para posterior entrega en respuesta a otra solicitud, la cual puede llegar utilizando otro formato de entrega todavía.
Comúnmente, un proxy inverso es desplegado en el contexto de servicios HTTP, y de esta manera se entienden bien las téenicas para aceptar una solicitud y reenviar la solicitud a un huésped apropiado (por ejemplo, servidor origen). Sin embargo, proxys inversos conocidos generalmente sólo reenvían la misma solicitud URL (Localizador de Recursos Uniformes) tal como fue recibida desde el dispositivo de cliente.
En contraste, el servidor intermedio 460 puede cambiar la solicitud URL recibida, con base en el formato de entrega soportado por el servidor origen y un número de otros factores aquí descritos.
La solicitud URL recibida (es decir, la solicitud URL de cliente) generalmente comprende tres componentes principales: el "dominio", que representa el nombre del huésped del servidor origen dentro del URL; la "ubicación" que representa el directorio o estructura de trayectoria utilizada por el servidor origen para identificar un recurso específico; y el identificador de multimedia, que representa la parte del URL solicitado que identifica un recurso específico, tal como el manifiesto o un fragmento de contenido.
Por ejemplo, para una solicitud de manifiesto por parte de un cliente utilizando el formato de entrega de Apple, la solicitud URL del cliente puede ser "http://www.example.com/ABR/videol/BBB.m3u8". Por consiguiente, el dominio es www.example.com, la trayectoria es "/ABR/videol/" y el identificador de medio es "BBB.m3u8".
En al menos algunas modalidades, los componentes de dominio y trayectoria del URL se pueden dejar sin cambios.
Sin embargo, el identificador de multimedia se puede modificar dependiendo de las necesidades del formato de entrega soportado por el servidor origen (es decir, el formato de entrega origen).
En el ejemplo anterior del formato de entrega de Apple, si el servidor origen soporto únicamente el formato de entrega de Flujo Continuo de Datos Suave de Microsoft, entonces el identificador de de multimedia seria cambiado de "BBB.m3u8" a "BBB:ism/Manifest". El dominio y la trayectoria se podrían dejar intactos.
Haciendo referencia ahora a la figura 5, se ilustra un diagrama en bloques del sistema simplificado ejemplar de un servidor intermedio 860, el cual es parte del sistema de flujo continuo de datos 500. El sistema de flujo continuo de datos 500 generalmente es análogo al sistema de flujo continuo de datos 400. De manera similar, cada servidor origen 520 y dispositivo de cliente 590 generalmente puede ser análogo al servidor origen 420 y el dispositivo de cliente 490, respectivamente.
El servidor intermedio 560 puede estar conceptualmente organizado en tres planos, incluyendo un plano de datos, un plano de control y un plano de administración.
El servidor HTTP 566 (el cual también se puede referir como un módulo de servidor intermedio) se puede configurar para recibir solicitudes HTTP (por ejemplo, comprendiendo la solicitud de cliente de los URLs) de los dispositivos de cliente 590, y reenviar las solicitudes recibidas al generador de contenido 564. El servidor HTTP 566 también se puede configurar para entregar datos de respuesta correspondientes a las solicitudes HTTP una vez recibidas desde el generador de contenido 564.
El servidor HTTP 566 puede ejecutar validación inicial de cada solicitud HTTP, por ejemplo, para asegurar gue la solicitud se adapte al protocolo HTTP. Generalmente, el servidor HTTP 566 se puede optimizar para proporcionar un alto desempeño y dar servicio a un número grande de conexiones concurrentes.
El cliente HTTP 562 (el cual también se puede referir como un módulo de cliente intermedio) se puede configurar para recibir solicitudes HTTP desde el generador de contenido 564 y para reenviar la solicitud al servidor origen apropiado 520. De manera similar el cliente HTTP 562 se puede configurar para entregar datos de respuesta al generador de contenido 564, cuando son recibidos desde cada servidor origen 520 en respuesta a una solicitud HTTP. Generalmente, el cliente HTTP 562 se puede optimizar para un alto rendimiento (por ejemplo, alta salida).
El generador de contenido 564 se puede configurar para mover solicitudes desde un componente (por ejemplo, servidor HTTP 566, cliente HTTP 562, plano de control) a otro, y vincular esas solicitudes entre cada uno de los otros componentes. Además, el generador de contenido 564 puede analizar sintácticamente las solicitudes para determinar la manera en que se puede dar mejor servicio a la solicitud.
Por ejemplo, el generador de contenido 564 puede identificar que una solicitud que utiliza el formato de entrega de Protocolo X está destinada a un servidor origen utilizando el formato de entrega de Protocolo Y, y entonces puede determinar que se requiere un transmultiplexor de Protocolo Y-X para dar servicio a la solicitud.
Además, el generador de contenido 564 puede recuperar políticas e información de sesión del cliente desde el plano de control (o plano de administración) para determinar si, o cómo hacer honor a una solicitud de cliente.
El plano de administración puede comprender un módulo de política 570 para almacenar políticas, un módulo de configuración 572 para almacenar configuraciones, un módulo de rastreo de estadísticas 574 para almacenar y rastrear estadísticas relacionas con el sistema, un módulo de registro 576 para almacenar registros y un módulo de eventos 578 para rastrear eventos del sistema.
El generador de contenido 564 puede comprender uno o más transmultiplexores 565, los cuales son responsables de la conversión de las solicitudes y respuestas desde un formato de entrega de corriente adaptable a otro. Cada transmultiplexor 565 puede ser especifico para los formatos de entrega de ingreso y egreso. Por ejemplo, un transmultiplexor de Flujo Continuo de Datos Suave de Microsoft a Apple probablemente sea diferente de un transmultiplexor de Flujo Continuo de Datos Suave de Microsoft a Adobe.
Cada transmultiplexor 565 se puede configurar para analizar sintácticamente una solicitud de cliente a fin de determinar si se trata de una solicitud valida (por ejemplo, se adapta a los reguerimientos del formato de entrega), para determinar si la solicitud es para un fragmento de manifiesto o contenido, y similar.
En caso que una solicitud de cliente requiera que más de una solicitud de servidor origen sea cumplida, entonces el transmultiplexor apropiado 565 también puede determinar cuáles son las solicitudes del servidor origen que se requieren para cumplir con la solicitud del cliente, y puede generar y reenviar las solicitudes correspondientes.
El transmultiplexor 565 también puede convertir ambas solicitudes de fragmento de manifiesto y contenido y las respuestas entre el formato de entrega de origen y el formato de entrega de cliente.
En algunas modalidades, el transmultiplexor 565 está compuesto de dos o más módulos. Un primer módulo, el módulo de mapeo, puede proporcionar servicios de manifiesto y protocolo, mientras que el segundo módulo, el módulo de conversión de contenedor, proporciona servicios de reempaque de fragmento. El reempaque comprende dos funciones: extracción (por ejemplo, el proceso de retirar muestras del fragmento origen); y empaque (por ejemplo, el proceso de colocar muestras en un nuevo formato de contenedor para entrega de fragmento al cliente).
El plano de control principalmente puede comprender un módulo de administración de sesión 568. El módulo de administración de sesión 568 sirve para administrar las sesiones de cliente iniciadas por los dispositivos de cliente 590, y para proporcionar información de configuración o política basada en sesión al generador de contenido 564. Por consiguiente, el módulo de administración de sesión 568 puede interactuar con varios componentes del plano de administración. Además, el módulo de administración de sesión 568 puede crear, leer y actualizar información de sesión de cliente con base en sus interacciones con el generador de contenido 564.
El módulo de administración de sesión 568 puede mantener una tabla de sesión de cliente activa, la cual puede incluir información relevante y contexto necesario para el proceso de extracción.
El módulo de administración de sesión 568 también puede cooperar con el generador de contenido 564 para proporcionar búsquedas rápidas de datos de sesión de cliente.
En algunas modalidades, el módulo de administración de sesión 568 también puede ejecutar funciones de administración de política, las cuales pueden incluir el mantenimiento de una tabla de políticas configuradas, la determinación y asignación de políticas a clientes (por ejemplo, con base en los atributos de cliente, dominio y contenido), y la recopilación y reporte de estadísticas.
La recopilación y reporte de estadísticas puede comprender el envío de actualizaciones de sesión de cliente a un servidor de registro o base de datos para registrar cuándo es que se establece y destruye una sesión.
Haciendo referencia ahora a la figura 6, se ilustra un flujo de llamada simplificado para el sistema de la figura 5.
Uno de los retos inherentes en el proceso de traslación en que el servidor intermedio tiene información limitada al inicio de una sesión de flujo continuo de datos. Cuando una solicitud de manifiesto es primero recibida desde un dispositivo de cliente, el formato de entrega origen puede no ser fácilmente aparente s partir de la solicitud de cliente URL. Por ejemplo, un servidor origen puede soportar más de un formato de entrega origen que puede ser utilizado para cumplir con la solicitud de manifiesto. Por consiguiente, el servidor intermedio 560 debe determinar una traslación conveniente del formato de entrega de cliente al formato de entrega origen. Una vez que se identifica una traslación conveniente, el servidor intermedio puede recuperar el manifiesto origen y generar un manifiesto de cliente. Opcionalmente, el servidor intermedio puede almacenar el formato de entrega origen correspondiente a la solicitud URL para permitir que futuras solicitudes de fragmentos de manifiesto y contenido para esa solicitud URL sean aceleradas.
Cuando primero se recibe una solicitud de cliente, el generador de contenido 564 puede intentar identificar si la solicitud es una solicitud de manifiesto inicial. Por ejemplo, el generador de contenido 564 puede examinar la solicitud URL para determinar si ésta contiene un identificador único (por ejemplo, UUID) previamente generado o utilizado por el generador de contenido 564, el cual indicaría que ya existe una sesión, y que la solicitud no es una solicitud de manifiesto inicial.
De manera más general para todos los tipos de solicitudes de cliente, el generador de contenido 564 puede analizar sintácticamente el URL en la solicitud HTTP para determinar si éste contiene una firma especifica en el URL que indique cuál es el formato de entrega que se está utilizando, y cuál transmultiplexor 565 debiera ser utilizado para manejar la solicitud. Cada formato de entrega tiene una firma específica única en su formato de solicitud de manifiesto. Por ejemplo, el formato de entrega de Flujo Continuo de .Datos Suave de Microsoft tiene un componente de identificador de medio del URL en la forma de "XXXXX.ism/Manifest", donde XXXXX es el nombre del activo multimedia. En otro ejemplo, el formato de entrega de Adobe utiliza una extensión de archivo de .f4m para representar un manifiesto. De manera similar, el formato de entrega de Apple utiliza una extensión de archivo de .m3u8 para representar un manifiesto. Por consiguiente, en algunas modalidades, el generador de contenido 564 simplemente puede utilizar el componente de identificador de multimedia de la solicitud URL para determinar si la solicitud corresponde a un manifiesto.
Los archivos de manifiesto generalmente son utilizados para proporcionar un índice de los fragmentos de contenido que constituyen un producto multimedia, y para proporcionar metadatos referentes a las opciones de flujo continuo de datos disponibles. Por ejemplo, un archivo de manifiesto puede especificar un tipo de formato de entrega, versión de formato de entrega, escala de tiempo, duración de contenido, duraciones de fragmento, parámetros de codificación de fragmento (tasa de transferencia de bits, codee, tamaño), fragmentos URLs o plantillas URL, y otros datos.
Por consiguiente, el manifiesto proporciona suficiente información a un dispositivo de cliente para que el dispositivo de cliente determine las diferentes tasas de transferencia de bits soportadas, la manera en que el video y audio han sido codificados, y la manera en que el cliente puede generar solicitudes para fragmentos específicos.
A continuación se muestra un archivo de manifiesto de Flujo Continuo de Datos Suave de Microsoft ejemplar. <?xml versión="1.0 " codificación="utf-16"?> <Medio de Flujo Continuo de Datos Suave VersiónMayor="2 " VersiónMenor="0" EscalaDeTiempo="10000000" Duración="200000000"> <IndiceDeCorrúente Tipo="video" EscalaDeTiempo="10000000" Nombre="video" Trozos="10" NivelesDeCalidad="6" Url="NivelesDeCalidad({TasaDeTransferenciaDeBits} )/Fragmentos(video={TiempoDelnicio}) " AnchuraMáxima="1280" AlturaMáxima="720" AnchuraDePantalla="1280" AlturaDePantalla="720 "> <NivelDeCalidad lndice="0" TasaDeTransferenciaDeBits="3500000" TasaDeTransferenciaDeBitsNominal="3518464 " TiempoDeMemoriaIntermedia="1000" CuatroCC="H264 " AnchuraMáxima="1280 " AlturaMáxima="720" DatosPrivadosCodec="00000001274D401F965402802 DD80B44000003000400000300C3B40035B006B8BDEF82 800000000128EF060CC8" CampoLongitudUnidadNAL="4 " /> <NivelDeCalidad Indice="l" TasaDeTransferenciaDeBits="2500000" TasaDeTransferenciaDeBitsNominal="2514944 " TiempoDeMemoriaIntermedia="1000" CuatroCC="H264 " AnchuraMáxima="853" AlturaMáxima="480" DatosPrivadosCodec="00000001274D401E965406C1E F37FF82800280B440000003004000000C3B400266004C EBDEF8280000000128EF060CC8 " CampoLongitudUnidadNAL="4 " <NivelDeCalidad Indice="2" TasaDeTransferenciaDeBits="1500000" TasaDeTransferenciaDeBitsNominal ="1509376" TiempoDeMemorialntermedia ="1000" CuatroCC="H264 " AnchuraMáxima ="640" AlturaMáxima ="360" DatosPrivadosCodec="00000001274D401E96540501 7FCB80B440000003004000000C3AB802E1005C4BDEF8 280000000128EF060CC8" CampoLongitudUnidadNAL ="4" /> < NivelDeCalidad Indice="3" TasaDeTransferenciaDeBits ="1000000" TasaDeTransferenGiaDeBitsNominal ="1005568" TiempoDeMemorialntermedia ="1000" CuatroCC="H264 " AnchuraMáxima ="568" AlturaMáxima ="320" DatosPrivadosCodec="00000001274D401E96540481 4F2FFF8140013FB440000003004000000C3A3003D600 7AEBDEF8280000000128EF060CC8" CampoLongitudUnidadNAL ="4" /> < NivelDeCalidad Indice="4" TasaDeTransferenciaDeBits ="500000" TasaDeTransferenciaDeBitsNominal ="502784" TiempoDeMemorialntermedia ="1000" CuatroCC="H264 " AnchuraMáxima ="568" AlturaMáxima="32O " DatosPrivadosCodec="00000001274D401E965404814 F2FFF8140013FB440000003004000000C39A803D6007B 0BDEF8280000000128EF060CC8" CampoLongitudUnidadNAL ="4" /> < NivelDeCalidad Indice="5" TasaDeTransferenciaDeBits ="300000" TasaDeTransferenciaDeBitsNominal ="301568" TiempoDeMemoriaIntermedia ="1000" CuatroCC="H264 " AnchuraMáxima ="568" AlturaMáxima ="320" DatosPrivadosCodec="00000001274D401E965404814 F2FFF8140013FB440000003004OOOOOOC39A8024D0049 EBDEF8280000000128EF060CC8" CampoLongitudUnidadNAL ="4" /> <c n="0" d="20000000" /> <c n="l" d="20000000 " /> <c n="2" d="20000000" /> <c n="3" d="20000000" /> <c n="4" d="20000000" /> <c n="5" d="20000000" /> <c n="6" d="20000000" /> <c n="7 " d="20000000" /> <c n="8 " d="20000000" /> <c n="9" d="20000000" /> </IndiceDeCorriente> <IndiceDeCorriente Tipo="audio" EscalaDeTiempo="10000000" Nombre="audio" Trozos="10" NivelesCalidad="1" Url="NivelesCalidad({TasaDeTransferenci DeBits})/ Fragmentos(audio={TiempoDeInicio}) "> <NivelDeCalidad lndice="0" TasaDeTransferenciaDeBits="64000" VelocidadDeMuestreo="44100" Canales="2" BitsPorMuestra="16" TamañoPaquete="4 " EtiquetaAudio="255" CuatroCC="AACL" DatosPrivadosCodec="1210" /> <c n="0" d= "20201360" /> <c n="1" d="20201361" /> <c n="2" d= "20201360 " /> <c n="3" d= "20201361 " /> <c n="4" d="20201360" /> <c n="5 " d="20201361" /> <c n="6" d="20201360" /> <c n="7 " d="20201361" /> <c n="8 " d="20201360" /> <c n="9" d="20201361" /> </IndiceDeCorriente> </MultimediaFlujoContinuoDeDatosSuave> En contraste al formato de entrega de Flujo Continuo de Datos Suave de Microsoft, el formato de entrega HLS de Apple utiliza un enfoque de manifiesto multi-niveles, en el cual un manifiesto inicial se refiere a manifiestos de nivel aún inferiores. A continuación se muestra un manifiesto inicial: #EXTM3U #EXT-X-CORRIENTE-INF: PROGRAMA-ID=1, ANCHODEBANDA=300000 http://www.example.com/ABR/Videol/bbb_6capas_2sec_3000 00.m3u8 #EXT-X-CORRIENTE-INF: PROGRAMA-ID=1, ANCHODEBANDA=500000 http://www.example.com/ABR/Videol/bbb_6capas_2sec_5000 00.m3u8 #EXT-X-CORRIENTE-INF: PROGRAMA-ID=1, ANCHODEBANDA=l000000 http://www.example.com/ABR/Videol/bbb_6capas_2sec_1000 000.m3u8 #EXT-X-CORRIENTE-INF: PROGRAMA-ID=1, ANCHODEBANDA=1500000 http://www.example.com/ABR/Videol/bbb_6capas_2sec_1500 000.m3u8 #EXT-X-CORRIENTE-INF: PROGRAMA-ID=1, ANCHODEBANDA=2500000 http://www.example.com/ABR/Videol/bbb_6capas_2sec_2500 000.m3u8 #EXT-X-CORRIENTE-INF: PROGRAMA-ID=1, ANCHODEBANDA=3500000 http://www.example.com/ABR/Videol/bbb_6capas_2sec_3500000.m 3u8 A continuación se muestra un manifiesto de nivel inferior, para la corriente de 300000 kbps anterior: #EXTM3U #EXT-X-DURACIONOBJETIVO:2 #EXT-X-MEDIO-SECUENCIA:0 #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 .ts #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 .ts #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 .ts #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 .ts #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 .ts #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 .ts #EXTINF: 2, http://www.example.com/ABR/Videol/bbb_6capas_2sec_300000 6.ts #EXTINF: 2, http:/ /www.example.com/ABR/Videol/bbb_6capas_2sec_30000 0_7.ts #EXTINF : 2, http://www.example .com/ABR/Videol/bbb_6capas_2sec_30000 0_8 .ts #EXTINF : 5 2, http:/ /www.example.com/ABR/Videol/bbb_6capas_2sec_30000 0_9 .ts #EXT-X-ENDLIST En contraste, el formato de entrega de Adobe identifica números de fragmento y su linea de tiempo asociada en un 10 campo llamado "Manos a la Obra"(bootstrap), el cual está codificado y comprimido en el manifiesto. Un ejemplo de un manifiesto de Adobe se muestra a continuación: <?xml version="l.0" codificación="UTF-8"?> <manif iesto ]_5 xmlns="http ://ns.adobe.com/f4m/1.0"> <id> http ://www.example.com/ABR/Videol/bbb_6capas_2sec </id> <TipoCorriente> Registrado 20 </TipoDeCorriente> <TipoDeEntrega> Flujo continuo de datos </TipoDeEntrega> <duración> 20.000000 </duración> <baseURL> http://www.example.com/ABR/Videol/ </baseURL> <Informaciónbootstrap perfi1="nombre" id="bootstrapO"> AAAAemFic3QAAAAAAAAAAQAAAAPoAAAAAAAJGeoAAAAAAAAAAA AAAAAAAQAAAB1hc3J0AAAAAAAAAAABAAAAAQAAASsBAAAANWF enQAAAAAAAAD6AAAAAACAAAAAQAAAAAAAAAAAAAHOAAAASsAAA AAAAkYIAAAAcoA </ Informaciónbootstrap > multimedia IDCorriente="bbb_6capas_2sec_300000_0" url="bbb_6capas_2sec_300000 300000" TasaDeTransferenciaDeBits0"300" bootstraplnfold="bootstrap0" /> < multimedia IDCorriente="bbb_6capas_2sec_500000_l" url="bbb_6capas_2sec_500000_500000" TasaDeTransferenciaDeBitsO "500" InformaciónbootstrapId="bootstrapO" /> < multimedia IDCorriente="bbb_6capas_2sec_1000000_2" url="bbb_6capas_2sec_1000000_1000000" TasaDeTransferenciaDeBitsO "1000" InformaciónbootstrapId="bootstrapO" /> < multimedia IDCorriente="bbb_6capas_2sec_1500000_3" url="bbb_6capas_2sec_1500000_1500000" TasaDeTransferenciaDeBits0"1500" InformaciónbootstrapId="bootstrapO" /> < multimedia IDCorriente="bbb_6capas_2sec_2500000_4 " url="bbb_6capas_2sec_2500000_2500000" TasaDeTransferenciaDeBits0"2500" InformaciónbootstrapId= "bootstrapO" /> < multimedia IDCorriente="bbb_6capas_2sec_3500000_5" url="bbb_6capas_2sec_3500000_3500000" TasaDeTransferenciaDeBitsO "3500" InformaciónbootstrapId="bootstrapO" /> </manifiesto> Se apreciará que los formatos de archivo de manifiesto para cada tipo de formato de entrega difieren significativamente. Como resultado de esto, los tipos de solicitud URL también difieren. Por consiguiente, el tipo de formato de entrega típicamente puede ser determinando por emparejamiento de patrón de la solicitud URL. El uso de emparejamiento de patrón permite que el servidor intermedio 560 sea actualizado fácilmente en el futuro con definiciones actualizadas de emparejamiento de patrón, a medida que se desarrollan nuevos tipos de formatos de entrega y versiones.
Haciendo referencia nuevamente a la figura 6, en 605, el dispositivo de cliente 590 transmite una solicitud de cliente (comprendiendo una solicitud de manifiesto URL) al servidor intermedio 560. El generador de contenido 564 identifica la solicitud de manifiesto URL y entrega la solicitud al transmultiplexor 565 apropiado.
Si el servidor origen 520 es conocido por el servidor intermedio 560, entonces el transmultiplexor 565 inmediatamente puede generar la solicitud de manifiesto URL apropiada para el servidor origen 520 y transmitir la solicitud en 610.
Si el servidor origen 520 no es conocido, entonces el transmultiplexor 565 puede intentar identificar los tipos de formato de entrega soportados por el servidor origen 520, generando una solicitud de manifiesto URL en un momento y reenviando al servidor origen 520. Si el servidor origen 520 rechaza un URL generado particular (por ejemplo, se devuelve una respuesta de error HTTP 404), entonces el transmultiplexor 565 puede repetir el proceso hasta que se recibe una respuesta exitosa. Este proceso iterativo puede ser detenido cuando el transmultiplexor 565 agota todas las posibilidades conocidas para la solicitud de manifiesto URL.
Cada transmultiplexor 565 puede tener su propio archivo de configuración que especifique los patrones de construcción de manifiesto. En una modalidad, los patrones de construcción pueden ser especificados utilizando pares de etiqueta-valor, tal como se muestra en la siguiente tabla 3.
TABLA 3 Por consiguiente, para una solicitud URL ejemplar de http://example. video storaqe/supervideo.m3u8, el [BASE_URL] seria "http://example.com/video storage", el [DOMINIO_URL] seria "http://example.com", el [UBICACIÓN_URL] seria "video_almacenamiento", el [MULTIMEDIA_URL] seria "supervideo" Y el [EXT_URL] seria "m3u8".
El módulo de mapeo del transmultiplexor 565 puede generar una solicitud de manifiesto URL para reenvió a un servidor origen insertando los valores apropiados en patrones de plantilla previamente específicos para cada formato de entrega soportado. Debido a que cada servidor origen puede tener variaciones menores, puede haber una pluralidad de patrones de plantilla previamente especificaos para que el transmultiplexor itere a través de ellos, incluso dentro de un tipo de protocolo particular.
Por ejemplo, los servidores origen que soportan el formato de entrega de Apple pueden tener variaciones menores en la forma de una solicitud de manifiesto URL. Por consiguiente, los patrones de plantilla previamente especificados pueden incluir: [BASE_URL]/[MULTIMEDIA_URL].m3u8 [BASE_URL]/[MULTIMEDIA_URL]/playlist.m3u8 [BASE_URL]/[MULTIMEDIA_URL].ism/Manifest(format=m3u8-aapl) [BASE_URL]/[MULTIMEDIA_URL].isml/Manifest(format=m3u8-aapl) [BASE_URL]/mp4:[MULTIMEDIA_URL].mp4/playlist.m3u8 [BASE_URL]/smil:[MULTIMEDIA_URL].smil/playlist.m3u8 Se apreciará que diversos patrones adicionales también podrían ser previamente especificados, tanto para el formato de entrega de Apple como para otros formatos de entrega.
Como un ejemplo, considerar una solicitud de cliente en el formato de entrega de Flujo Continuo de Datos Suave de Microsoft destinado a un servidor origen utilizando el formato de entrega de Apple. La solicitud URL puede asumir la forma de "http://example.com/vod/supervideo.ism/Manifest". En este ejemplo, el [BASE_URL] sería "example.com/", el [UBICACIÓN_URL] sería "vod/" y el [MULTIMEDIA_URL] sería "supervideo".
Por consiguiente, con base en un patrón previamente especificado para el servidor origen de "http://[BASE URL]/[LOCATION URL][MEDIA URL].m3u8", la solicitud generada URL para el servidor seria "http://example.com/vod/supervideo.m3u8".
Una vez que una solicitud URL es generada y transmitida en 610, y una respuesta exitosa que comprende un manifiesto es recibida en 615, el módulo de mapeo del transmultiplexor 565 puede convertir el manifiesto recibido del protocolo utilizado por el servidor origen en aquél utilizado por el dispositivo de cliente.
En esta etapa, el módulo de administración de sesión 568 puede proporcionar un identificador único para inserción dentro del manifiesto creado para el dispositivo de cliente 590 a fin de identificar la sesión de flujo continuo de datos asociada con el dispositivo de cliente 590 y el servidor origen 520.
En algunas modalidades, el identificador único se puede insertar en el manifiesto en una manera para incluir un identificador de sesión único (UUID) en la plantilla de solicitud URL. Por consiguiente, cuando el dispositivo de cliente 590 realiza solicitudes adicionales para fragmentos de contenido, el servidor intermedio 560 puede identificar que las solicitudes están asociadas con una sesión particular. El identificador único también se puede utilizar para determinar cual transmultiplexor 565 utilizar.
La ubicación precisa del identificador insertado puede diferir de acuerdo con el tipo de manifiesto. Por ejemplo, para algunos clientes, la plantilla de solicitud URL puede contener secuencias de parámetros al final del URL. Para otros clientes, los parámetros pueden ser insertados en el elemento [UBICACION_URL] de la plantilla de solicitud URL.
Tal como se observó antes, cada tipo de manifiesto proporciona información que describe al cliente cómo realizar futuras solicitudes ya sea para manifiestos adicionales o fragmento de contenido, además de información de temporización para asegurar una reproducción ininterrumpida (por ejemplo, duración de fragmento, tasa de transferencia de bits, etc.). Por consiguiente, cada tipo de manifiesto contiene información similar, la cual puede ser formateada en una manera diferente.
Debido a que los tamaños de fragmento y estructura de fragmento para cada protocolo pueden diferir, puede ser necesario recuperar múltiples fragmentos de contenido del servidor origen para cumplir con una solicitud de cliente particular. Por ejemplo, en algunos protocolos, cada fragmento contiene únicamente un sólo tipo de medio (por ejemplo, únicamente video o únicamente audio). Por consiguiente, para lograr la reproducción del contenido audiovisual se requiere recuperar tanto un fragmento de video como un fragmento de audio. Sin embargo, en algunos otros protocolos, tanto el contenido de video como de audio puede ser multiplexado junto en un solo fragmento, requiriendo asi únicamente el fragmento solo para lograr la reproducción.
Haciendo referencia ahora a la figura 7, se ilustra un fragmento de audio y video ejemplar mapeando en un eje de tiempo. El producto de contenido 710 está compuesto de cuatro fragmentos de video que tienen una duración de 5 segundos cada uno, y cinco fragmentos de audio que tienen una duración de 4 segundos cada uno. En contraste, el producto de contenido 750 está compuesto de cuatro fragmentos de contenido que tienen una duración de 5 segundos cada uno, donde cada fragmento de contenido contiene datos de audio y video intercalados.
Se apreciará que cuando diferentes tipos de multimedia son separados en fragmentos separados respectivos (por ejemplo, audio y video), los fragmentos pueden no tener la misma duración. Sin embargo, en un formato intercalado, se puede esperar que todas las muestras de audio y video para una duración determinada de un producto de contenido estén contenidas en un solo fragmento particular.
Por consiguiente, cuando se convierte entre manifiestos que representan un modelo segregado contra un modelo intercalado, un módulo de mapeo de transmultiplexor pudiera necesitar que se determine cómo representar la temporización y duración de los diversos fragmentos de contenido en el manifiesto objetivo.
En algunas modalidades, los fragmentos de video se pueden elegir como una fuente de temporización primaria. Por consiguiente, si una conversión de transmultiplexión es de una fuente segregada a una fuente intercalada, entonces la duración de los fragmentos intercalados estaría basada en la duración de los fragmentos de video en la fuente segregada. Por el contrario, cuando una conversión de transmultiplexión es desde una fuente intercalada a una fuente segregada, la duración del fragmento intercalado se puede utilizar tanto para el fragmento de audio como de video.
Para ayudar en un módulo de mapeo de transmultiplexor 565 en la traslación de solicitudes de fragmento desde un formato de entrega de cliente al formato de entrega origen, se pueden crear una o más tablas de mapeo de fragmentos de sesión para cada sesión cuando se genera un manifiesto inicial para un cliente. Tal como se describió antes, cada fragmento representa un lapso de tiempo específico dentro de un producto de contenido (activo multimedia) y los manifiestos que son proporcionados al cliente describen cómo crear una solicitud de fragmento para cada lapso de tiempo especifico.
Las tablas de Mapeo de Fragmentos de sesión pueden comprender una linea de tiempo de los fragmentos desde el manifiesto origen y una linea de tiempo correspondiente de los fragmentos en el manifiesto de cliente. Un par ejemplar de tablas de mapeo de fragmentos de sesión se muestra a continuación en las Tablas 5A y 5B. Por consiguiente, cada módulo de mapeo puede determinar cuáles fragmentos solicitar del servidor origen para cumplir con una solicitud del dispositivo de cliente.
TABLA 5A TABLA 5B Además, un módulo de apeo de transmultiplexor 565 puede seleccionar diferentes duraciones de fragmento de diferente longitud para entrega al cliente, lo cual no necesita estar basado en la duración del fragmento origen. Por ejemplo, el manifiesto de cliente puede definir fragmentos con una duración de 10 segundos, mientras que el manifiesto origen puede contener fragmentos con una duración de 2 segundos. Utilizando las tablas de mapeo de fragmentos de sesión, el módulo de mapeo entonces puede determinar que éste necesitará recuperar 5 fragmentos origen a fin de dar servicio a una sola solicitud de fragmento de cliente.
Una vez que se identifican y recuperan los fragmentos de contenido necesarios, el proceso de convertir los formatos de contenedor se puede ejecutar a través de un módulo de conversión de contenedor del trans ultiplexor 565. La conversión del contenedor de fragmento conceptualmente se puede dividir en dos partes: extracción y empaque.
Para extracción, los fragmentos recuperados del servidor origen pueden ser "desmultiplexados" del formato de contenedor origen en un conjunto de descriptores de multimedia (es decir, parámetros que aplican a todas las muestras en el contenedor), y las muestras sin procesar de audio y video y su temporización asociada (PTS y DTS). Para empaque, los datos extraídos pueden ser colocados en una estructura de datos genérica, la cual fácilmente puede ser "multiplexados" en el formato de contenedor objetivo.
Ejemplos de descriptores de medios se muestran en las siguientes tablas 6 a 8.
TABLA 6 TABLA 7 TABLA 8 Cada uno de los diversos protocolos de corriente y formatos de entrega soportan un formato de contenedor especifico para fragmentos de contenido. Por ejemplo, el formato de contenedor de Flujo Continuo de Datos Suave de Microsoft está basado en el formato ISO .mp4, donde los fragmentos están contenidos en un "MOOF" (fragmento de película). Adobe también utiliza un formato de contenedor basado en el formato ISO .mp4, pero además especifica que las muestras tienen información adicional con base en adiciones de marca propia al formato ISO. Apple utiliza un formato de contenedor de corriente de transporte MPEG-2. Por consiguiente, cada transmultiplexor 565 tiene un módulo de conversión de contenedor que está adaptado al tipo de contenedores requeridos para extraer y empacar, a fin de cumplir con los requerimientos del cliente y los formatos de contenedor origen (y por lo tanto los formatos de entrega).
Se apreciará que aunque se hace referencia en esta descripción al contenido de audio y video, existen otros tipos de contenido (por ejemplo, subtítulos) que también se pueden procesar de manera similar.
Haciendo referencia nuevamente a la figura 6, en 620, el dispositivo de cliente 590 recibe el manifiesto de cliente y determina cuales fragmentos de contenido recuperar. En 625, el dispositivo de cliente 590 transmite una solicitud de fragmento de cliente. La solicitud de fragmento de cliente es procesada por el módulo de mapeo del transmultiplexor 565 para generar una solicitud de fragmento origen en el formato de entrega origen, el cual es transmitido al servidor origen 520 en 640. En algunas modalidades, una solicitud de fragmentos de cliente puede corresponder a más de una solicitud de fragmentos origen, tal como aquí se describe. De igual manera, una sola solicitud de fragmentos origen puede corresponder a más de una solicitud de cliente.
En 645, el servidor origen 520 transmite el fragmento de contenido solicitado al transmultiplexor 565. El módulo de conversión de contenedor del transmultiplexor 565 convierte el fragmento de contenido del formato de entrega origen al formato de entrega de cliente. La conversión puede involucrar la transmultiplexión y reempaque del contenido, tal como aquí se describe.
En 660, el servidor intermedio 560 transmite el fragmento de contenido solicitado al dispositivo de cliente 590 utilizando el formato de entrega de cliente.
Debido a la naturaleza sin estado del protocolo HTTP y los protocolos de corriente adaptable basados en HTTP asociados, no hay una capacidad inherente en el protocolo HTTP por conocer el estado exacto de alguna sesión sencilla. Por ejemplo, no hay mensajería desde el cliente al servidor para indicar si un cliente ha pausado una sesión o de otra manera ha finalizado la sesión (por ejemplo, ha cerrado una ventana de navegador Web). En ambos casos, un cliente simplemente deja de solicitar datos adicionales. Esto crea un reto en la identificación respecto a cuándo ha finalizado una sesión.
En algunos casos, un cliente puede estar en un estado de pausa casi indefinidamente, de manera que no hay un evento específico en el que se pueda basar para identificar cuándo ha finalizado de forma permanente una sesión. Debido a que un servidor intermedio no puede mantener un número indefinido de sesiones de cliente en un estado activo en perpetuidad, debe haber un método para identificar sesiones finalizadas o "muertas" para permitir que recursos de almacenamiento y memoria sean reutilizados para nuevas sesiones.
En una modalidad, el módulo de administración de sesión 568 administra una tabla que identifica el estado de todas las sesiones de cliente abiertas. El módulo de administración de sesión 568 periódicamente puede, después de un periodo predeterminado, "expirar" todas las sesiones activas, marcándolas como estando en un estado de tiempo fuera. Si una sesión que ahora está en un estado de tiempo fuera realiza una solicitud de fragmento adicional antes del siguiente evento de tiempo fuera periódico, la sesión nuevamente puede ser marcada como "activa". Por el contrario, si una sesión ya está en un estado de tiempo fuera y no ha hecho solicitudes de fragmentos adicionales en el momento en que vuelve a ocurrir el evento de "tiempo fuera", la sesión puede ser movida a una cola de inactividad y ser marcada como un candidato para eliminación. La cola de inactividad se puede basar en un enfoque de primero en entrar primero en salir (FIFO), de manera que las sesiones que han estado inactivas durante más tiempo son aquellas que se retirarán primero. Sin embargo, las sesiones que son candidatos para eliminación no necesitan ser retiradas hasta que el servidor intermedio 160 determine que los recursos de sesión se han agotado.
Cualquier sesión que sea marcada como "tiempo fuera" o "inactiva" se pueden marcar como "activa" nuevamente en caso que una solicitud de fragmento adicional asociada con esa sesión sea recibida previa a que se elimine la sesión.
Haciendo referencia ahora a la figura 8, se ilustra un diagrama de estado ejemplar que puede ser utilizado por el módulo de administración de sesión de un servidor intermedio para representar el estado de una sesión de cliente.
Cuando en 810 se recibe una solicitud de manifiesto de cliente, la sesión de cliente es iniciada y marcada como inicializando. Posteriormente, si se recibe una solicitud de fragmento o solicitud de manifiesto adicional asociada con la sesión, el estado de sesión es marcado como activo en 820. Si no se reciben solicitudes adicionales, la sesión es marcada como tiempo fuera 830.
En 830 y 840, un proceso periódico cambia el estado de todas las sesiones en el estado de inicialización y el estado activo a tiempo fuera. Sin embargo, si se recibe una solicitud de fragmento adicional en asociación con una sesión (en 850), la sesión asociada puede ser marcada como activa nuevamente.
En 860, un proceso periódico cambia el estado de todas las sesiones en el estado de tiempo fuera a candidatos de eliminación. Sin embargo, si se recibe una solicitud de fragmento adicional en asociación con una sesión (en 870), la sesión asociada puede ser marcada como activa una vez más.
Si en 880 el servidor intermedio 560 determina que requiere recursos de sesión (por ejemplo, memoria) para dar servicio a una nueva sesión, y no hay sesiones anteriores marcadas como candidatos para eliminación, entonces la sesión existente que es un candidato para eliminación puede ser eliminada.
En algunas modalidades, el servidor intermedio 560 puede utilizar la temporización de una o más solicitudes de fraqmento para determinar un estado de sesión del cliente de la sesión de flujo continuo de datos del cliente. Por ejemplo, si la temporización de solicitud de fragmento muestra que los fragmentos solicitados tienen códigos de tiempo que están separados por una cantidad de tiempo mayor de la que en realidad ha transcurrido o que los fragmentos fueron recuperados fuera de secuencia, entonces el servidor intermedio 560 puede inferir que el cliente ejecutó una operación de búsqueda.
De manera similar, si la temporización determina que un tiempo transcurrido real excede un tiempo de reproducción de una o más solicitudes de fragmento, entonces el servidor intermedio 560 puede inferir que se ha ejecutado una operación de reproducción no estándar. En general, las operaciones de reproducción no estándar son operaciones que tiene como resultado la reproducción del contenido diferente a la velocidad de cuadro ordinaria. Ejemplos de operaciones de reproducción no estándar incluyen un evento de "pausa", un evento de "adelantar", un evento de "rebobinar", un evento de "movimiento lento", y similares.
Haciendo referencia ahora a la figura 9, se ilustra un flujo de llamada detallado ejemplar para el servidor intermedio de la figura 5.
El flujo de llamada 900 generalmente ilustra un flujo de mensaje ejemplar entre los componentes de un servidor intermedio, tal como el servidor intermedio 560. En algunas modalidades, el modelo fundamental puede ser sin bloqueo, ya que los componentes utilizan un modelo de solicitud/respuesta para comunicarse entre si y por lo tanto nunca están en un estado donde están "bloqueados" a la espera de una respuesta.
En algunas modalidades, el generador de contenido 564 se puede configurar para mantener los enlaces entre estos componentes mientras que el módulo de administración de sesión 568 se puede configurar para administrar los estados y políticas de conexión generales.
Tal como se muestra en la figura 9, hay dos flujos de mensaje extremo-a-extremo primarios. Un primer flujo de mensaje sigue desde una solicitud inicial para información de manifiesto. Un segundo flujo de mensaje sigue desde solicitudes para manifiestos o fragmentos de medios adicionales.
Los flujos de mensaje comienzan en 905, con una solicitud de OBTENER HTTP desde el cliente utilizando el formato de entrega de cliente. En 910, el generador de contenido 564 determina cuál transmultiplexor 565 debiera manejar la solicitud con base en el formato de entrega de cliente y pasa la solicitud al módulo de mapeo del transmultiplexor apropiado. Si un transmultiplexor apropiado no puede ser encontrado en 912, el flujo de mensaje puede proceder a emitir un mensaje de error 945. Si se encuentra un transmultiplexor apropiado, el flujo de mensaje procede a 915.
En 915, el transmultiplexor determina si la solicitud HTTP es una solicitud de un manifiesto inicial, o una solicitud posterior. Si la solicitud es una solicitud inicial, el flujo procede a 920 donde se crea un identificador único y contexto de sesión (por ejemplo, información de estado), tal como aguí se describió con lo cual el flujo procede a 935.
Si la solicitud no es una solicitud inicial, un identificador único es extraído de la solicitud HTTP y se utiliza para recuperar la información de estado de sesión en 925.
En 930, el transmultiplexor determina si la solicitud es para un manifiesto. Si la solicitud es para un manifiesto, el flujo procede a 935, en donde una solicitud para el manifiesto es generada por el módulo de mapeo utilizando el formato de entrega origen (por ejemplo, una solicitud intermedia para el manifiesto), y es transmitida al servidor origen.
En 940, el transmultiplexor determina si se recibió una respuesta exitosa a la solicitud. Si se recibió un error, el transmultiplexor identifica que un mensaje de error debiera ser entregado al dispositivo de cliente en 945, y transmite el mensaje de error en un mensaje de RESPUESTA HTTP correspondiente en 950.
Si el manifiesto fue recibido con éxito, el módulo de conversión de contenedor de transmultiplexor convierte el manifiesto en 990, tal como aquí se describió e identifica que el manifiesto transmultiplexado debiera ser entregado al dispositivo de cliente en 995. El manifiesto transmultiplexado es transmitido en un mensaje de RESPUESTA HTTP en 999.
Si en 930 el transmultiplexor determina que la solicitud no es para un manifiesto, el flujo procede a 955 para transmultiplexar la solicitud en el protocolo del servidor origen, generando asi una solicitud intermedia para el fragmento de contenido, y transmitir la solicitud intermedia para el fragmento (o fragmentos) de contenido al servidor origen.
En 960, el transmultiplexor determina si se recibió una respuesta exitosa a la solicitud. Si se recibió un error, el transmultiplexor identifica que un mensaje de error debiera ser entregado al dispositivo de cliente en 980, y transmite el mensaje de error en un mensaje de RESPUESTA HTTP correspondiente en 985.
Si el fragmento de contenido fue recibido con éxito, el módulo de conversión de contenedor del transmultiplexor convierte el fragmento (o fragmentos) en 965, por ejemplo desempacando los fragmentos del formato de contenedor origen, e identifica que el fragmento (o fragmentos) de contenido transmultiplexado debiera ser entregado al dispositivo de cliente en 970. El fragmento (o fragmentos) de contenido transmultiplexado puede ser empacado en el formato de contenedor de cliente (mientras que permanece en el formato de codificación origen) y transmitido, utilizando el formato de entrega de cliente, en un mensaje de RESPUESTA HTTP correspondiente en 975.
El empaque puede comprender empacar múltiples fragmentos en el formato de contenedor de cliente reensamblando los fragmentos de contenido, por ejemplo donde el formato de contenedor origen y el formato de contenedor de cliente tienen como resultado segmentos de diferente longitud gue comprenden varios fragmentos.
Haciendo referencia ahora a la figura 10, se ilustra un flujo de llamada ejemplar 1000 para aceptar una solicitud de manifiesto inicial.
El flujo de llamada 1000 comienza en 1001, cuando el servidor HTTP 566 recibe una solicitud de OBTENER HTTP para un manifiesto de un dispositivo de cliente 590.
En 1002, el servidor HTTP 566 revisa la validez de la solicitud y, en caso que la solicitud sea válida, reenvía el mensaje de solicitud al generador de contenido 564 con el URL solicitado. El mensaje de solicitud reenviado puede contener detalles del mensaje tal como un identificador de solicitud, solicitud URL, dirección IP de dispositivo de cliente, identificador de cliente (por ejemplo, cookie), agente de usuario, puerto TCP de cliente, y tiempo de solicitud.
En 1003, el generador de contenido 564, por ejemplo, el módulo de mapeo del transmultiplexor 565, determina que la solicitud es para una solicitud de manifiesto inicial, y notifica al módulo de administración de sesión 568. La notificación puede contener detalles tales como el identificador de solicitud, identificador de contexto de sesión generado por el generador de contenido 564, sello de hora, tipo de protocolo de cliente, dirección IP de cliente y la solicitud URL.
El módulo de administración de sesión 568 determina si puede permitir la sesión (por ejemplo, suficientes recursos están disponibles, el cliente está autorizado, etc.) y envía un mensaje de autorización al generador de contenido 564 en 1004. El mensaje de autorización puede comprender el identificador de solicitud, el identificador de contexto de sesión generado por el generador de contenido 564, un identificador único (UUID) para la sesión generada por el módulo de administración de sesión 568, un código de respuesta, un identificador correspondiente al protocolo de servidor origen, y una lista de patrones de solicitud para el módulo de mapeo del transmultiplexor 565 para intentar el uso cuando se formula una solicitud.
En 1005, el módulo de mapeo del transmultiplexor 565 crea una solicitud apropiada utilizando el protocolo origen y reenvía la solicitud generada gue comprende el identificador de solicitud y una o más solicitudes de URL al cliente HTTP 562. El identificador de solicitud se puede utilizar para correlacionar respuestas con el transmultiplexor 565.
En 1006, el cliente HTTP 562 determina la dirección IP apropiada para el servidor origen 520 y transmite el mensaje de OBTENER HTTP con la solicitud generada para un manifiesto origen.
En 1007, el servidor origen 520 responde con el archivo de manifiesto origen solicitado en el formato de entrega origen.
El cliente HTTP 563 transmite o reenvía el manifiesto solicitado al generador de contenido 564, en 1008. La respuesta puede comprender un identificador de solicitud, una o más solicitudes y códigos de estado correspondientes a cada solicitud.
En 1008, el generador de contenido 564 (y un módulo de conversión de contenedor del transmultiplexor apropiado) genera un archivo de manifiesto de cliente en el formato de entrega de cliente desde el archivo de manifiesto recibido en el formato de entrega origen, y reenvía el manifiesto del cliente al servidor HTTP 566.
Finalmente, en 1010 el servidor HTTP 566 transmite el manifiesto de cliente al dispositivo de cliente 590.
Haciendo referencia ahora a la figura 11, se ilustra un flujo de llamada ejemplar 1100 para una solicitud de manifiesto inicial rechazada.
El flujo de llamada 1100 comienza en 1101, cuando el servidor HTTP 566 recibe una solicitud de OBTENER HTTP para un manifiesto desde un dispositivo de cliente 590. La solicitud está en el formato de entrega de cliente.
En 1102, el servidor HTTP 566 revisa la validez de la solicitud y, en caso que la solicitud sea válida, reenvía el mensaje de solicitud al generador de contenido 564 con el URL solicitado.
En 1103, el generador de contenido 564 determina que la solicitud es para una solicitud de manifiesto inicial, y notifica al módulo de administración de sesión 568.
El módulo de administración de sesión 568 determina que no puede permitir la sesión (por ejemplo, no hay suficientes recursos disponibles, el cliente no está autorizado, etc.) y envía un mensaje de no autorización al generador de contenido 564, en 1104.
En 1105, el generador de contenido 564 crea un mensaje de rechazo (por ejemplo, mensaje de error HTTP) y reenvía el mensaje al servidor HTTP 566.
Finalmente, en 1106, el servidor HTTP 566 transmite el mensaje de rechazo al dispositivo de cliente 590.
Haciendo referencia ahora a la figura 12, se ilustra un flujo de llamada ejemplar 1200 para una solicitud de manifiesto inicial que contiene una dirección de servidor origen inválida.
El flujo de llamada 1200 comienza en 1201, cuando el servidor HTTP 566 recibe una solicitud de obtener HTTP para un manifiesto desde un dispositivo de cliente 590. La solicitud está en el formato de entrega de cliente.
En 1202, el servidor HTTP 566 revisa la validez de la solicitud y, en caso que la solicitud sea válida, reenvía el mensaje de solicitud al generador de contenido 564 con el URL solicitado.
El 1203, el generador de contenido 564 determina que la solicitud es para una solicitud de manifiesto inicial, y notifica al módulo de administración de sesión 568.
El módulo de administración de sesión 568 determina si puede permitir la sesión (por ejemplo, hay suficientes recursos disponibles, -el cliente está autorizado, etc.) y envía un mensaje de autorización al generador de contenido 564, en 1204.
En 1205, el generador de contenido 564 crea una solicitud apropiada utilizando el protocolo origen y reenvía la solicitud generada al cliente HTTP 562.
En 1206, el cliente HTTP 562 determina que no se puede conectar al servidor origen 520 (por ejemplo, debido a que la solicitud contiene una dirección de servidor origen inválida) y envía un mensaje de error al generador de contenido 564 con un estado indicando una falla de conexión con el servidor origen.
En 1207, el generador de contenido 564 determina que la sesión de cliente debiera ser eliminada y envía un mensaje de eliminación al módulo de administración de sesión 568, de manera que se pueden reclamar los recursos de la sesión.
En 1208, el generador de contenido 564 envía un mensaje de error al servidor HTTP 566 con un código de error HTTP apropiado.
Finalmente, en 1209, el servidor HTTP 566 transmite el mensaje de error al dispositivo de cliente 590.
Haciendo referencia ahora a la figura 13, se ilustra un flujo de llamada ejemplar 1300 para una solicitud de fragmento válida.
El flujo de llamada 1300 comienza en 1301, cuando el servidor HTTP 566 recibe una solicitud de OBTENER HTTP para un fragmento de contenido desde un dispositivo de cliente 590.
En 1302, el servidor HTTP 566 revisa la validez de la solicitud y, en caso que la solicitud sea válida, reenvía el mensaje de solicitud al generador de contenido 564 con el URL solicitado.
En 1303, el generador de contenido 564 determina que la solicitud es para el fragmento de contenido, extrae el ID de sesión única y notifica al módulo de administración de sesión 568 respecto del identificador de sesión única contenido en la solicitud.
El módulo de administración de sesión 568 identifica la sesión y envía un mensaje que contiene detalles de la sesión (por ejemplo, políticas, estado, etc.) al generador de contenido 564, en 1304.
En 1305, el generador de contenido 564 crea una solicitud apropiada utilizando el protocolo origen y reenvía la solicitud generada al cliente HTTP 562.
En 1306, el cliente HTTP 562 determina la dirección IP apropiada para el servidor origen 520 y transmite un mensaje de obtener HTTP con la solicitud generada para el fragmento de contenido solicitado.
En 1307 el servidor origen 520 responde con el fragmento de contenido solicitado.
El cliente HTTP 562 transmite o reenvía el fragmento de contenido solicitado al generador de contenido 564, en 1308.
En 1309, el generador de contenido 564 (y el transmultiplexor apropiado) transmite información referente al fragmento de contenido (por ejemplo, número de bytes, etc.) al módulo de administración de sesión 568. La información transmitida puede incluir el identificador de sesión único (UUID) para la sesión, número de bytes enviados para este fragmento, duración del fragmento de contenido enviado, tasa de transferencia de bytes del fragmento de contenido enviado, y posición en el producto de contenido (por ejemplo, segundos desde el inicio del video que representa el fragmento de contenido actual) En 1310, el generador de contenido 564 (y el transmultiplexor apropiado) transmultiplexa el fragmento de contenido recibido desde el protocolo origen al protocolo de cliente, y reenvía el fragmento de contenido transmultiplexado al servidor HTTP 566.
Finalmente, en 1311, el servidor HTTP 566 transmite el fragmento de contenido transmultiplexado al dispositivo de cliente 590.
Haciendo referencia ahora a la figura 14, se ilustra un flujo de llamada ejemplar 1400 para una solicitud de fragmento inválida.
El flujo de llamada 1400 comienza en 1401, cuando el servidor HTTP 566 recibe una solicitud de OBTENER HTTP para un fragmento de contenido desde un dispositivo de cliente 590.
En 1402, el servidor HTTP 566 revisa la validez de la solicitud y, en caso que la solicitud sea valida, reenvía el mensaje de solicitud al generador de contenido 564 con el URL solicitado.
En 1403, el generador de contenido 564 determina que la solicitud es una solicitud de fragmento inválida y envía un mensaje de rechazo al servidor HTTP con un código de error HTTP apropiado.
Finalmente, en 1404, el servidor HTTP 566 transmite el mensaje de rechazo al dispositivo de cliente 590.
Haciendo referencia ahora a la figura 15, se ilustra un flujo de llamada ejemplar 1500 para una solicitud de fragmento de contenido que contiene un identificador de sesión inválido (UUID).
El flujo de llamada 1500 comienza en 1501, cuando el servidor HTTP 566 recibe una solicitud de OBTENER HTTP para un fragmento de contenido de un dispositivo de cliente 590.
En 1502, el servidor HTTP 566 revisa la validez de la solicitud y, en caso que la solicitud sea válida, reenvía el mensaje de solicitud al generador de contenido 564 con el URL solicitado.
En 1503, el generador de contenido 564 determina que la solicitud es para el fragmento de contenido, y notifica al módulo de administración de sesión 568 del identificador de sesión único contenido en la solicitud.
El módulo de administración de sesión 568 intente identificar una sesión correspondiente al identificador único y, en caso que no exista, envía un mensaje de error (por ejemplo, sesión no encontrada) al generador de contenido 564, en 1504.
En 1505, el generador de contenido 564 crea un mensaje de error (por ejemplo, mensaje de error HTTP) y reenvía el mensaje al servidor HTTP 566.
Finalmente, en 1506, el servidor HTTP 566 transmite el mensaje de error al dispositivo de cliente 590.
Tal como aqui se describió, el enfoque proxy de traslación inversa permite la conversión de diferentes protocolos de corriente adaptable sobre una base "por solicitud" y "en el vuelo". Por consiguiente, el enfoque descrito se ha optimizado para transmultiplexar contenido sobre una base de solicitud por fragmento, mientras que se evidencia la necesidad de transmultiplexar fragmentos de contenido adicionales hasta que en realidad son solicitados. Capacidades adicionales incluyen definir dinámicamente una respuesta con base en el contexto de sesión para optimizar QoE. Por ejemplo, si se ha establecido una política para limitar el ancho de banda para un cliente particular, y el cliente solicita una tasa de transferencia de bits superior, el servidor intermedio puede recuperar únicamente aquellos fragmentos que coinciden con la política del ancho de banda.
Se apreciará que se establecen numerosos detalles específicos para proporcionar un completo entendimiento de las modalidades ejemplares aquí descritas. Sin embargo, aquellos expertos en la téenica entenderán que las modalidades aquí descritas se pueden practicar sin estos detalles específicos. En otros casos, métodos, procedimientos y componentes bien definidos no se han descrito a detalle para no oscurecer las modalidades aquí descritas. Por consiguiente, lo que se ha descrito antes ha pretendido ser ilustrativo de la invención y no limitativo y aquellos expertos en la téenica entenderán que se pueden realizar otras variaciones y modificaciones sin apartarse del alcance de la invención conforme a lo definido en las reivindicaciones anexas al presente.

Claims (28)

NOVEDAD DE LA INVENCION Habiendo descrito la presente invención, se considera como una novedad y, por lo tanto, se reclama como propiedad lo contenido en las siguientes: REIVINDICACIONES
1.- Un sistema para entregar un producto de contenido multimedia para flujo continuo de datos desde un servidor origen a un dispositivo de cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el sistema comprende: a) un módulo de mapeo configurado para recibir una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos utilizando un formato de entrega de cliente, determinar que la solicitud del cliente está en un formato de entrega de cliente y generar una solicitud intermedia en el formato de entrega origen que corresponde a la solicitud del cliente; b) un módulo de cliente intermedio configurado para transmitir la solicitud intermedia al servidor y recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondientes a la parte solicitada del producto de contenido multimedia para flujo continuo de datos, en donde el subconjunto es recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen; c) un módulo de conversión de contenedor configurado para desempacar el subconjunto del formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente permanecen codificados en el formato de codificación origen; y d) un módulo de servidor intermedio configurado para transmitir al cliente el producto de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente utilizando el formato de entrega de cliente.
2.- El sistema de conformidad con la reivindicación 1, caracterizado porque el módulo de conversión de contenedor empaca los productos de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente reensamblando la primera pluralidad de fragmentos de contenido en una segunda pluralidad de fragmentos contenido, en donde la segunda pluralidad de fragmentos de contenido tiene duraciones diferentes que la primera pluralidad de fragmentos de contenido.
3.- El sistema de conformidad con la reivindicación 1 ó 2, caracterizado porque el módulo de mapeo determina que el servidor origen está configurado para transmitir utilizando el formato de entrega origen transmitiendo una o más solicitudes utilizando formatos de entrega predeterminados y determinando si se recibe una respuesta exitosa.
4.- El sistema de conformidad con cualquiera de las reivindicaciones l a 3, caracterizado porque el módulo de mapeo determina que la solicitud de cliente está en el formato de entrega de cliente comparando la solicitud del cliente con una pluralidad de patrones de solicitud predeterminados.
5.- El sistema de conformidad con cualquiera de las reivindicaciones 1 a 4, caracterizado porque el servidor intermedio además comprende un módulo de administración de sesión configurado para iniciar una sesión de flujo continuo de datos cuando se recibe la solicitud del cliente.
6.- El sistema de conformidad con la reivindicación 5, caracterizado porque el módulo de administración de sesión además está configurado para determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando solicitudes de fragmento desde el cliente.
7.- Un método para entregar a un cliente un producto de contenido multimedia para flujo continuo de datos desde un servidor origen, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el método comprende: a) recibir una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos utilizando un formato de entrega de cliente; b) determinar que la solicitud del cliente está en el formato de entrega de cliente; c) generar una solicitud intermedia correspondiente a la solicitud de cliente, en donde la solicitud origen está en el formato de entrega origen; d) transmitir la solicitud intermedia al servidor; e) recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondiente a la parte solicitada del producto de contenido multimedia para flujo continuo de datos, en donde el subconjunto es recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen; f) desempacar el subconjunto del formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente permanecen codificados en el formato de codificación origen; y g) transmitir al cliente el producto de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente utilizando el formato de entrega de cliente.
8.- El método de conformidad con la reivindicación 7, caracterizado porque el empaque se ejecuta reensamblando la primera pluralidad de fragmentos de contenido en una segunda pluralidad de fragmentos de contenido, en donde la segunda pluralidad de fragmentos de contenido tiene duraciones diferentes que la primera pluralidad de fragmentos de contenido.
9.- El método de conformidad con la reivindicación 7 u 8, que además comprende determinar que el servidor origen está configurado para transmitir utilizando el formato de entrega origen transmitiendo una o más solicitudes utilizando formatos de entrega predeterminados y determinando si se recibe una respuesta exitosa.
10.- El método de conformidad con cualquiera de las reivindicaciones 7 a 9, que además comprende determinar que la solicitud del cliente está en el formato de entrega de cliente comparando la solicitud del cliente con una pluralidad de patrones de solicitud predeterminados.
11.- El método de conformidad con cualquiera de las reivindicaciones 7 a 10, que además comprende iniciar una sesión de flujo continuo de datos cuando se recibe la solicitud del cliente.
12.- El método de conformidad con la reivindicación 11, que además comprende determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando las solicitudes de fragmento desde el cliente.
13.- Un sistema para entregar un producto de contenido multimedia para flujo continuo de datos desde un servidor origen a un dispositivo de cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el sistema comprende: a) un módulo de mapeo configurado para recibir al menos una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos y generar una solicitud intermedia que corresponda al menos a una solicitud de cliente; b) un módulo de administración de sesión configurado para iniciar una sesión de flujo continuo de datos cuando se recibe al menos una solicitud de cliente, el módulo de administración de sesión además está configurado para determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando al menos una solicitud de cliente; c) un módulo de cliente intermedio configurado para transmitir la solicitud intermedia al servidor y recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondiente a la parte solicitada del producto de contenido multimedia para flujo continuo de datos; d) un módulo de servidor intermedio configurado para transmitir el producto de contenido multimedia para flujo continuo de datos al cliente.
14.- El sistema de conformidad con la reivindicación 13, caracterizado porgue el módulo de mapeo está configurar para recibir la solicitud de cliente utilizando un formato de entrega de cliente y determinar que la solicitud de cliente está en el formato de entrega de cliente, en donde la solicitud intermedia está en el formato de entrega origen, en donde el subconjunto de la primera pluralidad de fragmentos de contenido puede es recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen, comprendiendo además un módulo de conversión de contenedor configurado para desempacar el subconjunto del formato de contenedor origen y empacar el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente permanecen codificados en el formato de codificación origen, en donde el módulo de servidor intermedio está configurado para transmitir al cliente el producto de contenido multimedia para flujo continuo de datos en el formato de contenedor de cliente utilizando del formato de entrega de cliente.
15.- El sistema de conformidad con la reivindicación 13 ó 14, caracterizado porgue el módulo de administración de sesión además está configurado para identificar el estado de todas las sesiones de cliente abiertas.
16.- El sistema de conformidad con cualquiera de las reivindicaciones 13 a 15, caracterizado porque el módulo de administración de sesión además está configurado para marcar el estado de sesión como inactiva después de un periodo de tiempo fuera predeterminado
17.- El sistema de conformidad con la reivindicación 16, caracterizado porque el módulo de administración de sesión además está configurado para marcar el estado de sesión como activo cuando se recibe una solicitud de fragmento adicional asociada con la sesión de cliente.
18.- El sistema de conformidad con cualquiera de las reivindicaciones 13 a 17, caracterizado porque al menos una solicitud de cliente comprende una pluralidad de solicitudes de cliente, y en donde el estado de sesión es determinado con base en una temporización de la pluralidad de solicitudes de cliente.
19.- El sistema de conformidad con la reivindicación 18, caracterizado porque cuando la temporización indica que la pluralidad de solicitudes de cliente son para fragmentos que están fuera de secuencia, entonces se determina una operación de búsqueda.
20.- El sistema de conformidad con la reivindicación 18, caracterizado porque cuando la temporización indica que el tiempo transcurrido real excede un tiempo de reproducción de fragmentos solicitados en la pluralidad de solicitudes de cliente, entonces se determina una operación de reproducción no estándar.
21.- Un método para entregar un articulo de contenido multimedia para flujo continuo de datos desde un servidor origen a un dispositivo de cliente, en donde el servidor origen tiene un formato de contenedor origen y un formato de entrega origen para el contenido multimedia para flujo continuo de datos, y en donde el contenido multimedia para flujo continuo de datos comprende una primera pluralidad de fragmentos de contenido codificados en un formato de codificación origen, el sistema comprende: a) recibir al menos una solicitud de cliente desde el cliente para al menos una parte solicitada del producto de contenido multimedia para flujo continuo de datos; b) generar una solicitud intermedia que corresponda al menos a una solicitud de cliente; c) iniciar una sesión de flujo continuo de datos cuando se recibe al menos una solicitud de cliente; d) determinar un estado de sesión del cliente para la sesión de flujo continuo de datos monitoreando al menos una solicitud de cliente; e) transmitir la solicitud intermedia al servidor; f) recibir un subconjunto de la primera pluralidad de fragmentos de contenido correspondiente a la parte solicitada del producto de contenido multimedia para flujo continuo de datos; y g) transmitir al cliente el producto de contenido multimedia para flujo continuo de datos.
22.- El método de conformidad con la reivindicación 21, caracterizado porque la solicitud de cliente es recibida utilizando un formato de entrega de cliente, en donde la solicitud intermedia está en el formato de entrega origen, en donde el subconjunto de la primera pluralidad de fragmentos de contenido es recibido en el formato de contenedor origen desde el servidor origen utilizando el formato de entrega origen, comprendiendo además el desempaque del subconjunto a partir del formato de contenedor origen y empacando el subconjunto en un formato de contenedor de cliente, en donde los fragmentos de contenido en el subconjunto que están empacados en el formato de contenedor de cliente permanecen codificados en el formato de codificación origen, y en donde el producto de contenido multimedia para flujo continuo de datos es transmitido al cliente en el formato de contenedor de cliente utilizando el formato de entrega de cliente.
23.- El método de conformidad con la reivindicación 21 ó 22, que además comprende identificar el estado de todas las sesiones de cliente abiertas.
24.- El método de conformidad con cualquiera de las reivindicaciones 21 a 23, que además comprende marcar el estado de sesión como inactivo después de un periodo de tiempo fuera predeterminado.
25.- El método de conformidad con la reivindicación 24, que además comprende marcar el estado de sesión como activo cuando se recibe una solicitud de fragmento adicional asociada con la sesión de cliente.
26.- El método de conformidad con cualquiera de las reivindicaciones 21 a 25, caracterizado porque al menos una solicitud de cliente comprende una pluralidad de solicitudes de cliente, y en donde el estado de sesión es determinado con base en una temporización de la pluralidad de solicitudes de cliente.
27.- El método de conformidad con la reivindicación 26, caracterizado porque cuando la temporización indica que la pluralidad de solicitudes de cliente son para fragmentos que están fuera de secuencia, entonces se determina una operación de búsqueda.
28.- El método de conformidad con la reivindicación 26, caracterizado porque cuando la temporización indica que el tiempo transcurrido real excede un tiempo de reproducción de fragmentos solicitados en la pluralidad de solicitudes de cliente, entonces se determina una operación de reproducción no estándar.
MX2014012361A 2012-04-12 2013-04-10 Metodos y sistemas para transmultiplexar en tiempo real de contenido multimedia para flujo continuo de datos. MX353807B (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/445,361 US9712887B2 (en) 2012-04-12 2012-04-12 Methods and systems for real-time transmuxing of streaming media content
PCT/CA2013/000340 WO2013152426A1 (en) 2012-04-12 2013-04-10 Methods and systems for real-time transmuxing of streaming media content

Publications (2)

Publication Number Publication Date
MX2014012361A true MX2014012361A (es) 2015-05-08
MX353807B MX353807B (es) 2018-01-29

Family

ID=49326083

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2014012361A MX353807B (es) 2012-04-12 2013-04-10 Metodos y sistemas para transmultiplexar en tiempo real de contenido multimedia para flujo continuo de datos.

Country Status (7)

Country Link
US (1) US9712887B2 (es)
EP (1) EP2837196B1 (es)
JP (1) JP6014870B2 (es)
CN (1) CN104396263B (es)
CA (1) CA2870059C (es)
MX (1) MX353807B (es)
WO (1) WO2013152426A1 (es)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110264530A1 (en) 2010-04-23 2011-10-27 Bryan Santangelo Apparatus and methods for dynamic secondary content and data insertion and delivery
US9201938B2 (en) * 2012-05-21 2015-12-01 Sap Se Parameter driven data format conversion in client/server architectures
KR20140075829A (ko) * 2012-11-26 2014-06-20 한국전자통신연구원 투명 인터넷 캐시 서버와 콘텐츠 전달망을 결합한 콘텐츠 전달 시스템 및 방법
CN104956645B (zh) * 2013-01-16 2018-04-27 华为技术有限公司 自适应流中的url参数插入和添加
US9397902B2 (en) 2013-01-28 2016-07-19 Rackspace Us, Inc. Methods and systems of tracking and verifying records of system change events in a distributed network system
US9483334B2 (en) 2013-01-28 2016-11-01 Rackspace Us, Inc. Methods and systems of predictive monitoring of objects in a distributed network system
US9813307B2 (en) * 2013-01-28 2017-11-07 Rackspace Us, Inc. Methods and systems of monitoring failures in a distributed network system
US9710469B2 (en) 2013-03-15 2017-07-18 Comcast Cable Communications, Llc Efficient data distribution to multiple devices
US9681116B2 (en) * 2013-03-15 2017-06-13 Arris Enterprises, Inc. System and method for delivering 3DTV content to variety of receivers
WO2015000936A1 (en) 2013-07-03 2015-01-08 Koninklijke Kpn N.V. Streaming of segmented content
WO2015007795A1 (en) * 2013-07-16 2015-01-22 Bitmovin Gmbh Apparatus and method for cloud assisted adaptive streaming
US20150058448A1 (en) * 2013-08-21 2015-02-26 Josh Proctor Internet video streaming system
US20150067155A1 (en) * 2013-08-29 2015-03-05 Tune, Inc. Systems and methods for measuring approximate engagement of users in a software application
US10749761B1 (en) 2013-09-27 2020-08-18 Amazon Technologies, Inc. Unique user session tracking in adaptive bitrate video delivery
US10476930B2 (en) * 2014-01-06 2019-11-12 Intel IP Corporation Client/server signaling commands for dash
US10165029B2 (en) * 2014-01-31 2018-12-25 Fastly Inc. Caching and streaming of digital media content subsets
US11477262B2 (en) * 2014-02-13 2022-10-18 Koninklijke Kpn N.V. Requesting multiple chunks from a network node on the basis of a single request message
US20150256600A1 (en) * 2014-03-05 2015-09-10 Citrix Systems, Inc. Systems and methods for media format substitution
EP3123383B1 (en) * 2014-03-24 2019-08-21 Huawei Technologies Co. Ltd. System and method for partial url signing with applications to dynamic adaptive streaming
US9911460B2 (en) 2014-03-24 2018-03-06 Microsoft Technology Licensing, Llc Fast and smart video trimming at frame accuracy on generic platform
IL231685A (en) * 2014-03-24 2015-09-24 Giraffic Technologies Ltd A system and method for predicting memory reduction and network design
US10165028B2 (en) * 2014-03-25 2018-12-25 Intel Corporation Context-aware streaming of digital content
US10631070B2 (en) * 2014-05-22 2020-04-21 Idomoo Ltd System and method to generate a video on-the-fly
US10523723B2 (en) * 2014-06-06 2019-12-31 Koninklijke Kpn N.V. Method, system and various components of such a system for selecting a chunk identifier
US9692800B2 (en) * 2014-06-11 2017-06-27 Google Inc. Enhanced streaming media playback
US10028025B2 (en) 2014-09-29 2018-07-17 Time Warner Cable Enterprises Llc Apparatus and methods for enabling presence-based and use-based services
JP6572245B2 (ja) * 2015-02-04 2019-09-04 日本電信電話株式会社 体感品質最適化システム、体感品質最適化装置、レコメンド要求装置、体感品質最適化方法、レコメンド要求方法及びプログラム
JP6476995B2 (ja) * 2015-02-24 2019-03-06 沖電気工業株式会社 中継装置、コンテンツ配信システム、中継方法およびプログラム
US11076198B2 (en) 2015-05-28 2021-07-27 Idomoo Ltd. System and method to generate an interactive video on the fly
EP3311577B1 (en) * 2015-06-16 2020-05-27 Intel IP Corporation A dynamic adaptive streaming over hypertext transfer protocol (dash) assisting network element (dane) transcoding media content based on a set of metric and status messages received from the dash client and corresponding dash client device
WO2016205733A1 (en) * 2015-06-19 2016-12-22 Huawei Technologies Co., Ltd. Template uniform resource locator signing
US9954930B2 (en) 2015-08-06 2018-04-24 Airwatch Llc Generating content fragments for content distribution
US10334316B2 (en) 2015-09-18 2019-06-25 At&T Intellectual Property I, L.P. Determining a quality of experience metric based on uniform resource locator data
US10586023B2 (en) * 2016-04-21 2020-03-10 Time Warner Cable Enterprises Llc Methods and apparatus for secondary content management and fraud prevention
US10313418B2 (en) * 2016-06-20 2019-06-04 Ramp Holdings, Inc. Chunked HTTP video cache routing
US10063612B2 (en) * 2016-09-30 2018-08-28 Amazon Technologies, Inc. Request-based encoding for streaming content portions
US10652300B1 (en) * 2017-06-16 2020-05-12 Amazon Technologies, Inc. Dynamically-generated encode settings for media content
US11076177B2 (en) 2017-09-05 2021-07-27 Sonos, Inc. Grouped zones in a system with multiple media playback protocols
US10764650B2 (en) 2017-12-07 2020-09-01 At&T Intellectual Property I, L.P. Video optimization proxy system and method
US11144570B2 (en) 2018-01-26 2021-10-12 Vmware, Inc. Data ingestion by distributed-computing systems
US11016972B2 (en) 2018-01-26 2021-05-25 Vmware, Inc. Splitting a time-range query into multiple sub-queries for serial execution
US11016971B2 (en) 2018-01-26 2021-05-25 Vmware, Inc. Splitting a time-range query into multiple sub-queries for parallel execution
US10860576B2 (en) 2018-01-26 2020-12-08 Vmware, Inc. Splitting a query into native query operations and post-processing operations
US10824623B2 (en) 2018-02-28 2020-11-03 Vmware, Inc. Efficient time-range queries on databases in distributed computing systems
US11178213B2 (en) 2018-02-28 2021-11-16 Vmware, Inc. Automated configuration based deployment of stream processing pipeline
US10812332B2 (en) 2018-02-28 2020-10-20 Vmware Inc. Impartial buffering in stream processing
US10595055B2 (en) * 2018-04-23 2020-03-17 Amazon Technologies, Inc. Server-side insertion of media fragments
KR20240033297A (ko) * 2018-09-17 2024-03-12 구글 엘엘씨 매니페스트리스 스트리밍 미디어 콘텐츠를 전달하기 위한 방법들, 시스템들, 및 매체들
CN109327511B (zh) * 2018-09-18 2021-05-28 网宿科技股份有限公司 一种基于http协议的数据请求方法和服务器
US10735307B1 (en) 2019-01-10 2020-08-04 Ebay Inc. Network latency measurement and analysis system
US11252445B1 (en) * 2019-04-22 2022-02-15 Meta Platforms, Inc. Systems and methods for providing passthrough adaptive bitrate videos
US11403849B2 (en) 2019-09-25 2022-08-02 Charter Communications Operating, Llc Methods and apparatus for characterization of digital content
US20220350748A1 (en) * 2021-04-29 2022-11-03 Microsoft Technology Licensing, Llc Consistent hashing for communication devices
CN113488065B (zh) * 2021-07-01 2024-05-14 上海卓易科技股份有限公司 一种基于云手机的音频输出方法、装置及计算机设备、存储介质

Family Cites Families (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6240243B1 (en) 1994-12-05 2001-05-29 International Business Machines Corporation Method and apparatus for storing and retrieving scalable video data in a disk-array-based video server
US5978843A (en) 1995-12-06 1999-11-02 Industrial Technology Research Institute Scalable architecture for media-on-demand servers
JP2924817B2 (ja) 1996-09-13 1999-07-26 日本電気株式会社 情報サーバシステム
WO1998040810A2 (en) 1997-03-12 1998-09-17 Storage Technology Corporation Network attached virtual tape data storage subsystem
KR20010022752A (ko) * 1998-06-11 2001-03-26 요트.게.아. 롤페즈 디지털 비디오 레코더용 트릭 플레이 신호 발생
US6768774B1 (en) 1998-11-09 2004-07-27 Broadcom Corporation Video and graphics system with video scaling
US7446774B1 (en) 1998-11-09 2008-11-04 Broadcom Corporation Video and graphics system with an integrated system bridge controller
US6785704B1 (en) 1999-12-20 2004-08-31 Fastforward Networks Content distribution system for operation over an internetwork including content peering arrangements
US7028096B1 (en) 1999-09-14 2006-04-11 Streaming21, Inc. Method and apparatus for caching for streaming data
US6742043B1 (en) 2000-01-14 2004-05-25 Webtv Networks, Inc. Reformatting with modular proxy server
US6671757B1 (en) * 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
US6820133B1 (en) 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US7565450B2 (en) 2000-03-16 2009-07-21 Adara Networks Inc. System and method for using a mapping between client addresses and addresses of caches to support content delivery
US7747782B2 (en) * 2000-04-26 2010-06-29 Novarra, Inc. System and method for providing and displaying information content
US20040025186A1 (en) * 2001-01-19 2004-02-05 Jennings Charles A. System and method for managing media
US8107524B2 (en) 2001-03-30 2012-01-31 Vixs Systems, Inc. Adaptive bandwidth footprint matching for multiple compressed video streams in a fixed bandwidth network
US6816455B2 (en) * 2001-05-09 2004-11-09 Telecom Italia S.P.A. Dynamic packet filter utilizing session tracking
US20030110234A1 (en) * 2001-11-08 2003-06-12 Lightsurf Technologies, Inc. System and methodology for delivering media to multiple disparate client devices based on their capabilities
US7133905B2 (en) 2002-04-09 2006-11-07 Akamai Technologies, Inc. Method and system for tiered distribution in a content delivery network
US7483487B2 (en) 2002-04-11 2009-01-27 Microsoft Corporation Streaming methods and systems
US7194000B2 (en) 2002-06-21 2007-03-20 Telefonaktiebolaget L.M. Ericsson Methods and systems for provision of streaming data services in an internet protocol network
JP4022755B2 (ja) 2003-01-21 2007-12-19 ソニー株式会社 記録装置、再生装置、ファイル管理方法及びファイル再生方法
US7272658B1 (en) 2003-02-13 2007-09-18 Adobe Systems Incorporated Real-time priority-based media communication
US7313236B2 (en) 2003-04-09 2007-12-25 International Business Machines Corporation Methods and apparatus for secure and adaptive delivery of multimedia content
US7143170B2 (en) 2003-04-30 2006-11-28 Akamai Technologies, Inc. Automatic migration of data via a distributed computer network
JP4340483B2 (ja) * 2003-06-27 2009-10-07 富士通株式会社 複合コンテンツの配信方法および配信システム
ITBA20030039A1 (it) 2003-08-29 2005-02-28 Grieco Luigi Alfredo Controllo di congestione rate-based del traffico entrante
EP1678972B1 (en) * 2003-10-01 2009-08-26 Actix Limited Call tracking systems
US7369610B2 (en) 2003-12-01 2008-05-06 Microsoft Corporation Enhancement layer switching for scalable video coding
KR100834749B1 (ko) 2004-01-28 2008-06-05 삼성전자주식회사 스케일러블 비디오 스트림 재생장치 및 그 방법
US20050289619A1 (en) * 2004-06-01 2005-12-29 Joel Melby Methods and system for resource allocation in an on-demand server
US7664109B2 (en) 2004-09-03 2010-02-16 Microsoft Corporation System and method for distributed streaming of scalable media
US20060143678A1 (en) 2004-12-10 2006-06-29 Microsoft Corporation System and process for controlling the coding bit rate of streaming media data employing a linear quadratic control technique and leaky bucket model
US7536469B2 (en) 2004-12-10 2009-05-19 Microsoft Corporation System and process for controlling the coding bit rate of streaming media data employing a limited number of supported coding bit rates
US7543073B2 (en) 2004-12-10 2009-06-02 Microsoft Corporation System and process for performing an exponentially weighted moving average on streaming data to establish a moving average bit rate
FR2880743A1 (fr) 2005-01-12 2006-07-14 France Telecom Dispositif et procedes de codage et de decodage echelonnables de flux de donnees d'images, signal, programme d'ordinateur et module d'adaptation de qualite d'image correspondants
KR20060114080A (ko) 2005-04-27 2006-11-06 삼성전자주식회사 멀티미디어 스트리밍 서비스 시스템 및 방법
US20070022215A1 (en) 2005-07-19 2007-01-25 Singer David W Method and apparatus for media data transmission
US7933294B2 (en) 2005-07-20 2011-04-26 Vidyo, Inc. System and method for low-delay, interactive communication using multiple TCP connections and scalable coding
US8289370B2 (en) 2005-07-20 2012-10-16 Vidyo, Inc. System and method for scalable and low-delay videoconferencing using scalable video coding
WO2007026268A1 (en) * 2005-08-31 2007-03-08 Nokia Corporation Inter-access mobility and service control
US20080247460A1 (en) 2005-10-07 2008-10-09 Jung Won Kang Method and Apparatus For Scalable Video Adaption Using Adaption Operators For Scalable Video
EP1788774A1 (en) 2005-11-18 2007-05-23 Alcatel Lucent Method and system for initiating or recovering a media-on-demand session
KR100772868B1 (ko) 2005-11-29 2007-11-02 삼성전자주식회사 복수 계층을 기반으로 하는 스케일러블 비디오 코딩 방법및 장치
KR20070108433A (ko) 2006-01-09 2007-11-12 한국전자통신연구원 청크 디스크립터를 이용한 ｓｖｃ 파일포맷에서의 비디오데이터 공유방법
TWI432035B (zh) 2006-01-11 2014-03-21 Nokia Corp 可縮放視訊編碼之圖像反向相容聚合技術
US8619865B2 (en) 2006-02-16 2013-12-31 Vidyo, Inc. System and method for thinning of scalable video coding bit-streams
EP2005607B1 (en) 2006-03-27 2016-09-07 Vidyo, Inc. System and method for management of scalability information in scalable video coding systems using control messages
EP2008461B1 (en) 2006-03-30 2015-09-16 LG Electronics Inc. A method and apparatus for decoding/encoding a multi-view video signal
US20070276954A1 (en) 2006-05-19 2007-11-29 Hong Kong University Of Science And Technology Low-Delay High Quality Video Streaming Using TCP
US20070268362A1 (en) 2006-05-22 2007-11-22 Matthew James West Compressed data
WO2008042852A2 (en) 2006-09-29 2008-04-10 Vidyo, Inc. System and method for multipoint conferencing with scalable video coding servers and multicast
US7930449B2 (en) 2006-09-14 2011-04-19 Opentv Inc. Method and system for data transmission
US9807431B2 (en) 2006-10-20 2017-10-31 Nokia Technologies Oy Generic indication of adaptation paths for scalable multimedia
US7953880B2 (en) 2006-11-16 2011-05-31 Sharp Laboratories Of America, Inc. Content-aware adaptive packet transmission
JP5086372B2 (ja) * 2007-02-26 2012-11-28 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信に関連する方法及び構成
CN101669367A (zh) 2007-03-02 2010-03-10 Lg电子株式会社 用于解码/编码视频信号的方法及设备
US20090119594A1 (en) 2007-10-29 2009-05-07 Nokia Corporation Fast and editing-friendly sample association method for multimedia file formats
KR101518089B1 (ko) * 2007-11-16 2015-05-15 톰슨 라이센싱 미디어 스트리밍의 세션 관리 시스템 및 방법
US20090178091A1 (en) 2008-01-08 2009-07-09 Hiroki Miyamoto Contents distribution method and receiving device
US8155020B2 (en) * 2008-01-14 2012-04-10 Qualcomm Incorporated Policy control and charging (PCC) rules based on mobility protocol
JP4670902B2 (ja) 2008-05-30 2011-04-13 ソニー株式会社 送信装置、送信方法および受信装置
WO2010042595A2 (en) * 2008-10-07 2010-04-15 Velocent Systems Incorporated Method and apparatus pertaining to updating a high-bandwidth hardware-based packet-processing platform local session context state database
US7818445B2 (en) * 2008-10-15 2010-10-19 Patentvc Ltd. Methods and devices for obtaining a broadcast-like streaming content
US20100094971A1 (en) * 2008-10-15 2010-04-15 Patentvc Ltd. Termination of fragment delivery services from data centers participating in distributed streaming operations
US9003043B1 (en) * 2008-12-17 2015-04-07 Emc Corporation Techniques for client and server communication
US8180892B2 (en) * 2008-12-22 2012-05-15 Kindsight Inc. Apparatus and method for multi-user NAT session identification and tracking
US8228363B2 (en) 2009-01-30 2012-07-24 Polycom, Inc. Method and system for conducting continuous presence conferences
US9197677B2 (en) 2009-03-09 2015-11-24 Arris Canada, Inc. Multi-tiered scalable media streaming systems and methods
US9485299B2 (en) 2009-03-09 2016-11-01 Arris Canada, Inc. Progressive download gateway
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
CA2755774C (en) * 2009-03-19 2015-01-06 Azuki Systems, Inc. Method for scalable live streaming delivery for mobile audiences
US8209730B2 (en) * 2009-06-22 2012-06-26 Sony Corporation Speculative video on demand
US8184142B2 (en) 2009-06-26 2012-05-22 Polycom, Inc. Method and system for composing video images from a plurality of endpoints
CA2711311C (en) 2009-08-10 2016-08-23 Seawell Networks Inc. Methods and systems for scalable video chunking
US9038116B1 (en) * 2009-12-28 2015-05-19 Akamai Technologies, Inc. Method and system for recording streams
US20110296048A1 (en) * 2009-12-28 2011-12-01 Akamai Technologies, Inc. Method and system for stream handling using an intermediate format
US8521899B2 (en) * 2010-05-05 2013-08-27 Intel Corporation Multi-out media distribution system and method
US8190677B2 (en) 2010-07-23 2012-05-29 Seawell Networks Inc. Methods and systems for scalable video delivery
US9456015B2 (en) * 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
TW201216656A (en) * 2010-10-01 2012-04-16 Interdigital Patent Holdings Method and apparatus for media session sharing and group synchronization of multi media streams
US8880633B2 (en) * 2010-12-17 2014-11-04 Akamai Technologies, Inc. Proxy server with byte-based include interpreter
US20120265853A1 (en) * 2010-12-17 2012-10-18 Akamai Technologies, Inc. Format-agnostic streaming architecture using an http network for streaming
US8489760B2 (en) * 2011-03-31 2013-07-16 Juniper Networks, Inc. Media file storage format and adaptive delivery system
US8649668B2 (en) * 2011-06-03 2014-02-11 Adobe Systems Incorporated Client playback of streaming video adapted for smooth transitions and viewing in advance display modes
US20130132462A1 (en) * 2011-06-03 2013-05-23 James A. Moorer Dynamically Generating and Serving Video Adapted for Client Playback in Advanced Display Modes
US9160779B2 (en) * 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US8929356B2 (en) * 2013-02-05 2015-01-06 Anue Systems, Inc. Mobile user identification and tracking for load balancing in packet processing systems
US9311651B2 (en) * 2013-03-07 2016-04-12 Cable Television Laboratories, Inc. Identity-Media Measurement Model (IMMM)

Also Published As

Publication number Publication date
EP2837196B1 (en) 2019-06-12
WO2013152426A1 (en) 2013-10-17
EP2837196A4 (en) 2015-12-23
CA2870059C (en) 2018-06-05
CN104396263A (zh) 2015-03-04
MX353807B (es) 2018-01-29
JP2015518325A (ja) 2015-06-25
US20130275557A1 (en) 2013-10-17
US9712887B2 (en) 2017-07-18
CN104396263B (zh) 2018-06-08
CA2870059A1 (en) 2013-10-17
JP6014870B2 (ja) 2016-10-26
EP2837196A1 (en) 2015-02-18

Similar Documents

Publication Publication Date Title
JP6014870B2 (ja) ストリーミング・メディア・コンテンツのリアルタイム・トランスマックス変換の方法およびシステム
US9787747B2 (en) Optimizing video clarity
CN110089122B (zh) 用于检索媒体数据的方法、媒体装置及计算机可读存储媒体
Ma et al. Mobile video delivery with HTTP
TWI623226B (zh) 用於儲存媒體片段之基於目錄限制之系統及方法
US9247317B2 (en) Content streaming with client device trick play index
US8516144B2 (en) Startup bitrate in adaptive bitrate streaming
US9094737B2 (en) Network video streaming with trick play based on separate trick play files
Kesavan et al. An investigation on adaptive HTTP media streaming Quality-of-Experience (QoE) and agility using cloud media services
US8874778B2 (en) Live streaming media delivery for mobile audiences
US9596522B2 (en) Fragmented file structure for live media stream delivery
CN108769616A (zh) 一种基于rtsp协议的实时视频无插件预览方法及系统
US20150256600A1 (en) Systems and methods for media format substitution
US20140359678A1 (en) Device video streaming with trick play based on separate trick play files
CN110870282B (zh) 使用网络内容的文件轨处理媒体数据
WO2014193996A2 (en) Network video streaming with trick play based on separate trick play files
US20110299586A1 (en) Quality adjustment using a fragmented media stream
US9338204B2 (en) Prioritized side channel delivery for download and store media
US10924524B2 (en) Communication devices, communication data generation method, and communication data processing method
Yang et al. Implementation of HTTP live streaming for an IP camera using an open source multimedia converter
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
JP2007524167A (ja) ストリーミングサービスにおけるアセット情報の送信
Belda et al. Performance evaluation and testbed for delivering SRT live content using DASH Low Latency streaming systems
CN113364728A (zh) 媒体内容接收方法、装置、存储介质和计算机设备

Legal Events

Date Code Title Description
FG Grant or registration