
Show HN: Mux Video, a simple API to powerful video streaming - jon_dahl
https://mux.com
======
jon_dahl
Hi there - Jon from Mux here. We've been working hard on this product for the
last 6 months and are excited to open it up.

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/](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...](https://mux.com/blog/an-api-to-video-why-abstraction-matters/)

~~~
ajsharp
Yes yes a thousand times yes.

------
altano
I'm building a web app that needs video streaming but ultimately serves to
provide high-quality image extraction from the videos. I've procrastinated
solving the video delivery part and so your service intrigues me. While we
have your team on the line, I have some questions :):

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

~~~
mmcclure
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).

------
nathan_f77
This looks great! But my question is... what's the story behind the three-
letter domain name? If you bought it, was that for 6-7 figures, and what made
you decide to invest that much money in the brand?

~~~
jon_dahl
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. :)

~~~
kossae
That's certainly a very interesting way to structure a domain deal. If you
don't mind me asking, was this through a specific marketplace or via private
sale? A domain marketplace with this model could be very beneficial to
bootstrapping startups that could use the branding of an expensive domain, but
don't necessarily have all of the capital yet.

~~~
lwhite726
Hi, lauren here from Mux. It was a private deal negotiated through a broker
and escrow agent. The price only gets higher if your company is successful
(maybe why eshares just changed their name to Carta), so better to lock in a
deal early (with the bulk of payments down the road).

------
clintavo
My company is very interested in moving into this space (building a video
community and charging for paid videos not hosting & processing like Mux).

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?

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

~~~
clintavo
OK, but I looked at Vimeo's api docs and they looked pretty feature complete
for someone who wanted to build their own site and never use the vimeo CMS.
It's possible (it looks like) to add video all through the api, and simply
host the videos on Vimeo infrastructure. They even have the ability to lock
videos so that they can ONLY be streamed on certain domains (so you can
paywall videos etc). Am I mistaken about that? If not, is there an advantage
to Mux?

~~~
Heff
(Mux founder) The Vimeo API is an API to the full Vimeo platform, which is an
incredible platform all together, but requires using their player, at least
according this comment from a Vimeo employee on stack overflow.

> 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.
> [https://stackoverflow.com/questions/31384129/is-it-
> possible-...](https://stackoverflow.com/questions/31384129/is-it-possible-
> to-get-streaming-url-with-vimeo-api)

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.

~~~
clintavo
OK, that makes sense. Is it possible on your platform to make videos private?
IE, I add a video, make it private and then add something that says "this
video can only be played from subdomain.mydomain.com" (which I could then have
behind a paywall of course).

I ask because we're working on a solution for our users and we have 10,000 of
them.

~~~
jon_dahl
This is something we're working on. If you look at our API, we have a concept
called "playback_policies" that will encompass this.
[https://docs.mux.com/v1/reference#create-an-
asset](https://docs.mux.com/v1/reference#create-an-asset) At first, it's just
"public" and "private", but we'll soon have "signed" (e.g. short-term expiring
URLs), and will then build in other security options, like georestriction and
possibly domain-based restriction. We'll probably have to add full-on DRM
support as well at some point.

Would signed URLs work for your use-case?

~~~
clintavo
It's likely a no go for us without domain based restriction. I'd rather do
that then deal with signed urls, we wouldn't want them to expire. We deal with
artists who have painting instruction videos, they're going to want to have
those behind a paywall on their own domains (and then we'll offer them in our
marketplace on our domain too).

~~~
Heff
Thanks for the feedback. It's good to know this is a blocking feature for some
use cases.

~~~
clintavo
Just signed up and looked at the api docs. Even the "signed" option for
privacy says coming soon. I guess, at the moment, there is no way to secure a
video on mux?

------
fiatjaf
Seems like an amazing service and very much needed by everybody that is not
YouTube, because indeed video is too hard.

Also very cheap.

Video Stored: $0.007 per minute per month Video Streamed: $0.0013 per minute
streamed

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

------
f00_
I think the streaming business is really interesting, I assume the reason
Twitch (Amazon) is so successful is that they own their own infrastructure.
Youtube is a competitor for the same reason.

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.

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

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

~~~
Heff
(Mux founder) That's correct. Vimeo and Livestream are customers of Mux's
video performance monitoring, the product we built first and what's informing
decisions in our video API.

------
eliblock
This looks like a great alternative to Wistia for online course
sites/platforms like Teachable. I believe many developer built and focused
subscription video sites like gorails.com for example use Wistia because it
makes video easier, just like mux, even if they have no use for the marketing
focused gui tools.

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.

------
zutronics
Great to see you guys doing so well. As a BCOV'er, we really miss you guys!

------
simlevesque
Can it mix livefeeds ? The first page really does not say much and I wonder if
it's because all it does is streaming a feed, like many other players do in
this space.

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

~~~
mmcclure
(Mux founder) To be completely honest, I'd be pretty bummed if all we'd built
was a CDN (don't mean that as a diss on CDNs, we just think other folks have
solved that problem better than us).

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!

------
mt3ck
Great looking service, excited to check it out further. The company I work for
builds lots of self service video portals for clients and we use Azure Media
Services for ingestion, transcoding, storage and streaming.

Care to elaborate on how this related to Azure Media Services?

Thanks!

~~~
mmcclure
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!

~~~
mt3ck
Yes very much thanks for the breakdown and look forward to an email from me in
the future!! best!

------
wiradikusuma
I'm totally clueless about video streaming (other than being end user), but
isn't video streaming a solved problem with RTP/RTSP ages ago? With products
like Icecast, Helix, Darwin Streaming Server, etc?

~~~
therealwardo
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](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)

------
freecodyx
interesting, also looking at the team behind, the product must be good,

------
cicloid
This may be a dumb question, but would you describe the product as an
alternative to something like Wistia? How does it compare to it?

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

------
simplify
Does mux support temporary videos? e.g. a user-uploaded video that is only
available to watch for a few hours?

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

------
lyonlim
Nice! For companies streaming internal only videos, how do you satisfy their
infosec requirements?

~~~
mmcclure
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](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.

------
udia
Do you have support for 360 videos? (Streaming from a Ricoh Theta S for
instance)

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

------
tcd
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...](https://stream.mux.com/SdLAIpK2YUpIGOgVosm8Hyv6F7t01RadXYZWFuAd8YEh8m2gLrF8XZ2UzSKPWvy00iWOl00OlqxPSE/rendition.m3u8)

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.

~~~
dasil003
> _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.

~~~
tcd
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).

~~~
jon_dahl
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.)

~~~
tcd
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?)

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

------
akoumjian
What video codecs do you support as inputs?

~~~
mmcclure
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...](https://www.youtube.com/watch?v=cRSO3RtUOOk&list=PLkyaYNWEKcOfntbMd6KtHhF7qpL9hj6of&index=6)

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.

~~~
voltagex_
Which profiles / h264 settings? I know that YouTube prefers "streamable"
files, which I've never really understood.

~~~
chadnickbok
I'm Nick, a video engineer at Mux!

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.

------
stirner
FFmpegaaS?

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

