Brevet FR2889017A1 — publié le 20070126

Procédés de filtrage, de transmission et de réception de flux vidéo scalables, programmes, serveur, noeud intermédiaire et terminal correspondants. 1. domaine de l'invention Le domaine de l'invention est celui du traitement de signaux vidéo, et plus particulièrement de séquences vidéo compressées sous forme échelonnable, ou scalable. Plus précisément, l'invention concerne l'amélioration de l'exploitation d'un flux scalable, notamment, mais non exclusivement, dans le cadre du schéma de codage actuellement développé dans MPEG4-SVC. Cette 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 Reference Encoding Algorithm Description, April 2005, Busan (Julien Reichel, Heiko Schwarz, Mathias Wien) ; et - WD: 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 spatiotemporelle 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: - service de vidéo à la demande, ou VOD (terminaux cibles: UMTS, PC ADSL, TV ADSL...) ; - mobilité de session (reprise sur un PDA d'une session vidéo commencée sur TV; ou sur un mobile UMTS d'une session 20 commencée sur GPRS) ; - continuité de session (partage de la bande passante avec une nouvelle application) ; - TV haute définition (encodage unique pour servir des clients SD "Standard Definition" et HD "High Definition") ; visioconférence (encodage unique pour des clients UMTS/Internet) ; 2.1. 1 Granularité de la scalabilité Un flux vidéo scalable peut être considéré comme un ensemble de sous-flux représentés par des cubes 11 dans un espace tridimensionnel formé des trois 30 dimensions spatiale 12, temporelle 13, et qualité, ou SNR, 14 (S,T,Q), comme illustré schématiquement par la figure 1. La taille des incréments dans les différentes directions correspond à la "granularité" de la scalabilité: elle peut être fine, moyenne (10% de débit par incrément de scalabilité : MGS) ou grossière (25% de débit par incrément: CGS). Dans la suite, on considèrera que la scalabilité CGS correspond à un système en couches ( layers dans le document MPEG2005/M12043, Avril 2005. "ISO/MP4 File Format for Storage of Scalable Video",Thomas Rathgen, Peter Amon et Andreas Hutter) et la scalabilité MGS à un système par niveaux ( levels dans ce même document). 2.1.2 Mode de scalabilité fine (MGS) Un train binaire scalable peut être organisé pour supporter une scalabilité fine. On parlera par la suite de scalabilité MGS ( Medium Grain Scalability ) conformément à la règle adoptée dans MPEG. À partir du train binaire, n'importe quel sous-flux cohérent peut être extrait (y compris le niveau de base) et décodé avec la qualité correspondante, c'est-à-dire n'importe quelle combinaison des résolutions supportées (temporelle, spatiale ou SNR) peut être extraite. Les trains binaires MGS permettent la flexibilité la plus élevée. 2.1.3 Mode d'organisation en couches ( Layered Scalability Mode ) Alternativement un train binaire peut être organisé en couches. On parlera alors de flux CGS ( Coarse Grain Scalability ). Une couche contient tous les niveaux de scalabilité nécessaires pour passer à la couche de qualité supérieure. Une couche doit augmenter la qualité dans au moins une direction (temporelle, spatiale ou SNR). Une représentation CGS permet des opérations simples d'adaptation, notamment au niveau des noeuds du réseau. Les évolutions des informations dans l'espace qualité-résolution spatiale-résolution temporelle sont définis a priori selon les conditions imposées par une application ou par un utilisateur du service. 2.2 MPEG-4 SVC Le JSVM MPEG est décrit dans le document JSVM 2.0 déjà cité. Le modèle qui a été retenu 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 2. Il s'agit d'une structure pyramidale. Les composantes d'entrée vidéo 20 subissent un sous-échantillonnage dyadique (décimation 2D par 2 référencée 21, décimation 2D par 4 référencée 22). Chacun des flux sous- échantillonnés subit ensuite une décomposition temporelle 23 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é R_rO_max qui correspond au débit maximum décodable pour la résolution spatiale basse rO (ce niveau de base est compatible AVC). Les niveaux supérieurs sont ensuite codés 25, 26 par soustraction du niveau précédent reconstruit et sur-échantillonné et codage des résidus sous forme: - d'un niveau de base; - éventuellement d'un ou plusieurs niveaux de rehaussement obtenus par codage multipasse de plans de bits (appelé par la suite FGS pour "Fine Grain Scalability", échelonnabilité à grain fin). Le résidu de prédiction est codé jusqu'à un débit R_ri_max qui correspond au débit maximum décodable pour la résolution ri. Plus précisément, les blocs de filtrage MCTF 23 réalisent un filtrage en ondelettes temporel, c'est-à-dire qu'ils réalignent les signaux dans le sens du mouvement avant filtrage en ondelettes: ils délivrent des informations de mouvement 27 qui alimentent un bloc de codage de mouvement 24-26, et des informations de texture 28, qui alimentent un module de prédiction 29. Les données prédites, en sortie du module de prédiction 29 servent à réaliser une interpolation 210 depuis le niveau inférieur. Elles alimentent également un bloc 211 de transformation spatiale et de codage entropique, qui travaille sur des niveaux de raffinement du signal. Un module de multiplexage 212 ordonne les différents sous-flux générés dans un flux de données compressé global. Cette nouvelle approche est capable de fournir des flux scalables à grain moyen dans les dimensions temporelles, spatiale, et en qualité. Les caractéristiques principales de cette technique sont les suivantes: solution pyramidale avec sous-échantillonnage dyadique des composantes d'entrée; - décomposition temporelle de type MCTF ("Motion Compensated Temporal Filtering" ou filtrage temporel de compensation de mouvement) à chaque niveau; - codage du niveau de base (compatible AVC) ; codage des niveaux supérieurs par soustraction du niveau précédent reconstruit et codage des résidus sous forme: - d'un niveau de base; et -d'un ou plusieurs niveaux de réhaussement obtenus par codage multipasse de plans de bits (par la suite: FGS). Afin de réaliser une adaptation en débit, les informations de texture sont codées à l'aide d'un schéma progressif à chaque niveau: -codage d'un premier niveau de qualité minimale (appelé Base Layer Couche de Base) ; - codage de niveaux de raffinement progressif (appelés "Enhancement Layer" Couche de Réhaussement). 2.3 Architecture du codeur SVC L'encodeur SVC est basé sur un système en deux couches, comme AVC: - La couche VCL ( "Video Coding Layer") gère l'encodage de la vidéo; - La couche NAL ("Network Abstraction Layer") assure une interface entre la couche VCL et l'extérieur. En particulier, ce niveau organise en AUs ("access units" ou "blocs d'unités de données") les différentes NALU ("NAL Units" ou "unités de données") qui lui sont fournies par la couche VCL. Une NALU est une unité élémentaire contenant le niveau de base d'une image spatio-temporelle, contenant tout (dans la version courante) ou partie (en cours de discussion pour les versions 30 futures) d'un niveau FGS d'une image spatio-temporelle; Une AU est l'ensemble des NALUs correspondant à un instant temporel. 2.4 Signalisation des modes de scalabilité dans la couche NAL SVC Afin de pouvoir décoder convenablement une NAL SVC, il faut pouvoir signaler son positionnement dans l'espace (S,T,Q) illustré par la figure 1. Deux modes de signalisation (correspondant sensiblement aux modes CGS et MGS) sont actuellement en cours de discussion dans le JSVM: un mode de signalisation par chemin fixe, et un mode de signalisation par chemin variable. Un exemple simple est donné par la figure 3, pour un contexte à deux dimensions 2D (T, Q) : un flux vidéo scalable contient les représentations emboîtées de sous-flux en CIF, de résolutions temporelles 15 Hz (31) et 30 Hz (32). Le flux est constitué de quatre NALUs A(0), B(2) , C(1) et D(2). En utilisant ces quatre NALUs on peut obtenir les points de débit distorsion a, b, c, d. La priorité des NALUs est indiquée entre parenthèses. Sur cet exemple, on voit qu'il y a plusieurs "chemins" 33, 34 et 35, de décodage possible entre les points a et d: (a,b,c,d) mais aussi (a,b,d) ou (a,c,d). On comprend que certaines applications pourront privilégier un chemin par rapport à l'autre. Par exemple, il peut être judicieux d'utiliser le chemin (a,c,d) pour obtenir une vidéo fluide en 30 Hz, mais plutôt (a,b,d) si l'on souhaite privilégier la qualité en 15 Hz. Ce chemin est donc dépendant de l'application et du mode de codage utilisé. 2.5.1 Chemin fixe Ce mode signale un chemin unique dans l'espace 3D pour l'extraction du flux scalable. Il est bien adapté au mode CGS pour certaines applications. Dans l'exemple de la figure 3, un chemin fixe va être choisi, par exemple (a,c,d). Ce chemin sera toujours utilisé, que l'on décode en 30 ou en 15 Hz. L'inconvénient majeur qui apparaît alors est que le point b ne sera pas décodé, même en 15 Hz, alors qu'il pourrait être plus intéressant de le décoder pour avoir une meilleure qualité en 15Hz. Dans ce contexte, un indicateur unique permet de coder ce chemin fixe. 2. 5.2 chemin variable Ce mode propose de laisser à l'application (ou au réseau) le choix du chemin d'extraction. Pour ce faire, on introduit un élément supplémentaire, que l'on appelle l'indicateur de priorité, et qui va permettre de résoudre le problème évoqué plus haut lorsqu'on décode en 30 Hz. Les deux tableaux suivants montrent respectivement les priorités affectées aux NALUs A, B, C et D dans l'exemple ci-dessus et le résultat du filtrage en 15 Hz et en 30 Hz selon la priorité choisie au décodage (sont décodées/conservées les NALUs qui apparaissent dans le tableau). On notera qu'il est possible en 30 Hz de définir plusieurs chemins différents en fonction de l'indice de priorité affecté aux quatre NALUs. NAL A B C D Priorité 0 2 1 3 Priorité au 15Hz 30Hz filtrage 0 A A 1 A A+C 2 A+B A+B+C 3 A+B A+B+C+D Les règles de filtrage utilisées ici sont les suivantes: Pour une résolution temporelle T cible (30 ou 15 Hz) garder toutes les NALs dont la résolution temporelle est inférieure ou égale à la résolution demandée (T_NAL Le procédé est généralisable à plus de deux dimensions: dans l'exemple illustré par la figure 4A, il y a trois dimensions de scalabilité : - D = Spatial: QCIF/CIF (la dépendance D est un sur-ensemble de la résolution spatiale S) ; T = Temporel: 15 Hz/30 Hz; Q = Qualité/complexité faible/forte ( low/high ). Un exemple d'association de priorités aux différentes NALUs est précisé 5 sur la figure, et un exemple de filtrage associé est montré dans le tableau ci-dessous. Low complexity/SNR 0 A A A A 1 A+E A+(B+E) A+(C+E) A+C A+(B*C+q 2 A+E A+(B+E) A+(C+E) A+C A+(B+C+E) +F +G +(D+F+G) 3 A+E A+(B+E) A+(C+E) A+C A+(B+C+E) + F +G +(D+F+G) +H Dans ce contexte, un indicateur double est nécessaire: le "priority field" contient l'indicateur de priorité et le "decodability info" contient les informations de résolution spatiale, temporelle et en qualité. Ces deux indicateurs nécessitent une représentation sur deux octets. Ainsi, dans toute la suite du document, une NAL sera repérée par ses quatre indices (P,D,T,Q) accessibles par exemple dans l'en-tête de fichier où : - P indique la priorité ; - D indique la dépendance (surensemble de la résolution spatiale S) ; - T indique la résolution temporelle; - Q indique la qualité, ou la complexité. On notera que les cellules en gras du tableau ci-dessus présentent des anomalies par rapport à la résolution spatio-temporelle demandée: en QCIF 30 Hz, il serait souhaitable de bénéficier de la NALU B, et non uniquement de la NALU A qui est à 15 Hz. L'invention a entre autres comme objectif de pallier ce problème. 3. Inconvénients de la technique antérieure La solution à chemin fixe ne permet pas de servir simultanément des applications différentes, car il n'existe qu'une relation unique de dépendance entre les NALUs issus d'un codeur hiérarchique. La solution à chemins multiples est plus ouverte que la solution à chemins fixes: elle permet de s'adapter à des applications/résolutions différentes, dans le réseau ou au niveau du décodeur. L'augmentation de complexité reste limitée, mais peut n'être pas adaptée pour une adaptation à très faible complexité comme fait sur certains routeurs de réseaux par exemple. La solution à chemin fixe ne permet pas de s'adapter au cours du temps à des conditions différentes du côté de l'utilisateur, du réseau ou du serveur: un client ne pourra choisir à un instant de favoriser un axe (par exemple la fluidité temporelle) plutôt qu'un autre (par exemple la qualité SNR) tel que le choix imposé par l'ordonnancement défini par le chemin fixe d'adaptation. Aucune des deux solutions (fixe ou variable) ne permet de gérer un mode de repli qui permettrait à un utilisateur de réduire la qualité ou la résolution des données reçues selon ses propres préférences. 4. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'état de la technique. Plus précisément, un objectif de l'invention est de fournir une technique de représentation vidéo scalable fine (en couches) des unités de données, ou paquets, ou NALUs, issus d'un codeur vidéo scalable dans le domaine 3D spatial-temporelqualité, qui soit plus efficaces que les techniques connues. Ainsi, un objectif de l'invention est de permettre de gérer des chemins différents dans cet espace 3D en fonction des caractéristiques de l'application, du réseau ou des besoins du client. En d'autres termes, un objectif de l'invention est de fournir une telle technique permettant de réaliser des traitements adaptés d'une même vidéo scalable pour des applications différentes. Un autre objectif de l'invention est de permettre de définir des modes de repli spécifiques dépendants ou indépendants des applications. L'invention a également pour objectif de permettre de définir des modes de remontée spécifiques dépendants ou indépendants des applications. Un autre objectif de l'invention est de permettre de varier au cours du temps modes et les points de fonctionnement pour un même flux vidéo. 5. Résumé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront plus clairement par la suite, sont atteints selon l'invention à l'aide d'un procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées. Selon l'invention, ce procédé comprend une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. Ainsi, l'invention permet de s'adapter finement à un grand nombre de contextes pour lesquels il est souhaitable de réduire ou augmenter la quantité d'informations transmises ou reçues. Il peut par exemple s'agir d'adapter les données au niveau du serveur, au niveau de noeuds intermédiaires, ou translateurs, placés dans un réseau, ou au niveau du terminal par sélection d'un profil par l'usager. De façon avantageuse, un premier desdits chemins privilégie une caractéristique représentative de la qualité de chaque image reconstruite par un terminal et un deuxième desdits chemins privilégie une caractéristique représentative de la fluidité de la vidéo. Il est ainsi possible de privilégier, selon le contenu, la qualité de l'image, par exemple pour un film, ou la fluidité des mouvements, par exemple pour du sport. De nombreux autres chemins (également appelés profils) et variantes peuvent bien sûr être définis. Préférentiellement, chacune desdites unités de données de réhaussement porte au moins deux indicateurs permettant de définir lesdits chemins, parmi les indicateurs appartenant au groupe comprenant: - un indicateur de priorité (P) ; - un indicateur de dépendance, relatif à la résolution spatiale (D) ; - un indicateur de résolution temporelle (T) ; -un indicateur de qualité et/ou de complexité (Q). Selon un mode de réalisation avantageux de l'invention, lesdits chemins sont stockés dans un fichier de chemins, associant chacun desdits chemins à un profil applicatif prédéterminé. Ce fichier de chemins peut notamment être un fichier au format XML. Il peut par exemple être stocké et/ou calculé à la volée par les terminaux. Dans un mode de réalisation préférentiel, ledit fichier de chemins est transmis dans ledit flux vidéo, sous la forme d'au moins une unité de données d'information. De façon avantageuse, le procédé de filtrage comprend les étapes suivantes: - séparation desdites unités de données de réhaussement, en fonction du chemin sélectionné, entre des unités de données à utiliser et des unités de données écartées; - reconstruction d'images vidéo à l'aide desdites unités de données à utiliser; - mémorisation desdites unités de données écartées. Cette dernière étape peut correspondre à un stockage, par exemple sur un disque dur, permettant de rejouer plus tard la vidéo avec un autre niveau de qualité, par exemple si la taille d'écran n'est plus la même. Il peut également s'agir d'une mémorisation dans une mémoire tampon, en vue d'une transmission des unités de données écartées sur un autre canal de transmission. Bien sûr, les unités de données écartées peuvent également être directement supprimées. Avantageusement, le procédé comprend les étapes suivantes: -détection d'au moins une unité de données à utiliser manquante ou détériorée; reconstruction d'une vidéo à partir d'unités de données correspondant à une des positions de repli du chemin sélectionné. Ainsi, en cas de perte d'un paquet, on ne perd pas la restitution de la vidéo, mais on passe simplement à une qualité inférieure. Le procédé de l'invention peut être mis en oeuvre à différents niveaux de la chaîne de transmission, et notamment par au moins un desdits éléments suivants: - serveur de flux vidéo; - noeud intermédiaire d'un réseau de transmission; - terminal récepteur d'un flux vidéo. L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de filtrage décrit ci-dessus. Selon un autre aspect de l'invention, celle-ci concerne un procédé de transmission d'un flux vidéo scalable par un serveur de flux vidéo vers au moins un terminal récepteur, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées. Ce procédé comprend une étape de transmission d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente. Ledit serveur et/ou un noeud intermédiaire dudit réseau de transmission met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal (ou de plusieurs terminaux) recevant ledit flux, et une étape de transmission des unités de données sélectionnées. De façon avantageuse, ledit serveur et/ou ledit noeud intermédiaire met en oeuvre ladite étape de sélection en fonction d'une information de sélection émise par ledit terminal. Elle peut également tenir compte d'une synthèse des informations émises par un groupe de terminaux. L'invention concerne également un produit programme d'ordinateur pour la mise en oeuvre d'au moins une étape de ce procédé de transmission d'un flux vidéo scalable. Selon encore un autre aspect, l'invention concerne un procédé de réception dans un terminal récepteur d'un flux vidéo scalable transmis par un serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées. Selon ce procédé, on utilise au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et ledit terminal récepteur met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. La notion d'utilisation d'au moins deux profils peut signifier que le terminal a préalablement reçu, du serveur, ces différents profils, et/ou qu'il les a calculé, par exemple à la volée. La sélection d'un chemin peut être automatique (pilotée par le terminal) et/ou à l'initiative de l'utilisateur. L'invention concerne également un produit programme d'ordinateur pour la mise en oeuvre d'au moins une étape de ce procédé de réception d'un flux vidéo 15 scalable. L'invention concerne également les serveurs de flux vidéo, les noeuds intermédiaires d'un réseau de transmission et les terminaux récepteurs de flux vidéo comprenant des moyens pour mettre en oeuvre les procédés décrits ci-dessous. Enfin, l'invention concerne un signal destiné à être transmis depuis un serveur vers au moins un terminal, pour permettre le traitement d'un flux vidéo scalable transmis par ledit serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé comme détaillé précédemment. Un tel signal porte des données de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente. Ce signal permet ainsi une sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. Selon un mode de réalisation avantageux, le signal porte d'une part lesdites unités de données formant ledit flux vidéo, et d'autre part lesdites données de définition. Les deux éléments peuvent également être transmis de façons indépendantes. 6. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donnée à titre de simple exemple illustratif et non limitatif, et des dessins annexés parmi lesquels: - la figure 1, déjà commentée en préambule, illustre la structure d'un flux vidéo scalable, dont les sous-flux sont représentés par des cubes dans un espace tridimensionnel formé des trois dimensions spatiale, temporelle, et qualité ; - la figure 2, également commentée en préambule, présente la structure schématique d'un encodeur du flux de la figure 1; - la figure 3, commentée en préambule, est un exemple de structuration d'un flux scalable en deux dimensions, et de trois chemins correspondants; - la figure 4A, également commentée en préambule, illustre un exemple de structuration à trois dimensions de scalabilité, et lafigure 4B présente une une variante de répartition des priorités pour une NAL, selon un aspect de l'invention; - la figure 5 est un organigramme simplifié du principe de l'invention; - la figure 6 illustre un tableau de filtrage présentant deux chemins selon l'invention; - la figure 7 présente les plages de débit correspondant au tableau de la figure 6; - la figure 8 est un autre exemple de tableau de filtrage selon l'invention, utilisant la notion d'indicateur de priorité ; les figures 9 à 11 illustrent trois mises en oeuvre de l'invention, respectivement dans un modèle client-serveur, l'adaptation du débit dans un noeud intermédiaire et l'adaptation à un terminal; la figure 12 illustre les dépendances définies par un profil, et la figure 13 la reconstruction des dépendances pour le repli sur la meilleure qualité possible en cas de perte d'une NALU; les figures 14, 15 et 16 présentent respectivement des schémas simplifiés des serveur, noeud de transmission et terminal selon l'invention. Description d'un mode de réalisation préférentiel de l'invention éléments essentiels de l'invention L'invention propose donc d'utiliser, selon le mode de réalisation décrit par la suite, les champs (P,D,T,Q) de NALUs SVC, afin de gérer des ordres de priorité dépendant des besoins applicatifs spécifiés et utilisable pour faire de l'adaptation d'un flux vidéo côté serveur (régulation de débit, adaptation à la demande), noeuds de transmission (DiffServ, TOS) ou côté client (adaptation en complexité, ...). On se place dans le contexte du filtrage générique connu, décrit précédemment. Chaque NAL est donc définie par le quadruplet (P,D,T,Q). Le filtrage s'effectue selon N des 4 dimensions (N On dispose de modes de repli, c'est-à-dire de mécanismes permettant de privilégier un chemin dans l'espace (D,T,Q) lorsque les résolutions cibles ne peuvent être atteintes (pour des raisons de diminution de débit, de complexité, de choix de l'utilisateur...). Selon l'invention, un ensemble de profils applicatifs (ou chemins) est défini. Ces profils applicatifs définissent donc des ordres différents de priorité sur les modes de repli, en fonction de critères tels que le type de vidéo (sport ou cinéma par exemple), le type de terminal (capacité de traitement et de mémoire, taille de l'écran) et/ou les capacités du réseau. Par exemple, dans le premier cas, on peut définir deux profils: Profil sport: on privilégie la fluidité temporelle: - - - 7. 7.1 SD@30Hz high => SD@30Hz low => CIF@30Hz high => CIF@ 15Hz high Profil film: on privilégie la qualité à la fluidité et résolution spatiale: SD@30Hz high => SD@ 15Hz high => SD@7.5Hz high => CIF@7.5Hz high. Un profil applicatif est alors défini par une suite de valeurs (P,D,T,Q)i. L'ensemble des profils applicatifs peut être stocké dans un fichier, par exemple un fichier XML (ce fichier s'appliquant à une séquence complète ou bien à des segments de la séquence ou encore à un ensemble de séquences). Ce fichier peut être transmis avec le flux vidéo, ou dans un canal séparé. Il doit être disponible avant le début du décodage de la séquence/segment...). Un autre mode de réalisation est le transport ces méta-paramètres dans des NALUs d'information (par exemple NALUs de type SEI). Le déroulement du procédé de filtrage, illustré par l'organigramme de la figure 5, est le suivant: 1. Lecture 51 du fichier des profils applicatifs contenant les modes de repli et choix 52: a. d'un mode de fonctionnement initial (par exemple sport) (chemins de repli et de remontée) ; b. d'un point de fonctionnement initial (par exemple haut débit CIF@30 Hz) ; Ce point de fonctionnement peut être remis à jour de façon externe (sur une base d'adaptation en débit, en qualité, en complexité...) conformément à une stratégie de repli définie; 2. Lecture 53 des indices de l'unité de vidéo scalable à traiter: on lit dans l'en- tête de la NAL les informations de résolution spatio-temporelles-qualité (P_paq, D_paq, T_paq, Q_paq) (une ou plusieurs des dimensions peuvent être omises) ; 25 3. En fonction du point de fonctionnement (remis à jour ou non par le processus externe) : a. Lecture 55 du mode de fonctionnement (par exemple: sport) associé à un chemin ascendant et descendant permettant de se déplacer dans l'espace de scalabilité ; b. Choix d'un point de fonctionnement (lecture ou calcul de P'_cible D'_cible, T'_cible, Q'_cible) ; 4. Filtrage 56: a. Réduction du débit: suppression des paquets pour lesquels (P_paq, D_paq, T_paq, Q_Paq) ne sont pas conformes à la cible, conformément à la table XML; b. rejet 57 ou utilisation 58 du paquet (ou NALU) ; 5. Modification 54 (éventuelle via un processus externe ou autre) du point de fonctionnement: a. changement du mode de fonctionnement (passer d'une priorité donnée à la fluidité des images à une priorité sur la qualité ou la résolution spatiale) ; b. changement du point de fonctionnement (demande de remontée ou de descente en qualité de service). La modification 54 tient compte d'un indicateur 59 de mode de repli délivré par un adaptateur de profil 510 contrôlé selon les cas par le terminal client 511, le serveur 512 et le réseau 513. Chacune de ces étapes est détaillée par la suite. L'invention s'appuie sur la définition d'une relation entre les champs P, D, T, Q de l'en-tête des NALUs en vue d'organiser le flux vidéo en sortie du procédé conformément aux attentes d'un service particulier, ou d'un groupe de services. 7.2 Signalisation des NALUs On propose, selon un mode de réalisation avantageux, d'améliorer la numérotation proposée dans l'art antérieur en déclarant que chaque niveau de base 30 est de priority_id O. Cette approche est illustrée par la figure 4B. Elle permet 10 efficacement de faire disparaître les points en anomalie entre les résolutions spatiotemporelles demandées et délivrées (case en gras du tableau de l'art antérieur). 7.3 Etablissement du tableau de filtrage Le tableau de filtrage illustré en figure 6 est établi conformément à l'art antérieur. On peut aussi calculer, de manière optionnelle, un débit associé à chaque "case" significative du tableau. On peut interpréter ce tableau comme un ensemble d'intervalles de résolutions avec des débits recouvrants (ou non). Cette interprétation est illustré par la figure 7. A l'intérieur de chaque intervalle, le débit augmente avec le Priority_id P. Sur le tableau de la figure 6, on peut noter que chaque série est monotone dans le tableau, alors que la courbe 61 ne l'est pas. Cela est un avantage de la solution de l'invention. Un mode de repli correspond à une descente (flèches 61 et 62) dans le tableau de la figure 6. Par exemple, on définit: un profil sport 61, selon lequel on privilégie la fluidité temporelle CIF@30Hz high => CIF@30Hz low => QCIF@30Hz high => QCIF@30Hz Low > QCIF@ 15Hz high; - un profil film 62, selon lequel on privilégie la qualité à la fluidité et résolution spatiale: CIF @30Hz high => CIF @ 15Hz high =>QCIF @ 15Hz high =>QCIF @7.5Hz high. La même approche peut être définie par évolution de plages de débit, comme illustré par la figure 8: profil sport 81: SD@30Hz (high to low) => CIF@30Hz (high to low) => QCIF@30Hz (high to low) ... profil film 82... Afin de définir ces modes de repli en fonction des applications, on peut imaginer par exemple un fichier XML des profils applicatifs du type suivant: ="low" P i n="0" P?M a x= Q " /> Pnîa _-.. 2 /> PMax="0" /> sport path_preference> temporel "8 4 2" "150 150-300 450 450-900" Application name="appllcatjon deux"> film qualité "9 6 2" "100-200 400-600 800-900" mobile pathpreference> resolution "9 6 5" On présente en annexe un schéma complet permettant de valider cet exemple. Tout autre moyen de description des profils applicatifs est possible, tel qu'un tableau dans un langage de programmation, ou une insertion dans le flux vidéo (SEI à définir). Sur l'exemple de fichier XML ci-dessus, on a défini des plages de fonctionnement (dénommées range ). Ces plages de fonctionnement correspondent à un triplet de valeur (DTQ) et une plage de valeurs de priority_id (Pmin, Pmax). Cette plage de priority_id permet alors d'offrir une variation en qualité/débit pour une résolution donnée. La disponibilité de différentes plages pour différentes résolutions spatio-temporelles permet alors de définir des profils applicatifs de repli. Un profil applicatif est alors défini par une suite de range . Ainsi sur cet exemple, le profil sport passe d'une plage de débit en CIF@30Hz puis une plage de débit pour du QCIF@30Hz et enfin pour du QCIF@ 15Hz, privilégiant ainsi une fluidité temporelle lors de l'utilisation de mode de repli. Il est à noter que les plages de débits proposées dans un mode applicatif peuvent se chevaucher (voir figure 7). Ceci autorise ainsi un phénomène d'hystérésis dans l'algorithme décrit par la suite qui permet alors une plus grande stabilité du système en limitant l'utilisation des modes de repli. 7.4 Algorithme générique d'adaptation En reprenant l'exemple de profils applicatifs tels que décrit ci-dessus, un algorithme d'adaptation fonctionne de la manière suivante: 1- Lecture des profils applicatif. Par exemple le fichier xml décrit ci-dessus: a- sélection d'un mode applicatif. Par exemple profil sport ("application une") ; b- sélection d'un point de fonctionnement initial. Par défaut choix du mode de fonctionnement maximal: Point ayant le priority_id maximum dans le range 9. Soit p_cible=3, D_cible=CIF, T_cible=30Hz, Q_cible=High; 2- Lors d'une adaptation nécessaire, le processus externe fait alors varier la valeur du priority_id dans le range courant (par exemple en utilisant un système de rétro-action, ou bien en utilisant une tabulation priority_id donne débit). Si la contrainte n'est pas satisfaite, on peut alors décider d'opérer un repli (sélection du range inférieur) ou de remontée (sélection du range supérieur). La recherche du range adéquat et du priority_id peut être poursuivi jusqu'à obtention de la contrainte. 7.5 Filtrage Cette étape, classique en soi, consiste à É Rejeter (ou traiter de façon adéquate par exemple par routage haut débit) tous les paquets pour lesquels (P_paq > P_courant) et/ou (S_paq > S_courant) et/ou (T_paq > T_courant) et/ou (Q'_paq > Q_courant), É Traiter les autres paquets (transmission, stockage, ...). 7.6 Exemple d'applications de l'invention L'invention peut prendre en compte un grand nombre de contraintes applicatives et peut se réaliser indifféremment en tout point du réseau placé sur le chemin entre le codeur et le décodeur, dans un processus temps réel ou de traitement en différé. Le tableau ci-dessous décrit plusieurs exemples d'actions types et leurs localisations possibles dans le réseau: Type d'action Localisation des actions Serveur Noeud Récepteur intermédiaire Réduction débit Sélection des Sélection des NALUs par NALUs par niveau niveau hiérarchique de hiérarchique de débit débit Définition d'un Restreindre les Restreindre les Sélection des chemin d e dépendances au dépendances au dépendances dépendances décodage à un décodage à un autorisant un chemin unique et chemin unique et chemin optimum prédéfini, selon prédéfini, selon de décodage stratégie opérateur stratégie opérateur a d a p t é a u T V et/ou TV et/ou opérateur terminal. opérateur télécom télécom Pertes de paquets Trouver un chemin T r o u v e r u n de dépendance chemin de pour récupérer la dépendance pour qualité maximale récupérer la quand un paquet qualité maximale est perdu quand un paquet est perdu 7.6.1 Contexte 1: modèle client-serveur (adaptation aux ressources et aux choix de l'utilisateur) La figure 14 présente la structure simplifiée d'un serveur selon l'invention, qui comprend une mémoire M 148, une unité de traitement 146, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 147. A l'initialisation, les instructions de code du programme d'ordinateur 147 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 146. L'unité de traitement 146 reçoit en entrée un ensemble de NALUs 141. Le microprocesseur P de l'unité de traitement 146 délivre un flux vidéo filtré 143 en fonction du profil, ou chemin, sélectionné, selon les instructions du programme Pg 147. Cette mise en oeuvre est illustrée par la figure 9. Le serveur 91 propose (911) au client 92 un choix de profils applicatifs, en fonction d'une demande 921 de flux vidéo. Le client choisit (922) un mode et un point de fonctionnement. Le serveur reçoit le mode de fonctionnement et le point de fonctionnement 912 du client, en fonction de quoi il filtre (913) les éléments 914 du codage vidéo. Seuls les paquets conservés, formant la vidéo filtrée 915, sont transmis au client. Les modes et points de fonctionnement peuvent être remis à jour par un processus d'adaptation externe 93 recevant des rapports de l'usager (ou du réseau). L'adaptateur de profils 93 utilise les éléments "RangeOrder" du fichier XML de profils. 7.6.2 Contexte 2: modèle serveur-réseau-client (adaptation au réseau) La figure 15 présente la structure simplifiée d'un noeud intermédiaire de réseau selon l'invention, qui comprend une mémoire M 154, une unité de traitement 151, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 152. A l'initialisation, les instructions de code du programme d'ordinateur 152 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 151. L'unité de traitement 151 reçoit en entrée un flux vidéo 151. Le microprocesseur P de l'unité de traitement 151 filtre le flux vidéo 151, en fonction d'un profil sélectionné, et délivre un flux filtré 153, selon les instructions du programme Pg 152. Cette deuxième mise en oeuvre est illustrée par la figure 10. Le serveur 101 envoie dans le réseau un flux (vidéo haut débit) 102 destiné à un groupe de récepteurs acceptant une image haute qualité et avec un débit élevé. Contrairement à l'exemple précédent fonctionnant en point à point, cet exemple fonctionne en multicast. Le noeud intermédiaire 103 reçoit le même flux 102 que les autres récepteurs placés sur le réseau. Il dispose en interne d'un profil applicatif cible 1031 permettant de piloter l'algorithme de filtrage 1032 pour aboutir au débit cible du flux 1033, par élimination 1034 des paquets hors profil. Le client 104 reçoit cette vidéo filtrée 1033. Dans le cas où les profils fournis par le serveur ne sont pas adaptés, le noeud intermédiaire peut calculer de nouveaux profils directement par analyse des champs {P,D,T,Q}. 7.6.3 Adaptation du débit aux ressources du terminal La figure 16 présente la structure simplifiée d'un terminal selon l'invention, qui comprend une mémoire M 160, une unité de traitement 161, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 162. A l'initialisation, les instructions de code du programme d'ordinateur 162 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 161. L'unité de traitement 161 reçoit en entrée un flux vidéo 163. Le microprocesseur P de l'unité de traitement 161 filtre le flux vidéo 163, en fonction du profil sélectionné, selon les instructions du programme Pg 162. L'unité de traitement 161 délivre en sortie un flux vidéo filtré 164. La figure 11 donne un exemple de l'adaptation de l'affichage aux ressources d'un terminal 111, par exemple un terminal à ressources limitées. Le transport de la vidéo 112 contient l'ensemble des informations pour tous les terminaux. En fonction de la capacité réduite du terminal, un usager peut choisir (1111), pour son confort personnel, de privilégier un profil avec une meilleure fluidité ou un profil avec une meilleure définition, parmi ceux disponibles 1112. Par exemple, l'utilisateur choisit le profil "sport". Il dispose en outre d'une IHM qui va lui permettre de naviguer dans les niveaux de qualité. Il peut en particulier choisir d'augmenter ou diminuer le point de fonctionnement. Les profils applicatifs sont insérés dans les paramètres généraux 1121 de la vidéo, par message SEI, table xml, EPG ou par tout autre moyen. Le filtrage 1113 est effectué en fonction du profil sélectionné, et le décodeur 1114 reconstruit les images correspondantes. 7.6.4 Récupération de la meilleure qualité en cas de perte de NAL dans un récepteur L'adaptation des NALUs peut varier dans les plages de qualité correspondant à un niveau, comme indiqué par la figure 12, le basculement d'un niveau vers un autre peut s'effectuer aux extrémités de la plage. En considérant un usager recevant le niveau CIF30, et donc tous les niveaux intermédiaires, la description des profils applicatifs permet de retrouver l'information fournissant la meilleure qualité. La figure 13 montre un exemple de cette approche. Les NALUs 131, 132 et 133 ont été perdus. L'analyse des champs PDTQ permet de retrouver l'information disponible de meilleure qualité en attendant l'image suivante reçue sans erreur. Les NALUs reçus 134 et 135 correspondent aux niveaux inférieurs manquants ne permettent pas le décodage. On se replie alors sur la NALU 136. ANNEXE - 15 20 25 30 10 15 20 25 30 REVENDICATIONS 1. Procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'il comprend une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. 2. Procédé de filtrage d'un flux vidéo scalable selon la revendication 1, caractérisé en ce qu'un premier desdits chemins privilégie une caractéristique représentative de la qualité de chaque image reconstruite par un terminal et un deuxième desdits chemins privilégie une caractéristique représentative de la fluidité de la vidéo. 3. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 et 2, caractérisé en ce que chacune desdites unités de données de réhaussement porte au moins deux indicateurs permettant de définir lesdits chemins, parmi les indicateurs appartenant au groupe comprenant: - un indicateur de priorité (P) ; - un indicateur de dépendance, relatif à la résolution spatiale (D) ; - un indicateur de résolution temporelle (T) ; - un indicateur de qualité et/ou de complexité (Q). 4. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits chemins sont stockés dans un fichier de chemins, associant chacun desdits chemins à un profil applicatif prédéterminé. 5. Procédé de filtrage d'un flux vidéo scalable selon la revendication 4, caractérisé en ce que ledit fichier de chemins est un fichier au format XML. 6. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 4 et 5, caractérisé en ce que ledit fichier de chemins est transmis dans ledit flux vidéo, sous la forme d'au moins une unité de données d'information. 7. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend les étapes suivantes: - séparation desdites unités de données de réhaussement, en fonction du chemin sélectionné, entre des unités de données à utiliser et des unités de données écartées; - reconstruction d'images vidéo à l'aide desdites unités de données à utiliser; - mémorisation desdites unités de données écartées. 11. Procédé de filtrage d'un flux vidéo scalable selon la revendication 7, caractérisé en ce qu'il comprend une première étape de transmission desdites unités de données à utiliser via un premier canal de transmission, et une seconde étape de transmission desdites unités de données écartées via un second canal de transmission. 12. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend les étapes suivantes: - détection d'au moins une unité de données à utiliser manquante ou détériorée; - reconstruction d'une vidéo à partir d'unités de données correspondant à une des positions de repli du chemin sélectionné. 10. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il est mis en oeuvre par au moins un desdits éléments suivants: - serveur de flux vidéo; - noeud intermédiaire d'un réseau de transmission; - terminal récepteur d'un flux vidéo. 11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 10. 12. Procédé de transmission d'un flux vidéo scalable par un serveur de flux vidéo vers au moins un terminal récepteur, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'il comprend une étape de transmission d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et en ce que ledit serveur et/ou un noeud intermédiaire dudit réseau de transmission met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités d'au moins un terminal recevant ledit flux, et une étape de transmission des unités de données sélectionnées. 13. Procédé de transmission selon la revendication 12, caractérisé en ce que ledit serveur et/ou ledit noeud intermédiaire met en oeuvre ladite étape de sélection en fonction d'une information de sélection émise par ledit terminal. 14. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de transmission d'un flux vidéo scalable selon l'une quelconque des revendications 12 et 13. 15. Procédé de réception dans un terminal récepteur d'un flux vidéo scalable transmis par un serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'on utilise au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et en ce que ledit terminal récepteur met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. 16. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de réception d'un flux vidéo scalable selon la revendication 15. 17. Serveur de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. 18. Noeud intermédiaire d'un réseau de transmission de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. 19. Terminal récepteur de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de prise en compte d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. 20. Signal destiné à être transmis depuis un serveur vers au moins un terminal, pour permettre le traitement d'un flux vidéo scalable transmis par ledit serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce que ledit signal porte des données de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, de façon à permettre une sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux. 21. Signal selon la revendication 20, caractérisé en ce qu'il porte d'une part lesdites unités de données formant ledit flux vidéo, et d'autre part lesdites données de définition.