W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2014

Re: Capturing streams from DOM nodes: open issues

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 15 May 2014 14:49:35 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Jim Barnett <1jhbarnett@gmail.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFE52E8@ESESSMB209.ericsson.se>
On 15/05/14 16:16, Martin Thomson wrote:
> On 15 May 2014 06:49, Jim Barnett <1jhbarnett@gmail.com> wrote:
>> 1) are you thinking of an API other than pause/resume for "don't record that
>> stuff"?
> Yes, because of propagation delays inherent in the application.
> 1. Stream pauses.
> 2. Browser generates and dispatches event.
> 3. Application receives event, processes it.
> 4. Application issues pause() to recorder.
> 5. Recorder acts.
> The time between 1 and 5 is such that you can't be sure you haven't
> recorded at least some dead air.  You could block recording in
> anticipation of such an instruction, but that will probably cause
> other problems.
> And it's far worse in the other direction, where you miss the first
> frames of the newly resumed stream.

I see the problem, and it is not only tied to capturing from DOM nodes 
(as you point out a track can be muted).

We could potentially have an option on the recorder to have it 
automatically stop/resume recording when data goes away/comes back.

I guess we'd then define it in a way that recording should stop only if 
all tracks are muted, and resume as soon as one of them are again "live".

But it would be interesting to know how long the delay is 1-5 in the 
list above.

>> 2) under which of the circumstances that you list below would the
>> MediaStream "end"?
> None of them.  That being the point.  These are cases where the stream
> enters a temporary state of suspension.

Received on Thursday, 15 May 2014 14:49:59 UTC

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