Groupe de travail Réseau	D. Singer, Apple Computer Inc.
Request for Comments: 5484	mars 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Association des codes de temps aux flux RTP

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Le présent document décrit un mécanisme pour associer les codes de temps, tels que définis par la société des ingénieurs d'images animées et de télévision (SMPTE, Society of Motion Picture and Television Engineers) avec des flux de supports d'une façon indépendante du format de charge utile RTP du flux de supports lui-même.
Table des matières
1. Introduction	1
2. Notation des exigences	2
3. Objectifs de la conception	2
4. Exigences et contraintes	2
5. Informations de signalisation	3
6. Informations dans le flux	4
6.1 Format compact du code de temps	4
6.2 Format complet du code de temps	4
6.3 Associations dans RTCP	5
6.4 Associations dans RTP	6
7. Note de mise en œuvre (information)	6
8. Discussion (information)	6
9. Considérations sur la sécurité	7
10. Considérations relatives à l'IANA	7
11. Remerciements	7
12. Références	7
12.1 Références normatives	7
12.2 Références pour information	8
Adresse de l'auteur	8

 	1.	Introduction

D'abord un bref retour sur les codes de temps [SMPTE-12M].

Le système du code de temps couramment utilisé est défini par la société des ingénieurs d'images animées et de télévision (SMPTE, Society of Motion Picture and Television Engineers) ; dans ce système, les codes de temps comptent des trames. Une forme courante de l'affichage ressemble à une valeur d'horloge normale (hh:mm:ss.trame). Quand le débit de trame est vraiment entier, cela peut être une valeur d'horloge normale, en ce que les secondes s'écoulent au même rythme que les secondes qu'on connaît et qu'on aime.

Cependant, la vidéo NTSC s'écoule honteusement légèrement plus lentement que 30 trames par seconde (tps). Certains l'appellent 29,97, ce qui n'est  pas tout à fait exact ; pour être précis, une trame prend 1001 tics d'une horloge à 30  000  tic/s.  Quoi qu'il en soit, les codes de temps SMPTE comptent 30 de ces trames et prétendent  que cela fait une seconde.

Cela cause un affichage de code de temps SMPTE "en retard" par rapport au temps réel. Pour améliorer cela, un format appelé "abandon de trame" est parfois utilisé. Certains des numéros de trame sont sautés, afin que le compteur "rattrape" périodiquement (de sorte que certaines secondes de code de temps ont en, fait seulement 28 trames).

On notera qu'en aucun cas le code de temps SMPTE n'est une horloge précise ; dans le premier cas, il va trop lentement, dans le second, les ajustements sont brusques et périodiques -- et quand même pas très précis. Donc le reste de ce document essaye d'être clair quand il se réfère à une seconde dans un code de temps comme à une "seconde de code de temps".

Cependant, les codes de temps SMPTE fonctionnent en temps réel quand ils sont utilisés avec des systèmes avec des tps entières (par exemple, un contenu de film à 24 tps ou de la vidéo PAL).

La présente spécification définit comment porter des codes de temps dans RTP et RTCP (protocole de contrôle RTP) les associer à un flux de supports, et les synchroniser avec les horodatages RTP. Elle utilise le mécanisme général d'extension d'en-tête RTP [RFC5285].

 	2.	Notation des exigences

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],.

 	3.	Objectifs de la conception

Ce qu'on désire est un système qui permette d'associer un code de temps SMPTE avec un support dans un flux RTP [RFC3550]. Comme dans RTP tous les supports ont déjà une horloge, on peut souvent s'appuyer sur ce fait. Si on traite le support comme ayant des "segments" de temps dans lesquels le code de temps compte simplement, alors le code de temps n'importe où dans un segment peut être calculé si on connaît :
o	l'horodatage RTP du début du segment,
o	le code de temps du début du segment,
o	le taux de comptage et les autres paramètres du code de temps,
o	l'horodatage RTP où on veut connaître le code de temps.

Il y a deux cas à considérer :
1.	les codes de temps sont continus pièce à pièce avec seulement des discontinuités occasionnelles ;
2.	la continuité des codes de temps n'est pas certaine (ou pas connue).

Le premier peut être traité en fournissant les détails de l'axe de code de temps et une transposition initiale de l'heure RTP en heure de code de temps ainsi que les transpositions périodiques en paquets RTCP. C'est défini au paragraphe 6.3.

Le second exige une signalisation dans la bande au sein des paquets RTP eux-mêmes. C'est défini au paragraphe 6.4.

Il y a des applications où le transport de tous 8 octets de code de temps SMPTE 12M est important (par exemple, quand la date du code de temps doit être connue ou quand le transport RTP est utilisé comme tuyau transparent). Par ailleurs, il y a des cas (par exemple, quand les codes de temps sont utilisés avec de l'audio compressé) quand la bande passante est aussi importante. Pour prendre en charge ces deux cas d'utilisation, des dispositions sont prises pour à la fois compacter et  former complètement le code de temps.

 	4.	Exigences et contraintes

Les receveurs DOIVENT prendre en charge les codes de temps dans RTCP et dans RTP ainsi que les deux formes (compacte et pleine) de code de temps. Les envoyeurs ont bien sûr la liberté du choix.

Noter que la forme compacte permet des numéros de trame supérieurs à ceux de la forme complète (un champ de 6 bits contre un chiffre décimal codé en binaire (BCD, binary-coded decimal) complet et un chiffre BCD de 2 bits qui donne une valeur maximale transmise de 29). Dans certains cas, le fanion de trame de couleur (bit 11) est utilisé pour "étendre" le champ "dizaines de trames" de 2 à 3 bits ; cependant, de telles pratiques sortent du domaine de cette spécification.

Dans le cas où une présentation contient plus d'un flux, les envoyeurs DOIVENT continuer d'envoyer les informations standard de synchronisation RTP dans RTCP, même si les flux portent des codes de temps SMPTE qui pourraient être utilisés pour la synchronisation. En fait, quand des codes de temps sont portés par plus d'un flux, le présent document ne contraint pas les codes de temps : à un moment donné, ils peuvent être les mêmes, oi ils peuvent différer (par exemple, si ils portent les codes de temps originaux de différents matériels de source qui ont été  édités ensemble).

 	5.	Informations de signalisation

Si le receveur doit calculer des codes de temps fondés sur les temps de RTP, des informations d'établissement sont nécessaires. Cela DOIT être envoyé hors bande -- par exemple, dans un échange d'offre/réponse SIP [RFC3264]. Comme la présente spécification est une extension générale d'en-tête [RFC5285], quand le protocole de description de session (SDP, Session Description Protocol ) est utilisé, l'attribut "extmap" défini par le mécanisme d'extension est aussi utilisé.

Les informations d'établissement devraient inclure :
1.	La durée, dans l'échelle des temps RTP, d'un seul compte de trame dans la portion "trames" du code de temps (frame_duration)
2.	Le nombre de ces trames qui constitue une seconde de code de temps (frames_per_tc_second) ; les valeurs de framecounter peuvent être entre 0 et (frames_per_tc_second - 1)
3.	L'indication d'abandon de trame, is-NTSC-drop-frame, qui indique si le comportement habituel d'abandon de trame devrait ou non être appliqué.

Noter que d'autres informations dont on a besoin pour faire le calcul (par exemple, le débit d'horloge de l'horodatage RTP) sont déjà fournies et supposées disponibles.

Par exemple, si elle est associée à un flux de vidéo avec l'échelle de temps courante de 90 000 tics par seconde, alors une durée de trame de 3003 et une "frames-per-tc-second" de 30 va donner un code de temps SMPTE "normal" pour la vidéo NTSC. De même, des valeurs de 3750 et 24 donnent un code de temps pour un contenu de film de 24 tps, et ainsi de suite

Noter aussi qu'on fournit explicitement la durée de trame et le tps, même si ils sont évidemment en relation étroite. Cela supprime toute ambiguïté sur ce que devraient être les valeurs de compteur dans le cas de comptage d'abandon de trame. Ces trois valeurs DOIVENT correspondre les unes aux autres.

Quand SDP est utilisé, ces trois paramètres sont transmis comme des attributs d'extension, comme défini dans la spécification d'extension d'en-tête [RFC5285], avec la syntaxe ABNF suivante [RFC5234]. La forme des attributs d'extension est "possédée" par le nom d'extension. Ces paramètres de l'extension n'ont pas besoin d'action d'enregistrement au delà de leur documentation ici. Noter que les paramètres sont fournis comme des attributs d'extension, convenables pour l'utilisation en ligne dans RTP, même si dans un flux donné seule la transposition RTCP est utilisée.

digit = "0"/"1"/"2"/"3"/"4"/"5"/"6"/"7"/"8"/"9"	(chiffre)

integer = 1*digit	(entier)

frame-duration-length = integer	(longueur de durée de trame)

timestamp-rate = integer	(taux d'horodatage)

frame-duration = frame-duration-length "@" timestamp-rate	(durée de trame)

frames-per-tc-second = integer	(trames par tic de seconde)

drop = "/drop"	(abandon)

extensionattributes = frame-duration "/" frames-per-tc-second [drop]	(attributs d'extension)

La durée de trame est spécifiée comme un compte de tics d'une horloge qui a "taux d'horodatage" tics par seconde. Il est recommandé que le taux d'horodatage soit le même que le débit d'horloge du flux RTP dans lequel l'extension est incorporée, pour éviter une perte de précision dans la conversion des horodatages. Si le type de charge utile change durant un flux, en particulier entre des charges utiles avec des débits d'horloge différents, il est fortement recommandé que l'extension d'en-tête soit incluse dans le premier paquet de la nouvelle charge utile, pour établir explicitement la transposition pour le nouveau débit d'horloge.

Si "/drop" est spécifié, alors les deux premiers numéros de trame sont omis du compte de chaque minute, sauf pour les minutes 00, 10, 20, 30, 40, et 50, comme documenté au paragraphe 4.2.2 de la spécification SMPTE [SMPTE-12M]. (Noter que cela ne s'applique généralement qu'à la vidéo NTSC.)

L'URI utilisé pour la signalisation est "urn:ietf:params:rtp-hdrext:smpte-tc".

Cet URI signale la présence possible d'associations dans RTCP ou RTP, comme défini ci-dessous.

Un exemple dans SDP, pour du matériel de film, sur un flux avec une échelle de temps de 600, pourrait être :

a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24

Un autre exemple, pour un abandon de trame NTSC, sur un flux avec une échelle de temps de 600, pourrait être :

a=extmap:4 urn:ietf:params:rtp-hdrext:smpte-tc 20@600/30/drop

 	6.	Informations dans le flux
 	6.1	Format compact du code de temps
Un code de temps SMPTE compact binaire dans ce schéma occupe 24 bits. Il N'EST PAS formaté dans le système BCD, mais utilise des champs binaire de largeur fixe. Il a la structure suivante :
signe(1)  -- 1 pour négatif, 0 pour positif
heures (5 bits)  -- 0 à 23 ; les valeurs 24 à 31 sont réservées
minutes (6 bits)  -- 0 à 59 ; 60 à 63 sont réservées
secondes (6 bits)  -- 0 à 59 ; 60 à 63 sont réservées
trames(6 bits)  -- 0 à (frames-per-tc-second - 1)

Noter que ces champs sont plus grands que la disposition de SMPTE 12M, où le BCD (décimal codé binaire) est utilisé (et notamment, lorsque seulement deux bits sont fournis pour le chiffre des dizaines du compte de trame, de sorte que les numéros de trame au dessus de 39 ne peuvent pas être représentés).

 	6.2	Format complet du code de temps
Un code de temps SMPTE complet occupe 64 bits. Il est formaté exactement comme défini aux Sections 7 et 8 de SMPTE 12M [SMPTE-12M], sans le mot de synchronisation de 16 bits. La valeur du "fanion d'abandon de trame" DOIT être en accord avec l'utilisation de l'indicateur "drop" dans la signalisation.

Voici, pour information, l'allocation des bits de SMPTE 12M :
0 à 3	Unités de trames
4 à 7 	Premier groupe binaire
8 à 9	Dizaines de trames
10	Fanion d'abandon de trame
11	Fanion de trame de couleur
12 à 15	Second groupe binaire
16 à 19	Unités de secondes
20 à 23	Troisième groupe binaire
24 à 26	Dizaines de secondes
27	Correction de polarité 
28 à 31	Quatrième groupe binaire
32 à 35	Unités de minutes
36 à 39	Cinquième groupe binaire
40 à 42	Dizaines de minutes
43	Fanion de groupe binaire BGF0
44 à 47	Sixième groupe binaire
48 à 51	Unités d'heures
52 à 55	Septième groupe binaire
56 à 57	Dizaines d'heures
58	Fanion de groupe binaire BGF1
59	Fanion de groupe binaire BGF2
60 à 63	Huitième groupe binaire

 	6.3	Associations dans RTCP
Quand les codes de temps sont continus pièce par pièce, on fournit alors dans les paquets RTCP un horodatage RTP et un code de temps SMPTE pour le début de chaque tour de codes de temps calculables. Cela établit le code de temps pour tous les temps RTP supérieurs ou égaux à celui donné, jusqu'à ce qu'un paquet RTCP suivant rétablisse la transposition.

Noter que l'horodatage RTP dans la transposition RTCP peut ne pas correspondre à une trame dans le flux de supports. Pour la vidéo, il va normalement correspondre ; mais une transition d'horodatage peut se produire à mi-chemin par une trame audio décodée. Comme elles partagent la même horloge, le temps de cette transition et le temps du flux audio lui-même ont la même précision.

Les paquets RTCP n'ont pas besoin d'utiliser le même horodatage RTP que le rapport d'envoyeur (ou l'heure de transmission) dans le même paquet RTCP. Ils peuvent être envoyés "avant le besoin", si possible (par exemple, pour un contenu mémorisé, quand le serveur peut prévoir) ou "juste à temps". Par exemple, les paquets envoyés "juste à temps" peuvent être envoyés comme des paquets de rétroaction précoces, suivant les règles de la [RFC4585], après la détection d'une discontinuité dans les codes de temps. De tels paquets permettent à la mise en mémoire tampon chez le client d'avoir une chance "d'attraper" le RTCP avant que le paquet RTP correspondant soit traité et affiché.

L'association est un nouveau type de paquet de contrôle RTCP, utilisant la valeur 194 (voir la Section 10). Ce paquet de contrôle a une des deux formes suivantes, qui diffèrent par leur longueur.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    SC   |PT=SMPTETC=194 |           Longueur=3          |
+---+-+---------+---------------+---------------+---------------+
|                     SSRC de l'envoyeur du paquet              |
+---------------+---------------+---------------+---------------+
|                         Horodatage RTP                        |
+---------------+---------------+---------------+---------------+
|S|  heures |  minutes  |  secondes |  trames   |  réservé = 0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+

Figure 1 : Paquet RTCP en forme courte

Les champs S (signe), heures, minutes, secondes, et trames sont définis au paragraphe 6.1.
Pour cette forme courte, la longueur prend la valeur fixe de 3, indiquant un paquet de contrôle de 4 mots de 32 bits.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    SC   |PT=SMPTETC=194 |           Longueur=4          |
+---+-+---------+---------------+---------------+---------------+
|                     SSRC de l'envoyeur du paquet              |
+---------------+---------------+---------------+---------------+
|                         Horodatage RTP                        |
+---------------+---------------+---------------+---------------+
|                     Code de temps SMPTE 12M                   |
|                       complet sur 8 octets                    |
+---------------+---------------+---------------+---------------+

Figure 2 : Paquet RTCP en forme complète

Pour ce code de temps complet (forme longue) la longueur prend la valeur fixe de 4, indiquant un paquet de contrôle de 5  mots de 32 bits.

 	6.4	Associations dans RTP
Quand les codes de temps ne son pas continus pièce par pièce, ou quand une sûreté de transposition absolue est désirée, alors la transposition peut être placée dans certains ou tous les paquets RTP. C'est un chemin moins désirable ; il utilise l'extension d'en-tête RTP [RFC5285], que certains terminaux peuvent trouver problématique. Et il est clair que placer les informations de transposition dans chaque paquet utilise plus de bande passante.

Dans autant de paquets RTP que nécessaire (éventuellement tous) une extension d'en-tête RTP est utilisée [RFC5285] pour associer un temps RTP à un code de temps SMPTE.

Il y a deux formes de cette extension d'en-tête, là encore différenciées par leur longueur. La forme courte associe un code de temps compact à l'horodatage RTP du paquet. La forme longue permet d'associer un code de temps complet à un décalage d'horodatage par rapport à l'horodatage RTP du paquet.

La forme courte a une longueur de 3 octets (24 bits). La forme longue a une longueur de 12 octets (96 bits) et consiste en un code de temps SMPTE 12M complet, suivi par un décalage signé de 32 bits D par rapport à l'horodatage RTP. Si le paquet a l'horodatage T, cela fait que RTP établit une association de code de temps pour l'instant RTP T+D.

 	7.	Note de mise en œuvre (information)

Cette section contient une suggestion sur la façon de calculer un code de temps pour un instant T2, étant donnés un code initial à l'instant T1, et la durée de trame.

Il pourrait sembler que quand l'abandon de trame est utilisé, il y a un problème de "piquet de clôture" : combien de minutes pendant lesquelles des numéros de trame ont été éliminés se sont passées depuis le code de temps initial ? Cependant, cela peut être évité si tous les calculs sont "fondés sur zéro" ; alors le nombre de "piquets de clôture" est connu.

framesSinceTCzero := TimeCodeToFrameCount( initialTimeCode );
framesSinceMapping := floor( (T2-T1)/frameDuration );
totalFrames := framesSinceTCzero + framesSinceMapping;
timeCode := FrameCountToTimeCode( totalFrames );

Les lignes directrices pour l'ingénierie de SMPTE [SMPTE-EG40] contiennent toutes les équations, constantes, etc., appropriées pour effectuer ces conversions et les autres.

 	8.	Discussion (Information)

Cette conception présente l'avantage de ne pas exiger l'introduction de nouveaux paquets IP dans les sessions ou de nouvelles données dans le principal canal de données en utilisant une faible bande passante (presque inexistante dans le cas de flux sans discontinuités) et d'être indépendante de la conception des paquets RTP eux-mêmes : le profil RTP (incluant un éventuel chiffrement) et le format de charge utile RTP. Les codes de temps SMPTE peuvent être associés à tout flux RTP, y compris ceux qui ont des formats de charge utile existants.

On pourrait objecter qu'on pourrait établir la transposition initiale aussi dans SDP, car les paquets RTCP pourraient être perdus. Mais cela signifie que le SDP doit alors avoir connaissance du décalage aléatoire RTP, ce qui est désagréable ; aussi, si on met le paquet RTCP dans tous les rapports d'envoyeur, cela sera probablement suffisant. Donc si on a pas de codes de temps, on n'a pas non plus de synchronisation audio-vidéo.

La présente spécification associe le code de temps à un flux de supports particulier. Une solution de remplacement serait d'en faire un flux RTP de plein droit ; cependant, le débit de données est si lent que cela semble maladroit. En l'empaquetant en ligne, on peut rendre cela rétro-compatible pour les passerelles, etc., qui traitent déjà le double flux.

Il n'y a aucune façon décrite dans ce document pour détecter qu'un paquet RTCP a été perdu et qu'une transposition peut être utilisée en dehors de sa gamme prévue.

La conception suppose que les clients vont conserver les transpositions jusqu'à ce qu'elles soient remplacées, et qu'un client puisse avoir besoin de mettre en mémoire tampon un certain nombre de transpositions nouvelles.

 	9.	Considérations sur la sécurité

Les codes de temps SMPTE sont seulement pour information et il n'y a pas de considérations de sécurité connues provenant de leur association à des flux de supports.

 	10.	Considérations relatives à l'IANA

Le type de paquet RTCP utilisé pour les codes de temps SMPTE a été enregistré, en accord avec la Section 15 de la [RFC3550]. L'IANA a ajouté une nouvelle valeur au sous registre des types de paquet de contrôle RTCP du registre des paramètres du protocole de transport en temps réel (RTP, Real-Time Transport Protocol) conformément aux données suivantes :

Abréviation	Nom	Valeur	Référence
 SMPTETC	transposition de code de temps SMPTE	194	RFC 5484

De plus, l'IANA a enregistré un nouvel URI d'extension au sous registre des extensions d'en-tête compact RTP du registre des paramètres du protocole de transport en temps réel (RTP, Real-Time Transport Protocol) conformément aux données suivantes :

URI d'extension : urn:ietf:params:rtp-hdrext:smpte-tc
Description : transposition de code de temps SMPTE
Contact : singer@apple.com
Référence : +RFC 5484

 	11.	Remerciements

Brian Link et John Lazzaro ont tous deux fourni des commentaires utiles sur un projet initial. Colin Perkins a aidé à réviser et à traiter les détails. Ladan Gharai a fourni une révision finale pertinente.

 	12.	Références
 	12.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)

[RFC4585]	J. Ott et autres, "Profil RTP étendu pour rétroaction fondée sur le protocole de contrôle de transport en temps réel (RTCP) (RTP/AVPF)", juillet 2006. (P.S., MàJ par RFC8108)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5285]	D. Singer, H. Desineni, "Mécanisme général pour les extension d'en-tête RTP", juillet 2008. (P.S. ; remplacée par RFC8285)

 	12.2	Références pour information

[SMPTE-12M]	Society of Motion Picture and Television Engineers, "SMPTE Standard for Television -- Time and Control Code", SMPTE 12M-1-2008.

[SMPTE-EG40]	SMPTE, "Conversion of Time Values Between SMPTE 12M Time Code, MPEG-2 PCR Time Base and Absolute Time", SMPTE EG40-2002, août 2002.

 	Adresse de l'auteur

David Singer
Apple Computer Inc.
1 Infinite Loop
Cupertino, CA  95014
US

téléphone : +1 408 996 1010
mél : singer@apple.com