W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2013

Re: RECAP: Conclusion: Cloning and sharing of MediaStreamTracks - worth it?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 23 Aug 2013 12:21:18 +0200
Message-ID: <5217379E.8050107@alvestrand.no>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Tommy Widenflycht <tommyw@google.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 08/21/2013 06:14 PM, Martin Thomson wrote:
> On 21 August 2013 06:21, Tommy Widenflycht <tommyw@google.com> wrote:
>> So a user wants to send the audio MST through PC1 (with relay) and the video
>> MST through PC2. How does this require a MST to belong to more that one MS?
> In order to send A on PC1 and V on PC2, you need to have separate
> MediaStream instances, one for each PC.  Maybe you could use the same
> MediaStream and synthetically reject certain m-lines from each PC, but
> that doesn't help the receiving end.

The code I was envisioning when the problem was described looked like this.

pc1 = new PeerConnection(...)
<pc1 connects to peer A>
pc2 = new PeerConnection(...)
<pc2 connects to peer B>

pc1.onaddstream = function(stream) {
   audioOnlyStream = new MediaStream(stream.GetAudioTracks());

(Won't work in Chrome since relaying isn't supported yet, of course.)

This would relay audio coming from peer A to peer B, and would not relay
But since there's no automatic cloning either in GetAudioTracks or
the audio track(s) coming from A will now be members of both "stream"
and "audioOnlyStream".

If the track can only belong to one stream, it would have to be:

pc1.onaddstream = function(stream) {
    audioOnlyStream = new MediaStream();  // no tracks
    // FOR loop not quite right - Javascript's weird
    for track in stream.GetAudioTracks() {

Slightly more code.

>> And how can there be any expectation that the audio and video are
>> synchronized on the receiving side?
> This has to be possible.  The two tracks have the same source, with
> the same clock, and they should have the same (RTCP) CNAME.
> Assembling the two tracks into a single MS at the receiver should
> result in the playback being synchronized.

Surveillance is pervasive. Go Dark.
Received on Friday, 23 August 2013 10:21:50 UTC

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