- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Wed, 4 Dec 2013 16:33:36 +0000
- To: Randy Lin <rlin@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Randy, I'm not sure why the UA would call stop(). I would expect the application to do it. But in any case, the behavior should be as follows: both start() and stop() queue tasks, so the stop() method's task will not be executed before the start task completes. One of the first things that the start task does is to set the state to 'recording'. At the time the stop task executes, it is true that the start event may not have been processed, but the state will be 'recording' and the stop task will execute and fire the dataavailable and stop events. The only time that the stop task would raise an error would be if the recorder was in the wrong state. - Jim -----Original Message----- From: Randy Lin [mailto:rlin@mozilla.com] Sent: Wednesday, December 04, 2013 3:26 AM To: public-media-capture@w3.org Subject: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API? Hi all, Refer this API document. https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/MediaRecorder.html What's the expect behavior if UA try to call the stop method before receiving the onstart event on MediaRecorder API. Should we queue this stop() task after onstart event or throw exception on stop method invoked or cancel the recording task and fire the events which stop() method required? ------------------------------------- -rlin
Received on Wednesday, 4 December 2013 16:34:05 UTC