RE: pausing and resuming

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?  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.)

- 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 Friday, 14 December 2012 22:19:26 UTC