FR2911235A1 - Procedes et dispositifs de decodage et de codage d'un flux de donnees scalable,produits programmes d'ordinateur, support de donnees et signal correspondants - Google Patents

Abstract

L'invention concerne le décodage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs).Selon l'invention, le procédé de décodage comprend, pour chaque paquet d'en-tête de type SVC d'un niveau de base, les étapes suivantes :- extraction dans l'en-tête d'une information indiquant la présence d'une charge utile dans ledit paquet d'en-tête de type SVC ;- si ladite information indique une absence de charge utile : affectation des données de scalabilité dudit entête à la charge utile d'un paquet de type AVC précédant ledit paquet de type SVC ;- si ladite information indique une présence d'une charge utile : affectation des données de scalabilité de ladite entête à la charge utile dudit champ de données d'image.

Description

Procédés et dispositifs de décodage et de codage d'un flux de données

scalable, produits programme d'ordinateur, support de données et signal correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui du codage et du décodage d'images ou de séquences vidéo d'images. Plus précisément, l'invention concerne le codage d'images ou de séquences vidéo d'images générant un flux présentant une organisation en couches de données, et le décodage d'un tel flux de données échelonnable (ou scalable ), avec une qualité adaptable et une résolution spatio-temporelle variable. 2. Art antérieur 2.1 Principe général du codage vidéo scalable De nombreux systèmes de transmission de données sont aujourd'hui hétérogènes, en ce sens qu'ils desservent une pluralité de clients (terminaux de réception) disposant de types d'accès aux données très divers. Ainsi, le réseau mondial Internet, par exemple, est accessible aussi bien à partir d'un terminal de type ordinateur personnel (PC) que d'un radiotéléphone. Plus généralement, la bande passante pour l'accès au réseau, les capacités de traitement des terminaux clients, la taille de leurs écrans varient fortement d'un utilisateur à l'autre. Ainsi, un premier client peut par exemple accéder au réseau Internet à partir d'un PC puissant, et disposer d'un débit ADSL ( Asymmetric Digital Subscriber Line pour Ligne d'abonné numérique à structure asymétrique ) à 1024 kbits/s alors qu'un deuxième client cherche à accéder aux mêmes données au même instant à partir d'un terminal de type PDA ( Personal Digital Assistant pour assistant numérique personnel ) connecté à un modem à faible débit. Or la plupart des codeurs vidéo génèrent un seul flux compressé correspondant à l'intégralité de la séquence codée. Ainsi, si plusieurs clients souhaitent exploiter le fichier compressé pour décodage et visualisation, ils devront télécharger (ou streamer ) le fichier compressé complet.

Il est donc nécessaire de proposer à ces divers utilisateurs un flux de données qui soit adapté tant en termes de débit que de résolution des images à leurs différents besoins. Cette nécessité s'impose plus largement pour toutes les applications accessibles à des clients disposant de capacités d'accès et de traitement très diverses, et notamment les applications de : service de vidéo à la demande (VOD, en anglais Video On Demand pour vidéo à la carte ), accessibles aux terminaux de radiocommunication de type UMTS ( Universal Mobile Telecommunication 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, sur un mobile UMTS d'une session commencée sur GPRS ( General Packet Radio Service pour service général de radiocommunication par paquets )) ; 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. Pour répondre à ces différents besoins, des algorithmes de codage d'images échelonnables, ou scalables , ont été développés, permettant une qualité adaptable et une résolution spatio-temporelle variable. Selon ces techniques, le codeur génère un flux compressé présentant une structure hiérarchique en couches, dans laquelle chacune des couches est emboîtée dans une couche supérieure. Par exemple, une première couche de données véhicule un flux à 256 kbits/s, qui pourra être décodé par un terminal de type PDA, et une deuxième couche de données complémentaire véhicule un flux de résolution supérieure à 256 kbits/s qui pourra être décodé, en complément du premier, par un terminal plus puissant de type PC. Le débit nécessaire pour le transport de ces deux couches emboîtées est dans cet exemple de 512 kbits/s. De tels algorithmes de codage sont ainsi 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. Certains de ces algorithmes de codage vidéo échelonnables sont aujourd'hui en cours d'adoption par la norme MPEG-4 ( Moving Picture Expert Group ) AVC ( Advanced Video Coding pour codage vidéo avancé ), dans le cadre du groupe de travail JVT ( Joint Video Team ) joint entre l'ITU ( International Telecommunication Union pour Union Internationale des Télécommunications ) et l'ISO ( International Organization for Standardization pour Organisation internationale de normalisation ). 2.2 Notion de profils et niveaux de AVC Dans la plupart des standards de compression vidéo, il est défini une notion de profil (ou profile en anglais) et de niveau (ou level en anglais) attachés à un flux vidéo. Plus précisément, un profil définit un sous-ensemble d'outils de la norme utilisables pour coder un flux vidéo. Un décodeur dit compatible à ce profil doit pouvoir décoder ce flux vidéo.

Ainsi, l'activation d'outils selon un profil permet de contrôler la complexité de mise en oeuvre d'un codeur/décodeur suivant l'architecture visée, et d'adapter les outils nécessaires à une application donnée. Par exemple, l'annexe A de AVC telle que présentée dans le document JVT-T201 de T. Wiegand, G. Sullivan, J. Reichel, H. Schwarz et M. Wien (15-21 juillet 2006, Klagenfurt, Autriche, 20ème meeting, JD Joint Video Team de l'ISO/IEC MPEG et ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 et ITU-T SG16 Q.6)), définit différents profils dont : un profil de base, noté baseline , principalement destiné à des applications de visiophonie, vidéoconférence ou à un usage pour les mobiles, utilisant des outils de faible complexité, ainsi que quelques outils permettant un meilleur contrôle des erreurs ; un profil moyen, noté main , et un profil élevé, noté high , principalement destinés à des applications de diffusion de signaux de type TV ou de signaux de plus haute définition complets, utilisant des outils plus complexes, ou plus adaptés à des résolutions supérieures. La notion de niveau de complexité ( level ) permet quant à elle, à l'intérieur d'un profil, de raffiner la mesure de complexité (i.e. niveau de complexité ) nécessaire à un décodeur pour décoder un flux d'un profil donné.

Typiquement, chaque niveau de complexité peut être rattaché à un nombre de macro-blocs décodables par seconde, à une taille d'image maximale, ou encore à une taille maximale des tampons ( buffers ) de décodage. Ce niveau de complexité permet également d'activer certains outils de la norme, dépendants du niveau de complexité. Par exemple, comme présenté dans le tableau A-1 ( Table A-1 û Main profile level limits ) du document JVT-T201 cité précédemment, il est possible d'activer l'outil d'entrelacement dans le profil main à partir d'un niveau de complexité supérieur à 2.1 et inférieur à 4.2 ; dans ce cas, un indicateur (par exemple l'indicateur frame_mbs_only_flag ) est à 1 pour les niveaux de complexité de 2.1 à 4.2.

A travers cet exemple, on constate que les niveaux de complexité ne sont pas nécessairement emboîtés les uns dans les autres. Cependant, un niveau de complexité a peut englober un niveau de complexité b, dans le cas où aucun nouvel outil de codage n'est introduit entre les niveaux de complexité a et b. Dans ce cas, b a une complexité inférieure à a et on peut dire que le niveau de complexité b est inférieur au niveau de complexité a. 2.3 Signalisation des profils et des niveaux de complexité On rappelle qu'un flux issu d'un codeur de type AVC est généré pour une résolution spatiale donnée et pour une qualité donnée. Un tel flux comprend donc une unique couche avec un seul niveau de qualité en quantification.

Il est connu d'insérer une information de profil et de niveau de complexité dans un tel flux, avant émission, afin d'informer un décodeur recevant le flux de la complexité de ce flux. Ainsi, le décodeur sait s'il est capable de décoder le flux, c'est-à-dire si le décodeur est compatible avec le même profil et le même niveau de complexité que ceux indiqués dans le flux AVC. Cette information est classiquement insérée dans une unité de données appelée Sequence Parameter Set (SPS). 2.4 Syntaxe d'un flux SVC Un flux généré par un codeur de type SVC ( Scalable Video Coding pour codage vidéo échelonnable ) comprend quant à lui une ou plusieurs couches spatiales ou de qualité en quantification. Ces couches sont également appelées couches de dépendance. Plus précisément, un tel flux comprend un niveau de base et un ou plusieurs rehaussements, répartis dans une ou plusieurs couches. Ces rehaussements peuvent être de type rehaussement de qualité en quantification, rehaussement temporel ou rehaussement spatial. Un rehaussement spatial implique un changement de couche. Par exemple, la figure 1 illustre schématiquement la structure d'une couche 11 d'un flux de données de type SVC. Une telle couche 11 comprend par exemple un niveau de qualité en quantification de base 121, et deux niveaux de qualité de rehaussement en quantification 122 et 123. Par exemple, le niveau de qualité de base 121 correspond à un flux de type AVC. Une telle couche I l peut également être découpée en niveaux temporels, par exemple les trois niveaux 131, 132 et 133. Classiquement, une information de profil et de niveau de complexité est 30 insérée dans chacune des couches du flux, dans une unité de données SPS.

Autrement dit, une unité SPS est générée pour chaque couche spatiale du flux. Un flux SVC est organisé en AUs ("Access Units" pour Unités d'Accès) correspondant chacune à un instant temporel donné et comprenant une ou plusieurs NALUs ("Network Abstraction Layer Units" pour Unités d'Accès pour le réseau), ou paquets d'informations. Ces différents paquets d'informations, ou NALUs, peuvent être regroupés hiérarchiquement : û séquence vidéo : c'est un ensemble de paquets d'informations représentant une partie du flux vidéo (ne correspondant pas nécessairement à tout le flux vidéo). Classiquement (mais de manière non limitative) on retrouve dans les premiers paquets des informations globales relatives à la séquence : paquets de type SPS, mais aussi des paquets d'information relative aux différents types d'images présentes : paquets de type PPS (Picture Parameter Set) ; û Access Unit : c'est un ensemble d'informations correspondant à un instant temporel. On y retrouve des paquets d'informations de type message d'information (SEI "Supplemental Enhancement Information" pour informations supplémentaires d'amélioration), des paquets d'information globale (SPS) ou relatifs aux différents types d'images (PPS), et au moins un paquet d'informations d'images comprenant une charge utile ; On entend par charge utile des données codées représentatives de tout ou partie de l'image comprenant la représentation d'au moins un bloc d'image et par charge informative des données informatives relatives à l'image (pour les NALUs suffixe). û slice : c'est un ensemble d'informations codées au sein d'une NALU comportant une charge utile. Une "slice" regroupe un ensemble de macro-blocs d'une image pour un niveau de représentation (par exemple niveau de représentation spatiale) ; û macrobloc : c'est un ensemble d'informations présentes dans un groupe de blocs. Par exemple, un macrobloc est constitué de 4 blocs 8x8 de luminance et de 2 blocs 8x8 de chrominance (chrominance rouge, chrominance bleu) pour le format de couleur 4:2:0 ; û bloc : ensemble d'informations relatives à un bloc d'image de taille inférieure au macrobloc (Dans le standard MPEG-4 AVC, des tailles de blocs de 16x8, 8x16, 8x8, 8x4, 4x8 ou 4x4 sont utilisées). Chaque NALU est associée à une image issue de la décomposition spatio-temporelle, à un niveau de résolution spatiale, et à un niveau de qualité de quantification. Cette structuration en NALUs permet au décodeur SVC de pouvoir réaliser une adaptation en débit et/ou résolution spatio-temporelle en supprimant les NALUs de résolution spatiale, fréquence temporelle ou qualité d'encodage trop élevée. Les NALUs peuvent être des NALUs de données, dites VCL ("Video Coding Layer" pour couche de codage vidéo) ou de signalisation (SEI, SPS, PPS, suffixes...). Chaque NALU de données encapsule une "slice" d'image. Par exemple, la figure 2 illustre un exemple d'organisation en AUs et NALUs d'un flux de type SVC. Deux AUs 21 et 22 sont représentées sur cette figure, correspondant respectivement aux niveaux temporels TO et T 1. Ces AUs comportent plusieurs NALUs, en fonction des niveaux spatiaux Sj et des niveaux de qualité en quantification Ek. Une NALU est représentée par un bloc tel que le bloc 23, pour un niveau temporel Ti, un niveau spatial Sj et un niveau de qualité en quantification Ek. Comme décrit précédemment, dans chaque couche de dépendance d'un flux SVC, il y a un niveau de base et optionnellement des niveaux de rehaussement. Le niveau de base de la première couche est compatible AVC (c'est-à-dire ne comprenant que des NALUs définies dans la norme AVC). Le niveau de base des couches supérieures peut être de type AVC (sous certaines contraintes) ou SVC.

Les rehaussements sont de type SVC. Actuellement, dans SVC, deux ensembles de NALUs coexistent : û NALUs AVC (utilisées notamment pour le niveau de base d'une couche SVC) : chaque NALU spécifique à AVC (NALU de type 1 à 8) comporte un octet d'en-tête et peut comprendre une charge utile. û NALUs SVC (notamment pour les rehaussements d'une couche SVC ou le niveau de base d'une couche SVC supérieure à la première couche) : chaque NALU spécifique à SVC (NALU de type 20 ou 21) comporte un octet d'en-tête AVC et trois octets d'en-tête SVC, comprenant notamment les champs (P, D, T, Q) ("Priority_id", "Dependency_id", "Temporal_level", "Quality_level") nécessaires au filtrage de l'information contenue dans la NALU, et le champ "layer- base-flag" (pour indicateur de niveau de base) qui indique des données AVC, et peut comprendre une charge utile. Plus précisément : • le champ "Priority_id" indique un niveau de priorité d'une NALU pouvant servir à guider une adaptation en qualité ; • le champ "Dependency_id" permet de connaître la résolution spatiale d'une couche hiérarchique de codage. Ce champ peut aussi contrôler un niveau de rehaussement en qualité de quantification ou de rehaussement temporel dans le cadre d'un codage en couches • le champ "Temporal_level" permet d'indiquer le niveau temporel indiquant la fréquence d'image ; • le champ "Quality_level" permet d'indiquer le niveau de rehaussement en qualité de quantification, et donc de contrôler le débit/qualité et/ou la complexité ; • le champ base ("layer_base_flag") signale une syntaxe de données (payload, ou charge utile) compatible AVC (pas de prédiction inter-couches, pas de raffinement en qualité).

La figure 3 illustre un exemple de format d'une NALU SVC, mettant en évidence trois parties différentes, comme décrit ci-dessus : un en- tête AVC 31, un en-tête SVC 32, et un champ de données 33, pouvant comporter une charge utile. 2.5 Inconvénients de l'art antérieur Selon l'art antérieur décrit ci-dessus, les NALUs de type AVC ne comportent pas d'informations spécifiques utiles au filtrage du flux, telles que les informations contenues dans les champs P, D, T et Q par exemple. Or, ces informations (telles que le niveau temporel permettant de réaliser la scalabilité temporelle, ou l'information d'image clé (indiquant que la NALU contient une slice d'image-clé) ou d'image de base (indiquant que la NALU contient une slice d'image de base)), permettent à un décodeur d'adapter le flux par suppression de NALUs. Pour remédier à ce problème, une solution a été proposée en introduisant un troisième type de NALU, appelée NALU suffixe. Ces NALUs suffixes sont optionnelles. Si elles existent, elles sont situées juste derrière la NALU AVC à laquelle elles se rapportent. Elles sont réduites à leur en-tête et à une information supplémentaire, dite charge informative, comportant notamment des données informatives sur la gestion des images de référence. Elles sont reconnaissables à leurs données d'en-tête car les valeurs des champs "Dependency_id" et "Quality_level" signalées sont simultanément à 0 pour, et seulement pour, les NALUs suffixes. Ces NALUs suffixe permettent donc d'associer à une NALU AVC des informations de filtrage du flux. Cependant, un inconvénient de ces NALUs suffixe réside dans le fait qu'étant réduites à leur en-tête et à leur charge informative, elles ne peuvent pas comprendre de charge utile et ne permettent donc pas d'avoir des données utiles de type SVC dans le niveau de base de la première couche ("Dependency_id" = "Quality_level" = 0). En particulier, dans le cas d'un profil dit "baseline", la syntaxe actuelle interdit d'ajouter des images B (prédites bi-directionnellement) dans le niveau de base AVC, bien qu'un tel rehaussement améliore considérablement les performances d'un codeur SVC "baseline". Un autre inconvénient de cette technique actuelle est qu'elle ne permet pas un traitement simple et facile à mette en oeuvre des NALUs AVC, dans le cas où l'on veut exploiter les informations de filtrage contenues dans une NALU suffixe. En effet, si on considère un flux SVC émis, comprenant un niveau de base AVC et un niveau de rehaussement SVC, chacun constitué de deux sous-flux à deux niveaux de fréquence temporelle différentes (15 Hz et 30 Hz) et si l'on veut réaliser une adaptation du flux pour garder uniquement le 15 Hz, il faudra, dans le décodeur SVC, au moment de la lecture des NALUs : ù pour les NALUs SVC (du niveau de rehaussement) : • lire l'en-tête des NALUs SVC (de type 20 ou 21) ; • en déduire le niveau temporel ; • conserver ou non la NALU. ù pour les NALUs AVC (du niveau de base) : • lire l'octet d'en-tête AVC (de type 1 ou 5) ; • se déplacer à la fin de la NALU AVC ; • lire une éventuelle NALU suffixe (de type 20 ou 21) ; • lire l'en-tête de la NALU suffixe si elle existe ; • en déduire le niveau temporel ; • conserver ou non la NALU. Ce traitement des NALUs AVC est lourd et complexe à mettre en oeuvre dans un réseau. 3. Exposé de l'invention L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de décodage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC. Selon l'invention, au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile, et un tel procédé de décodage comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, les étapes suivantes : - extraction dans l'en-tête d'une information indiquant la présence d'une charge utile dans ledit paquet d'en-tête de type SVC ; - si ladite information indique une absence de charge utile : affectation des données de scalabilité dudit entête à la charge utile d'un paquet de type 15 AVC précédant ledit paquet de type SVC ; - si ladite information indique une présence d'une charge utile : affectation des données de scalabilité de ladite entête à la charge utile dudit champ de données d'image. Ainsi, l'invention repose sur une approche nouvelle et inventive du 20 décodage de données dans un flux scalable, selon lequel on détermine la présence d'une charge utile, dans un niveau de base d'une première couche. Autrement dit, l'invention propose une nouvelle signalisation indiquant si une charge utile est présente dans une NALU SVC, ce qui permet d'accéder plus rapidement aux informations utiles et donc d'optimiser le temps de traitement des 25 NALUs SVC. En particulier, un paquet de données peut comprendre plusieurs champs de données, dont au moins un champ de données d'image. Selon un premier mode de réalisation, l'information de présence est un élément binaire inséré dans ledit entête. 30 Il s'agit par exemple d'un indicateur noté NALU_payload_flag.

Un tel indicateur n'existe pas., dans le projet de normalisation actuel. Son ajout permet la mise en oeuvre de l'invention, ainsi qu'une amélioration de l'efficacité du traitement des paquets SVC dans les couches de base (ceux-ci pouvant alors comprendre une charge utile, et donc ne pas être limités à leur rôle actuel de NALU suffix). Selon un deuxième mode de réalisation, l'étape d'extraction d'une information de présence met en oeuvre les étapes suivantes : - lecture de la valeur d'une desdites données de scalabilité représentative d'un niveau temporel (T); -génération d'une information de présence positive, si ladite valeur est supérieure à un seuil prédéterminé (Tmin). Cette approche permet de s'affranchir de la présence d'un nouvel indicateur dans chaque paquet, par rapport au projet de norme actuel. En revanche, elle suppose que le seuil prédéterminé soit défini préalablement.

Selon une première variante, le seuil prédéterminé (Tmin) peut être défini dans au moins un paquet associé à une image d'initialisation de flux (IDR), pour tous les paquets suivant ladite image d'initialisation jusqu'à réception d'une nouvelle image d'initialisation. Plus précisément, ce seuil est défini dans l'entête des paquets associés à 20 l' IDR. Selon une deuxième variante, le seuil prédéterminé (Tmin) est défini dans un ensemble de données de signalisation caractérisant ledit flux (SPS). Il est à noter que ces deux variantes peuvent être mises en oeuvre conjointement. 25 Dans un autre mode de réalisation, l'invention concerne un dispositif de décodage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche.

Selon l'invention, au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile et un tel dispositif comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, les moyens suivants : - extraction dans l'en-tête d'une information indiquant la présence d'une charge utile dans ledit paquet d'en-tête de type SVC ; - si ladite information indique une absence de charge utile : affectation des données de scalabilité dudit entête à la charge utile d'un paquet de type AVC précédant ledit paquet de type SVC ; - si ladite information indique une présence d'une charge utile : affectation des données de scalabilité de ladite entête à la charge utile dudit champ de données d'image. Un tel dispositif de décodage est notamment adapté à mettre en oeuvre le procédé de décodage décrit précédemment. Il s'agit par exemple d'un téléviseur, d'une set top box , d'un ordinateur, ....

Un autre aspect de l'invention concerne un procédé de codage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement. Les données sont organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, et le niveau de base d'au moins ladite première couche comprend des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC.

Selon l'invention, au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile et un tel procédé comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, une étape d'insertion dans l'entête d'une information indiquant la présence d'une charge utile dans ledit paquet de type SVC.

Selon un premier mode de réalisation, l'information de présence est un élément binaire inséré dans ledit entête. Selon un deuxième mode de réalisation, le procédé comprend une étape d'insertion d'au moins un seuil prédéterminé, dans au moins un paquet spécifique, ladite information de présence étant une donnée de scalabilité représentative d'un niveau temporel (T) destiné à être comparé audit seuil. Selon une première variante, ce seuil peut être défini dans un paquet associé à une image d'initialisation de flux (IDR). Selon une deuxième variante, ce seuil prédéterminé est défini dans un ensemble de données de signalisation caractérisant ledit flux (SPS). Les avantages du procédé de codage sont les mêmes que ceux du procédé de décodage et ne sont pas décrits plus en détail. Dans un autre mode de réalisation, l'invention concerne un dispositif de codage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche. Selon l'invention, au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile et un tel dispositif comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, des moyens d'insertion dans l'entête d'une information indiquant la présence d'une charge utile dans ledit paquet de type SVC. Un tel dispositif de codage est notamment adapté à mettre en oeuvre le procédé de codage décrit précédemment. Il s'agit par exemple d'un serveur de diffusion, comme un serveur de vidéo à la demande.

Un autre aspect de l'invention concerne un signal représentatif d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC.

Selon l'invention, un tel signal comprend au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile et au moins une information dans ledit entête indiquant la présence d'une charge utile dans ledit paquet de type SVC. Un tel signal peut notamment représenter un flux de données codé selon le procédé de codage décrit ci-dessus. Ce signal pourra bien sûr comporter les différentes caractéristiques relatives au procédé de codage selon l'invention. Selon un premier mode de réalisation, l'information de présence est un élément binaire inséré dans ledit entête. Selon un deuxième mode de réalisation, le signal porte aumoins un seuil prédéterminé, dans au moins un paquet spécifique, et l'information de présence est une donnée de scalabilité représentative d'un niveau temporel (T) destiné à être comparé audit seuil. Selon une première variante, le seuil peut notamment être défini dans un paquet associé à une image d'initialisation de flux (IDR).

Selon une deuxième variante, le seuil prédéterminé est défini dans un ensemble de données de signalisation caractérisant ledit flux (SPS). Ces deux variantes peuvent être mises en oeuvre conjointement. Un autre aspect de l'invention concerne un support de données portant au moins un signal tel que décrit précédemment. Un tel support est par exemple de type CD, DVD, disquette, etc. 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, comprenant des instructions de code de programme pour la mise en oeuvre du procédé de codage décrit précédemment, et/ou 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, comprenant des instructions de code de programme pour la mise en oeuvre du procédé de décodage présenté ci-dessus. 4. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de deux modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : - la figure 1, déjà décrite en relation avec l'art antérieur, présente schématiquement la structure en couches d'un flux scalable ; la figure 2, déjà décrite en relation avec l'art antérieur, illustre un exemple d'organisation en AUs et NALUs d'un flux scalable ; la figure 3, décrite en relation avec l'art antérieur, décrit un exemple de format d'une NALU SVC ; la figure 4 présente les principales étapes du procédé de décodage selon un premier mode de réalisation particulier de l'invention ; la figure 5 présente les principales étapes du procédé de décodage selon un deuxième mode de réalisation particulier de l'invention ; - la figure 6 présente les principales étapes du procédé de décodage selon une première variante d'un deuxième mode de réalisation particulier de l'invention ; la figure 7 présente les principales étapes du procédé de décodage selon une deuxième variante d'un deuxième mode de réalisation particulier de l'invention ; les figures 8 et 9 illustrent des contextes d'application de l'invention. les figures 10 et 11 illustrent des exemples d'application selon les deux modes de réalisation particuliers de l'invention. les figures 12A et 12B présentent respectivement la structure simplifiée d'un dispositif de décodage et d'un dispositif de codage selon l'invention. . Description d'un mode de réalisation de l'invention 5.1 Principe général Le principe général de l'invention repose sur la prise en compte, par un décodeur, d'une information permettant de signaler la présence ou l'absence d'une 5 charge utile dans une NALU SVC. 5.2 Premier mode de réalisation On présente d'abord un premier mode de réalisation du procédé de décodage et de codage selon l'invention, se basant sur un indicateur dédié, appelé par exemple "NALU_payload-flag", pour détecter la présence d'une charge utile, cet indicateur étant inséré dans l'en-tête d'une NALU SVC. On présente plus précisément les différentes étapes du décodage selon ce mode de réalisation de l'invention, en relation avec la figure 4. La première étape 41 est une étape d'extraction de l'indicateur de présence de charge utile, dans l'en-tête de la NALU SVC.

Une fois cet indicateur "NALU_payload-flag" extrait de l'en-tête, le décodeur teste sa valeur, lors d'une étape 42 de test. En fonction du résultat, le décodeur sait s'il doit effectuer un décodage d'une charge utile ou non. En effet, si l'indicateur "NALU_payload-flag" signale la présence d'une charge utile, le décodeur, lors d'une étape 43b, exploite les données de scalabilité présentes dans l'en-tête de la NALU SVC pour le décodage de la charge utile dont la présence a été détectée. Dans le cas contraire, si l'indicateur signale l'absence de charge utile, le décodeur, lors d'une étape 43a, affecte les données de scalabilité présentes dans l'en-tête de la NALU SVC pour le décodage de la charge utile de la NALU AVC précédent la NALU SVC correspondante. On présente ci-après un exemple de modification d'une partie de l'algorithme de décodage correspondant à ce premier mode de réalisation particulier : slice layer_in_scalable_extension_rbsp( ) { C Descriptor if (NALU_payload_flag = = 0) { //nouveau test pour NALU suffixe if ( nal_ref idc != 0) { store_base_rep_flag 2 u(1) if ( use_base_representation_flag && nal unit type != 21 ) dec_ref_pic_marking_base( ) } } else { //NALU avec payload AVC ou SVC slice_header in_scalable_extension() 2 Dans cet exemple, une valeur égale à 1 de l'indicateur "NALU_payloadflag" signale la présence d'une charge utile. Ainsi, ce mode de réalisation particulier de l'invention permet au décodeur SVC de détecter la présence ou non d'une charge utile dans la NALU, en décodant son en-tête et en testant la valeur de l'indicateur "NALU_payload-flag". De plus, le décodeur peut connaître, en fonction d'un second indicateur, déjà existant dans la syntaxe actuelle d'une NALU SVC et appelé "Iayer_base_flag", le type (SVC ou AVC) de la charge utile. On présente ci-dessous un exemple de la syntaxe d'un entête d'une NALU SVC permettant de signaler la présence ou l'absence d'une charge utile dans une NALU SVC: Na_unit header_svc_extension( ) { C Descriptor reserved_zero_two_bits All u(2) priority_id All u(6) temporal_level All u(3) dependency_id All u(3) quality_level All u(2) NALU_payload_flag //nouveau champ inséré All u(1) layer_base_flag All u(l) use_base_prediction_flag All u(1) discardable_flag All u(1) fragmented_flag All u(1) last fragment_flag All u(1) fragment_order All u(2) nalUnitHeaderBytes += 3 } Dans cet exemple, l'indicateur de présence de charge utile est donc inséré dans l'en-tête d'une NALU SVC, après les paramètres de scalabilité priority_id, temporal_level, dependency_id et quality_level (P, T, D et Q). Un exemple d'application de ce premier mode de réalisation particulier est présenté ci-dessous au paragraphe 5.3, dans le contexte d'un enrichissement d'une couche de base AVC par un niveau SVC comportant des images B (dans cette même couche). 5.2 Deuxième mode de réalisation On présente maintenant, en relation avec la figure 5, un deuxième mode de réalisation particulier de l'invention.

Dans ce deuxième mode de réalisation, le procédé de décodage se base sur la signalisation d'un niveau temporel au-delà duquel les NALUs SVC ont systématiquementt une charge utile associée. Cet indicateur est par exemple appelé "AVC_temporal_level_compatibility", noté également Tmin. Le principe est alors de détecter le niveau temporel signalé puis de le comparer, au moment de la lecture des informations de scalabilité de l'en-tête des NALUs SVC, au niveau temporel contenu dans ces informations de scalabilité. En fonction du résultat de cette comparaison, le décodeur sait si la NALU SVC contient ou non une charge utile à décoder. La figure 5 décrit les étapes du procédé de décodage selon ce deuxième 20 mode de réalisation particulier. L'étape 51 d'extraction permet au décodeur d'extraire du flux SVC l'indicateur de niveau temporel minimum "AVC_temporal_level_compatibility". Le décodeur décode ensuite les informations de scalabilité de l'en-tête de la NALU SVC lors d'une étape 52 de décodage, de manière à connaître le niveau 25 temporel T de cette NALU SVC. Lors d'une étape 53 de comparaison, le décodeur teste si T est supérieur ou inférieur à la valeur de "AVC_temporal_level_compatibility" pour détecter la présence ou non d'une charge utile. Dans cet exemple, si T >= "AVC_temporal_level_compatibility", le 30 décodeur détecte la présence d'une charge utile dans la NALU SVC.

Dans ce cas, le décodeur, lors d'une étape 54b, affecte les données de scalabilité présentes dans l'en-tête de la NALU SVC pour le décodage de la charge utile dont la présence a été détectée. Dans le cas où l'on a T < "AVC_temporal_level_compatibility", le décodeur, lors d'une étape 54a, affecte les données de scalabilité présentes dans l'en-tête de la NALU SVC pour le décodage de la charge utile de la NALU AVC précédent la NALU SVC correspondante. Par exemple, si "AVC_temporal_level_compatibility" = 2, les NALUs des niveaux temporels 0 et 1 n'ont pas de charge utile associée. Par contre, les NALUs de niveau temporel supérieur à 2 ont une charge utile associée à décoder. Plusieurs variantes sont possibles pour insérer l'information de niveau temporel minimum dans un flux SVC, parmi lesquelles les deux variantes décrites ci-dessous, en relation avec les figures 6 et 7, qui sont compatibles entre elles, c'est à dire qui peuvent être mises en oeuvre simultanément. 5.2.1 Première variante Dans cette première variante, les images de type "IDR" ("Instantaneous Decoding Refresh" pour rafraîchissement de décodage instantané) et de syntaxe SVC, encore appelées images d'initialisation, sont utilisées pour transporter la signalisation du niveau temporel minimum ("AVC_temporal_level_compatibility"), au-delà duquel le décodeur peut considérer que les NALUs SVC ont une charge utile associée. Plus précisément, cette information est insérée dans la charge informative de la NALU suffixe qui accompagne la NALU AVC du niveau de base d'une image de type "IDR".

Cet indicateur "AVC_temporal_level_compatibility" est valable pour toutes les NALUs suivant l'image IDR considérée et jusqu'à réception d'une nouvelle image IDR. La figure 6 décrit les étapes du procédé de décodage selon cette variante de réalisation.

Le décodeur extrait d'abord, lors d'une étape 61 d'extraction, l'indicateur de niveau temporel minimum de l'en-tête de la NALU suffixe suivant la NALU AVC du niveau de base de l'image IDR considérée. Les étapes 52 de décodage, 53 de comparaison, 54a et 54b d'affectation des données de scalabilité, inclues dans l'ensemble 62, sont répétées chaque fois que nécessaire tant qu'une nouvelle image IDR n'est pas reçue. Ces étapes sont identiques aux étapes 52, 53, 54a et 54b de la figure 5 décrites précédemment, et ne sont pas détaillées ici. On présente ci-dessous un exemple de syntaxe d'une partie de l'algorithme de décodage correspondant à cette variante de réalisation : slice_layer_in_scalable_extension_rbsp( ) { C Descriptor If(( dependency_id = = 0 && quality_level = = 0 ) && ((nal_unit type = = 21) // suffixe d'une IDR Il (nal_unit_type != 21 && tempora_level < AVC tempora_leve_compatibility) ) ) // suffixe non-IDR if( nal_ref idc != 0) { store_base_rep_flag 2 u(1) if ( use_base_representation_flag && nal_unit_type != 21 ) dec_ref_pic_marking_base( ) } if (nal_unit type = = 21) // suffixe IDR AVC_temporal_leve_compatibility u(3) } else { slice_header in_scalable_extension() 2 if( slice_type != PR ) slice_data in_scalable_extension() 2 1 3 1 4 else { if( fragmented_flag = = 1) { if( fragment_order = = 0 ) NumBytesInPRF = 0 while( entropy_coding_mode_flag && !byte_aligned() ) cabac_alignment_one_bit 2 f(1) if( fragment_order != 0) { while(rbtmp_byte[ NumBytesInPRF ] = = 0x00 NumBytesInPRF-NumBytesInPRF-- } while( more_rbsp_trailing_data() ) rbtmp_byte[ NumBytesInPRF++ ] 2 1 3 4 b(8) if( next nalu_not belongs_to_current PRF() ) swap_buffers( rbtmp_byte, rbsp_byte ) } if ( fragmented_flag = = 0 1 1 next nalu not belongs to current PRF ( ) ) Progressive_refinement slice_data in_scalable_extensionO 2 1 3 1 4 } if ( fragmented_flag = = 0 ~ 1 next nalu not belongs to_current PRF ( ) ) rbsp_slice_trailing_bits() 2 } } 5.2.2 Deuxième variante Dans cette deuxième variante, on utilise le SPS pour transporter la signalisation du niveau temporel minimum Tmin, au-delà duquel le décodeur peut considérer que les NALUs SVC ont une charge utile associée. Les étapes du procédé de décodage selon cette variante de réalisation sont décrites en relation avec la figure 7.

Lors de la première étape 71 d'extraction, le décodeur extrait le niveau temporel minimum "AVC_temporal_evel_compatibility" du paquet SPS. Cette information est donc valable pour toute la séquence du flux correspondant au paquet SPS considéré. Les étapes 52 de décodage, 53 de comparaison, 54a et 54b d'affectation des données de scalabilité, incluses dans l'ensemble 72, sont répétées chaque fois que nécessaire tant qu'un nouveau paquet SPS n'est pas reçu. Ces étapes sont identiques aux étapes 52, 53, 54a et 54b de la figure 5 décrites précédemment, et ne sont pas détaillées ici. On présente ci-après un exemple de syntaxe d'une partie de l'algorithme de 15 décodage correspondant à cette variante de réalisation : Slice_layer_in_scalable_extension_rbsp( ) { C Descriptor If(( dependency_id = = 0 && quality_evel = = 0 ) && (temporal_level < AVC_tempora_leve_compatibility) ) // suffixe If ( nal_ref idc != 0) { store_base_rep_flag 2 u(1) if ( use_base_representation_flag && nal_unit type != 21 ) dec_ref_pic_marking_base( ) } } else { slice header_in_scalable_extension( ) 2 } Un exemple de syntaxe d'une partie de la signalisation contenue dans un paquet SPS est présenté dans le tableau suivant : seq_parameter set svc_extension( ) { C Descriptor interlayer_deblocking_filter_control_present_flag 0 u(1) extended_spatial_scalability 0 u(2) if ( chroma format idc > 0) { chroma_phase_x_plusl 0 u(2) chroma_phase_y_plusl 0 u(2) } if( extended_spatial_scalability = = 1) { scaled_base_left offset 0 se(v) scaled_base_top_offset 0 se(v) scaled_base_right_offset 0 se(v) scaled_base_bottom_offset 0 se(v) } AVC_tempora_level compatibility // champ ajouté u(3) fgs_coding_mode 2 u(l) if( fgs_coding_mode = = 0) { grouping_size_minusl 2 ue(v) } else { numPosVector = 0 do { if( numPosVector = = 0) { scan_index0_minus1 2 ue(v) } else { delta scanindex minus1 [ numPosVector ] 2 ue(v) } numPosVector ++ } while( scanPosVectLuma[ numPosVectorù 1 ] < 15 ) } } 5.3 Contexte d'application On présente ci-après un exemple de contexte d'application particulier des procédés de décodage et de codage de l'invention, décrit ci-dessous en relation avec la figure 8.

Dans le contexte d'un codeur AVC, les images B, prédites bidirectionnellement, permettent d'améliorer de manière conséquente l'efficacité de codage. Elles offrent de plus une scalabilité temporelle immédiate. Il est donc souhaitable de pouvoir disposer de ces images B. Or, dans certains cas ou profils, notamment celui du profil "baseline" prévu pour les appareils de type mobile à faible complexité sur des réseaux avec pertes, ces images B ne sont pas autorisées par la norme actuelle. Autrement dit, comme déjà décrit dans les inconvénients de l'art antérieur, il n'est pas possible d'avoir une charge utile (dans cet exemple, la charge utile correspond à des données codées d'image B) dans un niveau de base AVC. Dans le cadre d'un codeur SVC, qui dispose d'un flux AVC existant, ne comportant pas d'images B, on se propose d'enrichir le niveau de base de la couche AVC par un niveau SVC (dans la même couche) comportant des images B. Or, selon la norme actuelle, les deux solutions les plus simples à mettre en oeuvre ne sont pas autorisées. La première de ces deux solutions consisterait à ajouter des images B entre les images I et P du niveau de base (caractérisé par les paramètres de scalabilité D=0 et Q=0). Mais, actuellement, ces images B seraient interprétées par un décodeur SVC comme des NALUs suffixe (car D=0 et Q=0), lesquelles NALUs suffixe ne pouvant pas avoir de charge utile associée. En d'autres termes, la charge utile correspondant aux données codées des images B ne serait pas décodée.

Une deuxième solution, consisterait à ajouter des images B entre les images I et P du niveau de base en créant une nouvelle couche D=1. Cette solution n'est pas autorisée car la norme SVC contraint à rehausser également les images I et P dans ce cas, de façon à garantir que toutes les AUs d'un même niveau soient complètes.

Une troisième solution, autorisée par la norme actuelle, mais complexe à mettre en oeuvre et peu efficace, est illustrée en relation avec la figure 9. Elle consiste à raffiner les images I et P, dans la nouvelle couche D=1, avant de générer les images B. Une des applications des différents modes de réalisation particuliers de l'invention, illustrée en relation avec les figures 10 et 11, permet de proposer une solution pour l'enrichissement d'une couche de base AVC par un niveau SVC comportant des images de rehaussernent dans cette même couche, permettant d'augmenter la fréquence temporelle et d'introduire de nouveaux outils non supportés par le profil associé au flux de base (par exemple CABAC) et pour le décodage de cet enrichissement.

Ainsi, comme illustrée en relation avec la figure 10, l'invention permet, selon le premier mode de réalisation particulier, d'ajouter des images B dans la couche de base AVC (caractérisée par D=0 et Q=0), en utilisant l'en-tête des NALUs SVC pour insérer une information de présence de charge utile.

La figure 1 l illustre quant à elle un exemple de rehaussement d'une couche de base AVC par des images B, en utilisant un indicateur de niveau temporel minimum au-delà duquel les NALUs ont une charge utile associée, correspondant au deuxième mode de réalisation particulier de l'invention décrit précédemment. Cet exemple correspond au cas où l'indicateur Tmin, encore appelé "AVC_temporal_level_compatibility", est égal à zéro, c'est à dire où le niveau 0 comporte des NALUs SVC ayant une charge utile associée. 5.4 Structures d'un dispositif de décodage et d'un dispositif de codage On présente finalement, en relation avec les figures 12A et 12B, la structure simplifiée d'un dispositif de décodage et d'un dispositif de codage mettant respectivement en oeuvre en oeuvre une technique de décodage et une technique de codage selon l'un des modes de réalisation particulier décrit ci-dessus. Un tel dispositif de décodage comprend une mémoire 121, une unité de traitement 122, équipée par exemple d'un microprocesseur P, et pilotée par le programme d'ordinateur 123, mettant en oeuvre le procédé de décodage selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 123 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 122. L'unité de traitement 122 reçoit en entrée le flux scalable S. Le microprocesseur de l'unité de traitement 122 met en oeuvre les étapes du procédé de décodage décrit précédemment, selon les instructions du programme d'ordinateur 123, pour décoder au moins un paquet de données du flux scalable S. Pour cela, le dispositif de décodage comprend des moyens d'extraction dans l'en-tête d'une information indiquant la présence d'un champ de données d'image dans au moins un paquet d'en-tête de type SVC. Ces moyens sont pilotés par le microprocesseur de l'unité de traitement 122. Un dispositif de codage comprend quant à lui une mémoire 124, une unité de traitement 125, équipée par exemple d'un microprocesseur P, et pilotée par le programme d'ordinateur 126, mettant en oeuvre le procédé de codage selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 126 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 125. L'unité de traitement 125 reçoit en entrée des données à coder. Le microprocesseur de l'unité de traitement 125 met en oeuvre les étapes du procédé de codage décrit précédemment, selon les instructions du programme d'ordinateur 126, pour générer un flux scalable S. Pour cela, le dispositif de codage comprend des moyens d'insertion dans l'entête d'une information indiquant la présence d'un champ de données dans ledit paquet de type SVC. Ces moyens sont pilotés par le microprocesseur de l'unité de traitement 125.

Claims (16)

REVENDICATIONS

1. Procédé de décodage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC, caractérisé en ce qu'au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile, et en ce qu'il comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, les étapes suivantes : - extraction dans l'en-tête d'une information indiquant la présence d'une charge utile dans ledit paquet d"en-tête de type SVC ; - si ladite information indique une absence de charge utile : affectation des 20 données de scalabilité dudit entête à la charge utile d'un paquet de type AVC précédant ledit paquet de type SVC ; - si ladite information indique une présence d'une charge utile : affectation des données de scalabilité de ladite entête à la charge utile dudit champ de données d'image. 25

2. Procédé de décodage selon la revendication 1, caractérisé en ce que ladite information de présence est un élément binaire inséré dans ledit entête.

3. Procédé de décodage selon la revendication 1, caractérisé en ce que ladite étape d'extraction d'une information de présence met en oeuvre les étapes suivantes :- lecture de la valeur d'une desdites données de scalabilité représentative d'un niveau temporel (T); - génération d'une information de présence positive, si ladite valeur est supérieure à un seuil prédéterminé (Tmin).

4. Procédé de décodage selon la revendication 3, caractérisé en ce que ledit seuil prédéterminé (Tmin) est défini dans au moins un paquet associé à une image d'initialisation de flux (IDR), pour tous les paquets suivant ladite image d'initialisation jusqu'à réception d'une nouvelle image d'initialisation.

5. Procédé de décodage selon l'une quelconque des revendications 3 et 4, caractérisé en ce que ledit seuil prédéterminé (Tmin) est défini dans un ensemble de données de signalisation caractérisant ledit flux (SPS).

6. Dispositif de décodage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC, caractérisé en ce qu'au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile, et en ce qu'il comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, les moyens suivants : - extraction dans l'en-tête d'une information indiquant la présence d'une charge utile dans ledit paquet d'en-tête de type SVC ;- si ladite information indique une absence de charge utile : affectation des données de scalabilité dudit entête à la charge utile d'un paquet de type AVC précédant ledit paquet de type SVC ; - si ladite information indique une présence d'une charge utile : affectation 5 des données de scalabilité de ladite entête à la charge utile dudit champ de données d'image.

7. Signal représentatif d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, 10 chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, 15 le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC, caractérisé en ce caractérisé en ce qu'il comprend au moins un paquet d'un niveau 20 de base comprenant un en-tête de type SVC et une charge utile et au moins une information dans ledit entête indiquant la présence d'une charge utile dans ledit paquet de type SVC.

8. Signal représentatif d'un flux de données selon la revendication 7, caractérisé en ce que ladite information de présence est un élément binaire inséré 25 dans ledit entête.

9. Signal selon la revendication 7, caractérisé en ce qu'il porte au moins un seuil prédéterminé, dans au moins un paquet spécifique, et en ce que ladite information de présence est une donnée de scalabilité représentative d'un niveau temporel (T) destiné à être comparé audit seuil.

10. Signal selon la revendication 9, caractérisé en ce que ledit seuil est défini dans un paquet associé à une image d'initialisation de flux (IDR).

11. Signal selon l'une quelconque des revendications 9 et 10, caractérisé en ce que ledit seuil prédéterminé est défini dans un ensemble de données de signalisation caractérisant ledit flux (SPS).

12. Support de données contenant au moins un signal selon l'une quelconque des revendications 7 à 11.

13. 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, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de décodage selon l'une quelconque des revendications 1 à 5.

14. Procédé de codage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, 15 comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge 20 utile, le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC, 25 caractérisé en ce qu'au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile, et en ce qu'il comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, une étape d'insertion dans l'entête d'une information indiquant la présence d'une charge utile dans ledit paquet de type SVC.

15. Dispositif de codage d'un flux de données représentatif d'une image ou d'une séquence d'images, présentant une organisation en couches de données, comprenant au moins une première couche, chaque couche comprenant un niveau de base et optionnellement au moins un niveau de rehaussement, lesdites données étant organisées en paquets de données (NALUs), comprenant un en-tête et optionnellement un champ de données d'image, portant une charge utile, le niveau de base d'au moins ladite première couche comprenant des paquets dont le champ de données d'image, s'il existe, est codé selon un premier type de codage, dit type AVC, que leur en-tête soit codé selon ledit type AVC ou selon un second type de codage, dit type SVC, caractérisé en ce qu'au moins un paquet d'un niveau de base comprend un en-tête de type SVC et une charge utile, et en ce qu'il comprend, pour chacun desdits paquets d'en-tête de type SVC dudit niveau de base, des moyens d'insertion dans l'entête d'une information indiquant la présence d'une charge utile dans ledit paquet de type SVC.

16. 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, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de codage selon la revendication 14.