RE: Allocate a source to source less MediaStreamTracks

Yes, if we allow unattached MediaStreams/Tracks to be added to a PeerConnection, it should be possible to pass the MediaStream to gUM (which would use the types of the Tracks and any constraints  that we're set on them to determine the eligible set of devices.)

- Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Thursday, May 30, 2013 6:25 AM
To: public-media-capture@w3.org
Subject: Allocate a source to source less MediaStreamTracks

In Lyon we had a discussion about the events and delays involved in accepting a "call" (to use traditional telecom nomenclature). (And I am sorry to bring up WebRTC stuff; the problem to solve is there, but the solution would be done in Media Capture TF).

There was a discussion about using "unattached" (i.e. with no source
attached) MediaStreamTracks that are added (collected in a MediaStream of course) to the answerer's PeerConnection. The idea was that the connection setup, negotiation, creation of a MediaStream object at the receiving end etc. could progress immediately and not have to wait for user consent (on the answerer side) to use microphone and camera.

I think there was quite some support for this as it would speed things up and reduce the risk for audio clipping when the person at the answerer side accepts the call.

As a result of that discussion (I think) AudioMediaTrack and VideoMediaTrack now have constructors, so you can create such objects (not having a source) - and of course construct a MediaStream from them.

But there is still one piece missing: there should be a possibility to use a MediaStream containing MediaStreamTracks with no sources as an argument to getUserMedia, and as a result (if the user approves) sources would be allocated to those MediaStreamTracks.

I think we should add this, what do others think?

Stefan

Received on Thursday, 30 May 2013 14:07:25 UTC