Re: Thoughts on converging MediaStream and Stream objects

I think you are misled by an accident of naming.

If anything should be converged with the Stream API (something I'm not 
at all sure of), it should be the MediaStreamTrack.

The sharpest difference is that a Stream is a byte pipe; a 
MediaStreamTrack is a control surface for an underlying implementation 
where the concept of "byte" doesn't even have to be meaningful.

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).
>
> 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.
> 2. Streams serve as an excellent output format from a MediaStream recorder (rather than a Blob).
>
> [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 Friday, 9 December 2011 21:28:24 UTC