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

App Javascript refactor #56

Merged
merged 20 commits into from
Jul 16, 2020
Merged

App Javascript refactor #56

merged 20 commits into from
Jul 16, 2020

Conversation

gingervitis
Copy link
Collaborator

@gingervitis gingervitis commented Jul 13, 2020

JS App refactor

Instead of having various JS files creating global variables and timers scattered across the app, I wanted a single object as a source for entire app management.

  • As a result some files have been consolidated into a primary app.js "Owncast App" object, which gets created in a closure during page load. We also have a "OwncastPlayer" class (player.js) which handles mostly VideoJS functionalities of the video.
  • status.js, config.js, airplay.js have been removed. Airplay function has been moved into player.js, since it's videojs player related.. player.js has been moved out of /player dir.
  • created commonly used constants in utils.js, including urls, file names, timer values.

The main app.js flow:

  1. Sets up Vue.js app. After Vue app has mounted, it will instantiate the Videojs player from video.js.
  2. Fetches /config data, then updates Vue UI with results
  3. Instantiates "Messaging Interface" functionality (message.js), which basically sets up all the DOM events and interactions needed for the Chat section.
  4. Sets up Websocket instance for Chat.
  5. Fetches Stream Status, when videojs player is ready. The app will subsequently handle any Vue UI updates and Video actions based on status.
  6. Other
  • handles "extra user content" fetch (after config fetch), then updates Vue UI accordingly.
  • deal with player events

Player.js flow:
After the Vue app has mounted, from (1) above

  1. Prep our video object instance with any video-related event callbacks the app wants to make.
  2. Then actually init the videojs() on the <video> element in the DOM (with options defined in utils.js).
    This will lead Videojs's ready() state, so from there the App can start fetching Stream Status.

Current implemented Video playing logic:

  • When the app first loads, everything should be in an offline state. A logo will be in the video background. The Stream Status will poll every 5s.

  • When Stream status flips to online: true, we'll tell videojs player to play() the stream.

  • As long as the status is online the video player's poster will update with the stream's current thumbnail.

  • When the Stream status flips to online: false, we'll set the App back to the offline state with the logo in the background.

  • When the video's ended event fires, we'll also set the app back to the offline state.

  • If the status ever comes back online, right now videojs will just play() again. Not sure if any resets of sort are necessary.

TODO:

  • still need to fix ES6 issues for Safari.
  • implement disable-chat after stream ends
  • cleanup any timers?
  • double check logic and UI for more graceful error and networking fail handling

@gingervitis
Copy link
Collaborator Author

@gabek Can you give this branch a test run and see how it works for overall?
Chrome, Safari seem fine. Mobile, not sure yet, I haven't checked. And don't get me started with MS Edge :P, still need to find a machine for that.

I have 2 checkbox items left, which I think I will create separate tasks for them outside of this MR. I'd like to get this thing merged sooner so we can do other things with it.

Thanks!

@gingervitis gingervitis changed the title WIP: 0707 refactorjs App Javascript refactor Jul 15, 2020
@gabek
Copy link
Member

gabek commented Jul 15, 2020

Lots of changes! This is awesome!

Here's some initial things, but I may very well be testing it incorrectly, have incorrect opinions, or I'm misunderstanding things so don't take my comments too seriously :)

Chat stuff

  • The chat sidebar immediately automatically hides itself when online = false. Is that what we want?
  • If the chat sidebar is visible when offline but it changes to online = true the chat sidebar hides itself again. It's almost like anything that happens hides the chat.
  • Chat is hidden by default when offline. Is that what we want? Nevermind I don't see that now.
  • It takes two clicks of the chat toggle button to make the chat sidebar re-appear the first time you try it.
  • I see now why you asked if chat should be enabled by default in an offline state. If online = false, and then you visit the page, you won't be able to chat, but everyone else who has been there, and are in the 5min grace period, can still chat. So everyone should have the 5 minute grace period based on status.lastDisconnectTime.
  • My avatar changes every time I reload the page. I thought it generated the same one every time.

Player stuff

  • Video player shows poster over the video immediately when online = false, but you can keep hearing the audio.
  • I'm seeing when offline moves to online = true that the player starts playing, but it starts playing the old offline content, it never seems to go back to the live stream to update. The stream is live but the player only keeps looping over the old content. Do we need to tell the player to re-load the src? Even when I refresh the page it still doesn't play the correct video. I have to force refresh and clear cache (CMD+shift+r). Maybe there's a way to tell VideoJS "never cache playlists" or something? This is only an issue if you're sitting at an offline page and then the broadcaster goes online, so it's specific. I need to find a way to provide the frontend a more correct online = true. I'm afraid right now there's a chance that when it goes online and the player starts playing it starts playing the old stream, and then for some reason the player never plays the live content. I'm not sure if it's just a timing thing (enough HLS segments are not yet available) or if the offline video is just cached in the browser and it starts playing it. For now I'll probably just increase the amount of time between Broadcast Start -> online = true to be sure.

For this last item here's how I'm testing it:

  1. Start the server.
  2. Visit the web page and see that it's offline.
  3. Start playing some content to the server.
  4. See that the server comes online.
  5. It starts playing the old cached content and looping.
  6. It never starts playing the live content until you force refresh the browser.

@gingervitis
Copy link
Collaborator Author

gingervitis commented Jul 16, 2020

Responses!

Oh wait, some explanations first!.. which may help with what you're seeing.

  • The Chat panel display is controlled by the browser's localStorage. If you're a brand new user, the chat panel will be hidden. Once you've opened it (or and then closed it), localStorage will save that setting. So that the next time you return, the appearance of the chat panel will reflect how you last left off.

  • It looked like the original implementation of the Username seemed to generate randomly every time you come to the page. So I kept that implementation until you actually edit it. Once you edit the name, that name (and avatar image url) will also be stored in localStorage for you to use on subsequent page visits until you change it again. If you never change it (or clear out your localStorage, the user name will be random every time you visit.

  • Side note about user avatars - I saved a randomizer on the image url, per user. So if you're user "gabe" with you get "gabeimage+random()". If different "gabe" user joins the chat, that one will get "gabeimage+random()" image. The image url is saved, so that it's not re-generated every time your a new message appears.

  • The chat sidebar immediately automatically hides itself when online = false. Is that what we want?
  • If the chat sidebar is visible when offline but it changes to online = true the chat sidebar hides itself again. It's almost like anything that happens hides the chat.

Ah this is a bug! I'll fix! 😳

  • It takes two clicks of the chat toggle button to make the chat sidebar re-appear the first time you try it.

Bug, I'll fix!

  • I see now why you asked if chat should be enabled by default in an offline state. If online = false, and then you visit the page, you won't be able to chat, but everyone else who has been there, and are in the 5min grace period, can still chat. So everyone should have the 5 minute grace period based on status.lastDisconnectTime.

Oh good point. I'll update.

  • My avatar changes every time I reload the page. I thought it generated the same one every time.
    Explanation above!

Player stuff

  • Video player shows poster over the video immediately when online = false, but you can keep hearing the audio.

🤔 If you get to the page and online=false, yes you should see the poster - the poster of the user's logo. (that's what we want right?). Not sure about audio, where it's coming from. I can't repro that.

  • I'm seeing when offline moves to online = true that the player starts playing, but it starts playing the old offline content, it never seems to go back to the live stream to update...

Hm yeah I've wondered about caching. I can try the video.src() trick, maybe with a randomizer on the url, like src="video.url?random()"

@gingervitis
Copy link
Collaborator Author

Oh ok, I've repro'd .
So once online has flipped to false, I display "offline mode", which is just the user's logo poster.

Not sure what the intended display should be?

Can we flip to "online=false" after the ending animation video instead?

Player stuff

  • Video player shows poster over the video immediately when online = false, but you can keep hearing the audio.

🤔 If you get to the page and online=false, yes you should see the poster - the poster of the user's logo. (that's what we want right?). Not sure about audio, where it's coming from. I can't repro that.

@gabek
Copy link
Member

gabek commented Jul 16, 2020

The problem is the server doesn't know when the client has consumed all the video, so the server can't wait to flip the online. The server only knows when the broadcaster has disconnected. There's probably ~20sec more of video on the client after the broadcaster disconnects. I'm thinking when online changes to false nothing should happen until the player fires the ended event, and then switch to the offline UI?

…setting on pause to main app to keep player obj cleaner; use opacity to hide video element on offline as sometimes control bars may still linger with vis:hidden
@gabek
Copy link
Member

gabek commented Jul 16, 2020

🤔 If you get to the page and online=false, yes you should see the poster - the poster of the user's logo. (that's what we want right?). Not sure about audio, where it's coming from. I can't repro that.

Oh I meant

  1. Start playing content so online=true.
  2. Visit page
  3. Start playing the live video.
  4. Stop broadcasting content.
  5. Online changes to false but there's still video left to play, but you can't see it because the poster immediately gets in the way once online changes to false.

It's another example of just because online is false doesn't mean they're not still watching video, there's still seconds left + the "This stream is offline" video thing.

gingervitis and others added 2 commits July 15, 2020 23:08
* master:
  Fix missing default video bitrate if none is supplied
@gabek
Copy link
Member

gabek commented Jul 16, 2020

@graywolf336 Heads up, lots of changes here 🎊

@gabek gabek merged commit 42b0b05 into master Jul 16, 2020
@gabek gabek deleted the 0707-refactorjs branch July 16, 2020 19:17
gabek pushed a commit that referenced this pull request Apr 26, 2022
Bumps [date-fns](https://github.com/date-fns/date-fns) from 2.16.1 to 2.19.0.
- [Release notes](https://github.com/date-fns/date-fns/releases)
- [Changelog](https://github.com/date-fns/date-fns/blob/master/CHANGELOG.md)
- [Commits](https://github.com/date-fns/date-fns/commits)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
xarantolus pushed a commit to xarantolus/owncast that referenced this pull request Feb 14, 2023
…hatApiEndpoint

Ruffy/document new chat api endpoint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants