Network Working Group M. Civanlar
Request for Comments: 2862 G. Cash
Category: Standards Track AT&T
June 2000
RTP Payload Format for Real-Time Pointers
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism.
この文書は、プレゼンテーション中に使用することができる動的ポインタの座標を輸送するためのRTP [1]ペイロードフォーマットを記述する。マウスポインタとして使用することができるが、このペイロードフォーマットは意図されておらず、一般的なマウスイベント伝達機構を実装するために必要なすべての機能を有していなくてもよいです。
In most presentations, significant information is conveyed through the use of viewgraphs and a pointer. This makes accurate transmission of them vital in remote conferencing applications. Using regular video of a presenter's display for this purpose is problematic because, while the viewgraphs require a high spatial resolution, the pointer movements need to be sampled and transmitted at a high temporal resolution so that the presenter's pointing actions can be displayed synchronously with the corresponding audio and video signals. In many instances, this synchronization carries vital information. As an example, consider a speaker pointing at two alternatives on a viewgraph in sequence and saying "this one is better than this". To satisfy both high spatial and high temporal resolution requirements, at least S-VHS quality video may need to be used. Codecs that can compress S-VHS video effectively in real-time are expensive for this purpose, and transmitting such video uncompressed requires very high bandwidths.
ほとんどのプレゼンテーションでは、重要な情報は、ビューグラフとポインタの使用を介して搬送されます。これは、リモート会議アプリケーションにおけるそれらの正確な伝達が不可欠になります。この目的のために発表者のディスプレイの通常のビデオを使用すると、ビューグラフは、高い空間分解能を必要とするプレゼンタのポインティングアクションが対応する同期表示することができるように、ポインタの動きが高い時間分解能でサンプリングして送信する必要があるため問題ですオーディオおよびビデオ信号。多くの場合、この同期は重要な情報を運びます。例として、スピーカーがシーケンスのビューグラフ上の2つの選択肢を指しそして「この1つはこれよりも優れている」ということを検討してください。高い両方空間および高時間分解能の要件を満たすために、少なくともS-VHSの品質のビデオが使用される必要があるかもしれません。リアルタイムで効果的にS-VHSのビデオを圧縮することができますコーデックは、この目的のために高価であり、そのような映像の非圧縮を送信することは、非常に高い帯域幅を必要とします。
A much simpler and economical system can be designed by capturing and transmitting the pointer coordinates separately [2]. The pointer coordinates with respect to a displayed viewgraph can easily be obtained in electronic presentation systems. For presentations prepared for optical systems, such as transparencies for overhead projectors, an arrangement where the viewgraph is captured in a frame buffer on a computer can be used to associate the pointer coordinates with the displayed viewgraph. For capturing transparencies, printed material, or even three dimensional objects, a document camera and a personal computer or workstation based video capture card can be used. This arrangement can handle electronic viewgraphs by feeding the video output of the computer that displays them to the video capture card through an appropriate converter also. A side benefit of this is that it allows using a presenter's own computer to transmit electronic viewgraphs without connecting it to, for example, an intranet. The captured image is then displayed along with the capturing computer's mouse pointer on the presenter's display using a projector. The presenter moves the pointer on the display using a regular or maybe a wireless mouse whose location can easily be captured by appropriate software running on the capturing computer.
ポインタを捕捉及び送信することによって、はるかに簡単かつ経済的なシステムを設計することができる[2]に別々に調整します。ポインタが表示されたビューグラフに対して座標容易電子プレゼンテーションシステムで得ることができます。そのようなオーバーヘッドプロジェクタ用透明などの光学系、のために調製したプレゼンテーションのため、ビューグラフは、コンピュータ上でフレームバッファに捕捉される構成は、表示ビューグラフとポインタ座標を関連付けるために使用することができます。 OHPフィルム、印刷物、あるいは3次元の物体を捕捉するために、ビデオキャプチャカードをベースと書画カメラとパソコンやワークステーションを使用することができます。また、この構成は、適切なコンバータを介してビデオキャプチャカードにそれらを表示するコンピュータのビデオ出力を供給することにより、電子ビューグラフを扱うことができます。この副次的な利点は、それが、例えば、それを接続することなく、イントラネット、電子ビューグラフを送信するために発表者自身のコンピュータを使用できることです。取り込まれた画像は、その後、プロジェクタを使用して、プレゼンタのディスプレイ上に捕捉コンピュータのマウスポインタと一緒に表示されます。プレゼンターは、その位置を容易捕捉コンピュータ上で実行されている適切なソフトウェアによって捕捉することができるワイヤレスマウス多分規則的またはを使用して、ディスプレイ上のポインタを移動させます。
This document describes an RTP payload format to transmit the pointer coordinates captured in one of the ways described above using RTP. Although, a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism.
この文書では、RTPを用いて上記のいずれかの方法で捕捉ポインタ座標を送信するRTPペイロードフォーマットを記述する。マウスポインタとして用いることができるが、このペイロードフォーマットは意図されておらず、一般的なマウスイベント伝達機構を実装するために必要なすべての機能を有していなくてもよいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。
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 | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: contributing source (CSRC) identifiers :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|L|M|R| | x-coordinate | | PIN | y-coordinate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ MBZ
Figure 1 - An RTP packet for Real-Time Pointer
図1 - リアルタイムのポインタのためのRTPパケット
Fig. 1 shows an RTP packet carrying real-time pointer coordinates. This payload format does not have a payload specific header.
図1は、リアルタイムポインタ座標を運ぶRTPパケットを示しています。このペイロードフォーマットは、ペイロード特定のヘッダを持っていません。
Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range shall be chosen.
ペイロードタイプ（PT）：この新しいパケットフォーマットのためのRTPペイロードタイプの割り当ては、この文書の範囲外であり、ここで指定されません。アプリケーションの特定のクラスのためのRTPプロファイルは、この符号化のためのペイロードタイプを割り当てることが予想される、またはそれが次に行われていない場合、ダイナミックレンジ内のペイロードタイプが選択されなければなりません。
Marker (M) bit: Set to one if the pointer icon is changed in this packet.
マーカ（M）ビット：ポインタアイコンがこのパケットで変更された場合に1に設定します。
Extension (X) bit: Defined by the RTP profile used.
拡張（X）ビット：使用RTPプロファイルによって定義されています。
Sequence Number: Set as described in RFC1889 [1].
配列番号：RFC1889 [1]で説明されるように設定します。
Timestamp: The sampling time for the pointer location measured by a 90kHz clock.
タイムスタンプ：た90KHzクロックによって測定されたポインタの位置のためのサンプリング時間。
SSRC: Set as described in RFC1889 [1].
SSRC：RFC1889に記載されるように設定した[1]。
CC and CSRC fields are used as described in RFC 1889 [1].
RFC 1889に記載されるようにCCとCSRCフィールドが使用されている[1]。
RTCP SHOULD be used as defined in RFC 1889 [1].
RFC 1889で定義されるようにRTCPが使用されるべきである[1]。
The pointer's x and y coordinates are measured from the upper left corner of the associated display window. They are represented as a fraction of the corresponding edge length of the display window using 12 bits, positive, fixed point numbers between 0 and (1 - 2^-12).
ポインタのxとy座標は、関連する表示画面の左上隅から測定されます。それらは0と（^ -12 12）との間に12ビット、正の固定小数点数を使用して、表示画面の対応する辺の長さの割合として表されます。
L (left), R (right) and/or M (middle) bits are pointer special effects flags. Their use is application dependent and MUST be established out-of-band. Applications MAY ignore these bits.
L（左）、R（右）及び/又はM（中間）ビットポインタ特殊効果フラグです。これらの使用は、アプリケーションに依存し、アウト・オブ・バンド確立されなければなりません。アプリケーションは、これらのビットを無視するかもしれません。
PIN: Pointer Icon Number (3 bits) selects a pointer icon. The association between the PIN numbers and the icon pictures MUST be established out-of-band. PIN = 0 represents a default pointer icon. Applications which only support a single pointer icon SHOULD set the PIN field to zero. Applications MAY ignore non-zero PIN values on reception, and display a default icon.
PIN：ポインタアイコンの数（3ビット）は、ポインタアイコンを選択します。 PIN番号とアイコンの画像間の関連付けは、アウト・オブ・バンド確立されなければなりません。 PIN = 0は、デフォルトのポインタアイコンを表します。唯一のポインタアイコンをサポートするアプリケーションは、ゼロにPINフィールドを設定する必要があります。アプリケーションは、受信上の非ゼロのPIN値を無視し、デフォルトのアイコンが表示されることがあります。
This document defines a new RTP payload name, "pointer," and associated MIME subtype, "video/pointer."
この文書は、新しいRTPペイロード名、「ポインタ」と関連するMIMEサブタイプ、定義「ビデオ/ポインタを。」
MIME media type name: video
MIMEメディアタイプ名：ビデオ
MIME subtype name: pointer
MIMEサブタイプ名：ポインタ
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: Pointer video can be transmitted with RTP as specified in this document.
エンコードの考慮事項：この文書で指定されているポインタ映像は、RTPで送信することができます。
Security considerations: As described in this document.
セキュリティの考慮事項：この文書で説明したように。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: this document.
公開された仕様：このドキュメント。
Applications which use this media type: Videoconferencing systems that transmit VUgraphs with a real-time pointer.
このメディアタイプを使用するアプリケーション：リアルタイムのポインタでVUgraphsを送信するビデオ会議システム。
Additional information: None
追加情報：なし
Magic number(s): None
マジックナンバー（S）：なし
File extension(s): None Macintosh File Type Code(s): None
ファイルの拡張子（秒）：なしMacintoshのファイルタイプコード（S）：なし
Person & email address to contact for further information: M. Reha Civanlar e-mail: civanlar@research.att.com
人とEメールアドレスは、詳細のために連絡する：M.レハCivanlarメール：civanlar@research.att.com
Intended usage: COMMON Author/Change controller: M. Reha Civanlar e-mail: civanlar@research.att.com
意図している用法：COMMON著者/変更コントローラ：M.レハCivanlar電子メール：civanlar@research.att.com
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1].
本明細書で定義されたペイロードフォーマットを使用して、RTPパケットは、RTP仕様[1]で説明したセキュリティ上の考慮の対象となっています。
This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
このペイロードタイプは、潜在的なサービス拒否の脅威を引き起こすために、パケット処理のために受信機側計算の複雑さに重大な不均一性を示しません。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[2] 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.
[2] M. R. Civanlar、G. L.現金、 "ネットワークビューグラフ - NetVG" 第9回のIntの議事録。パケットビデオ、http://www.research.att.com/~mrc/PacketVideo99.htmlに関するワークショップ。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
M. Reha Civanlar AT&T Labs - Research 100 Schultz Drive, Room 3-205 Red Bank, NJ 07701, USA
M.レハCivanlar AT＆T研究所 - 研究100シュルツドライブ、ルーム3から205レッドバンク、NJ 07701、USA
EMail: civanlar@research.att.com
メールアドレス：civanlar@research.att.com
Glenn L. Cash AT&T Labs - Research 100 Schultz Drive, Room 3-213 Red Bank, NJ 07701, USA
グレン・L.現金AT＆T研究所 - 研究100シュルツドライブ、ルーム3から213レッドバンク、NJ 07701、USA
EMail: glenn@research.att.com
メールアドレス：glenn@research.att.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。