Re: recording

On 11/13/2012 02:38 PM, Jim Barnett wrote:
> 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.)

The nice thing about two classes is that you declare up front which 
functions you intend to call on it, so implementations can optimize for 
one way or the other way.

If the functions are all the same, and you can call getData on an 
initially all-at-once recording to break it into chunks, then we don't 
need two classes; all-at-once recording is just a capture with a very 
long buffer.
>
> - 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 14:09:12 UTC