W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > November 2015

Re: [mediacapture-main] Track changes on cloned streams

From: Martin Thomson via GitHub <sysbot+gh@w3.org>
Date: Thu, 12 Nov 2015 17:59:22 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-156184550-1447351161-sysbot+gh@w3.org>
I don't think that the original problem is getting through here and I 
don't know how I can rephrase this to help.  Certainly, my "removal 
for other reasons" comment only muddied the waters.  I'll try again 
anyway...

If you remove a track from a stream, then it stops being present in 
the playback of that stream*.  If you add a track to a stream, then it
 starts being present in the playback of that stream*. [*] modulo 
track selection and that sort of thing.

It is entirely possible that the events that these generate happen 
after the effects can be observed.  For example, if the browser adds a
 track to a stream, you might see the contents of that track before 
the `addtrack` event fires.

For a cloned stream, if we rely on an application propagating track 
changes between cloned streams, changes of this nature will result in 
a delay between the manifestation of the change in the original stream
 and the manifestation of the change in the cloned stream.

For example, I take a stream from `RTCPeerConnection` and clone it.  
It initially contains only video.  A live audio track is added.  The 
original stream plays out the phrase "Hello, my name is Lucy.".  The 
application has to propagate the changes before the cloned stream sees
 the track and by the time this is done it plays out only "I name is 
Lucy".

-- 
GitHub Notif of comment by martinthomson
See 
https://github.com/w3c/mediacapture-main/issues/271#issuecomment-156184550
Received on Thursday, 12 November 2015 17:59:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:28 UTC