Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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.


 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",
 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                           |
 |           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
 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 pointer icon is changed in this
 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
 90kHz 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].

Civanlar & Cash Standards Track [Page 3] RFC 2862 RTP Payload Format for Real-Time Pointers June 2000

2.2. Payload:

 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).
 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.
 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. MIME Media Type Registrations

 This document defines a new RTP payload name, "pointer," and
 associated MIME subtype, "video/pointer."

3.1. Registration of MIME media type video/pointer

    MIME media type name: video
    MIME subtype name: pointer
    Required parameters: None
    Optional parameters: None
    Encoding considerations: Pointer video can be transmitted with RTP
    as specified in this document.
    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.
    Additional information: None
      Magic number(s): None

Civanlar & Cash Standards Track [Page 4] RFC 2862 RTP Payload Format for Real-Time Pointers June 2000

      File extension(s): None
      Macintosh File Type Code(s): None
    Person & email address to contact for further information:
      M. Reha Civanlar
    Intended usage: COMMON Author/Change controller:
      M. Reha Civanlar

4. 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.

5. References

 [1] Schulzrinne, H., Casner, S.,  Frederick, R. and V. Jacobson,
     "RTP: A Transport Protocol for Real Time Applications", RFC 1889,
     January 1996.
 [2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG"
     Proceedings of The 9th Int. Workshop on Packet Video,
 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

Civanlar & Cash Standards Track [Page 5] RFC 2862 RTP Payload Format for Real-Time Pointers June 2000

6. Authors' Addresses

 M. Reha Civanlar
 AT&T Labs - Research
 100 Schultz Drive, Room 3-205
 Red Bank, NJ 07701, USA
 Glenn L. Cash
 AT&T Labs - Research
 100 Schultz Drive, Room 3-213
 Red Bank, NJ 07701, USA

Civanlar & Cash Standards Track [Page 6] RFC 2862 RTP Payload Format for Real-Time Pointers June 2000

7. Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 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
 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


 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Civanlar & Cash Standards Track [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2862.txt · Last modified: 2000/06/22 17:21 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki