On 27.10.2026 06:40, Sam via Cin wrote:

...... snip

3. Fixes from your reports

Terje (GNOME, native Wayland):

The interface was too small on a 27-inch WQHD screen. Settings, Preferences, Appearance has a new row Interface Scale, one value for X11 and one for Wayland. Terje, set Interface Scale (Wayland) to 1.40, that is what QT_SCALE_FACTOR=1.4 did for you. It applies after a restart, which Cinelerra offers.

The X in the title bar of a floating window (Compositor and the other docks) closes it again.

A docked window dragged by its title bar comes loose on Wayland. This is tested on KDE only. Terje, could you try it on GNOME?

Window, Show Compositor and the other Show entries carry a check mark while the window is shown

Yes, the Compositor window get a checkmark and can be dragged. (If the pointer is close the top frame, it a chance to vertical extension instead). The Compositor however is always put active (blue frame) on top over the main window, and cannot be switched opposite (it can be hidden by the Window list task bar at the bottom screen. If I dragged the main window it was hidden below the Compositor window.

4. Two new settings for everyone

Display platform: Settings, Preferences, Appearance has a row Display platform with Automatic, X11 and Wayland. Automatic is the default and behaves as before (X11 when there is an X11 display, also XWayland). It applies after a restart. CIN_QPA_PLATFORM still wins when you set it.

The default
./CinGG-qt6-alpha-20261027-x86_64.AppImage first time started in XWayland (X11) display server mode

Went to Setting | Appearance
Set Display server to Wayland. Was a bit confused by "X11" in the Interface Scale (X11), but I set it to 1.4
Restarted with Cin in Wayland but the scale factor (Wayland) was still the default 0.5. Changed it to 1.4 and Cin restarted with the corrected scale factor. Seemingly Cin has to be displayed in Wayland before the scale factor can be set.

Andrew, thank you for all the work you put into ffmpeg in Cinelerra over the years. You wrote that you hope AI assistants can help here. I would like to try exactly that. The part that burned you out, chasing every API change of ffmpeg, is the part an AI does tirelessly. What it cannot do is know where Cinelerra's ffmpeg code hides its traps, and that knowledge is yours. So if you ever feel like it, no pressure and no deadline: a look at a patch, or a one-line hint like the MLT patch you pointed us to, already helps a lot. Phyllis, I would like to help with VAAPI and ffmpeg 9. One thing I noticed: the MLT patch fixes a hwupload/buffersink filter graph, and Cinelerra does not use that graph for encoding. It sets up the hardware frames itself (ffmpeg.C, av_hwframe_ctx_alloc and av_hwframe_transfer_data), so the fix will probably look different.

The catch: I have no hardware for VAAPI encoding, only an NVIDIA card, so I cannot test it myself. Terje, your Arc A750 encodes h264_vaapi and hevc_vaapi with ffmpeg 9.0.2. Your test shows that the driver and ffmpeg 9 work on your system. It goes through the hwupload filter, though, and Cinelerra takes another way to the GPU, so only a Cinelerra build can show whether its encoding works. Would you run test builds if I prepare a patch? Anyone else with an Intel or AMD GPU is welcome too.

Yes I can test VAAPI with an AppImage build with ffmpeg-9.0.2 on my intel platform.

Terje