RE: pausing and resuming

Adam,
  Yes, that is how it will work.  Here's a small detail I'm thinking about:  

adding pause/resume requires adding a 'paused' state to the Recorder.  (If the device is in the 'paused' state, then the resume() command will cause it to start gathering data again, but not if it's  in any other state.  Also, attempts to change the codec will fail when in the paused state).  Thus the author can check for the Recorder.state attribute for the paused state before calling resume() and thus can be sure that the call will succeed.  

On the other hand, muting a track does not put the Recorder in the paused state, because muting operates at the Track level and even the muted Track is still recording media (silence or black frames).  However, unmute() only works  on a track that has been muted (otherwise the recorder will raise a bad-state exception, similar to the one you'll get if you call resume() when recording hasn't been paused).  So should the Recorder keep a read-only list of muted tracks (ids) that the app can examine before calling unmute()?  Alternatively we could add an function: Boolean isPaused(TrackID).  It seems asymmetric to me for the API to allow the developer to check that  resume() will work, but not that  unmute() will work, but I'm not sure it really matters.  

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Wednesday, December 19, 2012 2:08 AM
To: Stefan Hakansson LK
Cc: public-media-capture@w3.org
Subject: Re: pausing and resuming

On 2012-12-14 22:32, Stefan Hakansson LK wrote:
> On 12/14/2012 07:43 PM, Jim Barnett wrote:
>> I think we need a somewhat broader discussion on what sorts of 
>> objects can be paused and resumed.  In particular, do we need an API 
>> surface to pause/mute and resume Streams or Tracks?  Right now, a 
>> track can have readyState=muted, but that is a read-only attribute, 
>> so it looks like the muting happens on the underlying device (or at the remote end).
>
> That is right, muted is meant to mean that the source is not 
> delivering data right now, and it is readonly.
>
> But the app can use the "enabled" attribute, just set it to false, and 
> the track becomes effectively muted (zero amplitude audio 
> samples/blackness in the uncoded domain).
>
> I've been arguing that we should remove that attribute and instead 
> have the opportunity to disable at the sink. The reason for this 
> proposal is that the way the media element is currently specced [1]; 
> this control is already there ("enabled" for audio, "selected" for 
> video). This can be confusing IMO; e.g. if you enable a 
> MediaStreamTrack (kind = audio), but it is disabled at the sink, and vice versa.
>
> But what I really wanted to say is: in the case of recording there is 
> a big difference between disable/mute and pause. I'm thinking of a 
> tape recorded. If you disable/mute the input, the tape continues 
> rolling (but silence/blackness is captured). If you pause the tape 
> stops rolling until you "resume" recording. I think these are two 
> different concepts, and we should support both.

What Stefan writes here is exactly how I would like to see the recording work.

- Pause on the recorder
    -> Nothing is written to the recorded file until recording is resumed.
- Recorded track gets muted (someone sending you a stream has disabled a track on their end or, e.g., a camera has been temporarily muted via some browser UI)
    -> Silence or blackness recorded for that track
- Recorded track gets disabled locally (via API enabled = false;)
    -> Silence or blackness recorded for that track

/Adam

> [1]
> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#m

> edia-resources-with-multiple-media-tracks
>
>
> ...
>>
>> 1.Are we going to want pause/resume functionality on Track?
>
> I think we need a method to disable/mute tracks (the previous example 
> was to exclude one specific audio track from a part of a recording for 
> privacy even if the recording of the other tracks continue). I think 
> we should do disable at the sink, but that is another discussion.
>
> For recording we also need pause/resume, but that is not per track, it 
> is for the entire recorder.
>
>>
>> 2.If yes, do we also need it for recording?
>>
>> As for point 2, I think that there are use cases for pausing 
>> recording without pausing the underlying Track, but those could be 
>> handled by cloning the MediaStream. I find that a bit clunky, but it 
>> would keep the recording API smaller and simpler.
>>
>> -Jim
>>
>> *From:*Travis Leithead [mailto:travis.leithead@microsoft.com]
>> *Sent:* Friday, December 14, 2012 12:47 PM
>> *To:* Jim Barnett; robert@ocallahan.org
>> *Cc:* public-media-capture@w3.org
>> *Subject:* RE: pausing and resuming recording
>>
>> To try another approach to this scenario, we could instead try a 
>> "stitch" API. It would take a previously handed-out blob, and start 
>> recording into a new Blob which will be initialized with a 
>> copy/pointer to the data in the first blob (since its immutable). In 
>> short it just "resumes" from previously recorded content. This is 
>> probably easier speced than implemented, but might be worth 
>> considering given the complexity of what you're proposing with a new fundamental state.
>>
>> *From:*Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
>> *Sent:* Friday, December 14, 2012 6:15 AM
>> *To:* robert@ocallahan.org <mailto:robert@ocallahan.org>
>> *Cc:* public-media-capture@w3.org 
>> <mailto:public-media-capture@w3.org>
>> *Subject:* RE: pausing and resuming recording
>>
>> It’s certainly simpler for the recording doc to assume that pause and
>> resume are on the MediaStreams/Tracks themselves.   However,  I’m sure
>> that people will ask for the ability to pause the recording without 
>> pausing the stream.  One use case would involve a PeerConnection.  
>> You are talking to someone and recording the conversation.  You reach 
>> a point where you’re going to give them your credit card info or some 
>> other sensitive information.  You want to keep talking but pause the 
>> recording so that it doesn’t capture the sensitive information.  
>> (This sort of use case is very common in call centers.)
>>
>> You can presumably handle this case by cloning the MediaStream and 
>> using one copy for the PeerConnection and the other for recording, 
>> but for most people it will seem simpler to have a single MediaStream 
>> and then pause recording on it.
>>
>> -Jim
>>
>> *From:*rocallahan@gmail.com <mailto:rocallahan@gmail.com> 
>> [mailto:rocallahan@gmail.com] *On Behalf Of *Robert O'Callahan
>> *Sent:* Thursday, December 13, 2012 11:51 PM
>> *To:* Jim Barnett
>> *Cc:* public-media-capture@w3.org 
>> <mailto:public-media-capture@w3.org>
>> *Subject:* Re: pausing and resuming recording
>>
>> On Fri, Dec 14, 2012 at 8:43 AM, Jim Barnett 
>> <Jim.Barnett@genesyslab.com <mailto:Jim.Barnett@genesyslab.com>> wrote:
>>
>>     It makes sense to add pause and resume functionality to recording.
>>     The question is what the exact semantics should be.  First of all,
>>     we currently say that it a Track is muted, the record function
>>     should fill in with silence or black frames.  (I think that this
>>     would be necessary so that playback could be synchronized).
>>
>>     Now, if the entire record() operation is paused, I assume that it
>>     would simply stop gathering data while it is paused.  (So that if
>>     you pause and resume recording, there will be a sudden skip during
>>     the playback.)
>>
>>
>> I don't think this functionality should be in the recorder. Instead I 
>> think we should be able to pause and resume MediaStreams themselves.
>> Then we can do things like have a media element which is playing a 
>> MediaStream apply its pause/resume controls directly to the MediaStream.
>>
>>     However, I can imagine cases where someone might want to pause
>>     recording a specific track, without muting the underlying track (for
>>     example, the user would still be speaking, but it would be left out
>>     of the recording).
>>
>>
>> I don't understand this scenario. Can you explain it in more detail?
>>
>> Rob
>>
>> --
>> Jesus called them together and said, “You know that the rulers of the 
>> Gentiles lord it over them, and their high officials exercise 
>> authority over them. Not so with you. Instead, whoever wants to 
>> become great among you must be your servant, and whoever wants to be 
>> first must be your slave — just as the Son of Man did not come to be 
>> served, but to serve, and to give his life as a ransom for many.” 
>> [Matthew 20:25-28]
>>
>
>

Received on Wednesday, 19 December 2012 13:33:01 UTC