On 7/19/2012 1:16 PM, Robert O'Callahan wrote:
On Thu, Jul 19, 2012 at 1:10 PM, Randell Jesup <[email protected] <mailto:[email protected]>> wrote:Requiring using a ProcessedMediaStream might be confusing and contradictory to common use cases, like adding an output MediaStream from a PeerConnection directly to a <video> element.The idea is that, say, getUserMedia could create a ProcessedMediaStream internally and return that. Authors wouldn't be aware of it.
Ok, that's roughly equivalent to the "if pushing into a mediastream is blocked, discard", just done via a ProcessedMediaStream, and were saying that any realtime source should operate that way via ProcessedMediaStream. What will happen if you have different MediaStream source (video.captureStreamUntilEnded()), and a consumer blocks? From the previous discussion it pauses (blocks pushing in). Side effect: any data frozen in the streams in buffers will play out when it unfreezes, I assume, which may be slightly odd.
The question is "what are the sematics of a MediaStream at the JS level, and how should an author use them?"
I.e. we need a coherent statement about how they work and what can be expected, and make sure that handles the use-cases, and state how a user should expect to use them (and how it expects sources and sinks to react). And detail the edge conditions (merging/splitting of MediaStreams).
-- Randell Jesup _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
