RE: revised recording proposal

> It's not unlikely that some implementations that return blob-at-a-time will be considerably faster than some implementations that return file-at-a-time (the variant where file-at-a-time writes/swaps to disk, while blob-at-a-time stays within memory the whole time).

If RAM is not an issue, you may be right.  But when you are dealing with a limited heap space and the blob is not GC'ed upon consumption then what?  

If we have to comply with a requirement to provide timesliced data, I still think we are not exploring all options.  I've already posed the question to the spec author and the mailing list about why we are using blobs to return timesliced data versus using ArrayBuffers, and I have not received a response.  My understanding is that existing GC's handle the two data types very differently (if I go into more details I may have to start discussing proprietary implementations).   

> There are some proposed applications (speech recognition, recording to remote media on a limited-memory device) where file-at-a-time would be thoroughly inapppropriate.

As I have mentioned in another email, I don't believe those applications are currently outlined in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html.  My suggestion was to move support for these scenarios into a second version of the spec.  Also, if the idea is to enable reliable streaming of captured data, I don't think overloading a recording API with additional functionality is the way to do it.  A TCP-based PeerConnection media streaming solution may help in this regard, but that is not a topic for this mailing list.

I will reiterate that I like the direction in which this specification is moving.  However, I think there are enough fundamental issues with the spec as written that I feel it is not appropriate at this time to bring it to an FPWD stage.  I would like to see at least one more version before going that route.

-Giri

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Thursday, November 29, 2012 3:26 AM
To: public-media-capture@w3.org
Subject: Re: revised recording proposal

On 11/29/2012 08:53 AM, Stefan Hakansson LK wrote:
> On 11/28/2012 08:28 PM, Mandyam, Giridhar wrote:
>> There is a difference between returning a blob at timeSlice intervals 
>> until stopRecording is called, versus returning a File object only 
>> once.  I don't want to get into a discussion on how different GC's 
>> are treating blobs today, but to say that there is no performance 
>> difference between the two is premature.
>
> That is an aspect I did not consider! I - naïvely - was only thinking 
> about the API layer.
>
> If I understand you correctly, the issue is more related to returning 
> several instances of (time-sliced) recorded data during an ongoing 
> recording vs. only one set of data after the recording has ended than 
> to the actual handling of Blob's vs. File's.
It's not unlikely that some implementations that return blob-at-a-time will be considerably faster than some implementations that return file-at-a-time (the variant where file-at-a-time writes/swaps to disk, while blob-at-a-time stays within memory the whole time).

I don't think we're likely to see consistency in which way the advantage goes.

There are some proposed applications (speech recognition, recording to remote media on a limited-memory device) where file-at-a-time would be thoroughly inapppropriate.

Received on Thursday, 29 November 2012 16:14:25 UTC