You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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)
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.
The text was updated successfully, but these errors were encountered: