Re: MediaRecorder: stopRecording event language

On 2013-09-20 09:30, Harald Alvestrand wrote:
> On 09/20/2013 03:11 AM, Jim Barnett wrote:
>>
>> To me this is an argument for MediaStream raising the ended event when
>> stop() is called.  When an application requests an operation, it must
>> be able to find out when that operation has finished.  So either the
>> call should be synchronous or it should trigger a done/completed
>> event.  Apps that don’t care about that event can ignore it.
>>
>
> We had that discussion earlier, with no consensus to change; apparently
> there are other specs that have the same language about stop() and ended.

I think we have not finalized this discussion yet. The language in the 
draft is a bit confusing; it talks about "other reason than the stop() 
method being invoked", and I think that stop() method refers to when the 
(Local)MediaStream used to have a stop() method. It does not any more. 
And there is no clean way for the app to programatically revoke the 
access to microphones and cameras - it would have to find all tracks in 
all streams (which can be many if they have been cloned and/or assembled 
in new constellations) that correspond to the source it wants to revoke 
access to and stop all of those tracks. I think this is an area we might 
want to revisit.

I may be totally wrong, but I think Harald may be referring to the ended 
event on the MediaStreamTrack. The current draft is a bit vague on when 
it would be fired, but I think we have in the past said it should not 
fire as a result of the app using the stop() method on the track, but 
fire if the track stops e.g. because the camera is unplugged.

>
> (It will take me some time to dig out the discussion and/or examples if
> I have to do that; if someone has it on the tip of their keyboard,
> please chime in!)
>

Received on Saturday, 21 September 2013 11:38:29 UTC