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

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

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