Author here, this is a fun surprise to wake up to! I was doubting whether my project was "ready to post on HN" but someone beat me to it.
With Superstreamer, I'd like to create building blocks that simplify video end-to-end. While I initially wrote it as an "all-in-one" toolkit, I'm more leaning towards an open architecture. Like, you could use Stitcher to insert HLS interstitials (like ads, or bumpers) but have your original playlists come from Mux, Cloudflare Stream, etc... The transcode and package infrastructure is there for you to use it if you'd like to stick to a fully self hostable solution.
As for player, it's a neat facade around HLS.js (kudos to the maintainers, their project is great), while initially a streaming library, the facade exposes an interface that makes sense for UI developers.
I skimmed the Readme, the What is Superstreamer? page, and features list. I still don't understand when I would use this, or when I would recommend it to someone. I'm an engineer somewhat familiar with the space.
You may consider starting with a simple unique value proposition and reworking presentation from there.
Take the first sentence of the Readme as example: "Superstreamer is a self hostable platform that aims to simplify the complexities of video delivery" - and answer questions:
1. Who is benefiting?
2. How is this better?
3. What complexity is being solved?
4. What's the tangible outcome, or CTA?
5. What well-known alternative is this related to?
ChatGPT took a stab at it. Not amazing, but something to start with:
"Superstreamer is a self-hosted platform that simplifies video delivery, giving you full control over your content without third-party dependencies. Reduce costs, customize your setup, and deliver high-quality streams with ease. Drop <competitor> today and get started in minutes."
Also simple things like defining an acronym before it's used goes a long way.
Overall presentation, UX, design, code quality, and detail is a homerun IMO. Nice work, I can tell you put a heap of passion into it.
Hey, thank you! You're not the first to mention the docs. I'll have a full rewrite of the docs planned shortly where I'll address your (& others) valid points.
Full docs rewrite is nice, but for now maybe a two-minute update to the readme to clarify these points for people coming across the project would be beneficial.
I like the looks of this as a local or internet media-streaming server.
I assume you handle a few different media formats already, and can deliver or multicast something like mp4's which theoretically anybody with Windows, Apple, or Linux will be able to play on their various open-source or proprietary media players. Using no additional software on their part that they weren't already using to play their mp4's with.
Which is one of the killer features of VLC besides being an extremely versatile media player itself. VLC can be a little complex to get going however, even though there is lots of documentation it does not concentrate on streaming and there ends up being more solutions to show-stoppers on message boards than in "current" publications. Both are somewhat weighted toward deprecated versions, but OTOH it's good to have so much information building up over the decades.
What I would do is totally benchmark against VLC, focusing only on streaming, ease-of-setup use & maintenance, and especially documentation for anything that can not be made highly discoverable [0]. Make it bone simple to point & click a few times and have your chosen media playlist be instantly streaming & available from a known IP address on your local server's network, or from there over the internet, including privately through Wireguard would be good. So all you have to do is give the clients the IP address (and port if required) of the stream source, and any private credentials or keys which can easily be communicated over the phone verbally if wanted.
The clients should then be able to tune in at their leisure from any device, privately or publicly, on isolated LAN or wide open internet, with almost any firewalls in between.
I really like the idea of sensible defaults.
OTOH, it can take some doing to get VLC right, over more than one weekend :\
But once you do, here is how it works in Windows, even though VLC was primarily made for Linux, the Windows version sets a good example of an "easy" approach for beginners:
1. Take a blank SSD or equivalent, install Windows (Server or not) and join the desired network, at least a local LAN or something.
1a. installing Windows is not exactly one-click but it is basically a unit process that is going to be done anyway. You don't need to be an administrator when you are streaming, or have any further dependencies.
2. Install VLC. Just double-click on the single standalone EXE file, and it's installed. No dependencies other than one of the various basic Windows versions that millions of other people already have. Especially no need for the PC to ever connect to the internet unless you really want to.
2a. then comes the hairy part, configuring the hundreds of VLC options so the limited number of formats which support streaming can be focused on. Eventually you get configuration down to where a small script will launch a stream, in the desired format, out the desired port of your server. So eventually you can launch a stream with a single click after powering on, and if you could skip all the confusing configuration, ideally step 2 here would be only-a-couple-clicks-to-streaming-after-installation. After a one-click installation.
3. Obtain the current numerical IP address of this media server's stream, whether fixed IP or DHCP, along with any DNS equivalent whether dynamic or not. Communicate this target address, port, and any credentials to the client users, privately if desired, even over the phone verbally. After addressing the optional requirement for users when they might need a privacy approach like Wireguard to be present at the client end. Any device possessing a player having the proper codec for that stream should then have no problem playing it. In pretty much real time.
So basically, plop down the laptop that you're going to use as a streaming media server, double-click on the desired playlist (or webcam, etc) , and some kind of worthwhile popup shows the full (but simple) information needed for the clients to connect at that particular time. While the playlist is playing, or maybe have a stream menu available for user-selection Netflix-style. Publicly or privately with virtually the same workflow.
"All you need to do" is "streamline" the whole thing until it's smoother and quicker to get going compared to VLC.
I would estimate you could get it 100x easier, so if you only made it halfway look how impressive it would be :)
I think you're on the right track if you can get it to a matter of minutes, the saner the defaults the more you can just install a single standalone offline binary, then click on a playlist, whether interactive with the ultimate-media-client or not, and your streams will be available in a format that most people can play, and traverse firewalls for those who can access your current server address properly when you intend.
In only minutes after install of a single file onto any of a majority of common everyday devices, when neither the server operator nor their clients have very much tech ability. All the server needs is a valid playlist of some kind, which can be expected to be relatively non-simple to properly craft, but well-tolerated by users of corresponding super-smooth-workflow, optimized single-purpose software.
With all the other optional settings beyond default that you wish to provide, acting as icing on the top of a default cake like that.
Maybe even on Windows someday, but right now I would look forward to testing the Superstreamer on just about any major distro of Linux. When it was simple enough to be installed and launched by following a few documented proven steps that anyone booted to a laptop having your preferred version of Linux could do. In order to quickly install to the laptop and then instantly stream a playlist already residing on that laptop, or stream from its webcam, to other devices in other places the regular way. Over the internet or not.
The simplest thing in the world is local streaming from bare metal, so this should be the easiest to document by "default" or I wouldn't be so sure it wouldn't end up with more-variables-than-necessary to get very basic things going, and VLC already has that.
Right now for me there would be prohibitively more obstacles than VLC, but I admire it highly and understand it's a work in progress :)
[0] Which means accumulation of as many features as you can before considering a release or update, therefore document review and revision can be kept to a minimum too. With VLC the features definitely got ahead of the docs and they may never catch up.
This is really cool. I built a video streaming service CMS[1] earlier this year and have started building the the infra stack. Your implementation is really great!
I didn't know membrane until now. We do some things similarly (like transcode), although I'd like to provide the full chain, from source to playback with real-time video manipulation (such as ad, bumper insertion, filtering, ...) The latter is unique to do that open sourced.
With Superstreamer, I'd like to create building blocks that simplify video end-to-end. While I initially wrote it as an "all-in-one" toolkit, I'm more leaning towards an open architecture. Like, you could use Stitcher to insert HLS interstitials (like ads, or bumpers) but have your original playlists come from Mux, Cloudflare Stream, etc... The transcode and package infrastructure is there for you to use it if you'd like to stick to a fully self hostable solution.
As for player, it's a neat facade around HLS.js (kudos to the maintainers, their project is great), while initially a streaming library, the facade exposes an interface that makes sense for UI developers.
Happy to answer any questions you have.