Re: Thoughts on converging MediaStream and Stream objects

On 12/07/2011 07:22 PM, Travis Leithead wrote:
> As Rich mentioned in [1], it might be interesting to see how the
> Stream API [2] relates to MediaStream objects and what, if any,
> alignment the two may have.
>
> I've done some previous cursory investigation in this space and I'd
> like to share my conclusions with this group.
>
> Some points of commonality: * Both the Stream and MediaStream objects
> are non-buffered conduits for data flow * Both the Stream and
> MediaStream objects are meant to work with URL.createObjectURL
>
> Some points of difference: * A Stream should be of a known MIME type
> (type is its only property); MediaStream's type is opaque (not
> necessarily exposed) * A Stream can be programmatically built
> (StreamBuilder interface); a MediaStream must be supplied by a source
> (local or remote) * A Stream can be used in most places that a Blob
> can be used (like XHR, postMessage, etc.); a MediaStream has
> dedicated uses (PeerConnection).
I agree to most of the above (commonalities/differences). One could also 
add that MediaStream's implicitly have very strict delay requirements 
(as one intended use is for conversational A/V services), something that 
is not as obvious for Stream's, and that MediaStream's are rather 
tightly related to media elements (for Streams this depends on the 
(MIME) type).
>
> One possible way of relating these two concepts that occurred to me
> was to have the more specific MediaStream derive from the more
> generic Stream. Ultimately, I don't think that this is a good was to
> relate the two primarily because of the assumptions around a Stream's
> type: * Streams have a known Mime type (identifying the content
> flowing through the Stream). Conceptually, a MediaStream's content is
> dynamic (tracks can be combined, enabled, disabled, and possibly
> changed via capture device configuration changes). What should the
> Stream::type property be? Could it be reliable for all usages of
> Stream? For example, StreamReader's "readAsBlob" (and the other
> output formats) would imply a transcoding to a known type, yet the
> StreamReader lacks the necessary configuration settings to control
> how the transcoding should be done.
>
> Another way of relating the Stream to a MediaStream is as an output
> format. As mentioned in the "Post Processing" section in the
> MediaStream Capture Scenarios first draft [3], using a Stream as the
> output from a MediaStream recorder (whatever form or shape such a
> recorder may take) allows for an additional set of near-real-time
> processing of captured media information--scenarios that would not be
> possible if a Blob were used as the capture output (since a Blob must
> have a fixed length when created). Finally, the StreamReader
> interface allows web developers to control how the stream is chunked
> into 1 or multiple Blobs as it is produced by a recorder (another
> possible control point that we could avoid having to specify).
>
> So my conclusions are that: 1. MediaStreams and Streams are
> sufficiently different that they should not attempt to be "combined"
> logically.
Agree to this.
> 2. Streams serve as an excellent output format from a
> MediaStream recorder (rather than a Blob).
I could see use of both types (or perhaps it is sufficient to use 
StreamReader to create blobs if recorder produces a Stream). My worry 
would be that we become dependent on Stream; I don't know the planned 
schedule for it.
>
> [1]
> http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0036.html
>
>
[2] http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm
> [3]
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#post-processing
>
>
>
> -Travis
>
>
>

Received on Thursday, 8 December 2011 10:42:08 UTC