- From: Per-Erik Brodin <per-erik.brodin@ericsson.com>
- Date: Fri, 26 Nov 2010 19:01:40 +0100
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