On 2010-11-23 18:24, Anne van Kesteren wrote:
On Fri, 19 Nov 2010 19:50:42 +0100, Per-Erik Brodin
<per-erik.bro...@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


Reply via email to