Groupe de travail Réseau	S. Futemma, Sony
Request for Comments : 5371	E. Itakura, Sony
Catégorie : Sur la voie de la normalisation	A. Leung, Sony
Traduction Claude Brière de L'Isle	octobre 2008

Format de charge utile RTP pour flux vidéo JPEG 2000

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le présent mémoire décrit un format de charge utile RTP pour la norme internationale ISO/CEI 15444-1 | Recommandation UIT-T T.800, plus connue sous le nom de JPEG 2000. Les caractéristiques de JPEG 2000 sont examinées dans la conception de ce format de charge utile. JPEG 2000 est une technologie de compression vraiment adaptable qui permet aux applications de coder une fois et de décoder de nombreuses façons différentes. Le flux de vidéo JPEG 2000 est formé en étendant d’une seule image à une série d’images JPEG 2000.
Table des matières
1. Introduction	1
1.1 Conventions utilisées dans ce document	3
2. Caractéristiques de la vidéo JPEG 2000	3
3. Conception de la charge utile	3
4. Format de charge utile	4
4.1 Usage de l’en-tête fixe RTP	4
4.2 Format d’en-tête de charge utile RTP	4
5. Mise en paquet RTP	5
6. Enregistrement du type de support	6
7. Paramètres SDP	7
7.1 Transposition SDP	7
7.2 Usage avec le modèle d’offre/réponse SDP	8
8. Considérations relatives à l’IANA	9
9. Considérations sur la sécurité	9
10. Contrôle d’encombrement	10
11. Références	10
11.1 Références normatives	10
11.2 Références pour information	10
Appendice A. Appendice d‘information	11
A.1 Pratiques recommandées	11
A.2 Détails d’un échantillon d’en-têtes	11
Adresse des auteurs	17
Déclaration complète de droits de reproduction	17

 	1.	Introduction

Le présent document spécifie un format de charge utile pour les flux de vidéo JPEG 2000 sur le protocole de transport en temps réel (RTP, Real-time Transport Protocol). JPEG 2000 est une norme internationale de l’ISO/CEI et une Recommandation de l’UIT-T (Norme internationale ISO/CEI 15444-1 | Recommandation UIT-T T.800) développée pour la prochaine génération de compression d’image fixe. JPEG signifie Groupe conjoint d’experts en photographie, un groupe international de l’université et de l’industrie pour développer les normes de compression d’image. La technologie de base de JPEG 2000 est définie en détails dans ISO JPEG 2000 Partie 1 : Système de codage de base [T.800.1], avec le mouvement défini dans ISO JPEG 2000 Partie 3 : Mouvement JPEG 2000 [T.800.3].

La partie 3 de la norme JPEG 2000 définit le mouvement JPEG 2000 [T.800.3]. Cependant, le mouvement JPEG 2000 définit un format de fichier, pas un format de transmission pour le réseau. Le présent document spécifie un format de transmission pour le réseau pour une série d’images JPEG 2000.

JPEG 2000 prend en charge de nombreuses caractéristiques puissantes [T.800.1], [T.800.3] qui ne sont pas prises en charge dans la norme JPEG actuelle, comme :
o	une plus forte efficacité de compression que JPEG avec moins de distorsion visuelle en particulier à des taux de compression extrêmes,
o	un seul flux de codes qui offre à la fois la compression avec pertes et sans pertes,
o	une meilleure résilience à l’erreur que JPEG,
o	une transmission progressive par la précision de pixel (adaptabilité du rapport signal sur bruit (SNR, Signal-to-Noise Ratio)) et de résolution (adaptabilité de résolution),.
o	accès et traitement aléatoire du flux de codes.

L’algorithme JPEG 2000 est expliqué brièvement. La Figure 1 montre un diagramme de blocs de la méthode de codage JPEG 2000.

                                                    +-----+
                                                    | ROI |
                                                    +-----+
                                                       |
                                                       V
                  +----------+   +----------+   +--------------+
                  |DC, comp. |   |transform-|   |              |
  Image brute ==> |transform-|==>|  ation d’|==>|Quantification|==+
                  |  ation   |   |ondelettes|   |              |  |
                  +----------+   +----------+   +--------------+  |
                                                                  |
                 +-----------+   +----------+   +------------+    |
                 |  Ordre    |   |  Contrôle|   |            |    |
    JPEG 2000 <==|  des      |<==|  du      |<==| EBCOT      |<===+
 flux de codes   | données   |   | taux     |   |            |
                 +-----------+   +----------+   +------------+

Figure 1 : Diagramme de blocs du codeur JPEG 2000

L’image est d’abord transformée en coefficients d’ondelettes. L’image est échantillonnée en divers niveaux, verticalement et horizontalement, des hautes fréquences (qui contiennent des détails pointus) aux basses fréquences (qui contiennent des zones lisses). La quantification est effectuée sur les coefficients au sein de chaque sous-bande.

Après la quantification, des blocs de code sont formés à partir des districts au sein des pavés. (Les districts sont une séparation plus fines que les pavéx, et les blocs de code sont la plus petite séparation des données d’image.) Le codage de bloc incorporé optimisé pour la troncature (EBCOT, Embedded Block Coding Optimized for Truncation) est effectué au sein de chaque bloc de code et codé arithmétiquement par le plan binaire. Le contrôle de taux est effectué pour réaliser la meilleure qualité d’image pour le taux spécifié.

Par suite, pour un pavé donné, les unités de données appelées des paquets JPEG 2000 sont générées, qui contiennent les données provenant d’une couche spécifique, d’un composant spécifique, d’une résolution spécifique, ou d’un district spécifique, selon l’ordre des données.

Finalement, les paquets JPEG 2000 sont entrelacés en accord avec la progression selon quatre axes : couche, résolution, composant, et district. Un en-tête JPEG 2000 est ajouté pour devenir un flux de codes pleinement conforme à JPEG 2000 .

Pour décompresser un flux de codes JPEG 2000, on va suivre l’ordre inverse de celui du codage, sans le contrôle de taux.

Il sort du domaine d’application de ce document de décrire plus en détails cette procédure. Se référer aux divers textes relatifs à JPEG 2000 pour plus de détails [T.800.1].

La Figure 2 montre les détails du flux de codes JPEG 2000. Un flux de codes JPEG 2000 est structuré depuis l’en-tête principal, commençant par le marqueur de début du flux de codes (SOC, Start Of Codestream) un ou plusieurs pavés, et le marqueur de fin de flux de codes (EOC, End Of Codestream) pour indiquer la fin du flux de codes. Chaque pavé consiste en l’en-tête de la partie de pavé qui commence avec le marqueur Début de pavé (SOT, Start of Tile) et se termine par un marqueur début des données (SOD, Start of Data) et le flux binaire (une série de paquets JPEG 2000).

           +--  +------------+
  En-tête  |    |    SOC     |  Exigé comme premier marqueur
 principal |    +------------+
           |    | principal  |  Segments de marqueur d’en-tête principal
           +--  +------------+
           |    |    SOT     |  Exigé au début de chaque
   En-tête |    +------------+  en-tête de partie de pavé
 de partie |    |   T0,TP0   |  Pavé 0, segments de marqueur d’en-tête 
     pavé  |    +------------+  de partie de pavé 0 
           |    |    SOD     |  Exigé à la fin de chaque en-tête de partie de pavé
           +--  +------------+  
                |Flux de bits|  Flux binaire de partie de pavé
           +--  +------------+
           |    |    SOT     |
   En-tête |    +------------+
 de partie |    |   T1,TP0   |
     pavé  |    +------------+
           |    |    SOD     |
           +--  +------------+
                |Flux de bits|
                +------------+
                      .
                      .
                      .
                +------------+
                |    EOC     |  Exigé comme dernier marqueur dans le
                +------------+  flux de codes

Figure 2 : Construction de base du flux de codes JPEG 2000

 	1.1	Conventions utilisées dans ce document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Caractéristiques de la vidéo JPEG 2000

Les flux vidéo JPEG 2000 sont formés par une série continue d’images JPEG 2000 fixes. Les caractéristiques décrites précédemment de JPEG 2000 peuvent être utilisées efficacement dans des applications de flux de vidéo JPEG 2000. Un flux de vidéo JPEG 2000 a les qualités suivantes :

o	À bas débits, le SNR est considérablement amélioré sur JPEG et JPEG en mouvement.

o	Ceci est un plein format intra trame -- chaque frame est compressée indépendamment -- et a donc un faible délai de codage et de décodage.

o 	JPEG 2000 a un contrôle de taux souple et précis.

o	Cela convient pour le contrôle du trafic et de l’encombrement durant la transmission sur le réseau.

o	JPEG 2000 peut fournir ses propres marqueurs de résilience à l’erreur des flux de codes pour aider à la récupération de flux de codes en dehors de cette spécification.

 	3.	Conception de la charge utile

Pour concevoir un format de charge utile qui maximise les caractéristiques de JPEG 2000, on prend en considération :

o	Des dispositions sur les pertes  de paquet : sur l’Internet, 5 % de perte de paquet est courant et ce pourcentage peut varier jusqu’à 20 % ou plus. Pour partager les flux de vidéo JPEG 2000 en paquets RTP, une mise en paquets efficace des flux de codes est exigée pour minimiser les problèmes au décodage dus aux paquets manquants. Si l’en-tête principal est perdu, l’image ne peut pas être décodée.

o	Adaptabilité de JPEG 2000 : JPEG 2000 a des caractéristiques puissantes d’adaptabilité et des marqueurs dans l’en-tête de charge utile pour indiquer la signification spécifique de la charge utile, comme :
*	des marqueurs spéciaux pour les en-têtes, les fragments d’en-têtes, etc,
*	le numérotage des pavés pour l’association des paquets,
*	comme c’est principalement pour des applications de vidéo, des marqueurs spéciaux sont utilisés pour indiquer le format (c'est-à-dire, l’entrelacement des champs pairs/impairs),
*	la priorité des paquets en utilisant les méthodes décrites dans la [RFC5372],
*	la récupération de l’en-tête principal en utilisant les méthodes décrites dans la [RFC5372].

Un usage supplémentaire de l’en-tête de charge utile est décrit dans la [RFC5372].

 	4.	Format de charge utile
 	4.1	Usage de l’en-tête fixe RTP
Pour chaque paquet RTP, l’en-tête fixe RTP est suivi par l’en-tête de charge utile RTP JPEG 2000, qui est suivi par la charge utile, une partie d’un flux de codes JPEG 2000, qui est généralement un paquet JPEG 2000.

Les champs d'en-tête RTP qui ont une signification spécifique pour un flux vidéo JPEG 2000 sont décrits comme suit :

Bit marqueur (M) : le bit marqueur de l’en-tête fixe RTP DOIT être réglé à 1 pour le dernier paquet RTP d’une trame vidéo  ; autrement, il DOIT être 0. Quand la transmission est effectuée par plusieurs sessions RTP, ce bit est 1 dans le dernier paquet de la trame de chaque session.

Type de charge utile (PT, Payload Type) : le type de charge utile est alloué de façon dynamique par des moyens qui sortent du domaine d’application de ce document. Un type de charge utile dans la gamme dynamique devra être choisi au moyen d’un protocole de signalisation hors bande (c'est-à-dire, le protocole de flux en temps réel (RTSP, Real Time Streaming Protocol) SIP, etc.).

Horodatage : l’horodatage indique l’heure de présentation de la trame contenue dans le paquet RTP. La même valeur d’horodatage DOIT apparaître dans chaque paquet RTP portant un fragment d’une trame donnée. Quand une image JPEG 2000 est dans un format d’entre-laçage, le champ impair et le champ pair correspondant DOIVENT avoir la même valeur d’horodatage. Suivant la spécification de RTP [RFC3550], la valeur initiale de l’horodatage devrait être choisie au hasard.

Comme pour le taux d’horloge, les envoyeurs et les receveurs DOIVENT prendre en charge le taux d’horodatage RTP de 90  kHz, et PEUVENT prendre en charge d’autres taux. Des taux d’horodatage RTP inférieurs à 1000 Hz NE DEVRAIENT PAS être utilisés parce que ils vont résulter en une résolution insuffisante pour les mesures de protocole de contrôle RTP (RTCP, RTP Control Protocol (RTCP) fondées sur l’horodatage RTP, comme la gigue inter arrivées. Le taux d’horloge DOIT être négocié au début de la session. Quand on utilise le protocole de description de session (SDP, Session Description Protocol) il DOIT être exprimé en utilisant les attributs "rtpmap". Si un débit d’horloge différent de 90 kHz est utilisé, il est RECOMMANDÉ de ne pas présenter seulement un taux d’horloge préférable mais aussi un taux d’horloge de 90 kHz avec un type différent de charge utile RTP.

 	4.2	Format d’en-tête de charge utile RTP
Le format d’en-tête de charge utile RTP pour le flux vidéo JPEG 2000 est comme suit :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T|     Priorité  |        Numéro de pavé         |
+---+---+-----+-+---------------+---------------+---------------+
| réservé       |            Décalage de fragment               |
+---------------+---------------+---------------+---------------+

Figure 3: RTP charge utile header format for JPEG 2000

tp (type) : 2 bits. Ce champ indique comment une image JPEG 2000 est examinée (progressif ou entrelacé).
0 : La charge utile est examinée progressivement.
1 : La charge utile fait partie d’un champ impair d’une trame vidéo entrelacée. La hauteur spécifiée dans l’en-tête principal JPEG 2000 est la moitié de la hauteur de l’image affichée entière. Chez un receveur, un champ impair devrait être désentrelacé avec le champ pair qui le suit afin que les lignes provenant de chaque image soient affichées alternativement.
2 : La charge utile fait partie d’un champ pair dans un signal vidéo entrelacé.

MHF (Main Header Flag) fanion d’en-tête principal : 2 bits. le MHF indique si un en-tête principal ou paquet d’en-tête principal est dans le paquet RTP. Si il n’y a pas d’en-tête, le MHF a une valeur de 0. Si il y a juste une partie d’un en-tête fragmenté, le MHF a une valeur de 1. Si il y a la dernière partie d’un en-tête fragmenté, le MHF a la valeur 2. Si tout l’en-tête est dans le paquet, le MHF a la valeur 3.

Valeur de MHF	Description
0	pas d’en-tête princpal dans la charge utile
1	partie d’un en-tête fragmenté
2	dernière partie d’un en-tête fragmenté
3	en-tête principal entier

Tableau 1 : Valeurs d’usage de MHF

mh_id (Identification d’en-tête principal) : 3 bits. Valeur de l’identification d’en-tête principal. C’est utilisé pour la récupération de l’en-tête principal JPEG 2000. Pour les mises en œuvre qui suivent seulement la présente spécification, l'envoyeur DEVRAIT régler cette valeur à 0 et le receveur DEVRAIT ignorer ce champ.

T (Fanion d’invalidation du champ de pavé) : 1 bit. Le bit T indique si le champ Numéro de pavé est valide ou invalide. Un envoyeur DOIT régler le bit T à 1 quand il est invalide et à 0 quand il est valide. Il y a deux cas où le champ Numéro de pavé est invalide :
*	Quand un paquet RTP contient seulement l’en-tête principal. Un envoyeur ne peut pas mettre un nombre dans le champ Numéro de pavé, car aucun flux binaire de partie de pavé JPEG 2000 n’est inclus dans le paquet RTP.
*	Plusieurs parties de pavé sont regroupées ensemble dans une seule charge utile. Si il y a plusieurs pavés regroupés dans une seule charge utile, il n’y a pas de sens à allouer un numéro au champ Numéro de pavé.

Priorité : 8 bits. Le champ Priorité indique l’importance du paquet JPEG 2000 inclus dans la charge utile. Normalement, une valeur de priorité supérieure est mise dans les paquets JPEG 2000 qui contiennent les sous bandes inférieures. Pour les mises en œuvre qui suivent seulement la présente spécification, l'envoyeur DEVRAIT régler cette valeur à 255 et le receveur DEVRAIT ignorer ce champ.

Numéro de pavé : 16 bits. Ce champ montre le numéro de pavé de la charge utile. Il n’est valide que quand le bit T est 0. Si le bit T est réglé à 1, le receveur DOIT ignorer le champ.

Réservé : 8 bits. Cet octet est réservé pour une utilisation future. Les envoyeurs DOIVENT le régler à 0. Les receveurs DOIVENT ignorer ce champ.

Décalage de fragment : 24 bits. Cette valeur DOIT être réglée au décalage d’octet de la charge utile en cours en relation avec le début de chaque flux de codes JPEG 2000 (trame JPEG 2000). Les décalages d’octets sont calculés depuis le début de chaque flux de codes JPEG 2000 jusqu’à la position actuelle où la charge utile courante va tenir dans le flux de codes JPEG 2000 complet. Pour effectuer une livraison vidéo adaptable en utilisant plusieurs sessions RTP, la valeur de décalage à partir du premier octet de la même trame est réglée au décalage de fragment. Il est alors possible de livrer une vidéo en couches en utilisant plusieurs sessions RTP ; le décalage de fragment pourrait ne pas commencer à 0 dans certaines sessions RTP même si le paquet est le premier reçu dans la session RTP.

 	5.	Mise en paquet RTP

L’envoyeur doit mettre en paquets le JPEG 2000 de façon appropriée en accord avec les paramètres initiaux de type de support et/ou les détails des paramètres d’offre/réponse SDP.

Une "unité de mise en paquets" est définie comme un en-tête principal JPEG 2000, un en-tête de partie de pavé, ou un paquet JPEG 2000.

D’abord, un envoyeur divise le flux de codes JPEG 2000 en unités de mise en paquets en analysant le flux de codes ou en obtenant les informations du codeur, et met les unités de paquétisation en paquets RTP. Un envoyeur peut mettre un nombre arbitraire d’unités de paquétisation dans un paquet RTP, mais il DOIT préserver l’ordre du flux de codes. Un exemple de cette sorte de format de paquet RTP est montré à la Figure 4:

+-------+------------+-------------+-------------+
|En-tête| En-tête de |   Unité de  |   Unité de  |
|  RTP  |charge utile|paquétisation|paquétisation|
+-------+------------+-------------+-------------+

Figure 4 : Exemple avec plusieurs unités de paquétisation

Si une unité de mise en paquets avec des en-têtes (en-tête IP, en-tête RTP, et en-tête de charge utile) est supérieure à la taille de MTU, elle PEUT être fragmentée. Pour empaqueter une unité de mise en paquets fragmentée, l’unité fragmentée NE DOIT PAS être empaquetée avec l’unité de mise en paquets suivante au sein du même paquet RTP. Un exemple de cette sorte de format de paquet RTP est montré à la Figure 5:

   +-------+--------+-------------------------------------------------+
   |En-tête| En-tête| Fragment d’unité de paquétisation               |
   |  RTP  |ch. util|                                                 |
   +-------+--------+-------------------------------------------------+
   +-------+--------+-------------------------------------------------+
   |En-tête| En-tête| Fragment d’unité de paquétisation               |
   |  RTP  |ch. util|                                                 |
   +-------+--------+-------------------------------------------------+
              .
              .
              .
   +-------+--------+-------------------------------------------+
   |En-tête| En-tête| Fin de fragment d’unité de paquétisation  |
   |  RTP  |ch. util|                                           |
   +-------+--------+-------------------------------------------+

Figure 5 : Exemple d’unité de paquétisation fragmentée

 	6.	Enregistrement du type de support

Cet enregistrement utilise le gabarit défini dans la [RFC4288] et suit la [RFC4855].

Nom du type : video
Nom du sous type : jpeg2000
Paramètres exigés :
taux : taux d'horloge d'horodatage RTP. Par défaut 90000, mais d’autres tauxs PEUVENT être spécifiés. Les taux inférieurs à 1000 Hz NE DEVRAIENT PAS être utilisés.
échantillonnage : liste de valeurs spécifiant l’espace de couleur des données de charge utile.
Valeurs acceptables :
RGB : espace de couleur standard Rouge, Vert, Bleu.
BGR : espace de couleur standard Bleu, Vert, Rouge.
RGBA : espace de couleur standard Rouge, Vert, Bleu, Alpha.
BGRA : espace de couleur standard Bleu, Vert, Rouge, Alpha.
YCbCr-4:4:4 : espace de couleur standard YCbCr ; pas de sous échantillonnage.
YCbCr-4:2:2 : espace de couleur standard YCbCr ; Cb et Cr sont sous échantillonnés horizontalement par 1/2.
YCbCr-4:2:0 : espace de couleur standard YCbCr ; Cb et Cr sont sous échantillonnés horizontalement et verticalement par 1/2.
YCbCr-4:1:1 : espace de couleur standard YCbCr ; Cb et Cr sont sous échantillonnés verticalement par 1/4.
GRAYSCALE : fondamentalement, une seule image composante de juste plusieurs niveaux de gris.
VALEUR D’EXTENSION :  des échantillonnages de couleurs supplémentaires peuvent être enregistrés avec la liste courante des échantillons de couleurs enregistrés à : Color Sampling Registration Authority. Se référer au format RTP pour vidéo non compressée [RFC4175].

Paramètres facultatifs :
interlace : examen d’entrelacs. Si la charge utile est en format entrelacé, la valeur acceptable est "1" ; autrement, la valeur devrait être "0". Chaque image complète forme, verticalement, la moitié de l’affichage. La valeur tp DOIT correctement spécifier le champ que l’image représente : odd(tp=1) ou even(tp=2). Si cette option n’est pas présente, la charge utile DOIT être en format progressif et le tp DOIT être réglé à 0.
width : paramètre qui décrit la largeur maximum du flux vidéo. Ce paramètre DOIT apparaître quand hauteur est présent. Valeurs acceptables : valeur d’entier entre 0 et 4  294  967  295.
height :  paramètre qui décrit la hauteur maximum du flux vidéo. Ce paramètre DOIT apparaître quand largeur est présent. Valeurs acceptables : -- valeur d’entier entre 0 et 4  294  967  295.

Le receveur DOIT ignorer tous paramètres non spécifiés.

Considérations de codage : ce type de support est tramé et binaire, voir le paragraphe 4.8 de la [RFC4288].

Considérations de sécurité : voir la Section 9 de ce document.

Considérations d’interopérabilité : le flux vidéo JPEG 2000 est une séquence d’images fixes JPEG 2000. Une mise en œuvre conforme à [T.800.1] peut décoder et tenter d’afficher le flux vidéo codé JPEG 2000.

Spécification publiée : ISO/CEI 15444-1 | Recommandation UIT-T. T.800

Applications qui utilisent ce type de supports : flux vidéo et communication

Personnes et adresses de messagerie à contacter pour plus d’informations : 
Eisaburo Itakura, Satoshi Futemma, Andrew Leung 
mél : itakura@sm.sony.co.jp , satosi-f@sm.sony.co.jp, andrew@ualberta.net 

Usage prévu : COMMUN

Restrictions d’usage : ce type de supports dépend du tramage RTP, et n’est donc défini que pour le transfert via RTP [RFC3550]. Le transport dans d’autres protocoles de tramage n’est pas défini pour l’instant.

Auteurs: Eisaburo Itakura, Satoshi Futemma, Andrew Leung
Contrôleur des changements  : groupe de travail Transport audio/vidéo de l’IETF sur délégation de l’IESG.

 	7.	Paramètres SDP
 	7.1	Transposition SDP
Le type de support de chaîne video/jpeg2000 est transposé en champs dans le protocole de description de session (SDP, Session Description Protocol) [RFC4566] comme suit :

o 	Le nom de support dans la ligne "m=" de SDP DOIT être video.

o	Le nom du codage dans la ligne "a=rtpmap" de SDP DOIT être jpeg2000 (le sous type).

o	Le taux d’horloge dans la ligne "a=rtpmap" est réglé en accord avec le paramètre "rate". Les envoyeurs qui souhaitent utiliser un taux différent de 90 kHz DEVRAIENT aussi offrir le même flux en utilisant un taux d’horodatage de 90  kHz avec un type différent de charge utile RTP, permettant un repli en douceur sur le 90  kHz pour la compatibilité.

o	Le paramètre EXIGÉ, "sampling", DOIT être inclus dans la ligne "a=fmtp" de SDP.

o	Les paramètres FACULTATIFS, si il en est de présents, DOIVENT être inclus dans la ligne "a=fmtp" de SDP.

Ces paramètres sont exprimés comme une chaîne de type de supports, sous la forme d’une liste de paires paramètre=valeur séparées par des points-virgules.

Donc, un exemple de représentation de supports dans SDP en utilisant des paramètres normaux est comme suit :

m=video 49170/2 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128

Un exemple d’utilisation d’un horodatage non 90 kHz est comme suit :

m=video 49170/2 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128
a=fmtp:99 sampling=YCbCr-4:2:0;width=128;height=128

 	7.2	Usage avec le modèle d’offre/réponse SDP
Quand on offre JPEG 2000 sur RTP en utilisant SDP dans un modèle d’offre/réponse [RFC3264], les règles et limitations suivantes s’appliquent :

o	Tous les paramètres DOIVENT avoir une valeur acceptable pour le paramètre.

o	Tous les paramètres DOIVENT correspondre aux paramètres de la charge utile.

o	Le paramètre "sampling" avec une réponse acceptable DOIT apparaître dans l’offre et dans la réponse si il est accepté par le receveur. Le receveur DEVRAIT faire de son mieux pour traiter le flux de codes reçu dans l’espace de couleurs offert. Si le receveur ne peut pas traiter l’espace de couleurs offert pour une raison quelconque, il devrait répondre avec son espace de couleurs préféré et terminer la session en douceur. Les envoyeurs n’ont pas besoin de se conformer à l’espace de couleurs dans la réponse, mais ils devraient prendre note de ce que la session s’est terminée à cause des questions d’échantillonnage de couleurs.

o	Pour le paramètre facultatif "interlace", si cette option est utilisée, il DOIT apparaître dans l’offre et, si elle est acceptée, il DEVRAIT apparaître dans la réponse. Les receveurs devraient faire de leur mieux pour traiter les flux de codes entrelacés ou progressifs mais, si pour une raison quelconque, le receveur ne peut pas s’en accommoder, il devrait répondre avec ses réglages préférés dans la réponse, puis terminer la session en douceur. L’envoyeur n’a pas besoin d’ajuster ses réglages suite à cette réponse, mais il devrait prendre note que la session s’est terminée à cause de problèmes d’entrelacs ou progressif.

o	Pour les paramètres facultatifs "width" et "height", on applique ce qui suit :
*	si "width" apparaît dans l’offre ou la réponse, "height" DOIT être présent  ;
*	si "height" apparaît dans l’offre ou la réponse, "width" DOIT être présent.

o	Width et height devraient apparaître dans l’offre comme les dimensions maximales que l'envoyeur peut offrir. Dans la réponse, ils DEVRAIENT représenter le maximum dont le receveur peut s’accommoder. Si il y a une différence entre l’offre et la réponse, l'envoyeur devrait ré-offrir une nouvelle largeur et hauteur et diminuer en conséquence le flux de codes pour le receveur.

o	Dans un environnement de diffusion groupée, les receveurs conformes à la [RFC1112] devraient faire de leur mieux pour se conformer aux paramètres de l’offre de l'envoyeur. Les envoyeurs devraient utiliser les réglages recommandés dans les environnements de diffusion groupée et prendre note des réponses. Pour la largeur et la hauteur, l'envoyeur devrait s’accommoder des plus basses valeurs qu’il reçoit de toutes les réponses.

o	Toute option inconnue dans l’offre devrait être ignorée et supprimée de la réponse.

 	7.2.1	Exemples
Voici des exemples d’échanges d’offre/réponse.

Alice offre un espace de couleurs YCbCr 4:2:2, une image entrelacée d’une largeur de 720 pixels et d’une hauteur de 480  pixels :

v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480

Bob accepte l’espace de couleurs YCbCr-4:2:2, l’image entrelacée et répond :

v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1;width=720;height=480

 	7.2.2	Exemples : horodatages non à 90 kHz
Exemple d’échanges d’offre/réponse, où un offreur souhaite utiliser un horodatage non 90  kHz.

Alice offre un type de charge utile RTP avec un taux d’horloge de 27 MHz ainsi qu’un taux d’horloge de 90 kHz, et chaque type de charge utile inclut : espace de couleur YCbCr 4:2:2, entrelaçage d’image, largeur 720 pixels et hauteur de 480 pixels.

Elle met les attributs de taux d’horloge à 27 MHz avant le 90 kHz parce qu’elle veut l’utiliser plutôt que le 90  kHz.

v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:2;interlace=1;width=720;height=480
a=fmtp:99 sampling=YCbCr-4:2:2;interlace=1;width=720;height=480

Si Bob peut accepter le débit d’horloge de 27 MHz, il répond comme ceci :

v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/27000000
a=fmtp:98 sampling=YCbCr-4:2:2;interlace=1;width=720;height=480

Si Bob n'accepte pas le débit d’horloge de 27 MHz, il répond comme ceci :

v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 99
a=rtpmap:99 jpeg2000/90000
a=fmtp:99 sampling=YCbCr-4:2:2;interlace=1;width=720;height=480

 	8.	Considérations relatives à l’IANA

Un nouveau sous type de support (video/jpeg2000) a été enregistré par l’IANA. Pour les détails, voir la Section 6.

 	9.	Considérations sur la sécurité

Les paquets RTP  qui utilisent le format de charge utile défini dans cette spécification sont l’objet des considérations sur la sécurité discutées dans la spécification de RTP [RFC3550], et dans tout profil RTP applicable. Les principales considérations de sécurité pour le paquet RTP portant le format de charge utile RTP défini dans ce mémoire sont la confidentialité, l’intégrité, et l’authenticité de la source. La confidentialité est réalisée par le chiffrement de la charge utile RTP. L’intégrité des paquets RTP est réalisé par l’utilisation d’un mécanisme convenable de protection cryptographique de l’intégrité. Un système cryptographique peut aussi permettre l’authentification de la source de la charge utile. Un mécanisme de sécurité convenable pour ce format de charge utile RTP devrait assurer la confidentialité, la protection de l’intégrité, et au moins une méthode d’authentification de la source capable de déterminer si un paquet RTP est ou non en provenance d’un membre de la session RTP.

Noter que le mécanisme approprié pour fournir la sécurité à RTP et aux charges utiles qui suivent le présent mémoire peut varier. Il dépend de l’application, du transport, et du protocole de signalisation employé. Donc, un seul mécanisme n’est pas suffisant, bien que si il est convenable, l’usage de SRTP [RFC3711] soit recommandé. D’autres mécanismes qui peuvent être utilisés sont IPsec [RFC4301] et la sécurité de la couche transport (TLS, Transport Layer Security) [RFC5246] (RTP sur TCP), mais d’autres solutions de remplacement peuvent aussi exister.

 	10.	Contrôle d’encombrement

Si un service de qualité de service améliorée est utilisé, les receveurs RTP DEVRAIENT surveiller la perte de paquets pour s’assurer que le service qui était demandé est réellement fourni. Si il ne l’est pas, alors ils DEVRAIENT supposer qu’ils reçoivent un service au mieux et se comporter en conséquence.

Si le service au mieux est utilisé, les utilisateurs de ce format de charge utile DOIVENT surveiller la perte de paquets pour s’assurer que le taux de perte de paquets est dans des paramètres acceptables. La perte de paquets est considérée acceptable si un flux TCP à travers le même chemin de réseau, rencontrant les mêmes conditions de réseau, réaliserait un débit moyen, mesuré sur une durée raisonnable, qui n’est pas moins que le flux RTP réalisé. Cette condition peut être satisfaite en mettant en œuvre des mécanismes de contrôle de l’encombrement pour adapter le taux de transmission (ou le nombre de couches souscrit pour une session de diffusion groupée en couches) ou en s’arrangeant pour qu’un receveur quitte la session si le taux de pertes est inacceptablement élevé.

 	11.	Références
 	11.1	Références normatives
[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par RFC8843, 9143)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S. ; MàJ par 9335)

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

[RFC4855]	S. Casner, "Enregistrement du type de support des formats de charge utile RTP", février 2007. (P.S.)

[T.800.1]	Recommandation UIT-T T.800, aussi ISO/CEI 15444-1, "Technologie de l’information - Système de codage d’image JPEG 2000 – Partie 1 : Cœur du système de codage", décembre 2000.

 	11.2	Références pour information

[RFC1112]	S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", STD 5, août 1989. (Mise à jour par la RFC2236)

[RFC4175]	L. Gharai, C. Perkins, "Format de charge utile RTP pour vidéo non compressée", septembre 2005. (MàJ par RFC4421) (P.S.)

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", décembre 2005. (P.S.) (Remplace la RFC2401)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

[RFC5372]	A. Leung et autres, "Format de charge utile pour vidéo JPEG 2000 : extensions de mise à l'échelle et de récupération d'en-tête principal", octobre 2008. (P.S.)

[T.800.3]	Recommandation UIT-TT.800, aussi ISO/CEI 15444-1, "Technologie de l’information - Système de codage d’image JPEG 2000 – Partie 3 : JPEG 2000 animé", juillet 2002.

 	Appendice A.	Appendice d‘information
 	A.1	Pratiques recommandées
Comme la norme de codage JPEG 2000 est très souple, de nombreux flux de données différents mais conformes peuvent être produits et être toujours conformes aux flux de codes JPEG 2000.

Voici un ensemble de recommandations établies à partir de notre expérience du développement de JPEG 2000 et de cette spécification de charge utile. Les mises en œuvre de cette norme doivent traiter toutes les possibilités mentionnées dans cette spécification. Voici une liste des éléments qu’une mise en œuvre peut optimiser.

Marqueurs de résilience à l’erreur : l’utilisation de marqueur de résilience à l’erreur dans le flux de données JPEG 2000 est fortement recommandé dans toutes les situations. La récupération d’erreurs avec ces marqueurs est utile au décodeur et épargne les ressources externes (par exemple, les marqueurs comme RESET, RESTART, et ERTERM).

Espace de couleurs YCbCr : l’espace de couleurs YCbCr donné la plus grande quantité de compression de couleurs par rapport au système de vision humain. Quand il est utilisé avec JPEG 2000, cet espace de couleurs peut fournit d’excellents résultats visuels à de faibles débits binaires.

Ordre de progression : JPEG 2000 offre de nombreuses façons différentes d’ordonner le flux de codes final pour optimiser le transfert avec la présentation. On a trouvé que l’ordre de flux de codes le plus utile est la progression de couche et l’ordre de progression de résolution.

Pavés et paquets : les paquets JPEG 2000 sont formés sans égard à la méthode de codage. Le codeur a peu de contrôle sur la taille de ces paquets JPEG 2000 car ils peuvent être grands ou petits. Le pavage partage l’image en plus petites zones et chacune est codée séparément. Avec les pavés, les tailles de paquet JPEG 2000 sont aussi réduites. Quand on utilise le pavage, presque toutes les tailles de paquet JPEG 2000 sont de taille acceptable pour la transmission (c'est-à-dire, plus petites que la taille  de la MTU de la plupart des réseaux).

Traitement de l’envoyeur :  il n’y a pas de limitation à la façon dont l'envoyeur devrait empaqueter la charge utile. En général, l'envoyeur devrait empaqueter les en-têtes séparément du reste du flux de codes pour rendre la récupération d’en-tête simple. Les charges utiles devraient généralement commencer par un marqueur de début de paquet (SOP) et se terminer par un marqueur de fin d’en-tête de paquet (EPH) pour faciliter le traitement du décodeur.

 	A.2	Détails d’un échantillon d’en-têtes
Ce paragraphe donne divers exemples d’en-têtes dans diverses configurations pour référence.

Pour référence, l’en-tête de charge utile est comme suit :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T|     Priorité  |      Numéro de pavé           |
+---+---+-----+-+---------------+---------------+---------------+
|Réservé        |         Décalage de fragment                  |
+---------------+---------------+---------------+---------------+

Figure 6 : En-tête de charge utile JPEG 2000

 	A.2.1	Exemple 1 : Image progressive avec un seul pavé, 3500 octets (c'est-à-dire, concis)
Premier paquet : ce paquet va avoir tout l’en-tête principal de 210 octets
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 000 ....                                        |
+---------------+---------------+---------------+---------------+

Figure 7 : Échantillon d'en-tête 1-1 (premier paquet)

Second paquet : ce paquet va avoir un en-tête de pavé et la première partie du pavé LLband, 1500 octets
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 |  0  |0|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 2DB3 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+
Figure 8 : Échantillon d'en-tête 1-2 (second paquet)

Troisième paquet : ce paquet va avoir la partie suivante du pavé, pas d’en-tête de pavé 1500 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1710                      |
+---------------+---------------+---------------+---------------+
|E841 4526 4556 9850 C2EA ...                                   |
+---------------+---------------+---------------+---------------+

Figure 9 : Échantillon d'en-tête 1-3 (troisième paquet)

Quatrième paquet : dernier paquet pour l’image 290 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3210                      |
+---------------+---------------+---------------+---------------+
|A55D 8B73 3B25 25C7 B9EB ...                          2FBE B153|
+---------------+---------------+---------------+---------------+

Figure 10 : Échantillon d'en-tête 1-4 (4ième paquet)

 	A.2.2	Exemple 2 : image avec 4 pavés
Premier paquet : ce paquet va avoir tout l’en-tête principal, 210 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 000 ...                                         |
+---------------+---------------+---------------+---------------+

Figure 11 : Échantillon d'en-tête 2-1 (premier paquet)

Second paquet : ce paquet va avoir une première partie de pavé (pavé 0) 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 0578 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 12 : Échantillon d'en-tête 2-2 (second paquet)

Troisième paquet : ce paquet va avoir une seconde partie de pavé (pavé 1) 1423 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               1               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1610                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0001 0000 058F 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 13 : Échantillon d'en-tête 2-3 (troisième paquet)

Quatrième paquet : ce paquet va avoir une troisième partie de pavé (pavé 2) 1355 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               2               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3033                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0002 0000 054B 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 14 : Échantillon d'en-tête 2-4 (4th paquet)

Cinquième paquet : ce paquet va avoir une quatrième partir de pavé (pavé 3) 1290 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               3               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     4388                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0003 0000 050A 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 15 : Échantillon d'en-tête 2-5 (5th paquet)

 	A.2.3	Exemple 3 : empaquetage de plusieurs pavés dans une seule charge utile, en-tête fragmenté
Premier paquet : ce paquet va avoir la première partie de l’en-tête principal 110 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 000 ...                                         |
+---------------+---------------+---------------+---------------+

Figure 16 : Échantillon d'en-tête 3-1 (premier paquet)

Second paquet : ce paquet a la seconde partie de l’en-tête 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      110                      |
+---------------+---------------+---------------+---------------+
|FF64 00FF ...                                                  |
+---------------+---------------+---------------+---------------+

Figure 17: Échantillon d'en-tête 3-2 (second paquet)

Troisième paquet : ce paquet a deux pavés, le pavé 0 et le pavé 1  : 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1510                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 02BC 0001 FF93 ...                         |
//                                                             //
|FF90 000A 0001 0000 02BC 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 18 : Échantillon d'en-tête 3-3 (troisième paquet)

Quatrième paquet : ce paquet a un pavé, le pavé 2, 1395 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|      255      |               2               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     2910                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0002 0000 0573 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 19 : Échantillon d'en-tête 3-4 (4ième paquet)

 	A.2.4	Exemple 4 : Image entrelacée, un seul pavé
Premier paquet : ce paquet va avoir tout l’en-tête principal pour le champ impair, 210 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 3 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 000 ...                                         |
+---------------+---------------+---------------+---------------+

Figure 20: Échantillon d'en-tête 4-1 (premier paquet)

Second paquet : ce paquet va avoir la première partie du pavé du champ impair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 0578  0001 FF93 ...                        |
+---------------+---------------+---------------+---------------+

Figure 21 : Échantillon d'en-tête 4-2 (second paquet)

Troisième paquet : ce paquet va avoir la seconde partie du pavé du champ impair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1610                      |
+---------------+---------------+---------------+---------------+
|7F04 E708 27D9 D11D 22CB ...                                   |
+---------------+---------------+---------------+---------------+

Figure 22 : Échantillon d'en-tête 4-3 (troisième paquet)

Quatrième paquet : ce paquet va avoir la troisième partie du pavé du champ impair, 1300 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3010                      |
+---------------+---------------+---------------+---------------+
|98BD EC9B 2826 DC62 D4AB ...                                   |
+---------------+---------------+---------------+---------------+

Figure 23 : Échantillon d'en-tête 4-4 (4ième paquet)

Cinquième paquet : ce paquet va avoir tout l’en-tête principal du champ pair, 210 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 3 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 000 ...                                         |
+---------------+---------------+---------------+---------------+

Figure 24: Échantillon d'en-tête 4-5 (5ième paquet)

Sixième paquet : ce paquet va avoir la première parte du pavé du champ pair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 0578  0001 FF93 ...                        |
+---------------+---------------+---------------+---------------+

Figure 25 : Échantillon d'en-tête 4-6 (6ième paquet)

Septième paquet : ce paquet va avoir la seconde partie du pavé du champ pair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1610                      |
+---------------+---------------+---------------+---------------+
|626C 42F0 166B 6BD0 F8E1 ...                                   |
+---------------+---------------+---------------+---------------+

Figure 26 : Échantillon d'en-tête 4-7 (7ième paquet)

Huitième paquet : ce paquet va avoir la troisième partie du pavé du champ pair, 1300 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |  0  |1|      255      |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3010                      |
+---------------+---------------+---------------+---------------+
|8114 41D5 18AB 4A1B ...                                        |
+---------------+---------------+---------------+---------------+

Figure 27 : Échantillon d'en-tête 4-8 (8ième paquet)

 	Adresse des auteurs

Satoshi Futemma	Eisaburo Itakura	Andrew Leung	
Sony Corporation	Sony Corporation	Sony Corporation	
1-7-1 Konan	1-7-1 Konan	mél : andrew@ualberta.net	
Minato-ku	Minato-ku		
Tokyo  108-0075	Tokyo  108-0075		
Japan	Japan		
mél : satosi-f@sm.sony.co.jp	mél : itakura@sm.sony.co.jp		
URI : http://www.sony.net/	URI : http://www.sony.net/		

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est fourni par l'activité de soutien administratif de l'IETF (IASA).