RE: pausing and resuming

Well, media streams are streams, so you can't really "pause" them, you just start dropping the stream contents. The way to encourage a track into the muted state is to disconnect the source from all sinks and hope that the UA is smart enough to stop broadcasting.

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Friday, December 14, 2012 10:44 AM
To: public-media-capture@w3.org
Subject: pausing and resuming

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).   PeerConnection also doesn’t have a pause method.

It seems to me that there will be plenty of use cases for pausing media, particularly at the track level  ( you run out of the shower to get an important call, realize that it’s a video call and you’re naked, so you pause the video while leaving audio going).  You could do this by fiddling with the actual device, but it would  be a lot simpler to have a GUI control.  So:


1.       Are we going to want pause/resume functionality on Track?

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<mailto:robert@ocallahan.org>
Cc: public-media-capture@w3.org<mailto: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]