Thanks for the report, and dump!

pbos: I recall we used to have some sync problems related to Windows drivers, but this is OS X. Can you take a look?

I believe the AV sync offset is due to jitter buffer spikes. Does this AV sync ever recover once it goes out of sync?

No it does not. It continues to be out of sync. However, when we switch the stream from desktop back to camera it does get back into sync most of the times. But then that's not guaranteed.

FTR desktop capture is timestamped with TimeTick::Now:

https://chromium.googlesource.com/chromium/src/+/master/content/browser/media/capture/desktop_capture_device.cc#309

I'll take a look at SDPs tomorrow if they are in the dump to make sure that sync labels are applied properly.

What're you using for audio? How do you tell whether they are in sync or not?

The far end audio is just voice. We used simple counting mechanism to check for the AV sync. It was way off and was pretty easy to notice. Audio was ahead by atleast a couple of seconds.

This may be the root cause: https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/webrtc_audio_sink.cc?rcl=0&l=85

In other words, it's currently impossible to guarantee A/V sync because the necessary plumbing is missing. ;-)

I believe it's closer related to googCurrentDelayMs increasing to ~3 seconds. I wouldn't expect these to far out of sync otherwise. We're aware of the video jitter buffer increasing delays significantly over audio delays, I think this best tracks that.

Even without corresponding track labels we should best-effort be kind-of-in-sync I think.

ganapathy.vijay@gmail.com, Is there a media server involved here? 

Sounds to me like the stream switch isn't handled correctly causing unexpected jitter. Could either be caused by webrtc not timestamping correctly when streams switch, but also by a misbehaving 

Sorry for a late reply. Yes there is a media server involved here. We do use temasys plugin for our app on IE. We don't get into this situation with IE. To my knowledge our mediaserver doesn't treat these two any differently. At this point I think this point it appears to be a chrome factor.

Could you provide an rtc event log from chrome://webrtc-internals while you reproduce this problem at the receiver?
Check the checkbox named "Enable diagnostic packet and event recording" under "Create Dump".

That way we can look at the timestamps to ensure they're sane, as a first step.

ping

Archiving due to inactivity. Please reopen if more information becomes available.