3 ms·

> The only thing I really needed to hire was a CDN. Unless somebody was bookmarking your video directly (does that really happen, as opposed to a HTML page / a

> The only thing I really needed to hire was a CDN. Unless somebody was bookmarking your video directly (does that really happen, as opposed to a HTML page / app), this IS what the video hosts offer, just at a higher level. Vimeo isn't a social video platform the way YouTube is, it's just a video host for the most part, including whitelabeling options. What is the vendor lock-in concern? At the last educational place I worked for, we hosted our videos on YouTube, Vimeo, our own host, and a few other places. Nobody ever knew or asked which was which, except the YT and Vimeo videos were smoother experiences. They were all whitelabeled or else unlabeled. I'd argue that for most content producers and users, YouTube (for the social network and the wide compatibility across devices) and Vimeo (for the ridiculously cheap pricing and ease of use) are the best choices AS CDNs. Both offer superior developer/producer experiences than a self-hosted stack too. > had a high degree of control over my platform and could even develop some on-premises customizations that would be simply impossible had I relied on third-party, internet-only solutions. But I'd love to hear about these cases. What justifies that complexity for you?

myth2018 5y ago
I don't understand where you see complexity here. That was a fairly simple setup actually. About the use cases and motivations, some of the drivers were commercial -- e.g. clients with content they considered too sensitive to be hosted off-premises; clients distributing content to places with limited connectivity; also, integration with custom access control systems. The list goes on.
- technobabbler 5y ago
  > I could do pretty much everything I needed using ffmpeg (compiled with a customized configuration), video.js running a handful of custom plugins and some other pieces of open source software. This. That's so many points separate points of failure, and doesn't that mean you have to get a dev involved (or have an in-house automated video pipeline) anytime someone wants to post or update a video? Maybe we just have different thresholds of "complexity". I try to keep clients away from unnecessarily bespoke tools, and keep them on simple GUIs supported by proper vendors... but that's just in my sphere of work. In bigger teams it might make sense to in-house more stuff.

myth2018 5y ago

I don't understand where you see complexity here. That was a fairly simple setup actually. About the use cases and motivations, some of the drivers were commercial -- e.g. clients with content they considered too sensitive to be hosted off-premises; clients distributing content to places with limited connectivity; also, integration with custom access control systems. The list goes on.

technobabbler 5y ago
> I could do pretty much everything I needed using ffmpeg (compiled with a customized configuration), video.js running a handful of custom plugins and some other pieces of open source software. This. That's so many points separate points of failure, and doesn't that mean you have to get a dev involved (or have an in-house automated video pipeline) anytime someone wants to post or update a video? Maybe we just have different thresholds of "complexity". I try to keep clients away from unnecessarily bespoke tools, and keep them on simple GUIs supported by proper vendors... but that's just in my sphere of work. In bigger teams it might make sense to in-house more stuff.