Thanks for the reminder. The homepage is a GitHub page and does not support git lfs, so I have compressed the files as much as possible to reduce their size. We consider re-encode the mp4 files to x264, and provide a packed zip of the homepage.
It's a bit of a mess. The implementation of a codec, that is, and encoder or a decoder can be open source, despite the format itself not being open. H265 does have open implementation, but the format itself is not open. The opposite can be true as well, there are proprietary encoders to open formats for example. Actual list of open video formats: https://en.wikipedia.org/wiki/List_of_open_file_formats#Vide...
What OP meant is that they would like an open format on the website, which, then, can be viewed in any modern browser. I think that caniuse is a good resource in this regard.
This is exactly why I am not convinced that VVC is going to be useful; seems to have little advantage over AV1, as well as being late to the party in the first place.
Well yeah, they wanna rent, so they have to develop these things. It also depends on what business deals they make in the background. If the format is secured in some applications, that might cement it as a quasi-standard, which then they can leverage for further popularity.
I hope open standards keep winning. Overall, everyone wins with the infrastructure being openly accessible, especially the common folk.
Both manual-downloading models from our github repo and auto-downloading models with our python-library follow the above license policy(which is for non-commercial research purposes only).
Understood.
The core dependency of InsightFace in LivePortrait is the face detection algo. The face detection is easily to be replaced with self-developed or MIT-licensed model.
Thanks for your advice. I have no experience on a cooperative project before, so my committed messages are kind of meaningless.
I think you are right. I will read the committing guidance and take care of them later. Thanks for your critical voice again.
Having flexibility for “pointless” commit messages is really important for research-y projects. Sadly, the practice often clashes with readers who have never really done research before.
A nice compromise is to use Github PRs plus squash-merge commits (search for “Github squash merge button”). For example, you might start a project, commit a bunch of “garbage” commit messages, and then decide the project is ready for initial release. Then take your branch, create a PR, and squash-merge it to your master branch with a nice commit message.
Need to update your paper on arxiv? Create a branch, commit willy-nilly, the squash-merge the result with a nice message (that perhaps references the updated arxiv version).
If for some reason your project grows like Caffe did years ago, then it can be time for smaller PRs and more organized commit messages.
Thanks for your interest and try. The theory computation complexity is described in the paper, it is rather small. However, whether achieving real-time really depends on your hardware, your need and the code optimization.
thanks for your interest, releasing the training code should be granted by my lab leader. I am trying to apply for it. If you have any question, welcome to raise an issue or email me :)