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

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

From: stefan hakansson via GitHub <sysbot+gh@w3.org>
Date: Sun, 15 Nov 2015 13:41:55 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-156812625-1447594914-sysbot+gh@w3.org>
>>  I'm trying to find the use case where this is a practical problem.
 I don't think the RTCPeerConnection example is one. First of all, the
 time for the signaling to set up the additional audio track is 
probably much longer than the event propagation on the receiving side.

> Aren't there cases where streams appear prior to receiving 
signaling?  I'm thinking about the case of a re-offer with bundle.  
The answerer can start sending media long before passing back an 

I've been thinking a bit about that. (If the answerer stars sending 
immediately, while it takes a while for the answer to make it back to 
the offerer) it is clear the the addTrack event in some cases could 
fire as soon as the offerer gets RTP packets with mid indicating to 
the m-line in question. However, the `RTCTrackEvent` would not be able
 to contain the `streams[]`data, nor would the track have an Id until 
the answer has been applied.

It seems to make most sense, in case there is an outstanding offer, to
 hold off firing `ontrackĀ“ until the answer has arrived? I'm not sure 
exactly what the spec says though.

But regardless, in this situation there might be a gap in the cloned 
stream. The question is if the issue is big enough for us to redesign.

GitHub Notif of comment by stefhak
Received on Sunday, 15 November 2015 13:41:56 UTC

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