Re: Revised Constraints modification API proposal

On 08/22/2012 08:17 PM, Travis Leithead wrote:
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>> On 08/21/2012 10:56 PM, Travis Leithead wrote:
...
>>> I'm not a believer in track object mutation. In other words, I don't
>>> believe that a track should be able to be "in-place" updated by applying a
>>> constraint to it.
>>> Rather, my view is that if there is a change that the device makes in
>>> response to the application of new constraints, old tracks are stopped
>>> and new track objects are created in response. This makes the
>>> application of constraints implicitly asynchronous, which prevents
>>> developers from taking a dependency on the "immediate application" of
>> constraints to a given track which may not be possible for all devices.
>>
>> I think I'm not getting this.
>> What happens to references to the old track in other MediaStreams when
>> such a replacement happens? Do they silently become invalid, or does some
>> other magic happen?
>
> This design is open to change, as I mentioned in my response to Rich.
>
> To help explain what I wrote above, consider a scenario. Let's say you've got a
> MediaStream instance called "allTracks" which has aggregated all the tracks you've
> received from both local and remote sources. You also have a "localStream" which
> has only your local audio and video track from your single webcam.
>
> The question is, what happens when you apply a settings (constraint) change to
> "localStream's" video track via localStream.videoDevices.applySettings(..). Let's call
> the targeted track "localTrack1".
>
> I would expect all of the following to happen (perhaps in this order):
> 1. localTrack1's onended event would fire
> 2. localTrack1 would be removed from the localStream.videoDevices list
> 3. localStream.videoDevices' onremovetrack event would fire
> 4. The UA would apply the settings and create a new track: "localTrack2"
> 5. localTrack2 would be added to the localStream.videoDevices list
> 6. localStream.videoDevices' onaddtrack event would fire
> <optionally>
> 7. The application would need to manually remove "localTrack1" from allTracks.videoTracks (since it stopped).
> 8. The application would need to manually add "localTrack2" into allTracks.videoTracks
>
> As Rich noted, this all becomes must easier if the track itself just adjusts its
> setting internally, so I'm open to changing this behavior. Having non-mutable track
> objects just seemed like a good idea to me.

I agree to Rich here, the settings should just change internally. I 
don't know if it would make sense to add an "onchange" event. It is the 
application that that asks for the change so it should know, on the 
other hand it might be convenient in some cases.

>
>

Received on Thursday, 23 August 2012 13:30:27 UTC