FR2905221A1 - Procede et systemes pour optimiser la transmission d'un flux de donnees. - Google Patents

Procede et systemes pour optimiser la transmission d'un flux de donnees. Download PDF

Info

Publication number
FR2905221A1
FR2905221A1 FR0653479A FR0653479A FR2905221A1 FR 2905221 A1 FR2905221 A1 FR 2905221A1 FR 0653479 A FR0653479 A FR 0653479A FR 0653479 A FR0653479 A FR 0653479A FR 2905221 A1 FR2905221 A1 FR 2905221A1
Authority
FR
France
Prior art keywords
multimedia content
client
rate
encoding
encoding rate
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
FR0653479A
Other languages
English (en)
Other versions
FR2905221B1 (fr
Inventor
Eric Nassor
Barillon Pierre Gerbelot
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 FR0653479A priority Critical patent/FR2905221B1/fr
Publication of FR2905221A1 publication Critical patent/FR2905221A1/fr
Application granted granted Critical
Publication of FR2905221B1 publication Critical patent/FR2905221B1/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 or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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 or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display 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/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/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/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/6587—Control parameters, e.g. trick play commands, viewpoint selection

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Un procédé pour optimiser le temps de démarrage de présentation d'un contenu multimédia transmis sous forme de flux multimédia d'un serveur vers un client est décrit. Après la réception d'une requête d'un client pour recevoir le flux multimédia (750), cette requête comprenant au moins un paramètre lié à la qualité de présentation du contenu multimédia, le serveur détermine un premier débit d'encodage selon le paramètre de qualité (760), le premier débit d'encodage étant inférieur au débit de transmission du flux multimédia du serveur vers le client. Une première partie du contenu multimédia est encodée selon le premier débit d'encodage et transmise au client. Ensuite, un second débit d'encodage, sensiblement égal au débit de transmission du flux multimédia du serveur vers le client, est déterminé (780). Une seconde partie du contenu multimédia est encodée selon le second débit d'encodage et transmise au client. Le procédé permet la transmission d'un contenu multimédia à plusieurs clients en mode point à multipoint, même si les clients ne transmettent pas simultanément leur requête.

Description

La présente invention concerne la transmission de données entre une source
et au moins un destinataire connecté à un réseau et plus particulièrement un procédé et des systèmes pour optimiser le démarrage de la présentation d'un contenu multimédia reçu sous forme d'un flux de données. La transmission de contenu multimédia d'une source vers un ou plusieurs destinataires, également connue sous le nom de media streaming en anglais, connaît un développement croissant et commence à concurrencer la diffusion audiovisuelle classique. La transmission de contenu multimédia tel qu'une vidéo n'est pas comparable à la transmission d'un fichier car, contrairement à un contenu multimédia, il est généralement nécessaire de transférer la totalité d'un fichier avant de pouvoir l'utiliser. Afin d'éviter une longue attente pour l'utilisateur, l'approche utilisée pour la transmission d'une vidéo, aussi appelée video streaming, est différente. La vidéo est encodée et découpée en une succession de paquets qui sont transmis en tenant compte de l'ordre dans lequel ils sont générés. Le débit d'encodage est égal au débit de présentation. Le débit de transmission peut être supérieur ou inférieur au débit d'encodage. Le contenu multimédia est encodé à un rythme d'encodage et transmis au rythme de transmission. Il est décodé au rythme de présentation. Le rythme d'affichage est typiquement de 25 ou 30 images par secondes. Pour que la transmission en temps réel se déroule correctement les rythmes d'encodage et de transmission doivent en moyenne être supérieurs ou égaux au rythme réel, c'est-à-dire au rythme de présentation du contenu multimédia. Le débit d'encodage est lié au taux de compression des données à encoder : plus le débit d'encodage est faible, plus le taux de compression est élevé. Pour que la transmission se déroule en temps réel le récepteur décode les paquets au fur et à mesure de leur réception afin d'afficher le 2905221 2 contenu multimédia tout en continuant à recevoir les paquets suivants. En conséquence, lorsque le système est stable, les débits d'encodage, de transmission et de présentation sont sensiblement égaux. Cependant, il peut y avoir des phases transitoires pour lesquelles les débits sont différents. 5 Cette approche doit faire face à des problèmes tels que le débit limité et variable du réseau, la variation du délai de transmission ou la perte ou la corruption de données liée à l'utilisation d'un réseau sans garantie de qualité de service. Pour supporter le débit limité du réseau, le débit de transmission doit 10 être inférieur au débit disponible du réseau. Le débit d'encodage doit donc lui aussi être en moyenne inférieur ou égal au débit du réseau. Cela peut se faire par une adaptation dynamique du débit d'encodage au débit réseau disponible. Une solution couramment utilisée pour faire face aux problèmes de fiabilité dans le réseau consiste en l'utilisation d'une mémoire tampon placée 15 dans le récepteur. Le remplissage de cette mémoire tampon doit atteindre un niveau prédéterminé avant que le contenu multimédia ne soit effectivement présenté à l'utilisateur. Cette mémoire tampon ajoute un délai entre la réception effective d'un paquet et le moment où les données contenues dans ce paquet sont présentées à l'utilisateur. La mémoire tampon permet de compenser les 20 variations de délai de transmission des paquets, les pertes de données introduites par le réseau entre la source et le récepteur qui exige une demande de retransmission de données et/ou les variations brutales de débit réseau. Par nature, cette mémoire tampon introduit un délai de démarrage, aussi appelé start-up time, défini comme le temps entre le moment où l'utilisateur effectue sa 25 requête pour obtenir un contenu multimédia et le moment où le contenu multimédia lui est effectivement présenté. Ce délai, qui dégrade l'interaction du système avec l'utilisateur, permet de garantir à l'utilisateur la qualité de présentation du contenu multimédia demandé. La mémoire tampon du client se rempli (overbuffering) si le débit de transmission est supérieur au débit 30 d'encodage et elle se vide si le débit de transmission est inférieur au débit d'encodage. 2905221 3 Le brevet US 6,792,449 décrit une méthode pour réaliser un démarrage rapide dans le cadre de diffusion de contenu multimédia pré-encodé. Le client émet une requête vers un serveur qui identifie le contenu multimédia demandé et qui fournit la bande passante du lien reliant le client et 5 le serveur. Le serveur transmet alors le contenu multimédia demandé au client. Dans une première phase d'initialisation, le contenu multimédia est transmis à un débit supérieur au débit d'encodage du contenu multimédia pour remplir rapidement la mémoire tampon du client, afin d'obtenir un démarrage plus rapide de la présentation du contenu multimédia au client. Dans une seconde 10 phase, le contenu multimédia est transmis à la vitesse réelle, c'est-à-dire que le débit de transmission est équivalent au débit d'encodage du contenu multimédia. Le système utilise ainsi deux débits de transmission distincts. La demande de brevet WO 02/45372 présente une méthode pour réduire le délai de démarrage d'une application de streaming vidéo et une 15 méthode pour contrôler le débit de transmission du flux pour s'adapter à la congestion dans le réseau. Le serveur possède deux représentations de la vidéo avec deux débits d'encodage différents. Dans la phase initiale, la représentation de la vidéo avec le bas débit d'encodage est envoyée avec un débit de transmission supérieur au débit d'encodage. Le client commence à 20 présenter la vidéo sans attendre que la mémoire tampon de données ait atteint un seuil prédéterminé. Cependant, le niveau de remplissage de la mémoire tampon augmente car la vitesse de décodage de la vidéo est inférieure au taux de réception des données. Lorsqu'un premier seuil de remplissage prédéterminé est atteint, le client le communique au serveur qui envoie alors la 25 vidéo encodée avec le taux d'encodage supérieur et adapte le taux de transmission afin qu'il soit égal au taux d'encodage. La qualité de la vidéo augmente et le niveau de remplissage reste constant. Si le niveau de la mémoire tampon diminue (congestion dans le réseau) et atteint un second seuil de remplissage, le serveur transmet alors la vidéo encodée avec le taux 30 d'encodage inférieur pour réduire le débit de transmission requis. Bien que des solutions existent pour diminuer le temps de démarrage d'une présentation multimédia, le temps de démarrage est un 2905221 4 problème important de l'accès au contenu multimédia et il existe un besoin pour l'optimiser. L'invention permet de résoudre au moins un des problèmes exposés précédemment. 5 L'invention a ainsi pour objet un procédé pour transmettre un contenu multimédia sous forme de flux multimédia d'un serveur vers un client, ce procédé comprenant les étapes suivantes : . réception d'une requête dudit client pour transmettre ledit flux multimédia, cette requête comprenant au moins un paramètre lié à la qualité de 10 présentation dudit contenu multimédia ; . détermination d'au moins un premier débit d'encodage selon ledit au moins un paramètre, ledit au moins un premier débit d'encodage étant inférieur au débit de transmission du flux multimédia dudit serveur vers ledit client ; 15 . encodage d'une première partie dudit contenu multimédia selon ledit au moins un premier débit d'encodage et transmission de ladite première partie encodée dudit contenu multimédia audit client ; . détermination d'un second débit d'encodage supérieur audit au moins un premier débit ; et 20 . encodage d'une seconde partie dudit contenu multimédia selon ledit second débit d'encodage et transmission de ladite seconde partie encodée dudit contenu multimédia audit client. Le procédé selon l'invention permet d'optimiser le temps de démarrage de la présentation d'un contenu multimédia en diminuant le débit 25 d'encodage durant la phase de démarrage selon la qualité requise de présentation du contenu multimédia requise par le client. Selon un mode particulier de réalisation, le débit de transmission de la première partie du contenu multimédia au client est augmenté pour être supérieur au débit de transmission de la seconde partie du contenu multimédia 30 au client afin de réduire le temps de démarrage. 2905221 5 Toujours selon un mode particulier de réalisation, le second débit d'encodage est sensiblement égal au débit de transmission du flux multimédia du serveur vers ledit client pour optimiser le transfert du contenu multimédia. Toujours selon un mode particulier de réalisation, le premier débit 5 d'encodage est dynamiquement réévalué au cours de la transmission de la première partie du contenu multimédia pour optimiser le temps de démarrage selon la qualité de présentation requise. De façon préférentielle, la réévaluation dynamique du premier débit d'encodage peut être réalisée par un mécanisme de régulation avec boucle de rétroaction. 10 Selon un mode particulier de réalisation, le procédé selon l'invention comprend en outre une étape de transmission d'une commande de démarrage de la présentation de la première partie encodée du contenu multimédia de telle sorte que la présentation du contenu multimédia commence dès que les critères de qualité sont atteints. 15 Toujours selon un mode particulier de réalisation, les critères de qualité de la présentation du contenu multimédia sont liés à la mise en oeuvre de mécanismes de correction d'erreurs avec, en particulier, l'indication d'un temps maximum de coupure de transmission ou à la qualité visuelle de présentation du contenu multimédia. 20 Selon un autre mode particulier de réalisation, le procédé selon l'invention comprend en outre les étapes suivantes, permettant la transmission d'un contenu multimédia à plusieurs clients en mode point à multipoint, même si les clients ne transmettent pas simultanément leur requête : . détermination d'un troisième débit d'encodage différent du premier 25 débit d'encodage ; . encodage de la première partie du contenu multimédia selon le troisième débit d'encodage et transmission de la première partie du contenu multimédia encodée selon le troisième débit d'encodage à un second client différent du client, appelé premier client ; et, 30 . transmission de la seconde partie encodée du contenu multimédia aux premier et second clients. 2905221 6 Toujours selon un mode particulier de réalisation, les étapes d'encodage d'une partie du contenu multimédia consistent en des étapes de transcodage pour transmettre un contenu multimédia pré-encodé. L'invention a également pour objet un procédé pour recevoir d'un 5 serveur un contenu multimédia sous forme de flux multimédia, caractérisé en que ce procédé comprend les étapes suivantes : . émission d'une requête au serveur pour recevoir le flux multimédia, cette requête comprenant au moins un paramètre lié à la qualité de présentation du contenu multimédia ; 10 . réception d'une première partie du contenu multimédia, la première partie du contenu multimédia étant encodée avec un premier débit d'encodage ; . démarrage de la présentation de la première partie du contenu multimédia ; et, 15 . réception d'une seconde partie du contenu multimédia, la seconde partie du contenu multimédia étant encodée avec un second débit d'encodage. De façon préférentielle, le procédé comprend en outre une étape de réception d'une commande de démarrage de la présentation de la première partie dudit contenu multimédia. 20 L'invention a également pour objet un dispositif pour optimiser le temps de démarrage de présentation d'un contenu multimédia transmis sous forme de flux multimédia d'un serveur vers un client, le dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. 25 L'invention a également pour objet un programme d'ordinateur pour optimiser le temps de démarrage de présentation d'un contenu multimédia transmis sous forme de flux multimédia d'un serveur vers un client, le programme d'ordinateur comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. 30 L'invention a également pour objet un serveur pour optimiser le temps de démarrage de présentation d'un contenu multimédia transmis sous forme de flux multimédia d'un serveur vers un client, le serveur comprenant des 2905221 7 moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 5 au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un réseau de terminaux dans lequel la présente invention peut être mise en oeuvre ; la figure 2 illustre un dispositif adapté à l'implémentation de l'invention ; 10 - les figures 3 et 4 présentent schématiquement certaines étapes pour mettre en oeuvre l'invention afin de réduire le temps de démarrage de la présentation d'un contenu multimédia transmis par un réseau, d'un serveur à un client ; - la figure 5 montre, dans le domaine temporel, la diffusion d'un 15 contenu multimédia entre un serveur et un client permettant de réduire le temps de démarrage de la présentation d'un contenu multimédia ; - la figure 6, comprenant les figures 6a, 6b, 6c, 6d et 6e, illustre les avantages de l'invention et son influence sur le remplissage de la mémoire tampon, la qualité du contenu multimédia présenté et le débit d'encodage en 20 fonction du temps ; - la figure 7, comprenant les figures 7a et 7b, présente un exemple de l'algorithme pour mettre en oeuvre l'invention afin d'optimiser la réduction du temps de démarrage et la qualité du contenu multimédia présenté ; - la figure 8, comprenant les figures 8a, 8b et 8c, illustre un 25 dispositif permettant à un serveur de diffuser le même flux de données à plusieurs clients ; et - la figure 9 est une illustration temporelle d'un dispositif permettant à un serveur de diffuser le même flux de données à plusieurs clients. Selon l'invention, la mémoire tampon utilisée par le client pour 30 recevoir le flux du contenu multimédia est remplie rapidement lors de la phase de démarrage en transmettant le contenu multimédia avec un débit de transmission supérieur au débit d'encodage du contenu multimédia. Cela 2905221 8 implique, dans le cas d'un encodage en temps réel, que le serveur ait en mémoire au moins une partie des données encodées à transmettre. De plus, il est nécessaire qu'une différence existe entre le débit disponible sur le lien pour transmettre le flux de contenu multimédia et le débit d'encodage du contenu 5 multimédia, le débit disponible de transmission du contenu multimédia étant supérieur au débit d'encodage. Plus cette différence est importante, plus le remplissage de la mémoire tampon du client peut être accéléré pour un délai de démarrage fixe. Si cette différence est nulle, le remplissage de la mémoire tampon ne peut pas être accéléré. 10 Pour accélérer le remplissage de la mémoire tampon et ainsi diminuer le temps de démarrage de la présentation du contenu multimédia, le débit d'encodage de ce contenu multimédia est donc temporairement réduit afin d'augmenter la différence entre le débit de transmission disponible et ce débit d'encodage. La diminution du débit d'encodage peut être réalisé de plusieurs 15 façons, par exemple par la technique de transcodage, en utilisant plusieurs versions pré-encodées du contenu multimédia ou en utilisant une technique de compression variable , ou scalable compression en anglais. La diminution du débit d'encodage dégrade la qualité du contenu multimédia reconstitué par le client car il existe une relation directe entre le débit d'encodage et la distorsion 20 entraînée par ce codage. Selon l'invention, le serveur encode le contenu multimédia à un débit qui est, durant la phase de démarrage, contrôlé par la qualité du contenu multimédia décodé par le client, afin de réduire le temps de démarrage tout en maintenant un niveau requis de qualité de présentation du contenu multimédia. 25 La solution s'applique également lorsqu'un client émet une requête pour obtenir un contenu multimédia qui est en cours de diffusion à un ensemble d'utilisateurs, par exemple par l'intermédiaire d'un groupe multicast. Dans ce cas, il n'est pas possible d'augmenter temporairement le débit de transmission du flux commun ni de réduire le débit d'encodage du contenu multimédia pour 30 ne pas en perturber la réception par les autres clients. Afin que le nouveau client bénéficie de ce mécanisme de réduction du temps de démarrage, une communication point à point est établie entre le serveur et le nouveau client. 2905221 9 Lorsque la mémoire tampon du nouveau client a atteint un seuil optimum, le nouveau client peut rejoindre le flux commun via un mécanisme de synchronisation et couper la communication point à point. Dans un souci de clarté, la description suivante est principalement 5 orientée sur les contenus multimédia de type vidéo cependant, il doit être compris que l'invention peut être mise en oeuvre pour tous les contenus multimédia, et plus généralement pour toutes les données dont le transfert est tel qu'il permet la présentation des données reçues avant la réception de la totalité des données. 10 La figure 1 représente de façon schématique un réseau distribué d'échanges de données. Un tel réseau (RD) comporte un ensemble de terminaux (TE1, TE2, TE3 et TE4), chaque terminal étant relié au réseau et ayant des moyens de communication utilisant, par exemple, un mécanisme de requêtes (REQ) et de réponses (RES). Le réseau peut être par exemple un 15 réseau sans fil tel que WiFi 802.11g, un réseau Ethernet, ou Internet. Chaque terminal peut être, par exemple, un dispositif tel que décrit en référence à la figure 2, et pouvant comporter, en particulier: une mémoire de stockage volatile (cache), un serveur de fichiers et une interface homme-machine permettant la communication des requêtes de l'utilisateur. Les 20 terminaux peuvent communiquer directement par l'intermédiaire du réseau global. Chaque terminal peut représenter indifféremment un client ou un serveur. Alternativement, les clients et les serveurs ont des caractéristiques différentes. La figure 2 illustre un exemple d'appareil 200 mettant en oeuvre 25 l'invention, tel qu'un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable, un caméscope numérique, un appareil photo numérique, une caméra de vidéo surveillance ou webcam, un lecteur DVD, ou un serveur multimédia. Si cet appareil n'intègre pas directement un capteur numérique d'images, il peut être optionnellement connecté à un ou plusieurs 30 périphériques tels que, par exemple, une caméra numérique 201, un convertisseur analogique/numérique ou tout autre moyen de capture de vidéo, reliée à une carte graphique et fournissant à l'appareil des données multimédia. 2905221 10 De préférence, l'appareil 200 comporte un bus de communication 202 auquel sont reliés : . une unité centrale de traitement 203 telle qu'un microprocesseur ; • une mémoire morte 204 ou Read Only Memory (ROM), pouvant 5 comporter un ou plusieurs programmes "Prog", "Prog1" et "Prog2" ; . une mémoire vive 206 ou Random Access Memrory (RAM), comportant des registres adaptés à mémoriser des variables et des paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, . une interface de communication 218 reliée à un réseau de 10 communication distribué 220, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données. L'appareil 200 peut disposer optionnellement de l'un, de plusieurs ou de tous les dispositifs suivants : . écran 208 permettant de visualiser des données et/ou de servir 15 d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 210 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 211 ou un crayon optique, ou un écran tactile ou une télécommande ; . carte d'entrée/sortie (non représentée) reliée à un microphone 20 222 ; . disque dur 212 pouvant comporter des programmes et/ou des données, notamment des données traitées ou à traiter selon l'invention ; . lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention ; 25 . un lecteur de cartes mémoires adapté à y lire ou à y écrire des données, notamment des données traitées ou à traiter selon l'invention ; Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 200 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité 30 centrale est susceptible de communiquer des instructions à tout élément de l'appareil 200 directement ou par l'intermédiaire d'un autre élément de l'appareil 200. 2905221 11 Le code exécutable du ou des programme(s) permettant à l'appareil 200 de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou en mémoire morte 204. Selon une variante, la disquette 216, peut contenir des données ainsi 5 que le code exécutable des programmes précités qui, une fois lu par l'appareil 200, peuvent être stockés dans le disque dur 212. Alternativement, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 220, via l'interface 218, pour être stocké de façon identique à celle décrite précédemment. 10 Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes 15 dont l'exécution permet la mise en oeuvre du procédé selon l'invention. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage de l'appareil 200 avant d'être exécutés. L'unité centrale 203 contrôle l'exécution des instructions ou portions 20 de code logiciel du ou des programme(s) selon l'invention, instructions qui sont stockées dans le disque dur 212, dans la mémoire morte 204 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programme(s) stockés dans une mémoire non volatile, par exemple le disque dur 212 ou la mémoire morte 204, sont transférés dans la mémoire vive 206 25 (RAM) qui contient alors le code exécutable du ou des programme(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Il convient de noter que l'appareil comportant le dispositif selon l'invention peut également être un appareil programmé. Les instructions du ou 30 des programme(s) mettant en oeuvre l'invention peuvent, par exemple, être implémentées dans un circuit intégré programmable ou spécifique (Application-Specific Integrated Circuit, ASIC). 2905221 12 La figure 3 représente schématiquement une séquence d'images compressées selon un format de compression vidéo tel que H.264 ou MPEG-4. Il s'agit de formats connus, basés sur l'application de la transformation en cosinus discrète (Discrete Cosine Transform, DCT) par blocs de la séquence et 5 sur la compensation de mouvement. Généralement, une image I (appelée également image 'intra', décodable indépendamment) est suivie d'une séquence d'images P (appelées aussi images `inter', codées en différences par rapport à l'image I ou P précédente) et B (codées par rapport à l'image I précédente et aux images P 10 précédentes et suivantes). Cette séquence composée d'une image I et plusieurs images P ou B s'appelle un groupe d'images (Group Of Picture ou GOP). La taille des images I, P et B est très variable. Généralement l'image I est moins compressée car elle n'utilise pas de compensation de mouvement, 15 les images P sont mieux compressées et les images B sont les plus petites. La figure 3 illustre la taille de plusieurs images I, P et B de deux groupes d'images, M représentant la bande passante moyenne. Le calcul du débit d'une vidéo doit être calculé en moyenne sur une séquence et non pas image par image. Plusieurs paramètres peuvent être utilisés pour modifier le taux de 20 compression d'une vidéo : . pas de quantification pour les blocs intra et les blocs inter ; . nombre d'images affiché par seconde ; certaines images peuvent être supprimées dans la vidéo, ce qui correspond à un changement de fréquence d'affichage, la structure du GOP peut ainsi être modifiée ; et 25 . résolution des images (par exemple, division par deux de la taille des images (dans les deux directions), pour passer du format 704x576 au format 352x288). Le taux de compression obtenu pour un ensemble de paramètres n'est pas fixe car le résultat de la compression dépend du type d'image, de 30 vidéo et du contenu de la scène : un film avec une scène statique ou un petit objet en mouvement régulier en translation est fortement compressé alors que, par exemple, un film d'action génère une grande quantité de données. Le taux 2905221 13 de compression est lié à la quantité d'informations non redondantes dans la séquence d'images à compresser. Les techniques de compression présentées peuvent être mise en oeuvre lors d'un encodage ou d'un transcodage d'une vidéo. 5 Dans le cas d'un encodage, un capteur numérique génère des images qui sont ensuite encodées. En début de GOP une image I est générée, puis les images suivantes sont compressées en P (ou B suivant la structure du GOP). Pour obtenir un débit constant, le résultat de la compression est pris en compte et les paramètres de compression sont adaptés dynamiquement à 10 chaque image (ou à chaque macro bloc) pour atteindre le débit moyen fixé. Dans le cas d'un transcodage, la vidéo a été préalablement encodée mais le taux de compression doit être modifié. La technique la plus simple, mais peu efficace, consiste à décoder la vidéo puis à la compresser avec un taux de compression différent. Une autre technique, plus efficace, consiste à décoder 15 partiellement la vidéo et à la re-quantifier pour augmenter le taux de compression tout en réutilisant les vecteurs de mouvements sans les modifier. Comme dans le cas du transcodage, les nouveaux paramètres de compression sont dynamiquement modifiés à chaque macro bloc en fonction des compressions obtenues précédemment pour atteindre le débit moyen fixé. 20 D'autres techniques de compression et d'adaptation de bande passante peuvent être utilisées. Par exemple, certaines méthodes permettent d'avoir un encodage à plusieurs niveaux (scalable encoding). La vidéo est alors composée de plusieurs couches, chaque couche ajoutant des informations supplémentaires et augmentant la qualité, ce qui augmente le débit. 25 L'adaptation du débit consiste alors à sélectionner le nombre de couches désirées. Bien que l'invention soit adaptée à utiliser cette technique d'encodage, celle-ci est peu utilisé en raison de temps de calcul nécessaire. La qualité d'une vidéo compressée peut se mesurer de plusieurs façons, la façon la plus classique étant le calcul du rapport signal sur bruit, 30 Peak Signal to Noise Ratio (PSNR). Pour comparer une image compressée puis décompressée par rapport à l'image d'origine, l'erreur moyenne, Mean Square Error (MSE), est 2905221 14calculée sur une composante couleur de l'image (par exemple, la luminance notée X(i,j)) selon la formule, 1 width height MSE _ 1 1 (X(j,j)_X(j,j) width x height (1) où X est la valeur décompressée de la même composante pour le 5 même point sur l'image d'origine, le rapport signal sur bruit PSNR étant ensuite calculé selon la formule PSNR = 2OLog10 255 MSE (2) Cette métrique permet d'obtenir facilement une mesure objective de la distorsion d'une image. Cette mesure peut ensuite être appliquée à une 10 séquence vidéo de N images en calculant en calculant la moyenne, N PSNR =1 E PSNRi N iù1 (3) et la variance, 6PSNR =1 (PSNR i2 ù PSNR N i-1 (4) Si certaines images sont supprimées par la compression, il est 15 admis que l'image précédente reste affichée. Le PSNR de l'image compressée précédente est alors calculé par rapport à cette image. Ces deux valeurs permettent d'obtenir une évaluation de la qualité d'une vidéo : la moyenne du rapport signal sur bruit PSNR donne une indication sur la qualité visuelle moyenne des images tandis que la variance permet de 20 savoir si la qualité des images est très variable dans la vidéo. Ce dernier paramètre est important car de grandes variations de qualité des images donnent une vidéo désagréable à regarder. Une telle vidéo est donc de plus faible qualité qu'une vidéo ayant une faible variance et un rapport signal sur bruit PSNR moyen moins bon. D'autres méthodes pourraient être utilisées pour 25 évaluer la qualité visuelle d'une vidéo sans que cela change les principes de l'invention. ) 2905221 15 La figure 4 illustre certaines des étapes pour mettre en oeuvre l'invention afin de réduire le temps de démarrage de la présentation d'un contenu multimédia transmis par un réseau (400) d'un serveur (405) à un client (410). Une première étape consiste pour le client 410 à transmettre une requête 5 auprès du serveur 405 pour initier la transmission d'un contenu multimédia en utilisant, par exemple, le protocole Real Time Streaming Protocol (RTSP). Cette requête, émise par le module de contrôle du client (415), comprend par exemple les paramètres de niveaux de remplissage de la mémoire tampon ainsi que les niveaux requis pour la qualité des données présentées. 10 Dans une deuxième étape, le serveur 405 obtient le contenu multimédia et adapte son débit d'encodage. Pour une séquence vidéo, le serveur 405 peut l'obtenir en utilisant un capteur (420), en l'encodant avec un encodeur (425) pouvant compresser la vidéo et ainsi adapter la bande passante requise. Alternativement, le serveur 405 peut accéder une séquence vidéo sous 15 forme compressée sur une mémoire de stockage telle qu'un disque dur (430). Dans ce second cas un module transcodeur (435) doit être utilisé pour modifier l'encodage et adapter la bande passante. L'encodeur 425 ou le transcodeur 435 adaptent le débit de la vidéo suivant la méthode décrite dans la suite de la description, en particulier en 20 référence à la figure 7. L'encodeur 425 ou le transcodeur 435 est contrôlé par un module de décision (440) et un module de contrôle du débit (445) qui détermine les paramètres d'encodage. L'algorithme utilisé par ce module est décrit par référence à la figure 7. Dans une troisième étape, la séquence vidéo compressée est 25 transmise au module de transmission (450) du serveur 405, par exemple un module Real-Time Transport Protocol (RTP), qui crée des paquets de données et les envoie sur le réseau en utilisant les protocoles RTP, User Datagram Protocol et Internet Protocol (UDP/IP). Chaque paquet de données est numéroté ce qui permet ensuite au client de reconstruire le flux vidéo. 30 Dans une quatrième étape, le module RTP (455) du client 410 reçoit les paquets envoyés par le serveur. En utilisant les entêtes RTP, les paquets sont rassemblés pour recréer le flux vidéo encodé envoyé par le serveur 405. 2905221 16 Divers mécanismes de correction d'erreur peuvent être mis en oeuvre, par exemple les retransmissions de données, Automatic Repeat reQuest (ARQ), ou les codes correcteurs, Forward Error Correction (FEC). Le mécanisme ARQ est le suivant : lorsque le client détecte qu'un paquet est manquant (en utilisant les 5 numéros de séquence RTP) il envoie un message du type Negative ACKnowlege (NACK) au serveur pour indiquer la perte d'un paquet. Le serveur peut alors renvoyer le paquet perdu. Le mécanisme de correction d'erreur FEC consiste à ajouter des données redondantes dans les paquets envoyés (par exemple en utilisant des codes de Reed Salomon) qui permettent au client en 10 utilisant k paquets reçus de recréer n paquets d'origine (même si n-k paquets ont été perdus ou corrompus). Malgré l'intérêt de ces deux types de mécanismes, un inconvénient important est le temps de latence introduit qui peut être important : pour la retransmission de type ARQ il faut ajouter le temps de communication entre le client et le serveur, pour les corrections FEC il faut 15 ajouter le temps de réception de plusieurs paquets. Ils ne peuvent être mis en oeuvre que si un niveau suffisant de la mémoire tampon du client est atteint. Un autre mécanisme de correction d'erreur est le masquage d'erreur. Le client peut utiliser les images précédentes et suivantes pour essayer de masquer les erreurs liées au réseau qui se sont produites. Comme les autres mécanismes, 20 le masquage d'erreur peut ajouter une latence. Il convient de noter également que la mémoire tampon elle-même est un mécanisme permettant de supporter des erreurs réseau. En effet sur un réseau, particulièrement un réseau sans fil, il peut y avoir des interruptions totales de réseau de plusieurs centaines de millisecondes, voir même de plusieurs secondes. Dans ce cas seule une 25 mémoire tampon du client de taille suffisante permet de continuer à présenter le contenu multimédia sans interruption perceptible. Dès que le réseau est rétabli, les messages ARQ peuvent être utilisés pour permettre au serveur de renvoyer les données manquantes. La mémoire tampon sert aussi à supporter les fluctuations sur les temps de transmission du réseau (jitter) qui peuvent être de 30 plusieurs centaines de millisecondes. 2905221 17 Après avoir été reconstitué et stocké dans la mémoire tampon (460), le flux vidéo est transmis à un décodeur (465) pour décompresser la vidéo qui peut alors être affichée sur un écran (470). Les architectures du serveur 405 et du client 410 sont des exemples 5 d'architecture possible pour l'invention. D'autres variantes sont possibles. La figure 5 illustre, dans le domaine temporel, la diffusion d'un contenu multimédia entre un serveur et un client permettant de réduire le temps de démarrage de la présentation du contenu multimédia. Cette figure illustre un fonctionnement simple avec un seul changement de débit. 10 Un contenu multimédia est constitué d'une succession de fragments qui sont liés temporellement les uns aux autres, c'est à dire que chaque fragment possède une échéance d'utilisation. En cas de non respect de l'échéance d'un fragment, celui-ci devient inutile pour la reconstruction du contenu multimédia. Pour être transférés, les fragments sont transformés en 15 paquets comprenant, entre autre, l'adresse du client vers lequel ils doivent être acheminés. La mise en forme des paquets n'entrant pas directement dans le cadre de l'invention et étant bien connue du spécialiste de transmission de données n'est pas détaillée ici. La transmission en temps réel signifie que le rythme d'envoi des fragments est identique au rythme de leur échéance, ou en 20 d'autres termes que le débit de transmission des fragments et que le débit d'encodage des fragments sont identiques. Le client possède une mémoire tampon située entre le récepteur des fragments de contenu multimédia et le dispositif de décodage. Le rôle de cette mémoire tampon est d'introduire un délai entre le moment de réception des 25 fragments et leur utilisation pour permettre d'une part de lisser les variations de délai de transmission des fragments et d'autoriser l'utilisation de mécanismes pour parer la perte ou la corruption de fragments comme mentionné précédemment. Pour diminuer le temps de démarrage de la présentation du contenu 30 multimédia, le débit d'encodage est, dans une première phase, diminué. Ainsi, après la réception d'une requête de démarrage d'un contenu multimédia par le serveur, celui-ci envoie au client les fragments successifs en respectant des 2905221 18 échéances temporelles. Après avoir reçu une requête d'un contenu multimédia (référence 500), le serveur accède le contenu multimédia demandé et extrait le premier fragment qui est encodé et transmis vers le client (référence 505). Lorsque le fragment est reçu par le client (référence 510), il est stocké dans la 5 mémoire tampon d'où il est extrait (référence 515) pour être décodé. Le temps Round Trip Time (RTT) est égal à la somme du délai (t0) de transmission de la requête du contenu multimédia et du délai (t1) de transmission d'un fragment. Dans une première phase (jusqu'à la date 520) le temps t2, correspondant au délai entre la transmission de deux fragments consécutifs, est 10 inférieur au temps de décodage d'un fragment (t3), correspondant au délai entre les moments où deux fragments consécutifs sont extraits de la mémoire tampon. Le rythme de transmission est donc supérieur au rythme de décodage. Durant cette phase, l'encodeur (ou le transcodeur) doit générer chaque fragment dans un délai inférieur à t2. Comme le débit réseau est limité, il est 15 nécessaire de diminuer le débit d'encodage durant cette phase. Dans une deuxième phase, lorsque la mémoire tampon est remplie pour permettre la présentation du contenu multimédia avec une qualité suffisante, le rythme de transmission est modifié pour être approximativement égal au rythme de décodage. Le temps de transmission d'un fragment (t4) est 20 alors sensiblement égal au temps de décodage (t3). Le débit d'encodage peut alors être augmenté en respectant la contrainte du débit du réseau. Le temps nécessaire au remplissage de la mémoire tampon permettant la présentation du contenu multimédia est lié aux mécanismes de résistance aux erreurs que l'on veut mettre en oeuvre (durée de coupure, 25 latence des ARQ, FEC ou masquage d'erreur) et donc à la qualité de service que l'on veut garantir. Le seuil de démarrage tb est défini comme le temps de contenu multimédia à présenter que le tampon doit initialement contenir avant le démarrage de la présentation du contenu multimédia, équivalent au temps nécessaire pour remplir la mémoire tampon avec tb.rv bits du contenu 30 multimédia où rv est le débit d'encodage du contenu multimédia. Le temps de démarrage (ts) correspond au délai écoulé entre le moment où la requête a été formulée et le moment où les premiers fragments 2905221 19 reçus dans la mémoire tampon sont utilisés pour la présentation du contenu multimédia, c'est-à-dire à la somme des temps RTT et de remplissage de la mémoire tampon (tb). Le temps de démarrage ts se détermine selon la relation, t = RTT + tb'rv s 5 rt (5) où rt est le débit de transmission du contenu multimédia du serveur vers le client. Le régime transitoire (t5) est la période durant laquelle le contenu multimédia présenté est basé sur des fragments encodés avec le débit 10 d'encodage inférieur. Le temps passé par un fragment dans la mémoire tampon (t6) est déterminé par le moment où le fragment est stocké dans la mémoire tampon et le moment où il en est extrait. Il est maintenant possible d'analyser quelles sont les limites en débit et en durée. 15 Si le contenu multimédia est transmis en temps réel, le débit de transmission est égal au débit d'encodage du média, ts =RTT+tbrv =RTT+tb r v Cependant, si dans la phase initiale les fragments du contenu multimédia sont transmis n fois plus vite que le temps réel, ou temps 20 d'encodage (rt = n.rv) alors, ts = RTT + t.r = RTT + tb n.rv n (7) Le temps de démarrage est ainsi réduit, la réduction étant d'un facteur n si le délai de transmission d'un paquet sur lien réseau (RTT) est négligeable, n correspondant à la différence des débits d'encodage et de 25 transmission sur le lien réseau. Si rLien est le débit de transmission sur le lien réseau, le temps de démarrage est limité par les débits d'encodage et de transmission selon la relation suivante, (6) rt 'Lien n rLien rä t i tb rv s rLien (8) 2905221 20 La figure 6, comprenant les figures 6a, 6b, 6c, 6d et 6e, illustre les avantages de l'invention
et
son influence sur le remplissage de la mémoire tampon, la qualité du contenu multimédia présenté et le débit d'encodage en fonction du temps. Les figures 6a, 6b et 6c concernent les cas où un seul seuil 5 est défini dans la mémoire tampon alors que les figures 6d et 6e concernent les cas où plusieurs seuils sont définis. Les figures 6a, 6b et 6d concernent l'art antérieur tandis que les figures 6c et 6e illustrent les avantages de l'invention. La figure 6a présente le cas témoin où aucune optimisation concernant le temps de démarrage n'est mise en oeuvre. Comme indiqué 10 précédemment, le seuil de démarrage tb est défini comme le temps de contenu multimédia à présenter que le tampon doit initialement contenir avant le démarrage de la présentation du contenu multimédia, équivalent au temps nécessaire pour remplir la mémoire tampon, c'est-à-dire au temps de démarrage (ts), le délai de transmission de la requête et l'accès au contenu 15 multimédia (RTT) pouvant être considérés comme négligeables. La pente n du niveau de remplissage de la mémoire tampon durant la phase de démarrage est donc égale à un (n=tb/ts, avec tb=ts, selon l'équation 6). Lorsque le niveau de la mémoire tampon a atteint le seuil permettant la présentation du contenu multimédia, son niveau de remplissage reste constant, le débit d'encodage 20 étant sensiblement égal au débit de transmission et au débit de décodage. La présentation du contenu multimédia commence dès que le niveau de la mémoire tampon a atteint le seuil nécessaire. Le débit d'encodage étant constant, la qualité de la présentation est également constante. Le débit de transmission est constant.
25 La figure 6b illustre le principe de l'art antérieur généralement utilisé pour réduire le temps de démarrage où un mécanisme de débit de transmission supérieur au débit d'encodage est utilisé lors de la phase de démarrage pour réduire le temps de démarrage. Ainsi, le premier graphique montre que le temps pour atteindre le seuil de démarrage est réduit par rapport au cas 30 standard illustré sur la figure 6a. Le temps de démarrage est divisé par n qui est le rapport entre le débit de transmission et le débit d'encodage du contenu multimédia, selon l'équation 7. Comme illustré sur le deuxième graphique, la 2905221 21 qualité de présentation du contenu multimédia est constante à partir du moment où il est affiché car le débit d'encodage n'est pas modifié. Enfin, le troisième graphique présente la variation du débit de transmission entre la phase de démarrage et la phase suivante, le débit de transmission étant supérieur au 5 débit d'encodage durant la phase de démarrage. Il convient de noter que le débit de transmission ne peut pas être supérieur au débit du lien. La figure 6c présente une première mise en oeuvre de l'invention, utilisant un seul seuil dans la mémoire tampon, basé sur l'association de l'augmentation du débit de transmission et la diminution du débit d'encodage.
10 Le premier graphique montre que le temps pour atteindre le seuil de démarrage est réduit par rapport aux cas illustrés sur les figures 6a et 6b. Le temps de démarrage est divisé par n qui est le rapport entre le débit de transmission et débit d'encodage du contenu multimédia où rv-transcode est le débit d'encodage lors de la phase de transcodage, selon l'équation 8. Comme illustré 15 sur le second graphique, la réduction du débit d'encodage réduit la qualité de la présentation du contenu multimédia, le délai de compression de chaque fragment étant réduit. Ainsi, durant la phase de démarrage, la qualité de la présentation du contenu multimédia est inférieure à celle liée au débit d'encodage utilisé après la phase de démarrage. Le troisième graphique met en 20 évidence l'augmentation temporaire de la différence entre le débit de transmission et le débit d'encodage durant la phase de démarrage où le débit de transmission est augmenté alors que le débit d'encodage est diminué. Cette différence permet d'accroître le facteur n et donc de diminuer le temps de démarrage comme indiqué sur le premier graphique mais réduit 25 temporairement la qualité de la présentation du contenu multimédia comme illustré sur le deuxième graphique. Pour diminuer encore le temps de démarrage, une amélioration complémentaire consiste à réduire le seuil de démarrage de la mémoire tampon et à définir un seuil supplémentaire, nommé seuil optimal, qui détermine le 30 niveau de mémoire tampon qu'il est nécessaire d'atteindre pour que les mécanismes de correction d'erreur puissent être mis en oeuvre afin d'obtenir une qualité optimale. En d'autres termes, cela signifie que le seuil de 2905221 22 démarrage est dissocié du seuil où la quantité d'information contenue dans la mémoire tampon permet de mettre en place des mécanismes de correction d'erreurs. Cette amélioration complémentaire, tout en réduisant le temps de démarrage, augmente le temps du régime transitoire.
5 La figure 6d illustre un exemple dans lequel deux seuils distincts sont définis dans la mémoire tampon de données, un seuil de démarrage et un seuil optimal (t0). Selon cet exemple, seule la transmission initiale plus rapide que le temps réel est mise en place pour diminuer le temps de démarrage, il n'y a pas de diminution temporaire du débit d'encodage. Comme l'indique le premier 10 graphique, le niveau de la mémoire tampon atteint rapidement le seuil de démarrage, puis la vitesse d'augmentation du niveau du tampon diminue pour atteindre le seuil optimal où cette vitesse devient nulle. En effet, lorsque le seuil de démarrage est atteint, la mémoire tampon qui s'était remplie à la vitesse de transmission du contenu multimédia et qui n'était pas vidé, commence à se 15 vider à la vitesse de décodage du contenu multimédia. Comme la vitesse de décodage demeure plus faible que la vitesse de transmission le niveau de remplissage de la mémoire tampon augmente. Dès que le seuil optimal est atteint, la vitesse de transmission est réduite et devient égale à la vitesse d'encodage (temps réel). Le troisième graphique illustre ces changements de 20 débit en fonction du temps. En ce qui concerne la qualité de rendu du contenu multimédia, celui-ci n'est optimal que lorsque le niveau de remplissage de la mémoire tampon atteint le seuil optimal et que tous les mécanismes de protection d'erreur ont été mis en place. Avant, dans le régime transitoire entre le seuil de démarrage et le seuil optimal, la qualité est plus faible. De façon 25 approximative, la figure 6d représente la qualité qui augmente de façon continue selon le niveau de remplissage de la mémoire tampon. La figure 6e présente un second exemple de mise en oeuvre de l'invention. Dans ce dernier cas, le mécanisme de diminution temporaire du débit d'encodage et couplé au mécanisme d'augmentation du débit de 30 transmission, avec l'utilisation de deux seuils distincts dans la mémoire tampon, pour diminuer le temps de démarrage. Les résultats présentés sur cette figure peuvent s'interpréter comme la combinaison des résultats présentés sur les 2905221 23 figures 6c et 6d. Le premier graphique montre la réduction du temps de démarrage et la réduction du temps nécessaire à atteindre le niveau optimal de remplissage de la mémoire tampon. Ce résultat est obtenu par l'accroissement de la marge entre le débit d'encodage et le débit de transmission. La qualité de 5 la présentation du contenu multimédia est temporairement réduite pour diminuer le temps de démarrage et atteindre plus rapidement une qualité optimale. Comme illustré sur la figure 6, les moyens de réduction du temps de démarrage de la présentation du contenu multimédia ont un impact direct sur la 10 qualité du rendu de cette présentation et qu'il est donc nécessaire de trouver un compromis qui satisfasse au mieux l'utilisateur final. Ainsi un ou plusieurs seuils de qualité minimum acceptés par le client associés à des durées maximales de ces dégradations de qualité (correspondant au régime transitoire) sont communiqués par le client. La qualité peut prendre en compte à la fois la qualité 15 visuelle telle que calculée par le PSNR ou la variance comme décrit en référence à la figure 3, et la qualité introduite par les mécanismes de résistance aux erreurs. Ces paramètres sont utilisés pour limiter les mécanismes mis en oeuvre pour réduire le temps de démarrage du média. La figure 7, comprenant les figures 7a et 7b, illustre un exemple de 20 l'algorithme pour mettre en oeuvre l'invention afin d'optimiser la réduction du temps de démarrage et la qualité du contenu multimédia présenté. La figure 7a représente l'algorithme utilisé par le client pour accéder et visualiser un contenu multimédia alors que la figure 7b montre l'algorithme utilisé par le serveur pour transmettre le contenu multimédia.
25 Pour mettre en place les mécanismes décrits en référence à la figure 6e, il est nécessaire que le serveur détermine, pour satisfaire les contraintes de qualité et réaliser un démarrage rapide, les paramètres suivants: . le seuil de démarrage tb de la mémoire tampon de données du client ; 30 . le seuil de remplissage optimal to de la mémoire tampon de données du client ; 2905221 24 . le débit d'encodage du contenu multimédia lors de la phase de transcodage ni-transcode ; et . le débit disponible pour la transmission du média rLien. Comme illustré sur la figure 7a, le client voulant obtenir la 5 présentation d'un contenu média en fait la requête auprès d'un serveur (étape 700), par exemple en utilisant le protocole connu RTSP. Le client peut utiliser, en plus de la méthode classique de `RTSP SETUP', une méthode `RTSP SET PARAMETER' pour transmettre dans la requête la valeur des paramètres complémentaires suivants, 10 • la valeur minimale du rapport signal maximal à bruit (Peak Signal to Noise Ratio, PSNR) acceptable durant le régime transitoire, notée PSNRmin, et la durée maximum de ce régime, notée ttrans ; et, • le temps maximum de coupure de la transmission que le client veut supporter sans interruption dans l'affichage noté tcoupure.
15 En variante, le client peut indiquer plusieurs seuils de qualité et les durées maximales de chaque seuil ainsi que plusieurs mécanismes de résistance aux erreurs à mettre en place avec des latences associées. En variante, le client peut utiliser un autre protocole que RTSP, par exemple SIP, ou utiliser d'autres messages de RTSP.
20 Lors des échanges RTSP, le client reçoit un fichier Session Description Protocol (SDP) qui décrit les caractéristiques du contenu multimédia et les éventuels mécanismes de contrôle d'erreur mis en place (étape 705). Dans l'approche basée sur la retransmission de paquets (ARQ), le client utilise un canal de retour pour informer le serveur soit des paquets reçus 25 avec des messages d'acquittement (ACK) ou pour informer le serveur des paquets non reçus par des messages d'acquittement négatif (NACK). Le serveur renvoi alors les paquets perdus. Si le fichier SDP indique que le serveur supporte la retransmission de données, le client attend que le serveur lui indique le seuil de remplissage 30 optimal de la mémoire tampon de données to (ce calcul est détaillé ci-dessous). Lorsque ce seuil est atteint, le client peut demander la retransmission des paquets perdus.
2905221 25 Les paquets du contenu multimédia demandé lui sont alors transmis (étape 715). Dès que le serveur lui transmet la consigne de démarrage (étape 720), le contenu multimédia commence à être présenté à l'utilisateur (étape 725). En variante, le serveur peut indiquer dès le début le seuil de remplissage 5 tb permettant de commencer l'affichage. Dans ce cas le test 720 consiste à vérifier le niveau de remplissage du buffer. Lorsque le niveau de la mémoire tampon atteint le seuil optimal (étape 730), les mécanismes de protection face aux erreurs sont alors mis en place (étape 735), par exemple la retransmission de données.
10 Dans un premier temps, le serveur reçoit la requête du client (étape 750) avec les différents paramètres envoyés par le client, comme décrit dans le paragraphe précédent. Le serveur détermine alors le mécanisme de correction d'erreur à mettre en place et détermine la valeur du seuil to (étape 755). Si le mécanisme de retransmission de données est mis en place du coté serveur, le 15 serveur calcul le seuil optimal to de la mémoire tampon de données du client en fonction de la valeur maximal de coupure réseau que client souhaite supporter tcoupure, tel que, to = tcoupure + RTT Cette valeur est transmise au client.
20 Le contenu multimédia demandé est alors prêt à être transmit au client. Dans une première phase, le contenu multimédia est transmis plus vite que le temps réel (étape 760). Pour cela, son débit d'encodage est réduit selon la contrainte de la valeur minimale de qualité acceptable PSNRmin. Cette réduction du débit d'encodage du contenu multimédia est réalisée par un 25 mécanisme de régulation avec boucle de rétroaction. Ainsi, le module de contrôle du serveur transmet une consigne du débit d'encodage au module de contrôle de débit, ou rate control, et une valeur PSNR lui est donnée en retour. La consigne est modifiée en fonction de cette valeur de PSNR et en fonction de PSNRmin.
30 Le débit du lien est évalué dynamiquement en cours de la transmission en utilisant un algorithme de contrôle de débit connu comme 2905221 26 TFRC. Dans un premier temps, la limite est déterminée par la valeur maximale possible en fonction des capacités du serveur et du client. L'algorithme de transcodage avec contrainte de qualité est décrit ci-dessous: 5 1. Phase d'initialisation : la variable r est initialisée; si le contenu multimédia est directement reçu d'une source, r = rLien_max (débit maximal du lien) et si le contenu multimédia stocké sur un support local est déjà encodé, r = rv (débit d'encodage du contenu stocké). La consigne initiale du débit d'encodage est définie par, rv-transcode = min(r, rLien). Les paramètres de 10 régulation A et a sont, à titre d'illustration, définis tels que A = 1dB et a = 0,1. La valeur de ces paramètres peut être ajustée plus précisément selon les caractéristiques spécifiques de l'environnement dans lequel est implémenté l'algorithme. 2. Phase de régulation : durant la phase de régulation, le débit 15 d'encodage est déterminé de la façon suivante, si PSNR ? PSNRmin + A alors rv-transcode = rv-transcode x (1 ù a) si PSNR < PSNRmin alors rv-transcode = min(rLien, r, (1 + a) X rv- transcode) sinon rv-transcode = rv-transcode 20 la valeur rLien est réévaluée régulièrement en utilisant, par exemple, l'algorithme TFRC. Pour la mise en place de l'algorithme permettant de réaliser l'optimisation entre la réduction du temps de démarrage et la qualité du contenu multimédia présenté, il est nécessaire de déterminer le seuil de démarrage tb.
25 Comme illustré sur le premier graphique de la figure 6e, pour une valeur de n donnée, plus le seuil de démarrage est faible, plus le temps de démarrage ts est faible mais plus le temps tn mis pour atteindre le seuil optimal est long. Cependant, il est nécessaire de respecter la contrainte de qualité donnée par le client, et donc, 30 tn ù ttrans En se basant sur le premier graphique de la figure6e, il est possible de calculer la valeur du seuil de démarrage tb pour que tn soit inférieur à ttrans 2905221 27 en fonction de n. Les trois équations suivantes décrivent le niveau de remplissage de la mémoire tampon Nivtamp de données du client en fonction du temps, pour 0<<t<<ts Nwtamp=n•t 5 pour ts t<tn NiVtamp (nùl)'t+ tn pour tri ≤t Niv tamp = t Donc le temps pour atteindre le seuil optimal est déterminé selon la relation suivante, 1 y t t ù b nù1 n, 10 Ainsi ts to ù(nù1).t tb ~ n.(t0 ù(nù1).ttrans) ou tn ù ttrans implique que ans La valeur du seuil de démarrage calculée précédemment repose sur l'hypothèse que n ne varie pas en fonction du temps lors de la phase de transcodage, ce qui n'est pas le cas avec l'algorithme de transcodage utilisé.
15 En effet, la valeur de n a de forte chance d'augmenter en fonction du temps car rv-transcode doit diminuer jusqu'à ce que la qualité du contenu multimédia atteigne la valeur minimale de qualité. Si la valeur du seuil de démarrage tb est calculée avec le n moyen durant la phase de transcodage, une valeur de tb surestimée est calculée et donc la durée de période transitoire sera plus faible 20 que la contrainte fixée par le client. Ainsi, durant la phase transitoire, le module de contrôle du serveur calcule la valeur moyenne de n, et dès que la quantité de contenu multimédia envoyé atteint la valeur nm Y [t ù (nm Y ù 1) trans (étape 765), la consigne de démarrage est envoyée au client (étape 770).
25 Le régime transitoire continue jusqu'à ce que la quantité de contenu multimédia transmis atteigne la valeur to (étape 775). Le régime permanent est alors mis en place (étape 780), il n'y a plus de transcodage à réaliser et le débit de transmission est diminué pour être égal au débit d'encodage. Les systèmes de contrôle d'erreur sont mis en place.
2905221 28 La figure 8, comprenant les figures 8a, 8b et 8c, illustre le dispositif permettant à un serveur de diffuser le même flux de données à plusieurs clients. Lorsqu'un serveur diffuse le même flux à destination de plusieurs clients (mode broadcast ou multicast) et qu'un nouvel utilisateur émet une requête 5 pour recevoir le même contenu multimédia, il est nécessaire de mettre en place les mécanismes pour réduire le temps de démarrage du nouvel utilisateur. Il n'est pas possible de le faire sur le flux commun car cela aurait un impact sur tous les clients, même ceux qui ont déjà commencé la présentation du contenu multimédia depuis longtemps.
10 Une solution consiste, pour le serveur, à conserver les dernières images envoyées dans une mémoire tampon du serveur et à établir, dans une première phase, une transmission en mode point-à-point afin de remplir la mémoire tampon du client jusqu'au seuil optimal, plus rapidement que le temps réel, en utilisant les données stockées dans la mémoire tampon du serveur.
15 Lorsque ce seuil est atteint, le nouveau client peut basculer sur la transmission commune du flux de données. En pratique, la transmission point à point peut se faire en mode RTP sur UDP/IP unicast : le client choisit son port UDP, son adresse est alors imposée par les mécanismes réseau (par exemple DHCP).
20 La transmission point à multi point se fait en utilisant la transmission RTP sur UDP/IP multicast. Une adresse spéciale, réservée par le réseau, et un port IP multicast sont déterminés par le serveur. Cette adresse est communiquée à tous les clients qui veulent recevoir le flux de données. Les clients peuvent à tout moment s'abonner ou se désabonner de l'adresse 25 multicast. Tout paquet envoyé par le serveur à l'adresse multicast est automatiquement routé par le réseau vers tous les clients abonnés. La figure 8a présente un cas normal où le serveur transmet un flux multicast et trois clients (Cl, C2, C3) sont abonnés et reçoivent le flux de données. Un nouveau client (C4) fait une requête pour recevoir ce flux. Cette 30 requête se fait classiquement en utilisant le protocole RTSP sur TCP/IP. Une négociation a lieu sur RTSP pour le client et le serveur qui se mettent d'accord sur les protocoles, les adresses utilisés et les dates des opérations suivantes.
2905221 29 Dans un deuxième temps, comme illustré sur la figure 8b, le client C4 ouvre un port UDP/IP unicast en réception et le serveur lui transmet un flux unicast de démarrage rapide du contenu multimédia, comme décrit précédemment. Pendant ce temps le flux multicast continue d'être envoyé sans 5 modification aux autres clients. Dans un troisième temps le client C4 s'abonne au flux multicast et reçoit le même flux que les autres clients, comme montré sur la figure 8c. Il peut alors fermer son port unicast, le serveur arrête d'envoyer le flux sur le port unicast. Cela nécessite un mécanisme de synchronisation du premier flux avec 10 le flux commun pour que le changement entre le flux point-à-point et le flux point-à-multipoint se fasse sans interruption, comme illustré sur la figure 9. Le contenu multimédia est encodé à un débit rm et transmis en temps réel en multicast vers tous les clients (débit de transmission égal au débit d'encodage et débit de décodage). Ceci est indiqué sur la figure par la 15 transmission de l'image C au client Cl. Le serveur reçoit une demande de transmission d'un flux commun de la part d'un nouvel utilisateur. Celui-ci utilise l'algorithme décrit en figure 7a, il transmet donc les différents niveaux de qualité. Le serveur peut alors calculer les paramètres tb, rLien et rv- 20 transcode pour le nouveau client comme décrit précédemment en figure 7b. Le serveur applique les étapes 750 à 780 comme décrit précédemment. Le résultat est indiqué sur la figure 9 par la création du flux unicast. Le contenu multimédia (images D, E, F, G) est encodé au débit rv-transcode et transmis au client C4 avec un débit de transmission supérieur au temps réel. Le même contenu 25 multimédia est simultanément encodé au débit rm et transmis en temps réel en multicast vers tous les clients. On peut remarquer que le serveur a besoin d'accéder à des images qui avaient été envoyées auparavant en multicast (D, E) pour les renvoyer au nouveau client. Le serveur utilise pour cela une mémoire tampon dans lequel il 30 stocke les dernières images envoyées en multicast.
2905221 30 Le débit du lien rLien est évalué avec un algorithme de contrôle de débit TFRC et donc tient compte de l'utilisation partielle du réseau par le lien multicast. Après avoir rempli la mémoire tampon du client C4 à son niveau 5 optimal en utilisant le lien unicast, le serveur peut utiliser le même débit d'encodage pour le client C4 que pour les autres clients. En théorie, le client peut donc s'abonner au flux multicast dès que la mémoire tampon a atteint le niveau optimal. Il faut cependant augmenter ce temps pour que la transition entre la connexion point à point et la connexion multipoint se fasse sur une 10 frontière de GOP. En effet, un flux vidéo a une structure telle qu'il n'est pas possible de décoder une image d'un GOP si le début n'a pas été reçu. La date de transition est donc modifiée pour que le premier fragment reçu provenant de la connexion commune corresponde au changement de GOP. Le temps du passage entre la connexion point-àpoint et la connexion commune du coté 15 serveur est donc connue. Cette date (ou le numéro de l'image de transition) peut être transmise par le serveur au client en même temps que la consigne de démarrage, par exemple. Au moment de la transition, le serveur connaît le fragment du contenu multimédia envoyé par la connexion commune et peut en déduire le 20 dernier fragment à envoyer par la connexion point-à-point. Une fois ce fragment transmis, il arrête de transmettre sur la connexion point à point. Ceci est indiqué sur la figure par les images H et I qui sont transmises uniquement sur le flux multicast et qui sont reçues aussi par le client C4. De son cotés le client s'abonne à la connexion multipoint un peu 25 avant la date de transition. Il commence donc à recevoir des données correspondant à la fin du GOP précédent, ces données ne sont pas mémorisées par le client. Le client utilise les en-têtes des paquets RTP, qui indiquent le numéro de l'image, pour savoir à quel moment le nouveau GOP est envoyé. Il peut alors les stocker dans la mémoire tampon de réception. Pendant 30 ce temps il continue à recevoir les données sur la connexion point à point et à les stocker dans la mémoire tampon de réception, jusqu'à ce que le dernier fragment soit reçu.
2905221 31 Même si la synchronisation, entre les deux connexions, n'est pas parfaite, les derniers fragments sur la connexion point à point peuvent être reçus après le début de la réception multicast, cela peut être caché à l'utilisateur par le fonctionnement de la mémoire tampon de données.
5 Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de la transmission de contenu multimédia, et en particulier de vidéo, pourra appliquer des modifications dans la description précédente pour satisfaire ces besoins.

Claims (22)

REVENDICATIONS
1. Procédé pour transmettre un contenu multimédia sous forme de flux multimédia d'un serveur vers un client, caractérisé en ce que ce procédé comprend les étapes suivantes : . réception d'une requête dudit client pour transmettre ledit flux multimédia (750), cette requête comprenant au moins un paramètre lié à la 10 qualité de présentation dudit contenu multimédia ; . détermination d'au moins un premier débit d'encodage selon ledit au moins un paramètre (760), ledit au moins un premier débit d'encodage étant inférieur au débit de transmission du flux multimédia dudit serveur vers ledit client ; 15 . encodage d'une première partie dudit contenu multimédia selon ledit au moins un premier débit d'encodage et transmission de ladite première partie encodée dudit contenu multimédia audit client ; . détermination d'un second débit d'encodage supérieur audit au moins un premier débit (780) ; et, 20 . encodage d'une seconde partie dudit contenu multimédia selon ledit second débit d'encodage et transmission de ladite seconde partie encodée dudit contenu multimédia audit client.
2. Procédé selon la revendication 1 caractérisé en ce que ledit débit de transmission de ladite première partie dudit contenu multimédia audit client 25 est augmenté pour être supérieur audit débit de transmission de ladite seconde partie dudit contenu multimédia audit client.
3. Procédé selon la revendication 1 ou la revendication 2 dans lequel ledit second débit d'encodage est sensiblement égal audit débit de transmission du flux multimédia dudit serveur vers ledit client. 30
4. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que ledit premier débit d'encodage est dynamiquement 2905221 33 réévalué au cours de la transmission de ladite première partie dudit contenu multimédia.
5. Procédé selon la revendication 4 caractérisé en ce que la réévaluation dynamique dudit premier débit d'encodage est réalisée par un 5 mécanisme de régulation avec boucle de rétroaction.
6. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend en outre une étape de transmission d'une commande de démarrage de la présentation de ladite première partie encodée dudit contenu multimédia (770).
7. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que ledit au moins un paramètre comprend un paramètre de mise en oeuvre de mécanismes de correction d'erreurs liées à la transmission dudit contenu multimédia lors de la transmission de ladite première partie dudit contenu multimédia audit client.
8. Procédé selon la revendication 7 caractérisé en ce que ledit au moins un paramètre indique un temps maximum de coupure de transmission.
9. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que ledit au moins un paramètre comprend un paramètre lié à la qualité visuelle dudit contenu multimédia.
10. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend en outre des étapes suivantes : . détermination d'un troisième débit d'encodage différent dudit au moins un premier débit d'encodage ; . encodage de ladite première partie dudit contenu multimédia selon 25 ledit troisième débit d'encodage et transmission de ladite première partie dudit contenu multimédia encodée selon ledit troisième débit d'encodage à un second client différent dudit client, appelé premier client ; et, . transmission de ladite seconde partie encodée dudit contenu multimédia audits premier et second clients. 30
11. Procédé selon l'une quelconque des revendications précédentes dans lequel ladite étape d'encodage d'une première partie dudit contenu 2905221 34 multimédia et/ou ladite étape d'encodage d'une seconde partie dudit contenu multimédia consistent en une étape de transcodage.
12. Procédé de réception d'un contenu multimédia transmis sous forme de flux multimédia d'un serveur vers un client, caractérisé en que ce 5 procédé comprend les étapes suivantes : . émission d'une requête audit serveur pour recevoir ledit flux multimédia (700), cette requête comprenant au moins un paramètre lié à la qualité de présentation dudit contenu multimédia ; . réception d'une première partie dudit contenu multimédia (715), 10 ladite première partie dudit contenu multimédia étant encodée avec un premier débit d'encodage ; . démarrage de la présentation de la dite première partie dudit contenu multimédia (725) ; et, . réception d'une seconde partie dudit contenu multimédia, ladite 15 seconde partie dudit contenu multimédia étant encodée avec un second débit d'encodage.
13. Procédé selon la revendication 12 caractérisé en ce qu'il comprend en outre une étape de réception d'une commande de démarrage de la présentation de ladite première partie dudit contenu multimédia (720). 20
14. Dispositif pour transmettre un contenu multimédia à un client, sous forme de flux multimédia, caractérisé en ce que ce dispositif comprend les moyens suivants, . moyens pour recevoir une requête dudit client pour transmettre ledit flux multimédia (440), cette requête comprenant au moins un paramètre lié 25 à la qualité de présentation dudit contenu multimédia ; . moyens pour déterminer d'au moins un premier débit d'encodage selon ledit au moins un paramètre (445), ledit au moins un premier débit d'encodage étant inférieur au débit de transmission du flux multimédia dudit serveur vers ledit client ; 30 . moyens pour encoder une première partie dudit contenu multimédia selon ledit premier débit d'encodage (425) et pour transmettre ladite première partie encodée dudit contenu multimédia audit client (450) ; 2905221 35 . moyens pour déterminer un second débit d'encodage supérieur audit au moins un premier débit (445) ; et, . moyens pour encoder une seconde partie dudit contenu multimédia selon ledit second débit d'encodage (425) et pour transmettre ladite 5 seconde partie encodée dudit contenu multimédia audit client (450).
15. Dispositif selon la revendication 14 caractérisé en ce qu'il comprend en outre des moyens pour augmenter ledit débit de transmission de ladite première partie dudit contenu multimédia audit client de telle sorte que ledit débit de transmission de ladite première partie dudit contenu multimédia 10 est supérieur audit débit de transmission de ladite seconde partie dudit contenu multimédia audit client.
16. Dispositif selon la revendication 14 ou la revendication 15 caractérisé en ce qu'il comprend en outre des moyens pour réévaluer dynamiquement ledit premier débit d'encodage au cours de la transmission de 15 ladite première partie dudit contenu multimédia.
17. Dispositif selon la revendication 16 caractérisé en ce que les moyens pour réévaluer dynamiquement ledit premier débit d'encodage au cours de la transmission de ladite première partie dudit contenu multimédia comprennent un mécanisme de régulation avec boucle de rétroaction. 20
18. Dispositif selon l'une des revendications 14 à 17 caractérisé en ce qu'il comprend en outre des moyens pour transmettre une commande de démarrage de la présentation de ladite première partie encodée dudit contenu multimédia.
19. Dispositif selon l'une des revendications 14 à 18 caractérisé en 25 ce qu'il comprend en outre les moyens suivants : . moyens pour déterminer un troisième débit d'encodage différent dudit premier débit d'encodage ; . moyens pour encoder ladite première partie dudit contenu multimédia selon ledit troisième débit d'encodage et pour transmettre ladite 30 première partie dudit contenu multimédia encodée selon ledit troisième débit d'encodage à un second client différent dudit client, appelé premier client ; et, 2905221 36 . moyens pour transmettre ladite seconde partie encodée dudit contenu multimédia audits premier et second clients.
20. Dispositif selon la revendication 19 caractérisé en ce qu'il comprend en outre des moyens de stockage adaptés à mémoriser au moins 5 une partie de ladite seconde partie encodée dudit contenu multimédia transmise audits premier et second clients.
21. Dispositif selon l'une des revendications 14 à 20 caractérisé en ce que lesdits moyens pour encoder sont des moyens pour transcoder (435).
22. Dispositif pour recevoir un contenu multimédia d'un serveur, sous 10 forme de flux multimédia, caractérisé en que ce dispositif comprend les moyens suivants : . moyens pour émettre une requête audit serveur pour recevoir ledit flux multimédia (415), cette requête comprenant au moins un paramètre lié à la qualité de présentation dudit contenu multimédia ; 15 . moyens pour recevoir une première partie dudit contenu multimédia (455), ladite première partie dudit contenu multimédia étant encodée avec un premier débit d'encodage ; . moyens pour démarrer la présentation de la dite première partie dudit contenu multimédia (465) ; et, 20 . moyens pour recevoir une seconde partie dudit contenu multimédia (455), ladite seconde partie dudit contenu multimédia étant encodée avec un second débit d'encodage. 25. Dispositif selon la revendication 22 caractérisé en ce qu'il comprend en outre des moyens pour recevoir une commande de démarrage de la présentation de ladite première partie dudit contenu multimédia. 26. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 13. 27. Serveur comprenant des moyens adaptés à la mise en oeuvre de 30 chacune des étapes du procédé selon l'une quelconque des revendications 1 à 11.
FR0653479A 2006-08-28 2006-08-28 Procede et systemes pour optimiser la transmission d'un flux de donnees. Expired - Fee Related FR2905221B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0653479A FR2905221B1 (fr) 2006-08-28 2006-08-28 Procede et systemes pour optimiser la transmission d'un flux de donnees.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0653479A FR2905221B1 (fr) 2006-08-28 2006-08-28 Procede et systemes pour optimiser la transmission d'un flux de donnees.

Publications (2)

Publication Number Publication Date
FR2905221A1 true FR2905221A1 (fr) 2008-02-29
FR2905221B1 FR2905221B1 (fr) 2008-12-19

Family

ID=37909517

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0653479A Expired - Fee Related FR2905221B1 (fr) 2006-08-28 2006-08-28 Procede et systemes pour optimiser la transmission d'un flux de donnees.

Country Status (1)

Country Link
FR (1) FR2905221B1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000035201A1 (fr) * 1998-12-04 2000-06-15 Microsoft Corporation Minimisation du temps de latence pour presentation multimedia
US6185625B1 (en) * 1996-12-20 2001-02-06 Intel Corporation Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object
WO2002045372A2 (fr) * 2000-11-29 2002-06-06 British Telecommunications Public Limited Company Transmission et reception de donnees en temps reel
EP1225717A2 (fr) * 2001-01-22 2002-07-24 Hitachi, Ltd. Méthode pour la transmission d'un programme de radiodiffusion ou un signal d'enregistrement est transmis avec le programme et le programme est enregistré sur un support d'enregistrement et est reproduit quand un signal de reproduction est transmis, ainsi que récepteur utilisant cette méthode
EP1271953A2 (fr) * 2001-06-28 2003-01-02 Microsoft Corporation Procédés et appareils pour un démarrage amélioré lors de la transmission en continu de données
WO2004039034A1 (fr) * 2002-10-24 2004-05-06 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de reduction du temps de tamponnage initial pour une application en continu
US20040114605A1 (en) * 2002-12-11 2004-06-17 Jeyhan Karaoguz Quality of service support in a media exchange network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185625B1 (en) * 1996-12-20 2001-02-06 Intel Corporation Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object
WO2000035201A1 (fr) * 1998-12-04 2000-06-15 Microsoft Corporation Minimisation du temps de latence pour presentation multimedia
WO2002045372A2 (fr) * 2000-11-29 2002-06-06 British Telecommunications Public Limited Company Transmission et reception de donnees en temps reel
EP1225717A2 (fr) * 2001-01-22 2002-07-24 Hitachi, Ltd. Méthode pour la transmission d'un programme de radiodiffusion ou un signal d'enregistrement est transmis avec le programme et le programme est enregistré sur un support d'enregistrement et est reproduit quand un signal de reproduction est transmis, ainsi que récepteur utilisant cette méthode
EP1271953A2 (fr) * 2001-06-28 2003-01-02 Microsoft Corporation Procédés et appareils pour un démarrage amélioré lors de la transmission en continu de données
WO2004039034A1 (fr) * 2002-10-24 2004-05-06 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de reduction du temps de tamponnage initial pour une application en continu
US20040114605A1 (en) * 2002-12-11 2004-06-17 Jeyhan Karaoguz Quality of service support in a media exchange network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PETIT G H ET AL: "Bandwidth resource optimization in video-on-demand network architectures", COMMUNITY NETWORKING INTEGRATED MULTIMEDIA SERVICES TO THE HOME, 1994., PROCEEDINGS OF THE 1ST INTERNATIONAL WORKSHOP ON SAN FRANCISCO, CA, USA 13-14 JULY 1994, NEW YORK, NY, USA,IEEE, 13 July 1994 (1994-07-13), pages 91 - 97, XP010124402, ISBN: 0-7803-2076-X *

Also Published As

Publication number Publication date
FR2905221B1 (fr) 2008-12-19

Similar Documents

Publication Publication Date Title
US9112938B2 (en) Adaptive playback with look-ahead
EP2360924A1 (fr) Vorrichtung und Verfahren zur Übertragung digitaler Multimediadaten
US10944973B2 (en) Estimation of video quality of experience on media servers
FR2902266A1 (fr) Procede et dispositif de repartition de la bande passante de communication
FR2916600A1 (fr) Procede et dispositif de transmission de donnees
FR2883692A1 (fr) Procede d&#39;envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede
FR2975555A1 (fr) Methode d&#39;adaptation dynamique du debit de reception et recepteur associe
WO2007006786A2 (fr) Appareil et procede d&#39;estimation du taux de remplissage des tampons d&#39;entree de clients d&#39;une distribution de contenu temps reel
US10277957B2 (en) Method for delivering an audio-video live content in multicast form
FR2946820A1 (fr) Procede de transmission de donnees et dispositif associe.
WO2009053595A1 (fr) Dispositif de reception en continu de paquets de donnees audio et/ou video
EP3840335B1 (fr) Réception d&#39;un contenu numérique en mode truque
FR2905221A1 (fr) Procede et systemes pour optimiser la transmission d&#39;un flux de donnees.
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d&#39;un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
FR3054765B1 (fr) Procede pour la lecture sur un equipement d&#39;un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
FR3081647A1 (fr) Gestion du telechargement progressif adaptatif (has) d&#39;un contenu numerique au sein d&#39;un terminal lecteur de flux multimedia en temps reel.
EP3973714A1 (fr) Restitution d&#39;un contenu en arrière-plan ou sous forme d&#39;incrustation dans le cadre d&#39;un téléchargement progressif adaptatif de type has
WO2024013463A1 (fr) Streaming vidéo adaptatif hybride amélioré
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140430