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

Re: pausing and resuming

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 19 Dec 2012 08:08:25 +0100
Message-ID: <50D167E9.8020202@ericsson.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
CC: public-media-capture@w3.org
On 2012-12-14 22:32, Stefan Hakansson LK wrote:
> 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.

What Stefan writes here is exactly how I would like to see the recording 
work.

- Pause on the recorder
    -> Nothing is written to the recorded file until recording is resumed.
- Recorded track gets muted (someone sending you a stream has disabled a 
track on their end or, e.g., a camera has been temporarily muted via 
some browser UI)
    -> Silence or blackness recorded for that track
- Recorded track gets disabled locally (via API enabled = false;)
    -> Silence or blackness recorded for that track

/Adam

> [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 Wednesday, 19 December 2012 07:08:52 UTC

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