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

On 2013-08-22 12:19, Tommy Widenflycht wrote:
> I thought the idea was that the source of the tracks on the receiving
> side was their respective local PeerConnection, not the original source
> on the sending side.

This is my understanding as well. But it would keep the Id, right?

> This has far-fetching consequences I think.

I'm not sure I follow. What I intended to say I agree to is that tracks 
on the receiving side of a PC should be possible to play out in sync if 
their origin is the same (coming from the same physical unit, e.g. a 
computer with one microphone and one camera) regardless of if they are 
sent in one MediaStream or two different MS's, and that using the same 
RTP CNAME is needed to accomplish this.

> Consider adding a bit of echo and/or some sound effects on the
> MediaStream between the microphone and the PC using WebAudio. Should the
> original source identifier still be preserved? A PC processes the media
> similarly by doing error concealment in different forms...

This is a good point. We've not discussed the source identifier of a 
(audio) track originating from an AudioContext. But to me it seems 
obvious it can't be the same source identifier as the one of the 
microphone creating the original track.

>
>
> On Thu, Aug 22, 2013 at 10:15 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 2013-08-21 18:15, Martin Thomson wrote:
>      > On 21 August 2013 06:21, Tommy Widenflycht <tommyw@google.com
>     <mailto: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.
>      >
>      >> 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.
>
>     I agree fully to this (and this is what I tried to express at the Boston
>     interim).
>
>      >
>      >
>
>

Received on Thursday, 22 August 2013 11:13:30 UTC