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

[Stefan Håkansson LK <[e-mail]>]

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" <[e-mail]
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>