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

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

[wastedhours]

I'd be a +1 for domain-based restriction, just as it makes implementing a leaky paywall easier (I've got a series of chocolate making videos coming up that'll be behind a simple password gate, and would make things simpler to not have to implement URL-signing).