search

chrisguttandin / timing-provider

An implementation of the timing provider specification.
MIT License
30 stars 3 forks source link

Abstracting the transport layer #250

Open gurupras opened 2 years ago

gurupras commented 2 years ago

The entire set of timing* libraries that you have created have been extremely easy to use and get media synchronization up and running. However, I'm wondering if it would be possible to abstract out the WebRTC aspect of this.

I'm happy to try and contribute in this area, but I'm new to typescript and rxjs so it's going to be a pretty steep challenge for me :confused:

chrisguttandin commented 2 years ago

Hi @gurupras, I'm actually working on this already. I realized that a package with the generic name timing-provider should not really depend on my service. At least not without an option to change it. I would love this to become a package which can be used with many different backends/strategies to synchronize the vector.

If possible can you talk a bit about your use case and what you want to use as a replacement?

gurupras commented 2 years ago

I'm assessing the ease of video synchronization using this package. Setting up a simple demo was extremely easy. I did run into some puzzles with seek, but I'm working on that.

My issue with WebRTC is that many universities and work places block UDP and WebRTC(?). It's also possible that I've misconfigured my STUN/TURN servers and/or the WebRTC configuration.

Regardless, in large 'rooms', it might not be feasible to have a participant's browser connect to every other participant present in the 'room'. In such cases, a backend-based model is preferable, where the backend takes on the responsibility of dealing with all of the connections and passing messages across.

chrisguttandin commented 2 years ago

I think that WebRTC blocking became less usual lately because WebRTC is so ubiquitous by now. But that's just my personal assumption. In case UDP is blocked WebRTC can also use a TCP connection if necessary. But you're right the more clients you have the more likely it gets that there will be at least one which has problems. But a TURN server should usually solve these problems.

I think switching to a WebSocket comes with other tradeoffs. It's for example a single point of failure and doesn't scale very well.

Long story short, I still believe that making the network layer swappable is a good idea. I just need to find some time to do it ... :-)