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
Received on Tuesday, 30 July 2013 20:17:45 UTC