Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

> Am 21.07.2019 um 21:58 schrieb Josh Triplett :
> 
>> On July 21, 2019 11:38:03 AM PDT, James Cowgill  wrote:
>> Hi,
>> 
>>> On 12/03/2019 12:44, Reinhard Tartler wrote:
>>> On Tue, Mar 12, 2019 at 8:36 AM Carl Eugen Hoyos >> > wrote:
>>> 
>>>Please show the dependencies of (at least) libavutil and
>> libavcodec
>>>with your approach and maybe compare them to what sdl needs:
>> While the
>>>list may become smaller I wonder if it this would really solve
>> the
>>>described issue.
>>> 
>>> Sure thing, please find the full build log attached to this email.
>>> It details the full metadata at the end of the log.
>> 
>> I've been on a rather long haitus from Debian stuff for a while, t I
>> now
>> have some time to do more so I'm going to get FFmpeg 4.1.4 uploaded
>> next
>> (and by the looks of things 4.2 is just around the corner...)
>> 
>> I see a "fix" for this in the git history, but I think it's broken:
>> 
>> * There is an obvious typo in the d/rules file which prevents the
>> option
>> to disable the SDL output device from taking effect. You can see from
>> the build log attached to this bug report that we still have an SDL
>> dependency.
>> 
>> * Even after fixing that, the dependency remains. I think the "opengl"
>> device backend has a dependency on SDL as well. Disabling that is
>> probably a greater loss?
>> 
>> * With the above two changes (disabling both sdl and opengl), I ran the
>> final packages through dose and compared the dependencies. This is the
>> list of transitive dependencies that no longer need installing after
>> this change:
>> 
>> libsdl2-2.0-0
>> libwayland-client0
>> libwayland-cursor0
>> libwayland-egl1
>> libxcursor1
>> libxinerama1
>> libxkbcommon0
>> libxrandr2
>> libxss1
>> xkb-data
>> 
>> Notice that all of OpenGL, all xcb and core x11 libraries are still
>> required.
>> 
>> The total uncompressed size of these packages is around 8M, with
>> libsdl2-2.0-0 and xkb-data being the only significant packages (the
>> rest
>> are < 100k). Note that xkb-data is installed by default so that saving
>> is probably only relevant for stripped down containers. For comparison,
>> if I install ffmpeg in a build chroot, apt says it will use 418M of
>> extra space.
>> 
>> In conclusion, I don't think the savings this change gives us are worth
>> it, and I don't like disabling features in FFmpeg :)
>> 
>> I think what you really want is an "ffmpeg-nox" package containing a
>> build of the frontend ffmpeg tool with libavdevice completely disabled.
>> I haven't run this in dose, but by dropping this dependency I would
>> expect all the GL / X11 / etc dependencies to also go which would give
>> much better space savings. Probably needs a little more thinking about
>> the way this would be implemented though (and it's relationship with
>> the
>> normal ffmpeg package).
> 
> You're right, that's much more what I'm looking for. This is primarily for 
> headless servers, which primarily need the command line tool and a subset of 
> libraries.

I don’t understand: Didn’t you confirm that you tested the committed solution 
and that it works for you?

Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On July 21, 2019 11:38:03 AM PDT, James Cowgill  wrote:
>Hi,
>
>On 12/03/2019 12:44, Reinhard Tartler wrote:
>> On Tue, Mar 12, 2019 at 8:36 AM Carl Eugen Hoyos > > wrote:
>> 
>> Please show the dependencies of (at least) libavutil and
>libavcodec
>> with your approach and maybe compare them to what sdl needs:
>While the
>> list may become smaller I wonder if it this would really solve
>the
>> described issue.
>> 
>> Sure thing, please find the full build log attached to this email.
>> It details the full metadata at the end of the log.
>
>I've been on a rather long haitus from Debian stuff for a while, t I
>now
>have some time to do more so I'm going to get FFmpeg 4.1.4 uploaded
>next
>(and by the looks of things 4.2 is just around the corner...)
>
>I see a "fix" for this in the git history, but I think it's broken:
>
>* There is an obvious typo in the d/rules file which prevents the
>option
>to disable the SDL output device from taking effect. You can see from
>the build log attached to this bug report that we still have an SDL
>dependency.
>
>* Even after fixing that, the dependency remains. I think the "opengl"
>device backend has a dependency on SDL as well. Disabling that is
>probably a greater loss?
>
>* With the above two changes (disabling both sdl and opengl), I ran the
>final packages through dose and compared the dependencies. This is the
>list of transitive dependencies that no longer need installing after
>this change:
>
> libsdl2-2.0-0
> libwayland-client0
> libwayland-cursor0
> libwayland-egl1
> libxcursor1
> libxinerama1
> libxkbcommon0
> libxrandr2
> libxss1
> xkb-data
>
>Notice that all of OpenGL, all xcb and core x11 libraries are still
>required.
>
>The total uncompressed size of these packages is around 8M, with
>libsdl2-2.0-0 and xkb-data being the only significant packages (the
>rest
>are < 100k). Note that xkb-data is installed by default so that saving
>is probably only relevant for stripped down containers. For comparison,
>if I install ffmpeg in a build chroot, apt says it will use 418M of
>extra space.
>
>In conclusion, I don't think the savings this change gives us are worth
>it, and I don't like disabling features in FFmpeg :)
>
>I think what you really want is an "ffmpeg-nox" package containing a
>build of the frontend ffmpeg tool with libavdevice completely disabled.
>I haven't run this in dose, but by dropping this dependency I would
>expect all the GL / X11 / etc dependencies to also go which would give
>much better space savings. Probably needs a little more thinking about
>the way this would be implemented though (and it's relationship with
>the
>normal ffmpeg package).

You're right, that's much more what I'm looking for. This is primarily for 
headless servers, which primarily need the command line tool and a subset of 
libraries.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[James Cowgill]

Hi,

On 12/03/2019 12:44, Reinhard Tartler wrote:
> On Tue, Mar 12, 2019 at 8:36 AM Carl Eugen Hoyos  > wrote:
> 
> Please show the dependencies of (at least) libavutil and libavcodec
> with your approach and maybe compare them to what sdl needs: While the
> list may become smaller I wonder if it this would really solve the
> described issue.
> 
> Sure thing, please find the full build log attached to this email.
> It details the full metadata at the end of the log.

I've been on a rather long haitus from Debian stuff for a while, t I now
have some time to do more so I'm going to get FFmpeg 4.1.4 uploaded next
(and by the looks of things 4.2 is just around the corner...)

I see a "fix" for this in the git history, but I think it's broken:

* There is an obvious typo in the d/rules file which prevents the option
to disable the SDL output device from taking effect. You can see from
the build log attached to this bug report that we still have an SDL
dependency.

* Even after fixing that, the dependency remains. I think the "opengl"
device backend has a dependency on SDL as well. Disabling that is
probably a greater loss?

* With the above two changes (disabling both sdl and opengl), I ran the
final packages through dose and compared the dependencies. This is the
list of transitive dependencies that no longer need installing after
this change:

 libsdl2-2.0-0
 libwayland-client0
 libwayland-cursor0
 libwayland-egl1
 libxcursor1
 libxinerama1
 libxkbcommon0
 libxrandr2
 libxss1
 xkb-data

Notice that all of OpenGL, all xcb and core x11 libraries are still
required.

The total uncompressed size of these packages is around 8M, with
libsdl2-2.0-0 and xkb-data being the only significant packages (the rest
are < 100k). Note that xkb-data is installed by default so that saving
is probably only relevant for stripped down containers. For comparison,
if I install ffmpeg in a build chroot, apt says it will use 418M of
extra space.

In conclusion, I don't think the savings this change gives us are worth
it, and I don't like disabling features in FFmpeg :)

I think what you really want is an "ffmpeg-nox" package containing a
build of the frontend ffmpeg tool with libavdevice completely disabled.
I haven't run this in dose, but by dropping this dependency I would
expect all the GL / X11 / etc dependencies to also go which would give
much better space savings. Probably needs a little more thinking about
the way this would be implemented though (and it's relationship with the
normal ffmpeg package).

James



signature.asc
Description: OpenPGP digital signature

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 07:10:09PM -0400, Reinhard Tartler wrote:
> On Tue, Mar 12, 2019 at 1:49 PM Josh Triplett  wrote:
> 
> > On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> > >Depends: libavcodec58 (= 7:4.1.1-2),
> > > libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> > > 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2),
> > libc6
> > > (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> > > libswscale5 (= 7:4.1.1-2)
> > >  Suggests: ffmpeg-doc
> >
> > You might want to add a Suggests on ffplay, as well.
> >
> 
> Good idea, done.
> 
> The changes are in the 'master' branch of our packaging repository now.
> Unfortunately, we missed the Debian freeze. Not sure if this is worth
> asking for a freeze exception.
> 
> What do you guys think?

Speaking for myself only, all the systems on which this might end up
installed run sid. And the previous Debian stable had this dependency,
so this isn't a regression. I'd suggest not asking for a freeze
exception.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Tue, Mar 12, 2019 at 1:49 PM Josh Triplett  wrote:

> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> >Depends: libavcodec58 (= 7:4.1.1-2),
> > libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> > 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2),
> libc6
> > (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> > libswscale5 (= 7:4.1.1-2)
> >  Suggests: ffmpeg-doc
>
> You might want to add a Suggests on ffplay, as well.
>

Good idea, done.

The changes are in the 'master' branch of our packaging repository now.
Unfortunately, we missed the Debian freeze. Not sure if this is worth
asking for a freeze exception.

What do you guys think?

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 08:31:51PM +0100, Carl Eugen Hoyos wrote:
> 2019-03-12 18:48 GMT+01:00, Josh Triplett :
> > On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> 
> >> I think this should address the issue. Any objections to this approach?
> >
> > This would work perfectly for me, and I would then avoid installing
> > ffplay on my servers.
> 
> I was expecting that the ffmpeg package would still pull a large
> number of dependencies including X11 with this change but if
> there is an improvement for you, all the better!

As long as libavdevice no longer depends on libsdl2 either, that'll
suffice. libavdevice still depends on a handful of X libraries, but I
don't mind having a few of those installed on my server, and I already
had some of them for things like `ssh -X`. libsdl2 substantially
increased the dependencies.

Thank you!

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-12 18:48 GMT+01:00, Josh Triplett :
> On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:

>> I think this should address the issue. Any objections to this approach?
>
> This would work perfectly for me, and I would then avoid installing
> ffplay on my servers.

I was expecting that the ffmpeg package would still pull a large
number of dependencies including X11 with this change but if
there is an improvement for you, all the better!

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
>Depends: libavcodec58 (= 7:4.1.1-2),
> libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6
> (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> libswscale5 (= 7:4.1.1-2)
>  Suggests: ffmpeg-doc

You might want to add a Suggests on ffplay, as well.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote:
> On Sun, Mar 10, 2019 at 9:36 PM Carl Eugen Hoyos  wrote:
> 
> > > What might work is disabling the avdevice outdev AND
> > > moving 'ffplay' to its own binary package.
> >
> > Before suggesting this, I would prefer the OP to test. I
> > still do not entirely believe that this fixes his issue.
> >
> >
> There is a good chance that the OP did not get this message, because
> debbugs does not automatically subscribe the original submitter. One has to
> exlicitly use the nn-submit...@bugs.debian.org alias or include his
> email address explicitly.

I did get the original mail suggesting the additional config options, and
not the above mails.  I hadn't yet had time to try rebuilding ffmpeg
from source.

> I've went ahead and implemented the change (passing in
> --disable-outdev=sdl2 as you suggested, and moving ffplay into its own
> binary package)
> 
> With this patch, the ffmpeg binary package has a depends line like this:
> 
> 
> 
> 
> 
> 
>  Package: ffmpeg
> 
>  Version: 7:4.1.1-2
> 
>Architecture: amd64
> 
>Maintainer:
> Debian Multimedia Maintainers 
> 
>  Installed-Size: 1808
> 
>Depends: libavcodec58 (= 7:4.1.1-2),
> libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
> 7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6
> (>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
> libswscale5 (= 7:4.1.1-2)
>  Suggests: ffmpeg-doc
> 
>Breaks: libav-tools (<< 6:12~~), qt-faststart (<<
> 7:2.7.1-3~), winff (<< 1.5.5-5~)
>Replaces: libav-tools (<<
> 6:12~~), qt-faststart (<< 7:2.7.1-3~)
>
> Section:
> video
> 
> 
> 
> 
> 
> 
> Note that there is a dependency on libavdevice58, but not on SDL.
> 
> 
> 
> 
> 
> The 'ffplay' binary package has a depends line that looks like this:
> 
> 
> 
> 
> 
> 
>  Package: ffplay
>  Source: ffmpeg
>  Version: 7:4.1.1-2
>  Architecture: amd64
>  Maintainer: Debian Multimedia Maintainers <
> debian-multime...@lists.debian.org>
>  Installed-Size: 226
> 
>Depends: libavcodec58 (= 7:4.1.1-2), libavdevice58 (=
> 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (= 7:4.1.1-2),
> libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6 (>= 2.14),
> libpostproc55 (= 7:4.1.1-2), libsdl2-2.0-0 (>= 2.0.9), libswresample3 (=
> 7:4.1.1-2), libswscale5 (= 7:4.1.1-2), ffmpeg
>  Suggests: ffmpeg-doc
> 
>  Breaks: ffmpeg (<< 7:4.1.1-2~), libav-tools (<<
> 6:12~~), qt-faststart (<< 7:2.7.1-3~), winff (<< 1.5.5-5~)
>  Replaces: ffmpeg (<<
> 7:4.1.1-2~), libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)
> 
> Section:
> video
> 
> 
> 
> 
> 
> 
> Note that this includes both libavdevice58 as well as libsdl2-2.
> 
> 
> 
> 
> 
> 
> I think this should address the issue. Any objections to this approach?

This would work perfectly for me, and I would then avoid installing
ffplay on my servers.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-12 13:25 GMT+01:00, Reinhard Tartler :
> In a headless installation that is used for transcoding and streaming,
> such dependencies, like on X11, wayland, etc. may not be desirable.

Funny that you mention X11 and wayland: Both are still dependencies
of FFmpeg after your patch, no?

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

Please show the dependencies of (at least) libavutil and libavcodec
with your approach and maybe compare them to what sdl needs: While the
list may become smaller I wonder if it this would really solve the
described issue.

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sun, Mar 10, 2019 at 9:36 PM Carl Eugen Hoyos  wrote:

> > What might work is disabling the avdevice outdev AND
> > moving 'ffplay' to its own binary package.
>
> Before suggesting this, I would prefer the OP to test. I
> still do not entirely believe that this fixes his issue.
>
>
There is a good chance that the OP did not get this message, because
debbugs does not automatically subscribe the original submitter. One has to
exlicitly use the nn-submit...@bugs.debian.org alias or include his
email address explicitly.

I've went ahead and implemented the change (passing in
--disable-outdev=sdl2 as you suggested, and moving ffplay into its own
binary package)

With this patch, the ffmpeg binary package has a depends line like this:






 Package: ffmpeg

 Version: 7:4.1.1-2

   Architecture: amd64

   Maintainer:
Debian Multimedia Maintainers 

 Installed-Size: 1808

   Depends: libavcodec58 (= 7:4.1.1-2),
libavdevice58 (= 7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (=
7:4.1.1-2), libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6
(>= 2.14), libpostproc55 (= 7:4.1.1-2), libswresample3 (= 7:4.1.1-2),
libswscale5 (= 7:4.1.1-2)
 Suggests: ffmpeg-doc

   Breaks: libav-tools (<< 6:12~~), qt-faststart (<<
7:2.7.1-3~), winff (<< 1.5.5-5~)
   Replaces: libav-tools (<<
6:12~~), qt-faststart (<< 7:2.7.1-3~)
   Section:
video






Note that there is a dependency on libavdevice58, but not on SDL.





The 'ffplay' binary package has a depends line that looks like this:






 Package: ffplay
 Source: ffmpeg
 Version: 7:4.1.1-2
 Architecture: amd64
 Maintainer: Debian Multimedia Maintainers <
debian-multime...@lists.debian.org>
 Installed-Size: 226

   Depends: libavcodec58 (= 7:4.1.1-2), libavdevice58 (=
7:4.1.1-2), libavfilter7 (= 7:4.1.1-2), libavformat58 (= 7:4.1.1-2),
libavresample4 (= 7:4.1.1-2), libavutil56 (= 7:4.1.1-2), libc6 (>= 2.14),
libpostproc55 (= 7:4.1.1-2), libsdl2-2.0-0 (>= 2.0.9), libswresample3 (=
7:4.1.1-2), libswscale5 (= 7:4.1.1-2), ffmpeg
 Suggests: ffmpeg-doc

 Breaks: ffmpeg (<< 7:4.1.1-2~), libav-tools (<<
6:12~~), qt-faststart (<< 7:2.7.1-3~), winff (<< 1.5.5-5~)
 Replaces: ffmpeg (<<
7:4.1.1-2~), libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)

Section:
video






Note that this includes both libavdevice58 as well as libsdl2-2.






I think this should address the issue. Any objections to this approach?


-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

> What might work is disabling the avdevice outdev AND
> moving 'ffplay' to its own binary package.

Before suggesting this, I would prefer the OP to test. I
still do not entirely believe that this fixes his issue.

Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sun, Mar 10, 2019 at 6:57 PM Carl Eugen Hoyos  wrote:

> 2019-03-10 23:21 GMT+01:00, Reinhard Tartler :
> > On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos 
> wrote:
> >
> >> Could you test the configure option "--disable-outdev=sdl2"?
> >> Your report indicates it should fix your issue, I am not convinced but
> >> if it fixes your issue, Debian should consider using it as the device
> >> is mostly a (cheap) debug feature.
>
> > Wouldn't that video break playback in 'ffplay'?
>
> Can you elaborate why you think so?
>

By looking at
https://sources.debian.org/src/ffmpeg/7:4.1.1-1/fftools/ffplay.c/, I see
plenty of references to SDL, many of which aren't guarded by #ifdefs. Looks
like SDL2 is a hard dependency for a functional ffplay.


> > Can you elaborate what makes you think so?
>
> Iirc, I was the only one speaking against its removal.
>

You mean dropping ffplay altogether? - I am having a hard time parsing that
sentence.

> But given that your avconv project never contained an sdl output
> device I wonder what your expertise is here?
>
>
I believe we may mis-communicating here. AFAIUI, the original poster wanted
to make SDL an optional dependency. Even if the debian package was compiled
with '--disable-outdev=sdl2', wouldn't the 'ffmpeg' binary package still
continue to depend on sdl2 libraries? - In that case we haven't won
anything by this. I guess the debian package would in addition have to pass
the --disable-sdl2 switch to configure, which to my understanding would
prevent 'ffplay' from being compiled. I would consider that a regression.

What might work is disabling the avdevice outdev AND moving 'ffplay' to its
own binary package.

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

2019-03-10 23:21 GMT+01:00, Reinhard Tartler :
> On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos  wrote:
>
>> Could you test the configure option "--disable-outdev=sdl2"?
>> Your report indicates it should fix your issue, I am not convinced but
>> if it fixes your issue, Debian should consider using it as the device
>> is mostly a (cheap) debug feature.

> Wouldn't that video break playback in 'ffplay'?

Can you elaborate why you think so?

> at the very least, it would break the "SDL2 output device" in libavdevice.

Obviously.

> I'm not sure if I'd agree with that being a "cheap debug [only] feature".

You don't have to.

> Can you elaborate what makes you think so?

Iirc, I was the only one speaking against its removal.

But given that your avconv project never contained an sdl output
device I wonder what your expertise is here?

Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Reinhard Tartler]

On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos  wrote:

> Hi!
>
> Could you test the configure option "--disable-outdev=sdl2"?
> Your report indicates it should fix your issue, I am not convinced but
> if it fixes your issue, Debian should consider using it as the device
> is mostly a (cheap) debug feature.
>
> Please report back, Carl Eugen
>
>
Wouldn't that video break playback in 'ffplay'? - at the very least, it
would break the "SDL2 output device" in libavdevice.

I'm not sure if I'd agree with that being a "cheap debug [only] feature".
Can you elaborate what makes you think so?

-- 
regards,
Reinhard

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Carl Eugen Hoyos]

Hi!

Could you test the configure option "--disable-outdev=sdl2"?
Your report indicates it should fix your issue, I am not convinced but
if it fixes your issue, Debian should consider using it as the device
is mostly a (cheap) debug feature.

Please report back, Carl Eugen

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[Josh Triplett]

Package: ffmpeg
Version: 7:4.1.1-1
Severity: normal

ffmpeg currently has a hard dependency on libsdl2. This pulls in a
*huge* number of graphics-related dependencies. For a desktop/laptop,
that's fine, and likely won't pull in much the user doesn't already
have. However, on a headless server (using ffmpeg for transcoding and
similar), this pulls in numerous additional GUI packages that wouldn't
otherwise be installed. For this specific library, please consider
detecting its availability at runtime, and switching to Recommends.

Thank you.