Re: pausing and resuming

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 07:03:26 UTC