Classic confinement request for simple-video-converter

name: simple-video-converter description: A lightweight PySide6 GUI frontend for FFmpeg, designed for batch video conversion and analysis. It focuses on accessibility and performance, offering automated hardware detection (NVENC, VA-API) and “Smart Pairing” of FFmpeg/FFprobe binaries.

snapcraft: Simple-Video-Converter/snapcraft.yaml at main · STENS66/Simple-Video-Converter · GitHub upstream: github.com/STENS66/Simple-Video-Converter (Public showcase/Readme only) upstream-relation: Developer / Owner supported-category: Video Processing

reasoning:

  1. Licensing & Codec Support (Internal LGPL vs Host GPL) The snap includes a bundled, LGPL-compliant version of FFmpeg to ensure basic functionality out of the box. However, strictly adhering to LGPL means this bundled version lacks restricted codecs like H.264 (libx264) and HEVC (libx265). To enable full functionality, the application explicitly allows the user to switch to their host system’s FFmpeg binary (typically /usr/bin/ffmpeg). Classic confinement is mandatory to allow the execution of this external binary, giving the user access to their own GPL-licensed codecs which cannot be legally bundled inside this proprietary snap.

  2. Hardware Acceleration & Driver Access (Critical) The application features a HardwareDetector that validates NVENC (Nvidia) and VA-API (Intel/AMD) capabilities via the host’s FFmpeg. For this to work, the underlying process must have unfettered access to the host system’s graphics stack, including:

  • Proprietary drivers and ICD loaders (often in /usr/lib/).
  • Hardware device nodes (/dev/dri/renderD128 for VA-API, /dev/nvidia* for NVENC).
  • Kernel-matched libraries (e.g., libcuda.so, libva.so). Using Classic confinement allows the application to leverage the host’s correctly configured drivers, ensuring reliable hardware acceleration without bloating the snap with redundant or incompatible driver stacks.
  1. Arbitrary File Access As a general-purpose utility, users expect to convert files residing on various storage media, including secondary internal drives (often mounted in /mnt or custom paths), network shares, and temporary directories. The strictly confined interfaces (home, removable-media) are insufficient for these diverse workflows.

I understand that strict confinement is generally preferred over classic. I’ve tried the existing interfaces to make the snap to work under strict confinement.

This request has been added to the queue for review by the @reviewers team.

Not a reviewer, however I can’t help leaving the following feedback regarding this application:

Video processing is NOT a supported category of Process for reviewing classic confinement snaps .

There’s no reason why the GPL-licensed FFmpeg can’t be bundled into the snap as long as you don’t dynamically or statically link to the libraries AND also making the source code of the bundled FFmpeg available, see FFmpeg License and Legal Considerations.

There are also Content snap for ffmpeg available for usage which reduces the licensing requirement as you don’t distribute them as a whole.

FFmpeg. For this to work, the underlying process must have unfettered access to the host system’s graphics stack

These are already mostly allowed via the https://snapcraft.io/docs/opengl-interface and the https://canonical.com/mir/docs/the-gpu-2404-snap-interface .

Arbitrary File Access

Arbitrary file access is not a supported category of the application of classic confinement, see Process for reviewing classic confinement snaps .

Thanks for the feedback. I am switching to strict confinement with a bundled FFmpeg. I will close this request.

1 Like

Hi Lin-Buo-Ren,

Just a quick update to let you know that I followed your advice.

I successfully built the snap using Strict Confinement (and Core 24) with a bundled FFmpeg. It works great and is now published in the stable channel.

Thank you for pointing me in the right direction. Since I no longer need classic confinement, this request can be considered closed.

2 Likes