Show HN: Mux Video, a simple API to powerful video streaming

Re:Show HN: Mux Video, a simple API to powerful video streaming by tcd on Wednesday February 21, 2018 @04:31PM (#16433158)

Having had experience in streaming to many thousands of users myself I think what you're doing here is certainly interesting - having taken a look at your service it seems likely you're using nginx and possibly RTMP module? At least that's what I've used for HLS streaming in the past (which works really well). It's a shame you only support HLS - which famously chrome doesn't support on desktop, so this doesn't really solve the whole problem with multiple codecs and maximising cross-browser support, which relies on MSE at the moment to get HLS to work.

I also noticed in the m3u8 file there are multiple versions of your file depending on quality - it'd be nice to expose this via the player so I can select the quality I want to view it at - if I am bandwidth limited 480p may just be sufficient! Also with 4k and even 8k becoming ever popular, how do you plan on dealing with this?

I'm also intrigued about video storage - will you store videos forever? How will you handle storing multiple qualities? Is there server redundancy? I noticed your video is streaming via mux.com for the m3u8 and fastly CDN for the TS fragments themselves - In theory there's nothing stopping anyone using this as a rather nice transcoding service - POST a video, and download the m3u8 file to gather the .TS fragments and join them together for a nicely transcoded video, you should also allow people to download them and host it themselves, it's not like you can stop that anyway.

Will be intriguing to see how this develops, it's a nice idea, but you're soon going to figure out _why_ video is hard - making this was for sure the "easier" part, keeping it growing/sustainable is where you are going to struggle once you are dealing with multiple PB of data storage and streaming, it's the same reason Youtube isn't profitable.

Relying on a CDN like fastly is of course possibly cost efficient, but I worry if they decide to kick you off what your plan is, there's absolutely no way in hell you could _ever_ serve the video fragments yourself so whilst you're solved (possibly) one problem, you haven't really invented anything revolutionary.

I am also interested how you're going to stop people hotlinking the videos themselves - this is something I tried to prevent _really_ _really_ hard - but with m3u8 it's simply not possible (well, it is kind of if you use a query string with an expiration token, but that has its own problems).

As I said, I could just link the CDN m3u8, for example, downloading:

https://stream.mux.com/SdLAIpK2YUpIGOgVosm8Hyv6F7t01RadXYZWF...

tells me all the .ts files fastly is using - why bother with YOU and not just fastly themselves since THEY are the ones hosting your video.

[ Parent | on HN ]

Re:Show HN: Mux Video, a simple API to powerful video streaming by therealwardo on Wednesday February 21, 2018 @04:54PM (#16433322)

Matt Ward - engineer at Mux here. I'll address a few of your concerns. First off, I worked on building YouTube's video infrastructure for years and now I'm working on Mux's with people that built Zencoder. So our team has seen a few things, and rest assured my friend we know video is hard. That is actually part of why we started simple with just HLS which does get decent browser coverage and its works well on Android with ExoPlayer and iOS as well which a lot of our customers care about. What would you have started with?

Curious where you saw we were using the nginx rtmp module given that we don't have a public live streaming offering yet, but it is coming soon! Oh and yes nginx rtmp is probably the best open source offering on the market now so we will be using that. We've got plenty more coming as well so stay tuned.

If you want to select the quality you want to view at, that's a player decision. You can bring your own player to Mux. We think that's pretty neat. You can't bring your own CDN though, because we've taken that part of out of the equation for you. We've actually started integrating with multiple CDNs and have a Cedexis integration as well which helps us pick the optimal CDN for each playback. Hopefully handling all that configuration helps make things easier for developers just getting started with video and enables better smoother playbacks for everyone.

Finally, we are hiring so if you know some things about video and want to join us please reach out!

[ Parent | on HN ]

Re:Show HN: Mux Video, a simple API to powerful video streaming by dasil003 on Wednesday February 21, 2018 @04:47PM (#16433268)

> Will be intriguing to see how this develops, it's a nice idea, but you're soon going to figure out _why_ video is hard

You might want to take a look at the Team page before saying silly things like this.

[ Parent | on HN ]

Re:Show HN: Mux Video, a simple API to powerful video streaming by tcd on Wednesday February 21, 2018 @04:58PM (#16433370)

Thanks for adding nothing to the discussion - the team page tells me nothing about the challenges they're going to face, and how they're going to overcome them. Even Google, struggles, since they've been running Youtube at a loss since 2005. Streaming video is ridiculously expensive, and they are relying on CDNs, who can give them the boot at _any_ time, and I doubt they have fallbacks beyond those that have partnered with them. It'd be no different to akamai hosting the video (which I believe Apple uses IIRC, or some other big names).

[ Parent | on HN ]

Re:Show HN: Mux Video, a simple API to powerful video streaming by jon_dahl on Wednesday February 21, 2018 @05:08PM (#16433432)

I'm curious about your comments on CDNs. Have you had a CDN boot you first-hand (or seen it happen second-hand)? If so, what were the circumstances? Video delivery is a huge part of every CDN's business, and almost everyone doing video streaming relies on third-party CDNs. (Except for the biggest operations like Twitch and Google that have their own peering relationships and caching infrastructure.)

[ Parent | on HN ]

Re:Show HN: Mux Video, a simple API to powerful video streaming by tcd on Wednesday February 21, 2018 @05:47PM (#16433675)

The only one was Cloudflare on another project (file hosting) - and being fair, we did do 20tb of transfer in a single month on the free tier, which they weren't so pleased about :P. that really crippled the website and we struggled to run the service after that point (oddly enough, going from their CDN and network to our own which could barely squeeze past 1gbps wasn't ideal).

It's more the longer term potential - businesses change, or see valuable partners and may decide to react accordingly, I guess having many CDNs is the best approach and swapping them out on the fly.

I do have other concerns, mainly about the pricing and how you plan to deal with things like hotlinking, taking a .m3u8 is super easy to abuse. You charge $780 for 416 days worth of streaming or in easier terms $1/12 hours of streaming so I wonder whether you will let people impose limits or what happens once those limits are reached.

I could easily take someone elses m3u8 and let them run up the charges on your service whilst I get the wonderful video hosting for myself.

I especially liked this part:

"Please do not upload video, download the playable assets, and then delete video."

You might as well offer that as a service since there's not really much you can do to prevent people using you as a transcode service directly (well, you can, but do you want to?)

[ Parent | on HN ]

Re:Show HN: Mux Video, a simple API to powerful video streaming by Heff on Wednesday February 21, 2018 @11:28PM (#16435147)

Good questions. To address hotlinking we'll be encouraging people to use signed URLs. They're a little more complicated to work with but can protect from situations like you're describing. We also have a mechanism called Playback IDs, which allows you to kill a URL to a video (and create a new one) without deleting the video itself. Account limits are less ideal, but may need to be a reality. Mux is a utility service similar to AWS and Google Cloud, where you'll also have this issue, and we'll work with users to find the best approach.

Re: transcoding, this is something we've wrestled with a bit. If you only use us for transcoding then you lose half the value of the system we've built: the dynamic renditions based on real usage, real time CDN optimization, automatic new codec and device support at no extra cost. So we've tried to create the simplest pricing for people who want all of that, not just transcoding. At the same time, we do want to support real video publishing use cases that start to look more like just transcoding (videos with a short life span and few views). Hopefully we can find more real cases like that to help us think through that more.

[ Parent | on HN ]