FR2957743A1 - Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants - Google Patents

Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants Download PDF

Info

Publication number
FR2957743A1
FR2957743A1 FR1052006A FR1052006A FR2957743A1 FR 2957743 A1 FR2957743 A1 FR 2957743A1 FR 1052006 A FR1052006 A FR 1052006A FR 1052006 A FR1052006 A FR 1052006A FR 2957743 A1 FR2957743 A1 FR 2957743A1
Authority
FR
France
Prior art keywords
data
transition
encoded
transport period
transport
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
FR1052006A
Other languages
English (en)
Other versions
FR2957743B1 (fr
Inventor
Romain Guignard
Arnaud Closset
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 FR1052006A priority Critical patent/FR2957743B1/fr
Publication of FR2957743A1 publication Critical patent/FR2957743A1/fr
Application granted granted Critical
Publication of FR2957743B1 publication Critical patent/FR2957743B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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
    • H04N21/6379—Control signals issued by the client directed to the server or network components directed to server directed to encoder, e.g. for requesting a lower encoding rate
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Il est proposé un procédé de gestion d'une transmission d'une séquence de données par un dispositif émetteur vers un dispositif récepteur. Le dispositif émetteur comprend un encodeur encodant des blocs de données applicatives sous forme de blocs de données encodées selon des paramètres d'encodage. La transmission est cadencée par périodes de transport. Le dispositif émetteur effectue des étapes consistant à : - identifier (412, 413), en fonction d'un nombre prédéfini de blocs de données applicatives par période de transport, une donnée applicative de transition dont la donnée encodée de transition respective est la dernière donnée encodée de la séquence à transmettre pendant une période de transport de transition ; - modifier (414, 422) les paramètres d'encodage à partir d'un début de bloc de données limite, choisi parmi les blocs de données applicatives à transporter pendant la période de transport de transition ; - transmettre, pendant la période de transport de transition, des données encodées, la donnée encodée de transition étant la dernière donnée encodée transmise pendant la période de transport de transition.

Description

Procédé de gestion d'une transmission de données par un dispositif émetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif émetteur correspondants 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui de la transmission de données entre un dispositif émetteur et un dispositif récepteur. On suppose que le dispositif émetteur comprend un encodeur fournissant pour transmission des blocs de données applicatives sous forme de blocs de données encodées. L'invention s'applique notamment, mais non exclusivement, à la transmission de données, dans un système de distribution vidéo, entre une application source (qui génère par exemple un contenu vidéo issu d'un lecteur DVD), placée en amont du dispositif émetteur, et au moins une application réceptrice (par exemple un téléviseur), placée en aval du dispositif récepteur. La technique de l'invention se situe au niveau de la gestion du codage source (encodage) mis en oeuvre par l'encodeur en amont d'un canal de transmission, par exemple de type synchrone et à bande passante constante (c'est-à-dire à débit constant). 2. ARRIÈRE-PLAN TECHNOLOGIQUE Dans un système de distribution vidéo entre une application source et au moins une application réceptrice, les données applicatives à transmettre sont préalablement stockées dans une mémoire tampon du dispositif émetteur avant de procéder au transport de ces données via le canal de transmission mis en oeuvre dans le système. Cette mémoire tampon est destinée à absorber la différence de rythme entre le cadencement applicatif des données et le cadencement de transmission via le canal de transmission. Pour des systèmes de distribution temps réel à faible latence, supportant par exemple des applications vidéo interactives, le canal de transmission privilégié est de type synchrone et à bande passante constante (« Constant Bit Rate » en anglais), ce qui permet de garantir un temps de transmission constant. Cependant, au regard de cette propriété de bande passante constante, il est nécessaire d'adapter, dans le dispositif émetteur, la quantité de données à transmettre à la capacité du canal de transmission. Dans ce cas, les données vidéo brutes issues de l'application sont compressées par le dispositif émetteur avant transmission, en utilisant par exemple une technique de compression (encodage) dite par blocs de lignes. Chaque bloc de lignes contient, par exemple, 16 lignes. Dans la suite de la description, un bloc de lignes est aussi appelé « tuile » (ou « Tile » en anglais). Cette technique de compression par tuile permet ainsi de garantir une faible latence de transmission de bout en bout. Les systèmes de transmission radio à 60 GHz (bande d'ondes RF millimétriques) sont particulièrement bien adaptés pour la transmission de données à très haut débit sur courtes distances. Cependant, le caractère aléatoire du canal de transmission peut amener la couche réseau à modifier la bande passante allouée à une application, afin d'adapter son schéma de retransmission, ou son schéma de correction d'erreur, aux nouvelles conditions de transmission. Dans de tels cas, l'application doit également adapter son volume de données à la nouvelle capacité du canal de transmission qui lui est dédiée. Un des principaux problèmes liés à la modification du codage source (c'est-à- dire des paramètres d'encodage utilisés par l'encodeur pour encoder les blocs de données applicatives) suite à une réallocation de la bande passante, est de maintenir une qualité de service constante, c'est-à-dire éviter toute interruption de l'application vis-à-vis de l'utilisateur. Pour éviter ce genre de désagrément, le système doit pouvoir maintenir une latence de bout en bout constante malgré les changements conjugués de bande passante et de codage source. Ainsi, lorsque la bande passante diminue, respectivement augmente, le taux de compression du codage source doit être plus élevé, respectivement plus faible. Dans l'état de la technique, il existe plusieurs techniques de modification de codage source tenant compte des paramètres du réseau.
Selon une approche connue, présentée dans le document de brevet GB 2306073, les paramètres de quantification ainsi que les besoins en débit sont calculés en fonction des paramètres de « leaky bucket » (« sceau percé » en français) et du taux de remplissage des différentes mémoires tampons (appelées « buffers » en anglais), ceci afin d'éviter les phénomènes de congestion.
Un inconvénient de cette approche connue réside dans l'aspect non prédictible du basculement effectif au niveau du transport entre des données applicatives ayant subies un premier codage source et des données applicatives ayant subies un second codage source. Ainsi, dans le contexte précité d'un changement conjugué de bande passante et de codage source, en utilisant l'approche connue précitée, le codage source peut ne pas être cohérent avec la bande passante allouée durant plusieurs périodes de transport, ce qui peut entraîner une modification de la latence de bout en bout ou une mauvaise utilisation de la bande passante allouée à l'application. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, il est souhaitable de fournir une technique de transmission de données entre un dispositif émetteur et un dispositif récepteur, permettant d'optimiser la gestion d'une modification de codage source (c'est-à-dire de paramètres d'encodage) dans le cas d'une réallocation de bande passante.
Il est aussi souhaitable de maintenir une latence de bout en bout constante dans le cadre d'un changement conjugué de bande passante et de codage source. En d'autres termes, il est souhaitable de réduire les impacts sur la qualité de service de l'application. Il est aussi souhaitable de maximiser l'utilisation de la bande passante lors d'un changement conjugué de bande passante et de codage source pour garantir le meilleur rendu (visuel) possible au regard de la bande passante disponible. Il est aussi souhaitable de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'une transmission d'une séquence de données par un dispositif émetteur vers un dispositif récepteur, le dispositif émetteur comprenant un encodeur encodant des blocs de données applicatives sous forme de blocs de données encodées selon des paramètres d'encodage, la transmission étant cadencée par périodes de transport, un nombre prédéfini de blocs de données applicatives étant à transporter par période de transport.
Le dispositif émetteur est tel que, suite à un événement prédéterminé, il effectue des étapes consistant à : - identifier, en fonction du nombre prédéfini de blocs de données applicatives par période de transport, une donnée applicative de transition dont la donnée encodée de transition respective est la dernière donnée encodée de ladite séquence à transmettre pendant une période de transport de transition ; - modifier lesdits paramètres d'encodage à partir d'un début de bloc de données limite, choisi parmi les blocs de données applicatives à transporter pendant ladite période de transport de transition ; - transmettre, pendant la période de transport de transition, des données encodées, la donnée encodée de transition étant la dernière donnée encodée transmise pendant ladite période de transport de transition. Ainsi, ce mode de réalisation de l'invention repose sur une approche tout à fait nouvelle et inventive consistant à déterminer la dernière donnée à transmettre (donnée encodée de transition) pendant la période de transport de transition et s'assurer que cette donnée déterminée sera effectivement la dernière donnée transmise. Ceci permet de maintenir une latence de bout en bout constante. Une période de transport de transition est une période pendant laquelle des données ayant subies un premier codage source (c'est-à-dire des données encodées selon les paramètres d'encodage) et des données ayant subies un second codage source (c'est-à-dire des données encodées selon les paramètres d'encodage modifiés) peuvent être transportées. Alors que l'approche connue précitée propose de corréler le changement de codage source au taux de remplissage d'une mémoire tampon, il est proposé ici de détecter un événement prédéterminé pour démarrer une période de transport de transition pendant laquelle des blocs de données applicatives sont transportés. L'instant de changement de codage source (c'est-à-dire l'instant à partir duquel les paramètres d'encodage sont modifiés et appliqués sur les données applicatives) est défini pour que le transport des données applicatives transformées selon le premier codage source soit terminé à l'instant de changement de bande passante (à la fin de la période de transition).
Ainsi, l'instant auquel le nouveau codage source est appliqué sur les données applicatives est maîtrisé.
De façon avantageuse, le dispositif émetteur est tel qu'il effectue des étapes consistant à : - détecter, pour la période de transport de transition, que le nombre prédéfini de blocs de données applicatives par période de transport est atteint ; - ajouter, en complément des blocs de données applicatives à transporter pendant ladite période de transport de transition, des données de bourrage pour compléter la séquence à transmettre pendant ladite période de transport de transition. Ajouter des données de bourrage permet d'éviter, dans le cas d'un canal de transmission synchrone, que le nombre de données applicatives transportées pendant la période de transport de transition ne soit plus important que le nombre prédéfini de données applicatives à transmettre par période de transport. Ainsi, on conserve une latence de bout en bout constante, et donc une qualité de service constante, malgré les changements conjugués de codage source et de bande passante. Selon une caractéristique avantageuse, dans le cas d'une diminution de bande passante allouée à ladite séquence à l'issue de la période de transport de transition, le bloc de données limite comprend la donnée applicative dont l'encodage permet d'obtenir la donnée encodée de transition. Dans le cas d'une diminution de bande passante, il est proposé de minimiser le nombre de blocs de données applicatives qui sont encodés selon le nouveau codage source (c'est-à-dire avec les paramètres d'encodage modifiés) et qui vont être transportées pendant la période de transport de transition. De cette façon, on maximise la qualité perçue au vu de la diminution de la bande passante sur le canal de transmission. On notera que, dans le cas où le dispositif émetteur ajoute des données de bourrage pour compléter la séquence à transmettre pendant la période de transport de transition, le fait de choisir comme bloc de données limite le bloc de données applicatives qui comprend la donnée applicative dont l'encodage permet d'obtenir la donnée encodée de transition, permet de minimiser le nombre de données de bourrage à ajouter. De cette façon, on optimise l'utilisation de la bande passante allouée et on garde un maximum d'efficacité de rendu.
Selon une autre caractéristique avantageuse, dans le cas d'une augmentation de bande passante allouée à ladite séquence au départ de la période de transport de transition, le bloc de données limite est le bloc de données applicatives qui est encodé immédiatement après réception dudit événement prédéterminé. Dans le cas d'une augmentation de bande passante, il est proposé de minimiser le nombre de blocs de données applicatives encodés selon l'ancien codage source (c'est-à- dire avec les paramètres d'encodage non modifiés) et qui vont être transportés pendant la période de transport de transition. De cette façon, on maximise la qualité perçue au vu de l'augmentation de la bande passante sur le canal de transmission. On notera que, dans le cas où le dispositif émetteur ajoute des données de bourrage pour compléter la séquence à transmettre pendant la période de transport de transition, le fait de choisir comme bloc de données limite le bloc de données applicatives qui est encodé immédiatement après réception de l'événement prédéterminé, permet de minimiser le nombre de données de bourrage à ajouter. De cette façon, on optimise l'utilisation de la bande passante allouée et on garde un maximum d'efficacité de rendu.
De façon avantageuse, le dispositif émetteur effectue une étape consistant à insérer une information de marquage relative au bloc de données limite dans la séquence transmise pendant ladite période de transport de transition. Ainsi, on transmet au dispositif récepteur une information de marquage qui va lui permettre de déterminer rapidement et efficacement le début du bloc de données à partir duquel le nouveau codage source a été appliqué sur les données applicatives, et ainsi lui permettre d'adapter ses paramètres de traitement. De façon avantageuse, ledit événement prédéterminé correspond à un changement de condition de transport (par exemple, changement de bande passante résultant d'une modification du canal de transmission suite à des interférences, ou à une libération de bande passante suite à un arrêt d'une application,...) sur un canal de transmission, sur lequel la transmission de la séquence de données est effectuée. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur.
Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation).
Dans un mode de réalisation particulier de l'invention, il est proposé un dispositif émetteur comprenant des moyens pour gérer une transmission d'une séquence de données vers un dispositif récepteur via un canal de transmission, le dispositif émetteur comprenant un encodeur encodant des blocs de données applicatives sous forme de données encodées selon des paramètres d'encodage, la transmission étant cadencée par périodes de transport, un nombre prédéfini de blocs de données applicatives étant à transporter par période de transport. Le dispositif émetteur est tel qu'il comprend les moyens suivants, activés suite à un événement prédéterminé : - des moyens pour identifier, en fonction du nombre prédéfini de blocs de données applicatives par période de transport, une donnée applicative de transition dont la donnée de transition encodée respective est la dernière donnée encodée de ladite séquence à transmettre pendant une période de transport de transition, lesdits moyens pour identifier étant activés suite à un événement prédéterminé ; - des moyens pour modifier lesdits paramètres d'encodage à partir d'un début de bloc de données limite, choisi parmi les blocs de données applicatives à transporter pendant ladite période de transport de transition ; - des moyens pour transmettre, pendant la période de transport de transition, des données encodées, la donnée encodée de transition étant la dernière donnée encodée transmise pendant ladite période de transport de transition. Avantageusement, le dispositif émetteur comprend des moyens de mise en oeuvre des étapes du procédé de transmission tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de 30 la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : 20 25 • la figure 1 décrit l'architecture d'un système de distribution vidéo temps réel, selon un mode de réalisation particulier de l'invention ; • la figure 2 présente un exemple de système de communication entre un noeud émetteur et un noeud récepteur, qui implémente, côtés émission et réception, des mécanismes selon un mode de réalisation particulier de l'invention ; • la figure 3 illustre schématiquement le principe d'un mode de réalisation particulier de l'invention, à travers un exemple d'encodage de données et de transport de ces données encodées ; • la figure 4 présente un mode de réalisation particulier d'un algorithme de modification de codage source en fonction d'un changement de bande passante, tel qu'implémenté au sein d'un module de gestion de changement de codage source (compris dans le noeud émetteur de la figure 2) ; • la figure 5 présente un mode de réalisation particulier d'un algorithme d'application de codage source selon un rendement donné, tel qu'implémenté au sein d'un module de traitement (compris dans le noeud émetteur de la figure 2) ; • la figure 6 présente un mode de réalisation particulier d'un algorithme de gestion de la période de transport de transition inhérente à un changement conjugué de bande passante et de codage source, tel qu'implémenté au sein d'un module de gestion de transmission (compris dans le noeud émetteur de la figure 2) ; et • la figure 7 présente un mode de réalisation particulier d'un algorithme de traitement de délimiteurs de tuile et de délimiteurs de changement de codage source, tel qu'implémenté au sein d'un module de gestion de réception (compris dans le noeud récepteur de la figure 2). 6. DESCRIPTION DÉTAILLÉE La figure 1 décrit l'architecture d'un système de distribution vidéo temps réel, selon un mode de réalisation particulier de l'invention. Ce système de distribution permet d'afficher, au niveau d'un écran, le contenu d'une source vidéo. Plus particulièrement, le système de distribution vidéo temps réel comprend : - un canal de transmission synchrone 105 de type TDM (pour « Time Division Multiplexing » en anglais, et « multiplexage temporel » en français) ; 30 - un noeud émetteur 102, aussi appelé par la suite dispositif émetteur, (« sending device » en anglais) comprenant une première extrémité connectée au canal 105 et une seconde extrémité connectée à une source vidéo 101 (par exemple un lecteur DVD) générant des données applicatives audiovisuelles brutes ; - un noeud récepteur 103, aussi appelé par la suite dispositif récepteur, (« receiving device » en anglais) comprenant une première extrémité connectée au canal 105 et une seconde extrémité connectée à un dispositif d'affichage vidéo (ou écran) 104. La figure 2 présente un exemple de système de communication entre deux noeuds, qui implémente, côtés émission et réception, des mécanismes selon un mode de réalisation particulier de l'invention. Le noeud émetteur 102 est connecté en entrée à une application génératrice de données vidéo brutes (blocs de données applicatives), au travers de l'interface Video_in 210, et en sortie au canal de transmission 105, au travers de l'interface D_out 250. Le noeud émetteur 102 a pour objectif d'adapter la quantité de données produites par l'application à la bande passante allouée sur le canal de transmission pour cette application. Le noeud émetteur 102 comprend : • un module de traitement 201, aussi appelé par la suite encodeur, destiné à réduire le débit applicatif par compression, à hauteur de la capacité de débit du canal de transmission synchrone 105 ; • un module de gestion de transmission 203 ; • un module de gestion de changement de codage source 204. Le module de traitement 201 effectue un traitement de compression par bloc de données, par exemple par tuile, une tuile correspondant à un nombre prédéfini de macro-blocs (bloc de données) générés par l'application. Le module de traitement 201 applique donc un codage source sur les données vidéo brutes fournies par l'application, au travers de l'interface Video_in 210, en fonction d'une valeur cible de codage source 225 (ou valeur cible de « bitrate ») provenant du module de gestion de changement de codage source 204. Comme décrit ci-après, cette valeur cible de codage source donne le rendement de codage source à appliquer sur les blocs de données applicatives. Le module de traitement 201 produit alors des macro-blocs compressés (blocs de données encodées) et les fournit au module de gestion de transmission 203, au travers de l'interface MB_Data_in 215. L'algorithme de traitement du module de traitement 201 est décrit ci-dessous en relation avec la figure 5.
Le module de gestion de transmission 203, dont l'algorithme de traitement est décrit ci-dessous en relation avec la figure 6, reçoit les macro-blocs compressés, au travers de l'interface MB_Data_in 215, et les stocke dans une unité de stockage 202, au travers de l'interface E_Data 245. Le module de gestion de transmission 203 utilise un signal MB_delimiter 220 provenant du module de traitement 201 pour marquer les frontières entre les macro-blocs avant de les stocker. Le module de gestion de transmission 203 est également chargé de mettre en forme les données à transmettre sur le canal de transmission 105 au travers de l'interface D_out 250, et d'insérer un délimiteur de tuile dans le flux de données à transmettre, après chaque envoi d'un nombre prédéfini de macro-blocs ; Le module de gestion de changement de codage source 204, dont l'algorithme de traitement est décrit ci-dessous en relation avec la figure 4, fournit une valeur cible de codage source SC_setting 225 au module de traitement 201, par tuile ou par groupe de tuiles. Le module de traitement 201 fournit au module de gestion de changement de codage source 204 un signal Tile_event 230 lui indiquant la réception d'une nouvelle tuile ou d'un nouveau groupe de tuiles. Bien que la valeur cible de codage source SC_setting 225 soit prise en compte pour chaque nouvelle tuile ou groupe de tuiles, elle n'est modifiée qu'en cas de réception d'une requête de changement Change_request 235 provenant du module de gestion de transmission 203. Le module de gestion de transmission 203 génère la requête de changement Change_request 235 en cas de changement de l'environnement de transmission. Par exemple, un tel changement peut se produire en cas de dégradation ou d'amélioration des conditions de transmission, en cas d'introduction de nouveaux noeuds ou de suppression de noeuds, etc. Ainsi, le module de gestion de transmission 203 génère la requête Change_request 235 à chaque modification de la répartition de la bande passante allouée à l'application. Le module de gestion de changement de codage source 204 fournit au module de gestion de transmission 203 un signal SC_Delimiter 255 lui indiquant un changement de codage source. De cette façon, le module de gestion de transmission 203 est capable de générer et d'insérer un délimiteur de changement de codage source dans le flux de données à transmettre.
Le noeud récepteur 103 est connecté en sortie du canal de transmission 105, au travers de l'interface D_in 260, et à une application consommatrice de données vidéo brutes, au travers de l'interface Video_out 290. Le noeud récepteur 103 a pour objectif de décoder les données compressées reçues du canal de transmission pour fournir les données vidéo brutes à l'application consommatrice. Le noeud récepteur 103 comprend : • un module de gestion de réception 205, destiné à traiter les données compressées reçues du canal de transmission, puis à les stocker dans une unité de stockage 206, dont l'accès se fait au travers de l'interface Rx_Data 275 ; • un module de traitement 207 (décodeur) est destiné à reconstituer les données vidéo compressées issues du module de gestion de réception 205 ; Le module de gestion de réception 205 est chargé de l'analyse du délimiteur de changement de codage source afin de fournir une valeur cible de codage source SC_setting 265 au module de traitement 207. Le module de gestion de réception 205 fournit également au module de traitement 207 un signal start_decode 270 lui indiquant la réception d'un délimiteur de tuile. Sur réception du signal start_decode 270, le module de traitement 207 démarre le décodage des données compressées. L'algorithme de traitement du module de gestion de réception 205 est décrit ci-dessous en relation avec la figure 7. Le module de traitement 207 (décodeur) est destiné à reconstituer les données vidéo compressées issues du module de gestion de réception 205. Ainsi, sur réception du signal start_decode 270, le module de traitement 207 lit les données stockées dans l'unité de stockage 206, au travers de l'interface MB_Data_out 280. Le module de traitement 207 décode ces données en appliquant la fonction de transfert inverse (codage source-1) à celle appliquée par l'encodeur 201 du noeud émetteur 102. Pour déterminer la bonne fonction de transfert, le module de traitement 207 utilise la valeur cible de codage source SC_setting 265 fournie par le module de gestion de réception 205. Le module de traitement 207 lit la valeur cible de codage source SC_setting 265 à chaque réception du signal start_decode 270, avant de commencer la lecture des données stockées dans l'unité de stockage 206. Le module de gestion de changement de codage source 204 et le module de gestion de transmission 203, compris dans le noeud émetteur 102, ainsi que le module de gestion de réception 205, compris dans le noeud récepteur 103, se réalisent chacun indifféremment : • sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou • sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC). Dans le cas d'une réalisation d'un module sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non amovible, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. La figure 3 illustre schématiquement le principe d'un mode de réalisation particulier de l'invention, à travers un exemple d'encodage de données et de transport de ces données encodées. La figure 3 se décompose en une partie haute et une partie basse, référencées 340 et 350 respectivement. La partie haute 340 illustre la génération (au niveau de la couche applicative) des blocs de données par application d'un codage source sur les données applicatives brutes fournies par l'application. La partie haute 340 comprend quatre périodes temporelles 361, 362, 370 et 380 correspondant à quatre fenêtres d'encodage. Dans un souci de simplification, dans l'exemple de la figure 3, les fenêtres d'encodage sont alignées sur un même événement : l'événement 333 est représenté de manière commune à la partie basse 350 et à la partie haute 340 de la figure 3. Ainsi, les quatre périodes temporelles 361, 362, 370 et 380 correspondent aussi à quatre périodes de transport.
Pendant la première fenêtre d'encodage 361, les données applicatives brutes sont encodées (compressées) selon un premier codage source. Pendant la deuxième fenêtre d'encodage 362, aussi appelée par la suite fenêtre d'encodage de transition, les données applicatives brutes sont encodées selon le premier codage source, puis selon un second codage source. Pendant les troisième et quatrième fenêtres d'encodage 370 et 380, les données applicatives brutes sont encodées selon le second codage source. Chaque fenêtre d'encodage comprend une pluralité de périodes d'encodage 360, un bloc de données encodées étant généré par période d'encodage 360. Cependant les fenêtres d'encodage ne sont pas alignées sur les périodes d'encodage 360. En effet, comme illustré sur la figure 3, un bloc de données encodées, compris dans une période d'encodage 360, peut être à cheval sur deux fenêtres d'encodage. Tel est le cas du bloc de données 305 par exemple. Dans l'exemple de la figure 3, les blocs de données encodées sont numérotés de 301 à 317. Le bloc de données encodées 301 correspond au premier bloc de données, et le bloc de données encodées 317 au dix-septième bloc de données. Sur la figure 3, les blocs blancs 301 à 307 représentent les blocs de données encodées selon le premier codage source (par exemple un changement de rapport Y : U : V tel qu'une conversion 4 : 4 : 4 vers 4 : 2 : 2) et les blocs gris 308 à 317 représentent les blocs de données encodées selon le second codage source (par exemple un changement de rapport Y : U : V tel qu'une conversion 4 : 4 : 4 vers 4 : 2 : 0). A chaque fenêtre d'encodage est associée une période de transport au cours de laquelle les données encodées pendant la fenêtre d'encodage sont transportées. Dans l'exemple de la figure 3, les données encodées des blocs 302, 303, 304 et des données encodées du bloc 305 appartiennent à la fenêtre d'encodage « n » (période 361) et sont transportée pendant la période de transport « n » (période 362). Chaque événement Tile_event 230 généré par le module de traitement 201 marque le début d'un bloc de données encodées, ce qui correspond au début d'une période d'encodage 360. Sur la figure 3, les événements Tile_event 230 sont représentés par des flèches en pointillés au début des blocs de données encodées 301 à 317.
La partie basse 350 illustre une séquence de transport (au niveau de la couche transport) des blocs de données encodées. La partie basse 350 comprend quatre périodes de transport 361, 362, 370 et 380. Une première valeur de bande passante est allouée au transport des données encodées pendant les périodes de transport 361, 362. Une seconde valeur de bande passante est allouée au transport des données encodées pendant la période de transport 380. Une troisième valeur de bande passante est allouée au transport des données encodées pendant la période de transport de transition 370, qui est soit égale à la première valeur (diminution de bande passante), soit égale à la seconde valeur (augmentation de bande passante). Une période de transport de transition est une période pendant laquelle des données ayant subies le premier codage source et des données ayant subies le second codage source peuvent être transportées. Lors d'une étape d'initialisation, un nombre de données applicatives par période de transport est défini en fonction de la durée de la période de transport, et ceci indépendamment du codage source appliqué sur les données applicatives. Ainsi, pour connaître la quantité de données applicatives à transporter par période de transport, le noeud émetteur 102 calcule le rapport entre une période d'encodage 360 et une période de transport auquel il multiplie le nombre de données applicatives fournies par l'application durant une période d'encodage 360. Il est à noter que la durée d'une période de transport est identique à la durée d'une fenêtre d'encodage. De plus, de manière illustrative sur la figure 3, la latence initiale est fixée à une période de transport. Par exemple, le bloc de données encodées 302, produit par le module de traitement 201 pendant la fenêtre d'encodage 361, est transmis sur le canal de transmission 105 par la couche transport pendant la période de transport 362.
Lors de la première fenêtre d'encodage 361, on commence par obtenir le bloc de données encodées 302 à partir du premier événement Tile_event 230, puis le bloc de données encodées 303 à partir du deuxième événement Tile_event 230, puis le bloc de données encodées 304 à partir du troisième événement Tile_event 230 et enfin le bloc de données encodées 305 à partir du quatrième événement Tile_event 230. Ces quatre blocs de données encodées 302 à 305 vont ensuite être agrégés pour être transmis au cours de la période de transport suivante 362, jusqu'à avoir atteint le nombre de données applicatives à transporter par période de transport (ou à encoder par fenêtre d'encodage). C'est ainsi que seule une portion du bloc de données encodées 305 est transmise pendant la période de transport 362 et que le reste du bloc de données encodées 305 est transmis pendant la période de transport 370. Au début de la fenêtre d'encodage 362, une requête de changement 300 de codage source est reçue. La requête de changement 300 de codage source peut parvenir de manière asynchrone par rapport à un début de fenêtre d'encodage (ou d'une période de transport). Elle est alors prise en compte au début de fenêtre d'encodage (ou de période de transport) immédiatement suivante. Le traitement de cette requête de changement 300 de codage source marque le début de la fenêtre d'encodage de transition 362. Cette requête de changement 300 de codage source indique également que la bande passante allouée à l'application changera après une durée prédéfinie (en nombre entier de période de transport), connue à la fois par le module de gestion de transmission 203 et par le module de gestion de changement de codage source 204. Dans un premier mode de réalisation, cette durée prédéfinie est fixe, que ce soit pour une augmentation ou une diminution de la bande passante. Par exemple, le changement de bande passante s'effectue après une durée égale à deux périodes de transport après la requête de changement 300 de codage source. Dans un second mode de réalisation, cette durée prédéfinie dépend de ce qu'il y a augmentation ou diminution de la bande passante. Par exemple, le changement de bande passante peut s'effectuer après une durée égale à deux périodes de transport après la requête de changement 300 de codage source dans le cas d'une diminution de bande passante, et après une durée égale à une période de transport après la requête de changement 300 de codage source dans le cas d'une augmentation de bande passante. Pour répondre à cette requête, le système doit effectuer le changement de codage source sur un bloc de données applicatives particulier de cette période de temps (durée prédéfinie). Le module de gestion de changement de codage source 204 commence donc par identifier le bloc de données de transition, c'est-à-dire le bloc de données qui chevauche la fenêtre d'encodage de transition et la fenêtre d'encodage qui suit immédiatement la fenêtre d'encodage de transition. Dans l'exemple de la figure 3, le bloc de données de transition est le bloc 309. Dans certains cas, le bloc de données de transition ne chevauche pas deux fenêtres d'encodage et se termine à la fin de la fenêtre d'encodage de transition (la fin du bloc de données coïncide avec le changement de fenêtre d'encodage). L'identification du bloc de données applicatives de transition, ainsi que la donnée applicative dont la donnée encodée correspondante est la dernière donnée transportée au cours de la période de transport de transition, est effectuée en fonction des paramètres suivants : • le nombre de données applicatives fournies par l'application par période d'encodage 360 ; • une mesure de décalage (« offset » en anglais) 395 indiquant le temps écoulé entre la réception de la requête de changement 300 de codage source (marquant le début de la fenêtre d'encodage de transition 362) et l'événement Tile_event 230 qui suit immédiatement ; et • un paramètre indiquant le nombre de période d'encodage 360 par fenêtre d'encodage (c'est-à-dire indirectement le rapport entre une période d'encodage 360 et une période de transport).
Le bloc de données de transition est déterminé à partir du bloc de données courant auquel on ajoute le nombre de période d'encodage par fenêtre d'encodage et auquel on soustrait le décalage mesuré. Il est considéré que le bloc de donnée courant est le bloc de donnée dont le début est marqué par l'événement Tile_event 230 utilisé pour la mesure de décalage 395.
Le résultat du calcul « nombre de période d'encodage par fenêtre d'encodage auquel est soustrait le décalage mesuré » est un nombre réel dont la partie entière indique le nombre d'événement Tile_event 230 entre le bloc de données courant et le bloc de données de transition, alors que la partie décimale, pondérée par le nombre de données applicatives fournies par l'application durant une fenêtre d'encodage, indique la donnée applicative de transition, c'est-à-dire celle dont la donnée encodée correspondante est la dernière donnée transportée au cours de la période de transport de transition. Ce calcul est effectué par le module de gestion de changement de codage source 204 et le résultat correspondant est envoyé au module de gestion de transmission 203, au travers de l'interface DataBlock_Marker 240. Le module de gestion de transmission 203 est en charge de déterminer la donnée applicative de transition en fonction du résultat du calcul effectué par le module de gestion de changement de codage source 204 et de la taille de chaque macro-bloc après encodage. Dans l'exemple de la figure 3, le rapport entre une période d'encodage 360 et une fenêtre d'encodage est égal à 3.8 (3.8 périodes d'encodage par fenêtre d'encodage) et le décalage 395 est égal à 0.39, ce qui donne la formule suivante : Ainsi, le bloc de données de transition et le bloc de données courant sont séparés par 3 événements Tile_event (3.8-0.39=3.41, dont la partie entière est 3). Dans l'exemple de la figure 3, le bloc de données courant est le bloc 306. On détermine donc que le bloc de données de transition est le bloc 309, soit 306 + 3.
Par exemple, si on considère qu'une tuile est composée de 80 macro-blocs, alors le 32ème macro-bloc contient la donnée applicative dont la donnée encodée correspondante sera la dernière donnée transportée lors de la période de transport de transition (80 macro-blocs x 0.41 = 32.8 macro-blocs). Si on considère ensuite que le 32ème macro-bloc encodé du bloc 309 comprend 350 octets, la transition s'effectue sur le 280ème octet du 32ème macro-bloc (0.8 x 350 octets = 280 octets). Ensuite, le module de gestion de changement de codage source 204 choisit le bloc de données applicatives (aussi appelé bloc de données limite) sur lequel le changement de codage source doit s'opérer. Le bloc de données limite doit être un bloc de données applicatives appartenant à la fenêtre d'encodage de transition (soit un des blocs 306, 307, 308 et 309). Dans l'exemple de la figure 3, le bloc choisi est le bloc 308. Le module de gestion de changement de codage source 204 envoie une requête de changement de codage source 320 pour indiquer au module de traitement 201 que le second codage source doit être appliqué à partir du bloc 308. Ainsi, à partir du bloc 308, le module de traitement 201 fournit des blocs de données encodées selon le second codage source.
Au cours de la période de transport de transition 370, des blocs de données applicatives encodées selon les premier et second codages sources sont transportés. Ainsi, la couche transport émet successivement la fin du bloc de données encodées 305, puis les blocs de données encodées 306 et 307. Ensuite, elle insère un délimiteur 325 indiquant un changement de codage source, avant d'émettre les blocs de données encodées 308 et une partie 309a du bloc de données encodées 309. Dans l'exemple de calcul présenté ci-dessus, la partie 309a s'arrête sur le 280ème octet du 32ème macrobloc. On note que pendant la période de transport de transition 370, la bande passante allouée est la bande passante la plus élevée entre la bande passante allouée pour chacune des périodes de transport 361 et 362 et celle allouée pour la période de transport 380. Ainsi, dans le cas d'une diminution de bande passante (la bande passante de chacune des périodes de transport 361 et 362 est supérieure à celle de la période de transport 380) la période de transport de transition 370 conserve l'allocation de bande passante des périodes de transport 361 et 362. En revanche, dans le cas d'une augmentation de bande passante (la bande passante de chacune des périodes de transport 361 et 362 est inférieure à celle de la période de transport 380), la période de transport de transition 370 prend l'allocation de bande passante de la période de transport 380. Dans l'exemple illustré par la figure 3, il est nécessaire d'ajouter des données de bourrage en complément des blocs de données applicatives compris dans la période de transport de transition. En effet, dans cet exemple le nombre prédéfini de données applicatives à transporter par période de transport est déjà atteint (d'après la détermination de la donnée applicative de transition) avant que tout le paquet de transport ne soit rempli. La couche de transport ajoute donc des données de bourrage 330 pour compléter le paquet de transport jusqu'à ce que la bande passante allouée soit atteinte. Sans l'ajout de ces données de bourrage, le nombre de données applicatives, transportées pendant la période de transport de transition, serait plus important que le nombre prédéfini de données applicatives à transporter, ce qui entraînerait une modification de la latence de bout en bout et donc pourrait entrainer une rupture de service.
Ensuite, dans la période de transport 380, la couche transport émet l'autre partie 309b du bloc de données encodées 309, puis les blocs de données encodées 310, 311, 312 et 313. La figure 4 présente un mode de réalisation particulier d'un algorithme de modification de codage source en fonction d'un changement de bande passante, tel qu'implémenté au sein du module de gestion de changement de codage source 204 (compris dans le noeud émetteur 102). Lors d'une étape d'initialisation 400, on définit un rendement (paramètres d'encodage) pour le codage source en fonction de la bande passante dédiée à l'application considérée (celle fournissant les données applicatives). Après l'étape d'initialisation 400, on passe à une étape 401 d'attente d'une requête de changement de répartition de la bande passante allouée à l'application (Change_request 300) ou d'un événement Tile_event 230. Sur réception d'une requête de changement Change_request 300 (étape 410), un test est effectué (étape 411) pour déterminer si le changement de bande passante est une augmentation ou une diminution de bande passante. En d'autres termes, à l'étape 411 on compare la nouvelle valeur de bande passante B' (contenue dans la requête Change_request) avec l'ancienne valeur de bande passante B. Comme décrit précédemment, le noeud émetteur 102 sélectionne un bloc de données applicatives (bloc de données limite) parmi les blocs de données applicatives compris dans la fenêtre d'encodage de transition. Le bloc de données applicatives ainsi sélectionné est le bloc à partir duquel le changement de codage source doit s'opérer. Le choix de ce bloc de donnée a un impact sur la quantité de données de bourrage que la couche de transport doit insérer durant la période de transport de transition pour maintenir le nombre de données applicatives transportées par période de transport. La sélection du bloc de données applicatives à partir duquel le changement de codage source doit s'opérer dépend du sens du changement de la bande passante (augmentation ou diminution). Dans tous les cas, pendant la période de transport de transition, on travaille avec la bande passante la plus élevée.
Dans un mode de réalisation préférentiel, tel qu'illustré par la figure 4, il est proposé de minimiser la quantité de données de bourrage à insérer à la fin de la période de transport de transition. Ainsi : - dans le cas d'une diminution de bande passante, il est proposé de minimiser le nombre de blocs de données applicatives qui sont encodés selon le nouveau codage source au cours de la fenêtre d'encodage de transition. Ainsi, le noeud émetteur 102 sélectionne (étape 412) le bloc de données applicatives qui chevauche la fenêtre d'encodage de transition et la fenêtre d'encodage suivant immédiatement la fenêtre d'encodage de transition. Le bloc de données applicatives ainsi sélectionné correspond au bloc de données applicatives à partir duquel le changement de codage source doit s'opérer. Puis un retour dans l'état d'attente 401 est opéré ; - dans le cas d'une augmentation de bande passante, il est proposé de minimiser le nombre de blocs de données applicatives qui sont encodés selon l'ancien codage source durant la fenêtre d'encodage de transition. Ainsi, le noeud émetteur 102 sélectionne (étape 413) le premier bloc de données applicatives de la fenêtre d'encodage de transition, c'est-à-dire la tuile qui suit immédiatement l'événement de réception de la requête de changement Change_request 300. Puis, un changement de codage source est effectué (envoi de la valeur cible de codage source SC_setting au module de traitement 201), au cours de l'étape 414, avant de reboucler vers l'état d'attente 401. Ainsi, le bloc de données applicatives sélectionné à l'étape 413 est encodé selon le nouveau codage source. Sur détection d'un événement de début d'un nouveau bloc de données (étape 420), un test est effectué (étape 421) pour vérifier si le nouveau bloc de données correspond au bloc de données qui précède le bloc de données sélectionné à l'étape 412 (c'est-à-dire le bloc de données à partir duquel le changement de codage source doit s'opérer). Si le nouveau bloc de données est le bloc de données qui précède le bloc de données sélectionné à l'étape 412, alors un changement de codage source est effectué au cours de l'étape 422. Ainsi, pendant cette étape 422, le rendement du codage source est mis à jour, de sorte que le module de traitement 201 applique le nouveau codage source à partir du bloc de données sélectionné à l'étape 412. Puis un retour dans l'état d'attente 401 est opéré.
En revanche, si le nouveau bloc de données n'est pas le bloc de données qui précède le bloc de données sélectionné à l'étape 412, alors un test est effectué (étape 423) pour vérifier si le nouveau bloc de données correspond au bloc de données sélectionné à l'étape 412 ou à l'étape 413. A l'étape 423, si le nouveau bloc de données est le bloc de données sélectionné à l'étape 412 ou à l'étape 413, alors le module de gestion de changement de codage source 204 fournit (étape 424) au module de gestion de transmission 203 un signal SC_Delimiter 255 lui indiquant un changement de codage source. Ainsi, sur réception d'un tel signal SC_Delimiter 255, le module de gestion de transmission 203 génère et insère un délimiteur de changement de codage source dans le flux de données à transmettre. Puis un retour dans l'état d'attente 401 est opéré. A l'étape 423, si le nouveau bloc de données n'est pas le bloc de données sélectionné à l'étape 412 ou à l'étape 413, alors on reboucle vers l'état d'attente 401. La figure 5 présente un mode de réalisation particulier d'un algorithme d'application de codage source selon un rendement donné, tel qu'implémenté au sein du module de traitement 201 (compris dans le noeud émetteur 102). Le codage source est appliqué sur les blocs de données applicatives, suivant un rendement donné par la valeur cible de codage source SC_setting 225 fournie par le module de gestion de changement de codage source 204. Après une étape d'initialisation 500, un nouveau bloc de données applicatives est reçu (étape 501) par le module de traitement 201, au travers de l'interface Video_in 210. A l'étape 502, le module de traitement 201 envoie au module de gestion de changement de codage source 204 un événement Tile_event 230, indiquant le début d'un nouveau bloc de données. Ensuite, à l'étape 503, le module de traitement 201 lit la valeur cible de codage source fournie par le module de gestion de changement de codage source 204, puis encode (étape 504) le nouveau bloc de données applicatives reçu en fonction de la valeur cible de codage source lue, avant de retourner à l'étape 501. On note que le rendement du codage source (contenu dans la valeur cible de codage source) est mis à jour à chaque nouveau bloc de données applicatives si besoin.
La figure 6 présente un mode de réalisation particulier d'un algorithme de gestion de la période de transport de transition inhérente à un changement conjugué de bande passante et de codage source, tel qu'implémenté au sein du module de gestion de transmission 203 (compris dans le noeud émetteur 102). Plus précisément, l'algorithme de la figure 6 permet la mise en paquet des données pour le transport sur le canal de transmission 105, et la génération d'un délimiteur de changement de codage source. Ce délimiteur de changement de codage source permet de marquer la séparation entre les données encodées suivant l'ancien codage source et les données encodées suivant le nouveau codage source. Lors d'une étape d'initialisation 600, un nombre de données applicatives par période de transport est défini en fonction de la durée de la période de transport. En effet, pour qu'un système de distribution temps réel fonctionne, il faut transporter durant une période de transport autant de données que l'application a produites pendant une fenêtre d'encodage de même durée. Dans un tel système, le couple bande passante et codage source est modifié de manière à conserver une relation constante entre le nombre de données applicatives à transporter et la période de transport. Par exemple, si l'application produit 118,3 macroblocs par fenêtre d'encodage, alors il faudra transporter 118,3 macro-blocs par période de transport, afin de conserver le caractère temps réel de la distribution. Ainsi, pour chaque nouvelle répartition de la bande passante allouée à l'application, un nouveau codage source devra être défini de telle sorte qu'il permet de transporter la bonne quantité de données applicatives avec la meilleure qualité possible. Après l'étape d'initialisation 600, on passe à une étape 601 d'attente d'un événement de réception d'un signal SC_Delimiter 255 indiquant un changement de codage source ou d'un événement de transport 333 (changement de période de transport).
Sur réception d'un signal SC_Delimiter 255 indiquant un changement de codage source (étape 610), le module de gestion de transmission 203 génère et insère (étape 611) un délimiteur 325 de changement de codage source dans le flux de données à transmettre, avant de retourner dans l'état d'attente 601.
Sur détection d'un événement de transport 333 (étape 620), il est effectué un calcul des différentes limites (étape 621), c'est-à-dire des blocs de données à partir desquels le remplissage des paquets de transport doit être stoppé. Ainsi, au cours de cette étape 621, il est calculé le bloc de données contenant la dernière donnée à transporter pour la période de transport de transition et le bloc de données à partir duquel le changement de codage source a été opéré (bloc de données limite). A l'étape 622, un test est effectué pour vérifier si le bloc de données courant (reçu par le module de gestion de transmission 203 au travers de l'interface MB_Data_in 215 et stocké temporairement dans la mémoire de données encodées 202 en attendant son envoi par le module de gestion de transmission 203) correspond au bloc de données contenant la dernière donnée à transporter pour la période de transport de transition ou au bloc de données à partir duquel le changement de codage source a été opéré. Si le bloc de données courant n'est pas le bloc de données contenant la dernière donnée à transporter pour la période de transport de transition, ni le bloc de données à partir duquel le changement de codage source a été opéré, alors un remplissage des paquets de transport est effectué avec des données encodées (étape 623). Ainsi, au cours de cette étape 623, le module de gestion de transmission 203 lit les blocs de données encodées (macro-blocs) stockés dans l'unité de stockage 202, au travers de l'interface E_Data 245, et construit des paquets de transport avec les données encodées lues.
Pour chaque paquet de transport rempli, un test est effectué (étape 629) pour détecter si le paquet de transport rempli est le dernier paquet de transport à remplir pour la période de transport. Si le paquet de transport rempli est le dernier paquet de transport à remplir pour la période de transport, c'est-à-dire si tous les paquets de transport ont été remplis pour la période de transport, alors on retourne dans l'état d'attente de l'étape 601, sinon on retourne au test de l'étape 622 pour vérifier si le bloc de données suivant est le bloc de données à partir duquel le changement de codage source a été opéré. A l'issue de l'étape 622, s'il est détecté que le bloc de données courant est : - soit le bloc de données contenant la dernière donnée à transporter pour la période de transport de transition, - soit le bloc de données à partir duquel le changement de codage source a été opéré, alors on passe à une nouvelle étape de test 624. A l'issue de l'étape 624, s'il est détecté que le bloc de données courant est le bloc de données à partir duquel le changement de codage source a été opéré, alors le module de gestion de transmission 203 génère et insère (étape 625) un délimiteur de changement de codage source dans le flux de données à transmettre, avant de retourner au test de l'étape 622. De cette façon, les derniers paquets de transport pour la période de transport de transition sont remplis avec des données encodées suivant le nouveau codage source. Dans le mode de réalisation décrit en référence à la figure 3, le délimiteur de changement de codage source 325 est un symbole spécial inséré directement dans le flux de données à transmettre. Ce symbole spécial est placé au début de la première donnée à partir de laquelle le nouveau codage source est appliqué.
Dans un autre mode de réalisation, le délimiteur de changement de codage source est transporté au travers d'un canal de contrôle spécifique. Dans cet autre mode de réalisation, le délimiteur n'indique pas spatialement la délimitation entre les données encodées selon l'ancien codage source et les données encodées selon le nouveau codage source, mais indique à partir de quelle donnée de la période de transport le nouveau codage source est appliqué. A l'issue de l'étape 624, s'il est détecté que le bloc de données courant est le bloc de données contenant la dernière donnée à transporter pour la période de transport de transition, alors le module de gestion de transmission 203 lit (étape 626) les données encodées stockées dans l'unité de stockage 202 jusqu'à cette dernière donnée (calculé à l'aide du signal DataBlock_Marker 240), et construit des paquets de transport avec les données encodées lues. Ensuite, à l'étape 627, il est effectué un test pour savoir si des données de bourrage doivent être insérées pour compléter le remplissage des paquets de transport.
Si tous les paquets de transport sont remplis, alors on retourne dans l'état d'attente de l'étape 601, sinon on passe à l'étape 628 dans laquelle des données de bourrage sont ajoutées pour compléter le remplissage des paquets de transport. Il est rappelé que ces données de bourrage sont ajoutées pour ne pas excéder le nombre (prédéfini) de données applicatives à transporter par période de transport.
La figure 7 présente un mode de réalisation particulier d'un algorithme de traitement de délimiteurs de tuile et de délimiteurs de changement de codage source, tel qu'implémenté au sein du module de gestion de réception 205 (compris dans le noeud récepteur 103). Après une étape d'initialisation 700, on passe à une étape 701 d'attente d'un événement de réception d'un délimiteur de tuile ou d'un délimiteur de changement de codage source. Sur réception d'un délimiteur de tuile (étape 710), le module de gestion de réception 205 envoie (étape 711) au module de traitement 207 un signal start_decode, 270 afin d'autoriser celui-ci à commencer la lecture et le décodage des données compressées, stockées dans l'unité de stockage 206. Puis un retour dans l'état d'attente 701 est opéré. Sur réception d'un délimiteur 325 de changement de codage source (étape 720), la valeur cible de codage source SC_setting 265, fournie au module de traitement 207, est mise à jour (étape 721). Puis un retour dans l'état d'attente 701 est opéré.
Il est à noter qu'au démarrage, le module de gestion de réception 205 reçoit d'abord un délimiteur de changement de codage source indiquant le premier traitement à effectuer, avant de recevoir le premier délimiteur de tuile qui permet de déclencher le décodage des données.

Claims (9)

  1. REVENDICATIONS1. Procédé de gestion d'une transmission d'une séquence de données par un dispositif émetteur (102) vers un dispositif récepteur (103), le dispositif émetteur comprenant un encodeur (201) encodant des blocs de données applicatives sous forme de blocs de données encodées selon des paramètres d'encodage, la transmission étant cadencée par périodes de transport, un nombre prédéfini de blocs de données applicatives étant à transporter par période de transport, caractérisé en ce que, suite à un événement prédéterminé, le dispositif émetteur effectue des étapes consistant à : - identifier (412, 413), en fonction du nombre prédéfini de blocs de données applicatives par période de transport, une donnée applicative de transition dont la donnée de transition encodée respective est la dernière donnée encodée de ladite séquence à transmettre pendant une période de transport de transition ; - modifier (414, 422) lesdits paramètres d'encodage à partir d'un début de bloc de données limite, choisi parmi les blocs de données applicatives à transporter pendant ladite période de transport de transition ; - transmettre, pendant la période de transport de transition, des données encodées, la donnée encodée de transition étant la dernière donnée encodée transmise pendant ladite période de transport de transition.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - détecter (627), pour la période de transport de transition, que le nombre prédéfini de blocs de données applicatives par période de transport est atteint ; - ajouter (628), en complément des blocs de données applicatives à transporter pendant ladite période de transport de transition, des données de bourrage (330) pour compléter la séquence à transmettre pendant ladite période de transport de transition.
  3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, dans le cas d'une diminution de bande passante allouée à ladite séquence à l'issue de la période de transport de transition, le bloc de données limite comprend la donnée applicative dont l'encodage permet d'obtenir la donnée encodée de transition.
  4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, dans le cas d'une augmentation de bande passante allouée à ladite séquence au départ de la période de transport de transition, le bloc de données limite est le bloc de données applicatives qui est encodé immédiatement après réception dudit événement prédéterminé.
  5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le dispositif émetteur effectue une étape consistant à insérer (424) une information de marquage (325) relative au bloc de données limite dans la séquence transmise pendant ladite période de transport de transition.
  6. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit événement prédéterminé correspond à un changement de condition de transport sur un canal de transmission, sur lequel la transmission de la séquence de données est effectuée.
  7. 7. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur.
  8. 8. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 6.
  9. 9. Dispositif émetteur (102) comprenant des moyens pour gérer une transmission d'une séquence de données vers un dispositif récepteur (103), le dispositif émetteur comprenant un encodeur (201) encodant des blocs de données applicatives sous forme de blocs de données encodées selon des paramètres d'encodage, la transmission étant cadencée par périodes de transport, un nombre prédéfini de blocs de données applicatives étant à transporter par période de transport, caractérisé en ce que le dispositif émetteur comprend les moyens suivants, activés suite à un événement prédéterminé : des moyens pour identifier, en fonction du nombre prédéfini de blocs de données applicatives par période de transport, une donnée applicative de transition dont la donnée encodée de transition respective est la dernière donnée encodée de ladite séquence à transmettre pendant une période de transport de transition ; 5- des moyens pour modifier lesdits paramètres d'encodage à partir d'un début de bloc de données limite, choisi parmi les blocs de données applicatives à transporter pendant ladite période de transport de transition ; - des moyens pour transmettre, pendant la période de transport de transition, des données encodées, la donnée encodée de transition étant la dernière donnée encodée transmise pendant ladite période de transport de transition.
FR1052006A 2010-03-19 2010-03-19 Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants Expired - Fee Related FR2957743B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1052006A FR2957743B1 (fr) 2010-03-19 2010-03-19 Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1052006A FR2957743B1 (fr) 2010-03-19 2010-03-19 Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants

Publications (2)

Publication Number Publication Date
FR2957743A1 true FR2957743A1 (fr) 2011-09-23
FR2957743B1 FR2957743B1 (fr) 2012-11-02

Family

ID=42931879

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1052006A Expired - Fee Related FR2957743B1 (fr) 2010-03-19 2010-03-19 Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants

Country Status (1)

Country Link
FR (1) FR2957743B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2306073A (en) * 1995-10-03 1997-04-23 Nec Corp VBR MPEG video encoding for ATM networks with dynamic bandwidth renegotiation
US6535557B1 (en) * 1998-12-07 2003-03-18 The University Of Tokyo Method and apparatus for coding moving picture image
US20040076229A1 (en) * 2001-02-06 2004-04-22 Yutaka Ishikawa Wireless image transmission device and image transmission method
WO2008105883A1 (fr) * 2007-03-01 2008-09-04 Qualcomm Incorporated Procédé et systèmes pour coder des données dans un réseau de communications

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2306073A (en) * 1995-10-03 1997-04-23 Nec Corp VBR MPEG video encoding for ATM networks with dynamic bandwidth renegotiation
US6535557B1 (en) * 1998-12-07 2003-03-18 The University Of Tokyo Method and apparatus for coding moving picture image
US20040076229A1 (en) * 2001-02-06 2004-04-22 Yutaka Ishikawa Wireless image transmission device and image transmission method
WO2008105883A1 (fr) * 2007-03-01 2008-09-04 Qualcomm Incorporated Procédé et systèmes pour coder des données dans un réseau de communications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RINALDO R ET AL: "DVB-S2 ACM modes for IP and MPEG unicast applications", INTERNATIONAL JOURNAL OF SATELLITE COMMUNICATIONS AND NETWORKING, JOHN WILEY & SONS, CHICHESTER, GB LNKD- DOI:10.1002/SAT.792, vol. 22, 16 June 2004 (2004-06-16), pages 367 - 399, XP002428161, ISSN: 1542-0973 *

Also Published As

Publication number Publication date
FR2957743B1 (fr) 2012-11-02

Similar Documents

Publication Publication Date Title
US8499059B2 (en) System and methods for buffering of real-time data streams
CN102318348B (zh) 数据流的块划分
FR2960320A1 (fr) Procede de gestion d'une transmission de donnees depuis un dispositif emetteur, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants
EP2775673B1 (fr) Dispositif, procédé et programme d'estimation d'informations de reproduction de contenu
FR2906950A1 (fr) Procede et dispositifs pour adapter le debit de transmission d'un flux de donnees en presence d'interferences.
FR2922066A1 (fr) Procede de gestion de la bande passante dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants
EP1874061A1 (fr) Procédé de gestion de demandes d'accès à distance à des contenus multimedia
KR20130112936A (ko) 적응적 스트리밍 서비스를 제공하기 위한 방법
FR2916600A1 (fr) Procede et dispositif de transmission de donnees
WO2006064098A1 (fr) Procede de transmission a debit binaire variable a travers un canal de transmission
FR2908585A1 (fr) Procede et dispositif de transmission de donnees video.
FR2975555A1 (fr) Methode d'adaptation dynamique du debit de reception et recepteur associe
FR3076158A1 (fr) Procede de regulation de debit
FR2932938A1 (fr) Procede et dispositif de transmission de donnees
EP2901617A1 (fr) Procede de communication, procede de gestion de communication, dispositifs et n uds associes
EP2947888A1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP1330071A2 (fr) Système de gestion de réseau ou de services pour la détermination de la synchronisation entre deux flots de paquets
EP1834489A1 (fr) Procede et dispositif de codage video
FR2828979A1 (fr) Compresseur, decompresseur, bloc de donnees et procede de gestion de ressources
US8009687B2 (en) Measurement of network performance in transporting packet streams
FR2866183A1 (fr) Procedes d'emission et de reception d'une animation, et dispositifs associes
FR2935493A1 (fr) Procede et dispositif de suivi d'antenne.
FR2957743A1 (fr) Procede de gestion d'une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d'ordinateur, moyen de stockage et dispositif emetteur correspondants
EP1172958A1 (fr) Système de communication, émetteur, mèthode de protection contre des erreurs de transmission
FR2790892A1 (fr) Procede et dispositif de controle de la synchronisation entre deux bus de communication serie d'un reseau

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20141128