feat(multistream): Experimental multistream #25
Conversation
…t not settable when the streamer is not checked
Entrivax
force-pushed
the
experiment/multistream
branch
from
ba80631 to
4aa2363
Compare
|
After a lot of time, I rebased this PR and done a few changes to the UI, here is the current version: Since last time, the synchronization is now more stable, but at the cost of being able to play/pause and seek from the different players, that's why the seek and the play/pause buttons were added to the drawer containing the timeline. |
|
Wow this looks really good, thank you for these two PRs!
I'm in the early stages of refactoring a lot of the frontend code to be more type-safe and clean. When that is more complete I can take a look at the ability to control the video state (play, pause, seek, etc) using the players instead of static buttons. I believe it should be possible as the player API can emit states. No need to implement in this PR as it's probably not easily doable right now. For the release notes, do you mind if I link your Youtube video demoing the feature? |
|
No problem!
Oh that's pretty nice! At the beginning, I tried to listen to the play/pause/seek events of the player, except it always send events without distinction if it's either a script or the user that did the action, so infinite looping events, it was really hacky to try to make it work and not really readable, so I tossed it for now. And sure, no problem! Let me know if you find another issue! |
Co-authored-by: Zibbp <[email protected]>
|
Weird, I get an error with the build docker image on the channel page, but not with the dev server: |
|
Ok, that's not an issue brought by this PR, I have the same thing when building the docker image on the |
Works great for livestreams now.
Maybe expand the button to a small div to support the playback buttons + the expand button? That gets in the way of resizing/moving the videos though, so still an issue. I'm fine with leaving like this until the player itself can handle the video state unless you have any other ideas. Another question, is it possible to place the streams in a default configuration rather than requiring the user to place the stream every time they open the page? It doesn't have to be too fancy, I'd say one column per video and if the user wants to change it let them. Regarding the error, it looks like it's trying to statically build in a channel for some reason. It shouldn't be doing that. I'm guessing it's something with your local setup? Maybe try building with |
Yeah, unfortunately, it will get in the way, I will try to find a solution for that and maybe suggest it in an another PR, if that's good for you?
Done, now it should display every stream side by side by default, and if there is more than 3 streamers, it will display them on 2 rows by default.
Yeah, my local env is a Frankenstein's creature right now, maybe there is something weird happening. |
Works for me. I'll try incorporating this into the player when the frontend refactor is more complete.
Thanks, this provides a much better user experience. |
It's good for me, only you can merge the PR, so I leave it to you! |
This PR goes in pair with Zibbp/ganymede#355!
Adds a multistream page for playlists.
It uses playlist as a way to group multiple streams together, then allows to play them together, in sync (granted the Streamed at date is well filled.)
Accessible from the menu in the playlist page.
I had to implement another version of the video player, to allow multiple ones to be sync together. It will probably need a big refactoring between the two players (
VideoPlayerandSyncedVideoPlayer) to merge them, since it would need to rework the current VOD page, and probably the chat player too.In the multistream page, there is no chat for the moment, it will come later, after trying to refactor both the
ChatPlayerand theExperimentalChatPlayer