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

["Timothy B. Terriberry" <[e-mail]>]

Harald Alvestrand wrote:
> I don't understand what the problem is here. I may be dumb.
> If syncing is important to the guy writing the service, (he can't live
> with them being unsynchronized), he should put them in the same stream.

The argument goes that if we leave this unspecified, web authors will 
test against browser A which does X, and not against browser B which 
does Y, and users of browser B will suffer when things don't work like 
they did in browser A.

Personally I'm not convinced this argument applies here. For cases like 
"Do the contents of this table element show up at all when I fail to 
close my <tr>?" it's pretty important, but in reality resynchronization 
is only going to affect things so much... if things get more than a few 
100 ms out of sync on the wire, the experience is going to be terrible 
no matter what you do (and I'd call them "bad" long before that point).

The goal of pixel-perfect rendering for webpages might be reasonable, 
but sample-accurate rendering of real-time media will never be possible 
given the limitations of real-world networks, and whether you're forcing 
synchronization or not, the media will still play.

> The practical issue I can think of would be a source that had its own
> clock, not the system clock, but is otherwise a local source. Having the
> same CNAME would require resynchronizing that source. I don't know if
> any such sources exist in practice, but again, I don't want to outlaw them.

I can certainly think of cases where two local streams with, e.g., the 
same sampling rate would advance at different rates measured against a 
global wallclock. For example, a gUM stream running against the 
microphone's clock vs. a <video> tag playing back against the soundcard 
output clock.

Then AFAICT forcing the use of the same CNAME means we will always add 
some additional latency in the receiver to perform the 
resynchronization. In the above situation, I'm not sure that's always 
the best choice.