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

Re: Playability of individual Blobs produced by a MediaRecorder

From: Rachel Blum <groby@chromium.org>
Date: Tue, 30 Jul 2013 12:06:05 -0700
Message-ID: <CACmqxcwoMB0akBGR1Tg2UYZfxOB40ofgbK7sho4gi54EQexdKA@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, Travis Leithead <travis.leithead@microsoft.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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
Received on Thursday, 1 August 2013 09:20:46 UTC

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