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 has far-fetching consequences I think. 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... On Thu, Aug 22, 2013 at 10:15 AM, Stefan Håkansson LK < 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> 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 10:20:22 UTC