RE: Revised Constraints modification API proposal

> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> 
> On 2012-08-21 22:56, Travis Leithead wrote:
> > Hi folks!
> >
> If I understand correctly, then all LocalMediaStream instances have the same
> audioDevices and videoDevices lists. That means a particular
> LocalMediaStream may render some local audio and video (the tracks), but it
> may change settings on all granted devices. I think that's a bit weird and it's
> not clear how the tracks in audioDevices relate to the tracks in audioTracks.
> The elements in audioDevices are more like global device controllers than
> playable tracks.
> 
> An example that shows the lack of relation between the different track lists
> is when I have localStream0, localStream1 and have just used
> getUserMedia() to create localStream2 which has access to new devices.
> As a result, an "addtrack" event is fired on the device lists in
> localStream0 and localStream1 for no obvious reason.
> 
> It would perhaps make more sense to move the device lists to a singleton
> object in the page (as discussed in [3]) and skip the track inheritance.
> Like e.g.:
> 
> navigator.userMedia.audioDevices; (move gUM to the userMedia object?
> or
> navigator.userAudioDevices;
> 
> In that case, the objects in the device lists should be of some new
> UserMediaDevice type and not inherit from MediaStreamTrack IMO.

Yes, definitely less confusing than having four track lists on a LocalMediaStream, and the 
associated event firing confusion among instances. 

However, I like where you're going with your next comment below better...


> However, I agree with what you say above that these settings should be on
> track level. The approach with a devices lists on a singleton object doesn't
> help to make it clearer which tracks are affected when you change settings
> on a device. One approach to make the connection between tracks and the
> settings objects clearer would be to make LocalMediaStreamTrack objects
> behave like real tracks. I think it's best described by idls:
> 
> interface AbstractMediaStream {
>      readonly attribute DOMString label;
>               attribute boolean ended;
>               attribute EventHandler onended; };
> 
> [Constructor (TracksUnionType? trackContainers)] interface MediaStream :
> AbstractMediaStream {
>      readonly attribute MediaStreamTrackList audioTracks;
>      readonly attribute MediaStreamTrackList videoTracks; };
> 
> interface LocalMediaStream : AbstractMediaStream {
>      readonly attribute LocalMediaStreamTrackList audioTracks;
>      readonly attribute LocalMediaStreamTrackList videoTracks;
> 
>      void stop();
> };
> 
> There are only one track list (for each media type) in a media stream and it
> represents the playable tracks. Depending on the type of a stream, the
> tracks expose the appropriate settings API directly.
> 
> This model can also be extended to provide settings on aggregated, cloned
> and remotely produced streams that are not available in local streams.

This makes a lot of sense. It solves the original problem of LocalMediaStreams having
mutable track lists, and it also strongly ties the LocalMediaStream to the devices that
provide it which is related to a particular invocation of getUserMedia. Very nice.

I would say, that from this point, (as was suggested on the teleconference today) what 
we should also consider is a way to obtain (if possible) a derived "CameraMediaTrack" instance from
any generic MediaStreamTrack, so that we can hang all the camera settings (and change API) off 
of one interface without cluttering up the generic MediaStreamTrack interface, or having to check
a flag to see if the given track is "locked" or not (per Rich's proposal).

Received on Thursday, 23 August 2012 18:08:17 UTC