- 1 VideoLAN Movie Creator
- 2 Google Summer of Code Summer 2016
- 3 Getting started
- 4 Key ideas for VLMC
VideoLAN Movie Creator
VLMC currently awaits a transition to the current libvlc API and it's actual 1.0 release!
Google Summer of Code Summer 2016
If selected and developed, GSoC projects for VLMC will be included in the initial release!
All projects are covered by the GPL (v2+) or LGPL (v2.1+) licenses depending on the module.
Original good ideas will be valued. We don't want to impose anything. This is Free and Open Source software.
This may sound trivial, but it's harder than many expect. VLMC's compilation chain is different for every operating system. It doesn't really use the default toolchains on Windows or OS X, but a simple *nix like ./configure && make doesn't really do the trick either. We have plenty of information available on this wiki and we will happily provide help on our IRC channel.
Provide a small patch
Let's get in touch
We have 3 major communication channels: Our mailing-lists to discuss patches and further development related topics. Furthermore, we have our web forums for VLC-related end-user support - a VLMC section will be created once the product is published. Finally, there is our IRC channel #vlmc on the Freenode network. It's open to any kind of discussion. Usage issues, questions how to compile VLMC, getting to know the fellow developers, etc.
Key ideas for VLMC
Implement a real Audio/Video sync
So far, the lip-syncing strategy used by VLMC is pretty much "hope it works".
As you would think, this quite often leads to desync, and thus makes VLMC unusable.
We need to come up with a real synchronization strategy, quite likely based on an abstract clock & PTS
Proposed mentor: chouquette
Plug-in new libvlcpp & medialibrary
VLMC uses a from-sratch C++ binding to libvlc, which is stuck a few years in the past. Meanwhile, a new binding got written (https://code.videolan.org/videolan/libvlcpp/tree/master), and needs to be plugged in.
We also started working on a cross-platform media library, to replace the low-featured one, present in VLMC.
This media library will handle discovering media for the used, instead of having to manually importing every single file. This should also allow us to kill some of the "Backend" code, as a fair share of it is designed to create thumbnails. This is now done by the medialibrary, and can go away from the VLMC source code.
This probably requires a good C++ knowledge, as both libvlcpp & medialibrary make a heavy use of C++11 & templates meta-programming.
Proposed mentor: chouquette, fkuehne
Import/Save to/from cloud services
It would be a great addition to VLMC to be able to import some medias from a cloud service, and being able to export the result to another.
Since there are so many different cloud providers, we would like to have a "libcloudstorage" that would handle all the boilerplate out of VLMC's source code.
This lib can then easily be used to allow the user to use multiple service.
The cherry on the top would be to integrate this lib cloud storage into the medialibrary project, in order to automatically discover & analyze media stored on the cloud.
Proposed mentor: jb, chouquette
We would like to have a way to use VLMC from a web browser. You can easily imagine having a nice, shiny & simple UI for minimal movie edition, which would go hand in hand with the cloud storage feature.
This task aims toward the uncoupling of the rendering backend & UI, as the renderer will run server side, while the UI runs on the client side.
The idea is to be able to have a UI interacting with the renderer without having to be in the same process, or even machine.
Proposed mentor: jb, chouquette, fkuehne
VLMC is *not* tested.
Well, it is, but manually, which is not good enough. There are many race conditions, crash, deadlocks yet to be discovered.
The UI also has some fairly funky behavior when being stressed out, and that needs to be tested as well.
This task is about writing a unit test suite for both the renderers & the UI. Most likely, this will mean adding some mocking machinery, and therefor hiding all our classes behind an API.
This task is definitely a requirement before we are able to clean & modernize the code base!
Proposed mentor: chouquette