[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Re: [AVT] FWD: I-D ACTION:draft-even-mmusic-video-media-control-0 0.txt
Hi,
The garbage is a result of using illegal characters (Non ascii) in the
draft. The use of smart quotations (“ & ”) should be avoided, use only
the standard strait ones ("). Also please remove all the 15 extra left
columns before submission the next time. Please read the draft
guidelines, "http://www.ietf.org/ietf/1id-guidelines.txt", for other
things to consider.
Regards
Magnus
Even, Roni wrote:
> Hi,
>
>I have seen that too.
>This is the text file I submitted
>Roni
>
>>-----Original Message-----
>>From: Lior Sion [mailto:lior.sion@emblaze.com]
>>Sent: Wednesday, June 12, 2002 3:41 PM
>>To: 'Even, Roni'
>>Subject: RE: [AVT] FWD: I-D
>>ACTION:draft-even-mmusic-video-media-control-0 0.txt
>>
>>
>>Hi Roni,
>>
>>the link you gave brings me some garbage in the draft, can
>>you please send
>>me a text file with it?
>>
>>thanks,
>>lior
>>
>>-----Original Message-----
>>From: Even, Roni [mailto:roni.even@polycom.co.il]
>>Sent: Wednesday, June 12, 2002 11:50 AM
>>To: mmusic@ietf.org
>>Cc: avt@ietf.org
>>Subject: [AVT] FWD: I-D
>>ACTION:draft-even-mmusic-video-media-control-00.txt
>>
>>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> Title : SDP attributes for Video media Media Control
>> Author(s) : R. Even, O. Levin, P. Koskelainen
>> Filename : draft-even-mmusic-video-media-control-00.txt
>> Pages : 6
>> Date : 10-Jun-02
>>This document defines the syntax and the semantics for the new SDP
>>attributes required for handling of video. These attributes
>>are not CODEC
>>specific.
>>
>>A URL for this Internet-Draft is:
>><http://www.ietf.org/internet-drafts/draft-even-mmusic-video-m
>>
>edia-control-0
>0.txt>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then "get
>draft-even-mmusic-video-media-control-00.txt".
>
>A list of Internet-Drafts directories can be found in
><http://www.ietf.org/shadow.html> or
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>
>
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>****************************************************************************
>**********************
>The contents of this email and any attachments are confidential.
>It is intended for the named recipient(s) only.
>If you have received this email in error please notify the system manager or
>the
>sender immediately and do not disclose the contents to any one or make
>copies.
>
>** eSafe scanned this email for viruses, vandals and malicious content **
>****************************************************************************
>**********************
>
>
>------------------------------------------------------------------------
>
>
> 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
>
>
--
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic