FR2902266A1 - Procede et dispositif de repartition de la bande passante de communication - Google Patents

Procede et dispositif de repartition de la bande passante de communication Download PDF

Info

Publication number
FR2902266A1
FR2902266A1 FR0652115A FR0652115A FR2902266A1 FR 2902266 A1 FR2902266 A1 FR 2902266A1 FR 0652115 A FR0652115 A FR 0652115A FR 0652115 A FR0652115 A FR 0652115A FR 2902266 A1 FR2902266 A1 FR 2902266A1
Authority
FR
France
Prior art keywords
information
data stream
visual quality
multimedia data
information relating
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.)
Granted
Application number
FR0652115A
Other languages
English (en)
Other versions
FR2902266B1 (fr
Inventor
Eric Nassor
Floch Herve 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.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0652115A priority Critical patent/FR2902266B1/fr
Priority to US11/761,715 priority patent/US8510458B2/en
Publication of FR2902266A1 publication Critical patent/FR2902266A1/fr
Application granted granted Critical
Publication of FR2902266B1 publication Critical patent/FR2902266B1/fr
Expired - Fee Related 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6581—Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • 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/2365—Multiplexing of several video streams
    • H04N21/23655—Statistical multiplexing, e.g. by controlling the encoder to alter its bitrate to optimize the bandwidth utilization
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • 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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities

Landscapes

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

Abstract

Le procédé d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes effectuées dans un dispositif serveur susceptible d'émettre le flux de données multimédia sur le réseau : obtention d'au moins une information relative au flux de données, ladite au moins une information comprenant une information sur une qualité visuelle du flux de données multimédia et une information sur la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, et émission sur le réseau de communication, vers un dispositif client, de ladite au moins une information obtenue.

Description

La présente invention se rapporte à un procédé et un dispositif d'émission
d'au moins une information relative à un flux de données multimédia dans un réseau de communication et à un procédé et un dispositif de réception d'informations relatives à des flux de données multimédia provenant d'au moins deux dispositifs serveur d'un réseau de communication. Elle trouve une application générale dans le traitement de flux de données numériques et plus précisément de flux vidéo numériques, compressés et transportés depuis un ou plusieurs appareils émetteurs, appelés encore dispositifs serveurs, à destination d'un appareil récepteur, appelé encore dispositif client, lesdits dispositifs serveurs et dispositif client étant connectés entre eux à travers un réseau de communication.
De plus en plus d'équipements disponibles pour le grand public sont maintenant capables d'envoyer des flux vidéo élémentaires, tels que caméscope, appareil photo, caméra de vidéo surveillance, serveur de vidéo domestique, récepteur TV, ordinateur, téléphone. De tels flux vidéo élémentaires destinés à être envoyés peuvent être stockés et compressés à l'avance sur l'appareil émetteur ou au contraire être capturés, compressés et envoyés en direct à destination de l'appareil récepteur. En pratique, la connexion directe de tous les appareils émetteurs devient rapidement impossible à cause du nombre limité de prises sur l'écran de l'appareil récepteur. II convient donc d'utiliser un réseau de communication domestique capable de supporter plusieurs flux vidéo élémentaires simultanés. En pratique, le réseau de communication peut s'ouvrir sur Internet pour recevoir d'autres flux vidéo provenant d'appareils serveurs connectés à Internet. On sait aussi que de nombreux appareils peuvent maintenant être raccordés à un réseau numérique (par exemple de type Ethernet ou un réseau sans fil ou directement à Internet via un réseau téléphonique) sur lequel on peut avoir un ou plusieurs appareils récepteurs. Généralement, pour avoir un débit compatible avec celui :lu réseau les flux vidéo élémentaires sont compressés par exemple selon les normes de compression MPEG 2 ou MPEG 4. Du coté de le réception, les appareils d'affichage (écrans) ont aussi gagné en taille et en qualité d'affichage (les résolutions évoluent maintenant vers la haute définition). Par exemple, de plus en plus d'appareils d'affichage affichent plusieurs images simultanément sous forme d'une mosaïque d'images de même taille ou d'un jeu d'images constitué d'une image principale d'un flux vidéo et d'images de taille réduite d'autres flux vidéo élémentaires. De plus en plus d'appareils récepteurs sont également connectables (directement ou via un boîtier adaptateur) à un réseau numérique pour recevoir des flux vidéo numériques compressés, les décompresser et les afficher. L'inconvénient majeur de tels réseaux de communication (domestiques ou Internet) réside dans la limitation de la bande passante globale, qui peut varier au cours du temps. Des variations de la bande passante peuvent être dues à des problèmes de qualité de la transmission. Par exemple dans le cas d'un réseau domestique sans fil, si on déplace l'appareil émetteur ou si des objets se déplacent dans l'environnement, des interférences peuvent alors se produire. Des perturbations électromagnétiques peuvent aussi être causées par d'autres appareils (four micro onde, téléphone). Une autre cause de variation de la bande passante globale peut aussi être l'utilisation du réseau par d'autres applications par exemple de la navigation Internet ou un jeu vidéo. Si aucune action préventive n'est effectuée, des pertes de paquets de données vont se produire pendant la transmission vidéo, se traduisant par des dégradations très importantes de la qualité visuelle de l'affichage : image ou morceaux d'images gelés (plus de mouvement), chaque erreur se propageant ensuite aux images suivantes et peuvent entraîner des dégradations importantes. Pour éviter de tels inconvénients, il est connu de réduire la bande passante élémentaire utilisée par chaque flux vidéo pour être compatible avec la bande passante globale du réseau. Par exemple, une telle réduction se fait au niveau de l'appareil émetteur en compressant la vidéo plus fortement pour réduire le débit. En pratique, la compression consiste à augmenter le pas de quantification, à diminuer la fréquence des images, ou à réduire la résolution des images. Une telle compression peut cependant avoir un impact plus ou moins important sur la qualité visuelle de la vidéo affichée en fonction du type de vidéo. Par exemple une vidéo qui montre une pièce avec peu de mouvement (caméra de vidéo surveillance) peut être compressée fortement sans dégradation trop importante de la qualité visuelle. Au contraire un film d'action trop compressé risque d'avoir une dégradation visuelle inacceptable pour un utilisateur. Si plusieurs flux vidéo élémentaires sont affichés simultanément sur un appareil d'affichage (par exemple sous forme d'une mosaïque), des différences de qualités visuelles trop importantes sont désagréables pour l'utilisateur. II serait donc intéressant d'équilibrer les qualités visuelles entre les différentes vidéos. I:Je plus, si l'attention du spectateur se porte plus particulièrement sur l'une des vidéos, il serait intéressant que celle-ci ait une meilleure qualité visuelle que les autres vidéos. On s'est donc posé le problème d'adapter les bandes passantes des flux vidéo élémentaires en fonction de la qualité visuelle de l'image visualisée et/ou de l'utilisation qui en est faite. Une solution connue pour répartir la bande passante globale entre différents flux vidéo envoyés suivant le protocole RTP (A Transport Protocol for Real-Time Applications, RFC 1889) est d'utiliser un algorithme de calcul de la bande passante disponible pour chaque flux, compatible avec celui utilisé par TCP/IP. L'algorithme TFRC (TCP Friendly Rate Control, RFC 3448) permet ainsi de calculer une bande passante disponible pour un flux vidéo élémentaire sur le protocole RTP en fonction des pertes de paquet détectées. Le résultat permet de répartir équitablement la bande passante entre tous les flux élémentaires : chaque flux élémentaire obtient ainsi une part égale en moyenne. Un système de traitement (streaming) vidéo basé sur cet algorithme réduit alors la bande passante de chaque vidéo pour l'adapter à la bande passante calculée. Toutes les vidéos ont donc un débit identique en moyenne. Mais ceci se traduit par une dégradation de qualité visuelle variable en fonction du type de vidéo. De plus, une telle solution connue a l'inconvénient de ne pas tenir compte de l'utilisation qui est faite de la vidéo. Le document US 2005/20050021726 décrit un système de distribution de flux vidéo, dans lequel plusieurs dispositifs clients peuvent se connecter à un même dispositif serveur. Le dispositif serveur possède une base de données de flux vidéo pouvant être servies. Les flux vidéo sont compressés et analysés à l'avance. La répartition de la bande passante globale entre les différents dispositifs clients tient compte de la qualité visuelle de chaque vidéo et des caractéristiques des dispositifs clients. En pratique, la qualité visuelle des flux vidéo est adaptée aux caractéristiques du dispositif client, en répartissant de manière relativement uniforme les qualités visuelles entre les dispositifs clients. Cette solution connue ne permet cependant pas de résoudre le problème de répartition de la bande passante globale lorsqu'un dispositif client est connecté à plusieurs dispositifs serveurs. De plus, le système décrit dans le brevet US 2005/20050,021726 ne permet pas de faire varier la qualité visuelle d'un flux vidéo en fonction de son utilisation, mais seulement des caractéristiques du dispositif client. L'article Multiple sender distributed video streaming Nguyen, T.; Zakhor, A. Multimedia, IEEE Transactions on, Volume 6, Issue 2, Date: April 2004, Pages: 315 ù 326, décrit un système où un dispositif client se connecte à plusieurs dispositifs serveurs simultanément pour obtenir un flux vidéo. Le dispositif client décide du partage de la bande passante globale entre les différents dispositifs serveurs en utilisant les caractéristiques des connections réseau avec les différents dispositifs serveurs (les dispositifs serveurs qui ont une meilleure bande passante ou moins d'erreurs sont avantagés). Le dispositif client choisit quels paquets de données doivent être envoyés par chaque dispositif serveur. En d'autres termes, on sépare ici les paquets de données cles paquets de correction pour avoir plus de chance de corriger les données si une erreur se produit sur l'une des connections. Néanmoins, la solution décrite dans cet article ne permet pas de résoudre le problème relatif au partage de la bande passante globale d'un réseau de communication dans lequel plusieurs flux vidéo élémentaires sont reçus simultanément au niveau d'un dispositif client et dans lequel on tient compte de la qualité visuelle d'affichage et/ou de l'utilisation des flux vidéo. En effet, dans un tel système connu, le dispositif client ne reçoit qu'un seul flux vidéo élémentaire. La solution proposée dans cet article ne permet donc pas de répartir la bande passante globale entre plusieurs flux vidéo élémentaires en tenant compte de la qualité visuelle d'affichage et/ou de l'utilisation des flux vidéo. La présente invention vise à remédier à au moins un des inconvénients mentionnés ci-avant. La présente invention vise en premier lieu à fournir un procédé d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes effectuées dans un dispositif serveur susceptible d'émettre le flux de données multimédia sur le réseau - obtention d'au moins une information relative au flux de données, ladite au moins une information relative au flux de données comprenant une information sur une qualité visuelle du flux de données multimédia et une information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - émission sur le réseau de communication, vers un dispositif client, de ladite au moins une information obtenue. Le procédé d'émission d'une information relative à un flux de données multimédia dans un réseau de communication selon l'invention permet d'informer au moins un client d'une ou plusieurs qualités d'un flux de données que le serveur est apte à fournir. La qualité est décrite au moyen d'une information comprenant une information sur la qualité visuelle du flux de données et une information sur la bande passante nécessaire à l'émission de ce flux.
De la sorte, le client peut déterminer la qualité du flux de données qu'il souhaite.
Selon une caractéristique particulière, le procédé comprend les étapes suivantes : - réception d'au moins une donnée, ladite au moins une donnée permettant de déterminer une information relative au flux de données sélectionnée par le dispositif client parmi ladite au moins une information relative au flux de données émise, et - émission du flux de données multimédia en fonction de ladite information sélectionnée. Selon une autre caractéristique particulière, ladite au moins une donnée est au moins une information relative au flux de données. Selon encore une autre caractéristique particulière, le procédé comprend les étapes suivantes : -réception d'au moins une donnée, ladite au moins une donnée permettant de déterminer une qualité visuelle du flux de données multimédia et la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, -détermination, en fonction de ladite donnée, de ladite qualité visuelle et de la bande passante nécessaire à l'émission du flux avec cette qualité visuelle ; et - émission du flux de données multimédia en fonction de la qualité visuelle et de la bande passante déterminées. Selon ces différentes caractéristiques, le serveur reçoit d'un client auquel il a émis au moins une information de qualité, une donnée lui permettant de déterminer la qualité du flux de données que le client souhaite. Le serveur convertit le flux de données de sorte à respecter la qualité demandée.
La donnée émise par le client au serveur est, notamment, une information relative au flux de données préalablement émise par le serveur. En variante de réalisation, la donnée émise par le client est une information à partir dei laquelle le serveur détermine une qualité visuelle et la bande passante nécessaire à l'émission du flux.
Selon une caractéristique possible, l'émission du flux de données multimédia est réalisée en fonction de l'information sur la bande passante sélectionnée par le dispositif client.
Selon cette caractéristique, le flux est émis selon la bande passante sélectionnée par le dis: ositif client. Selon une caractéristique envisageable, ladite au moins une information relative au flux de données est obtenue et émise périodiquement vers le dispositif client. Ainsi, il est possible de s'adapter périodiquement aux requêtes du dispositif client et aux conditions du réseau de communication, ce qui permet d'améliorer la qualité de service. Selon un mode de réalisation, le serveur émet périodiquement les informations de qualité qu'il est susceptible de fournir de sorte à informer les clients des capacités du serveur en termes de qualité. De la sorte, le procédé prend en compte les variations survenant au cours du temps dans le flux de données multimédia à émettre. Selon une caractéristique possible, l'information de qualité visuelle est déterminée par le calcul du rapport signal sur bruit. Selon un mode de réalisation, le procédé comprend en outre les étapes suivantes : émission d'un flux de données multimédia avec une qualité visuelle courante, - obtention d'au moins une information comprenant une information sur une qualité visuelle supérieure à la qualité visuelle courante, - obtention d'au moins une information comprenant une information sur une qualité visuelle inférieure à la qualité visuelle courante, et - émission sur le réseau, vers un dispositif client, des dites informations obtenues. Selon ce mode de réalisation, le serveur émet le flux de données et en parallèle, ou en quasi parallèle obtient des informations sur une qualité visuelle supérieure et une qualité visuelle inférieure au flux de données qui est émis. Ainsi, le client peut réajuster la qualité du flux à partir de ces informations.
Selon une caractéristique possible, l'information relative au flux de données comprend en outre le taux de compression.
Selon une autre caractéristique possible, l'information relative au flux de données comprend en outre la technique de compression. Selon une caractéristique envisageable, le procédé comprend en outre une étape de mémorisation des informations relatives au flux de données dans une table d'informations. La table d'information permet notamment de mémoriser les informations de qualité émises aux clients. Selon une mode de réalisation particulier, ladite au moins une information obtenue est émise au moyen de paquets de contrôle du protocole 10 RTP Selon un autre mode de réalisation particulier, ladite au moins une information obtenue est insérée dans au moins un champ du format de codage du flux de données préalablement à l'émission de ladite au moins une information. 15 La présente invention a également pour but de fournir un procédé de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes effectuées dans un dispositif client susceptible de recevoir une pluralité de flux de données 20 multimédia du réseau - réception. en provenance d'au moins un dispositif serveur d'au moins une information relative au flux de données susceptible d'être émis par ledit au moins un dispositif serveur, ladite au moins une information comprenant une information sur une qualité visuelle du flux de données multimédia et une 25 information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, -répartition de la bande passante disponible sur le réseau entre les flux de données multimédia susceptibles d'être reçus par le dispositif client en fonction de ladite au moins une information reçue. 30 Selon le procédé de réception conforme à l'invention, le client réceptionne des informations de qualité de différents flux provenant de différents serveurs, et ià partir de ces informations effectue une répartition de la bande passante. De cette rnanière, la qualité d'un ensemble de flux de données affichés est optimisée globalement.
De même, la répartition de la bande passante entre plusieurs flux de données est effectuée en tenant compte des qualités possibles et des caractéristiques du réseau. Selon une caractéristique possible, la répartition est réalisée en outre, en fonction d'un critère prédéterminé.
Selon un mcde de réalisation, le critère prédéterminé est fonction de la sélection d'un flux de données multimédia principal. Selon cette caractéristique, la répartition de la bande passante tient compte également de l'utilisation de ces flux de données par l'utilisateur. De la sorte, les qualités de plusieurs flux de données qui ont la même utilisation sont harmonisées, alors que la qualité des flux de données les plus importants est augmentée. Selon une caractéristique envisageable, ladite au moins une information relative au flux de données émise par ledit au moins un dispositif serveur est reçue périodiquement.
Selon cette caractéristique, il est permis à l'utilisateur de réajuster à tout moment la qualité des différents flux de données. Selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes : - à partir d'informations sur différentes qualités possibles d'un même flux de données multimédia, sélection d'une information sur une qualité visuelle donnée, - émission vers le dispositif serveur correspondant d'au moins une donnée permettant la détermination de l'information relative au flux de données sélectionnée parmi ladite au moins une information relative au flux de données reçue, et - réception du flux de données multimédia en fonction de ladite information reçue.
Selon ce mode de réalisation, le client émet au serveur des données lui permettant de déterminer la qualité du flux de données souhaitée par le client. Selon une caractéristique possible, ladite au moins une donnée est au moins une information relative au flux de données. Selon une caractéristique envisageable, le procédé comprend une étape d'émission d'aLi moins une donnée, ladite au moins une donnée permettant de déterminer une qualité visuelle du flux de données multimédia et la bande passante nécessaire à l'émission du flux avec cette qualité visuelle.
Selon une caractéristique particulière possible, l'information relative au flux de données comprend en outre le taux de compression. Selon une autre caractéristique particulière, l'information relative au flux de données comprend en outre la technique de compression. Selon un mode de réalisation également envisageable, ladite au 15 moins une information obtenue est reçue au moyen de paquets de contrôle du protocole RTP Selon une caractéristique possible, ladite au moins une information obtenue est insérée 1:ians au moins un champ du format de codage du flux de données reçu. 20 Corrélativernent, l'invention vise également un dispositif d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication, caractérisé en ce qu'il comprend les moyens suivants mis en oeuvre dans un dispositif serveur susceptible d'émettre le flux de données multimédia sur le réseau : 25 -des moyens d'obtention d'au moins une information relative au flux de données, ladite au moins une information relative au flux de données comprenant une information sur une qualité visuelle du flux de données multimédia et une information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, 30 - des moyens d'émission sur le réseau de communication, vers un dispositif client, de ladite au moins une information obtenue.
Ce dispositif présente les mêmes avantages que le procédé d'émission d'au moins une information relative à un flux de données multimédia brièvement décrit ci-dessus. La présente invention a également pour but de fournir un dispositif de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication, caractérisé en ce qu'il comprend les moyens suivants mis en oeuvre dans un dispositif client susceptible de recevoir une pluralité de flux de données multimédia du réseau : - des moyens de réception, en provenance d'au moins un dispositif serveur d'au moins uie information relative au flux de données susceptible d'être émis par ledit au moins un dispositif serveur, ladite au moins une information comprenant une information sur une qualité visuelle du flux de données multimédia e: une information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - des moyens de répartition de la bande passante disponible sur le réseau entre les flux de données multimédia susceptibles d'être reçus par le dispositif client en fonction de ladite au moins une information reçue. Ce dispositif présente les mêmes avantages que le procédé de réception d'informations relatives à une pluralité de flux de données multimédia brièvement décrit ci-dessus et ils ne seront donc pas rappelés ici. Selon d'autres aspects, l'invention concerne aussi des programmes d'ordinateur pour une mise en oeuvre des procédés de l'invention décrits brièvement ci-dessus.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description ci-après et des dessins dans lesquels : - la figure 1 représente schématiquement un réseau distribué d'échanges de données numériques ; - la figure 2 est une représentation schématique des étapes du procédé de répartition de bande passante conforme à l'invention ; - la figure 3 est une représentation schématique de l'échange de données entre un dispositif client et un dispositif serveur conformément à l'invention ; les figures 4A et 4B sont des exemples de représentation schématique d'écran d'affichage d'un dispositif client conformément à l'invention ; - les figures 5A et 5B sont des représentations schématiques illustrant la taille de chaque image d'un groupe d'images compressées ; -les figures 6A et 6B sont des organigrammes illustrant le procédé conformément à l'invention ; - les figures 7A et 7B représentent des tables de qualité visuelle des flux vidéo côté serveur et côté client conformément à l'invention ; et - la figure 8 est un organigramme illustrant la modification de la qualité visuelle d'un flux élémentaire. -la figure 9 représente schématiquement un dispositif client apte à mettre en oeuvre le procédé selon l'invention ;
La figure 'I représente de manière schématique un réseau distribué RD d'échanges de données. Un tel réseau RD comporte un ensemble de terminaux TE (individualisés TE1 à TE4). Chaque terminal TE est relié au réseau RD et possède des moyens de communication pour émettre des requêtes REQ et recevoir des réponses RES. Le réseau RD peut être par exemple un réseau sans fil (WiFi / 802.11a ou b ou g), ou un réseau Ethernet, ou Internet.
On notera que l'invention s'applique à la transmission de données numériques multiméd a à travers le réseau de communication distribué RD représenté à la figure 1. Les données multimédia concernées sont dans l'exemple de réalisation constitutive d'une séquence vidéo numérique.
Les terminaux TE peuvent par exemple, prendre la forme de dispositif représenté à la figure 9 et dont la description sera faite ultérieurement.
Chaque terminal TE comporte, en particulier, une mémoire de stockage volatile (mémoire cache), un serveur de fichiers et une interface homme-machine qui permet l'émission des requêtes REQ de l'utilisateur à d'autres terminaux TE sur le réseau de communication. Selon l'invention, les terminaux peuvent communiquer entre eux par l'intermédiaire du réseau global. En référence à la figure 2, on a représenté les principales étapes du procédé d'émission d'information relative à un flux de données multimédia et du procédé de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur conformément à l'invention dans un contexte d'utilisation choisi à titre d'exemple non limitatif. Un utilisateur se trouve ici devant un dispositif client équipé d'un écran 4 qui est connecté au réseau RD. Plusieurs appareils serveurs 1, 2, 3 générant des flux de données multimédia sont connectés à ce même réseau RD, les flux de données multimédia étant selon l'exemple considéré des flux vidéo élémentaires. Par exemple, il peut y avoir un caméscope 1, un appareil photo 2 et une ou plusieurs caméras de vidéo surveillance 3 . L'utilisateur configure l'écran 4 pour visualiser simultanément trois flux vidéo élémentaires : un principal et deux en miniature. Un exemple de configuration de l'écran est décrit en référence aux figures 4A et 4B.
Dans une étape préalable de démarrage de l'application, l'utilisateur configure l'écran du dispositif client 4 pour que le dispositif client se connecte aux différents appareils serveurs 1, 2, 3 et envoie à chacun d'eux une requête REQ demandant à recevoir une vidéo particulière avec certains paramètres tels que la taille d'affichage et le débit maximal.
Dans ce ccntexte, chaque appareil serveur 1, 2, 3 met en oeuvre de manière répétitive le procédé d'émission selon l'invention. Pendant l'envoi du flux vidéo élémentaire, l'appareil serveur 1, 2 ou 3 procède dans une première étape El, à une analyse de la qualité visuelle de la vidéo et teste différentes possibilités d'encodage telles que décrites en référence aux figures 5A et 5B. Cela lui permet d'obtenir une liste d'informations relatives à la vidéo, Ces informations comprennent, notamment, une information sur une qualité visuelle de la vidéo et une information sur la bande passante nécessaire à l'émission de la vidéo avec cette qualité visuelle. Ces informations peuvent comprendre, en outre, le taux de compression et la technique de compression de la vidéo. Ces différents choix sont stockés localement au niveau de chaque dispositif serveur sous forme d'une table TA-serveur décrite en référence à la figure 7A. Dans une deuxième étape E2, les informations relatives à la vidéo concernant les possibilités de qualité visuelle de la vidéo et de bande passante nécessaire à l'émission de la vidéo avec cette qualité visuelle sont émises sur le réseau de communication au dispositif client 4 avec la vidéo. Dans l'étape E3, le dispositif client 4 reçoit les informations relatives à la vidéo provenant de l'appareil serveur 1, 2 ou 3 et les stocke dans une table-client de décision TB (figure 7B). Il peut ensuite décider de la répartition des bandes passantes élémentaires entre toutes les vidéos élémentaires tel que décrit en référence à la figure 8. Dans ce contexte, le dispositif client 4 met en oeuvre le procédé de réceptionconforme à l'invention. Lors de l'étape E4, le résultat de la sélection d'une information relative à la vidéo par le dispositif client 4 concernant une qualité visuelle de vidéo et/ou une bande passante correspondante est émis au dispositif serveur 1, 2 ou 3. Enfin, lors de l'étape E5, le dispositif serveur 1, 2 ou 3 commence par retrouver les paramètres stockés dans la table-serveur locale TA correspondant à la demande du client (figure 7A). Le dispositif serveur 1, 2, 3 adapte ensuite la bande passante de la vidéo suivant ces paramètres (figures 5A et 5B). En référence à la figure 3, on a décrit l'architecture matérielle ou logicielle des dispositifs serveurs 1, 2 ou 3 et du dispositif client 4. Un seul dispositif serveur 1, 2, 3 est représenté mais d'autres dispositifs serveurs peuvent exister avec la même architecture ou une architecture équivalente et être connectés au même dispositif client. En pratique, le dispositif serveur peut obtenir le flux vidéo de deux manières.
En premier lieu, le flux vidéo peut être capturé en direct par un capteur 301 puis encodé en temps réel par un encodeur 300, l'encodeur 300 se chargeant de compresser la vidéo en adaptant la bande passante élémentaire. En second lieu, le flux vidéo peut être stocké sous forme déjà compressée dans une mémoire de stockage (par exemple un disque dur 312). Dans ce deuxième cas, un module transcodeur 302 est utilisé pour modifier l'encodage du flux vidéo mémorisé et adapter la bande passante élémentaire. L'encodeur 300 ou le transcodeur 302 adaptent le débit de la vidéo suivant les méthodes décrites en référence aux figures 5A et 5B.
Les organes 300/302 sont contrôlés par un module de décision / contrôle de débit 304 qui choisit les paramètres d'encodage. L'algorithme utilisé par le module 304 est décrit en référence aux figures 6A et 6B. La vidéo compressée est ensuite fournie à un module serveur RTP 306 qui se charge de créer des paquets et de les envoyer sur le réseau RD en utilisant, par exemple, le protocole de transmission en temps réel RTP ( Realtime Transport Protocol ) sur UDP/IP ( User Datagram Protocol/lnternet Protocol ). Chaque paquet de données est numéroté, ce qui permet ensuite au dispositif client de reconstruire le flux vidéo.
Des paquets de contrôle RTCP de type SR ( Sender Report en terminologie anglo-saxonne) peuvent être utilisés pour permettre au dispositif serveur d'envoyer des informations supplémentaires. Le module de décision 304, pour envoyer les informations relatives à la vidéo comprenant des informations sur des qualités visuelles de la vidéo et des informations associées sur la bande passante nécessaire à l'émission de la vidéo avec ces qualités visuelles au dispositif client 4, va donc les fournir au serveur RTP 306 qui les envoie ensuite dans les paquets RTCP. En variante, une autre méthode consiste à ajouter des informations relatives à la vidéo dans le flux vidéo. On peut utiliser pour cela les possibilités du format MPEG4 qui réserve certains champs (tel que le champ user data ) pour des informations supplémentaires.
Une autre variante peut consister à utiliser un lien de communication direct sur TCP/IP entre les modules de décision côté serveur 304 et côté client 404. Du coté du dispositif client 4, un module client RTP 400 reçoit les paquets envoyés par les dispositifs serveurs 1, 2, 3. En utilisant les entêtes des paquets RTP, les paquets sont rassemblés pour recréer les flux vidéo envoyés par les dispositifs serveurs, et chaque flux peut alors être fourni à un décodeur 402. Le décodeur 402 décompresse la vidéo et peut fournir les images à afficher à l'écran 408. Celui-ci reçoit et affiche plusieurs vidéos.
Les informations de contrôle ajoutées au flux vidéo par le dispositif serveur sont également reçues par le module client RTP 400. Les entêtes de paquets différents permettent au dispositif client de les distinguer du flux vidéo normal et ainsi de les transmettre au module de décision client 404. L'algorithme du module de décision client 404 est décrit en référence à la figure 8. Les informations relatives à la vidéo sélectionnées par le module de décision client 404 (les choix de bande passante et de qualité visuelle) sont envoyées du dispositif client vers le dispositif serveur. Des messages spécifiques peuvent être utilisés dans la partie contrôle du protocole RTP (messages RR Receiver Report en terminologie anglo-saxonne) pour transmettre des informations du dispositif client vers le dispositif serveur. Dans ce cas, le module de décision client 404 transmet ces informations au module client RTP 400 qui les envoie vers le module serveur RTP 306. Celui-ci décode les paquets reçus et transmet l'information au module de décision du dispositif serveur 304. Une autre solution (représentée sur la figure 3) consiste à utiliser une communication directe 305 de type TCP/IP entre les deux modules de décision 304 et 404. Le module client 404 peut ainsi envoyer directement sa décision au module serveur 304.
Une telle architecture est un exemple d'architecture possible pour l'invention. D'autres variantes sont bien évidemment possibles dans le cadre de l'invention. On peut par exemple avoir les modules de décision client 404 répartis entre plusieurs machines : un afficheur (par exemple un téléviseur), un boîtier de réception et décodage (par exemple un boîtier décodeur relié au téléviseur), et le module de décision peut être situé sur une troisième machine (par exemple un point d'accès WiFi spécifique implémentant l'invention).
En référence aux figures 4A et 4B, on a représenté un exemple d'affichage sur le poste client des différents flux vidéo reçus. Deux possibilités sont représentées à titre d'exemple : Dans un premier cas (figure 4A), les vidéos sont affichées sous forme de mosaïque 500A. Chaque vidéo a une part d'écran 500A de même taille. Une vidéo 502 peut être sélectionnée par exemple pour disposer de la sortie sonore. Cette vidéo 502 peut être désignée directement par l'utilisateur en sélectionnant son numéro sur la télécommande. Dans un deuxième cas (figure 4B) l'une des vidéos 502 est représentée en pleine taille de l'écran 500B, les autres vidéos 501, 503, 504 sont affichées en miniature. Comme dans le premier cas de la figure 4A, l'utilisateur peut changer l'image principale en sélectionnant son numéro sur la télécommande. Dans les deux cas, les qualités visuelles des vidéos 501, 503 et 504 sont similaires : elles ont chacune une même taille sur l'écran. La qualité visuelle de la vidéo 502 est meilleure, puisqu'elle est sélectionnée par l'utilisateur. En effet, l'attention du l'utilisateur étant portée sur la vidéo 502, la qualité visuelle de cette vidéo doit être élevée. D'autres manières d'afficher les différentes vidéos et de les sélectionner peuvent ainsi être mises en oeuvre sans que cela modifie 25 l'invention. En référence à la figure 5, il est maintenant décrit l'adaptation du débit d'une vidéo. Les figures 6A et 6B représentent schématiquement une séquence d'images compressées selon un format de compression vidéo tel que H.264 ou 30 MPEG-4 par exemple. Il s'agit de formats connus, basés sur l'application de Transformation en Cosinus Discrète (DCT) par blocs de la séquence et sur la compensation de mouvement.
Classiquement, une séquence codée selon un tel format contient des images de type I ou INTRA, qui sont décodables indépendamment, des images prédites P et des images bi-prédites B. On définit des groupes d'images (GOP) constitués d'une image I suivie d'un nombre prédéterminé d'images de type P et B. La taille des images I, P et B est très variable. Généralement l'image I est moins compressée (car elle n'utilise pas de compensation de mouvement), les images P sont mieux compressées et les images B sont les plus petites. C'est la taille de chaque image qui est représentée en référence aux figures 5A et 5B. Le calcul du débit d'une vidéo doit donc être calculé en moyenne M sur une séquence et non pas image par image. Plusieurs paramètres peuvent être utilisés pour modifier le taux de compression d'une vidéo. Par exemple, le pas de quantification peut être modifié, pour les blocs intra et les blocs inter. Certaines images peuvent être supprimées dans la vidéo, cela correspond au changement de fréquence d'affichage. La structure du groupe d'images GOP peut ainsi être modifiée. On peut aussi changer la résolution spatiale des images.
Le taux de compression obtenu pour un ensemble de paramètres n'est pas fixe car le résultat de la compression dépend du type d'image et de vidéo et du contenu de la scène. En effet, un film avec une scène statique ou un petit objet en mouvement régulier translationnel est fortement compressé, tandis qu'un film d'action, par exemple, génère encore une grande quantité de données. Le taux de compression dépend de la quantité d'informations non redondantes dans la séquence d'origine. Les techniques décrites peuvent être appliquées lors d'un encodage ou d'un transcodage d'une vidéo. Dans le cas d'un encodage, un capteur numérique génère des images qui sont ensuite encodées. En début du groupe d'images GOP, une image I est générée, puis les images suivantes sont compressées en P (ou B suivant la structure du GOP). Pour obtenir un débit constant, le résultat de la compression est pris en compte et les paramètres de compression sont adaptés dynamiquement à chaque image (ou à chaque macro bloc) pour atteindre le débit moyen fixé. Dans le cas d'un transcodage, la vidéo représentée en figure 5A a déjà été encodée auparavant mais on veut changer son taux de compression pour faire baisser le débit moyen M de la séquence. La technique la plus simple, mais plus coûteuse en temps de calcul consiste à décoder la vidéo puis à la recompresser avec un taux de compression différent. Une technique plus efficace consiste à décoder partiellement la vidéo et à la requantifier pour augmenter le taux ce compression tout en réutilisant les vecteurs de mouvements sans les modifier. Cette technique permet de faire baisser la taille de chaque image I, P ou B. Une autre technique consiste à supprimer certaines images. Les images de type B peuvent être enlevées simplement car elles ne sont pas réutilisées par d'autres images. Comme dans le cas de l'encodage, les paramètres de compression sont dynamiquement modifiés à chaque macro bloc en fonction des compressions obtenues précédemment pour atteindre le débit moyen fixé. Le résultat du transcodage est représenté en figure 5B: certaines images B ont été supprimées et les images restantes ont été compressées plus fortement pour obtenir un débit moyen M plus faible que la vidéo initiale. D'autres techniques de compression et d'adaptation de bande passante peuvent être utilisées. Par exemple certains encodages permettent d'avoir un encodage à plusieurs niveaux (extensible ou scalable ). La vidéo est alors composée de plusieurs couches, chaque couche ajoute des informations supplérrentaires (donc du débit en plus) et de la qualité. L'adaptation du débit consiste alors à sélectionner le nombre de couches que l'on désire. On peut mesurer la qualité visuelle de la vidéo compressée de plusieurs manières. La manière la plus classique est le calcul du rapport signal 30 sur bruit. On peut comparer une image compressée puis décompressée par rapport à l'image d'origine. L'erreur moyenne ( Mean Square Error : MSE) sur une composante couleur d'une image après décodage (par exemple, la luminance, notée X(i,j)) se calcule par la formule : MSL - w ï où W est la largeur de l'image, H sa hauteur, et X' est la valeur décompressée de la même composante pour le même point sur l'image d'origine. Le rapport signal sur bruit (PSNR ou Peak Signal to Noise Ratio en terminologie anglo-saxonne) est ensuite calculé selon la formule suivante : PSNR = 2OLogi0 (255/RMSE) où R.MSE est la racine carrée de l'erreur moyenne MSE.
Cette métrique permet d'obtenir une mesure objective de la distorsion d'une image et est facilement calculable. Cette mesure peut ensuite être appliquée à une séquence vidéo de N images en calculant sa moyenne : = 1 `? PSNR PSNR.
Et sa variance : 1 a/'S, ,R N 1' Les deux valeurs permettent d'obtenir une évaluation de la qualité d'une vidéo : la moyenne du rapport signal sur bruit PSNR donne une indication sur la qualité visuelle moyenne des images tandis que la variance permet de savoir si la qualité des images est très variable dans la vidéo. Ce dernier paramètre est important car de grandes variations de qualité des images donnent une vidéo désagréable à regarder et donc de plus faible qualité qu'une vidéo avec une faible variance, même avec un rapport signal sur bruit PSNR moyen moins bon.
La variance entre les rapports signal sur bruit PSNR de plusieurs vidéos est utile pour évaluer la dispersion de qualité des vidéos. Cette valeur sera utilisée dans l'algorithme décrit figure 8.
Dans le cas où certaines images sont supprimées par la compression, on considère que l'image précédente reste affichée. On mesure donc le rapport signai sur bruit PSNR de l'image compressée précédente par rapport à cette image. En référence à la figure 6A, on a représenté la partie de l'algorithme mis en oeuvre sur le dispositif serveur selon un mode de mise en oeuvre de l'invention dans le module de décision correspondant. L'envoi de la vidéo n'est pas interrompu lorsque cette partie de l'algorithme selon l'invention est exécutée. Dans une première étape E610, le dispositif serveur décide d'émettre des informations relatives à la vidéo comprenant des informations sur des qualités visuelles de la vidéo et des informations associées sur la bande passante nécessaire à l'émission de la vidéo selon les qualités visuelles au dispositif client Ces informations sont par exemple des mesures de rapport signal sur bruit PSNR estimées en fonction de différents taux de compression. Cette décision (l'envoi d'information relative à la vidéo et la quantité d'information envoyée:i peut être prise en fonction de différents critères. Par exemple, cette décision peut être prise en début de vidéo pour permettre au dispositif' client de sélectionner la qualité visuelle optimale avant de commencer l'envoi. En variante, selon un mode de mise en oeuvre de l'invention, elle peut être prise périodiquement (par exemple toutes les 5 secondes) pour permettre une adaptation régulière de la qualité visuelle. Dans une autre variante, l'émission d'information peut être mise en oeuvre de manière synchronisée avec les messages de contrôle RTCP, avec le message Sender Report ce qui permet d'avoir un envoi rapide de l'information relative à la vidéo sans modifier le rythme d'envoi des messages RTCP. Enfin, selon encore une autre variante, l'émission d'information relative à la vidéo est réalisée en fonction de la vidéo. Par exemple, si un changement de scène est détecté dans la vidéo, la qualité peut être fortement modifiée. Cela nécessite une analyse de la vidéo (par exemple une mesure des vecteurs mouvements pour détecter un grand changement). Cette analyse peut être faite à l'avance dans le cas de vidéos stockées.
Le dispositif serveur commence par effacer la table-serveur TA (figure 7A) des résultats précédents (étape E615). En effet, les données liées à l'analyse précédente rie sont plus pertinentes et doivent donc être effacées. Lors de l'étape E620, la séquence vidéo courante est compressée.
L'algorithme de contrôle de débit choisit les paramètres de quantification en fonction d'un modèle débit-distorsion et en fonction de la bande passante globale disponible au moment de la compression. A titre d'exemple, des modèles connus utilisés dans le cadre de la compression MPEG sont TMN-5 ou TMN-8.
Ensuite, lors de l'étape E625, d'autres valeurs débit-distorsion (toujours données par le module de contrôle de débit) sont évaluées. Ces valeurs peuvent être choisies en fonctions des paramètres courants si la vidéo est déjà en cours de diffusion. Le dispositif serveur essaie au moins d'obtenir un taux de compression supérieur et un taux de compression inférieur à la compression courante afin de donner un meilleur choix de décision au dispositif client. Si lors de son dernier message, le dispositif client a demandé explicitement une augmentation ou une diminution de qualité visuelle (demande mémorisée à l'étape E705, figure 6B) le dispositif serveur essaie alors de choisir davantage de mesures débit-distorsion dans le sens demandé par le dispositif client. Le nombre de mesures peut ainsi être modifié par le dispositif client. Les paramètres de compression (par exemple, le pas de quantification, la fréquence temporelle, ...) correspondant aux différentes valeurs du modèle débit/distorsion ainsi que les valeurs de qualité et de débit sont stockés dans la table 8 côté table-serveur TA (figure 7A). Lorsqu'un nombre suffisant de mesures a été obtenu, l'algorithme passe à l'étape E630. Dans cette étape, les informations relatives au flux de données sous la forme de mesures débit/distorsion sont mises sous forme de paquets RTCP et envoyées au dispositif client. Le serveur envoie donc plusieurs possibilités de qualité et de débit En variante de réalisation, au lieu d'envoyer la mesure du débit explicitement, le serveur peut envoyer les paramètres du modèle débit-distorsion utilisés par l'algorithme de calcul du débit. Le client peut ainsi recalculer le débit en fonction du paramètre de quantification. L'algorithme se met ensuite en attente de la réponse du dispositif client (étape E640). Ultérieurement, chaque dispositif serveur reçoit les requêtes du client (étape E710, figure 6B). Ces requêtes peuvent être des contraintes de bande passante ou de qualité ou une sélection d'une des mesures envoyée. Le dispositif client calcule, comme expliqué en détail ultérieurement en référence à la figure 8, pour chaque dispositif serveur, en fonction des différentes valeurs débit-distorsion reçues des différents dispositifs serveurs, la bande passante qu'il autorise à chaque dispositif serveur. Cette bande passante est liée à la qualité visuelle vidéo qu'il souhaite obtenir des différents dispositifs serveurs. Les requêtes du client sont mémorisées lors de l'étape E705. Deux cas peuvent se présenter : Le premier cas concerne la vidéo en temps réel. Dans ce premier cas, les mesures débits/distorsions (avec les paramètres de compression correspondant) ne sont plus totalement à jour puisque l'encodage se fait en temps réel. Dans ce cas, le serveur utilise la table TA (étape 720) pour retrouver la mesure sélectionnée par le client et il en déduit ainsi la contrainte de bande passante. Une nouvelle mesure débit/distorsion doit ensuite être effectuée lors de la compression vidéo (étape E730). Le second cas concerne la vidéo préalablement stockée. Dans ce dernier cas, les mesures débits/distorsions (avec les paramètres de compression correspondant) ont été faites avec une avance temporelle. De ce fait, les valeurs de compression stockée peuvent s'appliquer sur les images en cours de compression/transmission. Ces valeurs de compression sont donc récupérées (lors de l'étape E720) à partir de la donnée envoyée par le client (débit ou qualité ou sélection d'une mesure) et directement appliquées (lors de l'étape E730) lors du transcodage de la vidéo aux contraintes de bande passante données par le dispositif client.
Les structures de données utilisées dans le dispositif serveur et le dispositif client sont présentées respectivement dans les tables TA et TB des figures 7A et 7B.
Le dispositif serveur possède une table-serveur TA permettant de stocker les résultats de simulation de compression ou par un modèle débit-distorsion, ce qui permet de les réutiliser lorsque le dispositif client a sélectionné certains paramètres (très utile dans le cas du transcodage si le dispositif serveur peur prendre de l'avance mais moins utilisé dans le cas de la vidéo en temps réel car ces paramètres doivent être réévalués). Chaque ligne de la table-serveur TA (figure 7A) contient - la bande passante B nécessaire (ou le taux de compression), cette mesure caractérie la quantité d'information qui est envoyée ; - la qualité visuelle Q de la vidéo : dans l'algorithme proposé, il s'agit de la mesure de rapport signal sur bruit PSNR moyen et de sa variance ; le pas q de quantification utilisé pour compresser la séquence ; - la fréquence f des images utilisée pour la vidéo compressée ; et la résolution r utilisée pour la vidéo compressée.
Le dispositif client tient à jour une table-client TB (figure 7B) contenant les différentes possibilités pour chaque flux vidéo reçu. Chaque ligne est associée à une vidéo V et contient : - l'identification de la vidéo idV ; - un indicateur iv du type d'utilisation : normal (correspond à une miniature 501, 503 ou 504 dans la figure 4A) ou prioritaire (image 502 dans la figure 4B) ; - la liste des propositions po du dispositif serveur telles qu'elles ont été émises lors de l'étape (E630) contenant les différentes possibilités de qualité et de débit ; les paramètres sélectionnés ps par le dispositif client. Notons que dans un mode de mise en oeuvre de l'invention, la qualité visuelle est mesurée par le rapport signal sur bruit PSNR moyen, qui présente l'avantage d'être facile à calculer. Néanmoins, d'autres mesures de qualité, notamment en utilisant une métrique de qualité psycho visuelle, pourraient être mises en oeuvre en variante. La partie de l'algorithme de répartition exécutée par le module de décision du client 304 est décrit en référence à la figure 8.
Dans l'étape E910, le dispositif client reçoit les informations relatives au flux contenant les informations relatives aux paramètres de qualité visuelle et de débit associé envoyées (étape E630) par chaque dispositif serveur.
Le dispositif client compare les valeurs reçues par rapport à celles déjà mémorisées dans la table-client TB (étape E920). Si la liste reçue n'a pas été modifiée par rapport à la précédente liste, la table-client TB n'est pas modifiée, l'algorithme est terminé (étape E920) et le dispositif client se remet en attente de nouveaux messages du dispositif serveur.
Dans le cas où les paramètres ont été modifiés, les nouvelles valeurs sont mémorisées en remplacement des anciennes dans la table- client TB (étape E940).
L'étape suivante E950 permet de sélectionner les paramètres pour chaque vidéo reçue ou à recevoir.
La sélection se fait en utilisant les données de la table-client TB.
Pour chaque vidéo i, le dispositif client dispose de ni couples bande passante Bj et qualité Qj. Il faut choisir la valeur de bande passante Bj de chaque vidéo telle que la somme des bandes passantes élémentaires soit inférieure à la bande passante globale du réseau : .v EBi <B 1=i Il faut sélectionner la qualité visuelle Qj de chaque vidéo de telle sorte que :
- toutes les vidéos normales aient une qualité visuelle la plus proche possible (cela aeut s'évaluer par la variance des qualités visuelles),
- la vidéo prioritaire ait une qualité visuelle Qprio plus importante, et - la qualité visuelle totale des vidéos soit la meilleure possible.
Pour arriver à optimiser tous ces critères, une solution consiste à créer une fonction à maximiser représentant la qualité visuelle globale des vidéos prenant en compte ces différents paramètres : f _ alcr No,-Pd +a2Q,A'nroml + a-3 Qprio où Q,,,,,,,,,,, est la valeur moyenne des qualités des vidéos normales et 6 est la variance de ces valeurs de qualité.
Les valeurs a1, a2 et a3 sont des paramètres qui doivent être dimensionnés : la valeur al doit être négative pour minimiser la variance, tandis que les valeurs a2 et a:3 sont positives avec la valeur de a3 plus grande que la valeur de a2 pour donner plus d'importance à la vidéo prioritaire. On peut prendre en première approximation -1, 1 et 2. L'optimisation de la fonction de qualité visuelle est un problème d'optimisation sous contraintes. Dans la mesure où seules les solutions envoyées par chaque dispositif serveur peuvent être choisies, et que nous avons vu que chaque serveur n'envoie qu'un nombre limité de solutions, le nombre de combinaisons de solutions possibles est limité. Une solution simple peut donc être implémentée qui consiste à lister toutes les combinaisons, et à ne garder que celles qui vérifient la contrainte de bande passante et à choisir ensuite celle qui maximise la fonction de qualité visuelle. A la fin de l'étape E950, on dispose donc du meilleur choix possible des paramètres de qualité visuelle et de bande passante élémentaire si une solution est possible. Une information permettant au serveur de retrouver les deux paramètres par vidéo est mise dans le message à envoyer pour chaque vidéo : ce peut être la valeur de qualité ou de bande passante ou un identifiant d'un des choix envoyé par le serveur À l'étape E960, le procédé conforme à l'invention cherche à évaluer si certains dispositifs serveurs doivent préciser davantage leurs choix, c'est-à-dire proposer plus de solutions. Cela peut être utile si les choix proposés par un dispositif serveur ne sont pas bien proportionnés par rapport aux autres. Plusieurs cas peuvent être par exemple intéressants : - aucune solution n'a été trouvée dans l'étape E950, car les bandes passantes sont trop importantes, dans ce cas, le dispositif client ajoute au message pour chaque vidéo une demande de bande passante plus faible, - l'une des vidéos normales à une qualité visuelle très différente des autres, et le dispositif serveur n'offre aucune valeur proche des autres. Dans ce cas le dispositif client peut demander d'autres valeurs augmentant ou diminuant la qualité visuelle pour cette vidéo, - le dispos tif serveur de la vidéo principale n'offre pas de meilleure qualité visuelle, le dispositif client fait une demande pour davantage de qualité visuelle pour cette vidéo. La dernière étape E970, consiste à envoyer les messages constitués des valeurs de qualité visuelle et bande passante élémentaire pour chaque vidéo, et de l'indicateL.r pour la vidéo calculé à l'étape E960. Chaque message est ensuite envoyé au dispositif serveur correspondant. En référence à la figure 9, un dispositif apte à fonctionner en tant que dispositif d'émission d'au moins une information relative à un flux de données multimédia et / ou dispositif de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication selon l'invention est maintenant décrit dans sa configuration matérielle. Le dispositif de traitement d'information de la figure 9 possède l'ensemble des moyens nécessaires à la mise en oeuvre du procédé d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication et / ou du procédé de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication selon l'invention.
Selon le mode de réalisation choisi, ce dispositif 1000 peut être par exemple un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable, un caméscope numérique, un appareil photo numérique, une caméra de vidéo surveillance (Webcam), un lecteur DVD ou un serveur multimédia.
Si ce dispositif n'intègre pas directement un capteur numérique d'images, il peut optionnellement être connecté à différents périphériques tels que, par exemple, une caméra numérique 1001 (ou un scanner ou tout moyend'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant à l'appareil des données multimédia.
Le micro-ordinateur 1000 comporte de préférence une interface de communication 1002 reliée à un réseau 1003, par exemple le réseau Internet, apte à transmettre des informations numériques.
Le micro-ordinateur 1000 comporte également un moyen de stockage 1004, tel que par exemple un disque dur, ainsi qu'un lecteur de disquette 1005. La disquette 1006 comme le disque 1004 peuvent contenir des données d'implantation logicielle de l'invention ainsi que le code (programme "Prog" et "Prog1 ") mettant en oeuvre le procédé d'émission selon l'invention et le procédé de réception selon l'invention qui, une fois lu par le micro-ordinateur 1000, sera stocké dans le disque dur 1004. Selon une variante, le ou les programmes permettant au dispositif 800 de mettre en oeuvre l'invention sont stockés dans une mémoire morte ROM 1007.
Selon une autre variante, le ou les programmes sont reçus totalement ou partiellement à travers le réseau de communication 1003 pour être stockés comme indiqué.. Le micro-ordinateur 1000 peut également être relié à un microphone 1008 par l'intermédiaire d'une carte d'entrée/sortie (non représentée). Le micro- ordinateur 1000 comprend également un écran 1009 pour visualiser les informations à traiter et/ou servir d'interface avec l'utilisateur, afin que l'utilisateur puisse par exemple paramétrer certains modes de traitement à l'aide du clavier 1010 ou de tout autre moyen approprié tel qu'une souris. L'unité centrale CPU 1011 exécute les instructions relatives à la mise en oeuvre de l'invention, ces instructions étant stockées dans la mémoire morte ROM 1007 ou dans les autres éléments de stockage décrits. Lors de la mise sous tension, les programmes et procédés de traitement stockés dans une des mémoires non-volatiles, par exemple la ROM 1007, sont transférés dans la mémoire vive RAM (ou mémoire cache) 1012 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. En variante, les procédés peuvent être stockés dans différents emplacements de stockage du dispositif 1000. De manière générale, un moyen de stockage d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme dont l'exécution met en oeuvre les procédés d'émission et de réception. Il est aussi possible de faire évoluer le mode de réalisation de l'invention, par exemple, en ajoutant des méthodes d'émission et de réception actualisées ou améliorées qui sont transmises par le réseau de communication 1003 ou chargées par l'intermédiaire d'une ou de plusieurs disquettes 1006. Bien entendu, les disquettes 1006 peuvent être rernplacées par tout support d'information tel que CD-ROM ou carte mémoire. Un bus de communication 1013 permet la communication entre les différents éléments du micro-ordinateur 1000 et les éléments reliés à celui-ci. On notera que la représentation du bus 1013 n'est pas limitative. En effet, l'unité centrale CPU 1011 est, par exemple, susceptible de communiquer des instructions à tout élément du micro-ordinateur 1000, directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 1000. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). Bien entendu, la présente invention n'est nullement limitée aux modes de réalisation décrits et représentés, mais englobe, bien au contraire, toute variante à la portée de l'homme du métier.

Claims (30)

REVENDICATIONS
1. Procédé d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes effectuées dans un dispositif serveur susceptible d'émettre le flux de données multimédia sur le réseau : -obtention d'au moins une information relative au flux de données, ladite au moins une information relative au flux de données comprenant une information sur une qualité visuelle du flux de données multimédia et une information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - émission sur le réseau de communication, vers un dispositif client, 15 de ladite au moins une information obtenue.
2. Procédé d'émission selon la revendication 1, caractérisé en ce qu'il comprend les étapes suivantes : - réception d'au moins une donnée, ladite au moins une donnée 20 permettant de déterminer une information relative au flux de données sélectionnée par le dispositif client parmi ladite au moins une information relative au flux de données émise, et - émission du flux de données multimédia en fonction de ladite information sélectionnée. 25
3. Procédé d'émission selon la revendication 2, caractérisé en ce que ladite au moins une donnée est au moins une information relative au flux de données. 3G
4. Procédé d'émission selon la revendication 1, caractérisé en ce qu'il comprend les étapes suivantes : - réception d'au moins une donnée, ladite au moins une donnée permettant de déterminer une qualité visuelle du flux de données multimédia et la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - détermination, en fonction de ladite donnée, de ladite qualité visuelle et de la bande passante nécessaire à l'émission du flux avec cette qualité visuelle ; et - émission du flux de données multimédia en fonction de la qualité visuelle et de la bande passante déterminées.
5. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce que l'émission du flux de données multimédia est réalisée en fonction de l'information sur la bande passante sélectionnée par le dispositif client.
6. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une information relative au flux de données est obtenue et émise périodiquement vers le dispositif client.
7. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce que l'information de qualité visuelle est déterminée par le calcul du rapport signal sur bruit.
8. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre les étapes suivantes : - émission d'un flux de données multimédia avec une qualité visuelle courante, - obtention d'au moins une information comprenant une information sur une qualité visuelle supérieure à la qualité visuelle courante, - obtention d'au moins une information comprenant une information sur une qualité visuelle inférieure à la qualité visuelle courante, et - émission sur le réseau, vers un dispositif client, des dites informations obtenues.
9. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce que l'information relative au flux de données comprend en outre le taux de compression.
10. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce que l'information relative au flux de données comprend en outre la technique de compression. 10
11. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape de mémorisation des informations relatives au flux de données dans une table d'informations. 15
12. Procédé d'émission selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une information obtenue est émise au moyen de paquets de contrôle du protocole RTP.
13. Procédé d'émission selon l'une quelconque des revendications 1 20 à 11, caractérisé en ce que ladite au moins une information obtenue est insérée dans au moins un champ du format de codage du flux de données préalablement à l'émission de ladite au moins une information.
14. Procédé de réception d'informations relatives à une pluralité de 25 flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes effectuées dans un dispositif client susceptible de recevoir une pluralité de flux de données multimédia du réseau : - réception, en provenance d'au moins un dispositif serveur d'au 30 moins une information relative au flux de données susceptible d'être émis par ledit au moins un dispositif serveur, ladite au moins une information comprenant une information sur une qualité visuelle du flux de données multimédia et une5 information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - répartition de la bande passante disponible sur le réseau entre les flux de données multimédia susceptibles d'être reçus par le dispositif client en fonction de ladite au moins une information reçue.
15. Procédé de réception selon la revendication 14, caractérisé en ce que la répartition est réalisée en outre, en fonction d'un critère prédéterminé.
16. Procédé de réception selon la revendication 15, caractérisé en ce que le critère prédéterminé est fonction de la sélection d'un flux de données multimédia principal.
17. Procédé de réception selon l'une quelconque des revendications 14 à 16, caractérisé en ce que ladite au moins une information relative au flux de données émise par ledit au moins un dispositif serveur est reçue périodiquement.
18. Procédé de réception selon l'une quelconque des revendications 14 à 17, caractérisé en ce qu'il comprend en outre les étapes suivantes : à partir d'informations sur différentes qualités possibles d'un même flux de données multimédia, sélection d'une information sur une qualité visuelle donnée, - émission vers le dispositif serveur correspondant d'au moins une donnée permettant la détermination de l'information relative au flux de données sélectionnée parmi ladite au moins une information relative au flux de données reçue, et - réception du flux de données multimédia en fonction de ladite information reçue.30
19. Procédé de réception selon la revendication 18, caractérisé en ce que ladite au moins une donnée est au moins une information relative au flux de données.
20. Procédé de réception selon l'une quelconque des revendications 14 à 17, caractérisé en ce qu'il comprend une étape d'émission d'au moins une donnée, ladite au moins une donnée permettant de déterminer une qualité visuelle du flux de données multimédia et la bande passante nécessaire à l'émission du flux avec cette qualité visuelle.
21. Procédé de réception selon l'une quelconque des revendications 14 à 20, caractérise en ce que l'information relative au flux de données comprend en outre le taux de compression.
22. Procédé de réception selon l'une quelconque des revendications 14 à 21, caractérisé en ce que l'information relative au flux de données comprend en outre la technique de compression.
23. Procédé de réception selon l'une quelconque des revendications 14 à 22, caractérisé en ce que ladite au moins une information obtenue est reçue au moyen de paquets de contrôle du protocole RTP.
24. Procédé de réception selon l'une quelconque des revendications 14 à 22, caractérisé en ce que ladite au moins une information obtenue est 25 insérée dans au moins un champ du format de codage du flux de données reçu.
25. Dispositif d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication, caractérisé en ce qu'il comprend les moyens suivants mis en oeuvre dans un dispositif serveur 30 susceptible d'émettre le flux de données multimédia sur le réseau : - des moyens d'obtention d'au moins une information relative au flux de données, ladite au moins une information relative au flux de données comprenant une information sur une qualité visuelle du flux de données multimédia et une information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, des moyens d'émission sur le réseau de communication, vers un dispositif client, de ladite au moins une information obtenue.
26. Dispositif d'émission selon la revendication 25, caractérisé en ce qu'il comprend les moyens suivants : - des moyens de réception d'au moins une donnée, ladite au moins une donnée permettant de déterminer une information relative au flux de données sélectionnée par le dispositif client parmi ladite au moins une information relative au flux de données émise, et - des moyens d'émission du flux de données multimédia en fonction de ladite information sélectionnée.
27. Dispositif d'émission selon la revendication 25, caractérisé en ce qu'il comprend les moyens suivants : - des moyens de réception d'au moins une donnée, ladite au moins une donnée permettant de déterminer une qualité visuelle du flux de données multimédia et la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - des moyens de détermination, en fonction de ladite donnée, de ladite qualité visuelle et de la bande passante nécessaire à l'émission du flux avec cette qualité visuelle ; et - des moyens d'émission du flux de données multimédia en fonction de la qualité visuelle et de la bande passante déterminées.
28. Dispositif d'émission selon l'une quelconque des revendications 25 à 27, caractérisé en ce que les moyens d'émission du flux de données multimédia sont aptes à réaliser l'émission en fonction de l'information sur la bande passante sélectionnée par le dispositif client.
29. Dispositf d'émission selon l'une quelconque des revendications 25 à 28, caractérisé en ce que les moyens d'obtention et les moyens d'émission sont aptes à obtenir et émettre ladite au moins une information relative au flux de données périodiquement vers le dispositif client.
30. Dispositif d'émission selon l'une quelconque des revendications 25 à 29, caractérisé en ce qu'il comprend en outre les moyens suivants : - des moyens d'émission d'un flux de données multimédia avec une qualité visuelle courante, - des moyens d'obtention d'au moins une information comprenant une information sur une qualité visuelle supérieure à la qualité visuelle courante, - des moyens d'obtention d'au moins une information comprenant une information sur une qualité visuelle inférieure à la qualité visuelle courante, 15 et - des moyens d'émission sur le réseau, vers un dispositif client, des dites informations obtenues. 34. Dispositif d'émission selon l'une quelconque des revendications 20 25 à 30, caractérisé en ce qu'il comprend en outre des moyens de mémorisation des informations relatives au flux de données dans une table d'informations. 35. Dispositif d'émission selon l'une quelconque des revendications 25 25 à 31, caractérisé par des moyens d'émission de paquets de contrôle du protocole RTP comprenant ladite au moins une information obtenue. 36. Dispositif d'émission selon l'une quelconque des revendications 25 à 32, caractérisé en ce qu'il comprend des moyens d'insertion aptes à 30 insérer ladite au moins une information obtenue dans au moins un champ du format de codage du flux de données préalablement à l'émission de ladite au moins une information. 34. Dispositif de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication, caractérisé en ce qu'il comprend les moyens suivants mis en oeuvre dans un dispositif client susceptible de recevoir une pluralité de flux de données multimédia du réseau : - des moyens de réception, en provenance d'au moins un dispositif serveur d'au moins une information relative au flux de données susceptible d'être émis par ledit au moins un dispositif serveur, ladite au moins une information comprenant une information sur une qualité visuelle du flux de données multimédia e1 une information permettant d'obtenir la bande passante nécessaire à l'émission du flux avec cette qualité visuelle, - des moyens de répartition de la bande passante disponible sur le réseau entre les flux de données multimédia susceptibles d'être reçus par le dispositif client en fonction de ladite au moins une information reçue. 35. Dispositif de réception selon la revendication 34, caractérisé en ce que les moyens de réception sont aptes à recevoir périodiquement ladite au moins une information relative au flux de données émise par ledit au moins un dispositif serveur. 36. Dispositif de réception selon l'une quelconque des revendications 34 à 35, caractérisé en ce qu'il comprend en outre les moyens suivants : - des moyens de sélection d'une information sur une qualité visuelle donnée à partir d'informations sur différentes qualités possibles d'un même flux de données multimédia, - des moyens d'émission vers le dispositif serveur correspondant d'au moins une donnée permettant la détermination de l'information relative au flux de données sélectionnée parmi ladite au moins une information relative au flux de données reçue, et - des moyens de réception du flux de données multimédia en fonction de ladite information reçue.37. Dispositif de réception selon l'une quelconque des revendications 34 à 35, caractérisé en ce qu'il comprend des moyens d'émission d'au moins une donnée, ladite au moins une donnée permettant de déterminer une qualité visuelle du flux de données multimédia et la bande passante nécessaire à l'émission du flux avec cette qualité visuelle. 38. Dispositif de réception selon l'une quelconque des revendications 34 à 37, caractérisé par des moyens de réception de paquets de contrôle du 10 protocole RTP comprenant ladite au moins une information. 39. Dispositif de réception selon l'une quelconque des revendications 34 à 37, caractérisé en ce que ladite au moins une information obtenue est comprise dans au moins un champ du format de codage du flux de données 15 reçu. 40. Système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, caractérisé en ce qu'il comprend au moins un dispositif terminal équipé d'un 20 dispositif d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication selon l'une quelconque des revendications 25 à 33 et au moins un dispositif terminal équipé d'un dispositif de réception d'informations relatives à une pluralité de flux de données multimédia selon l'une quelconque des revendications 34 à 39. 25 41. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'émission d'au moins une information relative à un flux de données multimédia dans un réseau de communication selon l'une quelconque 30 des revendications 1 à 13, lorsque ce programme est chargé et exécuté par un système informatique. 42. Programme d'ordinateur changeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé de réception d'informations relatives à une pluralité de flux de données multimédia provenant d'au moins un dispositif serveur d'un réseau de communication selon l'une quelconque des revendications 14 à 24, lorsque ce programme est chargé et exécuté par un système informatique.
FR0652115A 2006-06-13 2006-06-13 Procede et dispositif de repartition de la bande passante de communication Expired - Fee Related FR2902266B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0652115A FR2902266B1 (fr) 2006-06-13 2006-06-13 Procede et dispositif de repartition de la bande passante de communication
US11/761,715 US8510458B2 (en) 2006-06-13 2007-06-12 Method and device for sharing bandwidth of a communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0652115A FR2902266B1 (fr) 2006-06-13 2006-06-13 Procede et dispositif de repartition de la bande passante de communication

Publications (2)

Publication Number Publication Date
FR2902266A1 true FR2902266A1 (fr) 2007-12-14
FR2902266B1 FR2902266B1 (fr) 2008-10-24

Family

ID=37726942

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0652115A Expired - Fee Related FR2902266B1 (fr) 2006-06-13 2006-06-13 Procede et dispositif de repartition de la bande passante de communication

Country Status (2)

Country Link
US (1) US8510458B2 (fr)
FR (1) FR2902266B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2733903A1 (fr) * 2012-11-20 2014-05-21 Alcatel Lucent Procédé de transmission d'un flux vidéo

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2898459B1 (fr) * 2006-03-08 2008-09-05 Canon Kk Procede et dispositif de reception d'images ayant subi des pertes en cours de transmission
FR2932938B1 (fr) * 2008-06-19 2012-11-16 Canon Kk Procede et dispositif de transmission de donnees
US8085855B2 (en) * 2008-09-24 2011-12-27 Broadcom Corporation Video quality adaptation based upon scenery
FR2936926B1 (fr) * 2008-10-06 2010-11-26 Thales Sa Systeme et procede de determination de parametres de codage
US8667162B2 (en) * 2008-12-31 2014-03-04 Industrial Technology Research Institute Method, apparatus and computer program product for providing a mobile streaming adaptor
US9338515B2 (en) 2009-09-03 2016-05-10 At&T Intellectual Property I, L.P. Real-time and secured picture/video upload via a content delivery network
JP5509931B2 (ja) * 2010-03-02 2014-06-04 ソニー株式会社 送信装置、データ送信方法、および通信システム
US9516357B2 (en) * 2010-09-10 2016-12-06 Verizon Patent And Licensing Inc. Recording variable-quality content stream
US9215466B2 (en) * 2011-01-31 2015-12-15 Apple Inc. Joint frame rate and resolution adaptation
JP5837621B2 (ja) * 2011-02-11 2015-12-24 インターデイジタル パテント ホールディングス インコーポレイテッド コンテンツの配信および受信の方法および装置
AU2015215871B2 (en) * 2011-02-11 2017-04-13 Interdigital Patent Holdings, Inc. Method and apparatus for distribution and reception of content
US9781449B2 (en) 2011-10-06 2017-10-03 Synopsys, Inc. Rate distortion optimization in image and video encoding
US9338463B2 (en) * 2011-10-06 2016-05-10 Synopsys, Inc. Visual quality measure for real-time video processing
EP2728892A1 (fr) * 2012-11-06 2014-05-07 Alcatel Lucent Procédé de transmission d'un contenu vidéo avec une haute résolution vers des équipements de communication mobiles équipés d'écrans de collaboration et dispositifs associés
US9450879B2 (en) 2014-05-09 2016-09-20 Nexgen Storage, Inc. Adaptive bandwidth throttling
US10270834B2 (en) * 2015-08-20 2019-04-23 Huawei Technologies Co., Ltd. System and method for online multimedia streaming services
CN114328373A (zh) * 2020-09-29 2022-04-12 伊姆西Ip控股有限责任公司 管理文件***的方法、电子设备和计算机程序产品

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768535A (en) * 1995-04-18 1998-06-16 Sun Microsystems, Inc. Software-based encoder for a software-implemented end-to-end scalable video delivery system
EP0939545A2 (fr) * 1998-02-27 1999-09-01 Hitachi, Ltd. Système de service vidéo
US20010024233A1 (en) * 1996-10-15 2001-09-27 Shinya Urisaka Camera control system, camera server, camera client, control method, and storage medium
WO2005050992A1 (fr) * 2003-11-19 2005-06-02 Miwagi Inc. Systeme de diffusion intelligent destine a fournir des services de diffusion a plusieurs niveaux de qualite

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030076858A1 (en) * 2001-10-19 2003-04-24 Sharp Laboratories Of America, Inc. Multi-layer data transmission system
FR2834852B1 (fr) 2002-01-16 2004-06-18 Canon Kk Procede et dispositif de segmentation temporelle d'une sequence video
US20030236904A1 (en) * 2002-06-19 2003-12-25 Jonathan Walpole Priority progress multicast streaming for quality-adaptive transmission of data
US7352809B2 (en) * 2003-02-21 2008-04-01 Polycom, Inc. System and method for optimal transmission of a multitude of video pictures to one or more destinations
FR2857198B1 (fr) * 2003-07-03 2005-08-26 Canon Kk Optimisation de qualite de service dans la distribution de flux de donnees numeriques
US7433327B2 (en) * 2003-10-09 2008-10-07 Hewlett-Packard Development Company, L.P. Method and system for coordinating communication devices to create an enhanced representation of an ongoing event
US7593032B2 (en) * 2005-07-20 2009-09-22 Vidyo, Inc. System and method for a conference server architecture for low delay and distributed conferencing applications
US20070024705A1 (en) * 2005-08-01 2007-02-01 Richter Roger K Systems and methods for video stream selection
US8436889B2 (en) * 2005-12-22 2013-05-07 Vidyo, Inc. System and method for videoconferencing using scalable video coding and compositing scalable video conferencing servers
US8619865B2 (en) * 2006-02-16 2013-12-31 Vidyo, Inc. System and method for thinning of scalable video coding bit-streams
FR2898459B1 (fr) * 2006-03-08 2008-09-05 Canon Kk Procede et dispositif de reception d'images ayant subi des pertes en cours de transmission
US8773494B2 (en) * 2006-08-29 2014-07-08 Microsoft Corporation Techniques for managing visual compositions for a multimedia conference call
FR2928807B1 (fr) * 2008-03-11 2017-04-07 Canon Kk Procede de transmission sur un reseau de communication d'un signal video pre-encode
FR2932050B1 (fr) * 2008-06-03 2010-05-21 Canon Kk Procede et dispositif de transmission de donnees video

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768535A (en) * 1995-04-18 1998-06-16 Sun Microsystems, Inc. Software-based encoder for a software-implemented end-to-end scalable video delivery system
US20010024233A1 (en) * 1996-10-15 2001-09-27 Shinya Urisaka Camera control system, camera server, camera client, control method, and storage medium
EP0939545A2 (fr) * 1998-02-27 1999-09-01 Hitachi, Ltd. Système de service vidéo
WO2005050992A1 (fr) * 2003-11-19 2005-06-02 Miwagi Inc. Systeme de diffusion intelligent destine a fournir des services de diffusion a plusieurs niveaux de qualite

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BOUDIER T ET AL: "VIDOS, a system for video editing and format conversion over the Internet", COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 34, no. 6, December 2000 (2000-12-01), pages 931 - 944, XP004304831, ISSN: 1389-1286 *
GILGE M ET AL: "MOTION VIDEO CODING FOR PACKET-SWITCHING NETWORKS. AN INTEGRATED APPROACH", VISUAL COMMUNICATION AND IMAGE PROCESSING 1991: VISUAL COMMUNICATION, 11-13 NOV. 1991, BOSTON, BELLINGHAM, WA, US, vol. 1605, January 1991 (1991-01-01), pages 592 - 603, XP000431672 *
MULLER N J: "Improving and Managing Multimedia Performance Over TCP/IP Nets", INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT, WILEY, GB, vol. 8, 1998, pages 356 - 367, XP002261438, ISSN: 1055-7148 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2733903A1 (fr) * 2012-11-20 2014-05-21 Alcatel Lucent Procédé de transmission d'un flux vidéo
WO2014079793A1 (fr) * 2012-11-20 2014-05-30 Alcatel Lucent Procédé pour émettre un flux de données vidéo
US9380098B2 (en) 2012-11-20 2016-06-28 Alcatel Lucent Method for transmitting a video stream

Also Published As

Publication number Publication date
FR2902266B1 (fr) 2008-10-24
US20070288651A1 (en) 2007-12-13
US8510458B2 (en) 2013-08-13

Similar Documents

Publication Publication Date Title
FR2902266A1 (fr) Procede et dispositif de repartition de la bande passante de communication
FR2840495A1 (fr) Procede et dispositif de selection d&#39;une methode de transcodage parmi un ensemble de methodes de transcodage
FR2857198A1 (fr) Optimisation de qualite de service dans la distribution de flux de donnees numeriques
FR2975555A1 (fr) Methode d&#39;adaptation dynamique du debit de reception et recepteur associe
EP3225027A1 (fr) Procédé de composition d&#39;une représentation vidéo intermédiaire
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP3072303B1 (fr) Diffusion adaptative de contenus multimedia
FR2959636A1 (fr) Procede d&#39;acces a une partie spatio-temporelle d&#39;une sequence video d&#39;images
WO2017187044A1 (fr) Procédé de composition contextuelle d&#39;une représentation vidéo intermédiaire
FR2879387A1 (fr) Procede de transmission a debit binaire variable a travers un canal de transmission.
FR2893470A1 (fr) Procede et dispositif de creation d&#39;une sequence video representative d&#39;une sequence video numerique et procedes et dispositifs de transmission et reception de donnees video associes
EP3245794A1 (fr) Procédé de transmission d&#39;un flux de données utilisant un protocole de diffusion en direct
FR3081274A1 (fr) Gestion du telechargement progressif adaptatif d&#39;un contenu numerique au sein d&#39;un terminal de restitution d&#39;un reseau de communication local.
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d&#39;une sequence d&#39;images
FR3054765B1 (fr) Procede pour la lecture sur un equipement d&#39;un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
FR3109489A1 (fr) Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
WO2009095590A1 (fr) Procede de transmission de contenus vod
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
WO2020234030A1 (fr) Restitution d&#39;un contenu en arrière-plan ou sous forme d&#39;incrustation dans le cadre d&#39;un téléchargement progressif adaptatif de type has
FR2926177A1 (fr) Procede et disositif de transmission de donnees avec partage specifique des ressources de debit d&#39;un reseau.
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
WO2021105585A1 (fr) Procédé de gestion d&#39;une liste de contenus accessibles au zapping, les contenus numériques étant téléchargeables en mode de téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d&#39;ordinateur correspondants

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140228