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

Yes yes a thousand times yes.

Really excited about what you're building! Can't wait to try out your API.

Ok going to try and answer these in order:

> Is this a crazy use of your service?

Nope, not a crazy use of the service at all! To be blunt, it might not be the most profitable for us, but we tried to structure our pricing that we could support edge cases.

> If I request the full-size thumbnail will it be a lossless image from the original video?

If you give us an h.264 input that is 1080p or less and request a png thumbnail without specifying width and height, the thumbnail will be lossless (no _additional_ loss over the png compression, to be precise for the pedants out there).

> Storyboards

Storyboards are working and in the final stages of development. We should have that documentation updated in the next few days.

> 30 thumbnail limit

That's a soft limit. We can do more than that, but we should talk if you're going to be blowing through that limit consistently.

> The thumbnail API doc says the timecode param is a float.

Yes, if you have constant framerate video. It's technically a 64bit floating point, so it's highly accurate. Due to the complexities around variable frame rates, we don't support frame-stepping in our API.

> Can I send you a hard-drive full of videos to ingest into your system?

One of our engineers volunteered to take care of it, so sure, we can make that work as a one-off. Probably not going to put that on the marketing site anytime soon and deny this conversation ever happened in a year :)

> signed playback_policy

That will be available very soon, followed shortly by other types of restrictions (geo, domain-based, etc). Anything specific you'd like to see there?

> pricing

We're happy to talk! We actually only store the mezzanine long-term and then encode into the different bitrates at request, so that's not the only consideration for storage. Feel free to shoot me an email (matt at our domain).

Great question. Yes, it was quite expensive. We were able to negotiate a deal where we buy the domain over a long period of time, with a relatively low cost for the first few years, a much higher cost for the last few years, and the option to cancel. If we grow/sell/IPO, no big deal. If we die, we can stop paying. We just have to do it within 5 years or so. :)

Hey clintavo - your use-case is exactly what we built Mux Video for.

One way to think about it: Mux is more like a EC2/S3-level service, while Vimeo is more like a Squarespace-level service.

We think Vimeo is a great platform for publishing video if you want a platform that goes all the way from CMS to streaming to player to sharing. But if you want to build video into your own application, you might want something a bit lower-level, closer to a web service, that lets you bring your own CMS, player, workflow, etc. Our primitive is just `video` and you can do whatever you want with it.

Thanks flatjaf! Try it out and let us know if you have any feedback.

>Is this being used right now by Vimeo and Livestream?

Vimeo (and Livestream) have their own distribution and do not use Mux.

This is a really good point. Particularly for Twitch, owning their own CDN has turned out to be a massive comparative advantage. From everything I've heard, they've also done an incredible job with relationships and peering agreements over the years to bring costs even lower, and I'm sure that's only gotten better with the weight of Amazon behind them.

That being said, with solid relationships and a little scale behind you, the rate card starts dropping pretty quick. We ultimately use traditional CDNs for delivery, we just switch between those CDNs based on which one is going to provide the best experience for a given viewer. It makes a lot of sense for some teams to build out their own hardware/data centers/POPs at a certain scale, but I think we can all agree that's a decision that shouldn't be taken lightly.

Yes, we've got live on the way! It will be available on a limited basis to folks in the next few weeks, and hopefully public shortly after.

> The first page really does not say much

Indeed. It tries very hard to get me to sign up (four "Create Account" buttons; three red, one blue) but I still have no idea what I'd be signing up for.

It's a CDN for video files? Someone help me out here.

Thank you! Sounds like a great fit, ping me if you have any questions down the road (my email is just matt at our domain).

Azure Media Services (and other, similar products such as Amazon's media offerings, etc) is a suite of products that ultimately take you from ingesting a video to playing it back, but you're going to do a lot of gluing together parts to get there. While gluing those parts together you're making a lot of decisions around formats, encoding, etc, and let's be honest...those probably won't get revisited soon enough. Our system makes those decisions on the fly based on actual performance data for your viewers.

When you ingest an asset into Mux, we give you a playback ID that's playable in seconds (which, at least imo, is very cool on its own), and you can just use that in your players and go back to making amazing video portals. You can also use that same ID to do things like request smart thumbnails immediately (had to plug that because I spent _way_ too much time on that part of the marketing website).

We do some really cool things behind the scenes around how we encode the assets just-in-time, CDN switching, etc, but ultimately the goal is that you can just wire our API into your CMS and think less about encoding minutia.

Hope that helps!

Matt Ward - engineer at Mux here. The simplest answer here is that most browsers and native platforms don't easily support RTP/RTSP these days. It isn't technically impossible to stream RTSP to say an iPhone, but it I'd say it is non-trivial compared to simply using AVPlayer with HLS. Our goal with this product is to make video easier for developers to understand and use so that they can focus on the other parts of their apps. We are running those rather complex streaming servers and we even provide some guides for how to get started streaming video to common platforms - https://docs.mux.com/docs/playback

If you have questions about video streaming on a specific platform feel free to reach out! (my full name at mux)

Not a dumb question. We're lower-level - the biggest value Wistia brings is helping marketers be more effective with video. Mux Video is like the plumbing; we get the video from ingest to device/player efficiently with high quality, but we don't actually offer a video player, engagement tracking, content management, metadata, CRM integrations, etc.

We think of ourselves as more of an alternative to S3 + EC2 (or Elastic Transcoder) + CloudFront + weeks of engineering time.

Use Mux Video if you're a developer who wants to build software around video streaming. Use Wistia if you're a business who wants to use video to communicate.

Yes, but with a sightly different pricing structure. Send us an email - I'd be interested in hearing more about your use case.

Thanks! One of my co-founders mentioned this in another thread, but you can set up specific playback_policies when you create an asset (https://docs.mux.com/v1/reference#create-an-asset). For internal-only videos with strict infosec requirements, they'd probably want to use signed URLs, but we're also working on things like geo and domain-based restrictions.

Not at this point, but it's something our team has some experience with, so don't be surprised if we add it in the future.

If you're doing 360 streaming right now, shoot me an email (jon at mux) - I'd be curious what you use today and/or how you want to use it.

> 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.

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!

The goal is to support just about anything you can throw at us, but the reality is that's going to take months of debugging whatever insanity the internet can throw at us. Derek from the Vimeo/VideoLAN team gave a really great talk on just how awful the world of user uploads can be at Demuxed 2017: https://www.youtube.com/watch?v=cRSO3RtUOOk&list=PLkyaYNWEKc...

That being said, we should handle most modern codecs you can throw our way. PDFs are going to fail (you'd be shocked at how often I've seen this). If you can, use h264 video and AAC audio as that's what our system is optimized for and will you give you the best performance.

That was Zencoder (YC W10). We did that already. :)