I contribute to OSS very often, mostly sponsored by the company I work for (we're in video streaming, and we're too small to build everything from scratch). Outside of company hours, I work on my personal streaming project [1], and I've had a couple of people find the "Buy me a coffee" button and GitHub sponsors page. While it is not a sustainable amount of sponsorship, the joy of seeing people support with a few bucks feels incredible. It's a passion project after all.
I used to maintain a private fork of an OSS project as I assumed my company wouldn't want specific features out there (especially since they gave a competitive advantage). I eventually met up with the maintainers of that project with a situation I couldn't figure out and they were so eager to help. After, I went to legal and told them it didn't feel fair to have OSS maintainers help out but keep it private, and to my surprise, they agreed. All I had to do was ask, and not assume.
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.
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.
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.
As a parent of an almost 2 year old (tomorrow!), I feel a bit worried of what is yet to come. I notice kids around me (family, kids of friends) ranging 3 to 10+ mostly consume YouTube, TikTok, ... on a daily basis and when they do, they're totally isolated from what happens around them. They get feeded ad after ad, watching teenagers doing odd dances, minecraft video's, ... Rarely something of pedagogical value. Hope I can do better, time will tell. Tips are welcome though.
While I agree HN shouldn't be used as a way to get direct customer support, I don't think it's fair to grab and point our pitchforks to @jgrahamc over a one sided story. There's not nearly enough information from both sides to create fair judgement (these things happen, unfortunately, at larger scale with automated processes). What matters is the afterthought and actions taken of what's going to prevent a similar situation in the future (which I'd love to read from both OP and @jgrahamc if possible). HN is my go to stop for well formulated opinions written by people way smarter than me and I think we dropped the ball here, HN can do better. That said, happy that your issue got resolved OP and goodluck with your project!
How would one ship a full engine with an app on an OTT device? I've built a few TV apps but they all relied on the browser engines shipped with webOS and Tizen.
The person I was chatting with triggered the password reset mail, and stripped my security questions. As said, I was in exactly the same situation and probably entered random answers to their security questions years ago. When I went through the password reset they set up, I no longer had to enter those security questions. Point is, they're able to remove the additional step of providing answers to the security questions by their customer chat service. Give it some more tries until someone's on the other side willing to do so.
That's a very primitive approach. Once you're dealing with adaptive formats (DASH, HLS) containing multiple renditions (different bitrates) and/or codecs, it gets more complicated. I get that a single h264 codec/mp4 (webm) container file is easy enough as it is widely supported but once you're dealing with larger video's and getting them served over different connection types/speeds, it gets trickier. Atleast with services like Vimeo/YouTube, you don't have to bother too much.
I didn't verify this but my guess is that with the lack of the MSE API on Safari iOS, YT has no other option but to serve the HLS manifest directly to the video element thus it's a whole lot easier to grab the HLS URL (after YT's player JS generated the signature). Would be a bit more tricky to do this on Chrome (or Firefox) where the video buffer is built in code (MSE).
On second thought, muxing mpeg2ts to mp4 containers would make it possible to play the same HLS stream on Chrome.
I used to maintain a private fork of an OSS project as I assumed my company wouldn't want specific features out there (especially since they gave a competitive advantage). I eventually met up with the maintainers of that project with a situation I couldn't figure out and they were so eager to help. After, I went to legal and told them it didn't feel fair to have OSS maintainers help out but keep it private, and to my surprise, they agreed. All I had to do was ask, and not assume.
[1] https://superstreamer.xyz/