search

timvideos / streaming-system

Tim Video's - Live Streaming for user groups and other events.
https://code.timvideos.us/
Apache License 2.0
131 stars 52 forks source link

Change frontend to be static website #125

Open joeladdison opened 7 years ago

joeladdison commented 7 years ago

The current frontend is a mixture of client side and server generated content. For example, each group has its own set of JS functions generated when the index page is rendered on the server. Instead of doing this, move to a purely standalone frontend that interacts with the backend via API calls.

micolous commented 6 years ago

Yup. May also want to look at building this on some modern-ish framework as well. At the moment we hack up a lot of the DOM, and I'm convinced that's not a great idea. There's probably a bunch of XSS issues with what we've got now.

That would help to achieve some of the mobile compatibility goals outlined in #60 and #66.

My "ideal" flow would be to have some backend service which just reports current status. This could be a static file (for the case of YouTube-based streaming, where we don't have to "ping" anything) or something dynamic (for the case of Flumotion-based streaming, where we should be pinging telemetry).

Then we can do something like hijack DNS inside of the venue as a method to block casual streaming.

GitHub
Replace JWPlayer with fully free (libre) software equivalent · Issue #60 · timvideos/streaming-system
JWPlayer is released under a CC BY-NC-SA 3.0 -- the NC (non-commercial) part means it doesn't satisfy the Debian Free Software Guidelines (DFSG) and hence is not truely "free (libre) software". The...
GitHub
Change from jwplayer to using video.js, projeckktor or mediaelementjs · Issue #66 · timvideos/streaming-system
While jwplayer is technically "open source" its CC-BY-NC which is not free. Video.js and preojekktor look like decent really open source replacements.
mithro commented 6 years ago

The system is actually already divided into two parts.

The frontend is only dependent on the config file. The frontend is also the only place which deals with schedule stuff. I have wanted to move that into it's own "service" too. The backend serves the "dynamic" part which is really just JSON and a few very simple monitoring HTML pages.

See the diagram at https://github.com/timvideos/streaming-system/blob/master/website/README.md

It should be trivial to replace the frontend with something a bit more static.

GitHub
timvideos/streaming-system
streaming-system - Tim Video's - Live Streaming for user groups and other events.
micolous commented 6 years ago

Yeah, more the point in a YouTube streaming setup you need even less smarts, provided that you have reasonable expiry times on the monitoring feeds. You could have that JSON pushed into some cloudy-storage bucket instead.

wcmckee commented 6 years ago

Hi, I am interested in helping with this. I would use the Python library Nikola for the static website generation.

mithro commented 6 years ago

I'm going to leave @joeladdison and @micolous to guide you here. While I wrote all the original stuff I don't really have the time to move it forward.

micolous commented 6 years ago

Update on this:

@joeladdison has a React-based website running at timvideos.us -- the repository and source for this is currently pending release.

Backend for the new React site is a Python script that emits a bunch of JSON files, based on what we get from Veyepar, you can find this at https://github.com/micolous/streamchicken.

These will eventually get merged back here, or into a new repository on the timvideos organisation page on GitHub.

These assume that you're streaming to YouTube, and not using Flumotion.

GitHub
micolous/streamchicken
streamchicken - backend components for new timvideos.us streaming site