W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] need a way to set output format from StreamRecorder

From: Kevin Marks <kevinmarks@gmail.com>
Date: Mon, 14 Feb 2011 22:33:13 -0800
Message-ID: <AANLkTikB+zzcUX1B7peEr1k5YG_3kE9k-w8eSrxAXXi4@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC