FR2932938A1 - Procede et dispositif de transmission de donnees - Google Patents

Procede et dispositif de transmission de donnees Download PDF

Info

Publication number
FR2932938A1
FR2932938A1 FR0854069A FR0854069A FR2932938A1 FR 2932938 A1 FR2932938 A1 FR 2932938A1 FR 0854069 A FR0854069 A FR 0854069A FR 0854069 A FR0854069 A FR 0854069A FR 2932938 A1 FR2932938 A1 FR 2932938A1
Authority
FR
France
Prior art keywords
image
images
video
packets
packet
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
FR0854069A
Other languages
English (en)
Other versions
FR2932938B1 (fr
Inventor
Eric Nassor
Frederic Maze
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 FR0854069A priority Critical patent/FR2932938B1/fr
Priority to US12/487,348 priority patent/US8812724B2/en
Publication of FR2932938A1 publication Critical patent/FR2932938A1/fr
Application granted granted Critical
Publication of FR2932938B1 publication Critical patent/FR2932938B1/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/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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • 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/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/142—Detection of scene cut or scene change
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/149—Data rate or code amount at the encoder output by estimating the code amount by means of a model, e.g. mathematical model or statistical model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/164—Feedback from the receiver or from the transmission channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/573—Motion compensation with multiple frame prediction using two or more reference frames in a given prediction direction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving management of server-side video buffer
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/23412—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs for generating or manipulating the scene composition of objects, e.g. MPEG-4 objects
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/23418—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234309—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4 or from Quicktime to Realvideo
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 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, manipulating MPEG-4 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/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
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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
    • 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/6583—Acknowledgement
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

On transmet une vidéo constituée de données organisées sous forme de paquets dans un réseau de communication. Le procédé comporte une étape de codage d'images avec compensation de mouvement (310), consistant à comprimer les images de la vidéo et à créer des dépendances entre images comprimées, une étape d'ordonnancement des paquets (330), consistant à envoyer les paquets sur le réseau suivant un ordre choisi, et une étape de contrôle de débit de la vidéo (320). L'étape de contrôle de débit (320) commande les étapes de codage d'image (310) et d'ordonnancement des paquets (330), en choisissant simultanément les dépendances entre images et l'ordre d'envoi des paquets au moment de coder une nouvelle image.

Description

La présente invention se rapporte à un procédé et à un dispositif de transmission de données entre un serveur et au moins un client dans un réseau de communication, ainsi qu'à un serveur mettant en oeuvre un tel procédé. Elle appartient au domaine de la transmission de données multimédia dans un réseau de communication de paquets. Elle s'applique en particulier à la transmission de données vidéo en direct (en anglais "live") impliquant le codage de la vidéo comprimée avec compensation de mouvement et l'ordonnancement des paquets du flux de données vidéo, sur un réseau tel que l'Internet ou les réseaux locaux de type IP ("Internet Protocof').
Dans un serveur de données multimédia numériques relié à un réseau de communication, par exemple une caméra de vidéosurveillance numérique ou de visioconférence qui envoie des données audio et vidéo, les données sont codées dans un format de compression numérique puis stockées localement dans une mémoire tampon ou buffer de stockage, avant d'être transmises sur le réseau vers un ou plusieurs clients. Ces clients reçoivent et consomment ces données, par exemple en jouant la vidéo et l'audio, au fur et à mesure de leur réception. On parle de "streaming" multimédia. Ces flux multimédia sont constitués de données telles que des images, des portions ou tranches (en anglais "slices") d'images ou des portions de sons (en anglais "samples") qui ont pour caractéristique d'avoir une durée de vie utile limitée, c'est-à-dire que ces données doivent impérativement être reçues et traitées par le périphérique récepteur avant une certaine échéance. Cette échéance correspond à l'instant où la donnée est requise pour être affichée ou jouée par le client. Au-delà de cette échéance, la donnée devient inutile et est purement et simplement ignorée par le client. Les données multimédia sont comprimées pour pouvoir être envoyées sur un réseau à débit limité. Cette compression dégrade la qualité des données, mais est nécessaire pour adapter les données au débit du réseau. Il est donc important d'utiliser la bande passante du réseau le mieux possible pour comprimer les données le moins possible et avoir la meilleure qualité.
Il faut aussi éviter de modifier trop rapidement le taux de compression des données multimédia. En effet, la qualité perçue par l'utilisateur pour des données avec un taux de compression variant rapidement est très dégradée. Dans le cas d'une vidéo, par exemple, I'oeil est très sensible aux changements de qualité des images. Il est donc important d'avoir des variations lissées. Par ailleurs, la compression crée des dépendances entre les données successives ; ainsi, si une donnée n'est pas reçue, les données suivantes sont corrompues pendant un certain temps. Dans le cas de données vidéo, on parle de compression avec compensation de mouvement. La vidéo peut être codée conformément à une des normes décrites dans les recommandations H.263, H.264 de l'ITU-T, ou encore MPEG-4. Ces flux multimédia sont transmis sur des réseaux de communication constitués de noeuds d'interconnexion (routeurs, commutateurs, etc.) afin d'acheminer les paquets de données en provenance de dispositifs source jusqu'à des dispositifs destinataires. Ils partagent ces réseaux avec d'autres flux de données (par exemple de la navigation Internet, un jeu vidéo, le transfert d'un fichier vers une imprimante, etc.). Ainsi, tous ces flux de données sont susceptibles de créer de la congestion sur les réseaux de communication quand ils transitent par un même lien réseau de capacité insuffisante. Les paquets en surplus finissent généralement par être rejetés par le noeud d'interconnexion situé à l'entrée du lien. Traditionnellement, les serveurs et les clients utilisent des protocoles de communication mettant en oeuvre des mécanismes de contrôle afin d'éviter de perdre continuellement une grande quantité de données en cas de congestion. Ils permettent de détecter l'apparition d'un phénomène de congestion en fonction des pertes de paquets et ils agissent sur le débit de transmission du flux de données afin de le réduire ou de l'augmenter de façon à être compatible avec la bande passante globale du réseau.
Les mécanismes de contrôle de congestion généralement mis en oeuvre dans les réseaux IP sont de type TFRC ("TCP Friendly Rate Controf', IETF RFC3448) ou AIMD ("Additive Increase/Multiplicative Decrease", IETF RFC2581). Ces algorithmes calculent périodiquement la quantité de données qui peut être envoyée. Des paquets correspondant à cette quantité de données sont ensuite pris dans le buffer des données déjà codées et sont envoyés sur le réseau.
Le débit calculé par le contrôle de congestion peut varier très rapidement et beaucoup plus rapidement que les changements du taux de compression des données multimédia. Cela peut conduire à une augmentation importante de la quantité de données dans le buffer de données à envoyer et donc, créer des temps d'attente importants. A cause de la durée de vie limitée des paquets de données, cette attente peut rendre certains paquets inutilisables par le client, ce qui peut aussi avoir, à cause des dépendances entre données, un impact très important sur la qualité perçue par l'utilisateur. On cherche donc à réduire l'impact d'un changement rapide du débit disponible sur la qualité des données.
On connaît par le document de brevet WO-A-2004 064373 une méthode pour coder une vidéo en utilisant un buffer d'images de référence à plusieurs images, ces images de référence étant utilisées dans le cadre de la dépendance entre données évoquée plus haut. Plusieurs techniques sont présentées pour sélectionner la meilleure référence à utiliser. En particulier, le codeur reçoit les informations de bande passante et de perte de paquets. Il peut adapter la taille des images à la bande passante. Dans le cas d'une diminution de bande passante, le codeur peut choisir une image de référence plus ancienne car de meilleure qualité. Dans le cas de pertes de paquets, il peut calculer la propagation de l'erreur et éviter de prendre comme référence une image qui est touchée par l'erreur. Cependant, le système décrit présente notamment l'inconvénient d'un manque de réactivité face aux variations de la bande passante. L'article de Sang H. KANG et Avideh ZAKHOR intitulé "Packet scheduling algorithm for wireless video sreaming", Packet Video workshop 2002, décrit un ordonnanceur de paquets (en anglais "packet scheduler') pour l'envoi de vidéos. Le rythme d'envoi des paquets est adapté aux contraintes de débit du réseau. L'ordre des paquets à envoyer est adapté par l'ordonnanceur à la structure de la vidéo et aux échéances des images : les images de type I sont plus prioritaires que les images de type P, les images P en début de groupe d'images (GOP, en anglais "Group Of Pictures") sont plus prioritaires que les images P en fin de GOP car elles comptent plus d'images dépendantes.
Cependant, cette solution n'est pas non plus satisfaisante en termes de réactivité en cas de changement de la bande passante. Le document de brevet US-A-6 141 380 présente une méthode pour coder une vidéo. Le codeur peut décider de sauter la prochaine image, c'est-à-dire de ne pas la coder. Cette décision est fondée sur la qualité de la vidéo, en particulier sur les mouvements, et sur une estimation de la bande passante disponible. Néanmoins, cette méthode n'offre pas non plus une réactivité suffisante pour adapter le codage et la transmission des données aux variations de la bande passante.
La présente invention a pour but de remédier aux inconvénients de l'art antérieur en déterminant à la fois comment coder les données, quels paquets envoyer et dans quel ordre les envoyer, notamment en fonction de l'évolution de la bande passante disponible. Dans ce but, la présente invention propose un procédé de transmission d'une vidéo constituée de données organisées sous forme de paquets dans un réseau de communication, ce procédé comportant : une étape de codage d'images avec compensation de mouvement, consistant à comprimer les images de la vidéo et à créer des dépendances entre images comprimées, une étape d'ordonnancement des paquets, consistant à envoyer les paquets sur le réseau suivant un ordre choisi et une étape de contrôle de débit de la vidéo, ce procédé étant remarquable en ce que l'étape de contrôle de débit commande les étapes de codage d'image et d'ordonnancement des paquets en choisissant simultanément les dépendances entre images et l'ordre d'envoi des paquets au moment de coder une nouvelle image.
Ainsi, l'ordre des paquets de données est déterminé en même temps que le choix du type de codage et des références de la prochaine image. L'invention permet d'adapter la taille, c'est-à-dire le débit de la vidéo, et sa qualité à la bande passante disponible : en supprimant ou en retardant l'envoi de certaines images déjà codées, le codeur peut garder une taille suffisante pour la prochaine image à coder ; de plus, le codage de la nouvelle image tient compte des images qui pourraient ne pas être reçues. En outre, l'invention permet de récupérer rapidement d'une forte baisse de bande passante, voire d'une coupure de réseau, avec une perte de qualité faible. Par ailleurs, en cas de baisse de la bande passante disponible du réseau, l'invention permet de ne pas détruire des paquets, mais seulement de retarder leur envoi ; ainsi, en cas d'accroissement rapide de la bande passante après la baisse, le système peut souvent récupérer et finalement envoyer les paquets qui avaient été retardés dans un premier temps. Dans un mode particulier de réalisation, on choisit les dépendances entre images et l'ordre d'envoi des paquets en fonction de la bande passante disponible du réseau, et/ou du nombre de paquets en attente d'envoi et du contenu de la vidéo.
Le codage de la vidéo transmise peut ainsi varier rapidement en fonction des variations de débit du réseau. Le débit peut être mesuré directement ou déduit implicitement du nombre de paquets en attente d'envoi. Selon une caractéristique particulière, le procédé comporte en outre une étape consistant à évaluer la bande passante disponible au moyen d'un mécanisme de contrôle de congestion du réseau. Les mécanismes de contrôle de congestion permettent d'obtenir une indication de débit effectivement disponible sur le réseau en présence de trafic concurrent sans nécessiter de support matériel de la part de l'infrastructure du réseau.
Selon une caractéristique particulière, le mécanisme de contrôle de congestion est du type TFRC ("TCP Friendly Rate Contre) ou AIMD ("Additive Increase/Multiple Decrease").
Ces mécanismes de contrôle de congestion n'utilisent que des informations simples à calculer : les pertes de paquets détectées par le client et le temps de communication entre le serveur et le client. Selon une caractéristique particulière, le procédé comporte en outre une étape consistant à déterminer une qualité pour la vidéo en fonction de son contenu, cette qualité tenant compte des images non envoyées. Cela permet d'optimiser la qualité de la vidéo effectivement reçue et décodée par le client et non pas la qualité de la vidéo codée. Selon une caractéristique particulière, le choix des dépendances entre images consiste à définir un type d'image avec ou sans dépendance. La sélection du type d'image (images sans dépendance, par exemple de type I ou images avec dépendance, par exemple de type P) est simple à mettre en oeuvre et s'applique à de nombreux codecs, même anciens comme ceux de type MPEG2.
Selon une caractéristique particulière, lorsqu'on définit un type d'image avec dépendance, le choix des dépendances entre images consiste en outre à définir au moins une image de référence possible. La sélection des dépendances peut ainsi être beaucoup plus fine, ce qui permet d'obtenir une meilleure adaptation du débit de la vidéo au débit réseau disponible. Le choix de l'ordre d'envoi des paquets peut consister à décider de supprimer au moins un paquet. La suppression de paquets est très simple à mettre en oeuvre. D'autre part, dans certains cas, des paquets ne doivent pas être envoyés car ils seraient incompatibles avec certains choix de changement de codage de la vidéo (cas d'une suppression d'une image I, par exemple). Le choix de l'ordre d'envoi des paquets peut aussi consister à décider de retarder ou d'avancer l'envoi d'au moins un paquet. On peut ainsi se réserver la possibilité de changer d'avis si le débit 30 disponible sur le réseau augmente à nouveau. On pourra ainsi envoyer des images qui n'auraient pas été envoyées si le débit était resté bas.
Selon une caractéristique particulière, on attribue à chaque paquet une certaine priorité et une certaine échéance au terme de laquelle l'envoi du paquet devient inutile et on envoie les paquets par priorités décroissantes et par échéances croissantes.
Cela permet de modifier de façon simple l'ordre d'envoi des paquets. Selon une caractéristique particulière, la vidéo est codée suivant le format H.264. Ce format, le plus récent et le plus efficace à ce jour, permet en particulier d'avoir plusieurs images de référence, ce qui facilite la sélection 10 dynamique des images de référence. Dans le même but que celui indiqué plus haut, la présente invention propose également un serveur de transmission d'une vidéo constituée de données organisées sous forme de paquets dans un réseau de communication, ce serveur comportant : 15 un module de codage d'images avec compensation de mouvement, comprimant les images de la vidéo et créant des dépendances entre images comprimées, un module d'ordonnancement des paquets, adapté à envoyer les paquets sur le réseau suivant un ordre choisi et 20 un module de contrôle de débit de la vidéo, ce serveur étant remarquable en ce que le module de contrôle de débit commande le module de codage d'image et le module d'ordonnancement des paquets en choisissant simultanément les dépendances entre images et l'ordre d'envoi des paquets au moment de coder une nouvelle image. 25 Toujours dans le même but, la présente invention vise aussi un système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, remarquable en ce qu'il comprend au moins un dispositif terminal équipé d'un dispositif de transmission tel que succinctement décrit ci-dessus. 30 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 tel que succinctement décrit ci-dessus. Toujours dans le même but, la présente invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, remarquable en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de transmission tel que succinctement décrit ci-dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du dispositif de transmission, 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, ils ne sont pas répétés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1 représente de façon schématique un réseau de communication de données du type réparti susceptible de mettre en oeuvre la présente invention ; - la figure 2 représente de façon schématique un mode particulier de réalisation d'un dispositif émetteur adapté pour mettre en oeuvre la présente invention ; - la figure 3 représente de façon schématique l'architecture d'un serveur susceptible de mettre en oeuvre la présente invention, dans un mode particulier de réalisation ; - la figure 4 illustre la structure d'une vidéo comprimée pour sa transmission conformément à la présente invention, dans un mode particulier de réalisation ; - la figure 5 est un graphique illustrant un exemple non limitatif de contrôle de congestion mis en oeuvre dans le cadre de la présente invention ; - la figure 6 illustre le principe du contrôle de débit mis en oeuvre dans le cadre de la présente invention, dans un exemple non limitatif ; - la figure 7 est un organigramme illustrant les principales étapes de l'ordonnancement de paquets conforme à la présente invention, dans un mode particulier de réalisation ; - la figure 8 est un organigramme illustrant les principales étapes du contrôle de débit conforme à la présente invention, dans un mode particulier de réalisation ; - les figures 9a, 9b et 9c sont des organigrammes illustrant les principales étapes de la sélection du mode de codage conforme à la présente invention, dans un mode particulier de réalisation ; et - la figure 10 récapitule schématiquement les différents états et transitions entre états possibles pour des images contenues dans une mémoire tampon d'images de référence et dans une mémoire tampon de paquets, lors de la simulation du fonctionnement de ces mémoires conformément à la présente invention, dans un mode particulier de réalisation.
La figure 1 montre un exemple de réseau de communication de données où la présente invention peut être mise en oeuvre. Un dispositif émetteur ou serveur 101 transmet des paquets de données d'un flux de données à un dispositif récepteur ou client 102 à travers un réseau de communication de données 100.
Le réseau 100 peut contenir des noeuds d'interconnexion 103 et des liaisons 104 qui créent des chemins entre les dispositifs émetteur et récepteur. Les noeuds d'interconnexion 103 et le dispositif récepteur 102 peuvent rejeter des paquets de données en cas de congestion, c'est-à-dire en cas de débordement de la mémoire de réception.
Le réseau 100 peut être par exemple un réseau sans fil du type WiFi / 802.11a ou b ou g, ou un réseau Ethernet, ou Internet. Le flux de données fourni par le serveur 101 comprend des informations vidéo codées par compensation de mouvement. Le dispositif émetteur 101 peut être n'importe quel type de dispositif de traitement de données susceptible de coder et de fournir un flux de données à un dispositif récepteur. A titre d'exemple nullement limitatif, le dispositif émetteur peut être un serveur de flux capable de fournir un contenu à des clients sur demande, par exemple en utilisant le protocole RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocof') sur UDP (protocole de datagramme utilisateur, en anglais "User Datagram Protocof') ou DCCP (protocole de contrôle de congestion de datagramme, en anglais "Datagram Congestion Control Protocof') ou n'importe quel autre type de protocole de communication. Le dispositif émetteur peut mettre en oeuvre un algorithme de contrôle de congestion du type mentionné plus haut, à savoir, TFRC ou encore AIMD.
Le dispositif récepteur 102 reçoit les données, les décode et les affiche avec une latence faible. Tant le dispositif émetteur 101 que le dispositif récepteur 102 peut être par exemple du type représenté sur la figure 2, décrite ci-dessous. La figure 2 illustre en effet notamment un dispositif émetteur 101 adapté pour incorporer l'invention, dans un mode particulier de réalisation. De préférence, le dispositif émetteur 101 comporte une unité centrale de traitement (UC) 201 capable d'exécuter des instructions provenant d'une mémoire morte (ROM) de programmes 203 à la mise sous tension du dispositif émetteur, ainsi que des instructions concernant une application logicielle provenant d'une mémoire principale 202 après la mise sous tension. La mémoire principale 202 est par exemple du type mémoire vive (RAM) et fonctionne comme zone de travail de l'UC 201. La capacité de mémoire de la RAM 202 peut être augmentée par une RAM facultative connectée à un port d'extension (non illustré).
Les instructions concernant l'application logicielle peuvent être chargées dans la mémoire principale 202 à partir d'un disque dur 206 ou bien de la ROM de programmes 203 par exemple. De façon générale, un moyen de stockage d'informations qui peuvent être lues par un ordinateur ou par un microprocesseur, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Ce moyen de stockage est intégré ou non au dispositif 101 et est éventuellement amovible. L'exécution du ou des programmes mentionnés ci-dessus peut avoir lieu par exemple lorsque les informations stockées dans le moyen de stockage sont lues par l'ordinateur ou par le microprocesseur. L'application logicielle, lorsqu'elle est exécutée par l'UC 201, entraîne l'exécution des étapes des organigrammes des figures 7 à 9.
Le dispositif émetteur 101 comporte en outre une interface réseau 204 qui permet sa connexion au réseau de communication 100. L'application logicielle, lorsqu'elle est exécutée par l'UC 201, est adaptée pour réagir à des requêtes du client 102 reçues par le biais de l'interface réseau 204 et pour fournir au client 102 des flux de données par l'intermédiaire du réseau 100.
Le dispositif émetteur 101 comporte de plus une interface d'utilisateur 205, constituée par exemple d'un écran et/ou d'un clavier et/ou d'un dispositif de pointage tel qu'une souris ou un crayon optique, pour afficher des informations pour un utilisateur et/ou recevoir des entrées de celui-ci. Cette interface est optionnelle.
Un appareil mettant en oeuvre l'invention est 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éosurveillance (par exemple du type Webcam), un lecteur DVD, un serveur multimédia ou encore un élément routeur dans un réseau. Cet appareil peut intégrer directement un capteur numérique d'images, ou, en option, être connecté à différents périphériques tels que, par exemple, une caméra numérique (ou un scanner ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant à l'appareil des données multimédia. L'appareil peut aussi avoir accès à des données multimédia sur un support de stockage (par exemple le disque dur 206) ou encore recevoir un flux multimédia à traiter, par exemple en provenance d'un réseau. La figure 3 illustre plus en détail l'architecture d'un serveur 101 conforme à la présente invention, dans un mode particulier de réalisation. Le serveur dispose en entrée d'une vidéo provenant par exemple d'un capteur 305. Le capteur 305 est par exemple une caméra. La vidéo est fournie à un codeur vidéo ou codec 310 qui code la vidéo dans un format connu, par exemple H.264, puis mémorise le résultat dans une mémoire tampon 325 (en anglais "buffer") sous forme de paquets prêts à être envoyés. Dans toute la suite, cette mémoire tampon est appelée buffer de paquets 325. En variante, le serveur peut recevoir une vidéo déjà codée en provenance d'un autre réseau, par exemple dans le cas d'une passerelle domestique (en anglais "home gateway') recevant une chaîne de télévision par Internet. Dans ce cas, le codec 310 transcode la vidéo pour adapter son débit à la bande passante du réseau à la maison, lequel est par exemple un réseau sans fil. De même que dans le premier cas, les données créées sont mémorisées dans le buffer de paquets 325. Le codec 310 mémorise plusieurs images de référence dans une mémoire tampon 315. Dans toute la suite, cette mémoire tampon est appelée buffer d'images de référence 315. Ces images ont été codées puis décodées et vont servir à comprimer les prochaines images.
Le codec 310 est contrôlé par un module de contrôle de débit de la vidéo 320. Le module 320 détermine la quantité de données que peut produire le codeur et la qualité de la vidéo codée. Pour cela, classiquement, le module de contrôle de débit 320 calcule le pas de quantification de la prochaine image en fonction du contenu du buffer de paquets 325 et des informations de débit réseau provenant d'un module de contrôle de congestion 335. Le module de contrôle de débit 320 sélectionne aussi une sous-partie des images de référence que le codeur peut utiliser. Les paquets mémorisés dans le buffer de paquets 325 sont lus et envoyés sur le réseau par un module ordonnanceur de paquets 330 chargé de l'envoi des paquets. L'algorithme d'envoi des paquets est décrit plus en détail ci-après en liaison avec la figure 7. Le module ordonnanceur de paquets 330 décide des paquets à envoyer chaque fois qu'il est appelé par le module de contrôle de congestion 335. Le module de contrôle de congestion 335 calcule le débit disponible sur le réseau et décide des instants où des paquets peuvent être envoyés. Pour effectuer ces calculs, le module 335 utilise des informations reçues du client à travers le réseau, notamment les événements de perte de paquets, le temps de communication aller-retour sur le réseau (RTT, en anglais "Round-Trip Time") et la latence d'affichage. La latence d'affichage est la durée de vie limite d'une donnée. Au-delà de la latence, les données ne peuvent plus être utilisées car l'image a déjà été décodée pour être affichée. Ces informations sont transmises classiquement en utilisant les messages RTCP du protocole RTP. La latence d'affichage peut aussi être reçue lors d'une phase initiale d'initiation de la communication (par exemple lors des échanges RTSP, protocole de streaming en temps réel, en anglais "Real Time Streaming Protocof', IETF RFC 2326).
La figure 4 représente les structures définies pour le codage fondé sur la compensation de mouvement. Une vidéo 400 comprimée par un codeur fondé sur la compensation de mouvement (par exemple conforme à la norme H.264, MPEG-4 Part 2, etc.) est composée d'un ensemble d'images 401, 402, 403, etc. codées suivant plusieurs modes : sans compensation de mouvement, on parle de codage intra ou I (image 401). Le mode inter (e.g. image 402) repose sur une compensation de mouvement à partir d'une image de référence. Le mode bidirectionnel ou B (e.g. image 403) repose sur une compensation de mouvement à partir de deux images de référence. Un GOP (en anglais "Group Of Pictures") est une suite d'images 20 commençant par une image I qui ne fait aucune référence à une image dans un GOP précédent. Les images sont comprimées par macroblocs (blocs de 16x16 pixels). Les macroblocs sont groupés en tranches (en anglais "slices") 420. Dans le cas d'un envoi d'une vidéo sur un réseau, chaque tranche est mise 25 dans un paquet RTP et envoyée sur le réseau vers le récepteur. Dans une image, les macroblocs peuvent avoir différents types : dans une image I, tous les macroblocs sont de type I, mais dans une image P, les macroblocs sont de type I ou P et dans une image B, ils sont de type I, P ou B. Chaque macrobloc peut aussi utiliser une image de référence différente dans 30 le buffer d'images de référence 315. Le buffer d'images de référence 315 est constitué d'un ensemble d'images 414, 412, etc. de la séquence vidéo, précédemment codées puis décodées. Il permet de stocker les images utilisées comme références lors de la compensation de mouvement. Pendant le codage, chaque macrobloc codé en inter passe d'abord par une étape de compression qui commence par un calcul de mouvement. En mode inter, un macrobloc peut être partitionné jusqu'à une taille 4x4 dans le format H.264. A l'étape de calcul de mouvement, chaque partition est comparée à des zones dans des images de référence contenues dans le buffer d'images de référence 315. La zone sélectionnée est celle qui ressemble le plus aux pixels à coder. Il existe de nombreux algorithmes permettant d'obtenir rapidement un bon résultat sans faire une recherche exhaustive dans toutes les images de référence. Le buffer d'images de référence est utilisé à la fois dans le codeur et dans le décodeur. Pour le codeur, il est utilisé lors de l'estimation de mouvement et pour le décodeur, il est utilisé pour la compensation de mouvement. Par conséquent, ce buffer doit être mis à jour de la même façon du côté du client et du serveur. Ce buffer est généralement rempli en suivant le principe d'une file d'attente FIFO. Les nouvelles images de référence (comme l'image 412 sur la figure 4) sont ajoutées en queue de la file du buffer d'images de référence. Lorsque la queue est pleine, l'image en tête de la file est supprimée (image 414 sur l'exemple de la figure 4). Il existe cependant des cas plus complexes où des commandes de manipulation du buffer peuvent être associées à des images. Dans le cas du format H.264, le buffer d'images de référence 315 présente la possibilité de distinguer deux types de mémoires : la mémoire à court terme et la mémoire à long terme. La mémoire à court terme fonctionne sur le principe de la file d'attente FIFO, décrit précédemment. La mémoire à long terme permet de conserver une image pour une durée plus importante. Des commandes présentes dans les en-têtes des tranches permettent de marquer une image comme référence à long terme. Pour enlever les images du buffer d'images de référence à long terme, il faut utiliser une commande explicite ("mmco"), spécifiée également dans l'en-tête des tranches.
Toujours dans le cas du format H.264, une image I de type IDR ("Instantaneous Decoding Refresh" : par exemple, la première image d'un GOP) vide le buffer d'images de référence. Le type IDR est spécifié sous forme d'un indicateur (en anglais "flag") dans l'en-tête des tranches de l'image.
Conformément à la présente invention, on limite la recherche des vecteurs de mouvement à une sous-partie des images de référence sélectionnée par le module de contrôle de débit 320 en fonction de critères liés au réseau. Cette fonctionnalité est décrite en détail plus loin. La différence entre la valeur exacte de l'image et la partie d'image sélectionnée par le calcul de mouvement est calculée. Cette valeur est appelée résidu. Le résidu (ou la valeur de l'image dans le cas d'un macrobloc intra) est ensuite transformé par bloc puis quantifié. La quantification permet de contrôler la quantité de données produite (il s'agit d'une compression avec pertes). Le paramètre de quantification est choisi par le module de contrôle de débit 320. Le résultat de la quantification passe par un codage entropique (tel qu'un codage de longueur variable, en anglais "Variable Length Coding") par tranche. On obtient ainsi les macroblocs codés, qui sont ensuite groupés par tranches et envoyés dans des paquets RTP. En fonction de la taille de la vidéo, du type de l'image codée (I, P ou B), du pas de quantification et du contenu des images, la taille et donc le nombre de paquets produits par image est très variable : de quelques paquets à plusieurs centaines.
Dans le cas d'une vidéo à 25 images par seconde, une nouvelle image est codée toutes les 40 ms. Un algorithme de contrôle de congestion calcule la quantité de données envoyée à chaque instant sur le réseau. En effet, si on envoyait tous les paquets composant une image en un temps très court, on créerait une congestion du réseau. II faut donc lisser l'envoi des paquets pour éviter d'envoyer trop de paquets simultanément. II faut aussi s'adapter à l'état de congestion du réseau en faisant varier le nombre de paquets qu'on envoie.
Le contrôle de congestion le plus connu est celui de TCP qui est de type AIMD. Cet algorithme fonctionne en augmentant de façon progressive le débit des données envoyées tant que le client signale que les paquets sont bien reçus.
En moyenne, TCP envoie un paquet en plus pour chaque aller-retour correct, ce qui donne une augmentation linéaire. Lorsqu'une erreur apparaît, cela signifie que le réseau est congestionné ; en réaction, le débit est divisé par 2. Ce fonctionnement est illustré par la courbe de la figure 5, représentant le débit en fonction du temps. Lorsqu'il n'y a pas de pertes, le débit augmente linéairement. Les événements de pertes (repérés en 510, 512, 514, 516 sur le dessin) provoquent une chute du débit disponible. On peut parfois avoir plusieurs événements de pertes très rapprochés et donc des baisses rapides très importantes. A cause du temps de transmission du paquet et du temps pour recevoir l'information si le paquet a bien été reçu, AIMD a un comportement étroitement lié au temps de communication aller-retour du réseau (RTT). Dans un réseau local ou à courte distance, le temps de RTT peut être très bas, typiquement de l'ordre de la milliseconde. On peut donc avoir de très rapides variations de débit réseau par comparaison avec la vitesse du codeur (par exemple, une image toutes les 40 ms). On peut aussi parfois avoir une interruption totale de la communication, par exemple si, à cause d'une forte congestion, tous les paquets d'accusé de réception ont été perdus. Dans ce cas, l'interruption peut durer plusieurs centaines de millisecondes.
Comme l'algorithme de contrôle de congestion AIMD, un algorithme de type TFRC fonctionne en utilisant aussi les événements de perte de paquet et un calcul de RTT. Il calcule le débit en suivant une équation qui doit donner un débit comparable à celui de TCP, mais avec des variations plus lissées. On a constaté cependant que même si les variations sont moins brutales, on peut avoir de très fortes variations sur de très courtes périodes dans le cas d'un réseau avec un RTT faible. Comme dans l'algorithme de contrôle de congestion AIMD, on peut avoir des interruptions de plusieurs centaines de millisecondes.
Dans les deux cas, le module de contrôle de congestion 335 reçoit des informations de contrôle provenant du client, lui permettant de calculer le taux de perte ou les événements de perte ainsi que le temps de RTT. En utilisant ces informations, le module de contrôle de congestion 335 calcule un débit réseau disponible. II peut donc activer l'ordonnanceur de paquets 330 de façon répétée en espaçant dans le temps chaque activation. A chaque activation, il lui indique un nombre de paquets à envoyer pour respecter le débit courant. L'information de débit est aussi envoyée au calcul de débit du codeur pour que celui-ci puisse l'utiliser pour adapter la taille des prochaines images. On explique maintenant le principe du contrôle de débit conforme à l'invention à l'aide de l'exemple non limitatif illustré sur la figure 6. On se place dans le cas où le débit réseau a été stable en moyenne sur un période de plusieurs images et où le débit réseau disponible baisse brutalement. Les images précédentes (601, 602, 603, 604 sur le dessin) ont été codées, donnant des images comprimées 611, 612, 613, 614 de différents types (I pour 613, P pour les autres) et ayant des tailles variables. La première image 611 a déjà été envoyée au client et a donc été supprimée du buffer de paquets 325. Les trois autres images sont encore dans le buffer de paquets 325 au moment où le codeur doit coder la nouvelle image. Comme les quatre images codées sont de type I ou P, dans le cas d'un buffer d'images de référence 315 organisé en file d'attente FIFO à 4 places, elles peuvent aussi être stockées dans le buffer d'images de référence du codeur. Cependant, dans le cas où l'image 613 est une image I de type IDR, elle a pour conséquence d'invalider les images précédentes 601, 602 dans le buffer d'images de référence. Cela est représenté par les hachures sur les images 601 et 602 sur le dessin. A l'instant considéré, le serveur doit coder une nouvelle image 605. Dans l'état de l'art (cas 1), le contrôle de débit va calculer un pas de quantification pour la nouvelle image, puis le codeur va choisir pour chaque macrobloc une des images de référence pour le calcul de mouvement (par exemple l'image la plus récente 604). Comme on a une baisse importante de débit, la nouvelle image codée 620 sera fortement réduite en taille et donc très dégradée en qualité. On peut facilement constater que pour envoyer toutes les images précédentes et donc vider le buffer, l'ordonnanceur de paquet mettra plus de temps qu'initialement estimé par le contrôle de débit. On peut donc se retrouver dans la situation où les données de la nouvelle image 620 ne peuvent pas être envoyées. Cela pose un sérieux problème car toute image future qui l'utiliserait comme référence ne pourrait pas être décodée par le client. Une version améliorée du contrôle de débit (non représentée sur la figure 6) pourrait tenir compte de l'état du buffer de paquets 325 pour calculer un état de l'image de référence dans le buffer d'images de référence 315. S'il constate que la nouvelle image 605 ne peut pas être envoyée, il peut alors la marquer comme invalide dans le buffer d'images de référence, pour éviter de l'utiliser comme référence pour les prochaines images.
Cet exemple montre le cas où l'état d'une image de référence dans le buffer d'images de référence 315 est modifié. Il existe plusieurs autres possibilités si on autorise le module de contrôle de débit 320 à contrôler le buffer des images précédemment codées mais pas encore envoyées (buffer de paquets 325).
Dans le cas 2, le contrôle de débit peut décider de ne pas envoyer une image ancienne (par exemple l'image 614) du buffer de paquets 325. L'image 614 peut facilement être supprimée sans impact sur les autres images de la vidéo codée, car il s'agit d'une image P, dont aucune autre image ne dépend. Si cette image 614 n'est pas envoyée, le codeur peut se permettre de coder la nouvelle image 630 avec une taille plus importante et donc une meilleure qualité que dans le cas 1 (image 620). Le codeur doit éviter de prendre l'image 604 comme référence, puisque sa version codée 614 ne sera pas envoyée. Sur la figure 6, le codeur choisit par exemple pour un macrobloc, une référence sur l'image 603.
Pour ne pas envoyer l'image 604, on peut simplement supprimer tous les paquets de l'image codée 614 dans le buffer de paquets 325. Cependant, il vaut mieux en changer la priorité et ne pas la supprimer immédiatement. En effet, si par la suite le débit du réseau augmente, on pourra peut-être l'envoyer à temps, même si elle est envoyée après l'image 630. Cet exemple montre la modification simultanée de l'état d'une image dans le buffer d'images de référence 315 et le buffer de paquets 325.
Une autre solution possible (non représentée) serait de supprimer l'image 612. Dans ce cas, la nouvelle image codée pourrait utiliser, soit l'image 603, soit l'image 604 comme référence. Pour choisir entre le cas 1 et le cas 2 ou cette dernière solution, il faut prendre en compte, non seulement la qualité de chaque image, mais aussi l'impact sur la qualité de la vidéo. Par exemple, dans le cas où il y a un changement de scène entre l'image 602 et l'image 603 (ce qui justifierait d'ailleurs le codage en I de l'image de début de scène 613) mais pas entre l'image 604 et l'image 605, il vaut mieux choisir le dernier cas (suppression de l'image 602) : en effet, la suppression d'une image avant le changement de scène est peu visible comparé à une suppression d'image dans une scène. On peut aussi avoir le cas 3 où l'image 613 (de type I) est de taille tellement importante qu'elle risque avec le nouveau débit de trop retarder toutes les images suivantes. On peut donc dans ce cas préférer la solution suivante : l'image 613 de type I est supprimée ainsi que l'image 614 car celle-ci utilise l'image 603 comme référence et ne peut donc pas être décodée si l'image codée 613 n'est pas reçue. Si l'image 613 n'est pas envoyée, les images 601 et 602 ne sont pas invalidées dans le buffer d'images de référence 315. Il faut donc changer leur état d'invalide à valide.
Le codeur dispose ainsi de plus de débit pour la nouvelle image 640 et il choisit une image de référence parmi celles qui sont ou doivent être envoyées (611 et 612). L'impact sur la qualité de la vidéo doit être estimé pour savoir si cette solution est bien la meilleure possible. La suppression de plusieurs images peut dégrader la qualité d'une vidéo de façon importante dans le cas d'une vidéo avec des mouvements rapides. En revanche, dans le cas de mouvements lents, une vidéo peut supporter plus facilement la suppression de plusieurs images.
Cet exemple montre que l'état d'une image de référence dans le buffer d'images de référence 315 peut passer d'invalide à valide en fonction des changements d'état des images dans le buffer de paquets 325. Un dernier cas est représenté en 650, où on préfère supprimer toutes les images du buffer de paquets (612, 613 et 614) pour coder la nouvelle image, soit en référence à l'image 601, soit en mode I. Comme toutes les images précédentes ont été supprimées, on dispose d'un débit plus important pour la nouvelle image. Cette méthode peut par exemple être utilisable dans le cas où la nouvelle image est un début de scène et donc où on préfère supprimer les images de fin de la scène précédente pour avoir une meilleure qualité sur la nouvelle scène. L'organigramme de la figure 7 illustre l'algorithme d'ordonnancement de paquets mis en oeuvre par le module ordonnanceur de paquets 330. L'ordonnanceur de paquets 330 est appelé par le module de contrôle de congestion 335 à certains instants avec l'ordre d'envoyer N paquets (étape 700). Lors d'une première étape 705, une variable de priorité courante est mise à la priorité haute. Puis lors d'un test 710, on détermine si le nombre de paquets à 20 envoyer est atteint. Si c'est le cas, on arrête l'algorithme (étape 715). Sinon (étape 720), on choisit tous les paquets du buffer de paquets 325 ayant la priorité courante. On choisit ensuite le paquet ayant la plus petite échéance (étape 725). L'échéance d'un paquet est calculée en fonction de la date de création de 25 l'image associée au paquet, du temps de communication avec le client et de la latence du client, c'est-à-dire le retard que le client peut accepter. Ce temps est déterminé dans une phase de négociation avant l'établissement d'un flux vidéo, ou reçu régulièrement avec des paquets RTCP. Il est important de tenir compte de ce temps maximum pour ne pas envoyer des paquets qui sont trop en retard 30 et donc ne sont plus utiles pour le client. C'est ce qui est fait lors du test 740, qui consiste à déterminer si l'échéance peut être respectée, puis à l'étape 745, où on détruit les paquets trop anciens sans les envoyer, avant de revenir à l'étape 725 de sélection des paquets par échéance. Si, à l'étape 725, plus aucun paquet n'existe avec la priorité courante, on peut baisser la priorité courante (étape 730). Si la priorité était déjà au plus bas niveau acceptable, on peut arrêter l'algorithme (étape 735). Sinon, on retourne à l'étape 720 de sélection des paquets par priorité. Il est à noter que l'algorithme décrit ici permet de gérer plusieurs niveaux de priorités, car on pourrait choisir d'envoyer certains paquets plus importants avant d'autres en fonction par exemple d'un critère d'importance pour l'effet visuel. Il est important cependant que les paquets de priorité la plus basse ne soient pas envoyés, car ils pourraient entrer en conflit avec d'autres paquets déjà envoyés, à cause des dépendances entre images. Seul le contrôle de débit peut décider de remonter la priorité d'un paquet pour l'envoyer en tenant compte des contraintes de dépendance entre images.
Dans le cas où on détermine lors du test 740 que l'échéance du paquet peut être respectée, on passe à l'envoi du paquet (étape 750). On teste ensuite si tous les paquets de l'image ont été envoyés (test 755). Si c'est le cas, on notifie le module de contrôle de débit 320 à l'étape 760, pour que celui-ci en tienne compte dans son étape de sélection des priorités des images. On retourne ensuite au test 710 pour vérifier si le bon nombre de paquets a été envoyé. L'organigramme de la figure 8 illustre l'algorithme de contrôle de débit, qui permet à la fois de choisir les caractéristiques de codage de la prochaine image (quantification, image de référence) et les priorités des paquets dans le buffer des paquets à envoyer. Lors d'une première étape 805, on cherche à obtenir une prédiction de la bande passante moyenne pour les prochains instants. Idéalement, on souhaiterait connaître la bande passante qui sera disponible jusqu'à la date de codage de la prochaine image. Comme décrit précédemment, le rythme de variation de la bande passante peut être très rapide comparé au rythme des images. La valeur de la bande passante calculée par le contrôle de congestion est plus une valeur instantanée qu'il est donc préférable de moyenner pour obtenir une bande passante moyenne depuis la dernière image. Cette valeur est utilisée comme valeur prédictive pour les prochains instants. Ensuite, lors d'une étape 810, on évalue le temps nécessaire pour vider le buffer de paquets 325 en prenant en compte la taille actuelle de celui-ci. En tenant compte de la latence d'affichage du client, on peut calculer la date maximale à laquelle un paquet doit être envoyé et ainsi, vérifier si toutes les images du buffer de paquets respectent leur échéance (test 812). Si ce n'est pas le cas, on choisit de supprimer certaines images en faisant un autre choix de codage (étape 825). Si on détermine lors du test 812 que le temps de vidage du buffer de paquets 325 est acceptable, on cherche ensuite (étape 815) à calculer la taille de l'image et les bons paramètres de compression pour respecter les objectifs de débit et ne pas faire déborder le buffer de sortie tout en maximisant la qualité de la vidéo. Une technique classique consiste à utiliser un modèle débit-distorsion. A titre d'exemples non limitatifs, des modèles connus utilisés dans le cadre de la compression MPEG sont TMN-5 ou TMN-8. Ces modèles sont fondés sur une loi quadratique : Bframe = a/q + b/q2 où: ù Bframe est l'objectif de débit pour l'image courante, - q est le pas de quantification moyen utilisé dans l'image, - a et b sont des paramètres du modèle estimé par régression linéaire à partir des images précédentes de même type (I, P ou B). Il faut ensuite vérifier si la qualité de la vidéo ainsi obtenue est acceptable (test 820). On peut pour cela considérer un critère de continuité de la qualité des images. Si la qualité de la prochaine image est fortement dégradée par rapport aux images précédentes, on passe à l'étape 825 d'évaluation d'autres choix de codage. Cette étape est décrite en détail plus loin en liaison avec la figure 9a. Le résultat de cette étape est un choix d'images de référence utilisables par le codeur, les priorités d'envoi des paquets et le pas de quantification de la prochaine image. On peut aussi vouloir réévaluer les scénarios de codage si on a une forte hausse de la qualité de l'image : en effet, on pourra peut-être envoyer des images qui étaient en priorité basse.
En fonction de ces valeurs relatives au codage, on peut, à l'étape suivante 830, mettre à jour le buffer des images de référence 315 du codeur et les priorités dans le buffer de paquets 325. On peut ensuite procéder au codage de la prochaine image (étape 835).
Les organigrammes des figures 9a, 9b et 9c illustrent les principales étapes de la sélection simultanée des images de référence et des images à envoyer. Cet algorithme simule le fonctionnement du buffer d'images de référence 315 et du buffer de paquets 325 pour trouver quelles images peuvent être envoyées et quelles images peuvent être utilisées comme références, l'objectif étant d'avoir une vidéo de la meilleure qualité possible. L'algorithme utilise les dépendances (utilisation comme image de référence) entre les images déjà codées. On a ainsi un graphe de dépendance entre les images précédemment codées. On dit qu'une image A dépend d'une autre image B si au moins un macrobloc de A utilise comme référence une zone de B. Il convient d'abord de simuler le fonctionnement du buffer d'images de référence du client pour connaître exactement son contenu, afin de savoir quelles sont les images qui peuvent être envoyées. En effet, l'envoi ou non d'une image peut avoir plusieurs conséquences sur le buffer d'images de référence du client et donc, sur le choix des autres images qui peuvent être envoyées: - l'ajout d'une image dans le buffer d'images de référence ajoute une image qui peut être utilisée comme référence. Ainsi les images dépendantes peuvent être envoyées. Et donc, inversement, si une image de référence n'est pas envoyée, les images dépendantes ne peuvent pas être envoyées. - le décodage et l'ajout d'une image peut détruire des images dans le buffer d'images de référence du client : d'une part, à cause du fonctionnement FIFO avec mémoire limitée du buffer d'images de référence. L'ajout d'une image supprime donc l'image la plus ancienne ; d'autre part, à cause des commandes de manipulation des images de type long terme du buffer d'images de référence ; enfin, à cause des images de type IDR, qui vident le buffer d'images de référence.
Les images de référence ainsi supprimées ne peuvent plus être utilisées par d'autres images qui seraient décodées ensuite. La simulation utilise deux buffers simulés avec plusieurs états pour chaque image : - l'état des images dans la simulation du buffer d'images de référence peut être : Présent : l'image est présente dans le buffer d'images de référence du client et utilisable ; Invalide : l'image est présente dans le buffer d'images de référence mais n'est pas correcte (elle n'a pas été transmise complètement ou elle dépend d'images qui ne sont pas présentes) ; Détruit : l'image a été supprimée du buffer d'images de référence du client ; Absent : l'image n'a pas été mise dans le buffer d'images de référence du client. - l'état des images dans le buffer de paquets peut être : Envoyé : l'image a été envoyée ; Supprimé : l'image n'est pas envoyée ; Indéterminé : l'état de l'image n'est pas encore choisi.
Les états de la simulation des deux buffers évoluent de façon liée : les états qu'une image peut avoir dans la simulation sont : Indéterminé/Absent (VA), Envoyé/Présent (E/P), Envoyé/Invalide (E/I), Envoyé/Détruit (E/D), Supprimé/Absent (S/A), Supprimé/Invalide (S/I). Ces états, ainsi que les transitions entre états, sont représentés sur la figure 10. Cette figure fait référence à diverses étapes illustrées dans les organigrammes des figures 9b et 9c décrites ci-après.
Initialement, on ajoute toutes les images codées depuis la dernière image IDR. Ces images sont dans les états Indéterminé et Absent. Comme le montre la figure 9a, à l'étape 905, on calcule d'abord l'état du buffer d'images de référence du client sur la base des images envoyées de façon sûre. On utilise pour cela l'information fournie par l'ordonnanceur à l'étape 760 de la figure 7. A partir d'un état initial connu (par exemple, la dernière image IDR envoyée, qui a ainsi vidé le buffer d'images de référence du client), on simule d'abord le fonctionnement du buffer d'images de référence du client pour chaque image reçue et les contraintes qui en découlent.
On prend les images, non pas dans l'ordre d'envoi, mais dans l'ordre de décodage de la séquence vidéo. Pour chaque image envoyée (voir figure 9b) . - on passe l'état de l'image dans le buffer de paquet à Envoyé (étape 955) ; - on simule le fonctionnement du buffer d'images de référence du client : l'image reçue est ajoutée et mise à l'état Présent (étape 960) et on passe l'état des images déjà présentes, supprimées à cause d'une instruction de l'image reçue, à l'état Détruit (étape 965) ; - les images dépendantes d'une image détruite et qui sont après l'image envoyée sont mises à l'état Supprimé et Absent (étape 970). Si une image dépendante était déjà à l'état Envoyé/Présent, elle est mise dans l'état Envoyé/Invalide. Si elle était à l'état Envoyé/Détruit, elle ne change pas d'état ; - de façon récursive, on continue à propager l'état Supprimé/Absent pour toutes les images dépendantes d'une image à l'état Supprimé ou Invalide (étape 975). Comme à l'étape 970, si une image dépendante était déjà à l'état Envoyé/Présent, elle est mise à l'état Envoyé/Invalide. Si elle était à l'état Envoyé/Détruit, elle ne change pas d'état.
A l'issue de l'étape 905 de la figure 9a, on a donc l'état courant du buffer d'images de référence du client sur la base des images envoyées. Il convient ensuite (étape 910) de prendre en compte l'état créé par l'image qui est en cours d'envoi. En effet, lorsque le module de contrôle de débit 320 exécute son algorithme, une image a pu commencer à être envoyée. On peut décider d'arrêter cet envoi, mais le client recevra quand même les paquets déjà envoyés et donc exécutera les commandes associées de gestion du buffer d'images de référence. Pour l'image en cours d'envoi, on effectue les étapes de la figure 9b 10 sauf l'étape 955 : l'image reste dans l'état Indéterminé. On a ainsi obtenu l'état initial de la simulation. On simule ensuite un ou plusieurs scénarios d'images supprimées dans le buffer de paquets 325. A l'étape 915, on choisit une ou plusieurs images à supprimer. 15 Seules les images dont l'état est Indéterminé peuvent être choisies. On peut utiliser une heuristique, par exemple, prendre les images ayant les tailles les plus importantes (choix particulièrement intéressant s'il y a une baisse importante de bande passante ou une longue interruption, typiquement de l'ordre de plusieurs centaines de millisecondes), ou ne prendre que des images 20 n'ayant pas ou ayant peu d'images dépendantes. L'étape suivante de simulation 920 consiste à simuler les conséquences des choix. Pour chaque image qu'on a choisi de ne pas envoyer (voir figure 9c) : - on passe l'état de l'image dans le buffer de paquets à Supprimé 25 (étape 985). Si l'état est Présent, on le change en Invalide car il s'agit de l'image en cours de transmission : même si on arrête de l'envoyer, elle sera quand même présente dans le buffer d'images de référence du client mais incomplète ; - toutes les images dépendantes sont mises à l'état 30 Supprimé/Absent de façon récursive. Si une image dépendante était déjà à l'état Envoyé/Présent, elle est mise à l'état Envoyé/Invalide (étape 990).
On simule ensuite l'envoi des images restantes. On reprend toutes les images dans l'ordre de décodage de la séquence vidéo. Pour chaque image : - si 'état est Indéterminé, si sa taille est inférieure à la taille disponible, on ajoute sa taille à la quantité de données envoyée puis on simule son envoi selon la figure 9b ; si la taille de l'image est trop importante comparée à la bande passante disponible, l'image n'est pas envoyée, on simule sa suppression selon la figure 9c. - si l'état de l'image est Envoyé, on recalcule son impact en suivant l'algorithme de la figure 9b. En effet, lors la première simulation (étape 905), on ne connaissait pas encore toutes les images envoyées et donc on peut avoir sous-estimé le nombre d'images détruites à l'étape 965 ; - si l'image est déjà dans l'état Supprimé, elle est ignorée. On a ainsi calculé un scénario complet : toutes les images sont dans l'état Envoyé ou Supprimé. On peut ensuite (étape 925) évaluer la qualité de la vidéo résultante en tenant compte de la qualité des images, du nombre et du placement des images supprimées par rapport au contenu de la vidéo, de la quantité de mouvement de la vidéo et des changements de qualité dans les images successives. On peut par exemple calculer une valeur de la manière suivante : - on calcule une qualité moyenne pour la séquence : la moyenne des qualités des images à l'état Présent et Valide. Cela donne une première évaluation de la qualité ; - on passe ensuite en revue toutes les images depuis la plus ancienne dans le buffer de paquets : on peut estimer pour chaque image à l'état Supprimé/Absent si elle a un impact visuel fort ou faible en fonction des mouvements et des changements de séquence : une image dans une séquence à fort mouvement a un impact fort, une image en début ou fin de séquence ou dans une séquence à faible mouvement a un impact faible ; une image à l'état Envoyé/Invalide a un fort impact sur la qualité de la séquence : en effet, le décodeur risque d'avoir beaucoup de mal à corriger l'effet visuel ; enfin, un changement brutal de niveau de compression pour une image à l'état Envoyé/Présent a un impact visuel moyen. L'impact calculé pour chaque image permet de modifier la qualité calculée pour la séquence et d'obtenir une qualité pour le scénario.
On mémorise le scénario ainsi créé (étape 930). On peut ensuite explorer d'autres hypothèses (test 935) en reprenant l'étape 915 avec d'autres choix, ce qui permet de tester plusieurs heuristiques ou, si on dispose d'assez de temps, de simuler tous les scénarios possibles. Après avoir exploré toutes les hypothèses, on peut choisir le scénario de meilleure qualité (étape 940). Le scénario contient l'état du buffer d'images de référence et du buffer de paquets : les images à l'état Présent peuvent être utilisées dans le buffer d'images de référence du codeur, les autres sont à l'état Invalide ou Absent et ne doivent pas être utilisées comme référence, les images à l'état Envoyé qui sont encore dans le buffer de paquets ont une priorité haute, les autres ont une priorité basse car elles ne doivent pas être envoyées.

Claims (25)

  1. REVENDICATIONS1. Procédé de transmission d'une vidéo constituée de données organisées sous forme de paquets dans un réseau de communication, ledit 5 procédé comportant : une étape de codage d'images avec compensation de mouvement (310), consistant à comprimer les images de la vidéo et à créer des dépendances entre images comprimées, une étape d'ordonnancement des paquets (330), consistant à 10 envoyer les paquets sur le réseau suivant un ordre choisi et une étape de contrôle de débit de la vidéo (320), ledit procédé étant caractérisé en ce que l'étape de contrôle de débit (320) commande les étapes de codage d'image (310) et d'ordonnancement des paquets (330) en choisissant simultanément les dépendances entre images et 15 l'ordre d'envoi des paquets au moment de coder une nouvelle image.
  2. 2. Procédé selon la revendication 1, caractérisé en ce qu'on choisit les dépendances entre images et l'ordre d'envoi des paquets en fonction de la bande passante disponible du réseau, et/ou du nombre de paquets en attente d'envoi et du contenu de la vidéo. 20
  3. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comporte en outre une étape consistant à évaluer ladite bande passante disponible au moyen d'un mécanisme de contrôle de congestion du réseau (335).
  4. 4. Procédé selon la revendication 3, caractérisé en ce que le mécanisme de contrôle de congestion (335) est du type TFRC ("TCP Friendly 25 Rate Contre) ou AIMD ("Additive Increase/Multiple Decrease").
  5. 5. Procédé selon la revendication 2, 3 ou 4, caractérisé en ce qu'il comporte en outre une étape consistant à déterminer une qualité pour la vidéo en fonction dudit contenu, ladite qualité tenant compte des images non envoyées. 30
  6. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le choix des dépendances entre images consiste à définir un type d'image avec ou sans dépendance.
  7. 7. Procédé selon la revendication 6, caractérisé en ce que, lorsqu'on définit un type d'image avec dépendance, ledit choix des dépendances entre images consiste en outre à définir au moins une image de référence possible.
  8. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le choix de l'ordre d'envoi des paquets consiste à décider de supprimer au moins un paquet.
  9. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le choix de l'ordre d'envoi des paquets consiste à décider de retarder ou d'avancer l'envoi d'au moins un paquet.
  10. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on attribue à chaque paquet une certaine priorité et une certaine échéance au terme de laquelle l'envoi du paquet devient inutile et en ce qu'on envoie les paquets par priorités décroissantes et par échéances croissantes.
  11. 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la vidéo est codée suivant le format H.264.
  12. 12. Serveur de transmission d'une vidéo constituée de données organisées sous forme de paquets dans un réseau de communication, ledit serveur comportant : des moyens (310) de codage d'images avec compensation de mouvement, comprimant les images de la vidéo et créant des dépendances entre images comprimées, des moyens (330) d'ordonnancement des paquets, adaptés à envoyer les paquets sur le réseau suivant un ordre choisi et des moyens (320) de contrôle de débit de la vidéo, ledit serveur étant caractérisé en ce que les moyens (320) de contrôle de débit commandent les moyens (310) de codage d'image et les moyens (330) d'ordonnancement des paquets en choisissant simultanément les dépendances entre images et l'ordre d'envoi des paquets au moment de coder une nouvelle image.
  13. 13. Serveur selon la revendication 12, caractérisé en ce qu'il est adapté à choisir les dépendances entre images et l'ordre d'envoi des paquets en fonction de la bande passante disponible du réseau, et/ou du nombre de paquets en attente d'envoi et du contenu de la vidéo.
  14. 14. Serveur selon la revendication 13, caractérisé en ce qu'il comporte en outre des moyens adaptés à évaluer ladite bande passante disponible au moyen d'un mécanisme de contrôle de congestion du réseau (335).
  15. 15. Serveur selon la revendication 14, caractérisé en ce que le mécanisme de contrôle de congestion (335) est du type TFRC ("TCP Friendly Rate Contre) ou AIMD ("Additive Increase/Multiple Decrease").
  16. 16. Serveur selon la revendication 13, 14 ou 15, caractérisé en ce qu'il comporte en outre des moyens adaptés à déterminer une qualité pour la vidéo en fonction dudit contenu, ladite qualité tenant compte des images non envoyées.
  17. 17. Serveur selon l'une quelconque des revendications précédentes, 15 caractérisé en ce qu'il comporte en outre des moyens adaptés à définir un type d'image avec ou sans dépendance.
  18. 18. Serveur selon la revendication 17, caractérisé en ce que lesdits moyens adaptés à définir un type d'image avec dépendance sont adaptés à définir au moins une image de référence possible. 20
  19. 19. Serveur selon l'une quelconque des revendications 12 à 18, caractérisé en ce qu'il comporte en outre des moyens adaptés à décider de supprimer au moins un paquet.
  20. 20. Serveur selon l'une quelconque des revendications 12 à 19, caractérisé en ce qu'il comporte en outre des moyens adaptés à décider de 25 retarder ou d'avancer l'envoi d'au moins un paquet.
  21. 21. Serveur selon l'une quelconque des revendications 12 à 20, caractérisé en ce qu'il comporte en outre des moyens adaptés à attribuer à chaque paquet une certaine priorité et une certaine échéance au terme de laquelle l'envoi du paquet devient inutile et en ce qu'il est adapté à envoyer les 30 paquets par priorités décroissantes et par échéances croissantes.
  22. 22. Serveur selon l'une quelconque des revendications 12 à 21, caractérisé en ce que la vidéo est codée suivant le format H.264.
  23. 23. 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 serveur selon l'une quelconque des revendications 12 à 22.
  24. 24. 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 selon l'une quelconque des revendications 1 à 11.
  25. 25. 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 selon l'une quelconque des revendications 1 à 11, lorsque ce programme est chargé et exécuté par l'appareil programmable.
FR0854069A 2008-06-19 2008-06-19 Procede et dispositif de transmission de donnees Expired - Fee Related FR2932938B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0854069A FR2932938B1 (fr) 2008-06-19 2008-06-19 Procede et dispositif de transmission de donnees
US12/487,348 US8812724B2 (en) 2008-06-19 2009-06-18 Method and device for transmitting variable rate video data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0854069A FR2932938B1 (fr) 2008-06-19 2008-06-19 Procede et dispositif de transmission de donnees

Publications (2)

Publication Number Publication Date
FR2932938A1 true FR2932938A1 (fr) 2009-12-25
FR2932938B1 FR2932938B1 (fr) 2012-11-16

Family

ID=40457330

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0854069A Expired - Fee Related FR2932938B1 (fr) 2008-06-19 2008-06-19 Procede et dispositif de transmission de donnees

Country Status (2)

Country Link
US (1) US8812724B2 (fr)
FR (1) FR2932938B1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2920632A1 (fr) * 2007-08-31 2009-03-06 Canon Kk Procede et dispositif de decodage de sequences video avec masquage d'erreurs
JP5765920B2 (ja) * 2010-11-16 2015-08-19 キヤノン株式会社 送信装置および送信方法
US9525714B2 (en) * 2013-08-02 2016-12-20 Blackberry Limited Wireless transmission of real-time media
US9532043B2 (en) * 2013-08-02 2016-12-27 Blackberry Limited Wireless transmission of real-time media
DE102015101523A1 (de) * 2015-02-03 2016-08-04 CISC Semiconductor GmbH Verfahren zur Berechtigungsverwaltung in einer Anordnung mit mehreren Rechensystemen
WO2019192870A1 (fr) 2018-04-05 2019-10-10 Canon Kabushiki Kaisha Procédé et appareil pour encapsuler des images ou des séquences d'images avec des informations propriétaires dans un fichier
CN108848336A (zh) * 2018-06-01 2018-11-20 广州华工中云信息技术有限公司 利用移动通信网络及移动智能手机跟踪监视报警系统
CN111147798A (zh) * 2019-12-30 2020-05-12 视联动力信息技术股份有限公司 一种组会方法和装置
CN112422894B (zh) * 2020-10-14 2022-10-14 重庆恢恢信息技术有限公司 一种通过云平台海量数据进行工地视频图像处理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6141380A (en) * 1998-09-18 2000-10-31 Sarnoff Corporation Frame-level rate control for video compression
WO2004064373A2 (fr) * 2003-01-09 2004-07-29 The Regents Of The University Of California Procedes et dispositifs de codage video

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002334720B8 (en) * 2001-09-26 2006-08-10 Interact Devices, Inc. System and method for communicating media signals
KR100547139B1 (ko) * 2003-09-03 2006-01-26 학교법인 고황재단 ＩＥＴＦ ＱｏＳ 프로토콜을 이용한 ＭＰＥＧ 미디어데이터 전송 방법 및 장치
IL160921A (en) * 2004-03-18 2009-09-01 Veraz Networks Ltd Method and device for quality management in communication networks
EP1580914A1 (fr) * 2004-03-26 2005-09-28 STMicroelectronics S.r.l. Méthode et système pour contrôler l'opération d'un réseau
US7543073B2 (en) * 2004-12-10 2009-06-02 Microsoft Corporation System and process for performing an exponentially weighted moving average on streaming data to establish a moving average bit rate
US7965771B2 (en) * 2006-02-27 2011-06-21 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US20080201751A1 (en) * 2006-04-18 2008-08-21 Sherjil Ahmed Wireless Media Transmission Systems and Methods
FR2902266B1 (fr) * 2006-06-13 2008-10-24 Canon Kk Procede et dispositif de repartition de la bande passante de communication
FR2908585B1 (fr) * 2006-11-15 2008-12-26 Canon Kk Procede et dispositif de transmission de donnees video.
US8335266B2 (en) * 2007-06-29 2012-12-18 Cisco Technology, Inc. Expedited splicing of video streams
US8230100B2 (en) * 2007-07-26 2012-07-24 Realnetworks, Inc. Variable fidelity media provision system and method
CN101686383B (zh) * 2008-09-23 2013-05-01 Utc消防和保安美国有限公司 通过网络传输媒体的方法及系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6141380A (en) * 1998-09-18 2000-10-31 Sarnoff Corporation Frame-level rate control for video compression
WO2004064373A2 (fr) * 2003-01-09 2004-07-29 The Regents Of The University Of California Procedes et dispositifs de codage video

Also Published As

Publication number Publication date
US20090319682A1 (en) 2009-12-24
US8812724B2 (en) 2014-08-19
FR2932938B1 (fr) 2012-11-16

Similar Documents

Publication Publication Date Title
FR2932938A1 (fr) Procede et dispositif de transmission de donnees
US10972772B2 (en) Variable bit video streams for adaptive streaming
KR101500892B1 (ko) 적응 스트리밍을 위한 가변 비트 비디오 스트림들
US20160142510A1 (en) Cache-aware content-based rate adaptation mechanism for adaptive video streaming
FR2916600A1 (fr) Procede et dispositif de transmission de donnees
Yahia et al. HTTP/2-based frame discarding for low-latency adaptive video streaming
FR2897741A1 (fr) Procede et dispositif de generation de donnees representatives d'un degre d'importance de blocs de donnees et procede et dispositif de transmission d'une sequence video encodee
KR20150042191A (ko) 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들
AU2012207151A1 (en) Variable bit video streams for adaptive streaming
FR2908585A1 (fr) Procede et dispositif de transmission de donnees video.
FR2935862A1 (fr) Procede de prediction du taux d'erreurs de transmission dans un reseau de communication et serveur mettant en oeuvre un tel procede
FR2975555A1 (fr) Methode d'adaptation dynamique du debit de reception et recepteur associe
FR2946820A1 (fr) Procede de transmission de donnees et dispositif associe.
EP3780632A1 (fr) Systeme de distribution d'un contenu audiovisuel
US11622135B2 (en) Bandwidth allocation for low latency content and buffered content
FR2987213A1 (fr) Systeme video pour representer des donnees d'image et son procede d'application
EP2594069B1 (fr) Procédé de diffusion de séquences de données vidéo par un serveur vers un terminal client
US20230199267A1 (en) Method and apparatus for processing adaptive multi-view streaming
FR2926177A1 (fr) Procede et disositif de transmission de donnees avec partage specifique des ressources de debit d'un reseau.
CN114902685B (zh) 用于发送和接收视频的方法和装置
FR2917919A1 (fr) Procede et dispositif de transmission d'images.
US20230156280A1 (en) Systems, Devices, and Methods for Selecting TV User Interface Transitions
Ansari Advancing Temporal and Quality Adaptation in Video Streaming with AV1
EP3843409A1 (fr) Procede d'allocation pour liaison bas-debit
James Improving Quality of Experience (QoE) of Dynamic Adaptive Streaming (DAS) Systems.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140228