Re: Changes to the Stop method

On 2013-09-25 14:30, Harald Alvestrand wrote:
> The behaviour of the stop() method is changed in recent versions of the
> spec.*
>
> The spec text is:
>
>
> When a MediaStreamTrack
> <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack>object's
> stop()method is invoked, if no source is attached (e.g., sourceTypeis
> "none"), then this call returns immediately (e.g., is a no-op).
> Otherwise, the user agent mustqueue a task that runs the following steps:
>
>  1.
>
>     Let track be the current MediaStreamTrack
>     <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack>object.
>
>  2.
>
>     End
>     <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#event-mediastreamtrack-ended>track.
>     The track starts outputting only silence and/or blackness, as
>     appropriate.
>
>  3.
>
>     Permanently stop the generation of data for track's source. If the
>     data is being generated from a live source (e.g., a microphone or
>     camera), then the user agent shouldremove any active "on-air"
>     indicator for that source. If the data is being generated from a
>     prerecorded source (e.g. a video file), any remaining content in the
>     file is ignored.
>
> The task source for the tasks queued for the stop()
> <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-mediastreamtarck-stop>method
> is the DOM manipulation task source.
>
>
> Also:
>
>
> When a MediaStreamTrack
> <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack>object
> ends for any reason (e.g., because the user rescinds the permission for
> the page to use the local camera, or because the data comes from a
> finite file and the file's end has been reached and the user has not
> requested that it be looped, or because the UA has instructed the track
> to end for any reason, or because the reference count of the track's
> underlying media source has reached zero), it is said to be ended. When
> track instance track ends for any reason other than the stop()
> <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-mediastreamtrack-stop>method
> being invoked on the MediaStreamTrack
> <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack>object
> that represents track, the user agent mustqueue a task that runs the
> following steps:
>
>  1.
>
>     If the track's readyState
>     <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-mediastreamtrack-readystate>attribute
>     has the value endedalready, then abort these steps.
>
>  2.
>
>     Set track's readyState
>     <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-mediastreamtrack-readystate>attribute
>     to ended.
>
>  3.
>
>     Fire a simple event named ended
>     <http://dev.w3.org/2011/webrtc/editor/getusermedia.html#event-mediastreamtrack-ended>at
>     the object.
>
> If the end of the stream was reached due to a user request, the event
> source for this event is the user interaction event source.
>
>
>
> Chrome will change its behaviour to conform to this text, subject to the
> rules imposed by the required isolation between tabs.
>
> This means that:
>
>
>   *
>
>     When two tracks in the same tab are fed from the same source, stop()
>     will cause both of them to be ended. The one on which the call was
>     not made will have an event named “ended” fired at it.

To me, that sounds like a reasonable interpretation. An alternative 
could be that the camera (microphone) is not turned off until all tracks 
it feeds have been stopped. The advantage of your interpretation is that 
it is simpler to revoke access - you'd only have to stop one track (I 
guess that you'd have to call getUserMedia to use that source again).

>
>   *
>
>     When a source is used in two tabs, calling stop() in one of the tabs
>     will not cause any effect on the other; the camera light will remain
>     on, the per-tab indicator will continue to show for the tab that is
>     still capturing, and media will continue to flow. Only when all tabs
>     have released the camera will the camera actually be turned off.

Seems reasonable.

>
>   *
>
>     The stop() method on MediaStream is gone.

I think it should have been removed from the draft some time ago.



What (and perhaps this belongs to public-webrtc) it is not fully clear 
is what would happen if the source is a PeerConnection, or a WebAudio 
API. What would stop() mean in those cases? Do we need it?

>
>
> This change will happen in the M32 timeframe.
>
>
> *
>
> --
> Surveillance is pervasive. Go Dark.
>

Received on Wednesday, 25 September 2013 17:21:31 UTC