1 / 7

RTP Payload Format for Real-Time Pointers

RTP Payload Format for Real-Time Pointers. M. Reha Civanlar AT&T Labs - Research 45 th IETF Oslo, Norway. Why do we need this?. In presentations, it is essential to transmit viewgraphs & real-time pointers A straightforward approach, using a video codec, is not feasible because:

lottie
Download Presentation

RTP Payload Format for Real-Time Pointers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RTP Payload Format for Real-Time Pointers M. Reha Civanlar AT&T Labs - Research 45th IETF Oslo, Norway

  2. Why do we need this? • In presentations, it is essential to transmit viewgraphs & real-time pointers • A straightforward approach, using a video codec, is not feasible because: • Viewgraphs require high spatial resolution • Pointer requires high temporal resolution 45th IETF - Oslo, Norway

  3. Capturing the pointer, e.g. Document Camera Network Baseband Video Network Interface Video Capture VGA Interface Mouse Interface Projector Pointer Mouse (Pointer) Display PC, Workstation 45th IETF - Oslo, Norway

  4. Payload format • draft-civanlar-pointer • 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 45th IETF - Oslo, Norway

  5. Payload format • 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. • RTP Header Usage: • Marker (M) bit: Set to one if the payload carries information about mouse buttons. • Timestamp: The sampling time for the pointer location measured by a 1KHz clock. 45th IETF - Oslo, Norway

  6. Issues: • More buttons • how many? • Represent pointer position as a fraction from 0 to 1 in both x and y directions. • resolution? • computational overhead • Loss resilience? 45th IETF - Oslo, Norway

  7. Issues • Should this be a workgroup item? • Should we extend this to generic mouse coordinate transport? 45th IETF - Oslo, Norway

More Related