You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I started this project, I chose GStreamer because of its excellent integration with GNOME. This was especially important before version 3.0.0, when the extension rendered video by copying frames from a GStreamer appsink directly onto the lock screen.
Starting with 3.0.0, the rendering pipeline was redesigned entirely. Instead of copying frames, the extension now creates native player windows and places them on the lock screen. To support this, the GStreamer pipeline was refactored to use gtk4paintablesink, allowing a single video pipeline to be shared across multiple windows.
This approach has worked very well. It provides fine-grained control over video and GIF playback while keeping resource usage low. However, that same low-level control also means the extension is responsible for handling many implementation details that are outside its core purpose.
That causes issues such as:
Audio crackling when changing the volume or playback position.
Inconsistent GIF support on older GStreamer versions.
Recent issues involving NVIDIA drivers (although it is still unclear how the extension triggers the observed kernel OOM events).
While not all of these problems necessarily originate from GStreamer itself, they are all tightly coupled to the current implementation. Using a higher-level playback backend could abstract away much of this complexity, reduce maintenance burden, and allow development to focus more on extension features rather than multimedia pipeline internals.
Why MPV?
MPV was the obvious candidate.
It is a mature, lightweight media player with excellent format support, high performance, and low resource usage. More importantly, it exposes a rich control interface through its IPC (Unix socket) API, providing everything the extension needs without requiring manual pipeline management.
The main limitation compared to the current GStreamer implementation is that MPV cannot share a single playback pipeline across multiple windows.
My current idea is to create a single MPV window matching the video's native resolution and then replicate it across monitors using Clutter.Clone, applying the appropriate scaling and transformations for each display.
I don't yet know how robust this approach will be in practice, but initial experiments look promising. If it proves reliable, it could become an overall improvement over the current implementation.
Planned approach
The implementation will live in a separate branch named experimental-mpv.
Once the backend is feature-complete and sufficiently tested, it will be merged into the main extension as an optional playback backend. Users will be able to choose between the existing GStreamer backend and the new MPV backend.
Initially, GStreamer will remain the default option while the MPV implementation matures. If, over time, MPV proves to be more stable, easier to maintain, and functionally complete, I may eventually retire the GStreamer backend altogether.
Motivation
When I started this project, I chose GStreamer because of its excellent integration with GNOME. This was especially important before version 3.0.0, when the extension rendered video by copying frames from a GStreamer
appsinkdirectly onto the lock screen.Starting with 3.0.0, the rendering pipeline was redesigned entirely. Instead of copying frames, the extension now creates native player windows and places them on the lock screen. To support this, the GStreamer pipeline was refactored to use
gtk4paintablesink, allowing a single video pipeline to be shared across multiple windows.This approach has worked very well. It provides fine-grained control over video and GIF playback while keeping resource usage low. However, that same low-level control also means the extension is responsible for handling many implementation details that are outside its core purpose.
That causes issues such as:
While not all of these problems necessarily originate from GStreamer itself, they are all tightly coupled to the current implementation. Using a higher-level playback backend could abstract away much of this complexity, reduce maintenance burden, and allow development to focus more on extension features rather than multimedia pipeline internals.
Why MPV?
MPV was the obvious candidate.
It is a mature, lightweight media player with excellent format support, high performance, and low resource usage. More importantly, it exposes a rich control interface through its IPC (Unix socket) API, providing everything the extension needs without requiring manual pipeline management.
The main limitation compared to the current GStreamer implementation is that MPV cannot share a single playback pipeline across multiple windows.
My current idea is to create a single MPV window matching the video's native resolution and then replicate it across monitors using
Clutter.Clone, applying the appropriate scaling and transformations for each display.I don't yet know how robust this approach will be in practice, but initial experiments look promising. If it proves reliable, it could become an overall improvement over the current implementation.
Planned approach
The implementation will live in a separate branch named
experimental-mpv.Once the backend is feature-complete and sufficiently tested, it will be merged into the main extension as an optional playback backend. Users will be able to choose between the existing GStreamer backend and the new MPV backend.
Initially, GStreamer will remain the default option while the MPV implementation matures. If, over time, MPV proves to be more stable, easier to maintain, and functionally complete, I may eventually retire the GStreamer backend altogether.