W3C home > Mailing lists > Public > public-media-capture@w3.org > June 2012

Re: MediaStreams and state changes

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 07 Jun 2012 16:51:07 -0400
Message-ID: <4FD1143B.8070001@jesup.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC