Re: pausing and resuming

I don't think we can handle pausing by simply stopping recording. When recording is stopped, the app can change parameters, codecs etc. the blobs we get on resumption will be incompatible with the original ones. That's fine if they are two separate recordings, but not one that has been paused. We will need an explicit paused state. 

On Dec 16, 2012, at 1:47 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote:

> On 2012-12-14 23:18, Jim Barnett wrote:
>> Stefan, Using the definitions you give below, would you want to be
>> able to pause a single track while the other tracks are still being
>> recorded?
> 
> No.
> 
> That would make synchronization of the playback quite
>> difficult.  Using your terminology, I was thinking that the API would
>> allow you to pause recording the whole stream, and mute individual
>> tracks.  (If you want the effect of muting the entire stream, you can
>> mute each track individually.)
> 
> Exactly, the this is what I meant. And perhaps the pause/resume of a whole recording can be solved by stopping the current one at pause, and start a new one at resume, and let the app handle the two blobs.
>> - Jim
>> 
>> -----Original Message----- From: Stefan Hakansson LK
>> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Friday, December 14,
>> 2012 4:32 PM To: public-media-capture@w3.org Subject: Re: pausing and
>> resuming
>> 
>> 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.
>> 
>> [1]
>> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#media-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 Sunday, 16 December 2012 14:03:55 UTC