Re: Playability of individual Blobs produced by a MediaRecorder

On Tue, Jul 30, 2013 at 5:32 AM, Jim Barnett <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