W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2011

Thoughts on converging MediaStream and Stream objects

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Wed, 7 Dec 2011 18:22:28 +0000
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381C4697@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
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 

Received on Wednesday, 7 December 2011 18:23:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:08 UTC