Summer of code with Video Lan
Overview of the Code #
Updated SmartLoad extension to support VLC 4.0
Auto-run branch
Test improvements branch
Remove traces of CMD_SET_INPUT branch
Fixed Meta_Changed function from segfaulting branch
Background #
Building VLC #
The latest repo is on gitlab they have two build systems meson and gnu autotools.
I ended up choosing meson because it generates a ninja builds which is significantly faster on my system than auto tools. Ninja also produces a compile_commands.json which is need for clangd setup.
A blocking point in building vlc was finding the right the packages. Specifically qt packages which sometimes couldn't be recognized by pkg-conf. Eventually I found the packages from Ubuntu 21.10 worked, alternatively I could have built QT from source. I wasn't comfortable building QT, so I stuck with the latter.
I found the correct packages to install from the looking at the QT build decencies in vlc/modules/gui/qt/meson.build. I would also look in vlc's docker images for finding linux dependencies.
Note: to generate a compile_commands.json on autoools use bear.
And runbear -- make
modules: [
'Core', 'Gui', 'Widgets', 'Svg', 'Qml', 'QmlModels',
'QuickLayouts', 'QuickTemplates2', 'QmlWorkerScript',
'Quick', 'QuickControls2', 'ShaderTools'
],Comprehending the code base #
Some useful resources
https://wiki.videolan.org/Hacker_Guide/
https://mfkl.gumroad.com/l/libvlc-good-parts
https://www.doxygen.nl/manual/
I would recommend compiling your own documentation for source graphs. There are libvlc and libvlccore doxygen documentation online, but that didn't include any of the extensions system.
VLC Extension System #
Since my project is based around the lua extension system I will attempt to explain and show how it works in a brief paragraph.
The key part in the extension system that controls the communication between vlc and extension code is the extension manager. The extension manager holds all the extension data and contains a function, called control, which is the api that will handle commands. The function gets passed different command enums such as activate, deactivate, is_active... etc. And how the commands get handled is dependant your implementation.
The implementation from the lua module says that commands will get pushed onto queue. And on separate thread "extension thread" will execute commands and trigger a function in the lua code.
What I did #
Removing CMD_SET_INPUT #
Remove traces of CMD_SET_INPUT branch
This was a continuation of my mentors work deprecating CMD_SET_INPUT through ui commands, since it now gets binded to player's input changed event.
Adding missing Testing #
One of the goals for my project is to create tests for the extension commands. Only playing_changed had been done the rest needed to be implemented. Testing each command is just checking if the callback in the lua code got executed. The is achieved through blocking our main thread with a semaphore until the lua callback is triggered, from extension thread, signals to unblock the code.
typedef enum
{
CMD_ACTIVATE = 1,
CMD_DEACTIVATE,
CMD_TRIGGERMENU, /* Arg1 = int*, pointing to id to trigger. free */
CMD_CLICK, /* Arg1 = extension_widget_t* */
CMD_CLOSE,
CMD_SET_INPUT, /* No arg. Just signal current input changed */
CMD_UPDATE_META, /* No arg. Just signal current input item meta changed */
CMD_PLAYING_CHANGED /* Arg1 = int*, New playing status */
} command_type_e;
Auto-run feature #
Ideally extensions should be isolated in their own process and have a proper permission system which prompts the user when it uses features that are possible security risks like accessing the filesystem. Currently the new Autorun Start function is not 100% done, it loads the data and the starting of the new extension threads and enabling marked extensions is naively done through the extension manager.
Future Work
-
AutorunStart should create marked extension threads and enabled them.
-
Extension thread should also be stopped by the last module using the state shared_ptr.
Hurdles and What I learned From them #
For large code bases make sure you understand the common code and libraries. For example in vlc how is oop implement, what are interfaces and modules.
Don't focus on understanding what every line of code is doing, instead try to look at the big picture, what is this chunk of code doing?
Ask questions, so you don't waste your time getting stuck on a problem for too long.
Effective communication is incredibly important this is something I struggled with, learning how to communicate your ideas effectively and clearly is very difficult the idea in your head might be different than what someone else's. Being able to show what you mean so both parties can come to consensus is very important to a successful collaboration.
For a complex module I found sharing diagrams to express the general idea first before proceeding to code was a huge time saver, so my mentor could check the validity of the idea before I started coding.
Conclusion #
I'm grateful to be able to partake in g'soc 24 with VLC. I was in awe of the inner workings of VLC. For the future I want to contribute more performance optimizations and low level related code like a video filter or adding the caching playlist probing.
Thank you Alexandre Janniaux for your patience with me, teaching me to be better communicator, for always being there to support me and answer my questions and overall being an amazing mentor. And thank you Jean-Baptiste Kempf for making this possible.