- From: Kevin Marks <kevinmarks@gmail.com>
- Date: Mon, 14 Feb 2011 22:33:13 -0800
On Mon, Feb 14, 2011 at 2:39 PM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 19 Nov 2010, Per-Erik Brodin wrote: > > > > We are about to start implementing stream.record() and StreamRecorder. > > The spec currently says that ?the file must be in a format supported by > > the user agent for use in audio and video elements? which is a > > reasonable restriction. However, there is currently no way to set the > > output format of the resulting File that you get from recorder.stop(). > > It is unlikely that specifying a default format would be sufficient if > > you in addition to container formats and codecs consider resolution, > > color depth, frame rate etc. for video and sample size and rate, number > > of channels etc. for audio. > > > > Perhaps an argument should be added to record() that specifies the > > output format from StreamRecorder as a MIME type with parameters? Since > > record() should probably throw when an unsupported type is supplied, it > > would perhaps be useful to have a canRecordType() or similar to be able > > to test for supported formats. > > I haven't added anything here yet, mostly because I've no idea what to > add. The ideal situation here is that we have one codec that everyone can > read and write and so don't need anything, but that may be hopelessly > optimistic. That isn't the ideal, as it locks us into the current state of the art forever. The ideal is to enable multiple codecs +formats that can be swapped out over time. That said, uncompressed audio is readily codifiable, and we could pick a common file format, sample rate, bitdepth and channel caount specification. In the meantime I encourage implementors to experiment with > this (with all the APIs vendor-prefixed of course) to work out what the > API should look like. Implementation experience is the main thing that > will drive this forward, I think. > > That is a fair point.
Received on Monday, 14 February 2011 22:33:13 UTC