- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 Jun 2011 11:05:43 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12530 Per-Erik Brodin <per-erik.brodin@ericsson.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |per-erik.brodin@ericsson.co | |m --- Comment #10 from Per-Erik Brodin <per-erik.brodin@ericsson.com> 2011-06-28 11:05:41 UTC --- I still would like to be able to create MediaStream objects from individual tracks. One use case that this would enable is taking the audio track from a stream that is being received from a remote peer and combining it with the audio track from a local stream so that MediaStreamRecorder can be used to record the conversation to a single blob (as opposed to recording the remote peer audio to one blob and the local audio to another blob). If the different interfaces are only to prevent a buffered track from being passed to a MediaStream constructor then I think this is better served by simply having a readonly boolean property "buffered" or "streaming" and letting the MediaStream constructor throw when a buffered track is present in the arguments. I would expect the MediaStream tracks to show up on the media elements when playing a stream: URL so maybe those tracks are not always buffered. The availability of individual tracks will have to be tracked in some way. I also think that the enabled/disabled/selected states should be enough to determine whether a track is sent with a PeerConnection or not, if a received track is not supposed to be played back I guess it could always be disabled/unselected, right? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 28 June 2011 11:05:44 UTC