Internet DRAFT - draft-civanlar-pointer
draft-civanlar-pointer
Internet Engineering Task Force Civanlar & Cash - AT&T
INTERNET DRAFT June 24, 1999
File: draft-civanlar-rtp-pointer-00.txt Expires: December, 24 1999
RTP Payload Format for Real-Time Pointers
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a payload format for transporting the
coordinates of a pointer that may be used during a presentation in
real-time using RTP [1].
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. 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, e.g. when a speaker
points at two alternatives in sequence and says "this one is better
than this." To satisfy both of these requirements, at least S-VHS
quality video may need to be used. Codecs that can compress S-VHS
Civanlar & Cash [Page 1]
INTERNET-DRAFT RTP Payload Format for Real-Time Pointers June 1999
video effectively in real-time are expensive, and transmitting such
video uncompressed requires very high bandwidths.
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.
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].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: contributing source (CSRC) identifiers :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|L| | x coordinate |R| | y coordinate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ MBZ
Figure 1 - An RTP packet for Real-Time Pointer
Civanlar & Cash [Page 2]
INTERNET-DRAFT RTP Payload Format for Real-Time Pointers June 1999
Fig. 1 shows an RTP packet carrying real-time pointer coordinates.
This payload format does not have a payload specific header.
2.1. RTP Header Usage:
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.
Marker (M) bit: Set to one if the payload carries information about
mouse buttons.
Extension (X) bit: Defined by the RTP profile used.
Sequence Number: Set as described in RFC1889 [1].
Timestamp: The sampling time for the pointer location measured by a
1KHz clock.
SSRC: Set as described in RFC1889 [1].
CC and CSRC fields are used as described in RFC 1889 [1].
RTCP SHOULD be used as defined in RFC 1889 [1].
2.2. Payload:
The pointer's x and y coordinates are measured from the upper left
corner of the associated display window in pixels. The associated
window SHOULD be specified out-of-band. The coordinates are
represented as 14 bit, unsigned integers.
When the M bit is set to one, L (left) and/or R (right) bits are set
to one if their respective mouse buttons are down at the sampling
time.
3. Security Considerations
RTP packets using the payload format defined in this specification are
subject to the security considerations discussed in the RTP
specification [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.
Civanlar & Cash [Page 3]
INTERNET-DRAFT RTP Payload Format for Real-Time Pointers June 1999
4. References
[1] Schulzrinne, Casner, Frederick, Jacobson RTP: A
Transport Protocol for Real Time Applications RFC 1889,
Internet Engineering Task Force, January 1996.
[2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG" Proceedings
of The 9th Int. Workshop on Packet Video,
http://www.reseach.att.com/~mrc/PacketVideo99.html.
[3] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119, March 1997.
7. Authors' Addresses
M. Reha Civanlar
AT&T Labs - Research
100 Schultz Drive
Room 3-213
Red Bank, NJ 07701
USA
e-mail: civanlar@research.att.com
Glenn L. Cash
AT&T Labs - Research
100 Schultz Drive
Room 3-221
Red Bank, NJ 07701
USA
e-mail: glenn@research.att.com
Civanlar & Cash [Page 4]
