Browse Prior Art Database

STANDARDIZATION ON CONTROLLING DISPLAYING OF VIDEO FRAME AT RECEIVER

IP.com Disclosure Number: IPCOM000241009D
Publication Date: 2015-Mar-18
Document File: 3 page(s) / 60K

Publishing Venue

The IP.com Prior Art Database

Related People

Volvet Zhang: AUTHOR [+3]

Abstract

Techniques are presented for standardization of the control of the display of frames at a receiver. The first technique is to have an attribute line in a Session Description Protocol (SDP) INVITE message indicate the timestamp or timing information of a frame to start rendering at the beginning of the connection. The second technique is to add a "decode-but-not-render" flag in a Real-time Transport Protocol (RTP) header extension at the packet level.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

STANDARDIZATION ON CONTROLLING DISPLAYING OF VIDEO FRAME AT RECEIVER

AUTHORS: Volvet Zhang Andrew Shen Sijia Chen

CISCO SYSTEMS, INC.

ABSTRACT

    Techniques are presented for standardization of the control of the display of frames at a receiver. The first technique is to have an attribute line in a Session Description Protocol (SDP) INVITE message indicate the timestamp or timing information of a frame to start rendering at the beginning of the connection. The second technique is to add a "decode-but-not-render" flag in a Real-time Transport Protocol (RTP) header extension at the packet level.

DETAILED DESCRIPTION

     The state-of-the-art video standards define encoded video bit streams containing a key frame which can be independently decoded, and containing successive frames which can be decoded depending on the key frame. This means decoding always starts from the key frame, but in actual practice, displaying may not start from the key frame. Re-positioning key frames in existing bit streams may not be preferable, since it requires transcoding.

    Presented herein are two techniques for standardization to control the display of frames at the receiver end, at a specific time or at a specific connection. It is assumed for purposes of this description that there are already video streams on the server and the server is to control the display at the receiver.

    A first technique involves using an attribute line in Session Description Protocol (SDP) INVITE message to indicate the timestamp or timing information of a frame to start rendering at the beginning of the connection. This can be used when the server

Copyright 2015 Cisco Systems, Inc.
1


Page 02 of 3

knows the timestamp or time information of frames. Having such information in the INVITE message before initiating a video connection can be very efficient because the start of displaying information is only useful in starting a display.

    A second technique involves a "decode-but-not-render" flag in Real-time Transport Protocol (RTP) header extension. The server may not know the timestamp or time information of the frames, but it knows from which frame it wants the receiver to begin displaying at a specific time. Before sending media packets to a newly-joined receiver, the server can add such an RTP header extension to the packets which it wants the receiver to decode, for decoding frames afterwards, but not to render/display to the receiver. When the RTP header extension does not include the defined "decode-but-not- render" flag, it can be decoded and displayed normally. Providing such information in the RTP header extension can avoid editing the content of RTP pa...