RTP Payload Format for Real-Time Pointers
RFC 2862
Document | Type |
RFC - Proposed Standard
(June 2000; No errata)
Was draft-ietf-avt-pointer (avt WG)
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2862 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 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. 1. Introduction 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. Civanlar & Cash Standards Track [Page 1] RFC 2862 RTP Payload Format for Real-Time Pointers June 2000 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. 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. 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]. Civanlar & Cash Standards Track [Page 2] RFC 2862 RTP Payload Format for Real-Time Pointers June 2000 2. Payload Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Show full document text