By flathub


Basic org.videolan.VLC repo stats
15 days ago

org.videolan.VLC Alternatives

Similar projects and alternatives to org.videolan.VLC

  • GitHub repo mpc-hc

    Media Player Classic

  • GitHub repo LAVFilters

    LAV Filters - Open-Source DirectShow Media Splitter and Decoders

  • GitHub repo flutter_vlc_player

    📺 Flutter VLC powered video player.

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better org.videolan.VLC alternative or higher similarity.


Posts where org.videolan.VLC has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-02-01.
  • VideoLAN is 20 years old today | 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.

    > - 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:

    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:

    No idea about accessibility.


    It looks like some progress is being made on flathub, though it still needs filesystem access, notably for subtitle files: