RE: recording

Yes, I was thinking of this as one class with two different methods.
However, as Adam's subsequent email indicates, it could be one class
with one method: startRecord(optional timeslice),  where you get
all-at-once recording if timeslice is omitted.  I thought it was a bit
clearer to have two different methods, but don't  feel strongly about
it.  (I did intend the 'buffersize' argument to indicate number of
milliseconds, so 'timeslice' is a better name for it.)

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Tuesday, November 13, 2012 7:15 AM
To: Harald Alvestrand
Cc: public-media-capture@w3.org
Subject: Re: recording

On 2012-11-13 12:18, Harald Alvestrand wrote:
> On 11/12/2012 08:42 PM, Jim Barnett wrote:
>>
>> Here's a summary of what I think we agreed to in Lyon.  If we still 
>> agree to it, I will start writing it up.  (Please send comments on 
>> any or all of the points below.)
>>
> I think I like this. I'd like to see this as a proposal.
>>
>> Recording should be implemented by a separate class.  Its constructor

>> will take a MediaStream as an argument  (we can define it to take 
>> other types as well, if we choose, but no one is suggesting any at 
>> the
>> moment.)
>>
>> There are two kinds of recording:
>>
>> 1)incremental, in which (smaller) Blobs of data are returned to the 
>> application as they are available.
>>
>> 2)All-at-once, in which one big Blob of data is made available when 
>> recording is finished.
>>
> So are these 2 classes that both take a MediaStream as a constructor 
> argument?
> This might be simpler than having one merged class that does both.

I read the proposal as one class with two different record methods.

/Adam

Received on Tuesday, 13 November 2012 13:41:07 UTC