Re: Revised Constraints modification API proposal

On 2012-08-23 20:07, Travis Leithead wrote:
>> 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).

Yes, that's definitely something to consider, but I would prefer to not 
call it a "*Track" unless it behaves like a real track. Perhaps 
"*Controller" or "*Settings" would be more descriptive.

Looking forward to the next iteration of your proposal.

/Adam

Received on Friday, 24 August 2012 08:33:26 UTC