One document matched: draft-even-mmusic-video-media-control-00.txt-15391.txt
R. Even
Internet Draft Polycom
Document: draft-even-mmusic-video-media- O. Levin
control-00.txt RADVISION
P. Koskelainen
Columbia University
Expires: December 2002 June 2002
SDP attributes for Video media Media Control
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 defines the syntax and the semantics for the new SDP
attributes required for handling of video. These attributes are not
CODEC specific.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................2
2. Conventions used in this document...............................2
3. Video Resolution Attribute......................................2
4. Video Request Attribute.........................................3
5. IANA Considerations.............................................4
6. Security Considerations.........................................5
7. References......................................................6
8. Author's Addresses..............................................6
Even et al. Expires December 2002 1
1. Introduction
Internet multimedia conferencing based on SIP is picking up with
point-to-point and multipoint video conferencing implementation.
Video media has some characteristics that are common to all video
codecs. Video streams can build pictures for different display
resolutions each in a different supported frame rate. Compressed
Video information is typically composed of full picture frames and
frames that reflect changes from previous frames, this requires some
special handling to enable smooth switching of video source and
resynchronization on full pictures. In order to have better support
for video media this draft specifies the SDP syntax to be used for
the described video media properties. These attributes can be
delivered by some signalling protocol (e.g. SIP or SAP).
For example, the defined attributes help to control video streams
belonging to SIP dialogs in a point-to-point call as well as in a
multipoint call.
The attributes are especially useful in SIP but may be used in SAP.
2. Conventions used in this document
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 [1].
3. Video Resolution Attribute
The SDP draft [1] has an attribute of frame rate. Video CODECs can
support different frame rates that are dependent on the frame
resolution. Therefore we need a new attribute that will specify the
frame rate per resolution.
a=video-resolution:<size>
size="SQCIF" "=" mpi | "QCIF" "=" mpi | "CIF" "=" mpi |
"4CIF" "=" mpi | "16CIF" "=" mpi |
"XMAX" "=" xmax SP "YMAX" "=" ymax SP "MPI" "=" mpi
mpi=1*3DIGIT
xmax=1*3DIGIT
ymax=1*3DIGIT
"video-resolution" is a media level attribute that enables
definition of supported resolutions for a video CODEC for described
media.
MPI gives the maximum video frame rate in frames/sec. Decimal
representations of fractional values using the notation
"<integer>.<fraction>" are allowed. If a resolution is not specified
then the decoder will support the frame rate of the next highest
resolution specified.
Even et al. Expires December 2002 2
SQIF: Sub-QCIF picture size and its MPI value.
QCIF: QCIF picture size and its MPI value
CIF: CIF picture size and it MPI value
4CIF: is 4xCIF picture size and its MPI value
16CIF: is 16xCIF picture size and its MPI value.
Arbitrary picture size (XMAX, YMAX, MPI): the maximum X and Y values
in pixels for an arbitrary picture size and it MPI value. The X and
Y value must be dividable by 4.
4. Video Request Attribute
Output of a video CODEC is a frame. The frame can carry complete (in
time) information about a picture or about a picture segment. These
frames are known as "intra" frames. In order to save bandwidth,
other frames can carry only changes relative to previously sent
frames. Frames carrying relative information are known as "inter"
frames.
Some CODECs (such as H.261 and H.263), in addition to a "full"
picture, have a notion of picture slices: MB (Macro Block) and GOB
(Group Of Blocks) or arbitrary slices.
The decoder has an ability to recognize synchronization problem and
MUST have an ability to explicitly request from an encoder for
complete (in-time) information of a "full" picture or of a specific
slice of the picture. In addition, when an application needs to
start presenting a new video source, it MUST have the ability to
explicitly request from an encoder for a complete information about
the picture.
In case the encoder is aware of the upcoming changes in the
transmitted stream (that would result in synchronization lost by the
decoder), the encoder MUST be able to request the decoding side to
freeze the picture, i.e. to stop presenting the changes, until a new
stable image is encoded and transmitted.
A smooth video switch in a multipoint conference starts when the
conference host decides to switch to a new video source. It sends a
freeze picture request to all the decoders that will receive the new
stream. Afterwards, the conferencing host sends a request to the new
encoder to send an Intra frame with the complete information for the
new picture. The new Intra frame, from the encoder, releases the
decoders from the video freeze state and a new complete picture is
presented.
The AVT RTCP feedback draft [3] provides a mechanism for an
immediate feedback using RTCP. In order to be in line with the RTCP
role (as described in RTP [4]), the feedback mechanism is allowed
for notifications only. Moreover, the RTCP feedback provides a
Even et al. Expires December 2002 3
notification channel from decoder to encoder only. For our purposes,
a means of sending requests in both directions are required.
Using SDP (instead of RTCP) has a clear advantage for applications
that donĘt have an access to the RTCP channel of the media.
The media level attributes to support this are:
a=video-frame:<request>
Permitted values for request are:
"INTRA-PICTURE" - instructing the encoder to send an intra frame
"FREEZE-PICTURE" - instructing the decoder to stop decoding.
"INTRA-GOB" "=" fgb "," ngb - instruct the encoder to send ngb gobs
starting from gob fgb.
"INTRA-MB" "=" fgb "," fmb "," nmb - instruct the encoder to send
nmb macro blocks starting from gob fgb and first macro block fmb.
fmb=1*2DIGIT
nmb=1*2DIGIT
fgb=1*2DIGIT
ngb=1*2DIGIT
5. IANA Considerations
This document defines the following new SDP parameters of type "att-
field" (attribute names):
Attribute name: video-resolution
Long form name: video resolution .
Type of attribute: media-level.
Subject to charset: No.
Purpose: define supported frame rate per resolution.
Appropriate values: See Section 3.
Attribute name: video-frame
Long form name: video frame request.
Type of attribute: media-level.
Subject to charset: No.
Purpose: define video frame requests.
Appropriate values: See Section 4.
Even et al. Expires December 2002 4
6. Security Considerations
The new SDP attributes do not introduce additional security
pitfalls.
The security considerations are the same as for the SDP [1].
Even et al. Expires December 2002 5
7. References
[1] M. Handley and V. Jacobson, "SDP: session description protocol",
Request for Comments 2327, Internet Engineering Task Force, Apr.
1998.
[2] P. Koskelainen et al. "SDP syntax for H.263 options",
INTERNET-DRAFT, Internet Engineering Task Force, 1998.
[3] Ott, Wenger et al. "Extended RTP Profile for RTCP-based Feedback
(RTP/AVPF)", INTERNET-DRAFT, Internet Engineering Task Force, 2002
[4] AVT WG, Schulzrinne/Casner/Frederick/Jacobson, "RTP: A Transport
Protocol for Real-Time Applications", RFC 1889, Proposed Standard,
Jan 1996.
8. Author's Addresses
Roni Even
Polycom Network Systems
94 Derech Em Hamoshavot Phone: +972-3-9251200
Petach Tikva, Israel Email: roni.even@polycom.co.il
Orit Levin
RADVISION Inc.
575 Corporate Drive
Mahwah, NJ 07430 Phone: +1-210-529-4300 x230
USA Email: orit@radvision.com
Petri Koskelainen
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue Phone:
MC 0401 New York Email: petkos@cs.columbia.edu
NY 10027
USA
Even et al. Expires December 2002 6
| PAFTECH AB 2003-2026 | 2026-04-24 06:57:44 |