Similar projects and alternatives to org.videolan.VLC
Media Player Classic
LAV Filters - Open-Source DirectShow Media Splitter and Decoders
Scout APM - Leading-edge performance monitoring starting at $39/month. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
📺 Flutter VLC powered video player.
VideoLAN is 20 years old today
news.ycombinator.com | 2021-02-01
The situation has changed a bit, though. There are practical and technological means to address most of these concerns, though it would require some work. Admittedly, I have a very Linux-focused perspective. So here we go, as the devil's advocate:
> - you need to be able to open files without user interactions (no file picker), in order to open playlist, MXF or MKV files;
> - you need raw access to /dev/* to play DVD, CD and other optical disk (and the equivalent on Windows);
> - you need ioctl on such devices, to pass the MMC for DVD/Bluray;
That's what xdg portals are for: display a native file picker, pass the file descriptor. https://docs.flatpak.org/en/latest/desktop-integration.html?...
> - you need the same if ever you have a database of files (media center oriented);
Well, portals can also punch holes selectively to select a folder, I think. Plus, the database can sit inside the sandbox.
> - you need raw access to /dev/v4l* for your webcams and be able to control them;
Pipewire should sidestep that issue, though it
> - you need access to the GPU stack, which is running in kernel-mode, btw, to output video and get hw acceleration;
> - you need access to the audio stack, also in low-level mode;
> - you need access to the DSP acceleration (not always the GPU);
> - on linux, you have access to x11 for the 3 above features, which is almost root;
Wayland is here to stay. You just need access to DRI, which is a common use-case with flatpak/DRI. Admittedly, I know nothing about DSP interfaces. Not sure why you'd need low-level access to the audio stack, and not just pipewire or pulseaudio.
> - you need access to the system settings to disable screensavers, and adjust brightness;
> - you need to expose an IPC (think MPRIS on Linux);
All of this is handled via d-bus or portals (inhibitors, MPRIS), so fine for flatpaks.
> - you need to unzip, untar, decrypt, decipher and so on;
Usually provided as part of the Flatpak runtime.
> - you need access to mounts to be able to see the insertion of DVD/Bluray/USB/SD cards and such;
Well, desktop environments usually offer to open new devices with vlc. That could be a lost feature, but I didn't even know it was there.
> - many OpenGL client libraries need access to the /etc too;
Not sure about this one. Do they? What for? Couldn't a sandboxed /etc do?
> - you need access to the network, as input and output (think remote control);
Yes, you're right, that's one extra permission. I wish it was possible to ask for it at runtime with flatpak, on first use. I don't think even Android supports asking for this at run-time.
> - you need access to /etc/ (registry) for proxy informations, fonts configuration and accessibility;
> - you need access to the fonts and the fonts configuration (see fontconfig).
Proxy information is provided via a portal that should be automatically used by Qt: https://docs.flatpak.org/en/latest/portal-api-reference.html...
Theming is handled as runtime extensions, though I admit it's often broken (OK, most theming is broken for me under sway as I didn't bother setting it up: https://docs.flatpak.org/en/latest/desktop-integration.html?...
No idea about accessibility.
It looks like some progress is being made on flathub, though it still needs filesystem access, notably for subtitle files: https://github.com/flathub/org.videolan.VLC/issues/108