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

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

From: Per-Erik Brodin <per-erik.brodin@ericsson.com>
Date: Fri, 26 Nov 2010 19:01:40 +0100
Message-ID: <4CEFF604.4050904@ericsson.com>
On 2010-11-23 18:24, Anne van Kesteren 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.
>
>
A Stream can be treated as an abstract representation of a media stream. 
When a Stream is to be transported over a peer-to-peer connection, the 
format can be negotiated between the peers. In the current 
ConnectionPeer API, such format negotiation would be transparent to the 
API. If we would specify a single resolution for video, for example, 
that resolution may be to high for some mobile devices to encode in 
real-time. A mismatch in supported formats is just one reason why a 
peer-to-peer transport may fail, but that doesn't mean that the peers 
can't communicate. When relaying through a server you can interoperate 
with anything.

If you are referring to sendFile(file) on ConnectionPeer, the file may 
just as well come from the user's hard drive via <input type=file> and 
thus it will be up to the application to ensure that whatever is sent to 
the other peer is usable there.

//Per-Erik
Received on Friday, 26 November 2010 10:01:40 UTC

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