W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 25 Nov 2010 14:05:18 +1100
Message-ID: <AANLkTimKNvmqUx3Bpb1w-gXdf4E90fnPDzWViXgHquOS@mail.gmail.com>
On Wed, Nov 24, 2010 at 4:24 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 19 Nov 2010 19:50:42 +0100, Per-Erik Brodin
> <per-erik.brodin at ericsson.com> 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.
>
> But if we want interoperability for streams, also taking into account P2P
> messaging, we need a single format. Otherwise users with different browsers
> could end up not being able to communicate.

Can the decision for a file format be taken completely separately from
the codec decision for the <audio> or <video> element, I wonder?

My assumption is that a StreamRecorder will get video (or audio) from
a device and it will be possible to hand it on to a <video> (or
<audio>) element for display. Since these elements supports specific
codecs, wouldn't that imply that the StreamRecorder needs to save it
in those formats, too? Unless, of course, we want to introduce some
kind of transcoding element that is plugged between a recorded stream
and a <video> (<audio>) element.

Cheers,
Silvia.
Received on Wednesday, 24 November 2010 19:05:18 UTC

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