Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Sun, 10 March 2013 07:01 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB521F87D6 for <rtcweb@ietfa.amsl.com>; Sat, 9 Mar 2013 23:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 7tdkRkDWldWu for <rtcweb@ietfa.amsl.com>; Sat, 9 Mar 2013 23:01:16 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9002021F8782 for <rtcweb@ietf.org>; Sat, 9 Mar 2013 23:01:15 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-b5-513c2fb95546
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.BD.19728.9BF2C315; Sun, 10 Mar 2013 08:01:14 +0100 (CET)
Received: from [153.88.18.176] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Mar 2013 08:01:13 +0100
Message-ID: <513C2FB9.7040803@ericsson.com>
Date: Sun, 10 Mar 2013 08:01:13 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CABkgnnXCio-Dw7dN5yfSjeRf3wG2oWow_M2mU-Y49TedSAPQmg@mail.gmail.com> <CAHBDyN6CFTix3W9qWgC1T0O36t4SajL3hMXaHOdkat-p5TY_xA@mail.gmail.com> <CABcZeBMLdEkFZq5rMOY0texKb4DtFQ-O86JkC17kJihxv6Dj8w@mail.gmail.com> <CAHBDyN6mM-rT315uSbeTQfKuCiVwsEDhi7Q6DEbt8pjiJ_4i6g@mail.gmail.com> <CAHp8n2nz=NZb=UaevUSS7GRSBpvn-v9_=QHz6iddnZzyx5-TSQ@mail.gmail.com> <CAJrXDUETwfY7ZvaXO_1Bq8gs8pOTgALQE8FiimrUX7sfuEpDsw@mail.gmail.com> <CAHp8n2kcEHcz11LOYYMZ3-nv2PYQKu=z6M=dsQ_H5JuR8ND7hQ@mail.gmail.com> <513B5D98.2070601@alvestrand.no> <CAJrXDUEL_5BjWVaP4Fu7sY+P7kj1GVz3q3_z=wUtgyzMUnud2w@mail.gmail.com>
In-Reply-To: <CAJrXDUEL_5BjWVaP4Fu7sY+P7kj1GVz3q3_z=wUtgyzMUnud2w@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje4ufZtAgw+nWCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu3bB9gLFshWnG6ezNzA+Eysi5GTQ0LARGL2xo+sELaYxIV7 69m6GLk4hAROMkrsXvOIGcJZzShx8tVqsCpeAW2Jr8/XAiU4OFgEVCWWz/cACbMJBEpc//+L CSQsKhAlcWWfJUS1oMTJmU9YQGwRAXWJyw8vsIPYwgKVEm3v10LtWscqsbnhAiNIghNozoQn e9lAbGYBW4kLc66zQNjyEtvfzmEGsYUEdCXevb7HOoFRYBaSHbOQtMxC0rKAkXkVI3tuYmZO ernRJkZgmB3c8lt1B+OdcyKHGKU5WJTEecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YNxqHfVuEYNCjQLTqceJM5IFjm+4WLv3Rtl1P+HTOlsXh+Rs3MaQu8/fuf9zHseHTV0iHo+1 NNXzYh+8nMOwI3zn5tlGQdurzk16+HUfo7nz9VV5jzU+HuJlV0pUjT5fVLBBo3rR2enBYg9b tLsWHlrTvOVg0YvGbetFVq2auLPyVv+HhW6LfZ2UWIozEg21mIuKEwHyZrvIAQIAAA==
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2013 07:01:17 -0000

On 2013-03-10 06:02, Peter Thatcher wrote:
> There's a difference between the resolution that you open the camera at
> and the resolution you send over the network at.  Does the current
> constraints API let you capture at one resolution and send at another?
> Also, does it let you change the send resolution on the fly?
>
> These are important controls that, as far as I know, are not currently
> supplied to the application.  They could potentially be supplied by SDP,
> new methods, or as you suggest, perhaps even as some kind of
> constraint.  But I don't think they are currently provided.

They are currently not provided. One reason is that there was a 
comprehensive proposal for how to change - on the fly - settings using 
constraints submitted by Travis last fall [1]. After a lot of discussion 
the editors are currently incorporating a slightly modified version of 
it for the local use. Once we have general agreement on that model it 
can be extended to the cases when media is transmitted over the network.

I did make a proposal to the webrtc WG, [2], which is heavily influenced 
by [1], for how we could add an API surface to individually control 
setting for how media is transported (the focus is on Priority but the 
idea was that is should be extendable) but it was never thoroughly 
discussed. And, there are probably other and better ways to do it :-), 
my main point is that SDP manipulation should not be the way.

As for the specific control of resolution there has also been a 
discussion (and that is also part of [1]) that the display area used by 
e.g. a video element should travel back to the source so that is can 
adjust settings to optimize (even if the web app developer does nothing).

[1] 
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
[2] 
http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/att-0005/PrioAPI.pdf

Stefan

>
> On Mar 9, 2013 7:54 PM, "Harald Alvestrand" <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> wrote:
>
>     As usual, I'm trying to use subject line change in order to achieve
>     some separation of concerns...
>
>     On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>
>         Agreed, but it's also not sufficient. SDP is not "programmer
>         friendly" enough because it has too many details that are
>         protocol-details only and it's too hard to see the semantic bits
>         in SDP and ignore the rest.
>
>         For example: the programmer wants to say - I want to get this
>         video resolution, this audio bitrate & channels, I want to use
>         this camera and this microphone for this call. Having to
>         manipulate SDP directly for this is a programmer's nightmare.
>
>
>     I think we've been over exactly those pieces, and our current
>     proposed solution is called the Media Stream API and the constraints
>     mechanism - and they have exactly nothing to do with SDP, or even
>     with PeerConnection.
>
>     I don't think we've got it to be "unproblematic" yet, but also, I
>     don't think SDP, JSON or even the offer-answer model is either the
>     problem or the solution on this set of functionalities.
>
>     Or did I misunderstand something basic?
>
>                     Harald
>
>     _________________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>