[Question] Browser Compatibility

[bmsan]

Hello,

Firstly thank you a lot for your work with timingsrc & timing-object.

I've successfully used them to play synchronized two videos side by side under Chrome. While testing the same code on Firefox & Safari things looked very weird ( a lot of desynchronizations), while in Chrome I could not notice any desynchronization happening.

I wanted to ask you if this could be a browser compatibility issue(maybe certain features that are needed for synchronization are not yet implemented by Chrome competitors). I am not excluding that maybe I've introduced a bug in the integration of the solution that is triggering only on non-chrome browsers.

[chrisguttandin]

Hi @bmsan,

I would expect the library to work in recent versions of all 3 major browsers (Chromium, Firefox and Safari). However the implementation in Safari is different and therefore the result is not as smooth as in the other two browsers.

The actual synchronization is handled by two different algorithms. By default the userAgent string gets parsed to determine which algorithm to use. Since Safari is not capable of processing changes of the currentTime or the plackbackRate of a MediaElement in a timely manner the position in Safari is set abbruptly whenever it changes. Firefox and Chromium based browsers happily handle frequent changes of both properties which is why they are adjusted gradually to keep a MediaElement in sync with a TimingObject in these browsers. The technique for doing so has been taken from Tom Jenkinon's media-element-syncer.

But the behavior that you described for Firefox is not expected. Does the demo work for you in Firefox?

[bmsan]

Hi @chrisguttandin,

I managed to get the same behavior in the demo, but I had to do some visual modifications (css) in order to actually notice the behavior. (Running side by side it was harder to tell for me if the videos were in sync or not).

• I've made the video elements with position: absolute & opacity: 50%. Basically they should get overlaid with transparency and desynchronizations should be easier to spot. (I edited the properties directly in the browser on top of the demo that you are providing).
• I had to quickly pause/start the video playback multiple times to actually get to see the desynchronizations. (I think I noticed them the best at about ~80seconds in the movie where the bunny runs after the butterfly).

Doing the steps mentioned above didn't seem to affect Chrome where things seemed to be perfectly aligned(as far as I could notice).

I am using Firefox 89.0.2 (64-bit) on Windows and Chrome Version 91.0.4472.114 (Official Build) (64-bit).

[chrisguttandin]

Hi @bmsan, thanks for describing your debugging technique. That trick to overlay the videos is really handy.

I played around a bit with it today. I couldn't spot anything unexpected. Sometimes the player takes a while to jump to the new position and that sometimes happens quicker for one of the videos but they eventually get synced again.

Is that what you mean by "desynchronization" or is it something else?

[bmsan]

Thanks for your time to look into this!

I'm sharing with you an example from firefox. Initially the streams seem in sync(but when the bird falls things seem to go out of sync for a while). Please note that in this recording the play was continuous ( I didn't mess with the video stream play/pause during the recording), https://streamable.com/xo5som

Before recording I tried to let the video to buffer ( I played the recorded section in advanced and rewinded using the go back 5 seconds button multiple times)

In chrome I don't get to see the behavior shown in the video. Maybe the Firefox engine is struggling with my computer resources for this task, while the Chrome engine might be more efficient for this specific usecase hence why it seems to work without issues?

[chrisguttandin]

Thanks for providing that video. That was very helpful. In the video it looks like the videos are slowly drifting away by getting faster as they should. I would have expected them to slow down if the position is above the expected value.

With that in mind I revisited the algorithm to update the position and the playbackRate and I think I found the bug. Since I couldn't reproduce the bug in the demo could you please double check if the bug is gone on your end?

[bmsan]

Thanks for your quick turnaround! I've ran the demo in firefox and things do look better (while playing continuously) now(my computer load might also be different than when I ran the demo yesterday).

What I am noticing now and( I am not sure if it was happening before or if it is expected behaviour) is that in firefox(chrome seems ok) is that after I press pause and then play, there are a few seconds in the beginning where both videos and their counters update with ~ 1 fps, while the timerObject counter is updating continuously.

If it helps I can record a video of this behavior.

[chrisguttandin]

I guess there is not much we can do about that. The DEFAULT_THRESHOLD is one second. That means when the currentTime of the video is one second or more off, the timingsrc gives up updating the time gradually and seeks to the desired value. It seems like it sometimes takes more than one second for the browsers to jump to the new position in the video.

I meanwhile found a bug in Firefox which caused some weird sounds when the player slowly approaches the desired position. Because currentTime is not accurate in Firefox the value for the playbackRate jumps back and forth between 1 and almost 1. But this is what causes problems in Firefox.

I added a workaround for this which makes sure the playbackRate never goes back to 1. https://github.com/chrisguttandin/timingsrc/commit/6fcbed8afca42d0aa6076f4312a62b15a524808f