Re: Capturing streams from DOM nodes: open issues

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