ES2961465T3 - Transmisión de flujo de datos adaptable - Google Patents

Transmisión de flujo de datos adaptable Download PDF

Info

Publication number
ES2961465T3
ES2961465T3 ES20209367T ES20209367T ES2961465T3 ES 2961465 T3 ES2961465 T3 ES 2961465T3 ES 20209367 T ES20209367 T ES 20209367T ES 20209367 T ES20209367 T ES 20209367T ES 2961465 T3 ES2961465 T3 ES 2961465T3
Authority
ES
Spain
Prior art keywords
terminal
equipment
adaptation
session
telecommunications
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
ES20209367T
Other languages
English (en)
Inventor
Selim Ellouze
Gaël Fromentoux
Xavier Marjou
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.)
Orange SA
Original Assignee
Orange 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 Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2961465T3 publication Critical patent/ES2961465T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • H04L65/1089In-session procedures by adding media; by removing media
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/756Media network packet handling adapting media to device capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La invención se refiere a un método para transmitir flujos de datos previamente codificados según una codificación adaptable entre un equipo de telecomunicaciones (1) y un terminal (2) mediante una sesión establecida según un protocolo de transporte basado en HTTP, caracterizado porque comprende las etapas de : recopilación (34, 35, 37, 38), por parte del equipo, de un conjunto de información de contexto que comprende información relativa a la sesión e información relativa a una menos dicho equipo y terminal; formación de un esquema de adaptación según el conjunto de información de contexto, adaptación (36, 39) del flujo de datos por dicho equipo según el esquema de adaptación, y transmisión (36, 39) de los datos de flujo adaptados por dicho equipo al terminal . La invención también se refiere a un método de recepción de flujo correspondiente, a un equipo de telecomunicaciones, a un terminal de comunicaciones, a un sistema de telecomunicaciones, a un programa informático y a un medio de grabación. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Transmisión de flujo de datos adaptable
El campo de la invención es el de la transmisión de flujo de datos en una red de telecomunicaciones.
La presente invención se refiere, más particularmente, la transmisión de flujo de datos adaptable entre un servidor y un terminal entre los cuales está abierta una sesión que responde al protocolo HTTP o a un protocolo basado en HTTP.
A modo de ejemplo de flujo de datos adaptable, el "Scalable Video Coding" (SVC) es una tecnología estandarizada [Amendment 3 to ISO/IEC 14496 MPEG-4 Part 10] de compresión de contenido de vídeo utilizada para hacer una adaptación del contenido en tres dimensiones diferentes: bien en la dimensión espacial (diferentes resoluciones del vídeo), bien temporal (diferentes frecuencias) o bien de calidad (diferentes SNR "Signal to Noise Ratio"). El flujo de vídeo está compuesto por varios subflujos, llamados capas. Un ejemplo típico es la separación de un flujo de vídeo en 2 capas: una capa de base y una capa de mejora. Por ejemplo, cuando el ancho de banda entre el cliente y el servidor está restringido, solamente se envía al cliente el subflujo de base. Cuando el ancho de banda entre el cliente y el servidor aumenta, el subflujo de mejora se añade al flujo transmitido al cliente. Cabe señalar que la capa de base SVC es compatible con MPEG4-AVC que la mayoría de los terminales y servidores actuales implementan.
El transporte del contenido de vídeo SVC se realiza mediante el protocolo RTP (Real-time T ransport Protocol), durante la normalización en el IETF [draft-ietf-avt-rtp-svc-20].
Ahora bien, el protocolo RTP no es completamente satisfactorio, en concreto por las siguientes razones:
- el problema principal es que el flujo RTP no puede pasar los cortafuegos ("firewalls") que bloquean el tráfico en cualquier puerto distinto del puerto web 80,
- el flujo RTP debe ser transmitido, en general, del servidor (zona pública) hacia el cliente (zona privada), lo que requiere un paso de NAT (Network Address Translation) extremadamente difícil,
- el protocolo RTP no está integrado de forma innata en los navegadores web y son necesarios módulos adicionales,
- es difícil, en presencia de NAT, a nivel del servidor de VOD (Video On Demand) establecer el enlace entre los flujos de control (por ejemplo: SIP o RTSP) y los flujos RTP,
- los flujos de vídeo SVC transportados por RTP necesitan estar sincronizados con los flujos de audio transportados en otra sesión RTP.
Es por esto por lo que otros protocolos están previstos, tales como el protocolo HTTP (HyperText Transfer Protocol) o el protocolo WSP (Web Socket Protocol), que está basado en HTTP, al tiempo que le aporta mejoras.
La utilización de HTTP como protocolo de transporte presenta varias ventajas, ya que este protocolo resuelve cierto número de problemas. Por un lado, el puerto 80 asociado a los datos HTTP no está bloqueado por los equipos intermediarios (proxy, firewall,...) lo que no es el caso en puertos asociados a otros protocolos. En segundo lugar, el protocolo HTTP es un protocolo abierto y los servidores HTTP están ampliamente desplegados lo que ofrece un parque ya existente y listo para la explotación. En tercer lugar, el protocolo HTTP es un protocolo de transferencia de datos y, por lo tanto, puede ser aprovechado para multiplexar diferentes salidas de datos como el "chat", los votos en línea, los juegos interactivos de preguntas/respuestas, etc., lo que enriquece las sesiones multimedia convencionales y ofrece un amplio abanico para aplicaciones innovadoras.
El protocolo WSP es una evolución del protocolo HTTP que puede aprovechar la misma sesión de transporte que este último: puerto convencional 80 o puerto seguro 443. El protocolo WSP permite tener, además una vía de comunicación de dos sentidos entre dos extremos sin recurrir a la apertura de varias sesiones HTTP. Los datos pueden ser transmitidos en modo "Push" lo que es muy interesante para los flujos con restricciones de plazo.
De este modo, se han desarrollado técnicas de "streaming" adaptativo en HTTP para ofrecer una mejor calidad de experiencia (QoE) a los usuarios ofreciendo posibilidades de adaptación durante la sesión. Se trata de conmutar entre los flujos disponibles en el lado del servidor, exclusivamente en función del ancho de banda.
Se trata de soluciones patentadas. Por ejemplo, se utiliza un servidor web convencional y un cliente a descargar o implementar por defecto en el terminal cliente. En el lado del servidor, el flujo audiovisual se corta en segmentos que contienen, cada uno, un cierto periodo de tiempo del flujo (por ejemplo, 10 s). Cabe señalar que el corte de los archivos en trozos (chunks) no está estandarizado y que cada uno de los promotores de esta técnica ha utilizado una solución que le es propia. El reensamblaje de los segmentos en el lado del cliente restituye el flujo decodificable. El servidor crea un nuevo enlace para cada segmento y lo almacena en un archivo de indexación. El cliente descarga este archivo cuando solicita el flujo y a continuación comienza a descargar los segmentos desde los enlaces que encuentra en el archivo. Este archivo de indexación se formatea siguiendo modelos definidos por cada firma. Este archivo contiene otras informaciones sobre los segmentos y el flujo. El archivo de indexación debe ser descargado periódicamente para conocer los enlaces hacia los nuevos segmentos. En función de las informaciones recibidas y de su estimación del ancho de banda, el cliente decide los segmentos a descargar.
Las técnicas conocidas de streaming adaptativo en HTTP presentan un cierto número de inconvenientes. Se pueden citar, por ejemplo:
- Periodo de espera inicial: los archivos de indexación deben contener tres o más segmentos antes de estar disponibles para la descarga. Para contenidos "live", hay que esperar a la codificación y la indexación de al menos tres segmentos, lo que hace al periodo de espera inicial entre el instante de solicitud de flujo y el instante de lectura significativo. En "live streaming" y con un tamaño de segmento igual a 10 s, puede esperar 30 segundos.
- Los archivos índice son generadores de problemas. Hay que descargar un archivo índice y actualizarlo periódicamente. Este archivo contiene los enlaces hacia los segmentos del archivo media e informaciones sobre los segmentos, su estructuración y los datos que transportan. Este método presenta 3 inconvenientes principales: - Las solicitudes/respuestas periódicas entre el servidor y los clientes desperdician ancho de banda y constituyen una carga suplementaria para los servidores.
- El archivo de indexación necesita un servicio fiable, ya que la no recepción o la presencia de error puede generar cortes.
- Los mecanismos de caché en las pasarelas web pueden impedir la actualización del último archivo de indexación creado por el servidor y la transmisión del último archivo guardado en el caché de la pasarela. - Los flujos son estáticos y de formato predeterminado: las diferentes representaciones del flujo proponen velocidades de transferencia diferentes, pero están predeterminadas. Los clientes deben elegir entre lo que existe y no pueden aspirar a una adaptación personalizada. En paralelo, el corte del flujo en segmentos de igual tamaño no permite respetar los límites de los paquetes y de las imágenes Intra-codificadas. Estas imágenes constituyen el punto de conmutación entre representaciones diferentes de un mismo contenido. Este corte minimiza, por lo tanto, el número eventual de punto de conmutación entre las diferentes representaciones.
- La adaptación es rudimentaria: las técnicas propuestas soportan únicamente la conmutación entre representaciones de calidad diferentes, pero no características diferentes como la resolución espacial o la frecuencia temporal.
- El servidor es pasivo: la decisión para conmutar hacia un flujo más adaptado se toma únicamente en el lado del cliente. El servidor no es capaz de intervenir.
Por otra parte, la solicitud de patente US 2009/0254657 describe una arquitectura de transmisión que utiliza una velocidad de transferencia adaptativa que implica un terminal y un gestor de velocidad de transferencia adaptativa. En esta arquitectura, este gestor de velocidad de transferencia adaptativa determina en un primer momento una velocidad de transferencia de datos óptima para transmitir los datos hacia el terminal, por medio de un controlador de velocidad de transferencia adaptativa, y a continuación distribuye esta velocidad de transferencia óptima entre flujos de vídeo y flujos de audio por medio de un distribuidor de velocidad de transferencia antes de codificar flujos de datos de audio y/o vídeo según esta distribución y de transmitir estos flujos hacia el terminal 102. El controlador de velocidad de transferencia adaptativa calcula esta velocidad de transferencia óptima de transmisión a partir de la estimación de parámetros relativos solamente al estado de la red, tales como el MTT, la velocidad de transferencia de datos recibidos por el terminal, una estimación del tiempo de ida y vuelta o un cómputo de las pérdidas de paquetes durante la transmisión en esta red.
Además, la solicitud de patente 2007/087781 describe una arquitectura para la prestación de servicios de vídeo a un terminal celular, y más concretamente, la prestación de mensajes de vídeo, en donde un flujo es transmitido por un terminal cliente a un servidor de medios de vídeo, y no a otro terminal cliente, con vistas a su registro, siendo este flujo convertido por una pasarela de transcodificación en un único formato de vídeo H.263 antes de llegar a este servidor de soporte de vídeo, sin que la pasarela de transcodificación tenga en cuenta el contexto de este servidor de soporte de vídeo, en particular, al convertir el flujo al formato de vídeo H.263.
La presente invención tiene por objeto resolver los inconvenientes de la técnica anterior.
Con este fin, la invención propone un procedimiento de transmisión de flujo de datos previamente codificado según una codificación adaptable entre un equipo de telecomunicaciones y un terminal mediante una sesión establecida según un protocolo de transporte basado en HTTP, caracterizado porque consta de las etapas de:
- recopilación, por dicho equipo, de un conjunto de informaciones de contexto que comprenden informaciones relativas a la sesión e informaciones relativas a al menos uno de dichos equipo y terminal,
- formación de un esquema de adaptación (SCA) en función del conjunto de informaciones de contexto,
- adaptación del flujo de datos por dicho equipo en función del esquema de adaptación, y
- transmisión del flujo de datos adaptado por dicho equipo hacia el terminal.
Gracias a la invención, las informaciones de contexto transmitidas al primer terminal permiten realizar una adaptación optimizada del flujo de datos.
Por ejemplo, un cliente que cambia de tamaño de pantalla durante la visualización recibirá instantáneamente un flujo de resolución espacial adaptada al nuevo tamaño de pantalla.
La invención no utiliza archivo de indexación lo que permite un ahorro de ancho de banda y una mejor fiabilidad. El periodo de espera inicial antes del comienzo de la lectura depende únicamente del periodo de establecimiento de la sesión de transporte. No es necesario esperar a la codificación de tres segmentos completos para poder transmitir un archivo de indexación al cliente como es el caso para las otras técnicas. El primer paquete es transmitido hacia el terminal al comienzo de la sesión y permite la visualización instantánea por el cliente en espera de la recepción del contexto inicial del cliente y la adaptación del flujo en función de este contexto.
Según una característica preferida, las etapas de recopilación, formación, adaptación y transmisión se efectúan en la inicialización de la sesión y durante la sesión. De este modo, la transmisión del flujo adaptable se optimiza no solamente en función del contexto definido en la inicialización de la sesión, sino también en función de las posibles evoluciones del contexto.
Según una característica preferida, la etapa de recopilación consta de la recepción de un mensaje de señalización transmitido por el terminal. De este modo, el contexto específico del terminal se tiene en cuenta para optimizar la transmisión del flujo adaptable.
Según otra característica ventajosa, dichas informaciones relativas a al menos uno de dichos equipos y terminal comprenden informaciones relativas a la capacidad de memoria intermedia del terminal.
La invención también se refiere a un procedimiento de recepción de un flujo de datos previamente codificado según una codificación adaptable entre un equipo de telecomunicación y un terminal mediante una sesión establecida según un protocolo de transporte basado en HTTP, siendo dicho terminal un terminal cliente, caracterizado porque consta de las etapas de:
- recopilación por el terminal de un conjunto de informaciones de contexto que comprenden informaciones relativas a la sesión e informaciones relativas a al menos uno de dichos equipo y terminal;
- formación de un esquema de adaptación en función del conjunto de informaciones de contexto,
- recepción del flujo de datos por el terminal, y
- adaptación del flujo de datos por el terminal en función del esquema de adaptación.
De este modo, el terminal es capaz de realizar una adaptación adicional del flujo antes de que el flujo sea reproducido para un usuario.
Según una característica preferida, la etapa de recopilación comprende la recepción de un mensaje de señalización transmitido por el terminal. De este modo, el contexto específico del terminal se tiene en cuenta para la adaptación adicional del flujo adaptable.
Según otra característica ventajosa de este terminal, dichas informaciones relativas a al menos uno de dichos equipos y terminal comprenden informaciones relativas a la capacidad de memoria intermedia del terminal.
La invención también se refiere a un equipo de telecomunicaciones capaz de transmitir un flujo de datos previamente codificado según una codificación adaptable hacia un terminal a través de una sesión establecida según un protocolo de transporte basado en HTTP, caracterizado porque comprende:
- medios de recopilación de un conjunto de informaciones de contexto que comprenden informaciones relativas a la sesión e informaciones relativas al menos a uno de dichos equipos y terminal,
- medios de formación de un esquema de adaptación en función del conjunto de informaciones de contexto, - medios de adaptación del flujo de datos en función del esquema de adaptación, y
- medios de transmisión del flujo de datos adaptado hacia el terminal.
Este equipo de telecomunicaciones es, por ejemplo, un servidor.
La invención también se refiere a un terminal de telecomunicaciones capaz de recibir un flujo de datos previamente codificado según una codificación adaptable desde un equipo de telecomunicaciones a través de una sesión establecida según un protocolo de transporte de bajo nivel HTTP, siendo dicho terminal de telecomunicaciones un terminal cliente, caracterizado porque comprende:
- medios de recopilación de un conjunto de informaciones de contexto que comprenden informaciones relativas a la sesión e informaciones relativas a al menos uno de dichos equipos y terminal,
- medios de recepción del flujo de datos,
- medios de formación de un esquema de adaptación en función del conjunto de informaciones de contexto, y - medios de adaptación del flujo de datos en función del esquema de adaptación.
Estos diferentes equipos presentan ventajas análogas a las de los procedimientos descritos anteriormente.
En un modo particular de realización, las diferentes etapas de los procedimientos según la invención son determinadas por instrucciones de programas informáticos.
En consecuencia, la invención también se refiere a un programa informático en un soporte de informaciones, siendo este programa susceptible de ser implementado en un ordenador, constando este programa de instrucciones adaptadas a la implementación de las etapas de un procedimiento tal como se ha descrito anteriormente.
Este programa puede utilizar cualquier lenguaje de programación, y estar en forma de código fuente, código objeto o código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La invención también tiene como propósito un soporte de informaciones legible por un ordenador, y que consta de instrucciones de programas informáticos tales como se han mencionado anteriormente.
El soporte de informaciones puede ser no importa qué entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede constar de un medio de almacenamiento, tal como una ROM, por ejemplo, un CD-ROM o una ROM de circuito microelectrónico, o también un medio de registro magnético, por ejemplo, un disquete (floppy disc) o un disco duro.
Por otra parte, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede encaminarse a través de un cable eléctrico u óptico, por radio o por otros medios. El programa según la invención puede descargarse en particular desde una red de tipo Internet.
Como alternativa, el soporte de información puede ser un circuito integrado en el que está incorporado el programa, estando adaptado el circuito para la ejecución o para ser utilizado en la ejecución del procedimiento en cuestión. Surgirán otras características y ventajas con la lectura de modos de realización preferidos descritos con referencia a las figuras en las que:
- la figura 1 representa un modo de realización de dispositivos según la invención,
- la figura 2 representa un modo de realización de módulo de adaptación según la invención,
- la figura 3 representa un ejemplo de diagrama de intercambios entre un servidor y un terminal cliente según la invención,
- la figura 4 representa un modo de realización de dispositivo según la invención, y
- la figura 5 representa un modo de realización de dispositivo según la invención.
Según un modo de realización de la invención representado en la figura 1, los equipos que implementan la invención son un primer terminal que es un servidor 1 y un segundo terminal que es un terminal cliente 2. El servidor 1 y el terminal cliente 2 constan de medios convencionales para comunicar utilizando el protocolo HTTP o según un protocolo basado en HTTP tal como el protocolo HTTPS ("Secured") o el protocolo WSP (Web Socket Protocol) o incluso el protocolo WSP tunelizado en TLS.
Se describe brevemente la arquitectura en capas del servidor 1 y del terminal 2, comenzando por la capa superior. La capa de aplicación 11,21 consta de una parte de aplicación propiamente dicha y utiliza el protocolo HTTP. El protocolo TCP (Transmission Control Protocol) se utiliza a nivel de la capa de transporte 12, 22. El protocolo IP (Internet Protocol) se utiliza a nivel de la capa de red 13, 23. La capa de conexión de datos 14, 24 especifica en concreto el tramado de los paquetes de datos. Por último, la capa física 15, 25 se refiere a las características físicas de la conexión.
De manera convencional, la conexión entre el servidor y el terminal utiliza equipos intermedios de una red de telecomunicaciones, tales como pasarela, servidor proxy, que no se describirán en el presente documento. Se considera únicamente el servidor 1 y el terminal cliente 2 que son los equipos de extremo de la conexión.
Se considera más particularmente el caso en el que el servidor es capaz de transmitir un flujo multimedia adaptable al terminal.
Un flujo multimedia adaptable es, por ejemplo, un flujo de tipo SVC (Scalable Video Coding).
Según la invención, un módulo de adaptación 110, 210 se añade a nivel de la capa de aplicación del servidor y del terminal cliente.
En el caso en el que la invención es implementada entre dos terminales que se comunican según un modo par a par, hay establecimiento de una sesión WSP que es por naturaleza bidireccional o de dos sesiones HTTP distintas, para transportar los flujos de datos en los dos sentidos.
Con referencia a la figura 2, el módulo de adaptación según la invención, ya sea el módulo de adaptación 110 del servidor 1 o el módulo de adaptación 210 del terminal 2, consta de un conjunto de submódulos o funciones.
Función de recopilación de informaciones y de eventos útiles
La función de recopilación COL es capaz de interactuar con:
- diferentes entidades del terminal para determinar sus características materiales y sus capacidades (tarjetas de red, procesadores gráficos, CPU, memoria, batería, cambio de pantalla (mobile as a STB), comandos aplicativos de usuario (por ejemplo: comandos de magnetoscopio de avance/retorno lento/rápido, pausa"...),
- el usuario para determinar sus derechos, autentificarlo o conocer sus preferencias,
- la sesión de transporte para determinar el estado actual del enlace (ancho de banda, plazo, fluctuación,...). El conjunto de estas informaciones define el contexto. Un contexto es un conjunto de informaciones que caracteriza el entorno de una entidad. Para una sesión de streaming, el contexto es el conjunto de las informaciones relacionadas con esta sesión. Se trata de los dos extremos (las capacidades materiales del servidor y del cliente), del enlace entre los dos (naturaleza del ancho de banda,...), del usuario (crédito, preferencias, historial...).
Este contexto es dinámico ya que varias informaciones pueden variar a lo largo del tiempo. Es por esto por lo que el contexto se define en la inicialización de la sesión y a continuación se reactualiza durante la sesión para seguir las evoluciones de los diferentes componentes del contexto.
El conjunto de las informaciones de contexto se agrega en un descriptor de contexto DC.
El descriptor de contexto DC consta de tres secciones:
• Contexto global: contiene informaciones generales sobre la sesión (Live, VoD, contenido protegido, país autorizado,...)
• Contexto específico del servidor: describe las informaciones relativas al servidor (dirección, propietario, estado, tipos de flujos soportados, mecanismos de autentificación,...)
• Contexto específico del cliente: las informaciones sobre el entorno del cliente (características materiales, capacidades de decodificación CPU-memoria-Buffer, Batería, resolución de visualización del procesador gráfico, interfaz de red, preferencias del cliente,...).
La recopilación de informaciones de contexto se realiza tanto en el lado del terminal cliente como en el lado del servidor. Como se verá en lo sucesivo, el descriptor de contexto generado en un extremo es conformado y transmitido al otro extremo, de modo que estas informaciones de contexto sean procesadas por la función de recopilación del otro extremo.
Función de decisión
La función de decisión DEC recibe el flujo de datos adaptable FD y el descriptor de contexto DC. La función de decisión analiza las informaciones recopiladas, y a continuación define caso por caso un esquema de adaptación optimizado SCA que es aprovechado por la función de adaptación descrita en lo sucesivo. Se distingue el funcionamiento de la función de decisión del lado del servidor y del lado del terminal.
1. Lado del servidor:
Los principales procesamientos realizados por la función de decisión son:
<o>Análisis de la estructura del flujo adaptable. Para poder efectuar una adaptación óptima, hay que poder tener en cuenta todas las posibilidades de adaptación disponibles y conocer todas las características del flujo. El módulo de adaptación necesita saber exactamente:
- La estructura del flujo (el conjunto de capas que forman el flujo y las relaciones de dependencias que existen entre ellas)
- Las características de las capas que forman el flujo (resolución espacial (QCIF, HD,...) calidad, importancia de cada capa,...)
- Las adaptaciones no intuitivas (por ejemplo, transcodificación de varias capas SVC en una capa compatible MPEG-4) soportadas por el flujo. Estas adaptaciones se pueden deducir de un análisis en profundidad del flujo y en ciertas normas de codificación son señalizadas en mensajes particulares.
El conjunto de estas informaciones se guardará en la estructura del descriptor de medios DM y más específicamente en las tes secciones que define: "Media content structure", "media content characteristics" y "media content adaptability". Esta estructura puede ser transmitida:
- al cliente para permitirle efectuar adaptaciones adicionales si lo desea.
- a los equipos intermedios "Media Aware Network Equipment (MANE)" capaces de efectuar adaptaciones en núcleo o periferia de red.
<o>Procesamiento de las informaciones recopiladas por la función de recopilación (carga del servidor, estado de los enlaces salientes,...) y de las informaciones sobre el contexto enviadas por el cliente para determinar un esquema de adaptación SCA lo más en fase con su contexto.
<o>Definición del esquema de adaptación óptimo (conjunto de las acciones a realizar para modificar el flujo de partida a un flujo óptimo para el contexto actual de la sesión con el cliente).
Determinación de las informaciones pertinentes a transmitir a la función de señalización para ser enviadas al cliente.
2. Lado del cliente:
Los principales procesamientos realizados por la función de decisión son:
<o>Procesamiento de las informaciones recopiladas por la función de recopilación (estado del cliente, preferencias del usuario,...) y de las informaciones sobre el contexto enviadas por el servidor para efectuar una adaptación adicional si es necesario.
Determinación de las informaciones pertinentes sobre el contexto a transmitir a la función de señalización para ser enviadas al servidor.
La función de decisión DEC transmite el descriptor de contexto DC y el descriptor de medios DM a la función de terminación de señalización descrita más adelante. También transmite el esquema de adaptación SCA a la función de adaptación.
Función de adaptación del contenido audiovisual
La función de adaptación ADP recibe el flujo adaptable FD y el esquema de adaptación SCA establecido por la función de decisión. Realiza la adaptación propiamente dicha del contenido del flujo adaptable, en función del esquema de adaptación, para restituir un flujo adaptado en salida.
Función de terminación de señalización
La función de terminación de señalización SIG garantiza la comunicación entre los equipos que participa en la sesión. En el lado del servidor, esta función recibe el descriptor de contexto DC y el descriptor de medios DM y los conforma en vista de su transmisión hacia el terminal cliente. Esta transmisión se realiza al comienzo de la sesión y durante la sesión sobre la marcha.
En el lado del terminal cliente, esta función recibe el descriptor de contexto DC y lo conforma en vista de su transmisión hacia el servidor. Esta transmisión se realiza al comienzo de la sesión y durante la sesión sobre la marcha.
Para la transmisión en tiempo real del contexto se puede utilizar un protocolo de descripción de las "Capabilities & Current Context Protocol" (CCCP) o como variante un archivo XML.
Función de acondicionamiento de los datos
En el caso del protocolo WSP, el establecimiento de la sesión Web Socket permite multiplexar varias sesiones de datos. La función de acondicionamiento de los datos CND permite, en concreto, distinguir en el flujo global de datos los diferentes tipos utilizando campos en el formato TLV (Tipo, Longitud, Valor).
La figura 3 representa un diagrama de los intercambios entre el servidor 1 y el terminal cliente 2 durante una sesión en el transcurso de la cual un flujo de datos adaptable es transmitido según la invención.
El intercambio 31 es el establecimiento de la sesión, según el protocolo HTTP o un protocolo basado en HTTP. Se supone que el protocolo WSP es el que se utiliza. Este establecimiento de sesión es convencional.
El terminal envía una solicitud 32 de demanda de un flujo multimedia adaptable al servidor.
El servidor envía 33 la capa de base SVC al terminal.
El terminal recopila las informaciones de contexto y las transmite 34 al servidor, según el protocolo CCCP.
El servidor recopila las informaciones de contexto y las transmite 35 al terminal, según el protocolo CCCP. La recopilación efectuada por cada uno de los equipos consta, en concreto, de recibir eventualmente las informaciones de contexto del otro equipo y tenerlas en cuenta.
Cabe señalar que, si el terminal no transmite información de contexto, por ejemplo, porque no posee el módulo adecuado, el servidor es, no obstante, capaz de efectuar una adaptación del flujo en función de las informaciones de contexto que habrá recopilado.
El servidor forma un esquema de adaptación, adapta el flujo en función de las informaciones de contexto y transmite 36 el flujo adaptado al terminal. El flujo adaptado consta, por ejemplo, de la capa de base y una capa de mejora del flujo SCV. Además, el servidor transmite al terminal un descriptor de medios.
El terminal forma un esquema de adaptación, efectúa adaptaciones adicionales en el flujo recibido en función de las informaciones de contexto y después restituye el flujo adaptado al usuario.
El terminal recopila de nuevo las informaciones de contexto y transmite 37 al servidor estas informaciones de contexto, que, por ejemplo, integran un cambio de un parámetro con respecto a la transmisión 34, según el protocolo CCCP. Asimismo, el servidor recopila de nuevo las informaciones de contexto y transmite 38 al terminal estas informaciones de contexto. Como anteriormente, la recopilación efectuada por cada uno de los equipos consta, en concreto, de recibir eventualmente las informaciones de contexto del otro equipo y tenerlas en cuenta.
El servidor forma de nuevo un esquema de adaptación, readapta el flujo en función de las informaciones de contexto y transmite 39 el flujo adaptado al terminal.
Como anteriormente, el terminal forma un esquema de adaptación, efectúa adaptaciones adicionales en el flujo recibido en función de las informaciones de contexto y después restituye el flujo adaptado al usuario.
La figura 4 representa un primer equipo, tal como un servidor 1 según la invención. Este servidor implementa el procedimiento de transmisión de flujo adaptable según el modo de realización particular descrito anteriormente. Dicho dispositivo comprende, en concreto, una memoria 41 constituida por una memoria tampón, una unidad de procesamiento 42, equipada, por ejemplo, con un microprocesador, y gobernada por el programa informático 43, que implementa el procedimiento según la invención.
En la inicialización, las instrucciones de código del programa informático 43 se cargan, por ejemplo, en una memoria RAM antes de ser ejecutadas por el procesador de la unidad de procesamiento 42. La unidad de procesamiento 42 recibe en la entrada un flujo de datos adaptable FD a procesar. El microprocesador de la unidad de procesamiento 42 implementa las etapas del procedimiento descrito anteriormente, según las instrucciones del programa informático 43. Para ello, el equipo es capaz de comunicarse con otro equipo, llamado segundo terminal, por medio de una sesión establecida según un protocolo de transporte basado en HTTP, y este consta de:
- medios de recopilación de un conjunto de informaciones de contexto relativas a la sesión, al equipo y al segundo terminal,
- medios de formación de un esquema de adaptación en función del conjunto de informaciones de contexto, - medios de adaptación del flujo de datos en función del esquema de adaptación,
- medios de transmisión del flujo de datos adaptado hacia el segundo terminal.
Estos medios son gobernados por el microprocesador de la unidad de procesamiento 42.
La figura 5 representa un segundo equipo, tal como un terminal cliente 2 según la invención. Este terminal implementa el procedimiento de recepción de flujo adaptable según el modo de realización particular descrito anteriormente. Dicho dispositivo comprende, en concreto, una memoria 51 constituida por una memoria tampón, una unidad de procesamiento 52, equipada, por ejemplo, con un microprocesador, y gobernada por el programa informático 53, que implementa el procedimiento según la invención.
En la inicialización, las instrucciones de código del programa informático 53 se cargan, por ejemplo, en una memoria RAM antes de ser ejecutadas por el procesador de la unidad de procesamiento 52. La unidad de procesamiento 52 recibe en la entrada un flujo de datos adaptado a tratar. El microprocesador de la unidad de procesamiento 52 implementa las etapas del procedimiento descrito anteriormente, según las instrucciones del programa informático 53. Para ello, el equipo es capaz de comunicarse con otro equipo, llamado primer terminal, por medio de una sesión establecida según un protocolo de transporte basado en HTTP, y este consta de:
- medios de recopilación de un conjunto de informaciones de contexto relativas a la sesión, al primer terminal y al equipo,
- medios de recepción del flujo de datos,
- medios de formación de un esquema de adaptación en función del conjunto de informaciones de contexto, - medios de adaptación del flujo de datos en función del esquema de adaptación.
Estos medios son gobernados por el microprocesador de la unidad de procesamiento 52.

Claims (14)

REIVINDICACIONES
1. Procedimiento de transmisión de flujo de datos previamente codificado según una codificación adaptable entre un equipo de telecomunicaciones (1) y un terminal (2) por medio de una sesión establecida según un protocolo de transporte basado en HTTP, que consta de las etapas de:
- recopilación, por dicho equipo, de un conjunto de informaciones de contexto que comprende informaciones relativas a la sesión e informaciones relativas a al menos uno de dichos equipo y terminal;
- formación de un esquema de adaptación (SCA) en función del conjunto de informaciones de contexto,
- adaptación del flujo de datos por dicho equipo en función del esquema de adaptación, y
- transmisión del flujo de datos adaptado por dicho equipo al terminal.
2. Procedimiento según la reivindicación 1, caracterizado porque las etapas de recopilación, formación, adaptación y transmisión se efectúan en la inicialización de la sesión y durante la sesión.
3. Procedimiento según una de las reivindicaciones 1 o 2, caracterizado porque la etapa de recopilación comprende la recepción de un mensaje de señalización transmitido por el terminal.
4. Procedimiento según una de las reivindicaciones 1 a 3, en donde dichas informaciones relativas a al menos uno de dichos equipos y terminal comprenden informaciones relativas a la capacidad de memoria intermedia del terminal.
5. Procedimiento de recepción de flujo de datos previamente codificado según una codificación adaptable entre un equipo de telecomunicaciones (1) y un terminal (2) mediante una sesión establecida según un protocolo de transporte basado en HTTP, siendo dicho terminal un terminal cliente, que consta de las etapas de:
- recopilación por el terminal de un conjunto de informaciones de contexto que comprende informaciones relativas a la sesión e informaciones relativas a al menos uno de dichos equipo y terminal;
- formación de un esquema de adaptación (SCA) en función del conjunto de informaciones de contexto,
- recepción del flujo de datos por el terminal, y
- adaptación del flujo de datos por el terminal en función del esquema de adaptación.
6. Procedimiento de recepción según la reivindicación 5, caracterizado porque la etapa de recopilación consta de la recepción de un mensaje de señalización transmitido por el equipo de telecomunicaciones (1).
7. Procedimiento según una de las reivindicaciones 5 a 6, en donde dichas informaciones relativas a al menos uno de dichos equipo y terminal comprenden informaciones relativas a la capacidad de memoria intermedia del terminal.
8. Equipo de telecomunicaciones (1) capaz de transmitir un flujo de datos previamente codificado según una codificación adaptable a un terminal (2) por medio de una sesión establecida según un protocolo de transporte basado en HTTP, que consta:
- medios de recopilación (COL) de un conjunto de informaciones de contexto que comprenden informaciones relativas a la sesión e informaciones relativas al menos a uno de dichos equipo y terminal,
- medios de formación (DEC) de un esquema de adaptación (SCA) en función del conjunto de informaciones de contexto,
- medios de adaptación (ADP) del flujo de datos en función del esquema de adaptación, y
- medios de transmisión del flujo de datos adaptado al terminal.
9. Equipo de telecomunicaciones según la reivindicación 8, en donde las informaciones relativas a al menos uno de dichos equipo y terminal comprenden informaciones relativas a la capacidad de memoria intermedia del terminal.
10. Terminal de telecomunicaciones (2) capaz de recibir un flujo de datos previamente codificado según una codificación adaptable desde un equipo de telecomunicaciones (1) por medio de una sesión establecida según un protocolo de transporte basado en HTTP, siendo dicho terminal de telecomunicaciones un terminal cliente, que consta de:
- medios de recopilación (COL) de un conjunto de informaciones de contexto que comprenden informaciones relativas a la sesión e informaciones relativas al menos a uno de dichos equipo y terminal,
- medios de recepción del flujo de datos,
- medios de formación (DEC) de un esquema de adaptación (SCA) en función del conjunto de informaciones de contexto, y
- medios de adaptación (ADP) del flujo de datos en función del esquema de adaptación.
11. Terminal de telecomunicaciones según la reivindicación 10, en donde las informaciones relativas a al menos uno de dichos equipo y terminal comprenden informaciones relativas a la capacidad de memoria intermedia del terminal.
12. Programa informático que consta de instrucciones para la ejecución de las etapas del procedimiento según una cualquiera de las reivindicaciones 1 a 7 cuando dicho programa es ejecutado por un ordenador.
13. Soporte de registro legible por un ordenador en el que se registra un programa informático que comprende instrucciones para la ejecución de las etapas del procedimiento según una cualquiera de las reivindicaciones 1 a 7.
14. Sistema de telecomunicaciones que comprende un equipo de telecomunicaciones según una cualquiera de las reivindicaciones 8 a 9 y al menos un terminal de telecomunicaciones según una cualquiera de las reivindicaciones 10 a 11.
ES20209367T 2010-03-31 2011-03-30 Transmisión de flujo de datos adaptable Active ES2961465T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1052403 2010-03-31

Publications (1)

Publication Number Publication Date
ES2961465T3 true ES2961465T3 (es) 2024-03-12

Family

ID=43063966

Family Applications (2)

Application Number Title Priority Date Filing Date
ES11719316T Active ES2858466T3 (es) 2010-03-31 2011-03-30 Transmisión de flujo de datos adaptable
ES20209367T Active ES2961465T3 (es) 2010-03-31 2011-03-30 Transmisión de flujo de datos adaptable

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES11719316T Active ES2858466T3 (es) 2010-03-31 2011-03-30 Transmisión de flujo de datos adaptable

Country Status (6)

Country Link
US (1) US9369503B2 (es)
EP (2) EP2553900B1 (es)
ES (2) ES2858466T3 (es)
PL (1) PL3866432T3 (es)
PT (1) PT3866432T (es)
WO (1) WO2011121237A1 (es)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7685315B2 (en) * 2002-10-28 2010-03-23 Nokia Corporation System and method for conveying terminal capability and user preferences-dependent content characteristics for content adaptation
US20070087781A1 (en) * 2004-06-30 2007-04-19 Bettis Sonny R Video services delivered to a cellular handset
US7991904B2 (en) * 2007-07-10 2011-08-02 Bytemobile, Inc. Adaptive bitrate management for streaming media over packet networks
US8635309B2 (en) * 2007-08-09 2014-01-21 Hand Held Products, Inc. Methods and apparatus to change a feature set on data collection devices

Also Published As

Publication number Publication date
US9369503B2 (en) 2016-06-14
WO2011121237A1 (fr) 2011-10-06
PL3866432T3 (pl) 2024-01-22
US20130018986A1 (en) 2013-01-17
EP3866432A1 (fr) 2021-08-18
ES2858466T3 (es) 2021-09-30
EP3866432B1 (fr) 2023-07-26
PT3866432T (pt) 2023-10-18
EP2553900B1 (fr) 2020-12-30
EP2553900A1 (fr) 2013-02-06

Similar Documents

Publication Publication Date Title
KR101983432B1 (ko) 동적 적응형 스트리밍 오버 http(dash)를 http 라이브 스트리밍(hls)으로 변환 또는 번역하기 위한 장치, 시스템, 및 방법
KR101398319B1 (ko) 실시간 비디오 검출기
US9621617B2 (en) Method and server for sending a data stream to a client and method and client for receiving a data stream from a server
CN107819809B (zh) 对内容进行同步操作的方法及装置
US20140032777A1 (en) Method, apparatus, and system for transmitting and processing media content
US20100228875A1 (en) Progressive download gateway
WO2016182844A1 (en) Transferring media data using a websocket subprotocol
JP2009260818A (ja) サーバ装置とコンテンツ配信方法とプログラム
KR20130067232A (ko) 다중경로 적응적 스트리밍 세션을 제어하는 방법 및 장치
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
CN116800371B (zh) 一种数据处理方法、装置、设备及可读存储介质
Soua et al. IoT application protocols optimisation for future integrated M2M-satellite networks
Lykourgiotis et al. Hybrid broadcast and broadband networks convergence for immersive TV applications
ES2961465T3 (es) Transmisión de flujo de datos adaptable
Elhachi et al. Smart cross‐layer approach to multi‐access terrestrial and non‐terrestrial networks (NTNs): Real‐time mobile‐health use case
US12513347B2 (en) Systems and methods for reduced latency streaming
Gatimu et al. Experimental study of QoE improvements towards adaptive HD video streaming using flexible dual TCP-UDP streaming protocol
ELHACHI STUDY AND IMPROVEMENT OF THE QUALITY OF SERVICE OF A VIDEO STREAMING BY THE HEVC CODEC IN AD-HOC NETWORKS.
Ortiz et al. Information-Centric Networking Future Internet Video Delivery
Lykourgiotis et al. Hybrid Broadcast Broadband for the Delivery of 3D Video
WO2024240415A1 (en) Network-assisted dynamic control of application layer forward error correction in a wireless communication network
Lin Cross-Layer Network Optimization Targeting Endusers
Ortiz et al. SCTP as scalable video coding transport
Watanabe et al. A low latency and intuitive control video streaming system
WO2024230956A1 (en) Protocol data unit set signalling with application layer forward error correction in a wireless communication network