1301387 - Video and audio not synchronized during opentokrtc call

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P1)

Description

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

[Affected versions]:
- latest Developer Edition 50.0a2
- latest Nightly 51.0a1

[Affected platforms]:
- Mac OS X 10.10.5
- Windows 10 64-bit

[Steps to reproduce]:
1. Start Firefox
2. Visit https://opentokrtc.com/ and start a call.

[Expected result]:
- Conversation between two does not suffer from delay or interruption.

[Actual result]:
- Video and audio are not synced (Nightly has the same behavior, but RC 49 has a barely noticeable delay, Chrome works as expected)

[Regression range]:
- Will search for a regression as soon as possible.

[Additional notes]:
- 49.0 RC does not manifest the same delay so it's something that broke in 50.
- Delays were only encountered on Mac OS X, no matter who was caller or callee.

Comment 1

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

Forgot to mention that this reproduces with e10s disabled or enabled and also does not reproduce on Chrome.

Comment 2

[Dan Minor [:dminor]]

Just to clarify, you have both Windows and OS X as affected platforms but below you say the delay only shows up on OS X. Does that mean you've tested calls from Windows to OS X and the problem occurs, but only on the OS X machine? Thanks!

Comment 3

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

(In reply to Dan Minor [:dminor] from comment #2)
> Just to clarify, you have both Windows and OS X as affected platforms but
> below you say the delay only shows up on OS X. Does that mean you've tested
> calls from Windows to OS X and the problem occurs, but only on the OS X
> machine? Thanks!

I should have been more clean on this matter.
So we tested calls between Mac OS X and Windows (that's way I wrote both of them under 'Affected platforms'), where each OS was caller and callee, and the delays were only seen in Mac OS X.
Hope this clarifies things :)

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

CCing ctai since it's possible given the current known version it affects that this was fallout from ctai's landing of the don't-buffer-video bug.  Testing a Nightly from before his landing, and a few days after would likely resolve that question.  Same thing for bug 1301660.

ctai, what are the dates for the landing?

Comment 5

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

stop buffering video is landed on 2016-08-05 03:32:33 PDT(https://bugzilla.mozilla.org/show_bug.cgi?id=1201363#c179). And the target milestone of bug 1201363 is 51.

Comment 6

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

Well, I tried again using latest Developer Edition on the same setup I reproduced the first time and everything works as expected...no delays, no interruptions.

Comment 7

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

Since I could not reproduce this anymore using latest Nightly 54.0a1, I'll go ahead and close it as WFM.