RE: Playability of individual Blobs produced by a MediaRecorder

Rachel,
I can't think of a good use case for a series of contiguous playable blobs.  It suppose it might be used as an ad-hoc substitute for streaming, but that's not something I'd want to encourage.  If someone can come up with a good use case, I'd be willing to consider it though.

On the issue of overlapping calls to record(), the way I read that passage is that an early version of the spec allowed for them, but Travis couldn't think of a good use case for them.  So we've taken that possibility out.  If you really want that functionality, you can clone the MediaStream, create a separate MediaRecorder for it, and use the two recorders any way you want - overlapped or not.


-          Jim

From: groby@google.com [mailto:groby@google.com] On Behalf Of Rachel Blum
Sent: Tuesday, July 30, 2013 3:06 PM
To: Jim Barnett
Cc: robert@ocallahan.org; Travis Leithead; public-media-capture@w3.org
Subject: Re: Playability of individual Blobs produced by a MediaRecorder


On Tue, Jul 30, 2013 at 5:32 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
I've always assumed that requestData was for the case where the developer wants to set his own timing for getting (possibly unplayable Blobs).  If he wants a complete resource, can't  he call stop() followed by start() if we wants to begin another one?

Question: What if I want the blobs to be contiguous? record() potentially waits for the MediaSource. While I read requestData the same way you do, is there a use case for requesting contiguous playable blobs/forcing a new "first" blob?

Slightly related note: Capture scenarios mentions record() being overlappable (http://www.w3.org/TR/capture-scenarios/#issues-7). The MediaRecorder spec says 'if the state is not "inactive", the UA must raise an INVALID_STATE exception and return immediately'.

 - rachel