Procédé et dispositif d'adaptation d'un flux de données scalable, produit programme d'ordinateur et équipement réseau correspondants.

1. DOMAINE DE L'INVENTION

Le domaine de l'invention est celui du traitement de flux de données scalables, aussi appelés flux de données hiérarchiques, fournis à des usagers par transport en temps réel sur un réseau de communication.

Plus précisément, l'invention concerne un procédé d'adaptation d'un flux de données scalable aux caractéristiques d'un réseau et/ou des usagers.

L'invention s'applique notamment, mais non exclusivement, à l'adaptation d'un flux vidéo scalable (par exemple un flux MPEG4-svc) aux caractéristiques de la liaison de l'usager et/ou de son terminal.

La technique MPEG4-SVC est notamment présentée dans les documents :

- JSVM 2.0 : Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG, N7084, Joint Scalable Video Model (JSVM) 2.0 Référence Encoding Algorithm Description, April 2005, Busan (Julien Reichel, Heiko Schwarz, Mathias Wien) ; et

- WD 2 : J. Reichel, H. Schwarz, M. Wien - Scalable Video Coding - Working Draft 2 -ISO/IEC JTC1/SC29/WG11, W7084, April 2005, Busan.

2. ART ANTéRIEUR 2.1 Les systèmes vidéo scalables (échelonnables)

Actuellement, la plupart des codeurs vidéo génèrent un seul flux compressé correspondant à l'intégralité d'une séquence codée. Chaque client souhaitant exploiter le fichier compressé pour décodage et visualisation doit pour cela télécharger (ou « streamer ») le fichier compressé complet. Or, dans un système hétérogène (par exemple Internet), tous les clients ne disposent pas du même type d'accès aux données : la bande passante, les capacités de traitement, les écrans des différents clients peuvent être très différents (par exemple, sur un réseau Internet, l'un des clients pourra disposer d'un débit ADSL à 1024 kb/s et d'un micro-ordinateur (PC) puissant alors que l'autre ne bénéficiera que d'un accès modem et d'un PDA).

Une solution évidente à ce problème consiste à générer plusieurs flux compressés correspondant à différents débits/résolutions de la séquence vidéo : c'est le simulcast. Cette solution est cependant sous-optimale en termes d'efficacité, et suppose de connaître à l'avance les caractéristiques de tous les clients potentiels. Plus récemment sont apparus des algorithmes de codage vidéo dit scalables (ou échelonnables), c'est-à-dire à qualité adaptable et résolution spatio-temporelle variable, pour lesquels le codeur génère un flux compressé en plusieurs couches, chacune de ses couches étant emboîtée dans la couche de niveau supérieur. Ces algorithmes sont aujourd'hui en cours d'adoption en amendement de MPEG4-AVC (appelé dans la suite de ce document : SVC).

De tels codeurs sont très utiles pour toutes les applications pour lesquelles la génération d'un seul flux compressé, organisé en plusieurs couches de scalabilité, peut servir à plusieurs clients de caractéristiques différentes, par exemple :

VOD ("Video On Demand" pour "vidéo à la carte"), accessibles aux terminaux de radiocommunication de type UMTS ("Universal Mobile Télécommunication

Service" pour "service de télécommunication mobile universel"), aux PC ou aux terminaux de télévision avec accès ADSL, etc. ; mobilité de session (par exemple reprise sur un PDA d'une session vidéo commencée sur un téléviseur, ou, reprise sur un mobile GPRS ("General Packet Radio Service" pour "service général de radiocommunication par paquets") d'une session commencée sur UMTS) ; continuité de session (dans un contexte de partage de la bande passante avec une nouvelle application) ; télévision haute définition, dans laquelle un encodage vidéo unique doit permettre de servir aussi bien des clients disposant d'une définition standard SD que des clients disposant d'un terminal à haute définition HD ; visioconférence, dans laquelle un encodage unique doit répondre aux besoins de clients disposant d'un accès UMTS et d'un accès Internet ; etc. 2.2 MPEG-4 SVC

Le modèle JSVM MPEG est décrit dans le document JSVM 2.0 déjà cité. Il est basé sur un codeur scalable fortement orienté vers des solutions de type AVC, dont la structure schématique d'un encodeur correspondant est présenté à la figure 1. Il s'agit d'une structure pyramidale. Les composantes d'entrée vidéo 10 subissent un sous- échantillonnage dyadique (décimation 2D par 2 référencée 11, décimation 2D par 4 référencée 12). Chacun des flux sous-échantillonnés subit ensuite une décomposition temporelle 13 de type MCTF ("Motion Compensated Temporal Filtering" pour "filtrage temporel compensé en mouvement"). Une version basse résolution de la séquence vidéo est codée 14 jusqu'à un débit donné qui correspond au débit maximum décodable pour la résolution spatiale basse (ce niveau de base est compatible AVC).

Les niveaux supérieurs sont ensuite codés 19 par soustraction du niveau précédent reconstruit et sur-échantillonné et codage des résidus sous forme d'un niveau de base, et éventuellement d'un ou plusieurs niveaux de rehaussement obtenus par codage multipasse de plans de bits (appelé FGS pour "Fine Grain Scalability", échelonnabilité à grain fin).

Selon cette approche, on distingue les informations de mouvement 17 et les informations de texture 18. Afin de réaliser une adaptation en débit, les informations de texture 18 sont codées à l'aide d'un schéma progressif : codage d'un premier niveau de qualité minimale (appelé « Base Layer » en anglais, ou Couche de Base) ; codage de niveaux de raffinement progressif (appelés « Enhancement Layer » en anglais, ou Couche de Réhaussement).

En référence à la figure 1 , les informations de texture 18 alimentent un module de codage de la couche de base de quantification 19. Les données codées, en sortie du module 19 servent à alimenter un bloc 21 de transformation spatiale et de codage entropique, qui travaille sur les niveaux de raffinement du signal. Les données en sortie du module 21 alimentent une interpolation 20 depuis le niveau de base. Cette interpolation est utilisée comme prédiction dans le module de codage 19 du niveau situé au-dessus. Un module de multiplexage 22 ordonne les différents sous-flux générés dans un flux de données compressé global 23.

Le flux compressé 23, en sortie du codeur, est structuré en unités de données appelées « NALU » (pour « Network Abstraction Layer Unit » en anglais). Les NALUs sont organisées en blocs d'unités de données appelés par la suite « AU » (pour « Access Units » en anglais). Une AU comprend l'ensemble des NALUs correspondant à un même instant temporel, c'est-à-dire possédant un même DTS (pour « Decoding Time

Stamp » en anglais, ou « information d'horodatage pour le décodage »), et appartenant donc à une même image. Chaque NALU est associée à une image issue de la décomposition spatio-temporelle, un niveau de résolution spatiale, et un niveau de quantification. Cette structuration en unités de données permet de réaliser une adaptation en débit et/ou résolution spatio-temporelle en supprimant les NALUs de résolution spatiale trop grande, ou de fréquence temporelle trop grande ou bien encore de qualité d'encodage trop grande.

2.3 Technique décrite dans la demande de brevet français FR2854018

La demande de brevet français publiée sous le n° FR2854018 décrit une technique de contrôle d'un trafic de paquets de données en entrée d'un réseau. Le trafic comprend N flux et/ou sous-flux associés chacun à un niveau de priorité, N > 2. Chacun des paquets est marqué avec le niveau de priorité associé au flux ou sous-flux auquel il appartient.

Dans une application particulière, le trafic comprend N sous-flux correspondant chacun à un des N niveaux hiérarchiques d'un flux hiérarchique ou d'un agrégat de flux hiérarchiques. Il s'agit par exemple d'un flux hiérarchique audio/vidéo comprenant les sous-flux suivants : un sous-flux audio, un sous-flux vidéo de base et un sous-flux vidéo de réhaussement.

L'objectif est de traiter les rafales pour maîtriser les congestions dans un réseau. En effet, les congestions affectent principalement les rafales, qui contiennent les informations les plus importantes d'un flux codé MPEG. Cette maîtrise est particulièrement adaptée pour les réseaux de type ADSL quand le débit nominal du flux est proche du débit maximum de la liaison.

Le principe général de cette technique connue consiste à mettre en œuvre un mécanisme de seau à jetons multi-niveau (MLTB, pour « Multi Layer Token Bucket »).

Chaque niveau du MLTB est utilisé pour traiter l'un des N niveaux de priorité. Chacun

des paquets subit un traitement selon un marquage correspondant à son niveau de priorité : il est accepté ou refusé selon qu'il est possible ou non de lui attribuer des jetons en fonction de son niveau de priorité. Les paquets acceptés sont placés dans une mémoire tampon (buffer) de paquets à émettre, qui forme un moyen de gestion d'une file d'attente. Les paquets refusés sont jetés ou, dans une variante de réalisation, placés dans le buffer après avoir été à nouveau marqués avec un niveau de priorité plus faible (c'est-à-dire après avoir été reclassés dans un niveau de priorité plus faible). Dans un exemple de réalisation, le MLTB précité est placé en entrée du buffer de paquets à émettre, pour le contrôle des rafales, et un seau à un seul niveau est placé en sortie, pour le lissage de trafic (TBTS, pour « Token Bucket Traffic Shaper »).

Un inconvénient de cette technique connue est que le reclassement d'un paquet est effectué indépendamment de la notion de dépendance entre paquets. En d'autres termes, on ne tient pas compte du fait qu'un paquet est reclassé pour le traitement des paquets suivants qui dépendent de ce paquet reclassé. Un autre inconvénient de la technique connue est que le reclassement d'un paquet implique un nouveau marquage de ce paquet (c'est-à-dire une modification de ce paquet).

Un autre inconvénient de la technique connue est qu'elle ne propose pas de solution optimale pour le reclassement d'un paquet dans un niveau de priorité plus faible.

Un autre inconvénient de la technique connue est qu'un paquet n'est traité que quand il se trouve en entrée du buffer de paquets à émettre. Elle ne propose aucun traitement sur les paquets déjà présents dans le buffer, et de ce fait ne nécessite pas de moyens de distinction entre paquets présents dans le buffer et ayant un même niveau de priorité (pas de pondération des paquets).

Encore un autre inconvénient de la technique connue est qu'elle n'envisage pas que les paquets sortant du buffer de paquets à émettre soient dirigés vers différents moyens de transmission en fonction de leurs niveaux de priorité. Ainsi, dans l'exemple de réalisation précité, le TBTS à un seul niveau ne sait pas gérer l'envoi simultané de plusieurs flux. De plus, l'indépendance entre le MLTB et le TBTS risque éventuellement

d'aboutir à une incompatibilité entre le remplissage et la sortie. La qualité du signal en sortie en serait altérée le temps de revenir à un fonctionnement normal. 3. EXPOSé DE L'INVENTION

Dans un mode de réalisation particulier de l'invention, il est proposé un procédé d'adaptation d'un flux de données scalable organisé en blocs d'unités de données comprenant chacun au moins une unité de données de base et au moins une unité de données de réhaussement, permettant de définir une pluralité de niveaux de qualité et de débit selon le nombre et le type d'unités de données utilisées, chaque unité de données étant initialement classée dans un niveau initial sélectionné parmi ladite pluralité de niveaux. Ce procédé met en œuvre un mécanisme de régulation tel que si une unité de données est reclassée dans un niveau de reclassement différent du niveau initial de ladite unité de données, toutes les unités de données qui dépendent au décodage de ladite unité de données reclassée sont également reclassées dans des niveaux de reclassement où toutes les unités de données indispensables à leur décodage sont accessibles. Le principe général de l'invention consiste donc à prendre en compte, de façon dynamique, l'impact du reclassement d'une unité de données sur le classement des autres unités de données qui dépendent de cette unité de données reclassée. Ainsi, on assure que le flux pourra être décodé correctement par le terminal de l'usager.

Il est à noter que le reclassement d'une unité de données n'implique pas un nouveau marquage (et donc aucune modification) de cette unité de données. Ce reclassement n'est donc pas porté par l'unité de données reclassée, et est géré entièrement et uniquement par le dispositif mettant en œuvre le procédé d'adaptation de l'invention. Toutefois, comme indiqué ci-après, dans un mode de réalisation particulier de l'invention, ce reclassement a pour conséquence un changement de moyen de transmission vers lequel l'unité de données reclassée est dirigée.

Il est également à noter que si le traitement d'une unité de données en entrée d'une mémoire tampon (buffer) de type FIFO entraîne un reclassement, il existe une première réalisation de l'invention dans laquelle c'est cette unité de données qui est reclassée (voir ci-après l'algorithme détaillé de « compensation simplifiée »), et une seconde réalisation de l'invention dans laquelle il peut y avoir une ou plusieurs unités de données reclassées parmi cette unité de données et l'ensemble des unités de données

déjà présentes dans la mémoire tampon (voir ci-après l'algorithme détaillé de « compensation complète »).

Avantageusement, chaque unité de données est dirigée vers un moyen de transmission associé au niveau dans lequel ledit mécanisme de régulation a au final classé ou reclassé ladite unité de données. M moyens de transmission différents sont utilisés, avec l≤M≤R, où R est le nombre de niveaux de qualité et de débit.

Ainsi, on modifie la répartition des unités de données soit dans un unique moyen de transmission, soit parmi plusieurs moyens de transmission. Dans le second cas, sans subir de nouveau marquage (c'est-à-dire sans être modifiées), les unités de données peuvent être redirigées d'un moyen de transmission à un autre, et on optimise ainsi l'utilisation des différents moyens de transmission.

Dans un exemple de réalisation avantageux, chaque niveau de régulation est associé à un moyen de transmission distinct (M=R).

Avantageusement, au moins un des niveaux de reclassement est tel que les unités de données qui y sont reclassées ne sont pas transmises. Il s'agit par exemple d'un niveau fictif formant poubelle, ne faisant pas partie de la pluralité de niveaux de qualité et de débit.

Selon une caractéristique avantageuse, ledit mécanisme de régulation comprend un algorithme de type seau à jetons multi-niveau (MLTB). En d'autres termes, on peut combiner le concept général de la présente invention (reclassement des unités de données en tenant compte de dépendance entre unités de données classées dans des niveaux différents) avec celui du MLTB, et ainsi bénéficier de tous les avantages liés au MLTB.

De façon avantageuse, une unité de données est reclassée si une ressource de débit disponible pour le niveau initial de ladite unité de données n'est pas suffisante.

Il est à noter qu'une unité de données peut également être reclassées pour d'autres raisons, par exemple liées aux ressources du terminal de l'utilisateur recevant le flux.

Avantageusement, lorsque le flux comprend une unité de données de référence, on annule, pour les unités de données qui suivent ladite unité de données de référence

dans le flux, les reclassements qui découlent de reclassements déjà effectués pour des unités de données qui précèdent ladite unité de données de référence dans le flux.

Avantageusement, ledit mécanisme de régulation gère toute modification dynamique d'une ressource de débit affectée à l'un desdits niveaux. Ainsi, on peut améliorer immédiatement (par exemple en temps réel) l'adaptation du flux.

Avantageusement, ledit mécanisme de régulation tient compte du temps réel d'émission des unités de données, pour gérer les ressources de débit affectées aux niveaux. De cette façon, on peut ajuster les ressources (par exemple les ressources de débit) affectées aux différents niveaux et prendre en compte indirectement les en-têtes de protocole de transport qui sont inconnus de la régulation.

De façon avantageuse, ledit mécanisme de régulation est tel qu'il gère selon un mode cumulé les ressources de débit affectées aux niveaux, de sorte qu'au moins une partie d'une ressource non utilisée d'un niveau peut profiter à un autre niveau dont la ressource de débit disponible n'est pas suffisante. Ceci permet d'améliorer encore l'adaptation du flux, sans dépasser le débit global prévu.

Selon une variante avantageuse, ledit mécanisme de régulation est tel qu'il gère selon un mode indépendant les ressources de débit affectées aux niveaux, de sorte que chaque ressource affectée à un niveau ne peut pas profiter à un autre niveau. Cette variante est plus simple à gérer. Dans une première réalisation avantageuse de l'invention, ledit mécanisme de régulation effectue une régulation simplifiée comprenant les étapes suivantes si la ressource de débit disponible pour le niveau initial sélectionné n'est pas suffisante : a) on choisit un nouveau niveau sélectionné moins prioritaire que le précédent niveau sélectionné ; b) si la ressource de débit disponible pour le nouveau niveau sélectionné est suffisante, alors ladite unité de données est reclassée dans le nouveau niveau sélectionné ; c) sinon : si le nouveau niveau n'est pas le moins prioritaire parmi ladite pluralité de niveaux de qualité et de débit, on revient à l'étape a), sinon ladite unité de données est reclassée dans un niveau fictif formant poubelle.

Cette première réalisation (régulation simplifiée) est simple à mettre en œuvre mais n'agit que lors de l'entrée des unités de données dans le dispositif mettant en œuvre le procédé de l'invention.

Dans une seconde réalisation avantageuse de l'invention, ledit mécanisme de régulation effectue une régulation complète comprenant les étapes suivantes si la ressource de débit disponible pour le niveau initial sélectionné n'est pas suffisante : a) ladite unité de données est classée dans le niveau initial sélectionné ; b) on choisit comme niveau courant le niveau sélectionné ; c) si la ressource de débit pour le niveau courant n'est pas dépassée, le niveau courant est considéré comme régulé et on passe à l'étape d) ; sinon : on sélectionne au moins une unité de données à reclasser parmi les unités de données classées dans le niveau courant, en fonction d'au moins un critère de reclassement prédéterminé, on reclasse ladite au moins une unité de données sélectionnée dans un niveau moins prioritaire que le niveau courant, et on réitère l'étape c) ; d) si le niveau courant n'est pas le moins prioritaire parmi ladite pluralité de niveaux de qualité et de débit, on choisit un nouveau niveau courant moins prioritaire que le précédent niveau courant puis on revient à l'étape b), sinon ladite régulation complète est terminée. Cette seconde réalisation (régulation complète) est plus complexe que la première mais offre l'avantage d'agir sur l'ensemble des unités de données déjà entrées et pas encore sorties du dispositif mettant en œuvre le procédé de l'invention. Comme détaillé par la suite, la régulation complète est plus performante que la régulation simplifiée car elle permet une meilleure réactivité et un lissage de la qualité du flux décodé.

Dans le cas de la seconde réalisation précitée, avantageusement, pour chaque unité de données, le procédé comprend en outre une étape d'affectation à ladite unité de données d'une pondération parmi une pluralité de pondérations possibles associées chacune à un rang de priorité relative à l'intérieur d'un niveau, ladite affectation étant effectuée en fonction d'au moins une règle d'affectation permettant d'établir une correspondance entre d'une part ladite au moins une information de marquage portée par

les unités de données et d'autre part l'une des pondérations possibles. En outre, ladite étape de sélection d'au moins une unité de données est effectuée au moins en fonction de la pondération des unités de données classées dans ledit niveau courant.

Le choix des pondérations est cohérent avec les dépendances entre unités de données. La prise en compte de la pondération facilite la sélection des unités de données en excès dans un niveau, suite à un reclassement.

Avantageusement, ladite étape de sélection d'au moins une unité de données est effectuée avec le double critère suivant : la pondération la plus forte, parmi des pondérations affectées à chacune des unités de données ; et et pour une même pondération, la référence temporelle la plus récente.

L'invention s'applique avantageusement dans le cas où ledit flux de données scalable est un flux vidéo scalable. Dans ce cas, le classement initial de chaque unité de données dans un niveau initial est fonction d'au moins une information de marquage portée par ladite unité de données et comprenant un n-uplet d'au moins deux indicateurs parmi les indicateurs appartenant au groupe comprenant : un indicateur de priorité (P) ; un indicateur de dépendance (D), relatif à une résolution spatiale ; un indicateur de résolution temporelle (T) ; et- un indicateur de qualité et/ou de complexité (Q).

Ainsi, ainsi on exploite les distinctions entre unités de données (NALUs) existant du fait du marquage de chaque unité de données avec un quadruplet d'indicateurs {P, D, T, Q} issus d'un codeur MPEG4-svc.

De façon avantageuse, le procédé est mis en œuvre par au moins un des équipements réseau suivants : serveur de flux et nœud intermédiaire d'un réseau de transmission.

Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ce produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précité, lorsque ledit programme est exécuté sur un ordinateur.

Dans un autre mode de réalisation, l'invention concerne un dispositif d'adaptation d'un flux de données scalable organisé en blocs d'unités de données comprenant chacun au moins une unité de données de base et au moins une unité de données de réhaussement, permettant de définir une pluralité de niveaux de qualité et de débit selon le nombre et le type d'unités de données utilisées, chaque unité de données étant initialement classée dans un niveau initial sélectionné parmi ladite pluralité de niveaux. Ce dispositif comprend des moyens de régulation tels que, si une condition de reclassement est vérifiée pour une unité de données, alors ladite unité de données est reclassée dans un niveau de reclassement moins prioritaire que le niveau initial de ladite unité de données, et toutes les unités de données qui dépendent au décodage de ladite unité de données reclassée sont également reclassées dans des niveaux de reclassement où toutes les unités de données indispensables à leur décodage sont accessibles.

Plus généralement, le dispositif d'adaptation selon l'invention comprend des moyens de mise en œuvre du procédé d'adaptation tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation).

Dans un autre mode de réalisation, l'invention concerne un équipement réseau comprenant un dispositif d'adaptation tel que précité.

Avantageusement, l'équipement réseau appartient au groupe comprenant des serveurs de flux et des nœud intermédiaire d'un réseau de transmission. 4. LISTE DES FIGURES

D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation préférentiel), et des dessins annexés, dans lesquels : la figure 1, déjà décrite en relation avec l'art antérieur, présente un synoptique d'un encodeur générant un flux MPEG4-svc (flux vidéo scalable) ; la figure 2 présente un synoptique d'un dispositif d'adaptation de flux de données scalable selon un mode de réalisation de l'invention ; - la figure 3 présente les trois axes de scalabilité d'un flux MPEG4-svc ;

la figure 4 présente un exemple de dépendances entre des NALUs de différents niveaux de codage ; la figure 5 illustre le principe de fonctionnement du buffer de régulation et du buffer de réserve apparaissant sur la figure 2 ; - la figure 6 présente une vue plus détaillée du module de régulation apparaissant sur la figure 2 ; la figure 7 illustre une structure de données à double référencement, entre le buffer de régulation et le MLTB, selon un mode de réalisation particulier de l'invention ; - les figures 8 et 9 illustrent deux modes de fonctionnement, indépendant et cumulé respectivement, du MLTB mis en œuvre dans le module de régulation apparaissant sur la figure 2 ; la figure 10 présente un autre exemple de dépendances entre différents niveaux de codage ; - la figure 11 présente un organigramme d'un mode de réalisation particulier d'un algorithme de régulation simplifiée mise en œuvre par le module de régulation apparaissant sur la figure 2 ; les figures 12 et 13 présentent un organigramme d'un mode de réalisation particulier d'un algorithme de régulation simplifiée mise en œuvre par le module de régulation apparaissant sur la figure 2 (la figure 13 détaille l'étape d'ajustement des niveaux de régulation, qui apparaît sur la figure 12) ; et la figure 14 présente un exemple de répartition des NALUs dans les différents niveaux de régulation. 5. DESCRIPTION DéTAILLéE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 5.1 Dispositif (figure 2)

Comme illustré sur la figure 2, dans un mode de réalisation particulier, le dispositif d'adaptation de flux de données scalable selon l'invention 1 comprend les éléments suivants (qui sont décrits en détail par la suite) :

une mémoire tampon de réserve 3 (appelée ci-après buffer de réserve), qui reçoit un flux MPEG4-svc 2 ; une mémoire tampon de régulation 4 (appelée ci-après buffer de régulation), dont l'entrée est reliée à la sortie du buffer de réserve 3 ; - une table de classement statique 5 ; une table de classement dynamique 6 ; un module d'ajustement des ressources 7 ; un module de régulation 8, permettant de garantir les différents débits demandés (flèche référencée 26) pour les différents niveaux de régulation ; et - un module d'aiguillage 9, permettant d'aiguiller chacune des NALUs présentes en sortie du buffer de régulation 4 en fonction du niveau de régulation dans lequel le module de régulation 8 les a classé. Le module d'aiguillage génère plusieurs sous-flux 24 correspondant chacun à l'un des niveaux de régulation.

Dans un exemple de réalisation, au moins certains des moyens précités 3 à 9 compris dans le dispositif d'adaptation sont des moyens logiciels, résultant de l'exécution d'un programme d'ordinateur par une unité de traitement. Dans ce cas, le dispositif comprend une mémoire non volatile stockant un programme d'ordinateur mettant en oeuvre le procédé d'adaptation de flux selon l'invention, et une unité de traitement (microprocesseur par exemple) pilotée par ce programme d'ordinateur. A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans une mémoire volatile avant d'être exécutées par le processeur de l'unité de traitement.

5.2 Tables de classement (figures 3 et 4)

Les tables de classement 5 et 6 contiennent les différentes configurations permettant d'effectuer la répartition des NALUs dans les différents niveaux de la régulation. Dans les faits, elles contiennent des correspondances entre des éléments présents dans les informations supplémentaires des données et les niveaux de régulation gérés dans le module de régulation 8.

Dans le cas des NALUs utilisées en MPEG4-svc, ces éléments sont des indicateurs présents dans l'entête de chaque NALU, sous la forme d'un quadruplet : {P,

D, T, Q} où :

P indique la priorité ;

D indique la dépendance (sur-ensemble de la résolution spatiale S) ; T indique la résolution temporelle ; et Q indique la qualité et/ou la complexité. Le classement est donc réalisé à partir des propriétés de scalabilité d'un flux

MPEG4-svc.

Comme illustré sur la figure 3, un flux MPEG4-svc présente trois axes de scalabilité possibles : axe spatial S (résolution de l'image), axe fréquentiel T (fréquence des images) et axe Q, aussi appelé axe SNR (qualité), traduisant le niveau de détail obtenu par la troncature des coefficients issus du codage. Chaque NALU est représentée par un cadre.

La figure 4 présente un exemple de dépendances entre des NALUs de différents niveaux de codage. Dans cet exemple, on suppose que : le premier niveau de régulation (niveau de base B) est associé aux codages QCIF15 et QCIF30 ; le deuxième niveau de régulation (premier niveau de réhaussement Rl) est associé au codage CIF 15 ; et le troisième niveau de régulation (second niveau de réhaussement R2) est associé au codage CIF30. Chaque niveau de codage comprend, pour une résolution spatiale/temporelle donnée (par exemple CIF/15Hz), des NALUs de différentes qualités SNR. On peut donc dire que chaque niveau de codage comprend une pluralité de niveaux SNR. En d'autres termes, un niveau de codage correspond à une gamme de débit qu'il est possible d'ajuster en prenant plus ou moins de NALUs ayant différentes SNR. La figure 4 montre les dépendances entre NALUs pour accéder à un niveau précis de qualité. Dans cet exemple, le niveau de codage CIF30 s'appuie sur le niveau de codage CIF 15, qui lui-même s'appuie sur le niveau de codage QCIF 15 ou QCIF30.

Dans certains cas, tous les niveaux SNR d'un niveau de codage ne sont pas systématiquement utilisés par les niveaux de codage de qualité supérieure. Par exemple, sur la figure 4, parmi les niveaux SNR du niveau de codage CIF 15 : ceux qui sont utilisés par le niveau de codage CIF30 sont référencés 41 et ceux qui ne le sont pas 42.

Dans les exemples de tables présentés ci-dessous, les NALUs non nécessaires pour les niveaux au-dessus sont identifiées par une pondération élevée (valeur 255).

Quand un besoin de reclassement apparaît, cette valeur élevée a pour effet, dans le cas d'une régulation complète, de favoriser leur rejet (reclassement dans le niveau fictif formant poubelle) ou leur reclassement dans un niveau de priorité très faible.

Par ailleurs, la demande de brevet n° FR0507690 précise que plusieurs modes de replis (aussi appelés chemins de filtrage) sont possibles. Il est à noter que, dans le mode de réalisation de la présente invention, les tables de classement statique 5 et dynamique 6 correspondent à un mode de repli donné. Par exemple, les exemples de tables ci- dessous accordent la priorité à la fluidité des images (QCIF 15 et QCIF30 en premier niveau) sur la résolution de l'affichage (CIF 15 en deuxième niveau). Un autre mode de repli permettrait d'accorder la priorité à la résolution de l'affichage (QCIF 15 et CIF 15 en premier niveau et QCIF30 en deuxième niveau). Dans les exemples de tables ci-dessous, la présence simultanée du QCIF30 et du QCIF 15 dans le premier niveau est justifiée par leur nécessité pour décoder le CIF30.

Il est bien sûr possible de changer de mode de repli, et donc de table de classement statique (de référence), sur l'arrivée d'une image de référence. Dans ce cas, la table de classement dynamique n'est pas mise à jour avec la précédente table de classement statique, mais avec la nouvelle table de classement statique. Ensuite, l'adaptation du flux vidéo au(x) débit(s) modifie cette table de classement dynamique comme indiqué ci-dessus.

Les tables de classement contiennent donc une liste de correspondances sous la forme : {P, D, T, Q} -> (niveau de régulation, pondération au sein du flux). En d'autres termes, chaque type de NALU, défini par un quadruplet {P, D, T, Q} particulier, est associé à une information « niveau de régulation » et à une information « pondération ».

L'information « niveau de régulation » correspond au niveau de régulation dans lequel sera affectée la NALU. L'information « pondération au sein du flux » permet de pouvoir ordonner les NALUs au sein d'un même niveau de régulation. Cette information de pondération est indépendante du classement dans un niveau de régulation. Dans un cas particulier de réalisation, cette information de pondération est égale à la valeur P de l'entête NALU.

La table de classement statique 5, dite de référence, est fournie avec des métadonnées 25 comprises dans les données d'accompagnement du contenu audiovisuel. Elle contient les niveaux de classement définis par le fournisseur du contenu.

La table de classement dynamique 6 a pour but de prendre en compte les dépendances entre les NALUs. Elle intervient en cas de modification du classement par le module de régulation. Son objectif est de maintenir la cohérence du flux. étant donné que la régulation de débit peut placer des NALUs du niveau N dans un niveau supérieur (ou les supprimer : classement dans un niveau fictif formant poubelle), cette table de classement dynamique permet d'éviter de placer dans le niveau N des NALUs dont le décodage s'appuie sur des NALUs placées en niveau N+l (ou supprimées). Cette table de classement dynamique peut ne pas contenir les éléments de pondération.

La table de classement dynamique est réinitialisée avec les valeurs de la table de classement statique à chaque image de référence (image IDR ou I).

Le contenu des tables de classement statique 5 et dynamique 6 n'est pas statique. Les correspondances évoluent au fur et à mesure de la régulation effectuée par le module de régulation, afin de prendre en compte toutes évolutions des contraintes. C'est à un module externe, de décision, de modifier dynamiquement leur contenu. En règle générale, à tout moment une NALU entrante de valeur {P, D, T, Q} peut être reclassée dans un niveau N+k moins prioritaire, avec k>l, afin de limiter le débit du niveau N. La mise à jour de la table de classement dynamique est telle que tous les NALU qui entrent ensuite dans le buffer de régulation et qui dépendent au décodage de cette NALU reclassée seront classées dans un niveau N+m, avec m>k et N+m≤Nmax où Nmax est le dernier niveau possible (c'est-à-dire le niveau de plus faible priorité). Seul le niveau fictif formant poubelle est supérieur à Nmax. Le classement d'une NALU du niveau N vers le niveau N-I n'a pas de sens dans la mesure où les NALUs antérieures du flux vidéo indispensables au décodage de cette

NALU n'y sont pas tous présentes. En d'autres termes, le niveau N-I est indépendant du niveau N, alors que le niveau N est dépendant du niveau N-I (principe du hiérarchique).

La table suivante présente un exemple de table de classement statique pour une régulation à trois niveaux. La colonne « Cible » 51 présente à titre informatif une possibilité de caractéristique de flux (niveau de codage). Cible I P I D I T I Q I Niveau | Pondération j

La table suivante présente un exemple un exemple de table de classement dynamique selon l'invention, obtenue par mise à jour de l'exemple de table statique ci- dessus après régulation du premier niveau de régulation. On observe dans cet exemple que cette mise à jour porte sur deux types de NALUs : les NALUs ayant un PDTQ {3,0,1,2} (cinquième ligne) devront être reclassées dans le niveau 4 de régulation (niveau fictif formant poubelle) ; et les NALUs ayant un PDTQ {2,0,1,1} (douzième ligne) devront être reclassées dans le niveau 2 de régulation.

5.3 Buffer de régulation et buffer de réserve (figure 5)

La figure 5 illustre le principe de fonctionnement du buffer de régulation et du buffer de réserve.

Le buffer de régulation 4 contient les données provenant directement de la source. Il sert essentiellement à garder l'ordre d'arrivée des données afin de faciliter leurs traitements lors de l'émission. En effet, toutes les données ayant le même DTS doivent être transmises au même moment, cette information cadençant l'émission.

C'est une file FIFO, dont la flèche référencée 70 indique le sens. La contrainte associée étant le calcul de débit de chaque niveau d'adaptation de la régulation, sa taille doit être fixe tout au long du processus et il doit être constamment rempli pour pouvoir effectuer ce calcul. La notion de remplissage est effectuée sur la base des informations temporelles des données. Ainsi, pour les données contenues dans le buffer de régulation, on peut dire que : DTSi - DTSo = constante, avec DTSi la valeur DTS de la dernière AU entrée dans le buffer de régulation, et DTSo la valeur DTS de la première AU à sortir du buffer de régulation. En d'autres termes, dans un fonctionnement normal, quand le buffer de régulation est normalement rempli, il contient un nombre constant d'images. Afin de synchroniser les entrées et sorties, le buffer de réserve 3 est ajouté en entrée du buffer de régulation 4. La présence de cette réserve permet aussi le regroupement des NALUs pour former les AU. En effet, les données sont traitées au niveau AU dans le buffer de régulation 4, mais au niveau NALU dans le module de régulation 8. Cette réserve permet également d'introduire le problème de suralimentation et de sous-alimentation du buffer de régulation. La suralimentation correspond à une entrée d'un nombre de données plus importante que le buffer de régularisation ne peut consommer. Dans ce cas, les données supplémentaires seront stockées dans la réserve, jusqu'à saturation de celle-ci. Enfin, si la réserve est considérée comme ayant atteint sa taille maximale, les données ne seront plus acceptées et rejetées du système. La sous- alimentation correspond à une consommation des données plus rapide que l'entrée des données dans le buffer de régulation. Le buffer de régulation n'a donc pas sa taille optimale, et le calcul de débit reste possible, mais sur une base incomplète car toutes les données attendues ne sont pas présentes. Cependant, le fonctionnement est toujours possible, tant que le buffer de régulation n'est pas complètement vide car il y a toujours des données à envoyer sur le réseau en sortie. éventuellement, l'émission s'arrête s'il n'y a plus de données, seul ce cas pose problème, car il ne sera pas possible de récupérer le débit perdu. 5.4 Module de régulation (figures 6 à 14) 5.4.1 Principe général de la régulation

Afin de garantir les différents débits demandés, le module de régulation 8 est implémenté. Il : reçoit en entrée les références des NALUs contenues dans le buffer de régulation

4 suivant un classement pré-établi ; - régule les NALUs entre ses niveaux afin de garantir les débits demandés ; met à jour la table de classement dynamique 6. En effet, lors d'un reclassement d'une NALU d'un niveau N à N+k, il faut que les données en dépendances soient également reclassée au moins à ce niveau N+k.

Un ajustement des ressources peut être établi en fonction des débits ciblés et des retours d'informations (flèche référencée 27 sur la figure 2) provenant de l'émission. Cet ajustement est effectué par le module d'ajustement des ressources 7 qui peut, par exemple, affiner les débits pour prendre en compte les entêtes des NALUs émises.

Seules les NALUs présentes dans le buffer de régulation 4 sont gérées dans le module de régulation 8. Le module d'aiguillage 9 dirige les NALUs en sortie du buffer de régulation.

Chaque NALU est aiguillée vers le moyen de transmission correspondant au niveau de régulation dans lequel elle est classée. à chaque niveau de régulation correspond par exemple un moyen de transmission différent, afin de séparer les niveaux. Cette différenciation peut se faire au niveau des adresses IP/port, marquage TOS, piste au sein d'un multiplexage... Dans une variante, il existe également plusieurs moyens de transmission mais plusieurs niveaux de régulation sont associés à un même moyen de transmission. Dans encore une autre variante, il existe un unique moyen de transmission auquel sont associés tous les niveaux de régulation. 5.4.2 Régulation par un algorithme MLTB Pour effectuer la régulation, le module de régulation 8 met par exemple en œuvre un mécanisme de régulation comprenant un algorithme de type seau à jetons multi- niveau (appelé MLTB par la suite).

Dans l'exemple de la figure 6, le MLTB gère trois niveaux de régulation Nl, N2 et N3. Les flèches référencées 81, 82 et 83 symbolise les ressources de débit affectées à chacun des niveaux de régulation. La flèche référencée 84 la régulation entre les niveaux

Nl et N2. La flèche référencée 85 la régulation entre les niveaux N2 et N3.

Optionnellement, le MLTB permet un changement dynamique du débit d'un niveau de régulation quelconque (sans modifier les débits des autres niveaux). Ainsi, le changement du débit d'un niveau modifie instantanément les jetons alloués à ce niveau, adaptant ainsi la régulation à la nouvelle consigne de débit. Les données au sein du MLTB sont des références (pointeurs) vers le buffer de régulation. La plus petite information est la NALU. L'intégrité des AU et les notions temporelles ne sont gérées qu'indirectement via le buffer de régulation. Seule la notion de jeton est utilisée dans les calculs du MLTB.

Par rapport au contenu du buffer de régulation, les données présentent dans la réserve ne sont pas prises en compte dans le MLTB.

Comme détaillé ci-après, le MLTB peut fonctionner en mode indépendant ou cumulé. 5.4.2.1 Organisation des données entre le buffer de régulation et le MLTB

On présente maintenant, en relation avec la figure 7, une structure de données à double référencement, entre le buffer de régulation et le MLTB, selon un mode de réalisation particulier de l'invention.

Chaque niveau du MLTB contient des premiers pointeurs vers les NALUs stockées dans le buffer de régulation 4. Pour mémoire, chaque NALU contient un entête

(dont les indicateurs {P, D, T, Q}) et des données du codage. Sur la figure 7, les premiers pointeurs du niveau Nl sont référencés 9I ₁ , 9I ₂ ,..., ceux du niveau N2 sont référencés 92 _ls 92 ₂ ,... etc.

Dans chaque niveau du MLTB, les premiers pointeurs de NALUs sont classés par ordre de pondération (comme symbolisé par la flèche référencée 93). Pour un même niveau de pondération, les pointeurs vers les NALUs de DTS les plus anciens sont placés en premier. Cette organisation permet de trouver immédiatement les NALUs les moins prioritaires (dans le cas de la régulation complète, décrite ci-dessous). L'ajout de nouvelles NALUs dans le MLTB respecte cette règle.

Les données du buffer de régulation sont ordonnées par AU, et suivant le DTS

(comme symbolisé par la flèche référencée 94). L'ordre des NALUs au sein d'une AU est indifférent pour la régulation effectuée par le MLTB (le MLTB contient l'ordre de

priorité). Ceci permet de s'affranchir de l'ordre d'arrivée des NALUs, par exemple en cas de coopération de réseaux avec des temps de transferts différents.

Outre les données effectives, le buffer de régulation 4 contient des seconds pointeurs vers les premiers pointeurs au sein du MLTB. Cette structure à double référencement (premiers et seconds pointeurs), symbolisée par les flèches référencées

95, permet de retrouver efficacement les NALUs d'une AU qui sont réparties dans le MLTB. Il est possible de retrouver les informations des NALUs au sein du buffer de régulation, à partir des premiers pointeurs compris dans le MLTB, et inversement, de retrouver la position des NALUs au sein du MLTB, à partir des seconds pointeurs compris dans le buffer de régulation.

5.4.2.2 Calcul des jetons

Dans le MLTB, un seau de jetons est affecté pour chaque niveau de régulation, avec un nombre de jetons fixé en fonction du débit demandé pour ce niveau de régulation et la taille du buffer de régulation. On utilise par exemple l'une des deux manières suivantes de calculer les jetons libérés :

Jetons libérés = taille AU : le MLTB se comporte comme une moyenne simple sur le buffer de régulation, et le débit correspond au niveau AU ;

Jetons libérés = débit sortie * temps sortie AU : le MLTB intègre les entêtes IP dans son calcul. Le débit correspond au niveau IP.

Ces deux manières de calculer le débit peuvent s'appliquer indifféremment au mode indépendant en niveaux, ou au mode cumulé qui prend en compte les jetons disponibles dans les niveaux d'indices inférieurs (et donc de priorités supérieures).

Les figures 8 et 9 illustrent ces deux modes de fonctionnement, indépendant et cumulé respectivement.

Cl et C2 représentent les débits cibles des niveaux respectifs 1 et 2. Dl et D2 représentent les débits effectifs.

Dans le mode indépendant (figure 8), nous avons les relations suivantes, relatives aux contraintes de débits : Dl < Cl, et D2 < C2. Les contraintes de débits montrent clairement une sous-utilisation de la bande passante.

Dans le mode cumulé (figure 9), le niveau 2 peut profiter des réserves du niveau 1 pour améliorer la qualité de sa transmission. Nous avons donc les relations suivantes : Dl < Cl, et Dl + D2 < C1+C2. La contrainte de débit globale est respectée, optimisant ainsi la qualité par une meilleure utilisation de la bande passante. Le mode cumulé peut être utilisé dans un autre mode de régulation que le

MLTB. En effet, il suffit que la régulation puisse utiliser, pour chaque niveau, les ressources disponibles du niveau inférieur.

Dans certains cas, il est intéressant d'utiliser un MLTB fonctionnant avec un mélange de modes indépendants et cumulés. Ainsi, dans l'exemple illustré sur la figure 10, d'un flux de base SD (de débit cible Cl) disposant de flux de rehaussement HD en mode 72Op (de débit cible C2) et d'un autre mode de rehaussement HD en mode 1080i (de débit cible C3), ces deux modes de rehaussement sont indépendants. Les contraintes de débit sont alors : D1 + D2 ≤ C1 + C2 D1 + D3 ≤ C1 + C3

II serait aussi possible d'ajouter un mode 1080p (débit cible C4) basé sur les modes 72Op et 1080i tel que : Dl + D2 + D3 + D4 < Cl + C2 + C3 + C4. 5.4.2.3 Organisation des données dans le MLTB

Dans l'utilisation de données provenant de flux SVC, certaines NALUs sont prioritaires. De ce fait, les NALUs les moins prioritaires seront les premières à être reclassées. Pour définir l'ordre de reclassement, l'information de pondération présente dans les tables de classement est utilisée prioritairement. 5.4.3 Régulation complète et régulation simplifiée

On présente ci-après deux types de régulation pouvant être effectuées en utilisant un algorithme de type MLTB : une régulation complète, mettant en oeuvre l'ensemble des NALUs contenues dans le buffer de régulation pour chaque niveau de régulation ; et une régulation simplifiée n'agissant qu'à l'entrée du buffer de régulation.

Dans les deux cas, le cadencement se fait lors de la sortie d'une AU. Ainsi, pour respecter la contrainte de taille DTS fixe du buffer de régulation dans le cas normal

d'utilisation, une nouvelle AU est entrée dans le buffer de régulation lors de la sortie d'une AU. La régulation peut alors être effectuée.

Lors de la sortie d'une AU, le MLTB indique la répartition des NALUs de cette

AU dans chacun des niveaux de régulation (niveaux de débits), pour calculer l'ajustement des ressources par niveau de régulation.

5.4.3.1 Régulation simplifiée

La régulation simplifiée n'agit que lors de l'entrée des données (AU regroupant des NALUs) dans le buffer de régulation. Lorsque la quantité de jetons libérés par la sortie de données du buffer de régulation ne suffit pas pour permettre l'entrée d'une nouvelle donnée en ne prenant en compte que l'opération de classement, cette donnée est reclassée dans les niveaux supérieurs du MLTB. Pour prendre en compte les problèmes de dépendances, la table de classement dynamique est mise à jour.

On présente maintenant, en relation avec l'organigramme de la figure 11, un mode de réalisation particulier de l'algorithme de régulation simplifiée. Dans une étape 131, un événement provoque la sortie d'une AU du buffer de régulation. Dans une étape 132, les jetons qui étaient associés aux NALUs de cette AU redeviennent disponibles pour le MLTB (selon le calcul de jetons détaillé ci-dessus).

Dans une étape 133, une AU prise dans le buffer de réserve est importée dans le buffer de régulation. Dans ce scénario standard, à une AU sortie correspond une AU entrée. Le classement est appliqué séquentiellement à chaque NALU de l'AU entrée, grâce aux jetons disponibles dans le MLTB.

Ensuite, dans une étape 134, on détecte si toutes les NALUs composant l'AU entrée ont été traitées. Dans l'affirmative, on passe à l'étape de fin 135. Sinon, dans une étape 136 on prend une NALU à traiter, puis dans une étape 137 on détecte si les jetons disponibles du niveau de régulation N demandé (d'après la table de classement dynamique) suffisent pour la NALU.

Si les jetons disponibles du niveau N suffisent, alors dans une étape 138 la

NALU est classée dans le niveau N et les jetons du niveau N lui sont attribués. Puis on revient à l'étape 134. Si les jetons disponibles du niveau N ne suffisent pas pour la NALU, alors dans une étape 139 on choisit le niveau de régulation N+l, de priorité plus faible que le

niveau N. Puis, dans une étape 1310, on détecte si les jetons disponibles du niveau de régulation N+l suffisent pour la NALU : si les jetons disponibles du niveau N+l suffisent, alors on passe à l'étape 1311 de modification de la table de classement dynamique (pour prendre en compte les dépendances) avant de passer à l'étape 138 afin que la NALU soit reclassée dans le niveau N+l et les jetons du niveau N+l lui soient attribués ; si les jetons disponibles du niveau de régulation N+l ne suffisent pas pour la NALU, on revient à l'étape 139. Le dernier passage par l'étape 139 consiste à choisir le niveau de régulation fictif formant poubelle, et dans ce cas le test de l'étape 1310 qui suit est considéré comme vérifié et on passe donc à l'étape 1311.

L'avantage de cette régulation simplifiée est la faible complexité de l'algorithme. Elle n'agit que sur les données arrivants dans le système et est uniquement basée sur la consultation et éventuellement une mise à jour des tables de classements. 5.4.3.2 Régulation complète La régulation complète mets en œuvre l'intégralité de la régulation. Lors de l'entrée d'une nouvelle AU, celle-ci est mise dans le MLTB à partir de la table de classement. La régulation se fait ensuite sur l'ensemble du contenu du MLTB en sélectionnant les NALUs les plus appropriées à un reclassement. En effet, lors d'un besoin de reclassement, il y a peut-être une NALU dans le système qui est plus à même d'être reclassée que la nouvelle AU.

On présente maintenant, en relation avec l'organigramme de la figure 12, un mode de réalisation particulier de l'algorithme de régulation complète.

Dans une étape 141, un événement provoque la sortie d'une AU du buffer de régulation. Dans une étape 142, les jetons qui étaient associés aux NALUs de cette AU redeviennent disponibles pour le MLTB. Dans une étape 143, une AU prise dans le buffer de réserve est importée dans le buffer de régulation.

Ensuite, dans une étape 144, on détecte si toutes les NALUs composant l'AU entrée ont été traitées. Dans l'affirmative, on passe à l'étape de fin 145. Sinon, dans une étape 146 on prend une NALU à traiter, puis dans une étape 147 on détecte si les jetons disponibles du niveau de régulation N demandé (d'après la table de classement dynamique) suffisent pour la NALU.

Si les jetons disponibles du niveau N suffisent, alors dans une étape 148 la NALU est classée dans le niveau N et les jetons du niveau N lui sont attribués.

Si les jetons disponibles du niveau N ne suffisent pas pour la NALU, alors dans une étape 149 on effectue une régulation de l'ensemble des NALUs de tous les niveaux de régulation du MLTB, puis dans une étape 1410 on modifie la table de classement dynamique (afin de prendre en compte les dépendances) avant de revenir à l'étape 144.

On présente maintenant, en relation avec la figure 13, le détail de l'étape 149 d'ajustement des niveaux de régulation (régulation de l'ensemble des NALUs de tous les niveaux de régulation du MLTB). Dans une étape 151, la NALU en entrée est ajoutée au niveau N. Le nombre de jeton disponible dans ce niveau de régulation est alors susceptible de devenir négatif si, avant l'ajout, il n'y avait pas assez de jetons disponibles. La NALU est malgré tout ajoutée car elle doit être prise en compte dans la recherche à venir.

Ensuite, dans une étape 152, on détecte si tous les niveaux de régulation à traiter (à savoir le niveau N et les niveaux de priorité inférieure) l'ont été. Dans l'affirmative, on passe à l'étape de fin 153. Sinon, dans une étape 154 on prend un nouveau niveau de régulation courant à traiter (on commence par le niveau N puis à chaque itération on passe au niveau suivant N+l de priorité inférieure), puis dans une étape 155 on détecte si le nombre de jetons disponibles pour le niveau courant est correct (c'est-à-dire supérieur ou égal à zéro).

Si le nombre de jetons disponibles pour le niveau courant est correct, le niveau est considéré comme régulé et on revient à l'étape 152.

Si le nombre de jetons disponibles pour le niveau courant est incorrect, on passe à une étape 156 de sélection de la NALU, parmi celles classées dans le niveau de régulation courant, ayant le moins de dépendance. Un critère de sélection consiste à prendre la NALU ayant la pondération la plus élevée et le DTS le plus récent. Dans une étape 157, la NALU sélectionnée est reclassée au niveau N+l, libérant ainsi les jetons qui lui étaient associés. Puis on revient à l'étape 155, pour vérifier si le reclassement de cette NALU a suffi.

Le dernier passage par l'étape 157 consiste en un reclassement dans le niveau de régulation fictif formant poubelle, et dans ce cas le test de l'étape 155 qui suit est considéré comme vérifié et on revient donc à l'étape 152.

La figure 14 présente un exemple de répartition des NALUs (représentés par des carrés noirs) dans trois niveaux de régulation possibles Nl, N2, N3 et un niveau de régulation fictif formant poubelle N4.

Chaque AU est représentée par une colonne de NALUs pouvant avoir un nombre différent de NALUs. Lors de la régulation, les NALUs sont sélectionnées pour être affectées à un niveau de régulation. Le nombre de NALUs classés dans un niveau de régulation peut varier d'un DTS à l'autre, en fonction du débit affecté à ce niveau de régulation. Ainsi, dans cet exemple, on note une diminution du débit affecté au niveau Nl, entre les deuxième et troisième DTS (en partant de DTSo), puis une augmentation de ce débit entre les cinquième et sixième DTS. De façon complémentaire, on note une augmentation du débit affecté au niveau N2, entre les deuxième et troisième DTS, puis une diminution de ce débit entre les cinquième et sixième DTS. En revanche, le débit affecté au niveau N3 reste constant.

Lors d'un changement de débit, les dépendances sont prises en comptes lors de la sélection des NALUs. Ainsi, une NALU n'aura pas de dépendance vis-à-vis d'une autre NALU placée dans un niveau supérieur (de priorité plus faible). La flèche en pointillé référencée 161 illustre l'ordre de parcours pour le reclassement des NALUs. Les NALUs reclassées en premier sont celles ayant la pondération la plus forte et le DTS le plus récent (proche de DTSi).

Chacune des flèches référencées 162 et 163 illustre la dépendance entre deux NALU. On rappelle qu'une NALU d'un niveau de régulation N ne peut dépendre que d'une NALU du même niveau de régulation N ou d'un niveau de régulation N' moins prioritaire (N '>N).

Cette figure 14 illustre également le (re)classement de deux NALUs, conformément à l'exemple de table de classement dynamique ci-dessus (voir les cinquième et douzième lignes), suite à une réduction du débit affecté au niveau Nl : - IaNALU référencée 164 est (re)classée dans le niveau 2 ; et

IaNALU référencée 165 est (re)classée dans le niveau 4 (poubelle).

La complexité de l'algorithme de la régulation complète est accrue par rapport à celui de la régulation simplifiée, car il doit consulter, voire modifier, l'ensemble des NALUs contenues dans le buffer de régulation, et ce pour chaque introduction d'une nouvelle donnée. L'avantage de la régulation complète est la réactivité. En effet, toutes les données présentes dans le système sont régulées lors du changement des contraintes. Ainsi, la donnée transmise juste après le changement respectera déjà ces nouvelles contraintes.

Un autre avantage de cette régulation complète est de lisser la qualité du flux décodé, en régulant le classement des NALUS sur la totalité du buffer de régulation. L'ordre de sélection des NALUs reclassées optimise la qualité en suivant un ordre qui respecte les dépendances.