FR2913163A1 - Procede et dispositif de transmission de donnees video - Google Patents
Procede et dispositif de transmission de donnees video Download PDFInfo
- Publication number
- FR2913163A1 FR2913163A1 FR0753535A FR0753535A FR2913163A1 FR 2913163 A1 FR2913163 A1 FR 2913163A1 FR 0753535 A FR0753535 A FR 0753535A FR 0753535 A FR0753535 A FR 0753535A FR 2913163 A1 FR2913163 A1 FR 2913163A1
- Authority
- FR
- France
- Prior art keywords
- quality
- level
- clients
- quality level
- video
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000004422 calculation algorithm Methods 0.000 title claims abstract description 28
- 230000007704 transition Effects 0.000 claims abstract description 34
- 238000004590 computer program Methods 0.000 claims abstract description 7
- 230000005540 biological transmission Effects 0.000 claims description 21
- 230000008859 change Effects 0.000 claims description 18
- 238000004364 calculation method Methods 0.000 claims description 3
- 239000010410 layer Substances 0.000 description 44
- 230000007246 mechanism Effects 0.000 description 14
- 230000002123 temporal effect Effects 0.000 description 14
- 230000006835 compression Effects 0.000 description 10
- 238000007906 compression Methods 0.000 description 10
- 230000033001 locomotion Effects 0.000 description 8
- 238000013139 quantization Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000000750 progressive effect Effects 0.000 description 3
- 239000004107 Penicillin G sodium Substances 0.000 description 2
- 238000004873 anchoring Methods 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 239000004220 glutamic acid Substances 0.000 description 2
- 239000011229 interlayer Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 239000004099 Chlortetracycline Substances 0.000 description 1
- 239000004104 Oleandomycin Substances 0.000 description 1
- 239000004186 Penicillin G benzathine Substances 0.000 description 1
- 239000004187 Spiramycin Substances 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6405—Multicasting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
- H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8451—Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
- H04N7/17309—Transmission or handling of upstream communications
- H04N7/17318—Direct or substantially direct transmission and handling of requests
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
Ce procédé de transmission de données codées, représentant une vidéo numérique, d'un serveur vers une pluralité de clients, au moins un sous-ensemble des clients mettant en oeuvre des algorithmes de contrôle de congestion, met en oeuvre une pluralité de signaux de passage d'une représentation codée de la vidéo à un niveau de qualité donné à une représentation codée à au moins un niveau de qualité différent du niveau donné. L'envoi (E618) d'au moins un des signaux de passage au moins au sous-ensemble de clients est fonction d'informations représentatives du comportement des algorithmes de contrôle de congestion mis en oeuvre par le sous-ensemble de clients.
Description
La présente invention se rapporte à un procédé et à un dispositif de
transmission de données codées représentant une vidéo numérique, dans un réseau de télécommunications. L'invention appartient au domaine de la transmission vidéo. Elle est particulièrement avantageuse lorsque l'application consiste à transmettre une vidéo d'un serveur vers plusieurs clients ayant des capacités différentes et variant dans le temps. L'invention s'applique en particulier à la compression vidéo hiérarchique ou "scalable", dans la dimension SNR (rapport signal sur bruit, en anglais "Signal to Noise Ratio") et offrant la fonctionnalité de codage progressif de l'information de texture. La présente invention s'applique donc en particulier au cas du système SVC (codage vidéo à échelle variable, en anglais "Scalable Video Coding") en cours de normalisation. Elle s'applique aussi au codage vidéo hiérarchique comprenant la possibilité de codage des échantillons représentatifs de la texture de façon progressive et emboîtée, via des technologies de quantification emboîtée et codage par plans de bits, par exemple. Cette application de l'invention n'est néanmoins pas limitative. En effet, l'invention peut également être mise en oeuvre en utilisant un codage non scalable, du type H.264. La future norme de compression vidéo connue sous le nom de "SVC" prévoit de fournir une représentation vidéo hiérarchique, ou "scalable", c'est-à-dire à différents niveaux évalués selon trois critères ou dimensions : le rapport signal/bruit, connu sous le nom de SNR, qui définit la qualité du codage pixel à pixel, la résolution temporelle, c'est-à-dire le nombre d'images par seconde représentées par les données codées et la résolution spatiale, c'est-à-dire le nombre de pixels représentés par les données codées. La norme SVC est développée par le groupe JVT (Joint Video Team), qui réunit les experts de la compression vidéo du groupe MPEG du comité ISO/IEC et les experts vidéo de l'ITU. Cette nouvelle norme reprend pour base les techniques de compression de la norme MPEG-4-AVC, également appelée H.264. Les avancées technologiques de SVC concernent principalement la scalabilité du format vidéo. En effet, ce nouveau format vidéo pourra être décodé de façon différente en fonction des possibilités du décodeur et des caractéristiques du réseau. Par exemple, à partir d'une vidéo haute résolution (type SD, 704x576, 60 Hz), il sera possible de coder dans un flux binaire unique, à l'aide de deux "couches", les données comprimées de la séquence SD et celles d'une séquence au format CIF (352x288, 60 Hz). Pour décoder la résolution CIF, le décodeur ne décodera qu'une partie des informations codées dans le flux binaire. A l'inverse, il devra décoder l'intégralité du flux binaire pour restituer la version SD.
Cet exemple illustre la fonctionnalité de scalabilité spatiale, c'est-à-dire la possibilité, à partir d'un flux unique, d'extraire des vidéos dont la taille des images est différente. Le système de compression vidéo SVC prévoit des scalabilités dans les dimensions temporelle, spatiale et SNR (en qualité). La scalabilité 15 temporelle est obtenue via les images B. La scalabilité SNR existe sous deux formes : la scalabilité SNR fine, notée FGS, est obtenue par quantification progressive des images. La scalabilité SNR grossière ou CGS est fournie par le codage d'une couche (en anglais "layer") dans laquelle une décomposition temporelle est effectuée 20 indépendamment de la couche inférieure, et qui est prédite depuis la couche directement inférieure. Enfin, la scalabilité spatiale est obtenue par codage prédictif d'une couche dans laquelle une décomposition temporelle est effectuée indépendamment de la couche inférieure. Le codage d'une couche de 25 raffinement spatial est similaire à celui d'une couche CGS, à ceci près qu'il sert à comprimer la séquence vidéo à un niveau de résolution supérieur par rapport à la couche inférieure. Il inclut notamment une étape de sur-échantillonnage spatial dans les deux dimensions spatiales (largeur et hauteur) dans le processus de prédiction inter-couches. 30 La figure 1 illustre un exemple d'organisation multicouche possible avec la norme SVC. La couche de base 200 représente la séquence d'images à son plus bas niveau de résolution spatiale, comprimée de façon compatible à la norme H264/AVC. Comme l'illustre la figure 1, la couche de base est composée d'images de type I, P et B hiérarchiques, leurs versions améliorées étant notées respectivement El, EP et EB. Les images B hiérarchiques constituent un moyen d'engendrer une couche de base scalable dans la dimension temporelle. Elles sont notées B;, i>_1, et respectent la règle suivante : une image de type B; peut être prédite temporellement à partir des images d'ancrage, images de référence de type I ou P qui apparaissent en frontières du groupe d'images (en anglais "Group Of Pictures") traité, l'entourant, ainsi que des images Bi, j<i, localisées dans le même intervalle d'images d'ancrage I ou P. On observe qu'entre les images d'ancrage se trouvent des images de type B. On observe aussi qu'une image BI, c'est-à-dire la première image d'une séquence, ne peut être prédite qu'à partir des images d'ancrage l'entourant puisqu'il n'y a pas d'image Bi avec j<1. Sur la figure 1, deux couches de raffinement spatial 205 et 210 sont illustrées. La première couche de raffinement spatial 205 est codée de façon prédictive par rapport à la couche de base 200 et la deuxième couche de raffinement spatial 210 est prédite depuis la première couche de raffinement spatial 205. Une étape de sur-échantillonnage spatial consistant à sur-échantillonner avec un coefficient 2 intervient au cours de ces prédictions entre couches (en anglais "inter-layer"), de sorte qu'une couche supérieure contient des images dont les définitions sont, dans chaque dimension, doubles de celles de la couche immédiatement inférieure. La figure 2 illustre la représentation hiérarchique de la figure 1, dans laquelle ont été ajoutées des couches 300 et 305 de raffinement de type FGS.
Concernant la scalabilité SNR, une couche de raffinement, ou rehaussement, de type SNR contient des données utiles pour décomprimer une séquence vidéo à un niveau de qualité supérieur à celui de la couche inférieure dans la hiérarchie de représentation vidéo. Une couche de raffinement SNR peut prendre deux formes : - une couche de raffinement de type CGS (scalabilité à grains grossiers, en anglais "Coarse Grain Scalability') contient à la fois des données de raffinement des données de mouvement et des données de raffinement des données de texture. Une couche de qualité CGS combine, d'une part, la prédiction temporelle compensée en mouvement au sein de cette couche et, d'autre part, le codage prédictif des données de mouvement et de texture depuis sa couche de base ; et - une couche de raffinement de type FGS (scalabilité à grains fins, en anglais "Fine Grain Scalability') contient uniquement des données de raffinement progressif des informations de texture. Une ou plusieurs couches de qualité FGS successives peuvent être codées au-dessus de la couche de base, d'une couche de scalabilité spatiale ou d'une couche CGS. Typiquement, des moyens de quantification emboîtée et de codage progressif des coefficients DCT (transformée en cosinus discret, en anglais "Discrete Cosine Transform") permettent de fournir un train binaire FGS emboîté, apte à être tronqué à une position quelconque et augmentant progressivement la qualité de l'ensemble de l'image considérée. En effet, le pas de quantification qui était attribué aux données de texture de la couche de qualité précédente est divisé par deux et les données associées sont requantifiées avec le nouveau pas de quantification de la couche FGS courante. De plus, le codage FGS produit des portions de train binaire (en anglais "bitstream") comprimé aptes à être tronquées en n'importe quel endroit.
Le segment de train binaire ainsi tronqué est toujours décodable et son décodage restitue un raffinement de la qualité de l'ensemble des images considérées. Cette propriété résulte du codage cyclique des coefficients DCT des différents macroblocs employé dans la technologie FGS. La technologie FGS fournit un moyen pratique et efficace pour réaliser un contrôle de débit dans un système de transmission SVC : lorsque la bande passante disponible entre un codeur et un décodeur le permet, le codeur peut émettre les données d'un niveau supplémentaire de qualité. Inversement, lorsqu'on souhaite réduire la bande passante consommée, le codeur n'émet plus les données représentatives du niveau de qualité le plus élevé.
La prédiction temporelle implique deux étapes : l'estimation de mouvement et la compensation en mouvement, connues de l'homme du métier. Des études récentes montrent que les meilleures performances de compression sont obtenues lorsque la boucle de prédiction temporelle fonctionne dans le mode appelé "boucle fermée". Concernant l'estimation de mouvement, l'approche dite en "boucle fermée" consiste à estimer les vecteurs de mouvement entre une image d'origine à comprimer et la version reconstruite (codée puis décodée) d'une image de référence. En ce qui concerne la compensation en mouvement, l'approche en boucle fermée consiste à calculer l'erreur de prédiction entre un bloc d'origine et la version reconstruite de son bloc de référence compensé en mouvement. De plus, lorsque plusieurs couches de qualité de type FGS sont engendrées dans le flux binaire SVC, selon ces études, les meilleures performances de compression sont obtenues lorsqu'une compensation en mouvement est utilisée dans le codage de chaque niveau de qualité FGS. En effet, le codage en boucle fermée a la propriété de compenser la distorsion de quantification qui était introduite dans les images de référence. II assure également la synchronisation entre le codeur et le décodeur lorsque la vidéo est décodée à un niveau de qualité constant, ce terme de synchronisation signifiant que le codeur et le décodeur utilisent des images de référence identiques dans le processus de prédiction temporelle.
Lorsque la technologie FGS est utilisée à des fins de contrôle de débit pour transmettre un flux SVC pré-codé, le serveur de flux vidéo comprimé peut avoir besoin de modifier son débit de transmission en fonction d'une bande passante variable. Malheureusement, le fait de passer d'une couche de qualité à une autre arrête la synchronisation entre le codeur et le décodeur. En effet, pendant la phase de modification du débit de transmission, le décodeur reconstruit des images de référence différentes de celles qui avaient été décodées par le codeur lors du codage précédant la phase de transmission. Un défaut, appelé "dérive" (en anglais "drift"), est introduit, ce qui entraîne que des images reconstruites par le décodeur sont différentes de celles reconstruites par le codeur. II en résulte une baisse de la qualité visuelle affichée par rapport à ce qui devrait être affiché par le décodeur. De plus, cette dérive est propagée sur plusieurs images, à cause de la boucle de prédiction temporelle.
Le document US-A-6 996 173 décrit une méthode de transmission vidéo d'un serveur vers un client à travers un réseau non fiable, fondée sur des images similaires aux images SP définies dans la norme MPEG-4 partie 10, AVC/H.264. Dans cette approche, plusieurs flux vidéo scalables de débits différents représentant la même séquence vidéo sont engendrés par un serveur. En fonction des variations du débit disponible sur le réseau, un client peut passer d'un flux à un autre. Cependant, ce document ne mentionne pas la possibilité d'utiliser plusieurs types de signaux de passage, ni comment choisir la fréquence d'envoi des signaux de passage.
Une application similaire est proposée dans un article de M. E. NILSSON et al. intitulé "Adaptive multimedia streaming over IP', BTexact Technologies. Plusieurs flux représentant une vidéo identique mais à des débits différents sont transmis sur un réseau. Un flux de données de passage permettant le passage d'un flux vidéo à un autre est engendré par le serveur lorsque celui-ci estime qu'un client doit se connecter à un autre flux vidéo. Outre le fait que cette application soit faiblement scalable puisque l'envoi des données de passage à un client est décidé par le serveur, cette application n'utilise qu'un seul type de signal de passage. La demande de brevet français de numéro de dépôt 06 50974 propose une solution pour résoudre le problème de dérive mentionné plus haut, en réduisant la perte de synchronisation pouvant résulter d'une augmentation ou d'une baisse de niveau de qualité FGS. Elle propose de coder et insérer un signal différentiel de texture permettant de sauter d'un niveau de qualité FGS à un autre, tout en maintenant le décodeur synchronisé avec le codeur.
De plus, le signal résiduel introduit est compatible avec le processus de codage FGS et ne requiert donc aucune modification du processus de décodage. Il n'est transmis que lors d'une modification du nombre de niveaux de qualité FGS transmis. Cette solution est typiquement appliquée aux images de type P du système de compression SVC. Elle peut également être utilisée à des fins de résistance aux erreurs de transmission pouvant par exemple survenir sur un réseau de transmission à perte de paquets, comme l'Internet.
Dans toute la suite, ce signal différentiel de texture est indifféremment appelé "switch FGS" ou "signal de passage". Aucune des solutions de l'art antérieur évoquées ci-dessus ne permet de réguler l'envoi des signaux de passage en fonction des capacités variables des clients. La présente invention a pour but de remédier à cet inconvénient. Dans ce but, la présente invention propose un procédé de transmission de données codées, représentant une vidéo numérique, d'un serveur vers une pluralité de clients, au moins un sous-ensemble des clients mettant en oeuvre des algorithmes de contrôle de congestion, ce procédé étant remarquable en ce qu'il met en oeuvre une pluralité de signaux de passage d'une représentation codée de la vidéo à un niveau de qualité donné à une représentation codée à au moins un niveau de qualité différent du niveau donné, l'envoi d'au moins un des signaux de passage au moins au sous-ensemble de clients étant fonction d'informations représentatives du comportement des algorithmes de contrôle de congestion mis en oeuvre par le sous-ensemble de clients. Ainsi, l'invention permet au serveur de fixer, d'une part, la fréquence d'envoi et d'autre part, le type des signaux de passage envoyés, en fonction des capacités des clients et de l'état de charge du réseau. On adapte ainsi la quantité d'informations transmise relativement aux changements de niveau de qualité, en fonction des besoins des clients. Ainsi, la part de bande passante accordée aux données vidéo par rapport aux données de passage entre niveaux de qualité est optimisée.
Selon une caractéristique particulière, le procédé comporte une étape consistant à calculer des statistiques concernant des transitions entre niveaux de qualité à partir des informations représentatives du comportement des algorithmes de contrôle de congestion. Ces statistiques permettent au serveur d'avoir un aperçu synthétique 30 du comportement des algorithmes de contrôle de congestion de l'ensemble des clients qui les mettent en oeuvre.
Selon une caractéristique particulière, le procédé comporte en outre une étape consistant à déterminer le type et la fréquence de changement de niveau de qualité en fonction des statistiques. Ces informations de fréquence et de type permettront au serveur 5 d'ajuster au mieux le type de signaux de passage à envoyer ainsi que la fréquence d'envoi de ces signaux. Selon une caractéristique particulière, le procédé comporte des étapes suivant lesquelles - on crée, dans un réseau contenant le serveur et la pluralité de 10 clients, un nombre prédéterminé de groupes multipoints auxquels les clients sont susceptibles de s'abonner, en fonction du nombre de niveaux de qualité existant dans ladite vidéo ; - on initialise des données de passage en attribuant une valeur par défaut à une fréquence de changement de niveau de qualité et en choisissant 15 un type par défaut de signal de passage à transmettre ; - on transmet les données vidéo sur leur groupe multipoint respectif et on transmet les données de passage sur le groupe multipoint transportant les données vidéo correspondant au niveau de qualité le plus bas à partir duquel le signal de passage contenu dans les données de passage permet la transition 20 entre niveaux ; - on vérifie si un ou plusieurs clients ont transmis au serveur des rapports contenant des informations représentatives du comportement de l'algorithme de contrôle de congestion mis en oeuvre par ces clients ; - si au moins un rapport a été transmis, on calcule des statistiques 25 concernant les transitions entre niveaux, à partir d'informations contenues dans les rapports ; - on attribue une nouvelle valeur à la fréquence de changement de niveau de qualité pour chaque transition possible, en fonction des statistiques obtenues précédemment ; 30 - on détermine un ou plusieurs types de signaux de passage à transmettre, en fonction d'informations contenues dans les rapports ; et -on transmet du serveur aux clients les signaux de passage déterminés précédemment avec les fréquences et les types déterminés précédemment. Les conditions de réception sur le réseau étant variables, l'algorithme 5 proposé s'adapte constamment à leur évolution. La diversité de ces signaux de passage permet de trouver le meilleur compromis entre fonctionnalité de passage et débit alloué à ces signaux en fonction des statistiques. Selon une caractéristique particulière, l'étape de création de groupes 10 multipoints consiste à créer un groupe multipoint par niveau de qualité. Le fait de transmettre les niveaux de qualité sur des groupes multipoints permet, d'une part, de déporter la régulation de débit du côté des clients et, d'autre part, d'avoir une bonne granularité d'adaptation du débit. Selon une caractéristique particulière, l'étape de calcul de 15 statistiques consiste à calculer le nombre de passages d'un niveau de qualité à un autre pour chaque transition possible. Selon une caractéristique particulière, l'étape de calcul de statistiques consiste à calculer, pour chaque transition possible, la valeur minimale, la valeur maximale, la valeur moyenne et la valeur médiane de 20 l'intervalle de temps entre les deux dernières tentatives d'abonnement d'un client à un groupe multipoint. Selon une caractéristique particulière, lors de l'étape d'attribution de valeur de fréquence de changement de niveau, on attribue à la fréquence de changement de niveau de qualité pour chaque transition possible la valeur 25 moyenne de cette fréquence. On satisfait ainsi l'ensemble des clients les plus représentatifs. Selon une caractéristique particulière, lors de l'étape de détermination de signaux de passage à transmettre, on décide de transmettre un signal de passage pour chaque transition sur laquelle les rapports 30 contiennent des informations. On augmente ainsi la probabilité qu'un client ait à sa disposition un signal de passage quand il en a besoin.
Dans un mode particulier de réalisation, dans lequel les niveaux de qualité sont des niveaux de scalabilité, la pluralité de types de signaux de passage comporte : - un premier type de signal de passage permettant de passer d'un niveau de qualité au niveau de qualité immédiatement supérieur, - un deuxième type de signal de passage permettant de passer d'un niveau de qualité à un unique niveau de qualité supérieur quelconque, et - un troisième type de signal de passage permettant de passer d'un niveau de qualité à plus d'un niveau de qualité supérieur.
Dans un mode particulier de réalisation, la vidéo est codée suivant la norme SVC (Scalable Video Coding). Dans un autre mode particulier de réalisation, la vidéo est codée suivant la norme H.264. Dans le même but que celui indiqué plus haut, la présente invention propose également un dispositif de transmission de données codées, représentant une vidéo numérique, d'un serveur vers une pluralité de clients, au moins un sous-ensemble des clients mettant en oeuvre des algorithmes de contrôle de congestion, ce dispositif étant remarquable en ce qu'il met en oeuvre une pluralité de signaux de passage d'une représentation codée de la vidéo à un niveau de qualité donné à une représentation codée à au moins un niveau de qualité différent du niveau donné et en ce qu'il comporte un module pour envoyer au moins un des signaux de passage au moins au sous-ensemble de clients en fonction d'informations représentatives du comportement des algorithmes de contrôle de congestion mis en oeuvre par le sous-ensemble de clients. Toujours dans le même but, la présente invention propose également un système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, comprenant au moins un dispositif terminal équipé d'un dispositif de transmission de données tel que succinctement décrit ci-dessus. Toujours dans le même but, la présente invention vise aussi un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, remarquable en ce qu'il permet la mise en oeuvre d'un procédé de transmission de données tel que succinctement décrit ci-dessus. Dans un mode particulier de réalisation, ce moyen de stockage est 5 partiellement ou totalement amovible. Toujours dans le même but, la présente invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, comportant des séquences d'instructions pour mettre en oeuvre un procédé de transmission de données tel que succinctement décrit ci-dessus, 10 lorsque ce programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du dispositif de transmission de données, du système de télécommunications, du moyen de stockage d'informations et du produit programme d'ordinateur étant similaires à ceux du procédé de transmission de données, ils ne sont pas répétés ici. 15 D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit d'un mode particulier de réalisation, donné à titre d'exemple non limitatif. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1, déjà décrite, représente schématiquement un exemple 20 d'organisation multicouche possible d'une séquence vidéo conforme à la norme SVC ; - la figure 2, déjà décrite, représente schématiquement l'insertion de couches de raffinement FGS dans une représentation multicouche du type de la figure 1 ; 25 - la figure 3 illustre le principe d'un signal de passage de type "switch FGS" ; - les figures 4 à 6 illustrent différents types de switchs FGS ; - la figure 7 illustre schématiquement le mécanisme de contrôle de congestion RLM (en anglais "Receiver-driven Layered Multicast") ; 30 - la figure 8 illustre schématiquement un exemple de changement de niveaux de qualité dans la version modifiée, conformément à la présente invention, du mécanisme de contrôle de congestion RLM ; - la figure 9 est un organigramme illustrant les principales étapes d'un procédé de transmission de données conforme à la présente invention, dans un mode particulier de réalisation ; - la figure 10 est un organigramme illustrant le comportement d'un 5 client lors du déroulement du procédé de transmission de données conforme à la présente invention, dans un mode particulier de réalisation ; - la figure 11 représente schématiquement un mode particulier de réalisation d'un appareil susceptible de mettre en oeuvre la présente invention ; et 10 - la figure 12 illustre les différentes fonctionnalités de passage proposées simultanément par des signaux de passage de type 3 illustrés sur la figure 6. Dans le cadre de la présente invention, le réseau de télécommunications considéré est de type multipoint (en anglais "multicast"). 15 Un serveur transmet une séquence vidéo à plusieurs clients ayant des capacités différentes et variant dans le temps. Chaque niveau de scalabilité engendré par le serveur est transmis sur un groupe multipoint. Chaque client décide de s'abonner à un ensemble de groupes multipoints en fonction de ses capacités. Il peut modifier son abonnement en fonction des variations de l'état 20 du réseau et peut ainsi augmenter le nombre de niveaux de qualité FGS reçus. La figure 3 illustre le principe d'un signal de passage de type "switch FGS" décrit dans la demande de brevet français de numéro de dépôt 06 50974. Les traitements relatifs aux signaux de passage sont exécutés uniquement par le codeur, tandis que l'algorithme de décodage vidéo associé 25 demeure inchangé. Ils consistent à engendrer un signal de raffinement de texture conforme à la spécification de la technologie FGS dans la norme SVC, mais permettant de reconstruire une image P à un niveau de qualité FGS donné (l'image Pr 2 sur la figure 3) à partir d'une image de référence reconstruite à un niveau de qualité inférieur. 30 Pour ce faire, le signal de raffinement de texture est calculé par le codeur de façon à permettre de reconstruire une image d'erreur de prédiction temporelle qui, une fois ajoutée à l'image de référence reconstruite au niveau inférieur, restitue une image reconstruite (P%) aussi proche que possible de celle qui serait reconstruite si la prédiction temporelle était effectuée avec l'image de référence (P21) reconstruite au niveau FGS courant. Par conséquent, le codeur doit d'abord coder puis décoder l'image 5 courante (PP 2 sur la figure 3) au niveau de qualité courant, en utilisant l'image de référence normalement destinée à cet effet, notée 13,2+1, qui apparaît sur la figure 3 mais est supposée non disponible côté décodeur. Ensuite, le codeur reconstruit le résidu de prédiction temporelle en décodant les données de texture de l'image d'indice temporel n+2 jusqu'au niveau de qualité FGS d'indice 10 1. Le signal d'erreur de prédiction issu de ce dernier décodage est noté Eln+2. De plus, le codeur reconstruit l'image de référence Pn+1 jusqu'au niveau de qualité FGS d'indice 1. II reste ensuite au codeur à calculer la différence entre l'image reconstruite Pr 2 et la somme de l'image de référence reconstruite Pn'+, et du signal d'erreur de prédiction En+2 , pour connaître le raffinement de texture 15 qui doit être codé dans le signal de raffinement FGS Pn 2. Ainsi, le signal différentiel correspondant à la différence calculée ci-dessus permet au décodeur de reconstruire un signal d'erreur de prédiction temporelle qui, ajouté à l'image de référence reconstruite PP+, , permet de reconstruire l'image Pn 2 proche de sa version reconstruite côté codeur. Ainsi, la 20 synchronisation entre le décodeur et le codeur est maintenue en dépit de l'augmentation du nombre de couches de raffinement FGS décodées en cours de séquence. Le signal différentiel ainsi codé, ou "switch FGS", est noté S(n+,,1)ù>(n+2,2) > illustrant qu'il permet de passer de l'image de référence reconstruite à l'image courante reconstruite Pn 2. 25 Le switch de type 1 représenté en figure 4 permet de passer d'un niveau de scalabilité spatiale, CGS ou FGS au niveau FGS immédiatement supérieur. Le switch de type 2 représenté en figure 5 permet de passer directement d'un niveau de scalabilité spatiale, CGS ou FGS à un et un seul niveau FGS supérieur quelconque. Le switch de type 3représenté en figure 6 permet de passer d'un niveau de scalabilité spatiale, CGS ou FGS à plus de un niveau FGS supérieur. Pour créer des switchs de type 3, on code tout d'abord un premier signal de type switch FGS, afin de permettre le passage de la couche de base vers la première couche de raffinement FGS au-dessus de la couche de base. Ce premier étage de la hiérarchie de switchs FGS est illustré en traits pointillés sur la figure 12 et est noté S(n,base)ù>(n+1,1) Ensuite, les switchs FGS supérieurs de la hiérarchie, illustrés en traits pleins, sont codés comme suit. Pour coder le premier switch FGS illustré en traits pleins, on reconstruit l'image ciblée par le switch FGS précédemment codé en décodant ce dernier. L'image reconstruite est donc une approximation de l'image suivante Pn+1 qui serait reconstruite en décodant la couche FGS régulière notée FGS 1 sur la figure 12. Le codage du prochain signal de type switch FGS consiste à prendre désormais comme image cible l'image reconstruite Pn 1, c'est-à-dire l'image suivante reconstruite au prochain niveau de qualité FGS. On forme donc la différence entre cette nouvelle image cible et l'image reconstruite via le décodage du dernier switch FGS codé S(n,base) (n+11) . Cette différence constitue alors le nouveau signal résiduel à comprimer. Sa compression est opérée en mettant en oeuvre un codage conforme à la syntaxe FGS. Le signal ainsi codé, noté S(n,base)ù>(n+1,2) est inséré dans le train binaire SVC comme un raffinement du signal de texture codé dans le switch FGS précédent S(n,base),(n+1,1) • Il est donc codé avec un pas de quantification divisé par deux par rapport au pas de quantification utilisé dans le signal de switch S(n,base)_ (n+1,1) L'opération de codage ci-dessus, fournissant le signal de passage entre couches FGS S(n,base) (n+1,2) , est ensuite réitérée de façon analogue pour coder le troisième signal de passage S(n,base)_ (n+1.3) de la suite de switchs FGS en cours de construction. L'ensemble des switchs illustrés sur les figures 4 à 6 offre des 30 fonctionnalités différentes et possède aussi des propriétés différentes. Le débit nécessaire au codage des switchs de type 1 est inférieur à celui des switchs de type 2, qui est lui-même inférieur à celui des switchs de type 3. En fonction des besoins des clients, le serveur pourra être amené à faire varier la fréquence et le type de switch transmis.
L'invention s'appuie sur un mécanisme de contrôle de congestion appelé RLM (en anglais "Receiver-driven Layered Multicase'). On se reportera utilement à ce sujet à l'article de Steven McCANNE, Van JACOBSON et Martin VETTERLI intitulé "Receiver-driven Layered Multicast", ACM SIGCOMM 96, 1996. Ce mécanisme basé client est adapté aux sessions vidéo multipoints.
Dans ce mécanisme, le serveur n'a aucun rôle actif. Il se contente de transmettre un ensemble de flux représentant une même vidéo à plusieurs niveaux de qualité, sur des groupes multipoints séparés. Pour déterminer son débit de réception optimal, chaque client fait des tentatives d'abonnement à un ensemble de groupes multipoints. Tant que ces tentatives ne provoquent pas de congestion, chaque client incrémente d'une unité le nombre de groupes multipoints demandés. Si une tentative d'abonnement supplémentaire provoque de la congestion, le nouveau groupe est rejeté et on revient à la configuration d'abonnement précédente. Après une période de temps A, une nouvelle tentative d'abonnement est réalisée pour ce même groupe. La figure 7 illustre ce mécanisme. Afin de ne pas provoquer de congestion transitoire lors de tentatives d'abonnement trop répétées, la période de temps A entre deux tentatives d'abonnement est augmentée pour chaque tentative infructueuse. Le mécanisme RLM permet ainsi de converger vers un état stable et optimal. Conformément à la présente invention, on apporte de légères modifications au mécanisme RLM pour lui permettre de mieux réagir aux phénomènes de congestion isolée. Une congestion isolée est un phénomène de congestion ponctuelle qui n'était pas prédictible et n'aura aucune influence sur le futur comportement du réseau. Concrètement, une chute de débit (ou des pertes) de courte durée se produit, puis on revient rapidement au débit initial. L'algorithme d'accroissement de débit de RLM n'est alors pas adapté. En effet, dans ce cas, il convient de revenir rapidement au débit initial, sans passer par des paliers comme dans le mécanisme de base RLM. Les modifications apportées au mécanisme de base sont les suivantes : un client peut passer d'un niveau à n'importe quel niveau supérieur directement en cas de congestion isolée, de même qu'il peut chuter de plus de un niveau en rejetant plusieurs groupes multipoints. Cette situation est illustrée par la figure 8, qui montre un client passant directement du niveau 2 au niveau de base, puis du niveau de base au niveau 2. L'organigramme de la figure 9 représente le fonctionnement global du serveur. Une session vidéo débute par l'étape E602 au cours de laquelle un opérateur décide d'une vidéo à transmettre. On supposera cette vidéo stockée sur une unité de stockage sous une forme comprimée. Une compression scalable a été mise en oeuvre, de sorte que cette vidéo est constituée d'un ensemble de niveaux de scalabilité. Parmi ces niveaux, un certain nombre sont des niveaux de rehaussement en qualité de type FGS. En plus des données vidéo, des switchs de tout type ont été précalculés, de façon à permettre le passage d'un niveau FGS à un autre toutes les N images. N pourra prendre une valeur supérieure ou égale à 1.
Lors de l'étape suivante E604, le serveur détermine le nombre de groupes multipoints à créer en fonction du nombre de niveaux de scalabilité existant dans la vidéo. Avantageusement, on crée un groupe multipoint par niveau de scalabilité. Toutefois, en variante, certains niveaux pourront être regroupés.
L'envoi de données sur un groupe multipoint est virtuel tant qu'aucun client ne s'abonne à ce groupe. En d'autres termes, les données ne transitent sur le réseau que si au moins un client les demande. L'étape suivante E606 lance la détermination d'une valeur par défaut de la fréquence et des types des switchs à transmettre. Parmi tous les switchs disponibles, le switch du type de celui illustré sur la figure 6 est le plus universel puisqu'il permet le passage entre tous les niveaux FGS. On transmettra donc ce type de switch avec une fréquence permettant de passer d'un niveau à un autre toutes les N images. Lors de l'étape suivante E608, les données vidéo sont transmises sur leur groupe multipoint respectif. Les données de switch sont transmises sur le groupe multipoint transportant les données vidéo correspondant au niveau le plus bas à partir duquel le switch permet la transition entre niveaux. Pour les switchs du type de celui illustré sur la figure 6, ce niveau est le niveau de base dans chaque résolution. Notons qu'un groupe multipoint pourrait aussi être créé pour chaque type de switch envoyé. Un client pourrait alors s'abonner à l'un de ces groupes suivant ses besoins, ce qui est plus optimal en termes de consommation de débit. L'étape E608 est suivie de l'étape E610 au cours de laquelle le serveur vérifie si un ou plusieurs récepteurs ont transmis des rapports (RR, en anglais "Receiver Report'). En effet, comme décrit plus loin en liaison avec la figure 10, lorsqu'il fait une tentative d'abonnement à un niveau supérieur, chaque client transmet un RR. Ces RR sont chargés de transporter vers le serveur des informations représentatives du comportement de l'algorithme de contrôle de congestion mis en oeuvre par le client. Dans le cas d'une mise en oeuvre du mécanisme RLM, le client transmet trois informations au serveur : - Li : intervalle de temps entre les deux dernières tentatives d'abonnement ; - Ls : niveau de qualité de départ lors de la tentative d'abonnement ; - LT : niveau de qualité d'arrivée lors de la tentative d'abonnement. On peut noter que dans une autre mise en oeuvre, seul un sous- ensemble de clients peut être chargé de transmettre des RR au serveur. En effet, dans les sessions multipoints comportant un nombre important de clients, la multiplication des RR engendrerait un débit associé à l'envoi des RR non négligeable. Dans ce cas, des solutions existent limitant le débit associé aux RR. Ces solutions consistent à regrouper les clients en sous-réseaux ayant des caractéristiques de transmission similaires. Dans chacun des sous-réseaux, l'un des clients est désigné pour représenter tous les autres. Ce client représentatif sera chargé de transmettre des informations représentatives des conditions de réception de son sous-réseau, les autres clients du sous-réseau ne transmettant aucun RR. Conformément à la présente invention, chaque client représentatif transmettra des informations représentatives du comportement de son algorithme RLM. II pourra de plus indiquer le nombre de clients qu'il représente dans ces RR, cette information étant utile pour le calcul des statistiques. Le fait que certains clients ne transmettent pas de RR ne les empêchera pas de mettre en oeuvre l'algorithme RLM, ni d'utiliser des switchs. Si, au cours de l'étape E610, aucun RR n'a été reçu, on passe à l'étape E620 qui joue le rôle d'une temporisation de valeur T. Lorsque le temps de temporisation est dépassé, on retourne à l'étape E610. Si, au cours de l'étape E610, au moins un RR a été reçu, cette étape est suivie de l'étape E612. Le serveur calcule alors des statistiques sur l'ensemble des RR reçus. II pourra par exemple calculer le nombre de passages d'un niveau à un autre pour chaque transition possible. II pourra de plus calculer, pour chacune de ces transitions, la valeur minimale, la valeur maximale, la moyenne et la valeur médiane de A. L'étape suivante E614 lance la détermination de la fréquence des switchs pour chaque transition possible. Notons ici que chaque type de switch à transmettre aura une valeur de fréquence qui lui sera propre et sera donc potentiellement différente pour chaque type. Plusieurs choix s'offrent au serveur: - la fréquence prend la valeur maximale : dans ce cas, le serveur va satisfaire l'ensemble des clients, qui recevront fréquemment des switchs. Toutefois, cette solution est sous-optimale en termes d'utilisation réseau puisque tous les clients n'ont pas besoin de switchs aussi fréquemment ; - la fréquence prend la valeur médiane ou moyenne : dans ce cas, on veut satisfaire les clients les plus représentatifs ; - la fréquence prend la valeur minimale : dans ce cas, on minimise le coût en débit du switch.
On choisira de préférence la valeur moyenne de la fréquence d'envoi des switchs.
L'étape suivante E616 consiste à déterminer le ou les types de switchs à envoyer. Avantageusement, cette étape consiste à transmettre des switchs pour toutes les transitions constatées à l'aide des RR. L'idée sous-jacente est de ne pas transmettre de switch pour des transitions qui ne sont pas 5 demandées. Si, pour un ensemble de transitions constatées, plusieurs solutions sont possibles, on choisira la solution la plus économique en termes de débit. Les switchs sont transmis lors de l'étape suivante E618, avec les fréquences et les types déterminés précédemment. On retourne ensuite à l'étape E620. 10 L'organigramme de la figure 10 illustre le comportement du client. Lors de l'étape E702, celui-ci se connecte à la session vidéo. Lors de cette étape, il reçoit une description des sessions transmises sous forme de messages SDP (en anglais "Session Description Protocof') transmise par le serveur. 15 Après avoir reçu cette description, il met en oeuvre le mécanisme de contrôle de congestion RLM modifié comme décrit précédemment, afin de déterminer sa bande passante optimale (étape E704). Lors des étapes suivantes E706 et E708, pour chaque tentative d'abonnement à un niveau supérieur FGS, il envoie un RR tel que décrit plus 20 haut. Cette étape est suivie d'une temporisation (étape E710) dont la durée dépend de l'intervalle entre deux tentatives d'abonnement calculé par le mécanisme RLM. On revient ensuite à l'étape E706. Comme indiqué en introduction, l'invention peut également être mise en oeuvre en utilisant un codage vidéo non scalable, du type H.264. 25 Dans cette seconde mise en oeuvre, plusieurs flux pré-codés représentant une même vidéo à des qualités différentes (et à des débits différents) sont envoyés sur des groupes multipoints différents. Notons N flux le nombre de flux vidéo engendrés par le serveur. Chaque client met en oeuvre le mécanisme de contrôle de congestion RLM. Cependant, à la différence de la 30 première mise en oeuvre de l'invention précédemment décrite, qui était fondée sur un codage SVC, le client s'abonne, non pas à un ensemble de groupes multipoints contenant une version de base de la vidéo et des versions d'amélioration, mais à un seul groupe multipoint à la fois. L'algorithme RLM indique les instants de passage d'un niveau de qualité donné à un autre niveau, de qualité inférieure ou supérieure, de la 5 même façon que dans l'approche fondée sur un codage SVC. Dans cette seconde mise en oeuvre, les algorithmes des figures 9 et 10 sont appliqués de la même façon. Toutefois, les données de switch sont de nature différente. En effet, ici, les switchs sont des images SP permettant de passer d'un premier flux vidéo à un second flux vidéo, comme décrit dans 10 l'article de M. E. NILSSON et al. cité plus haut. Ces images SP sont transportées par le groupe multipoint à partir duquel se fait la transition. Par exemple, les images SP permettant le passage du flux N vers le flux N+1 sont transportées dans le groupe multipoint transportant le niveau N. La fréquence de passage d'un flux vidéo à un autre 15 flux vidéo et le type de passage sont fixés par l'algorithme de la figure 9. On suppose qu'à cet ensemble de N flux flux vidéo est associé un ensemble de signaux de passage permettant au plus le passage d'un flux à une qualité donnée à l'un des N_flux -1 autres flux restants. La fréquence de ces switchs est fixée à une valeur donnée Fd. En début de session, tous les types 20 de switchs sont envoyés avec une fréquence égale à Fd. Puis la fréquence et le type de switch envoyé évolueront au cours de la session en suivant l'algorithme de la figure 9. Comme représenté sur la figure 11, un dispositif mettant en oeuvre l'invention est par exemple un micro-ordinateur 10 connecté à différents 25 périphériques, par exemple une caméra numérique 101 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant des informations à comprimer selon l'invention. Le dispositif 10 comporte une interface de communication 118 reliée à un réseau 113 apte à transmettre des données numériques à traiter ou à 30 transmettre des données traitées par le dispositif. Le dispositif 10 comporte également un moyen de stockage 112 tel qu'un disque dur. II comporte aussi un lecteur 114 de disques 116. Ce disque 116 peut être une disquette, un CD-ROM, ou un DVD-ROM, par exemple. Le disque 116 comme le disque 112 peuvent contenir des données traitées selon l'invention ainsi que le ou les programmes mettant en oeuvre l'invention qui, une fois lus par le dispositif 10, seront stockés dans le disque dur 112. En variante, le ou les programmes permettant au dispositif de mettre en oeuvre l'invention pourront être stockés en mémoire morte 104 (appelée ROM sur le dessin). Dans une autre variante, ce ou ces programmes pourront être reçus pour être stockés de façon identique à celle décrite précédemment par l'intermédiaire du réseau de communication 113.
Le dispositif 10 possède un écran 108 permettant de visualiser les données à traiter ou de servir d'interface avec l'utilisateur qui peut ainsi paramétrer certains modes de traitement, à l'aide du clavier 110 ou de tout autre moyen (souris par exemple). L'unité centrale 103 (appelée CPU sur le dessin) exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 104 ou dans les autres éléments de stockage. Lors de la mise sous tension, les programmes de traitement stockés dans une mémoire non volatile, par exemple la ROM 104, sont transférés dans la mémoire vive RAM 106 qui contiendra alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention. De façon plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement totalement ou partiellement amovible, mémorise un programme mettant en oeuvre le procédé de transmission de données. Le bus de communication 102 permet la communication entre les différents éléments inclus dans le micro-ordinateur 10 ou reliés à lui. La représentation du bus 102 n'est pas limitative et notamment l'unité centrale 103 est susceptible de communiquer des instructions à tout élément du micro- ordinateur 10 directement ou par l'intermédiaire d'un autre élément du micro- ordinateur 10.
Claims (10)
1. Procédé de transmission de données codées, représentant une vidéo numérique, d'un serveur vers une pluralité de clients, au moins un sous-ensemble des clients mettant en oeuvre des algorithmes de contrôle de congestion, ledit procédé étant caractérisé en ce qu'il met en oeuvre une pluralité de signaux de passage d'une représentation codée de la vidéo à un niveau de qualité donné à une représentation codée à au moins un niveau de qualité différent du niveau donné, l'envoi (E618) d'au moins un desdits signaux de passage au moins audit sous-ensemble de clients étant fonction d'informations représentatives du comportement des algorithmes de contrôle de congestion mis en oeuvre par ledit sous-ensemble de clients.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape (E612) consistant à calculer des statistiques concernant des 15 transitions entre niveaux de qualité à partir desdites informations représentatives du comportement desdits algorithmes de contrôle de congestion.
3. Procédé selon la revendication 2, caractérisé en ce qu'il comporte en outre une étape (E618) consistant à déterminer le type et la fréquence de 20 changement de niveau de qualité en fonction desdites statistiques.
4. Procédé selon la revendication 1, 2 ou 3, caractérisé en ce qu'il comporte des étapes suivant lesquelles : - on crée (E604), dans un réseau contenant ledit serveur et ladite pluralité de clients, un nombre prédéterminé de groupes multipoints auxquels 25 les clients sont susceptibles de s'abonner, en fonction du nombre de niveaux de qualité existant dans ladite vidéo ; - on initialise (E606) des données de passage en attribuant une valeur par défaut à une fréquence de changement de niveau de qualité et en choisissant un type par défaut de signal de passage à transmettre ; 30 - on transmet (E608) les données vidéo sur leur groupe multipoint respectif et on transmet les données de passage sur le groupe multipoint transportant les données vidéo correspondant au niveau de qualité le plus basà partir duquel le signal de passage contenu dans les données de passage permet la transition entre niveaux ; - on vérifie (E610) si un ou plusieurs clients ont transmis au serveur des rapports contenant des informations représentatives du comportement de 5 l'algorithme de contrôle de congestion mis en oeuvre par ces clients ; si au moins un rapport a été transmis, on calcule (E612) des statistiques concernant les transitions entre niveaux, à partir d'informations contenues dans les rapports ; - on attribue (E614) une nouvelle valeur à la fréquence de 10 changement de niveau de qualité pour chaque transition possible, en fonction des statistiques obtenues précédemment ; - on détermine (E616) un ou plusieurs types de signaux de passage à transmettre, en fonction d'informations contenues dans les rapports ; et -on transmet (E618) du serveur aux clients les signaux de passage 15 déterminés précédemment avec les fréquences et les types déterminés précédemment.
5. Procédé selon la revendication 4, caractérisé en ce que l'étape (E604) de création de groupes multipoints consiste à créer un groupe multipoint par niveau de qualité. 20
6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que l'étape (E612) de calcul de statistiques consiste à calculer le nombre de passages d'un niveau de qualité à un autre pour chaque transition possible.
7. Procédé selon l'une quelconque des revendications 4 à 6, 25 caractérisé en ce que l'étape (E612) de calcul de statistiques consiste à calculer, pour chaque transition possible, la valeur minimale, la valeur maximale, la valeur moyenne et la valeur médiane de l'intervalle de temps entre les deux dernières tentatives d'abonnement d'un client à un groupe multipoint.
8. Procédé selon l'une quelconque des revendications 4 à 7, 30 caractérisé en ce que lors de l'étape (E614) d'attribution de valeur de fréquence de changement de niveau, on attribue à la fréquence de changement de niveau de qualité pour chaque transition possible la valeur moyenne de ladite fréquence.
9. Procédé selon l'une quelconque des revendications 4 à 8, caractérisé en ce que lors de l'étape (E616) de détermination de signaux de passage à transmettre, on décide de transmettre un signal de passage pour chaque transition sur laquelle les rapports contiennent des informations.
10. Procédé selon l'une quelconque des revendications précédentes, dans lequel les niveaux de qualité sont des niveaux de scalabilité, ledit procédé étant caractérisé en ce que ladite pluralité de types de signaux de passage comporte : - un premier type de signal de passage permettant de passer d'un niveau de qualité au niveau de qualité immédiatement supérieur, - un deuxième type de signal de passage permettant de passer d'un niveau de qualité à un unique niveau de qualité supérieur quelconque, et - un troisième type de signal de passage permettant de passer d'un niveau de qualité à plus d'un niveau de qualité supérieur. 13. Dispositif de transmission de données codées, représentant une vidéo numérique, d'un serveur vers une pluralité de clients, au moins un sous-ensemble des clients mettant en oeuvre des algorithmes de contrôle de congestion, ledit dispositif étant caractérisé en ce qu'il met en oeuvre une pluralité de signaux de passage d'une représentation codée de la vidéo à un niveau de qualité donné à une représentation codée à au moins un niveau de qualité différent du niveau donné et en ce qu'il comporte des moyens pour envoyer au moins un desdits signaux de passage au moins audit sous- ensemble de clients en fonction d'informations représentatives du comportement des algorithmes de contrôle de congestion mis en oeuvre par ledit sous-ensemble de clients. 14. Dispositif selon la revendication 11, caractérisé en ce qu'il comporte des moyens pour calculer des statistiques concernant des transitions entre niveaux de qualité à partir desdites informations représentatives du comportement desdits algorithmes de contrôle de congestion. 13. Dispositif selon la revendication 12, caractérisé en ce qu'il comporte en outre des moyens pour déterminer le type et la fréquence de changement de niveau de qualité en fonction desdites statistiques. 14. Dispositif selon la revendication 11, 12 ou 13, caractérisé en ce qu'il comporte : - des moyens pour créer (E604), dans un réseau contenant ledit serveur et ladite pluralité de clients, un nombre prédéterminé de groupes multipoints auxquels les clients sont susceptibles de s'abonner, en fonction du nombre de niveaux de qualité existant dans ladite séquence vidéo ; - des moyens pour initialiser (E606) des données de passage en attribuant une valeur par défaut à une fréquence de changement de niveau de qualité et en choisissant un type par défaut de signal de passage à transmettre ; - des moyens pour transmettre (E608) les données vidéo sur leur groupe multipoint respectif et pour transmettre les données de passage sur le groupe multipoint transportant les données vidéo correspondant au niveau de qualité le plus bas à partir duquel le signal de passage contenu dans les données de passage permet la transition entre niveaux ; - des moyens pour vérifier (E610) si un ou plusieurs clients ont transmis au serveur des rapports contenant des informations représentatives du comportement de l'algorithme de contrôle de congestion mis en oeuvre par ces clients ; - des moyens pour calculer (E612) des statistiques concernant les transitions entre niveaux, à partir d'informations contenues dans les rapports ; - des moyens pour attribuer (E614) une nouvelle valeur à la fréquence de changement de niveau de qualité pour chaque transition possible, en fonction des statistiques obtenues par les moyens de calcul de statistiques ; - des moyens pour déterminer (E616) un ou plusieurs types de signaux de passage à transmettre, en fonction d'informations contenues dans les rapports ; et -des moyens pour transmettre (E618) du serveur aux clients les signaux de passage déterminés par les moyens de détermination de signaux depassage avec les fréquences déterminées par les moyens d'attribution de valeurs de fréquences de changement de niveau et les types déterminés par les moyens de détermination de signaux de passage. 15. Dispositif selon la revendication 14, caractérisé en ce que les 5 moyens de création de groupes multipoints sont adaptés à créer un groupe multipoint par niveau de qualité. 16. Dispositif selon l'une quelconque des revendications 12 à 15, caractérisé en ce que les moyens de calcul de statistiques sont adaptés à calculer le nombre de passages d'un niveau de qualité à un autre pour chaque 10 transition possible. 17. Dispositif selon l'une quelconque des revendications 14 à 16, caractérisé en ce que les moyens de calcul de statistiques sont adaptés à calculer, pour chaque transition possible, la valeur minimale, la valeur maximale, la valeur moyenne et la valeur médiane de l'intervalle de temps entre 15 les deux dernières tentatives d'abonnement d'un client à un groupe multipoint. 18. Dispositif selon l'une quelconque des revendications 14 à 17, caractérisé en ce que les moyens d'attribution de valeur de fréquence de changement de niveau sont adaptés à attribuer à la fréquence de changement de niveau de qualité pour chaque transition possible la valeur moyenne de 20 ladite fréquence. 19. Dispositif selon l'une quelconque des revendications 14 à 18, caractérisé en ce que les moyens de détermination de signaux de passage à transmettre sont adaptés à décider de transmettre un signal de passage pour chaque transition sur laquelle les rapports contiennent des informations. 25 20. Dispositif selon l'une quelconque des revendications 11 à 19, dans lequel les niveaux de qualité sont des niveaux de scalabilité, ledit dispositif étant caractérisé en ce que ladite pluralité de types de signaux de passage comporte : - un premier type de signal de passage permettant de passer d'un 30 niveau de qualité au niveau de qualité immédiatement supérieur, - un deuxième type de signal de passage permettant de passer d'un niveau de qualité à un unique niveau de qualité supérieur quelconque, et - un troisième type de signal de passage permettant de passer d'un niveau de qualité à plus d'un niveau de qualité supérieur. 21. 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 dispositif de transmission de données selon l'une quelconque des revendications 11 à 20. 22. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé de transmission de données selon l'une quelconque des revendications 1 à 10. 23. Moyen de stockage d'informations selon la revendication 22, caractérisé en ce qu'il est partiellement ou totalement amovible. 24. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de transmission de données selon l'une quelconque des revendications 1 à 10, lorsque ce programme est chargé et exécuté par l'appareil programmable.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0753535A FR2913163A1 (fr) | 2007-02-27 | 2007-02-27 | Procede et dispositif de transmission de donnees video |
| US12/035,769 US8429706B2 (en) | 2007-02-27 | 2008-02-22 | Method and device for transmitting data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0753535A FR2913163A1 (fr) | 2007-02-27 | 2007-02-27 | Procede et dispositif de transmission de donnees video |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2913163A1 true FR2913163A1 (fr) | 2008-08-29 |
Family
ID=38596901
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0753535A Withdrawn FR2913163A1 (fr) | 2007-02-27 | 2007-02-27 | Procede et dispositif de transmission de donnees video |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8429706B2 (fr) |
| FR (1) | FR2913163A1 (fr) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2257073A1 (fr) * | 2009-05-25 | 2010-12-01 | Canon Kabushiki Kaisha | Procédé et dispositif pour transmettre des données vidéo |
| US8914834B2 (en) * | 2011-07-18 | 2014-12-16 | Motorola Solutions, Inc. | Source rate and channel rate matching for scalable video transmission |
| US10212049B2 (en) | 2013-03-14 | 2019-02-19 | Time Warner Cable Enterprises Llc | Apparatus and methods for managing service delivery telemetry |
| US10171607B2 (en) | 2014-03-28 | 2019-01-01 | Time Warner Cable Enterprises Llc | Apparatus and methods for managing quality of experience during the delivery of content |
| AU2019315029A1 (en) * | 2018-08-03 | 2021-03-11 | V-Nova International Limited | Transformations for signal enhancement coding |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6292512B1 (en) * | 1998-07-06 | 2001-09-18 | U.S. Philips Corporation | Scalable video coding system |
| US20030028643A1 (en) * | 2001-03-13 | 2003-02-06 | Dilithium Networks, Inc. | Method and apparatus for transcoding video and speech signals |
| US20030135863A1 (en) * | 2002-01-17 | 2003-07-17 | Koninklijke Philips Electronics N.V. | Targeted scalable multicast based on client bandwidth or capability |
| US20030151753A1 (en) * | 2002-02-08 | 2003-08-14 | Shipeng Li | Methods and apparatuses for use in switching between streaming video bitstreams |
| US6996173B2 (en) | 2002-01-25 | 2006-02-07 | Microsoft Corporation | Seamless switching of scalable video bitstreams |
| FR2842057B1 (fr) | 2002-07-05 | 2005-10-28 | Canon Kk | Procede et dispositif de traitement de donnees dans un reseau de communication |
| FR2853797A1 (fr) | 2003-04-09 | 2004-10-15 | Canon Kk | Procede et dispositif de pre-traitement de requetes liees a un signal numerique dans une architecture du type client-serveur |
| US7844992B2 (en) * | 2003-09-10 | 2010-11-30 | Thomson Licensing | Video on demand server system and method |
| FR2884027B1 (fr) | 2005-04-04 | 2007-06-01 | Canon Kk | Procede et dispositif de transmission et de reception de sequences d'images entre un serveur et un client |
-
2007
- 2007-02-27 FR FR0753535A patent/FR2913163A1/fr not_active Withdrawn
-
2008
- 2008-02-22 US US12/035,769 patent/US8429706B2/en not_active Expired - Fee Related
Non-Patent Citations (3)
| Title |
|---|
| MCCANNE S ET AL: "Receiver-driven Layered Multicast", COMPUTER COMMUNICATION REVIEW, ACM, NEW YORK, NY, US, no. 4, October 1996 (1996-10-01), pages 117 - 130, XP002452811, ISSN: 0146-4833 * |
| NILSSON M E ET AL: "ADAPTIVE MULTIMEDIA STREAMING OVER IP", INTERNATIONAL CONFERENCE ON VISUAL INFORMATION ENGINEERING, 7 July 2003 (2003-07-07), pages 214 - 217, XP008023217 * |
| QIANG NI ET AL: "SARLM: sender-adaptive & receiver-driven layered multicasting for scalable video", MULTIMEDIA AND EXPO, 2001. ICME 2001. IEEE INTERNATIONAL CONFERENCE ON 22-25 AUG. 2001, PISCATAWAY, NJ, USA,IEEE, 22 August 2001 (2001-08-22), pages 757 - 760, XP010661949, ISBN: 0-7695-1198-8 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US8429706B2 (en) | 2013-04-23 |
| US20090064254A1 (en) | 2009-03-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2939593A1 (fr) | Procede et dispositif de codage video | |
| FR2880743A1 (fr) | Dispositif et procedes de codage et de decodage echelonnables de flux de donnees d'images, signal, programme d'ordinateur et module d'adaptation de qualite d'image correspondants | |
| FR2894421A1 (fr) | Procede et dispositif de decodage d'un flux video code suivant un codage hierarchique | |
| FR2931610A1 (fr) | Procede et un dispositif de transmission de donnees d'images | |
| FR2918520A1 (fr) | Procede et dispositif de transmission video | |
| WO2006015979A1 (fr) | Procede de mise en forme de trames d'une sequence video | |
| EP2052545B1 (fr) | Dispositif et procede de codage et de decodage echelonnables de flux de donnees d'images, signal et programme d'ordinateur correspondants | |
| EP3707900B1 (fr) | Procédé de formation d'une séquence d'images de sortie à partir d'une séquence d'images d'entrée, procédé de reconstruction d'une séquence d'images d'entrée à partir d'une séquence d'images de sortie, dispositifs, equipement serveur, equipement client et programmes d'ordinateurs associés | |
| FR2889017A1 (fr) | Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants | |
| FR2857198A1 (fr) | Optimisation de qualite de service dans la distribution de flux de donnees numeriques | |
| FR2854019A1 (fr) | Embrouillage, desembrouillage et distribution securisee de sequences audiovisuelles issues de codeurs videos bases sur un traitement par ondelettes | |
| FR2913163A1 (fr) | Procede et dispositif de transmission de donnees video | |
| EP1969854A1 (fr) | Procede de codage et de decodage d'une image ou d'une sequence d'images, dispositifs, programmes d'ordinateur, et signal correspondants | |
| US20210352347A1 (en) | Adaptive video streaming systems and methods | |
| EP2410749A1 (fr) | Procédé d'encodage adaptatif d'un flux vidéo numérique, notamment pour diffusion sur ligne xDSL | |
| EP2060074A1 (fr) | Procede et dispositif d'adaptation d'un flux de donnees scalable, produit programme d'ordinateur et equipement reseau correspondants | |
| WO2020157413A1 (fr) | Procédé et dispositif de codage et de décodage de données correspondant à une séquence vidéo | |
| FR2923970A1 (fr) | Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images | |
| Eberhard et al. | Nextsharepc: an open-source bittorrent-based p2p client supporting svc | |
| FR2913844A1 (fr) | Procede et dispositif d'allocation de debit dans une sequence video | |
| FR2910773A1 (fr) | Procede et dispositif de codage de donnees video. | |
| FR2931609A1 (fr) | Procedes de codage et de decodage pseudo-hierarchiques et systemes associes. | |
| Slanina et al. | Rate Distortion Performance of H. 264/SVC in Full HD with Constant Frame Rate and High Granularity | |
| Ramzan et al. | Scalable and Adaptable Media Coding Techniques for Future Internet. | |
| MORALES FIGUEROA | Adaptive video coding to optimize video streaming in Internet and wireless ad-hoc networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 9 |
|
| ST | Notification of lapse |
Effective date: 20161028 |