Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleaner channel takeover for video #64

Open
LBegnaud opened this issue Sep 5, 2019 · 2 comments
Open

Cleaner channel takeover for video #64

LBegnaud opened this issue Sep 5, 2019 · 2 comments
Labels
feature request something new to be implemented help wanted I could use some help with this

Comments

@LBegnaud
Copy link

LBegnaud commented Sep 5, 2019

We use a channel takeover every morning to play a short video, and currently that video plays at different times across the various chromecasts, also some of them will lag perhaps due to increased bandwidth on the server hosting the video file.

Looking for some way to clean this up. My thought is for the multicast server to proxy/buffer the video and wait for all takeovers to complete before starting playback. Perhaps even setup some kind of multicast stream (not to be confused with the name of the project...) to scale better for more chromecasts.

@superhawk610
Copy link
Owner

Hmm, that's an interesting use case I hadn't considered.

Just thinking out loud:

  • have each device confirm with the central server once they've initially loaded
  • have the server decide on a time a few seconds in the future after all devices have confirmed page load
  • devices receive timestamp from server and set a timeout to play the media once that time hits

As for keeping devices in sync and accounting for buffering, that will require additional work:

  • need a consistent method of detecting video buffering (do <video> elements emit events?)
  • when one client begins buffering, notify the server, which will in turn notify all other clients to pause
  • once all clients have confirmed that they've paused, server decides on a time a few seconds out, then repeats initial pairing sync with the new timestamp

It's definitely doable, but it would require relatively heavy integration between Multicast and the media file host - if you've just got a plain audio/video file hosted on a network-accessible URL, it should be doable, but not so much for something like YouTube or Vimeo.

I'm currently working to finalize the project-wide refactor and 3.0 release, then I have a handful of features planned for the 3.1 release. Since this will require a decent amount of novel work, I'll tentatively add it to the 3.2 milestone, but if you'd like to contribute anything toward it that would be more than welcome! (If you do, make sure to base your work on the master branch, that contains the existing 3.x code).

@superhawk610 superhawk610 added feature request something new to be implemented help wanted I could use some help with this labels Sep 5, 2019
@LBegnaud
Copy link
Author

LBegnaud commented Sep 5, 2019

I know next to nothing about multicast traffic, but that seems like it would keep things in sync by the nature of the feed. Keeping devices in sync is definitely tricky, and isn't terribly important for our use case... But seems like it would be useful in general if maybe we generalize video channels into this app.

Basically allow for video uploads directly and define a channel against it. That would allow this app to control start times etc (which could solve the first point)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request something new to be implemented help wanted I could use some help with this
Projects
None yet
Development

No branches or pull requests

2 participants