[clue] New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00

Bo Burman <bo.burman@ericsson.com> Thu, 08 March 2012 13:01 UTC

Return-Path: <bo.burman@ericsson.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413421F866D for <clue@ietfa.amsl.com>; Thu, 8 Mar 2012 05:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.478
X-Spam-Level:
X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSq-GrPdf4hz for <clue@ietfa.amsl.com>; Thu, 8 Mar 2012 05:01:06 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A51421F86A2 for <clue@ietf.org>; Thu, 8 Mar 2012 05:01:06 -0800 (PST)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-fb-4f58ad915a5f
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.3B.17856.19DA85F4; Thu, 8 Mar 2012 14:01:05 +0100 (CET)
Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.209]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Mar 2012 14:01:04 +0100
From: Bo Burman <bo.burman@ericsson.com>
To: "clue@ietf.org" <clue@ietf.org>
Date: Thu, 08 Mar 2012 14:01:03 +0100
Thread-Topic: New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00
Thread-Index: Acz9K4SvuUC29E4dSl6CitiVHixBSA==
Message-ID: <05F760EF51FA6A4F804F9759C239313A3A72087208@ESESSCMS0361.eemea.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: sv-SE, en-US
Content-Type: multipart/alternative; boundary="_000_05F760EF51FA6A4F804F9759C239313A3A72087208ESESSCMS0361e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [clue] New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "avtext@ietf.org" <avtext@ietf.org>
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 13:01:07 -0000

Hi,

My colleagues and I have a proposal for an RTCP extension to AVPF CCM allowing a media receiver to dynamically ask the media sender to use a certain codec configuration (called a Codec Operation Point, COP). We see this as being used both in WEBRTC (RTCWEB WG) and Video Conferencing / Telepresence (CLUE WG). Additional applications are expected.

The proposal is not intended to replace or conflict with codec negotiation taking place during SDP Offer / Answer, but rather optimize and fine-tune codec usage within the limits established by SDP O/A.

The draft defines a set of what is believed generally useful and reasonably codec-independent set of parameters. Those parameters can be used by a media sender to describe the codec configuration (Codec Operation Point) used to generate the media stream to the media receiver. The media receiver can in turn examine the parameter values in the announced Codec Operation Point and use the same set of defined parameters to ask the media sender to use other, more suitable values for those parameters. It is the media sender's responsibility to decide if such request can be honored or not. If the request is accepted, the media sender then changes the media stream accordingly and sends another Codec Operation Point announcement with the changed parameter values.

One possible example is to let a video media receiver control the encoded video resolution based on decoded video window display size.

https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/

This draft is designed to:

* Allow for minimal implementation. The media sender need only announce COP support for the payload types it wishes to make controllable. It is not a requirement to support all parameter types, and receive support for each parameter type is signaled explicitly in SDP. Unsupported parameter types can safely be ignored.

* Be extensible. It is for example easy to define more parameter types in extensions to this draft. New message types and result codes can also be defined as extensions.

* Be possible to use both in point-to-point, in multipoint (conferencing), and even some specific multicast situations.

* Be responsive. The user at the media receiver can request and experience the result of changes in a dynamic and interactive fashion. The codec control signaling need only traverse the media path and uses the most responsive RTCP mode available, AVPF.

* Support single layer as well as multi-layered (scalable) media streams. A multi-layered media stream can easily be described and configured by using multiple, simultaneously active Codec Operation Points.

* Be as media and codec agnostic as possible. The defined parameter types are chosen to be as generic as possible and should therefore apply to many different codecs. Some media type awareness is however included in the chosen set of parameters.

* Be robust. It leaves to the media sender to decide exactly what is changed. A media sender that receives a request to set a certain value for a parameter can choose another value that is seen as more appropriate, or even choose to not change anything at all. "Unreasonable" requests can thus safely be ignored.

* Be flexible in what type of parameter value restrictions that can be described. A request can use either an exact single value, an open-ended minimum or maximum restriction, or a range of values. It is also possible to use a "target" value, standalone or in combination with a range, to express a preference. It is even possible to specify a set of prioritized, alternative configurations that the media sender can choose from.

* Allow for advertised, synchronized configuration changes. The Codec Operation Point notification can be time stamped some time into the future, allowing the media receiver some time for informed preparation (if needed) before the actual media stream change occurs.

We would like to see this work as WG item in AVTEXT WG.

If you have input, please provide comments to the AVTEXT WG (reply-to set there).

Best Regards

Bo Burman

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7141311
Färögatan 6                 | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com
----------------------------------------------------------------------