RE: MediaStreams and state changes

> From: Randell Jesup [mailto:randell-ietf@jesup.org]
> On 8/1/2012 3:54 PM, Travis Leithead wrote:
> >> From: Randell Jesup [mailto:randell-ietf@jesup.org]
> >> Sent: Thursday, June 7, 2012 7:18 AM
> >> [...]
> >> If instead we pass a request back "upstream" (nominally as some form
> >> of event), it would let the event ripple up to the source (or
> >> sources) - this would apply at the track level generally.  There may
> >> be multiple MediaStream objects and processors between the consumer
> and the source.
> > This seems overly complex for the UA to support, and is something really
> simple that a script library could offer.
> 
> Perhaps I miss something, but this is confusing: overly complex for the UA,
> but really simple for a script library.

What I'm trying to say is that it's easy to send these requests to the producer of the MediaStream via a side-channel--not something we should build-in to the PeerConnection signaling protocol itself.


> >   As long as there is some way to do it, then the appropriate
> > contracts can be worked out, even if the contract is as archaic as the
> > human consumer asking the human producer (via the RTC video/audio
> > channel itself) to turn up the volume on their end :)
> >
> >> Also, fundamental object for this type of change is the track, and
> >> not the MediaStream, which needs to be thought about even if we were
> >> to use constraints for modifications.
> > Yep, which is why we should at least consider a "local" version of a
> MediaStreamTrack. The problem with my proposal (being on a
> LocalMediaStream object) is that the application of change requests through
> the proposed API is supposed to happen against the devices supplying the
> tracks, and is not necessarily tied to the actual tracks that are present in a
> LocalMediaStream at any given point in time (since Tracks lists are fully
> mutable). It's easy (and likely) that developers will confuse those concepts
> and think they are applying the requested changes to the current tracks. If
> we can limit this confusion it would be advantageous.
> 
> Yes, I worry about the confusion as well.  A clear and easy-to-use API for
> applications to vary capture parameters seems important IMHO, whatever it
> is.

Received on Monday, 6 August 2012 17:37:15 UTC