timvideos
Change frontend to be static website
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.
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
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...
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.
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.
streaming-system - Tim Video's - Live Streaming for user groups and other events.
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.
Hi, I am interested in helping with this. I would use the Python library Nikola for the static website generation.
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.
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.
streamchicken - backend components for new timvideos.us streaming site
