RE: Playability of individual Blobs produced by a MediaRecorder

One option would be an optional parameter to requestData() that would specify whether to deliver the current data as the end of one file and to start another.  We could do the same thing with record() when the timeslice is specified, specifying whether each returned segment was a complete file or not.  However such a parameter wouldn't make much sense for record() without a timeslice specified.  What would it mean to call record() without a timeslice and with createfile? (or whatever it's called) set to 'false'.  Would we wait till the stream ended and then dump out one huge buffer without any headers or metadata?  

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, August 01, 2013 7:23 AM
To: Jim Barnett
Cc: Rachel Blum; robert@ocallahan.org; Travis Leithead; public-media-capture@w3.org
Subject: Re: Playability of individual Blobs produced by a MediaRecorder

On 1 August 2013 13:20, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 30 July 2013 22:17, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
>> I can’t think of a good use case for a series of contiguous playable blobs.
>
> I can.  You are maintaining a continuous record of the output of a 
> security camera.  You don't want to archive an arbitrarily long stream 
> into a single file, instead you want to ensure that you can separately 
> access records from a given time (slice) without having to scan 
> through a single big stream.

(Whoops, fat-fingered the enter key...)

A command that triggers the atomic creation of the end of one file and the start of the next seems like an appropriate solution, though I'm sure that other options are possible.

I'd like to avoid the need for applications to create overlapping recording contexts.  That sucks for any number of reasons.

Received on Thursday, 1 August 2013 17:13:36 UTC