Re: Possible simplification: Remove distinction between track "stop" and source "detach"

On 2015-04-22 11:41, Harald Alvestrand wrote:
> Den 22. april 2015 11:31, skrev Adam Bergkvist:
>> On 2015-04-15 15:11, Harald Alvestrand wrote:
>>> In the current specification, we have two concepts related to sources
>>> and tracks:
>>>
>>> - A track can be stop()ed, in which case it is ended.
>>> - A track can be detached from its source.
>>>
>>> The text says:
>>>
>>> A) in terminology for "source", we have:
>>>
>>> Sources are detached from a track when the track is ended for any reason.
>>>
>>> B) Under "Life-cycle and Media Flow", we have:
>>>
>>> A MediaStreamTrack can be detached from its source. It means that the
>>> track is no longer dependent on the source for media data. If no other
>>> MediaStreamTrack is using the same source, the source will be stopped.
>>> MediaStreamTrack attributes such as kind and label must not change
>>> values when the source is detached.
>>>
>>> C) Under the "enabled" attribute of a track, we have:
>>>
>>> On getting, the attribute must return the value to which it was last
>>> set. On setting, it must be set to the new value, regardless of whether
>>> the MediaStreamTrack object has been detached from its source or not.
>>>
>>> Under the "stop" function for a track, we have:
>>>
>>> 3. Set track's readyState attribute to ended.
>>>
>>> 4. Detach track's source.
>>>
>>> It seems to me that this is one concept more than we need.
>>> Whether there is a relationship between a stopped track and its source
>>> or not is an implementation detail, and we shouldn't be constraining it
>>> in our API description.
>>>
>>> So my suggestion:
>>>
>>> In A, C and D, simply remove the text that refers to "Detach".
>>>
>>> In B, instead say:
>>>
>>> If all MediaStreamTracks that are using the same source are ended, the
>>> source will be stopped.
>>>
>>> I think that simplifies the terminology, and doesn't change any
>>> observable property of the API.
>>>
>>> What do people think?
>>> (If others like it, I'll file a bug for it.)
>>
>> I think this is a simplification worth doing.
>>
>> This will let us refer to properties on the source without having to
>> verify that the track has a source attached. A new thing, however, is
>> that a track can have a stopped source (attached).
>
> Is this an issue?
>
> I think only stopped tracks can have stopped sources, since a source is
> only stopped if all the tracks have been stopped. So we can't have a
> live track sourced from a stopped source (which would indeed be a bit
> strange).

I don't think it's an issue. We need to specify what happens if, for 
example, getCapabilities() is called on a track with a stopped source. 
But it's not a new problem; detached or stopped, I guess the same thing 
should happen.

> We do have the concept of a source ending by itself (someone removed the
> camera?), which causes all the attached tracks to stop.

It's mentioned in the MediaStreamTrack.onended handler [1].

[1] https://w3c.github.io/mediacapture-main/#widl-MediaStreamTrack-onended

Received on Wednesday, 22 April 2015 10:04:28 UTC