- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Mon, 06 Aug 2012 19:11:03 -0400
- To: public-webrtc@w3.org
On 8/6/2012 5:51 PM, Matthew Kaufman wrote: > In addition to these differences that fall out of not baking in the > full ICE and SDP O/A state machines, our proposal provides several > other capabilities, including hooks that allow a developer to > customize their application's response to changing network > conditions... an area which is currently completely unaddressed in the > current WebRTC draft. We've said repeatedly that we need such capability, and I have a proposed JS API for just that: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 The other side of this is in the hands of the Media Capture Task Force, where we've been discussing the best way to modify a MediaStream/Track after they're created. There are two rough proposals, one to re-use the constraints API for getUserMedia(), and the other I've proposed (verbally only so far, no draft API) uses events and lets them "bubble up" the chain of MediaStreams/Tracks from a consumer to a source (which could be a remote source, and the application could signal that request (such as a resolution or frame-rate change) across to the remote source of the stream. This is relevant even without a remote connection. > I wouldn't be surprised if the existing use-case document(s) is (are) > inadequate to describe situations where, for instance, a developer > might wish to prioritize video quality over frame rate, or drop video > in order to continue audio, but that just means that we all need to > provide more input on those documents as well. Matthew Kaufman I think most of those concerns are covered in what I describe above. (For example, the application could override the automatic allocation of bits and close a video stream, change the resolution, etc.) I'd love to your input on these proposals, API suggestions, alternatives, etc! I'm glad you're willing to help flesh out them out and bring them to completion, and get them into the spec drafts ASAP. -- Randell Jesup randell-ietf@jesup.org
Received on Monday, 6 August 2012 23:13:19 UTC