Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files

[alban.browaeys at gmail.com]

On Fri, 10 May 2024 09:30:03 +0100 Simon McVittie <smcv at debian.org>
wrote:
> On Fri, 10 May 2024 at 06:14:46 +0200, Alban Browaeys wrote:
> > Would adding openblas_set_num_threads(1) to totem-resource.c be
fine?
> > Wouldn't it add  a hard dependency to openblas on totem?
> 
> I think this would not be OK. totem cannot assume that the current
> implementation of libblas.so.3 or liblapack.so.3 is openblas: it
might
> equally well be libatlas3-base, which presumably does not offer that
> openblas-specific function.


What about OMP_NUM_THREADS environment variable set to 1 in the totem
thumbnailer? As in
https://salsa.debian.org/gnome-team/totem/-/merge_requests/8

 
> > Should the ffmpeg or gstreamer provide an API to set this openblas
> > number or thread to 1 in case the application is multi-threaded (I
> > believe totem is multi-threaded) to avoid adding such hard
dependency
> > in the upper layers if they don't already provides such an API?
> 
> My understanding is that all GStreamer programs are automatically
> multi-threaded, because GStreamer uses threads for the elements of a
> pipeline.
> 
> It is not usually safe for libraries to alter process-global state at
> runtime, because by the time the application calls into the library,
> it might already have multiple threads running.
> 
> > until a solutoin that does not involve hardcoding low level
optional
> > dependencies into totem is sorted out (probably more of an upsteam
> > issue), one can add "OPENBLAS_NUM_THREADS=1" to the environment of
the
> > totem thumbnailer.
>
> It would be possible for affected applications like totem to work
> around this bug by adding g_setenv("OPENBLAS_NUM_THREADS", "1", TRUE)
> near the beginning of main(), before they have had the opportunity to
> create multiple threads.
> 
> After a second thread has been created, it is no longer safe to call
> g_setenv() or similar functions like setenv() and putenv(), so it
really
> does have to be right at the beginning of main(), and probably cannot
> be in library code.
> 
> This seems like a workaround that would not scale particularly well,
> because totem is far from being the only application that uses
GStreamer.

Agreed but we are only applying this environment variable to the totem
thumbnailer code and this totem thumbnailer children. So I believe it
is OK. Also the amount of memory that openblas pthread upping its
memory requirement depending on the number of cores can take at max
cannot be predicted (if say one run on a Ampere ARM box and has 128
cores). So we cannot predict a hard max limit to the amount that the
totem thumbnailer can hardcode as it currently does. Except if we also
hardcode the number of threads that openblas pthread can use.

 
Cheers,
Alban