Re: MediaStream "ended" event

On 2012-08-10 01:08, Travis Leithead wrote:
>> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] On
>> 2012-07-30 21:28, Stefan Hakansson LK wrote:
>>> On 07/30/2012 07:20 PM, Travis Leithead wrote:
>>>>> From: Stefan Hakansson LK
>>>>> [mailto:stefan.lk.hakansson@ericsson.com] To me, the 'ended'
>>>>> on MediaStream level makes life easier for the application
>>>>> developer. E.g., if the consent to use input devices is
>>>>> revoked by the user (I imagine browsers will supply ways to
>>>>> do that), the app would know that directly (and not have to
>>>>> keep track of that all tracks included in the MediaStream in
>>>>> question have ended).
>>>>>
>>>>> But the problem that comes from being able to remove all
>>>>> tracks, and then add (at least) one, was one I had not
>>>>> thought of before. In principle the same problem would
>>>>> surface if all tracks of a MediaStream ended, and the
>>>>> MediaStream went to state 'ended' as a result, followed by
>>>>> "add" of a non- ended track.
>>
>> These are two different cases in the current spec. A MediaStream is
>> only defined as ended (or finished as it's called in the spec) if
>> all tracks are ended. Removing all tracks will not end the stream.
>> Nor will an empty MediaStream created without track-arguments to
>> the MediaStream constructor be ended. Then we wouldn't be able to
>> add tracks to it since the MediaStreamTrackList.add() algorithm
>> currently prevents adding tracks to an ended stream (illegal
>> state).
>>
>>>> Another alternative is to simply enhance the MediaStream object
>>>> with a corresponded "started" event for cases where a media
>>>> stream with no tracks becomes a media stream with at least one
>>>> live track.
>>>
>>> Without thinking very much, that seems like the best solution to
>>> me.
>>
>> When we moved the life cycle handling for media sources from
>> MediaStream down to MediaStreamTrack we got a better one-to-one
>> mapping. The old scenario where a MediaStream tried to represent
>> the state of a number of cameras and microphones altogether was a
>> bit strange. As a result, MediaStream has become more of a track
>> container with a state that, e.g., makes it easier to know if there
>> are any live tracks in the stream and really simple applications
>> don't have to deal with tracks at all. With that definition I guess
>> it would be OK to let a MediaStream end and restart as tracks end
>> and new live tracks are added.
>>
>> I'm just thinking about how this works together with
>> LocalMediaStream and its stop() method. In that case it feels like
>> the LocalMediaStream has some kind of life cycle anyhow where it's
>> created by getUserMedia() and destroyed permanently with stop().
>
> I think what we may end up doing is moving the state from the
> LocalMediaStream to a LocalMediaStreamTrack in the same way that you
> mentioned that life cycle handling for media sources was moved from
> MediaStreams to MediaStreamTracks. In that way things end up
> consistent, application of state changes are portable to the relevant
> track they apply to (as tracks get moved around), and MediaStreams
> continue to act more as containers and synchronizers with perhaps
> only a few helpers to make the "simple" applications easy to use.

I like the behavior that getUserMedia() produces as stream when the user 
grants access to devices and the API to revoke access is on the same 
level (LocalMediaStream). It's more symmetric when you don't have to go 
down a level to the tracks and revoke them individually. The question is 
if it's worth preserving if it has too many confusing consequences.

/Adam

Received on Friday, 10 August 2012 08:09:48 UTC