ES2940452T3 - Procedimiento y servidor para la distribución de contenido de audio y/o vídeo - Google Patents

Procedimiento y servidor para la distribución de contenido de audio y/o vídeo Download PDF

Info

Publication number
ES2940452T3
ES2940452T3 ES20315225T ES20315225T ES2940452T3 ES 2940452 T3 ES2940452 T3 ES 2940452T3 ES 20315225 T ES20315225 T ES 20315225T ES 20315225 T ES20315225 T ES 20315225T ES 2940452 T3 ES2940452 T3 ES 2940452T3
Authority
ES
Spain
Prior art keywords
audio
video content
client device
cache server
segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES20315225T
Other languages
English (en)
Inventor
Guillaume Bichot
Pierre-Jean Guery
Vincent Richard
Scouarnec Nicolas Le
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Broadpeak SA
Original Assignee
Broadpeak SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Broadpeak SA filed Critical Broadpeak SA
Application granted granted Critical
Publication of ES2940452T3 publication Critical patent/ES2940452T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • 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/2368—Multiplexing of audio and video streams
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26233—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving content or additional data duration or size, e.g. length of a movie, size of an executable file
    • 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/637—Control signals issued by the client directed to the server or network components
    • 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/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64769—Control signals issued by the network directed to the server or the client directed to the server for rate control
    • 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/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64776—Control signals issued by the network directed to the server or the client directed to the server for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)

Abstract

Para entregar un contenido de audio y/o video utilizando la transmisión adaptativa desde un servidor de caché a un dispositivo cliente, el contenido de audio y/o video se segmenta en segmentos de datos disponibles en varias representaciones con las respectivas calidades de audio y/o video, siendo las representaciones tiempo -alineado por segmento, dividiéndose además los segmentos en fragmentos, un método comprende: obtener un valor de tiempo de ida y vuelta aplicable entre el servidor de caché y el dispositivo cliente; calcular un tamaño mínimo de transferencia masiva a partir de la tasa de bits media máxima de las diversas representaciones del contenido de audio y/o vídeo ya partir del valor de tiempo de ida y vuelta obtenido; computar una duración mínima masiva, con respecto al contenido de audio y/o video, para que la representación sea entregada al dispositivo del cliente; (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento y servidor para la distribución de contenido de audio y/o vídeo
CAMPO TECNICO
La presente invención generalmente se refiere a la distribución de un contenido de audio y/o vídeo desde un equipo servidor a un dispositivo cliente usando una tasa de bits adaptable, también denominada emisión en continuo adaptable.
TÉCNICA RELACIONADA
En la emisión en continuo adaptable HTTP ("protocolo de transferencia de hipertexto"), un dispositivo cliente interactúa con un equipo servidor para solicitar partes, denominadas segmentos, de un flujo de audio y/o vídeo (contenido en vivo) o archivo (contenido de vídeo bajo demanda) para ser reproducido. El flujo o archivo de audio y/o vídeo está codificado en varias calidades, denominadas representaciones. Cada una de las representaciones está compuesta por una sucesión de segmentos de igual duración con respecto al contenido de audio y/o vídeo. Por lo tanto, las representaciones están alineadas en el tiempo por segmento y comienzan con la misma trama de referencia de audio y/o vídeo, lo que permite que el dispositivo cliente, y más particularmente un reproductor de audio y/o vídeo incluido en el mismo, cambie de una representación a otra representación en los límites del segmento.
En la tecnología de emisión en continuo adaptable tal como HLS (que significa "emisión en vivo en HTTP", que es un protocolo de comunicaciones de emisión en vivo basado en HTTP y desarrollado por Apple Inc.) o DASH (que significa "emisión en continuo dinámica adaptable sobre HTTP", que es una tecnología de emisión en continuo multimedia desarrollada por el Grupo de expertos en imágenes en movimiento (MPEG), el cambio de una representación a otra es impulsado por el dispositivo cliente, lo que significa que el dispositivo cliente solicita al equipo servidor que cambie a dicha otra representación. Típicamente, el dispositivo cliente selecciona la representación apropiada basándose en la evaluación del ancho de banda disponible desde el equipo servidor hasta el dispositivo cliente y, potencialmente, otros criterios como la ocupación del búfer, la resolución de la pantalla, las capacidades del decodificador, etc.
Las tecnologías emergentes de baja latencia para emisión en vivo tales como CTE (codificación de transferencia fragmentada) con MPEG CMAF (formato común de aplicaciones multimedia) o LL HLS (HLS de baja latencia) permiten la reproducción temprana de contenido de audio y/o vídeo mediante una gestión de fragmentos particulares que no necesita la disponibilidad de un segmento completo antes de iniciar la reproducción.
Por lo tanto, en una implementación de red de distribución de contenido (CDN) para emisión en continuo adaptable, un servidor de origen (también conocido como servidor original) que actúa como un equipo empaquetador proporciona las representaciones en forma de segmentos divididos en fragmentos listos para ser enviados cuando el segmento relacionado es solicitado por un servidor de caché. Los fragmentos corresponden a una duración predefinida del contenido de audio y/o vídeo y, por tanto, son unidades codificadas más pequeñas que los segmentos. El servidor de caché sirve al dispositivo cliente al recibir solicitudes de segmento del mismo, distribuyendo fragmentos en transferencias en ráfaga.
Aunque estas tecnologías de baja latencia aceleran la distribución de datos, crean perturbaciones al estimar el ancho de banda disponible. En consecuencia, se puede seleccionar una representación (calidad) de contenido de audio y/vídeo inapropiada y, por tanto, se puede reducir la QoE (calidad de la experiencia).
El rendimiento del servidor de caché al dispositivo cliente puede estar limitado por la capacidad del enlace del servidor de caché al dispositivo cliente o por el tiempo de ida y vuelta (RTT) entre el servidor de caché y el dispositivo cliente.
Consideremos un ejemplo ilustrativo como sigue. Un contenido de vídeo está disponible en tres representaciones, con tasas de bits correspondientes de 3 Mbps, 2 Mbps y 1 Mbps. El contenido de vídeo se divide en segmentos que tienen una duración de 2 segundos con respecto al contenido de vídeo, y se divide adicionalmente en fragmentos de 200 milisegundos de duración con respecto al contenido de vídeo (10 fragmentos por segmento). Consideremos un RTT de 100 milisegundos y un ancho de banda de cuello de botella máximo de 8 Mbps. El dispositivo cliente (reproductor) ha solicitado un segmento de vídeo de 1 Mbps, que se distribuye fragmento tras fragmento, lo que lleva a una estimación de ancho de banda de 2 Mbps, aunque la capacidad efectiva es igual a 8 Mbps.
Esto significa que el dispositivo cliente o el servidor de caché que intenta evaluar el ancho de banda máximo disponible mediante el análisis de la cantidad de bits transmitidos durante un período de ráfaga correspondiente a la transmisión de un fragmento estima incorrectamente 2 Mbps de ancho de banda disponible, muy por debajo del ancho de banda real disponible, lo que impide el uso de representaciones de mayor calidad (que tienen una mayor tasa de bits). La situación es ciertamente incluso peor que la que se muestra en el ejemplo anterior porque dividir un segmento en fragmentos de igual duración con respecto al contenido de audio y/vídeo no conduce a fragmentos con el mismo tamaño (es decir, cantidad de bits). De hecho, considerando un contenido de vídeo, un fragmento que incluye datos de imagen I (de acuerdo con el esquema de compresión IPB convencional) es ciertamente de un tamaño mayor que el tamaño promedio de 200 kbits usado en el ejemplo anterior para estimar el ancho de banda disponible, mientras que otros fragmentos que incluyen otros datos de la misma trama de vídeo son de menor tamaño. Dependiendo de qué fragmentos se consideren en la ventana de tiempo de congestión para estimar el ancho de banda disponible, puede conducir a una estimación del ancho de banda disponible aún más reducida, que también puede amplificarse cuando hay almacenamiento en búfer de red entre el servidor de caché y el dispositivo cliente.
Caba señalar, además, que cuando el RTT es diferente, la estimación del ancho de banda disponible resultante es diferente, por ejemplo, con un RTT igual a 10 milisegundos, habría dado como resultado una estimación teórica del ancho de banda de 20 Mbps, que de hecho está limitada por el ancho de banda de cuello de botella máximo de 8 Mbps (capacidad de enlace).
Por tanto, es deseable superar los inconvenientes anteriores de la técnica anterior y, más particularmente, mejorar la QoE cuando se distribuye un contenido de audio y/o vídeo desde un equipo servidor a un dispositivo cliente usando una tasa de bits adaptable. También es particularmente deseable proporcionar una solución que sea simple de implementar y que sea rentable.
El documento KEVIN STREETER (ADOBE) ET AL: "On Low Latency Live Streaming with MPEG-DASH", 102. MPEG MEETING; 20121015 - 20121019; SHANGHAI; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11), no. m27233 15 de octubre de 2012 (15-10-2012), XP030272927 describe la codificación de transferencia fragmentada de segmentos DASH.
El documento US 2019/306551 A1 (ARYE MATVEY [US] ET AL) del 3 de octubre de 2019 describe las solicitudes de segmento de canalización de modo que múltiples segmentos se combinen en fragmentos más grandes. El tamaño de fragmento óptimo se determina basándose en el tiempo de ida y vuelta.
RESUMEN DE LA INVENCIÓN
Con ese fin, en el presente documento se divulga un procedimiento para distribuir un contenido de audio y/o vídeo usando emisión en continuo adaptable desde un servidor de caché a un dispositivo cliente, estando segmentado el contenido de audio y/o vídeo en segmentos de datos disponibles en diversas representaciones con calidades de audio y/o vídeo respectivas, estando las representaciones alineadas en el tiempo por segmento, estando los segmentos divididos además en fragmentos, en donde el procedimiento comprende: obtener un valor temporal de ida y vuelta aplicable entre el servidor de caché y el dispositivo cliente; calcular un tamaño mínimo de transferencia masiva mTBS a partir de la tasa de bits promedio máxima de las diversas representaciones del contenido de audio y/o vídeo y a partir del valor temporal de ida y vuelta obtenido; calcular una duración masiva mínima mTBDi, con respecto al contenido de audio y/o vídeo, para la representación i del contenido de audio y/o vídeo que tiene que ser distribuido al dispositivo cliente; y distribuir el contenido de audio y/o vídeo mediante transferencias en ráfaga en forma de L masas de al menos un fragmento o fragmentos agregados sucesivos para cada segmento, conteniendo las L masas conjuntamente datos de contenido de audio y/o vídeo correspondientes a dicho segmento, y en donde, para cada segmento, al menos L-1 masa o masas están formadas respectivamente por M fragmento o fragmentos de modo que
M—1
y CHf < m Tt
y
M — l
^ CHj < m T B D i
j =i
en donde CHj (j = 1,...,M) representa la duración temporal del fragmento j con respecto al contenido de audio y/o vídeo. Por tanto, realizando transferencias en ráfaga con una duración masiva definida teniendo en cuenta el valor temporal de ida y vuelta aplicable entre el servidor de caché y el dispositivo cliente, se puede realizar una estimación del ancho de banda efectivo. En consecuencia, se puede realizar una selección apropiada de la representación del contenido de audio y/o vídeo, lo que mejora la QoE.
De acuerdo con una realización particular, el valor temporal de ida y vuelta es almacenado por el servidor de caché como un parámetro de configuración por defecto y corresponde al tiempo de ida y vuelta máximo posible que debe gestionar el servidor de caché cuando distribuye datos de contenido de audio y/o vídeo a cualquier dispositivo cliente.
De acuerdo con una realización particular, el valor temporal de ida y vuelta es el valor promedio del tiempo de ida y vuelta calculado por el servidor de caché a lo largo del tiempo mediante el análisis de sesiones para distribuir contenido de audio y/o vídeo a los dispositivos clientes.
De acuerdo con una realización particular, dicho valor temporal de ida y vuelta se usa como configuración inicial y definición del tamaño mínimo de transferencia masiva mTBS y la duración masiva mínima mTBDi, y a continuación se actualiza dinámicamente, así como el tamaño mínimo de transferencia masiva mTBS y la duración masiva mínima mTBDi, de acuerdo con mediciones del tiempo de ida y vuelta entre el servidor de caché y el dispositivo cliente.
De acuerdo con una realización particular, se usa el mismo valor temporal de ida y vuelta durante una sesión completa de distribución de contenido de audio y/o vídeo.
De acuerdo con una realización particular, para obtener el valor temporal de ida y vuelta, el servidor de caché, al recibir desde el dispositivo cliente una solicitud para obtener una lista de reproducción o un archivo declarativo relacionado con el contenido de audio y/o vídeo, el servidor de caché redirige el dispositivo cliente para obligar al dispositivo cliente a retransmitir la solicitud en cuestión, y calcula el valor temporal de ida y vuelta como la diferencia de tiempo desde el instante en que el servidor de caché redirigió el dispositivo cliente hasta el instante en que el servidor de caché recibe de nuevo la solicitud en cuestión desde el dispositivo cliente.
De acuerdo con una realización particular, el servidor de caché indica en la lista de reproducción o archivo declarativo que una duración de segmentos parciales es igual a la duración de la masa de fragmentos como se define en función del valor temporal de ida y vuelta.
De acuerdo con una realización particular, un archivo declarativo relacionado con el contenido de audio y/o vídeo indica que la solicitud de segmento se puede realizar tan pronto como un fragmento esté teóricamente disponible, y en donde el servidor de caché bloquea el procesamiento de una solicitud de segmento recibida desde el dispositivo cliente hasta que suficientes fragmentos del segmento solicitado estén disponibles en la memoria caché para construir la masa que se transmitirá en respuesta.
En el presente documento se divulga, además, un producto de programa informático que comprende instrucciones de código de programa que se pueden cargar en un dispositivo programable para implementar el procedimiento anterior en cualquiera de sus realizaciones, cuando las instrucciones de código de programa son ejecutadas por el dispositivo programable. En el presente documento se divulga, además, un medio de almacenamiento de información que almacena dicho programa informático.
En el presente documento se divulga, además, un servidor de caché configurado para distribuir un contenido de audio y/o vídeo usando emisión en continuo adaptable a un dispositivo cliente, estando segmentado el contenido de audio y/o vídeo en segmentos de datos disponibles en diversas representaciones con calidades de audio y/o vídeo respectivas, estando las representaciones alineadas en el tiempo por segmento, estando los segmentos divididos además en fragmentos, en donde el servidor de caché comprende circuitos electrónicos configurados para: obtener un valor temporal de ida y vuelta aplicable entre el servidor de caché y el dispositivo cliente; calcular un tamaño mínimo de transferencia masiva mTBS a partir de la tasa de bits promedio máxima de las diversas representaciones del contenido de audio y/o vídeo y a partir del valor temporal de ida y vuelta obtenido; calcular una duración masiva mínima mTBDi, con respecto al contenido de audio y/o vídeo, para la representación i del contenido de audio y/o vídeo que tiene que ser distribuido al dispositivo cliente; y distribuir el contenido de audio y/o vídeo mediante transferencias en ráfaga en forma de L masas de al menos un fragmento o fragmentos agregados sucesivos para cada segmento, conteniendo las L masas conjuntamente datos de contenido de audio y/o vídeo correspondientes a dicho segmento, y en donde, para cada segmento, al menos L-1 masa o masas están formadas respectivamente por M fragmento o fragmentos de modo que
M
^ CHj > mTBDi
7 = 1
y
Figure imgf000004_0001
en donde CHj (j = 1,...,M) representa la duración temporal del fragmento j con respecto al contenido de audio y/o vídeo
En el presente documento se divulga, además, una red de distribución de contenido que incluye el servidor de caché anterior.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Las características de la invención se manifestarán más claramente a partir de la lectura de la siguiente descripción de al menos una realización, estando dicha descripción realizada con referencia a los dibujos adjuntos, entre los cuales:
- La figura 1 representa esquemáticamente un sistema de distribución de contenido de audio y/o vídeo en el que se puede implementar la presente invención;
- La figura 2 representa esquemáticamente segmentos alineados en el tiempo de diversas representaciones; - La figura 3 representa esquemáticamente un segmento, un trozo y una masa con respecto al tiempo;
- La figura 4 representa esquemáticamente un ejemplo de arquitectura de hardware de un dispositivo utilizable en el ámbito del sistema de distribución de contenido de audio y/o vídeo; y
- La figura 5 representa esquemáticamente un algoritmo para distribuir datos de contenido de audio y/o vídeo en forma de masas de fragmentos mediante transferencias en ráfaga, en una realización particular;
- La figura 6 representa esquemáticamente un algoritmo para gestionar solicitudes de segmento, en una realización particular; y
- La figura 7 representa esquemáticamente un algoritmo para distribuir datos de contenido de audio y/o vídeo en forma de masas de fragmentos mediante transferencias en ráfaga, en otra realización particular.
DESCRIPCIÓN DETALLADA DE AL MENOS UNA REALIZACIÓN
La figura 1 representa esquemáticamente un sistema de distribución de contenido de audio y/o vídeo 100 que comprende un servidor de caché CSERV 130 y al menos un dispositivo cliente CL 140. El sistema de distribución de contenido de audio y/o vídeo 100 comprende además un servidor de origen OSERV 150.
El servidor de caché CSERV 130 es el equipo encargado de distribuir segmentos de al menos un contenido de audio y/o vídeo al, al menos un, dispositivo cliente CL 140 a través de un enlace de comunicación 120. El servidor de caché CSERV 130 puede ser un único servidor o un grupo de servidores. El servidor de caché CSERV 130 puede ser parte de una red de distribución de contenido que incluye al menos un equipo servidor de ese tipo.
El enlace de comunicación 120 puede ser un enlace físico, tal como un cable o una serie de cables, o un enlace inalámbrico. El enlace de comunicación 120 puede ser un enlace lógico, tal como una vía de comunicación a través de Internet.
Un dispositivo cliente CL 140 está representado en la figura 1, pero el sistema de distribución de contenido de audio y/o vídeo típicamente comprende numerosos dispositivos clientes.
El servidor de origen OSERV 150 se encarga de empaquetar al menos un contenido de audio y/o vídeo en forma de segmentos divididos en fragmentos. El servidor de origen OSERV 150 proporciona el contenido de audio y/o vídeo en representaciones plurales (calidades) que tienen tasas de bits respectivas. El equipo servidor de origen OSERV 150 puede ser un único servidor o un grupo de servidores. El servidor de caché CSERV 130 obtiene el al menos un contenido de audio y/o vídeo del equipo servidor de origen OSERV 150 por medio de un enlace de comunicación 121.
El enlace de comunicación 121 puede ser un enlace físico, tal como un cable o una serie de cables, o un enlace inalámbrico. El enlace de comunicación 121 puede ser un enlace lógico, tal como una vía de comunicación a través de Internet.
Como se divulga a continuación con respecto a la figura 2, cuanto mayor sea la calidad de una representación, mayor será la tasa de bits correspondiente. Los segmentos están alineados en el tiempo entre todas las representaciones de uno cualquiera de dichos contenidos de audio y/o vídeo, lo que permite cambiar de una representación a otra dependiendo de qué tasa de bits de representación se adapte mejor a la estimación del ancho de banda disponible para lograr la mejor QoE posible.
Los fragmentos tienen la misma duración con respecto al contenido de audio y/o vídeo. Esta duración de fragmento define una unidad mínima de tiempo de transferencia masiva entre el servidor de origen OSERV 150 y el servidor de caché CSERV 130 y, lo que es más importante, entre el servidor de caché CSERV 130 y el al menos un dispositivo cliente CL 140. El servidor de origen OSERV 150 está configurado para generar fragmentos con una función de duración de fragmento del RTT mínimo que se espera que gestione el sistema de distribución de contenido de audio y/o vídeo 100. Por ejemplo, podría ser de 50 milisegundos.
Cuando el servidor de caché CSERV 130 pertenece a una CDN con varios servidores de caché de este tipo, está duración de fragmento (que es una unidad de transferencia masiva mínima, como es evidente en la explicación detallada a continuación) puede ser la misma para varios o todos dichos servidores de caché, o diferente de un servidor de caché a otro.
Los contenidos de audio y/o vídeo típicamente están acompañados por los respectivos archivos declarativos. Cada archivo declarativo se relaciona con el contenido de audio y/o vídeo y describe cómo se ponen a disposición los segmentos del contenido de audio y/o vídeo, más particularmente qué representaciones (calidades) del contenido de audio y/o vídeo en cuestión están disponibles. Cabe señalar que, dependiendo la tecnología de tasa de bits adaptable que se use, el archivo declarativo puede denominarse lista de reproducción. Por tanto, el servidor de origen OSERV 150 adapta cada archivo declarativo adjunto al servidor de caché CSERV 130 de acuerdo con esta duración de fragmento (o unidad de transferencia masiva mínima) que se aplica al servidor de caché CSERV 130. Por ejemplo, en MPEG DASH de baja latencia, se indica un desfase de tiempo en un campo denominado desfase de tiempo de disponibilidad que es usado por el dispositivo cliente CL 140 para calcular el momento adecuado para enviar una solicitud de segmento. Se espera que el dispositivo cliente CL 140 reste el valor de desfase de tiempo de disponibilidad del instante teórico correspondiente al envío de la solicitud de segmento por parte del servidor de caché CSERV 130. Este valor es válido para toda la sesión y se calcula en función de la duración de fragmento. Cualquiera que sea la fuente original del archivo declarativo, hay que asegurarse de que el valor de desfase de tiempo de disponibilidad se haya calculado en función de la duración de fragmento (unidad de tiempo de transferencia masiva mínima) asociada con el servidor de caché CSERV 130.
El servidor de caché CSERV 130 sirve al, al menos un, dispositivo cliente CL 140 al recibir solicitudes de segmento del mismo, distribuyendo grandes cantidades de fragmentos en transferencias en ráfaga. Como se divulga a continuación, el servidor de caché CSERV 130 forma la masa de fragmentos agregando los fragmentos dependiendo del valor de RTT aplicable entre el servidor de caché CSERV 130 y el al menos un dispositivo cliente CL 140 en cuestión.
Cada dispositivo cliente CL 140 comprende un reproductor y un decodificador. El decodificador es configurado (inicializado o reinicializado) por el reproductor de acuerdo con el formato de codificación y la calidad (es decir, la representación) efectivamente en uso y se encarga de decodificar de acuerdo con los datos de audio y/o vídeo recibidos por el reproductor. El reproductor se encarga de realizar intercambios con el equipo servidor de caché CSERV 130 para recibir los datos de audio y/o vídeo codificados desde el servidor de caché CSERV 130. El reproductor solicita segmentos de al menos un contenido de audio y/o vídeo y el servidor de caché CSERV 130 transmite a cambio los segmentos solicitados en forma de masas de fragmentos en transferencias en ráfaga.
Considerando una sesión para distribuir un contenido de audio y/o vídeo desde el servidor de caché CSERV 130 a dicho dispositivo cliente CL 140, la evaluación del ancho de banda disponible es realizada por el servidor de caché CSERV 130 y/o por el dispositivo cliente CL 140. La evaluación del ancho de banda disponible permite seleccionar una representación del contenido de audio y/o vídeo dependiendo de qué tasa de bits de representación se adapte mejor a la estimación del ancho de banda disponible para lograr la mejor QoE posible. Por ejemplo, la estimación del ancho de banda disponible se realiza usando información BBR (ancho de banda de cuello de botella y tiempo de propagación de ida y vuelta). El enfoque de BBR es un algoritmo de control de congestión reciente que se adapta particularmente bien a la comunicación inalámbrica y que se puede usar en asociación con el protocolo TCP u otro protocolo de transporte (por ejemplo, QUIC sobre UDP (protocolo de datagramas de usuario)). Son posibles realizaciones alternativas donde la estimación del ancho de banda disponible se realiza usando otros algoritmos de control de congestión tales como en TCP CUBIC, VEGAS, RENO o en otros protocolos de transporte tales como QUIC, SCTP (protocolo de control de transmisiones de corrientes), etc. Como alternativa, la estimación del ancho de banda disponible se realiza directamente analizando la forma del tráfico del protocolo de transporte (paquetes de datos y paquetes de reconocimiento) de al menos una conexión de transporte (por ejemplo, conexión TCP) usada para distribuir fragmentos al dispositivo cliente CL 140 en cuestión.
Como se muestra en la figura 2, cada contenido de audio y/o vídeo está disponible en diversas representaciones R1, R2, R3, con calidades de audio y/o vídeo respectivas. Un segmento de todas y cada una de las representaciones (por ejemplo, R1) del contenido de audio y/o vídeo contiene la misma parte de contenido que el mismo segmento de todas y cada una de las demás representaciones (por ejemplo, resp. R2, R3) del contenido de audio y/o vídeo. En otras palabras, los segmentos de las diversas representaciones R1, R2, R3 están alineados en el tiempo. Cada segmento comienza con una trama de referencia RF. En la figura 2, considerando el mismo segmento del contenido de audio y/o vídeo, la trama de referencia RF está etiquetada como RF1 para la representación R1, la trama de referencia RF está etiquetada como RF2 para la representación R2 y la trama de referencia RF está etiquetada como RF3 para la representación R3. Además, la trama de referencia RF es seguida por al menos una trama SF subsiguiente en el segmento. En la figura 2, la al menos una trama subsiguiente SF está etiquetada como SF1 para la representación R1, la al menos una trama subsiguiente SF está etiquetada como SF2 para la representación R2 y la al menos una trama subsiguiente SF está etiquetada como SF3 para la representación R3.
Dado que las representaciones R1, R2, R3 corresponden a diferentes cualidades, el tamaño de un segmento de todas y cada una de las representaciones (por ejemplo, R1) típicamente difiere del tamaño del mismo segmento de todas y cada una de las demás representaciones (por ejemplo, resp. R2, R3). De hecho, el tamaño de segmento aumenta con la calidad, como se muestra en la figura 2 donde se representa esquemáticamente el mismo segmento de las representaciones R1, R2, R3, y donde se considera que la representación R3 corresponde a una mejor calidad que la representación R2 y la representación R2 corresponde a una mejor calidad que la representación R1. En consecuencia, el tamaño de la trama de referencia RF3 en la representación R3 es mayor que el tamaño de la trama de referencia RF2 en la representación R2, y el tamaño de la trama de referencia RF2 en la representación R2 es mayor que el tamaño de la trama de referencia RF1 en la representación R1. Además, el tamaño de las tramas subsiguientes SF3 en la representación R3 es mayor que el tamaño de las tramas subsiguientes SF2 en la representación R2, y el tamaño de las tramas subsiguientes SF2 en la representación R2 es mayor que el tamaño de las tramas subsiguientes SF1 en la representación R1. Como consecuencia, los requisitos de ancho de banda también aumentan con la calidad del audio y/o vídeo.
Como se muestra en la figura 3, considerando un segmento S de un contenido de audio y/o vídeo, el segmento S en cuestión cubre una duración de tiempo ts del contenido de audio y/o vídeo. El segmento S se divide en fragmentos. Un fragmento C del segmento S tiene una duración inferior tc del contenido de audio y/o vídeo, lo que define una unidad mínima de tiempo de transferencia masiva. Por tanto, las masas B de fragmentos C son formadas por el servidor de caché CSERV 130 por agregación de los fragmentos C en cuestión, correspondiendo así a una duración te del contenido de audio y/o vídeo (también inferior a la duración ts del segmento S con respecto al contenido de audio y/o vídeo). El número de fragmentos C en la agregación que forman la masa B que se transmitirá en una transferencia en ráfaga desde el servidor de caché CSERV 130 al dispositivo cliente CL 140 en cuestión se define de acuerdo con el valor de RTT a considerar entre el servidor de caché CSERV 130 y el dispositivo cliente CL 140 en cuestión.
La figura 4 representa esquemáticamente un ejemplo de arquitectura de hardware 400 utilizable en el ámbito del sistema de distribución de contenido de audio y/o vídeo 100. La arquitectura de hardware puede ser parte del equipo servidor de caché CSERV 130. La arquitectura de hardware puede ser parte del equipo servidor de origen OSERv 150. La arquitectura de hardware puede ser parte del dispositivo cliente Cl 140.
La arquitectura de hardware 400 comprende los siguientes componentes interconectados por un bus de comunicaciones 410: un procesador, microprocesador, microcontrolador o CPU (unidad central de procesamiento) 401; una RAM (memoria de acceso aleatorio) 402; una ROM (memoria de sólo lectura) 403, tal como una EEPROM (ROM programable y borrable eléctricamente), por ejemplo una memoria Flash; una HDD (unidad de disco duro) 404, o cualquier otro dispositivo adaptado para leer información almacenada en un medio de almacenamiento, tal como un lector de tarjetas SD (digitales seguras); al menos una interfaz de comunicación COM 405.
La CPU 401 es capaz de ejecutar instrucciones cargadas en la RAM 402 desde la ROM 403 o desde una memoria externa, tal como HDD 404 o una tarjeta SD. Después de encender la arquitectura de hardware 400, la CPU 401 es capaz de leer instrucciones de la rAm 402 y ejecutar estas instrucciones. Las instrucciones forman un programa informático que hace que la CPU 401 ejecute las etapas realizados divulgadas en el presente documento con respecto al equipo servidor de caché CSERV 130 o al equipo servidor de origen OSERV 150 o al dispositivo cliente CL 140.
Por tanto, las etapas y algoritmos descritos en el presente documento pueden implementarse en forma de software mediante la ejecución de un conjunto de instrucciones o programa por una máquina de computación programable, tal como una PC, un DSP (procesador de señales digitales) o un procesador; o bien implementarse en forma de hardware por una máquina o un componente, chip o conjunto de chips dedicado, tal como una FPGA (matriz de puertas programables in situ) o un ASIC (circuito integrado específico de aplicación). Más generalmente, el equipo servidor de caché CSERV 130, el equipo servidor de origen OSERV 150 y el dispositivo cliente CL 140400 comprenden circuitos electrónicos configurados para realizar las etapas y algoritmos descritos en el presente documento con respecto al dispositivo o servidor en cuestión.
La figura 5 representa esquemáticamente un algoritmo para distribuir datos de contenido de audio y/o vídeo en forma de masas de fragmentos mediante transferencias en ráfaga, en una realización particular.
En una etapa 501, el servidor de caché CSERV 130 obtiene información de RTT aplicable entre el servidor de caché CSERV 130 y el dispositivo cliente CL 140 al que se deben distribuir los datos de contenido de audio y/o vídeo. De acuerdo con un primer ejemplo, el RTT es medido por el servidor de caché CSERV 130 durante los intercambios con el dispositivo cliente CL 140. Como alternativa, durante dichos intercambios, el RTT puede ser medido por el dispositivo cliente CL 140 y a continuación proporcionado por el dispositivo cliente CL 140 al servidor de caché CSERV 130. El RTT puede ser medido una vez para una sesión completa de distribución del contenido de audio y/o vídeo desde el servidor de caché CSERV 130 al dispositivo cliente CL 140. Como alternativa, el RTT es medido regularmente. En otro enfoque, el RTT se almacena como un parámetro de configuración por defecto y corresponde al RTT máximo posible que tiene que gestionar el servidor de caché CSERV 130 cuando distribuye datos de contenido de audio y/o vídeo a cualquier dispositivo cliente. Cabe señalar que, en el caso de una configuración de CDN sobre una infraestructura de red móvil, los servidores de caché se pueden implementar en diversas ubicaciones en la infraestructura de red móvil (dentro de estaciones base o dentro de puertas de enlace, etc.). En este caso, el parámetro de configuración por defecto que define el RTT máximo posible puede diferir de un servidor de caché a otro dependiendo de sus respectivas ubicaciones en la infraestructura de red móvil. Otra realización es usar el valor de rTt promedio. El valor de RTT promedio es calculado por el servidor de caché CSERV 130 a lo largo del tiempo mediante el análisis de sesiones para distribuir contenidos de audio y/o vídeo a dispositivos clientes. Este enfoque permite alcanzar más rápidamente un tamaño óptimo de transferencia masiva en caso de actualización dinámica del valor de RTT usado para la definición de duración masiva, y es particularmente eficiente para la configuración de CDN sobre una infraestructura de red móvil. Las realizaciones del valor de RTT aplicable enumeradas anteriormente pueden usarse durante una sesión completa de distribución de contenido de audio y/o vídeo, o usarse como configuración inicial y, a continuación, actualizarse dinámicamente de acuerdo con mediciones de RTT.
En una etapa 502, el servidor de caché CSERV 130 calcula un tamaño mínimo de transferencia masiva mTBS. Suponiendo N representaciones del contenido de audio y/o vídeo (i = 1,...,N), teniendo cada representación una tasa de bits promedio Bi, el tamaño mínimo de transferencia masiva mTBS se calcula de la siguiente manera:
mTBS = C0*max (Bl..Bn)*RTT
en donde C0 > 1 es una constante que añade un margen predefinido que compensa errores potenciales en la estimación de RTT y además compensa que Bi es una indicación de tasa de bits promedio (lo que significa que la tasa de bits efectiva puede variar alrededor de esta indicación de tasa de bits promedio).
En una etapa 503, el servidor de caché CSERV 130 calcula una duración masiva mínima mTBDi, con respecto al contenido de audio y/o vídeo, para la representación i que debe distribuirse al dispositivo cliente CL 140, de la siguiente manera:
mTBDi = mTBS / Bi
Con referencia a la figura 3, la duración masiva mínima mTBDi (i = 1,...,N) corresponde al valor mínimo de tB, expresado preferentemente en segundos.
El servidor de caché CSERV 130 puede calcular la duración masiva mínima mTBDi, para cualquier representación i (i = 1,...,N) cada vez que se obtiene un nuevo valor de RTT (puede ser para toda la sesión). Como alternativa, el servidor de caché CSERV 130 sólo calcula, cada vez que se obtiene un nuevo valor de RTT (puede ser para toda la sesión), la duración masiva mínima mTBDi, para la representación i (i = 1,...,N) que necesita ser distribuido al dispositivo cliente CL 140.
En una etapa 504, el servidor de caché CSERV 130 distribuye los datos de contenido de audio y/o vídeo en forma de masas de fragmentos sucesivos, por ejemplo recibidos desde el servidor de origen OSERV 150 o desde un servidor intermedio aguas arriba). El servidor de caché CSERV 130 transfiere cada masa como una ráfaga de datos. El servidor de caché CSERV 130 distribuye el contenido de audio y/o vídeo mediante transferencias en ráfaga en forma de L masas de al menos un fragmento o fragmentos agregados sucesivos para cada segmento, las L masas (L > 1) que contienen conjuntamente datos de contenido de audio y/o vídeo correspondientes a dicho segmento, y, para cada segmento, al menos L-1 masa o masas están formadas respectivamente por M fragmento o fragmentos que confirman las siguientes condiciones:
M
^ CHj > mTBDi
7 = 1
y
M — 1
^ CHj < m TBD i
7 = 1
en donde i indica la representación a distribuir al cliente CL 140, y que, por tanto, puede cambiar con el tiempo durante la sesión,
y en donde CHj (j = 1,...,M) representa la duración temporal del fragmento j con respecto al contenido de audio y/o vídeo.
En otras palabras, la duración de segmento puede no corresponder exactamente con L masas de fragmentos que cumplan las condiciones anteriores. En este caso, las masas L-1 cumplen las condiciones anteriores y una masa tiene una duración inferior. Preferentemente, este lote de duración inferior es el último en transmitirse para el segmento en cuestión.
Cabe señalar que, por defecto, todos los fragmentos tienen la misma duración, pero es posible que la duración del fragmento cambie por algún motivo.
En una realización preferida, los M fragmentos sucesivos se seleccionan de modo que el primer fragmento (j = 1) de la masa considerada es el siguiente en secuencia que aún no se ha transmitido al dispositivo cliente CL 140.
Por tanto, cuando el dispositivo cliente CL 140 solicita un segmento del contenido de audio y/o vídeo, el servidor de caché CSERV 130 distribuye, mediante transferencias en ráfaga, fragmentos agregados que forman masas como se ha definido anteriormente. Dado que la forma en que se agregan los fragmentos para formar las masas depende del valor de RTT, la estimación del ancho de banda es fiable y, en consecuencia, la representación apropiada del contenido de audio y/o vídeo puede ser seleccionada, ya sea por el dispositivo cliente Cl 140 o por el servidor de caché CSERV 130, y ser distribuida, mejorando así la QoE.
Cuando la duración de las masas se adapta dinámicamente durante la sesión debido al valor de RTT refinado o a la evolución monitorizada del valor de RTT, puede ser interesante comenzar con la representación de la más alta calidad del contenido de audio y/o vídeo para obtener rápidamente un valor de ancho de banda disponible preciso. Este es particularmente el caso cuando la selección de representación de contenido de audio y/o vídeo es realizada por el servidor de caché CSERV 130.
La figura 6 representa esquemáticamente un algoritmo para gestionar solicitudes de segmento, en una realización particular. Antes de la solicitud de segmento, el dispositivo cliente CL 140 debe solicitar un archivo declarativo. El servidor de caché CSERV 130 obtiene el archivo declarativo del servidor de origen OSERV 150 y lo reenvía al dispositivo cliente CL 140 previa solicitud.
El tiempo adecuado para que el dispositivo cliente CL 140 solicite un segmento se determina habitualmente (por ejemplo, de acuerdo con MPEG dAs H) en una tasa de bits adaptable de baja latencia usando información del archivo declarativo. Se indica en el mismo información representativa del momento adecuado para solicitar un segmento. Por ejemplo, en MPEG DASH, esta información se indica indirectamente en un campo llamado desfase de tiempo de disponibilidad, que corresponde a un desfase de tiempo mínimo que el dispositivo cliente CL 140 tiene que restar al instante teórico correspondiente a la disponibilidad de todo el segmento, como ya se ha mencionado. Típicamente, en latencia no baja, el dispositivo cliente CL 140 debe esperar una duración que corresponde a un segmento completo (por ejemplo, 2 segundos) antes de enviar su solicitud de segmento (para asegurarse de que el segmento haya sido recibido en su totalidad por el servidor de caché) y, por lo tanto, el valor de desfase de tiempo de disponibilidad es 0 o no está presente en el archivo declarativo. En latencia baja, el dispositivo cliente puede enviar su solicitud de segmento tan pronto como al menos un fragmento haya sido recibido por el servidor de caché y, por lo tanto, el valor de desfase de tiempo de disponibilidad corresponde a la duración de un segmento menos la duración de un fragmento. Por ejemplo, si la duración del segmento corresponde a 2 segundos del contenido de audio y/o vídeo y la duración de los fragmentos corresponde a 40 milisegundos del contenido de audio y/o vídeo, el valor de desfase de tiempo de disponibilidad se fija en 1.860 milisegundos. En términos generales, el archivo declarativo indica que la solicitud de segmento se puede realizar tan pronto como un fragmento esté teóricamente disponible.
Debido a que, de acuerdo con el valor de RTT, la duración masiva puede ser diferente entre sesiones o puede actualizarse dinámicamente, y dado que la información representativa del momento adecuado para solicitar un segmento (por ejemplo, desfase de tiempo de disponibilidad de acuerdo con MPEG DASH) es estática en el archivo declarativo, puede ocurrir que el dispositivo cliente CL 140 solicite un segmento para el que aún no están disponibles suficientes datos de fragmento para formar una masa apropiada y comenzar a enviar la respuesta.
Para evitar devolver un código de error al dispositivo cliente CL 140 en dicha situación, se propone que el servidor de caché CSERV 130 espere antes de enviar la parte inicial de la respuesta (primera masa en la secuencia) al dispositivo cliente CL 140 hasta que estén disponibles suficiente datos de fragmento para formar una primera masa apropiada para ser distribuida al dispositivo cliente CL 140, como se divulga en el presente documento con respecto a la figura 6. Posteriormente, el servidor de caché CSERV 130 hace lo mismo para el resto de la respuesta de segmento: esperar hasta que suficientes datos de fragmentos estén disponibles para formar una masa apropiada para ser distribuida al dispositivo cliente CL 140, como se divulga en el presente documento con respecto a la figura 6 y así sucesivamente hasta que se envíe la respuesta de segmento completa.
El servidor de caché CSERV 130 recibe, en una etapa 601, una solicitud de segmento del dispositivo cliente CL 140. Se supone que el servidor de caché CSERV 130 responde a la solicitud transmitiendo ráfagas de fragmentos correspondientes al segmento en cuestión.
En una etapa 602, el servidor de caché CSERV 130 verifica si suficientes de dichos fragmentos están disponibles en la memoria caché para construir una masa, como se define en el presente documento, para ser transferida al dispositivo cliente CL 140. Si suficientes fragmentos están disponibles en la memoria caché, el servidor de caché CSERV 130, se realiza una etapa 603 durante la cual el servidor de caché CSERV 130 inicia la transmisión de la masa de fragmentos al dispositivo cliente CL 140; de lo contrario, en una etapa 604, el servidor de caché CSERV 130 bloquea el procesamiento de la solicitud de segmento. La construcción y la transmisión de la masa se bloquean hasta que suficientes fragmentos estén disponibles en la memoria caché para construir dicha masa, como se define en el presente documento, para ser transferida al dispositivo cliente CL 140, y a continuación se realiza la etapa 604 en concordancia. En la etapa 605, el servidor de caché CSERV 130 verifica si esta fue la última masa de datos que se debe transferir. Si no, continúa volviendo cíclicamente a la etapa 602. De lo contrario, en una etapa 606, este es el final de la transmisión del segmento. Cabe señalar que, como ya se mencionó, la última masa de datos puede tener una duración menor que la masa o masas previas, ya que el número total de fragmentos para el segmento dividido por M (el número óptimo de fragmentos para formar una masas), como se calculó anteriormente, puede no ser igual a un número entero.
La figura 7 representa esquemáticamente un algoritmo para distribuir datos de contenido de audio y/o vídeo en forma de masas de fragmentos mediante transferencias en ráfaga, en otra realización particular. Se usa HTTP preferentemente en el ámbito de la figura 7.
Con HLS en un enfoque de baja latencia, de manera similar a MPEG DASH, el archivo declarativo, denominado aquí lista de reproducción, recopila información de duración de fragmento (siendo los fragmentos denominados segmentos parciales de acuerdo con la terminología de HLS) indicados en la lista de reproducción a través de un llamado atributo PART-TARGET. Lo que difiere de MPEG DASH es que el dispositivo cliente CL 140 solicita explícitamente segmentos parciales, típicamente usando una información de rango de bytes, mientras que en MPEG DASH, el dispositivo cliente CL 140 solicita un segmento particular, que se distribuye mediante ráfagas de fragmentos sin que los límites sean conocidos de antemano para el dispositivo cliente CL 140.
Dado que HLS en el enfoque de baja latencia define que el dispositivo cliente CL 140 solicita explícitamente los segmentos parciales (fragmentos), la duración masiva no se puede cambiar dinámicamente durante la sesión. Sin embargo, la duración del segmento parcial, como se indica en la lista de reproducción, se puede adaptar para que sea igual al tamaño masivo en función de la sesión. Para hacerlo, el valor de RTT debe ser conocido por el servidor de caché CSERV 130. Se implementa una característica de redirección particular para permitir que el servidor de memoria caché CSERV 130 obtenga el valor de RTT a usar, como se detalla a continuación.
En una etapa 701, el servidor de caché CSERV 130 recibe una solicitud de lista de reproducción (o archivo declarativo) desde el dispositivo cliente CL 140. La lista de reproducción solicitada corresponde a un contenido de audio y/o vídeo que, a continuación, será distribuido al dispositivo cliente CL 140. En una etapa 702, en lugar de responder a esto transmitiendo la lista de reproducción solicitada (o archivo declarativo), el servidor de caché CSERV 130 redirige el dispositivo cliente CL 140 hacia la misma URL que se usó en la solicitud de lista de reproducción recibida en la etapa 701 de señalar el contenido de audio y/o vídeo al que se refiere la lista de reproducción solicitada. Para ello, el servidor de caché CSERV 130 transmite un mensaje de redirección (redirigir HTTP) al dispositivo cliente CL 140. Al hacerlo, el servidor de caché CSERV 130 obliga al dispositivo cliente CL 140 a retransmitir la solicitud de lista de reproducción (o archivo declarativo).
Por lo tanto, en una etapa 703, el servidor de caché CSERV 130 recibe nuevamente la solicitud de lista de reproducción (o archivo declarativo) desde el dispositivo cliente CL 140.
A continuación, en una etapa 704, el servidor de caché CSERV 130 calcula el valor de RTT, que se estima que es la diferencia de tiempo desde el instante en que el servidor de caché CSERV 130 redirigió el dispositivo cliente CL 140 hasta el instante en que el servidor de caché CSERV 130 recibió nuevamente la solicitud de lista de reproducción (o archivo declarativo) desde el dispositivo cliente CL 140.
En una etapa 705, el servidor de caché CSERV 130 calcula el tamaño mínimo de transferencia masiva mTBS como ya se explicó con respecto a la figura 5.
En una etapa 706, el servidor de caché CSERV 130 calcula la duración masiva mínima mTBDi, con respecto al contenido de audio y/o vídeo, para cada representación i (i = 1,...,N) que posiblemente tiene que ser distribuida al dispositivo cliente CL 140, como ya se ha explicado con respecto a la figura 5. Las duraciones masivas mínimas mTBDi (i = 1,...,N) son aplicables a lo largo de toda la sesión.
En una etapa 707, el servidor de caché CSERV 130 construye una lista de reproducción para ser transmitida al dispositivo cliente CL 140. La lista de reproducción (o archivo declarativo) indica una duración de los segmentos parciales que es igual a la duración de la masa de fragmentos como se define en función del valor de RTT. En una realización particular, el servidor de caché CSERV 130 ajusta la información de lista de reproducción (o la información de archivo declarativo) obtenida del servidor de origen OSERV 150 para que la lista de reproducción indique una duración de los segmentos parciales que sea igual a la duración de la masa de fragmentos como se define como función del valor de RTT. El servidor de caché CSERV 130 transmite la lista de reproducción (o archivo declarativo) así construida, o ajustada, al dispositivo cliente CL 140.
En una etapa 708, el servidor de caché CSERV 130 distribuye los datos de contenido de audio y/o vídeo en forma de masas de fragmentos sucesivos mediante transferencias en ráfaga. Cada masa tiene un tamaño que corresponde al menos a un fragmento y como máximo a M fragmentos sucesivos, como ya se ha explicado con respecto a la figura 5.
Por tanto, cada vez que el dispositivo cliente CL 140 solicita un segmento parcial del contenido de audio y/o vídeo, el servidor de caché CSERV 130 distribuye, mediante transferencias en ráfaga, fragmentos agregados que forman una masa como se definió anteriormente, que corresponde a la duración del segmento parcial publicado en la lista de reproducción El dispositivo cliente CL 140 encuentra consistente la forma en que responde el servidor de caché CSERV 130, ya que la duración de los segmentos parciales como se indica en la lista de reproducción coincide con la duración de la masa de fragmentos como se define en función del valor de RTT.

Claims (12)

REIVINDICACIONES
1. Un procedimiento para distribuir un contenido de audio y/o vídeo usando emisión en continuo adaptable desde un servidor de caché a un dispositivo cliente, estando segmentado el contenido de audio y/o vídeo en segmentos de datos disponibles en diversas representaciones con calidades de audio y/o vídeo respectivas, estando las representaciones alineadas en el tiempo por segmento, estando los segmentos divididos además en fragmentos, en donde el procedimiento comprende:
- obtener un valor temporal de ida y vuelta aplicable entre el servidor de caché y el dispositivo cliente;
- calcular un tamaño mínimo de transferencia masiva mTBS a partir de la tasa de bits promedio máxima de las diversas representaciones del contenido de audio y/o vídeo y a partir del valor temporal de ida y vuelta obtenido; - calcular una duración masiva mínima mTBDi, con respecto al contenido de audio y/o vídeo, para la representación i del contenido de audio y/o vídeo que tiene que ser distribuido al dispositivo cliente; y
- distribuir el contenido de audio y/o vídeo mediante transferencias en ráfaga en forma de L masas de al menos un fragmento o fragmentos agregados sucesivos para cada segmento, conteniendo las L masas conjuntamente datos de contenido de audio y/o vídeo correspondientes a dicho segmento,
y en donde, para cada segmento, al menos L-1 masa o masas están formadas respectivamente por M fragmento o fragmentos de modo que
Figure imgf000012_0001
y
M —1
^ CHj < m TBD i
7 = 1
en donde CHj (j = 1,...,M) representa la duración temporal del fragmento j con respecto al contenido de audio y/o vídeo.
2. El procedimiento de acuerdo con la reivindicación 1, en donde el valor temporal de ida y vuelta es almacenado por el servidor de caché como un parámetro de configuración por defecto y corresponde al tiempo de ida y vuelta máximo posible que debe gestionar el servidor de caché cuando distribuye datos de contenido de audio y/o vídeo a cualquier dispositivo cliente.
3. El procedimiento de acuerdo con la reivindicación 1, en donde el valor temporal de ida y vuelta es el valor temporal de ida y vuelta promedio calculado por el servidor de caché a lo largo del tiempo mediante el análisis de sesiones para distribuir contenido de audio y/o vídeo a dispositivos clientes.
4. El procedimiento de acuerdo con la reivindicación 2 o 3, en donde dicho valor temporal de ida y vuelta se usa como configuración inicial y definición del tamaño mínimo de transferencia masiva mTBS y la duración masiva mínima mTBDi, y a continuación se actualiza dinámicamente, así como el tamaño mínimo de transferencia masiva mTBS y la duración masiva mínima mTBDi, de acuerdo con mediciones del tiempo de ida y vuelta entre el servidor de caché y el dispositivo cliente.
5. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 3, en donde se usa el mismo valor temporal de ida y vuelta durante una sesión completa de distribución de contenido de audio y/o vídeo.
6. El procedimiento de acuerdo con la reivindicación 5, en donde para obtener el valor temporal de ida y vuelta, el servidor de caché, al recibir desde el dispositivo cliente una solicitud para obtener una lista de reproducción o un archivo declarativo relacionado con el contenido de audio y/o vídeo, el servidor de caché redirige el dispositivo cliente para obligar al dispositivo cliente a retransmitir la solicitud en cuestión, y calcula el valor temporal de ida y vuelta como la diferencia de tiempo desde el instante en que el servidor de caché redirigió el dispositivo cliente hasta el instante en que el servidor de caché recibe de nuevo la solicitud en cuestión desde el dispositivo cliente.
7. El procedimiento de acuerdo con la reivindicación 6, en donde el servidor de caché indica en la lista de reproducción o el archivo declarativo que una duración de segmentos parciales es igual a la duración de la masa de fragmentos como se define en función del valor temporal de ida y vuelta.
8. El procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 5, en donde un archivo declarativo relacionado con el contenido de audio y/o vídeo indica que la solicitud de segmento se puede realizar tan pronto como un fragmento esté teóricamente disponible, y en donde el servidor de caché bloquea el procesamiento de una solicitud de segmento recibida desde el dispositivo cliente hasta que suficientes fragmentos del segmento solicitado estén disponibles en la memoria caché para construir la masa que se transmitirá en respuesta.
9. Un producto de programa informático que comprende instrucciones de código de programa que se pueden cargar en un dispositivo programable para implementar el procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 8, cuando las instrucciones de código de programa son ejecutadas por el dispositivo programable.
10. Un medio de almacenamiento de información que almacena un programa informático que comprende instrucciones de código de programa que pueden cargarse en un dispositivo programable para implementar el procedimiento de acuerdo con una cualquiera de las reivindicaciones 1 a 8, cuando las instrucciones de código de programa son leídas desde el medio de almacenamiento de información y son ejecutadas por el dispositivo programable.
11. Un servidor de caché configurado para distribuir un contenido de audio y/o vídeo usando emisión en continuo adaptable a un dispositivo cliente, estando segmentado el contenido de audio y/o vídeo en segmentos de datos disponibles en diversas representaciones con calidades de audio y/o vídeo respectivas, estando las representaciones alineadas en el tiempo por segmento, estando los segmentos divididos además en fragmentos, en donde el servidor de caché comprende circuitos electrónicos configurados para:
- obtener un valor temporal de ida y vuelta aplicable entre el servidor de caché y el dispositivo cliente;
- calcular un tamaño mínimo de transferencia masiva mTBS a partir de la tasa de bits promedio máxima de las diversas representaciones del contenido de audio y/o vídeo y a partir del valor temporal de ida y vuelta obtenido; - calcular una duración masiva mínima mTBDi, con respecto al contenido de audio y/o vídeo, para la representación i del contenido de audio y/o vídeo que tiene que ser distribuido al dispositivo cliente; y
- distribuir el contenido de audio y/o vídeo mediante transferencias en ráfaga en forma de L masas de al menos un fragmento o fragmentos agregados sucesivos para cada segmento, conteniendo las L masas conjuntamente datos de contenido de audio y/o vídeo correspondientes a dicho segmento,
y en donde, para cada segmento, al menos L-1 masa o masas están formadas respectivamente por M fragmento o fragmentos de modo que
M
^ CHj > mTBDi
7 = 1
y
M — l
^ CHj < m T B D i
j =i
en donde CHj(j = 1,...,M) representa la duración temporal del fragmento j con respecto al contenido de audio y/o vídeo.
12. Una red de distribución de contenido que incluye el servidor de caché de acuerdo con la reivindicación 11.
ES20315225T 2020-04-27 2020-04-27 Procedimiento y servidor para la distribución de contenido de audio y/o vídeo Active ES2940452T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20315225.1A EP3905708B1 (en) 2020-04-27 2020-04-27 Method and server for audio and/or video content delivery

Publications (1)

Publication Number Publication Date
ES2940452T3 true ES2940452T3 (es) 2023-05-08

Family

ID=70977898

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20315225T Active ES2940452T3 (es) 2020-04-27 2020-04-27 Procedimiento y servidor para la distribución de contenido de audio y/o vídeo

Country Status (9)

Country Link
US (1) US11812114B2 (es)
EP (1) EP3905708B1 (es)
JP (1) JP2023522895A (es)
KR (1) KR20230002784A (es)
CA (1) CA3176231A1 (es)
ES (1) ES2940452T3 (es)
IL (1) IL297561A (es)
MX (1) MX2022013136A (es)
WO (1) WO2021219563A1 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4158848A4 (en) * 2020-05-29 2023-07-26 Telefonaktiebolaget LM Ericsson (PUBL) METHODS AND ARRANGEMENTS TO SUPPORT THE ESTIMATION OF LATENCY ACROSS A COMMUNICATION PATH IN A COMMUNICATION NETWORK
EP4002793B1 (en) * 2020-11-13 2024-01-03 Broadpeak Method and controller for audio and/or video content delivery
US11606277B2 (en) * 2021-02-10 2023-03-14 Cohesity, Inc. Reducing the impact of network latency during a restore operation
US12452328B2 (en) 2023-06-12 2025-10-21 Akamai Technologies, Inc. Server-side adaptive bitrate streaming (ABR) with manifest file encoding

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2362651A1 (en) * 2010-02-19 2011-08-31 Thomson Licensing Multipath delivery for adaptive streaming
EP2375680A1 (en) * 2010-04-01 2011-10-12 Thomson Licensing A method for recovering content streamed into chunk
US20140136653A1 (en) * 2012-02-27 2014-05-15 Qualcomm Incorporated Dash client and receiver with download rate acceleration
EP2908535A4 (en) * 2012-10-09 2016-07-06 Sharp Kk Content transfer device, content playback device, content distribution system, method for controlling a content transfer device, method for controlling a content playback device, control program and recording medium
KR101942208B1 (ko) * 2015-01-08 2019-01-24 애리스 엔터프라이지즈 엘엘씨 Dlna http 스트리밍 클라이언트들을 위한 서버측 적응형 비트 레이트 제어
US10771833B2 (en) * 2016-05-31 2020-09-08 The Trustees Of Princeton University System and method for improving streaming video via better buffer management
US11617019B2 (en) * 2016-07-28 2023-03-28 Qualcomm Incorporated Retrieving and accessing segment chunks for media streaming
US10567461B2 (en) * 2016-08-04 2020-02-18 Twitter, Inc. Low-latency HTTP live streaming
KR101837637B1 (ko) * 2016-12-08 2018-03-13 서울대학교산학협력단 클라이언트 측 ack 조정 기반 적응 스트리밍 방법 및 장치
GB201812862D0 (en) * 2018-08-08 2018-09-19 British Telecomm Improved congestion response

Also Published As

Publication number Publication date
MX2022013136A (es) 2022-11-10
KR20230002784A (ko) 2023-01-05
EP3905708B1 (en) 2022-12-21
CA3176231A1 (en) 2021-11-04
JP2023522895A (ja) 2023-06-01
EP3905708A1 (en) 2021-11-03
US11812114B2 (en) 2023-11-07
IL297561A (en) 2022-12-01
WO2021219563A1 (en) 2021-11-04
US20230143627A1 (en) 2023-05-11

Similar Documents

Publication Publication Date Title
ES2940452T3 (es) Procedimiento y servidor para la distribución de contenido de audio y/o vídeo
US11949512B2 (en) Retransmission of data in packet networks
EP2537340B1 (en) Multipath delivery for adaptive streaming
US9043467B2 (en) Adaptive chunked and content-aware pacing of multi-media delivery over HTTP transport and network controlled bit rate selection
US9565482B1 (en) Adaptive profile switching system and method for media streaming over IP networks
CN111740808A (zh) 一种数据传输方法及装置
US9596323B2 (en) Transport accelerator implementing client side transmission functionality
CN108494454A (zh) 链路感知流传输自适应
BR112015000117B1 (pt) Dispositivo de rede para suportar streaming de mídia adaptativo baseado em qualidade em uma rede
BR112014013006B1 (pt) Dispositivo e método para obter conteúdo por pelo menos dois protocolos de transporte tendo diferentes requisitos em termos de largura de banda de rede disponível
CN105191334A (zh) 用于自适应比特率视频回放的基于调度器的网络虚拟播放器
US10735485B2 (en) Technique for adaptive streaming of temporally scaling media segment levels
KR20130112936A (ko) 적응적 스트리밍 서비스를 제공하기 위한 방법
KR20160026886A (ko) 멀티미디어 컨텐츠를 수신하도록 구성되는 클라이언트 단말기의 다운로딩 거동을 적응시키는 방법 및 대응 단말기
KR20140023983A (ko) 수신 비트율 및 연관된 수신기의 동적 적응 방법
KR20150086110A (ko) 부호화된 비디오 스트림 전송 장치 및 방법
JP6970124B2 (ja) Ｍｍｔｐパケットを送受信する方法及びその装置
CN116320532B (zh) 调整串流延迟方法及装置
GB2588930A (en) Multimedia system &amp; method
US11973814B2 (en) Method and controller for audio and/or video content delivery
CN121262396A (zh) 基于8k机顶盒的拥塞控制方法、传输方法、控制装置、终端及介质
Sajid Mushtaq et al. QoE Approaches for Adaptive Transport of Video Streaming Media
EP2816782A1 (en) Node and methods for use in TCP friendly HAS content distribution systems