matvp

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.

[1] https://superstreamer.xyz/

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.

Happy to answer any questions you have.

I'm building a video API suite [0] in my free time, from transcode to package to player. The full shebang!

[0]: https://github.com/matvp91/mixwave

There isn't much info out there yet, but this video is a small preview: https://youtu.be/lGEMwh32soc

The latest update is mentioned in the March 2023 blog post: https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...

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!

Side note, synthetic events are no longer pooled since React 17. There's no longer a noticable performance gain with more modern browsers nowadays.

Happy newyear from Belgium!

Providing adaptive video (MPEG-DASH / HLS on any non Safari browser) still requires JS though.

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.

They were valid years ago when I was a kid but god knows what my favorite food was 10 years ago.

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.

Give their chat another try. I went through the same a while back and they reset my password.

Wanted to read through the docs but I'm getting a 404 from the page link at the top.

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.

Not so sure that'll work due to the fact that the first segment in a subset of segments is not the init segment (thus missing atoms like moov, ...)

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've actually found myself coding in the evening again due to quarantine. Contributing to OSS, releasing stuff on GitHub, ...

These two comments are fixed and will be available in a new version in a few minutes!

I've added different volume icons based on the current volume, shall hit production anytime!

WebVTT, yes. https://matvp91.github.io/indigo-player/#/Configuration?id=c...

Thanks for the feedback, this small feature was already part of my roadmap. :) Will hit production soon!

I can't speak for plyr as I am not familiar with their project. What I like about indigo is the way modules are structured, the initial file (indigo-player.js) loads the needed code in order to provide playback, it's basically a mono repo. I've spent a fair amount of time on state management too, meaning you have a well defined & standardized API no matter whether you play DASH/HLS or use FreeWheel / Google IMA ads.

Edit: the state interface can be found here: https://github.com/matvp91/indigo-player/blob/master/src/ext...

Do you mean something like: "force the player in landscape mode when you hit the fullscreen button on a mobile device?". I like it, YouTube does that with it's mobile apps and I find it practical.

You're more than welcome to contribute! Good ol' days!

Thanks for the suggestions!

1. Absolutely, it's on my radar.

2 & 3. According to me, the volume button seems off in mobile. I think I'll remove it completely on mobile devices, people are used to lowering the volume with the physical buttons (assumption). What do you think?

Noticed it too, I have no idea yet. I use a wrapper around the native Fullscreen API's (https://github.com/sindresorhus/screenfull.js/) and it doesn't do anything fancy. Interesting, I'll have a look at it but I'll put it lower on my prio list if you don't mind.

I'm sorry, it was wrong on the Github page, fixed.