W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

RE: Feedback on the recording proposal

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 9 Oct 2012 16:29:17 +0000
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, "robert@ocallahan.org" <robert@ocallahan.org>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3853A50A63@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> On 2012-10-09 07:13, Robert O'Callahan wrote:
> > I liked the old StreamRecorder proposal that had a MediaStream.record()
> > method returning a StreamRecorder object with the rest of the API on the
> > StreamRecorder object. That supported multiple recordings that don't
> > interfere with each other, which seems like a good idea and is no more
> > complex to implement or use. If you do that, you don't need a
> > "recording" boolean.
> I think it would be nice to have the recording API in a separate
> interface. The old API had some issues but I agree that the record()
> method that returned the MediaStreamRecorder worked pretty well.

One of the main issues that Microsoft's Media Engine team had with the old design, is that it allows for overlapping recordings. There really were no good use-cases for that scenario, and on many devices starting two independent encoders simultaneously is just not practical given the resource constraints of the device.

The current design makes it intentionally harder to inadvertently start two concurrent recordings (though still possible, when working with multiple media streams), and provides an out (failure to start recording) for UAs that don't have the resources to run multiple recordings at once.
Received on Tuesday, 9 October 2012 16:30:53 UTC

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