search

quelea-projection / Quelea

Open source projection software for churches.
https://quelea.org
GNU General Public License v3.0
154 stars 145 forks source link

2024.0 CI - Live video stuttering with visible Videos tab, relative high GPU load #628

Closed DeeTigIT closed 6 months ago

DeeTigIT commented 6 months ago

When I go live with a video, with a visible Videos tab, there is visible stutter on the projection screen. This stuttering disappears when I switch from the Videos tab to the Songs tab. But appears again when switching back to Videos tab. Also, notice the higher GPU load (compared to 2022.0)

After the inital Videos tab build-up: is Gstreamer is somehow still working on the (thumbnail) videos when the Videos tab is active?

I have a dedicated AMD Radeon RX 5600 XT. With a less equipped GPU the experienced the load might be even higher. This could impact the systemrequirements for running Quelea. Can Gstreamer be tuned for this? Note: even with the Songs tab visible the load stays this high.

Recordings 2022.0 (with VLC) and 2024.0 CI (with Gstreamer) : https://mega.nz/file/S74WGbCZ (key will be sent using discourse)

Testset: 46 videos (1920 x 1080 50 fps) in .quelea\vid with total disk space 5.8 GB

berry120 commented 6 months ago

@DeeTigIT Could you give it a try now?

DeeTigIT commented 6 months ago

Switching between Videos tab and Songs tab:

Next test I did:

Perhaps a cache setting in Gstreamer can be applied or increased?

berry120 commented 6 months ago

@DeeTigIT Hopefully the latest change has also solved the issue with 4k.

Just for interest's sake (and also to note it here for reference) the issue isn't actually on the GStreamer side at all, but to do with how we're getting the frame buffer data from GStreamer, storing that to memory, and painting it on the screen.

The first fix applied dealt with the preview images in the video tab directly - they were still being stored at full size in memory, despite being only shown as thumbnails. Those are now being scaled down so they take up much less space.

The second (latest) fix is a more fundamental change to how the image on the video itself (as it's playing) is actually rendered to the various canvases in place - it's a different mechanism under the hood that adjusts the pixels directly rather than creating and rendering a fresh image each time, then disposing of the old one. The new approach is much faster, and more memory efficient.

The stuttering you were noticing is actually GC (garbage collector) pauses - the entire application was being frozen as the garbage collector had to kick in and free all the unused memory that was being accumulated very quickly, so we didn't run out! It's normal for this to happen once in a while when memory intensive operations are going on - but certainly not that often, and it shouldn't be normal for a video to be a memory intensive operation either.

Hope that fixes things, let me know how you get on!

DeeTigIT commented 6 months ago

This second fix is a big improvement. The regular freezing is gone, now. Also thanks for the details behind this change. The issue can be closed.

berry120 commented 6 months ago

@DeeTigIT Awesome, thanks very much for confirming!