Closed Bug 1301387 Opened 5 years ago Closed 5 years ago

Video and audio not synchronized during opentokrtc call

Categories

(Core :: WebRTC, defect, P1)

All
macOS
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox49 --- unaffected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: bogdan_maris, Unassigned)

Details

[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.
Forgot to mention that this reproduces with e10s disabled or enabled and also does not reproduce on Chrome.
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!
Rank: 17
Priority: -- → P1
(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 :)
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?
Flags: needinfo?(ctai)
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.
Flags: needinfo?(ctai)
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.
Since I could not reproduce this anymore using latest Nightly 54.0a1, I'll go ahead and close it as WFM.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.