Try it out and we'd love feedback. Free to start.
As background, here are a few blog posts about what we're doing and why.
Video is too hard - https://mux.com/blog/video-is-too-hard/
An API to Video: Why Abstraction Matters - https://mux.com/blog/an-api-to-video-why-abstraction-matters...
- Is this a crazy use of your service?
- If I request the full-size thumbnail will it be a lossless image from the original video?
- Your front-page says "With Mux Video request a single thumbnail with a simple request or an entire storyboard to use in your player to scrub preview images." but the docs don't mention anything about storyboards. Is it not done yet? Or is the implication here that I can just make several separate requests to the thumbnail API to build a storyboard scrubber?
- One of your pages says "Note that there is a default limit of 30 thumbnails per asset. If you need more, contact Mux." but the thumbnail API doc doesn't mention this limit. Is that actually a limit?
- The thumbnail API doc says the timecode param is a float. Does this mean that if I calculate the timecode based on the framerate I can get high-precision, frame-by-frame stepping in my video player? Any chance you'll offer a version of the thumbnail API that takes the frame instead to make frame-stepping easier to build?
- Can I send you a hard-drive full of videos to ingest into your system?
- Is a signed playback_policy the only way to secure the video from public viewing, and if so, when will this be implemented (doc currently says "signed: (coming soon) ...")
- Your pricing seems extremely reasonable but I'll be looking to cut corners at least initially. If I require fewer output formats (e.g. I don't need to support mobile devices, only desktop browsers), can I get a cheaper storage rate? I'll ultimately have high storage needs (starting with 31,860 minutes of video and then eventually getting closer to 100-200K) but low streaming demand.
> 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 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?
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).
We might be very interested in Mux, however, here is my question and please forgive my ignorance: isn't this pretty much what you can do with Vimeo via their api?
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.
> Video files are not available for basic or Plus users, and are not available for users beyond the one making the request. For those videos you should use the embed codes we provide in the API request (under the key response.embed.html, or through oEmbed.
We want people to build new Vimeos on top of Mux, and new interesting uses of video.
With Vimeo you would start to run into limitations when you want to build custom experiences around the video, new player features, tracking specific analytics, advertising. Really any customizing of the player outside of what Vimeo feels is important for the Vimeo platform. The Vimeo player is also very recognizable. If you're hoping to brand the player as your own, that would be difficult. We have one customer switching off of YouTube because they currently serve premium (paid for) content from a private youtube playlist, and their customers assume that because it's the YouTube player, it must be free online somewhere. I'm not sure if you'd get the same issue on Vimeo but I thought it was an interesting detail.
I ask because we're working on a solution for our users and we have 10,000 of them.
Would signed URLs work for your use-case?
Also very cheap.
Video Stored: $0.007 per minute per month
Video Streamed: $0.0013 per minute streamed
Using Akamai/other CDNs is just crazy expensive, wonder what smashcast (formerly azubu and hitbox), Mixer (microsoft), AfreecaTV, and I assume there are some large chinese streaming sites use
Is this being used right now by Vimeo and Livestream?
I kind of get the use case, I wonder what the cost is like with traditional CDNs.
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.
Vimeo (and Livestream) have their own distribution and do not use Mux.
Wistia is much better than other OVPs for startup projects but they charge 100/month if you want more than 3 videos which meant paying for while my project was still in development. Amazon like pricing would have been a major relief.
The pricing is far better as well. For HD video at 3GB per hour thats .026/GB compared to .085/GB for low volume on cloudfront, although hard to compare without knowing how much streaming will be full HD for a given video service.
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.
Right now, a developer has to know quite a bit about video/delivery to get your own stack up and running. At the highest level, we're a clean API around ingesting and serving videos to your customer. What's actually happening is we use our analytics data to power smarter decision making around what formats and renditions we deliver to your viewers.
We do just-in-time encoding, which means we can quickly change what we deliver to those same viewers as their needs change over time without needing to do massive library re-encodes. On the edge of all of that, we also make real-time, data-driven decisions around which CDNs we use around the world.
But if you don't really care about what's going on under the hood, what you'll get in practice is adaptive bitrate playback within seconds of creating a new asset in our system, and cool features around grabbing thumbnails and stuff.
Hope that helps!
Care to elaborate on how this related to Azure Media Services?
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.
If you have questions about video streaming on a specific platform feel free to reach out! (my full name at mux)
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.
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.
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:
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.
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!
You might want to take a look at the Team page before saying silly things like this.
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?)
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.
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.
We can support almost any valid h264 file :D
In an ideal world, you'd send 1080p high profile h264 encoded with a bitrate above 8Mbps (or CRF 18 for x264 nerds), with a max keyframe interval of around 5 seconds. Closed GOPs also makes processing more efficient.