The state of Vidify in 2021
I wanted to give some closure regarding Vidify to its followers, I’m very grateful for the support I’ve received. I haven’t been working on this lately; I’ve been with other projects and more stuff outside of programming so I had put Vidify aside for some time. I wanted to explain why in this article.
The Issues
I have some very big issues that I have to deal with before continuing, which have prevented me from working on Vidify further until now:
Copyright
I’m not sure how to handle legal issues regarding video playback from YouTube. This is very complicated to me because I don’t know anything about the topic and I would have to hire a consultant – for which I don’t really have the money right now.
As far as I know the possible copyright infringement issues aren’t a deal breaker for Vidify. This is how I currently think it’ll go (before consulting anyone):
Vidify has to own the videos it displays, and it needs to save them outside of YouTube. This is what makes the most sense to me, since we’re not only using copyrighted material, but also infringing YouTube’s Terms of Service when we download their videos, meaning that they could block us in any moment.
There’s a catch, though! There doesn’t seem to be a problem with playing YouTube videos if we use their official player API. This is currently what Vidify uses for the mobile app and what was being worked on by @pawKer at #118.
The problem would be simplified if we limited Vidify to the official YouTube API then, as we wouldn’t be infringing their ToS. But someone would still have to pay to the owners of the videos we display. For this, what I’m not sure about is if it’s Vidify the one that would have to pay for all of their users, or if the payment would have to come from each individual user on their own. There are platforms like JunkinMedia that help with this, which could establish a monthly/yearly fee only for access to the copyrighted content.
My current plan is to continue developing Vidify until it’s more popular, at which point there’ll be a bigger risk of getting a complaint, but I’ll probably have more resources to handle this issue.
Audio Synchronization
I personally don’t think Vidify will be a good enough program until a decent audio synchronization system is implemented. By good enough I mean that someone would pay for it; as I’ve commented earlier it’s very likely I’ll have to implement a subscription model for Vidify due to copyright issues. And my first attempt was fun, but not really viable.
This is also extremely complicated to me because I’m still a student and I haven’t been taught much about the topic yet. I have to dedicate a lot of time to investigate about how this could possibly be done, and even more implementing it. Fortunately, I will be taking Audio Engineering courses during my next semester, which should help me get a better understanding about it.
Rust Integration
After thinking it through I don’t think Rust integration in #108 is worth it either. If anything I’ll just make some Python bindings for the audiosync feature, but including Rust in the core of Vidify just a maintenance burden that isn’t really that much of an improvement. It did help me sharpen my Rust skills, but it wasn’t helping the Vidify project altogether, and I’ve learned the lesson.
Said PR still has a lot of interesting things I want to keep, though:
- An improved CI
- An improved build system, including WIP Windows Store support
- Removing VLC support
- Removing the QtWebEngine in place for a web server
I’ll be moving structconf to my own profile, as it won’t be used by Vidify anymore.
Youtube-dl Breakage
Vidify needs to update automatically in order to avoid issues with youtube-dl.
It gets outdated very quickly, which means the videos stop working if you don’t
update youtube-dl. This is a big problem when Vidify is built statically
because updating it isn’t easy.
The best solution to this in my opinion is to upload Vidify to the main repositories in all Operating Systems, so that this is handled by them. I don’t really want to add an auto-updater feature to Vidify; I dislike it when that happens with Steam/Discord/etc instead of via the official repositories, and I consider it unnecessary when I can use:
- Windows: the Windows Store, building statically.
- Linux: Snap/Flatpak for distros with slow updates (Ubuntu/Debian), and the official repos for the rest of them (Arch, Gentoo, …). The builds can be dynamic in this case.
- MacOS: the App Store can be used for that, building statically. Although developing stuff for Apple sucks if you don’t want to buy one of their products for the low cost of $1K.
Then, I could just have a Continuous Deployment flow that uploads an update each
week for the statically built packages (Windows and MacOS). Vidify could try to
“ping” youtube-dl when launched, and if that fails, it can just ask the user
to update it. This shouldn’t really be a problem because the repositories I
mentioned earlier update automatically.
The Plan
Since the audio synchronization feature is a blocker until I can fully release Vidify and it’s not coming soon, I will be working on its core in the meanwhile:
- Clean up the Rust Integration PR
- Polish the Web Server Player PR and merge it
- Work on the new deployment method
After that’s done I’ll probably have a better grasp at audio engineering, and will be able to work on the audiosync feature I have always wanted.
What do you think? Any thoughts/opinions? You can discuss with us at the Vidify Discord.