W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2013

RE: Playability of individual Blobs produced by a MediaRecorder

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 30 Jul 2013 20:17:17 +0000
To: Rachel Blum <groby@chromium.org>
CC: "robert@ocallahan.org" <robert@ocallahan.org>, Travis Leithead <travis.leithead@microsoft.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810626C5@GENSJZMBX01.msg.int.genesyslab.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC