W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

RE: pausing and resuming recording

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Fri, 14 Dec 2012 18:19:45 +0000
To: Travis Leithead <travis.leithead@microsoft.com>, Jim Barnett <Jim.Barnett@genesyslab.com>, "robert@ocallahan.org" <robert@ocallahan.org>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A1636F727@nasanexd01h.na.qualcomm.com>
I assumed that the previously handed-out blob was supposed to be fully-encoded and in some container format.  If new media is to be appended to the blob, then it seems that the container would have to be opened, new data appended with possible re-encoding (though not strictly necessary), and a new container generated.  Would recording formats now be sufficient to describe UA capabilities?  The UA would also have to be able to append multiple containers – should part of the UA recording capabilities now not only entail what kind of encoding/container it supports, but also whether it can support append functions for specific containers (ISO BMFF, Matroska, etc.)?


From: Travis Leithead [mailto:travis.leithead@microsoft.com]
Sent: Friday, December 14, 2012 9:47 AM
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 18:20:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:13 UTC