W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: ReplaceTrack and track.id (Re: ReplaceTrack - need to evaluate alternatives)

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Fri, 17 Apr 2015 02:19:33 -0400
Message-ID: <5530A5F5.4070506@mozilla.com>
To: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
(Ah, this is where you explained how A talks to B. I missed it)

On 4/15/15 3:01 AM, Harald Alvestrand wrote:
> Just reiterating what I percieve as the original purpose of having IDs 
> on these items:
> To let Javascript applications talk to each other about the tracks.
>
> That is:
>
> A sends X and Y to B
>
> A sends (data channel, via web server, whatever) to B, something like:
> {'display_map: { 'X': 'left', 'Y: 'right' }}
>
> B displays X to the left and Y to the right.
>
> If tracks have IDs that are consistent over the connection, this can 
> be done by an application without referring to any property of the 
> PeerConnection whatsoever; it just looks at the tracks.
>
> I'd like that property to remain - it's not necessary, because the 
> receiver could look up the RTPReceiver for the track and get the 
> identifier value from there, but it makes life easier in the simple case.

If RtpSender.id = original_track.id, and RtpSender.id is used in SDP (as 
I think someone suggested, can't find the post right now sorry), then 
your model would seem to hold, provided that iff A wants to use 
replaceTrack, it would remember to indirect through its senders, e.g. 
send {'display_map: { [senderX.id]: 'left', [senderY.id]: 'right' }}

People who don't use replaceTrack would be unaffected.

.: Jan-Ivar :.
Received on Friday, 17 April 2015 06:20:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC