- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Thu, 07 Jun 2012 16:51:07 -0400
- To: public-media-capture@w3.org
On 6/7/2012 3:50 PM, Robert O'Callahan wrote: > Sorry I wasn't on the call ... > > What sort of constraints are these? Currently there's a complex structure of mandatory and optional constraints passed into getUserMedia to control what is returned. (From what types of streams, to the resolution and frame rate, etc.) See the current draft I think. > What would we do if different consumers request different constraints? > Do we have some kind of lattice for computing the intersection of > constraints? That was brought up, since a track can end up in multiple streams. If we use the "bubble up" event or equivalent method, the person who split them could catch and resolve that before passing it up, or you just let the default which would likely be that either can request a change (both sides bubble up). We also talked to changes being different than constraints, and that the ultimate source (caller to getUserMedia) can take the change requests and use them to ask for a modification to the track via constraints (if it's a getUserMedia source). Other sources (PeerConnection, video element decoding a file or a network stream, etc) may do something else with the change request, or ignore it. > It shouldn't be hard to internally route constraints backwards along > the media graph from consumers to sources, once we know what they are > and how to combine them. Yes, that was the thought I had. -- Randell Jesup randell-ietf@jesup.org
Received on Thursday, 7 June 2012 20:51:49 UTC