Discussion:
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
(too old to reply)
Josh Triplett
2019-02-28 23:20:01 UTC
Permalink
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.
Carl Eugen Hoyos
2019-03-09 20:00:01 UTC
Permalink
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
Reinhard Tartler
2019-03-10 22:30:01 UTC
Permalink
Post by 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
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
Carl Eugen Hoyos
2019-03-10 23:00:02 UTC
Permalink
Post by Reinhard Tartler
Post by Carl Eugen Hoyos
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?
Post by Reinhard Tartler
at the very least, it would break the "SDL2 output device" in libavdevice.
Obviously.
Post by Reinhard Tartler
I'm not sure if I'd agree with that being a "cheap debug [only] feature".
You don't have to.
Post by Reinhard Tartler
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
Reinhard Tartler
2019-03-11 01:10:01 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Reinhard Tartler
Post by Carl Eugen Hoyos
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.
Post by Carl Eugen Hoyos
Post by Reinhard Tartler
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.
Post by Carl Eugen Hoyos
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
Carl Eugen Hoyos
2019-03-11 01:40:01 UTC
Permalink
Post by Reinhard Tartler
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
Reinhard Tartler
2019-03-12 12:30:02 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Reinhard Tartler
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 NNNNNN-***@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 <debian-***@lists.debian.org>

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-***@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
Carl Eugen Hoyos
2019-03-12 12:40:01 UTC
Permalink
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.
Carl Eugen Hoyos
2019-03-12 13:00:01 UTC
Permalink
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?
Josh Triplett
2019-03-12 18:00:01 UTC
Permalink
Post by Reinhard Tartler
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.
Reinhard Tartler
2019-03-12 23:20:02 UTC
Permalink
Post by Josh Triplett
Post by Reinhard Tartler
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
Post by Reinhard Tartler
(>= 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
Josh Triplett
2019-03-12 23:30:02 UTC
Permalink
Post by Reinhard Tartler
Post by Josh Triplett
Post by Reinhard Tartler
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
Post by Reinhard Tartler
(>= 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.
Josh Triplett
2019-03-12 18:00:02 UTC
Permalink
Post by Reinhard Tartler
Post by Carl Eugen Hoyos
Post by Reinhard Tartler
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
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.
Post by Reinhard Tartler
I've went ahead and implemented the change (passing in
--disable-outdev=sdl2 as you suggested, and moving ffplay into its own
binary package)
Package: ffmpeg
Version: 7:4.1.1-2
Architecture: amd64
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~)
video
Note that there is a dependency on libavdevice58, but not on SDL.
Package: ffplay
Source: ffmpeg
Version: 7:4.1.1-2
Architecture: amd64
Maintainer: Debian Multimedia Maintainers <
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~)
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.
Carl Eugen Hoyos
2019-03-12 19:40:01 UTC
Permalink
Post by Josh Triplett
Post by Reinhard Tartler
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!
Josh Triplett
2019-03-12 19:50:01 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Josh Triplett
Post by Reinhard Tartler
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!
Josh Triplett
2019-07-21 20:10:02 UTC
Permalink
Post by Reinhard Tartler
Hi,
Post by Carl Eugen Hoyos
Please show the dependencies of (at least) libavutil and
libavcodec
While the
Post by Carl Eugen Hoyos
list may become smaller I wonder if it this would really solve
the
Post by Carl Eugen Hoyos
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...)
* 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
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.
Carl Eugen Hoyos
2019-07-21 22:50:01 UTC
Permalink
Post by Josh Triplett
Post by Reinhard Tartler
Hi,
Post by Carl Eugen Hoyos
Please show the dependencies of (at least) libavutil and
libavcodec
While the
Post by Carl Eugen Hoyos
list may become smaller I wonder if it this would really solve
the
Post by Carl Eugen Hoyos
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...)
* 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
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

Loading...