[要約] RFC 2862は、リアルタイムポインタのためのRTPペイロード形式を定義しています。このRFCの目的は、リアルタイム通信でポインタ情報を効果的に伝送するための標準化を提供することです。
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
リアルタイムポインター用のRTPペイロード形式
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.
Copyright（c）The Internet Society（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つの代替案を指し示し、「これはこれよりも優れている」と言っているスピーカーを考えてください。高い空間的および高い時間分解能要件の両方を満たすには、少なくとも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]。表示されたビューグラフに関するポインター座標は、電子プレゼンテーションシステムで簡単に取得できます。オーバーヘッドプロジェクターの透明度などの光学システム用のプレゼンテーションについては、コンピューター上のフレームバッファーでビューグラフがキャプチャされる配置を使用して、ポインター座標を表示されたビューグラフに関連付けることができます。透明性、印刷された素材、または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を使用して上記の方法の1つでキャプチャされたポインター座標を送信する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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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パケットを示しています。このペイロード形式には、ペイロード固有のヘッダーがありません。
2.1. RTP Header Usage:
2.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].
CCおよびCSRCフィールドは、RFC 1889 [1]に記載されているように使用されます。
RTCP SHOULD be used as defined in RFC 1889 [1].
RTCPは、RFC 1889 [1]で定義されているように使用する必要があります。
2.2. Payload:
2.2. ペイロード：
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座標は、関連するディスプレイウィンドウの左上隅から測定されます。それらは、12ビット、正の固定点数（1-2^-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.
ピン：ポインターアイコン番号（3ビット）ポインターアイコンを選択します。ピン番号とアイコンの写真との関連は、帯域外に確立する必要があります。PIN = 0は、デフォルトのポインターアイコンを表します。単一のポインターアイコンのみをサポートするアプリケーションは、ピンフィールドをゼロに設定する必要があります。アプリケーションは、受信時にゼロ以外の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.
このメディアタイプを使用するアプリケーション：リアルタイムポインターでVugraphを送信するビデオ会議システム。
Additional information: None
追加情報：なし
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information: M. Reha Civanlar e-mail: civanlar@research.att.com
詳細については、人とメールアドレスをお問い合わせください：M。Reha Cenlarメール：cenlar@research.att.com
Intended usage: COMMON Author/Change controller: M. Reha Civanlar e-mail: civanlar@research.att.com
意図された使用法：Common Auther/Change Controller：M。Reha Cenlar Email：cenlar@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.、Frederick、R。and 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. Cash、「ネットワークビューグラフ - NetVG」9th 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
M. Reha Civanlar AT&T Labs - Research 100 Schultz Drive, Room 3-205 Red Bank, NJ 07701, USA
M. Reha Civanlar AT＆T Labs -Research100 Schultz Drive、Room 3-205 Red Bank、NJ 07701、米国
EMail: civanlar@research.att.com
Glenn L. Cash AT&T Labs - Research 100 Schultz Drive, Room 3-213 Red Bank, NJ 07701, USA
Glenn L. Cash AT＆T Labs -Research100 Schultz Drive、Room 3-213 Red Bank、NJ 07701、米国
EMail: glenn@research.att.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。