Format de charge utile RTP pour pointeurs en temps réel

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

Le présent document décrit un format de charge utile RTP [RFC1889] pour transporter les coordonnées d’un pointeur dynamique qui peut être utilisé durant une présentation. Bien qu’une souris puisse être utilisée comme pointeur, ce format de charge utile n’est pas destiné à avoir et ne peut pas avoir toutes les fonctionnalités nécessaires pour mettre en œuvre un mécanisme général de transmission d’événement par souris.

1. Introduction

Dans la plupart des présentations, les informations significatives sont convoyées par l’utilisation de vue-graphes et d’un pointeur. Cela rend leur transmission précise vitale dans les applications de conférence à distance. Utiliser une vidéo régulière de l’affichage d’un présentateur à cette fin est problématique parce que, tandis que le vue-graphe exige une forte résolution spatiale, les mouvements du pointeur doivent être échantillonnés et transmis à une forte résolution temporelle afin que les actions de pointage du présentateur puissent être affichées de façon synchrone avec les signaux audio et vidéo correspondants. Dans de nombreuses instances, cette synchronisation porte des informations vitales. Par exemple, considérons un orateur qui pointe sur deux alternatives sur un vue-graphe l’une après l’autre et qui dit "celle ci est meilleure que celle là". Pour satisfaire aux exigences de haute résolution aussi bien spatiale que temporelle, la qualité au moins de la vidéo S-VHS peut devoir être utilisée. Les codecs qui peuvent compresser efficacement la vidéo S-VHS en temps réel à cette fin sont coûteux, et la transmission d’une telle vidéo non compressée exige une très forte bande passante.

Un système beaucoup plus simple et économique peut être conçu en capturant et en transmettant séparément les coordonnés du pointeur [NetVG]. Les coordonnées du pointeur par rapport à l’affichage d’un vue-graphe peuvent aisément être obtenues dans des systèmes de présentation électronique. Pour les présentations préparées pour des systèmes optiques, tels que des transparents pour un projecteur, un arrangement où le vue-graphe est capturé dans une mémoire tampon de trame sur un ordinateur peut être utilisé pour associer les coordonnées du pointeur avec le vue-graphe affiché. Pour capturer les transparents, du matériel imprimé, ou même des objets en trois dimensions, une caméra de documents et une carte de capture vidéo fondée sur un ordinateur individuel ou une station de travail peuvent être utilisées. Cet arrangement peut traiter des vue-graphes électroniques en alimentant la sortie vidéo de l’ordinateur qui les affiche sur la carte de capture vidéo à travers un convertisseur approprié. Ceci présente l’avantage supplémentaire de permettre d’utiliser le propre ordinateur du présentateur pour transmettre les graphiques électroniques sans le connecter, par exemple, à un intranet. L’image capturée est alors affichée avec le pointeur de la souris de l’ordinateur utilisé pour la capture sur l’affichage du présentateur à l’aide d’un projecteur. Le présentateur déplace le pointeur sur l’affichage en utilisant une souris normale ou peut être une souris sans fil dont la localisation peut être facilement capturée par un logiciel approprié fonctionnant sur l’ordinateur de capture.

Le présent document décrit un format de charge utile RTP pour transmettre les coordonnées du pointeur capturées d’une des façons décrites ci-dessus en utilisant RTP. Bien qu’une souris puisse être utilisée comme pointeur, ce format de charge utile n’est pas destiné à avoir et peut ne pas avoir toutes les fonctionnalités nécessaires pour mettre en œuvre un mécanisme général de transmission d’événements de souris.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2. Format de charge utile

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|X| CC |M| PT | numéro de séquence |

+---+-+-+-------+-+-------------+---------------+---------------+

| Horodatage |

+---------------+---------------+---------------+---------------+

| Identifiant de source de synchronisation (SSRC) |

+---------------+---------------+---------------+---------------+

: Identifiants de source de contribution (CSRC) :

+===============+===============+===============+===============+

|G|M|D| | coordonnées x | | PIN | coordonnées y |

+-+-+-+-+-------+---------------+-+-----+-------+---------------+

MBZ MBZ

Figure 1 : paquet RTP pour pointeur en temps réel

La Figure 1 montre un paquet RTP qui porte des coordonnés de pointeur en temps réel. Ce format de charge utile n’a pas d’en-tête spécifique de charge utile.

2.1 Utilisation de l’en-tête RTP

Type de charge utile (PT, Payload Type) : l’allocation d’un type de charge utile RTP pour ce nouveau format de paquet sort du domaine d’application du présent document, et ne sera pas spécifié ici. On s’attend à ce que le profil RTP pour une classe particulière d’applications alloue un type de charge utile pour ce codage, ou bien si ce n’est pas fait, il faudra choisir un type de charge utile dans la gamme dynamique.

Bit Marqueur (M) : réglé à un si l’image du pointeur est changée dans ce paquet.

Bit Extension (X) : défini par le profil RTP utilisé.

Numéro de séquence : réglé comme décrit dans la [RFC1889].

Horodatage : l’heure d’échantillonnage pour la localisation du pointeur mesurée par une horloge à 90 kHz.

SSRC : réglé comme décrit dans la [RFC1889].

Les champs CC et CSRC sont utilisés comme décrit dans la [RFC1889].

RTCP DEVRAIT être utilisé comme défini dans la [RFC1889].

2.2 Charge utile

Les coordonnées x et y du pointeur sont mesurées à partir du coin supérieur gauche de la fenêtre d’affichage associé. Elles sont représentées comme une fraction de la longueur du bord correspondant de la fenêtre d’affichage en utilisant des nombres positifs de 12 bits, à virgule fixe entre 0 et (1 - 2^-12).

Les bits G (gauche), D (droit) et/ou M (milieu) sont des fanions d’effets spéciaux du pointeur. Leur utilisation dépend de l’application et DOIT être établie hors bande. Les applications PEUVENT ignorer ces bits.

PIN (Pointer Icon Number) : numéro d’image de pointeur (3 bits) choisit une image de pointeur. L’association entre les numéros de PIN et les représentations d’image DOIT être établie hors bande. PIN = 0 représente une image de pointeur par défaut. Les applications qui ne prennent en charge qu’une seule image de pointeur DEVRAIENT régler le champ PIN à zéro. Les applications PEUVENT ignorer les valeurs de PIN différentes de zéro à réception, et afficher une image par défaut.

3. Enregistrements du type de support MIME

Le présent document définit un nouveau nom de charge utile RTP, "pointer," et le sous-type MIME associé, "video/pointer."

3.1 Enregistrement du type de support MIME vidéo/pointeur

Nom de type de support MIME : video

Nom de sous-type MIME : pointer

Paramètres exigés : aucun

Paramètres facultatifs : aucun

Considérations de codage : pointeur vidéo peut être transmis avec RTP comme spécifié dans ce document.

Considérations de sécurité : comme décrit dans ce document.

Considérations d’interopérabilité : aucune

Spécification publiée : le présent document.

Applications qui utilisent ce type de support : systèmes de vidéoconférence qui transmettent des VUgraphs avec un pointeur en temps réel.

Informations supplémentaires : aucune

Numéro magique : aucun

Extension de fichier : aucune

Code de type de fichier Macintosh : aucun

Adresse personnelle & de messagerie à contacter pour information : M. Reha Civanlar mél : civanlar@research.att.com

Utilisation prévue : courante

Auteur/contrôleur de changements : M. Reha Civanlar mél : civanlar@research.att.com

4. Considérations pour la sécurité

Les paquets RTP qui utilisent le format de charge utile défini dans la présente spécification sont soumis aux considérations pour la sécurité exposées dans la spécification RTP [RFC1889].

Ce type de charge utile ne présente aucune non uniformité significative dans la complexité de calcul côté receveur pour le traitement de paquet susceptible de causer une menace potentielle de déni de service.

5. Références

[NetVG] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG" Proceedings of The 9th Int. Workshop on Packet Video, http://www.research.att.com/~mrc/PacketVideo99.html

[RFC1889] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64)

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

6. Adresse des auteurs

7. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.