Black screen in video preview, but only sometimes

[ExecutorElassus]

Please include the following information.

1. Flowblade version (Help->About): 2.12 (built just now from git; also an issue with 2.10)
2. MLT version (Help->Runtime Environment): 7.18.0
3. Your distribution (Ubuntu, Debian, Mint etc.): gentoo
4. If possible, try to provide step-by-step instructions on how to reproduce the issue. From developer point of view this is the easieast way to understand what is happening.:

When I first start flowblade, the video preview window is usually black. Restarting flowblade 2-3 times gets me a working video preview. Audio always works. I don't see any error in the console. Any guess what this might be? Any suggestions for how to get some kind of error message?

[jliljebl]

Ok, thanks for the report. This does not reproduce my system, maybe there are some issues with Gentoo build of MLT?

[AlexBocken]

I also experience this problem. My setup differs so it probably is not Gentoo in particular.

OS: Arch (kernel 6.6.2)
flowblade: 2.10.0.4-1
MLT: 7.18.0-4

Is there a way we can help with logs or something of the sort?

[jliljebl]

Is there a way we can help with logs or something of the sort?

There are a couple of things you could try:

1. Install the Flatpak version of Flowblade and compare the behavior. If it is different we get some data.

2. If you start application from terminal (likely with command 'flowblade') and then compare the output between the cases when monitor works and when it does not.

[AlexBocken]

Alright, I was hoping that there might be a more detailed debugging log available.
I could find a way to reproduce my issue: opening a .FLB file reliably results in no preview image. Starting from scratch results in a fully functioning video preview. I'm not sure whether this is still the same problem @ExecutorElassus is experiencing.

I have recorded two logs (stdout and stderr combined) for these two scenarios, maybe you can find something in there that gives you a hint what it might be.

Starting from scratch (video preview works):
flowblade.log

Opening a .FLB file (video preview does not work):
flowblade_open_project.log

I tried the flatpak version, there the preview does not have any issues (although other stuff like saving seems to break or at least throw errors, did not look too deeply into it though).
You can find the same log for the flatpak version attached as well:
flowblade_flatpak.log

[ExecutorElassus]

@AlexBocken , that is indeed the case with me as well. Starting a new project consistently allows me to see the video preview, but opening a project requires multiple restarts before it will show a preview.

[jliljebl]

@AlexBocken @ExecutorElassus

Ok, thanks for the input:

ladspa_dsp: error: no config files found
/usr/lib/python3.11/site-packages/mlt7.py:299: Warning: cannot register existing type 'gtkmm__GBinding'
  return _mlt7.Factory_init(directory)
mlt_repository_init: failed to dlopen /usr/lib/mlt-7/libmltrtaudio.so
  (librtaudio.so.6: cannot open shared object file: No such file or directory)

...and this one:

Traceback (most recent call last):
  File "/app/share/flowblade/Flowblade/cairoarea.py", line 80, in _draw_event
    self._draw_func(None, cr, (a.x, a.y, a.width, a.height)) # 'None' is event object that was used to pass through here.
  File "/app/share/flowblade/Flowblade/tlinewidgets.py", line 2397, in _draw
    self.draw_track(cr, current_sequence().tracks[i], y, is_insert_track)
  File "/app/share/flowblade/Flowblade/tlinewidgets.py", line 2440, in draw_track
    cr.move_to(COLUMN_LEFT_PAD + ID_PAD_X, y + text_y)
UnboundLocalError: local variable 'text_y' referenced before assignment

with further commet here:

that is indeed the case with me as well. Starting a new project consistently allows me to see the video preview, but opening a project requires multiple restarts before it will show a preview.

I think the issue underlying all these reports might be that mlt.Comsumer("sdl") is created before all the required resources are available. I thought that the move to using Gtk.Application for the main app might have helped here, but that does not seem to be the case. This is something that worked for years, but now seems to be broken.

I will try to change the order that things are initialized to get a different outcome for users having this problem. With Christmas and New Year coming it will probably be mid-January before I have something new to present with this problem.

[schauveau]

I am also experiencing a black preview window on Debian using their official package for flowblade 2.12-1.

At first, I assumed that it was a Wayland problem since I am using Sway (with GDK_BACKEND=x11 and SDL_VIDEODRIVER=x11) but I just tried a true X11 session with Openbox and that did not solve anything.

Here is a log under Sway with GDK_BACKEND=x11 and SDL_VIDEODRIVER=x11

LOG-flowblade.txt

I am not seeing anything suspicious in the log except maybe for the missing MLT services: frei0r.alpha0ps_alphagrad, frei0r.alpha0ps_alphaspot and frei0r.alpha0ps_alpha0ps.

Since frei0r.alpha0p is about Display and manipulation of the alpha channel, I wonder if that could cause a black preview.

[schauveau]

I forgot to mention that I never managed to get it working even when starting a project from scratch.

[fersdt]

I also experience the same problem. My setup is the following:

OS: Debian trixie/sid (kernel 6.5.0.5-amd64)
flowblade: 2.12.0
MLT: 7.22.0

The only way for not have a black screen in video preview is to use a X11 window session.
Screen remains black for Gnome classic window session.

Here you can see the log file for the Gnome classic window session.
flowblade_log.txt

And here the logfile for thr X11 windows sessions (here all works fine):
flowblade_x11_log.txt

[flippette]

I also have this problem on Arch Linux with Flowblade 2.12, MLT 7.22 and Hyprland, but only with the native Arch package (run as GDK_BACKEND=x11 SDL_VIDEODRIVER=x11 /usr/bin/flowblade)

The flatpak works fine.

Here's the logs for the native package:
flowblade_native.log

And here's the logs for the flatpak:
flowblade_flatpak.log

[schauveau]

I found a workaround ... kind of.

Following the previous comment that the issue was related to mlt.Comsumer("sdl") , I looked in the MLT documentation and noticed that there are several other consumer plugins to choose from.

https://www.mltframework.org/plugins/PluginsConsumers/

So I edited /usr/share/flowblade/Flowblade/mltplayer.py to replace "sdl" by something else. I am still using GDK_BACKEND=x11 SDL_VIDEODRIVER=x11 flowblade

With "sdl2", I get a preview in a separate window but resizing does not work ; the output is displayed 1:1 and so is clipped when the window is too small.

with "qglsl" (Qt OpenGL) there is a warning about an expected failure and nothing appears.

with "xgl" , I get a valid preview in a separate window but, unlike with "sdl2", the content is properly resized. I haven't figure out if it it possible to embed the preview in the main window.

To summarize, edit /usr/share/flowblade/Flowblade/mltplayer.py and transform the line
self.consumer = mlt.Consumer(self.profile, "sdl")
into
self.consumer = mlt.Consumer(self.profile, "xgl")

I am not really surprised that "sdl" is causing problem since it is using SDL1 and according to the Debian documentation "The toolkit is in maintenance mode, and it will not get Wayland support." All SDL1 apps should migrate to SDL2 (even on X11).

Correction: The "sdl" consumer may not be SDL1 after all since it is advertised as SDL Fast YUV.

[schauveau]

After a few more minutes playing with the "xgl" Consumer, it appears that it is quite unstable. It crashes on a lot of actions (e.g. resize window or even during playback).

"sdl2" seems a lot more robust. Now, I just have to figure out how to fix the rescaling issue.

[schauveau]

I have a usable workaround for the black screen issue by moving the preview to a separate window.
That does not really explain the bug itself but for those that are interested, look in https://gist.github.com/schauveau/cb3ec6a855d16f3982760d0b256f808c

[jliljebl]

@ExecutorElassus, @fersdt @AlexBocken

I updated the Issue template to ask for DE and X11/Wayland situation to get more detailed info on issues such as this.

If possible could you provide info on the question mark parts of the OS/X11 or Wayland/DE info in the table of below.

System	Status	User
Flatpak	GOOD	all
gentoo /?/?	BAD	@ExecutorElassus
Arch/?/?	BAD	@AlexBocken
Debian/Wayland/Sway	BAD	@schauveau
Debian/X11/Openbox	BAD	@schauveau
Arch/Wayland/Hyprland	BAD	@flippette
Debian/X11/?	GOOD	@fersdt
Debian/Wayland/?	BAD	@fersdt

[jliljebl]

update:

System	Status	User
Flatpak	GOOD	all
gentoo /?/?	BAD	@ExecutorElassus
Arch/?/?	BAD	@AlexBocken
Debian/Wayland/Sway	BAD	@schauveau
Debian/X11/Openbox	BAD	@schauveau
Arch/Wayland/Hyprland	BAD	@flippette
Debian/X11/?	GOOD	@fersdt
Debian/Wayland/?	BAD	@fersdt
Arch/X11/i3wm	BAD	users in Issue #1143

[AlexBocken]

My setup is X11/dwm, so should probably be the same as #1143

[ExecutorElassus]

my setup is xorg/fvwm

[schauveau]

I noticed that the flatpak is using libSDL-1.2.so.0.11.4 so the real SDL1 library.

My Debian system provides SDL1 as a wrapper around SDL2 in package libsdl1.2debian "SDL 1.2 binary compatibility library wrapping SDL 2.0" so I copied libSDL-1.2.so.0.11.4 from the flatpak to my home dir and then

LD_PRELOAD=$HOME/libSDL-1.2.so.0.11.4 GDK_BACKEND=x11 SDL_VIDEODRIVER=x11 flowblade

I started flowblade multiple times without getting the black screen while it is always there when using the SDL1/SDL2 wrapper.

[schauveau]

I may have an even simpler bugfix. I tried some the env vars listed in https://github.com/libsdl-org/sdl12-compat/ but nothing worked when using the wrapper. Then I started browsing through the code and I found this

   / * Some games (notably the Steam build of Multiwinia), will
     * SDL_Quit(SDL_INIT_VIDEO) on resolution change, and never call
     * SDL_Init() again before creating their new window.
     */
    if (SDL12Compat_GetHintBoolean("SDL12COMPAT_NO_QUIT_VIDEO", SDL_FALSE)) {
        sdl12flags &= ~SDL12_INIT_VIDEO;
    }

See https://github.com/libsdl-org/sdl12-compat/blob/97e01d2bf5d50e41ed6c61c077490e3263021bcd/src/SDL12_compat.c#L2729

So setting SDL12COMPAT_NO_QUIT_VIDEO=1 appears to solve the problem.

SDL12COMPAT_NO_QUIT_VIDEO=1 GDK_BACKEND=x11 SDL_VIDEODRIVER=x11 /usr/bin/flowblade

So what is likely happening is that Flowblade/MLT is destroying & recreating the SDL window multiple times. I noticed that when playing with the sdl2 backend. see #1134 (comment) . That typically happens when the Flowblade window is resized.

[AlexBocken]

I can confirm that using SDL12COMPAT_NO_QUIT_VIDEO=1 GDK_BACKEND=x11 SDL_VIDEODRIVER=x11 /usr/bin/flowblade solves the issue for me.
Thanks for the great research @schauveau !

[jliljebl]

/ * Some games (notably the Steam build of Multiwinia), will
* SDL_Quit(SDL_INIT_VIDEO) on resolution change, and never call
* SDL_Init() again before creating their new window.
*/
if (SDL12Compat_GetHintBoolean("SDL12COMPAT_NO_QUIT_VIDEO", SDL_FALSE)) {
sdl12flags &= ~SDL12_INIT_VIDEO;
}

So what is likely happening is that Flowblade/MLT is destroying & recreating the SDL window multiple times. I noticed that when playing with the sdl2 backend. see #1134 (comment) . That typically happens when the Flowblade window is resized.

Flowblade does indeed call consumer.stop()/consumer.start() repeatedly and I do seem to remember that the reason was exactly that window resize needed that to update video size.

I looked at code in consumer_sdl.c and in there the SDL_Init() is called in consumer_start() if:

        if (sdl_started == 0 && display_off == 0) {
            ...
            int ret = SDL_Init(SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE); 

and in consumer_stop() SDL_Quit() is called if

        if (mlt_properties_get_int(MLT_CONSUMER_PROPERTIES(parent), "sdl_started") == 0)
            SDL_Quit();

so SDL_Init() seems to require more conditions to be called, so it seems probable without doing full analysis of state changes that SDL_Quit() might get called without SDL_Init() being called again.

The research was indeed great @schauveau. I believe you got everything right and presented a working solution also, thank you.

I'll post the solution on front page with a link to this Issue if the fix is not working for someone.

[ExecutorElassus]

can confirm that schauveu's fix solved the issue for me as well. Amazing work. Is there a way to fix that permanently without having to initiate flowblade with those settings every time?

[schauveau]

SDL12COMPAT_NO_QUIT_VIDEO can be set from within the flowblade executable file (a python script) with something like

os.putenv('SDL12COMPAT_NO_QUIT_VIDEO' , '1')

That line must be inserted after the import os but before starting the main loop.

If you are under Wayland you could also add GDK_BACKEND=x11 and SDL_VIDEODRIVER=x11 to the environment

Another possible location is the flowblade desktop file. On Debian, that is /usr/share/applications/io.github.jliljebl.Flowblade.desktop and you want to edit the Exec line to something like

Exec=env GDK_BACKEND=x11 SDL12COMPAT_NO_QUIT_VIDEO=1 flowblade %f

Of course, any change made to a file managed by the system is likely to be reverted during the next upgrade so a safer approach is probably to create a shell script for instance as /usr/local/bin/flowblade

#!/bin/sh
export GDK_BACKEND=x11
export SDL_VIDEODRIVER=x11
export SDL12COMPAT_NO_QUIT_VIDEO=1
exec /usr/bin/flowblade "$@"

[sobrus]

I'm also getting black screen preview, but only when I activate proxy video.
At first, the video is showing correctly (at least usually), and after minimizing and then maximizing window the display is black until I use original media instead. The preview goes black again if I enable proxy media, comes back for original ones. Restarting the app helps, but then it goes black again. Tried various proxy media formats.

OS: Manjaro Unstable + CachyOS v3 (kernel 6.7.4)
flowblade: 2.12-1 (from manjaro ustable extra repo)
MLT: 7.22.0 (cachyos v3 repo)
GPU: RX6800XT using open source drivers, hardware acceleration available

edit:
adding SDL12COMPAT_NO_QUIT_VIDEO=1 fixes the problem