ITU-T H 281 FRENCH-1994 A FAR END CAMERA CONTROL PROTOCOL FOR VIDEOCONFERENCES USING H 224《使用H 224的视频会议的远端摄像机控制协议 15号研究组 12pp[作废的 ITU-T H 283]》.pdf

《ITU-T H 281 FRENCH-1994 A FAR END CAMERA CONTROL PROTOCOL FOR VIDEOCONFERENCES USING H 224《使用H 224的视频会议的远端摄像机控制协议 15号研究组 12pp[作废的 ITU-T H 283]》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 281 FRENCH-1994 A FAR END CAMERA CONTROL PROTOCOL FOR VIDEOCONFERENCES USING H 224《使用H 224的视频会议的远端摄像机控制协议 15号研究组 12pp[作废的 ITU-T H 283]》.pdf（12页珍藏版）》请在麦多课文档分享上搜索。

1、UNION INTERNATIONALE DES TLCOMMUNICATIONSUIT-T H.281SECTEUR DE LA NORMALISATION (11/94)DES TLCOMMUNICATIONSDE LUITTRANSMISSION DE SIGNAUXNON TLPHONIQUESPROTOCOLE DE TLCOMMANDE DECAMRA POUR LES VISIOCONFRENCESUTILISANT LA COUCHE H.224Recommandation UIT-T H.281(Antrieurement Recommandation du CCITT)AV

2、ANT-PROPOSLUIT-T (Secteur de la normalisation des tlcommunications) est un organe permanent de lUnion internationale destlcommunications (UIT). Il est charg de ltude des questions techniques, dexploitation et de tarification, et met cesujet des Recommandations en vue de la normalisation des tlcommun

3、ications lchelle mondiale.La Confrence mondiale de normalisation des tlcommunications (CMNT), qui se runit tous les quatre ans, dtermineles thmes dtudes traiter par les Commissions dtudes de lUIT-T lesquelles laborent en retour desRecommandations sur ces thmes.Lapprobation des Recommandations par le

4、s Membres de lUIT-T seffectue selon la procdure dfinie dans laRsolution n 1 de la CMNT (Helsinki, 1er-12 mars 1993).La Recommandation UIT-T H.281, que lon doit la Commission dtudes 15 (1993-1996) de lUIT-T, a tapprouve le 1ernovembre 1994 selon la procdure dfinie dans la Rsolution n 1 de la CMNT._NO

5、TEDans la prsente Recommandation, lexpression Administration est utilise pour dsigner de faon abrge aussi bienune administration de tlcommunications quune exploitation reconnue de tlcommunications. UIT 1995Droits de reproduction rservs. Aucune partie de cette publication ne peut tre reproduite ni ut

6、ilise sous quelque formeque ce soit et par aucun procd, lectronique ou mcanique, y compris la photocopie et les microfilms, sans laccordcrit de lUIT.TABLE DES MATIRESRecommandation H.281 (11/94)PageRsum ii1 Champ dapplication. 12 Rfrences normatives . 13 Dfinitions 14 Abrviations . 25 Elments de pro

7、cdure . 25.1 Messages daction . 35.2 Exemples de messages daction 35.3 Slection de la source vido 45.4 Exemples de slection de source vido. 45.5 Mise en mmoire de prrglage 45.6 Activation de prrglage. 45.7 Recommandation gnrale 46 Structure des messages FECC 56.1 Champs des possibilits de tlcommande

8、 FECC 7Recommandation H.281 (11/94) i RSUMLa prsente Recommandation explique comment un systme de tlcommande de camra pour terminaux H.320 peutfonctionner avec donnes faible vitesse (LSD), donnes grande vitesse (HSD) ou protocole multicouche (MLP) entant que couche infrieure en exploitation point po

9、int et exploitation multipoint.ii Recommandation H.281 (11/94) Recommandation H.281Recommandation H.281 (11/94)PROTOCOLE DE TLCOMMANDE DE CAMRA POURLES VISIOCONFRENCES UTILISANT LA COUCHE H.224(Genve, 1994)1 Champ dapplicationLa prsente Recommandation est applicable aux lments de procdure et au form

10、at des champs destins prendre encharge un protocole de tlcommande de camra (FECC) (far end camera control) constituant la couche au-dessus duprotocole de liaison de donnes dont traite la Recommandation H.224. Le protocole de tlcommande FECC est conupour fonctionner dans les modes simplex point point

11、 et multipoint, avec utilisation du protocole de couche de liaisonH.224. Une exigence majeure impose la tlcommande de camra est une variation minimale du temps detransmission et un temps de transmission absolu minimum.Le prsent protocole FECC permet, en association avec la couche H.224, de commander

12、 chaque camra dunevisioconfrence multipoint partir de nimporte quel terminal vido.Le protocole FECC attend de la couche liaison de donnes H.224 que, si les deux canaux de transmission de donnes faible vitesse (LSD) (low speed data) et grande vitesse (HSD) (high speed data) sont utiliss pour la couch

13、e H.224,toutes les donnes FECC soient transmises sur le seul canal LSD. Cela permettra de recevoir les donnes FECC danslordre de leur mission.2 Rfrences normativesLes Recommandations UIT-T et autres rfrences suivantes contiennent des dispositions qui, par suite de la rfrencequi y est faite, constitu

14、ent des dispositions valables pour la prsente Recommandation. Au moment de la publication, lesditions indiques taient en vigueur. Toutes Recommandations et autres rfrences sont sujettes rvision; tous lesutilisateurs de la prsente Recommandation sont donc invits rechercher la possibilit dappliquer le

15、s ditions les plusrcentes des Recommandations et autres rfrences indiques ci-aprs. Une liste des Recommandations UIT-T envigueur est publie rgulirement. Recommandation UIT-T H.224, Protocole de commande en temps rel pour les applications simplexmettant en oeuvre les canaux de donnes faible vitesse/

16、grande vitesse de protocole multicouche dfinisdans la Recommandation H.221. Recommandation UIT-T H.261 (1993), Codec vido pour services audiovisuels p 64 kbit/s. Recommandation T.50 du CCITT (1984), Alphabet international no 5.3 DfinitionsPour les besoins de la prsente Recommandation, les dfinitions

17、 ci-aprs sappliquent:3.1 protocole simplex: Protocole de communication qui est purement unidirectionnel et dans lequel aucunprotocole dapplication ne contient daccuss de rception. La protection contre les erreurs ny est pas non plus prvue,sauf par codes correcteurs derreurs (sans voie de retour).3.2

18、 client: Entit qui utilise les services de transfert de donnes de la couche liaison de donnes. La tlcommandede camra est un exemple de client.3.3 entit de gestion de client: Client de liaison de donnes qui utilise lIdentificateur de client 0 00 pourenvoyer une liste complte de clients enregistrs loc

19、alement ainsi que leurs possibilits complmentaires facultatives.Pour plus de renseignements, voir la Recommandation H.224.Recommandation H.281 (11/94) 1 3.4 commandes FECC: Requtes lmentaires daction sur une camra distante, par exemple dbut daction decamra, poursuite daction de camra, arrt daction d

20、e camra et slection de source vido.3.5 PTZF (Pan-Tilt-Zoom-Focus): Mouvement panoramique horizontal ou vertical variation de distance focale(zoom) mise au point: les quatre mouvements de base dune camra pris en charge par le prsent protocole.3.6 prrglage de salle: Informations qui peuvent servir sle

21、ctionner une source vido puis la commanderpour obtenir la vue souhaite. La gestion des prrglages de salle est une possibilit complmentaire qui est annoncepar un message correspondant envoy par lentit de gestion de client (CME) utilisant la couche H.224. La possibilitdeffectuer des prrglages est facu

22、ltative et peut ne pas tre gre par tous les terminaux.3.7 activation de prrglage: Ordre un terminal de se commuter sur la source vido spcifie par le prrglagede salle puis de la positionner de manire obtenir la vue spcifie par ce prrglage. Un ordre dactivation deprrglage peut tre donn localement par

23、un utilisateur sur son terminal vido ou distance par un utilisateur dun autreterminal. Dans le cadre de cette Recommandation, on admet quun ordre dactivation de prrglage est donn distance.3.8 ASCII: Caractres cods comme dans lalphabet international no5 dfini dans la Recommandation T.50, avecle bit 8

24、 mis zro.3.9 image fixe rsolution normale: Image fixe transmise dans le flux vido H.261, code la mme rsolutionque dans le mode dimages animes prcdent (cest-dire en format QCIF ou FCIF). Ce mode utilise le bit 2(Indicateur de camra de document) qui est dfini au 4.2.1.3/H.261.3.10 image fixe double rs

25、olution: Image fixe transmise dans le flux vido H.261, code au double de larsolution horizontale et au double de la rsolution verticale du mode dimages animes prcdent (cest-dire au formatFCIF si limage tait en QCIF ou au format 4*FCIF si elle tait en FCIF). Ce mode utilise le bit 5 (Haute rsolution)

26、qui est dfini au 4.2.1.3/H.261 et lAnnexe D/H.261.4 AbrviationsCIF Format intermdiaire commun (common intermediate format) (Pour plus de renseignements, voir laRecommandation H.261)CME Entit de gestion de client (client management entity)FCIF CIF complet (full CIF) (Identique CIF)QCIF Quart de CIF (

27、Pour plus de renseignements, voir la Recommandation H.261)5 Elments de procdureLe protocole de tlcommande FECC comporte les types de messages de base suivants: demandes de DBUT DACTION sur chacun des trois axes de dplacement de la camra; demandes de POURSUITE DACTION sur chacun des trois axes de dpl

28、acement de la camra; demandes dARRT DACTION sur chacun des trois axes de dplacement de la camra; demandes de SLECTION DE SOURCE VIDO, cest-dire de commutation sur la source vidoindique pour le codage et la transmission; demandes de MISE EN MMOIRE DE PRRGLAGE, pour lenregistrement sous le numro deprr

29、glage indiqu, de la source vido et de ses paramtres spatiaux en cours; demandes dACTIVATION DE PRRGLAGE, pour la slection de la source vido et le rglage de sescoordonnes spatiales selon lenregistrement sous le numro de prrglage indiqu.2 Recommandation H.281 (11/94) 5.1 Messages dactionLes messages d

30、e type DBUT DACTION possdent un paramtre daction et une valeur de temporisation associs. Leparamtre daction indique quelle sorte de dplacement de camra (dans lensemble PTZF) est souhaite, ainsi que sonsens. Les messages de type POURSUITE DACTION et ARRT DACTION ont galement le mme paramtre dactionas

31、soci. Un message de type POURSUITE DACTION accompagn dun paramtre daction correspondant au prcdentmessage DBUT DACTION rinitialisera la priode de temporisation. Un message ARRT DACTION accompagndun paramtre daction correspondant au prcdent message DBUT DACTION provoque larrt du mouvement de lacamra.

32、 (La dure minimale daction la suite de lordre DBUT DACTION est laisse au choix du constructeur sur labase des paramtres de la camra. Cette dure minimale permet quun certain dplacement se produise.) Si latemporisation intervient, le client FECC rcepteur agit comme sil avait reu un message ARRT DACTIO

33、N assorti duparamtre daction appropri. Tout message ultrieur de type POURSUITE ou ARRT DACTION doit tre rejet danslattente de la rception dun nouveau message DBUT DACTION. La valeur de temporisation envoye dans unmessage initial DBUT DACTION protge contre la perte possible de la demande dARRT DACTIO

34、N finale. Toutmessage de type POURSUITE DACTION ou ARRT DACTION assorti dun paramtre daction qui ne correspond pasau message DBUT DACTION immdiatement prcdent doit tre rejet.Le dplacement en continu de la camra est obtenu au moyen dun message initial DBUT DACTION suivi ou non dunmessage POURSUITE DA

35、CTION et termin par un message ARRT DACTION. Lintervalle de temps qui scouleentre lmission de deux messages conscutifs quelconques dans cette squence ne doit jamais dpasser la valeur detemporisation spcifie dans le message DBUT DACTION, moins 200 ms. Si lon souhaite un dplacement en continu,la valeu

36、r de temporisation devra donc toujours tre gale ou suprieure 250 ms.Le paramtre daction dun message DBUT DACTION peut indiquer plusieurs dplacements pour un mme ordredonn (par exemple, pivoter droite et monter). Tout message POURSUITE DACTION ou ARRT DACTION doittre assorti dun paramtre daction corr

37、espondant tous les attributs de dplacement du prcdent message DBUTDACTION. Une fois quun message DBUT DACTION valide a t reu, ventuellement suivi dun certain nombre demessages POURSUITE DACTION correspondants, un nouveau message DBUT DACTION peut tre mis avec unparamtre daction diffrent. Ce nouveau

38、message de DBUT DACTION sera interprt comme un message ARRTDACTION pour tout dplacement qui nest plus mentionn, comme un message POURSUITE DACTION pour toutdplacement qui continue tre fix et comme un message DBUT DACTION valide pour tout nouveau dplacementindiqu par le paramtre daction. Les dveloppe

39、urs devront veiller ce que, lorsquun terminal est en train de donner desordres une camra, les ordres donns la mme camra partir dautres terminaux soient rejets jusqu la fin descommandes du premier terminal. Le protocole de liaison de donnes (voir la Recommandation H.224) fournit, dans sesmessages aus

40、si bien ladresse de lorigine que ladresse de la destination afin de permettre ce verrouillage.5.2 Exemples de messages dactionUn exemple de squence de commande de camra pourra aider montrer le bon usage du protocole. On peut envoyer unmessage de type DBUT DACTION indiquant un panoramique droite et u

41、ne inclinaison vers le haut, suivi dunnombre quelconque de messages POURSUITE DACTION spcifiant les mmes types de dplacement. On pourra fairesuivre ces messages dun autre message DBUT DACTION spcifiant seulement un panoramique droite. Puis envoyerun certain nombre de messages POURSUITE DACTION spcif

42、iant un panoramique droite. Puis un autre messageDBUT DACTION spcifiant un panoramique droite et une inclinaison vers le bas, suivi de plusieurs messagesPOURSUITE DACTION pour ces dplacements. Finalement, on envoie un message ARRT DACTION spcifiant lepanoramique droite et linclinaison vers le bas af

43、in de mettre fin la tlcommande de la camra. Dans cet exemple,laction dorientation vers la droite est continue, tandis que laction dinclinaison vers le haut na lieu que pendant lapremire phase de commande de camra. De mme, laction dinclinaison vers le bas na lieu que pendant la dernirephase de comman

44、de de camra. Lutilisation simultane de plusieurs commandes de camra est facultative pour lesterminaux qui envoient et reoivent des requtes FECC. Tout terminal non quip pour traiter des ordres simultans dedplacement de camra devra donner suite un ou plusieurs de ces ordres et ne pas tenir compte des

45、autres. Le choix desaxes de dplacement est arbitraire. (Lutilisateur distant constatera quune ou plusieurs de ses requtes de mouvement decamra auront t suivies deffet et il pourra envoyer ultrieurement les autres ordres de dplacement.)Recommandation H.281 (11/94) 3 5.3 Slection de la source vidoUn m

46、essage de type SLECTION DE SOURCE VIDO possde des paramtres associs de source vido et de modevido. Ds rception du message SLECTION DE SOURCE VIDO, le terminal vrifie la validit de ces deuxparamtres pour cette source. Si lun deux nest pas valide, le terminal rcepteur rejette le message sans lui donner suite.Si les paramtres so