Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization

[Magnus Westerlund <[e-mail]>]

On 2013-02-14 14:00, Timothy B. Terriberry wrote:
> Magnus Westerlund wrote:
>> between media sources, a particular encoding and MediaStreamTrack. To my
>> knowledge it is not agreed on what should happen if I have two
>> MediaStreams, each with an audio and video MediaStreamTrack that are the
>> same media source, i.e. microphone and video camera. Even if no
>> configuration for encoding has been done, will the peer receive two
>> copies or are these optimized to send only two RTP streams, one with the
>> audio, one with the video that is used in both?
> 
> I think you have all of the same problems if you simply have two
> MediaStreams with the same MediaStreamTrack locally, without involving
> RTP at all. In the MediaStream Processing API
> <https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html> Section
> 2.1, we argued that the best approach is to require that all sinks of a
> MediaStreamTrack advance at the same rate (as otherwise you require
> either multiple decoders or unbounded buffering). I don't think that's
> written down anywhere in either an IETF or W3C spec that's currently
> active.

I don't quite get the example in Section 2.1 in the yellow box. It is
unclear what the URI's represent.

I agree with the sentiment that all copies of the same media resource
will need to be played out in sync also locally. I would like to add
that in the context of different media sources there exist an importance
to have a common clock base and deal with that nominal sampling rates
does not match the actual as measured by the local reference clock.


> 
> Once we have resolved that issue, I think that once you involve
> PeerConnection, the only thing that makes sense is that a series of
> invocations of AddStream() on the sender's PC produces a corresponding
> set of objects on the receiver's PC: if you call AddStream() with two
> MediaStreams that both contain the same MediaStreamTrack, then the
> remote side should create two MediaStreams that also contain the same
> MediaStreamTrack. If a sender wishes to use multiple SSRCs for a single
> track for either layered coding or simulcast or whatever, then following
> draft-alvetrand-mmusic-msid-02, they must have the same value for
> identifier and appdata.

I agree that you need to have the corresponding objects on the receivers
side. When it comes to identifiers I get a bit confused here on how the
MSID draft is supposed to work. It switches between MediaStream and
MediaStreamTrack in section 4. Is the WMS semantics providing the
MediaStream IDs or the MediaStreamTrack IDs the SSRC is associated with?
The current text appears to indicate both. Is the ID making it possible
to distinguish between the two types?


> 
>> If they are then they MUST share the same CNAME in both media streams
>> all the MediaStreamTracks.
> 
> I think it is perfectly reasonable to require that all SSRCs that share
> the same msid attributes (i.e., that belong to the same
> MediaStreamTrack) use the same CNAME. 

MediaStreamTrack or MediaStream?

That should probably be written
> down somewhere (in the msid draft? in the RTP usage draft? I don't have
> a strong opinion, but the former at least involves fewer cross-document
> references). I think that solves the issue you're raising here.

At some point we will need to have a mapping between the API concepts
and RTP to be written up and agreed on. We will have to find the most
suitable spot for that.

> 
>> Yes, it may incur delay, depending on what media operation you are
>> doing. I think the requirement we are discussing is what the sender MUST
>> do so that the receiver can ensure synchronization if they want to.
> 
> Agreed, and I think Harald's answer was that the sender must put the
> tracks it wants synchronized into the same MediaStream, and that the
> browser must then use the same CNAME for any two tracks that belong to
> the same MediaStream (which would have to be applied transitively). I'm
> not sure anyone has disagreed with this. 

Good, lets start with assuming that this has consensus and that if
anyone objects there is time to do that now.


The only question is whether it
> also must use the same CNAME for two different tracks that appear in
> different MediaStreams.

Yes, this is the real question. And I think my answer is it depends.

The issue I have is that different mediaStreams can have different mixes
of tracks, and they can share some or all tracks. From a receivers
perspective it appears necessary to avoid media glitches that a receiver
can determine that a given track is a duplicate of another and ensure
that they are played in sync and on the same time line.

As long as only one encoding and one RTP stream is sent for each media
source then implicit its tracks must have a common CNAME over all the
MediaStreams it occurs in.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------