Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#43100 closed enhancement (wontfix)

ffmpeg, ffmpeg-devel: switch to using SDL2

Reported by: thomas.c.jansen@… Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia)
Port: ffmpeg, ffmpeg-devel

Description

Ports ffmpeg and ffmpeg-devel have a dependency on port libsdl. SDL2 (port libsdl2) has been stable since August 2013, and FFMPEG supports SDL2 during compilation. It would be great if the dependency could be changed from libsdl to libsdl2. I tested this change locally on OS 10.9.2 and didn’t run into any problem.

Attachments (1)

patch-sdl-variant.diff (1.1 KB) - added by dbevans (David B. Evans) 6 years ago.
Work in progress patch for a +sdl default variant (not fully effective)

Download all attachments as: .zip

Change History (11)

comment:1 Changed 6 years ago by ryandesign (Ryan Schmidt)

Cc: jeremyhu@… added
Owner: changed from macports-tickets@… to devans@…
Port: ffmpeg ffmpeg-devel added
Summary: Port ffmpeg(-devel) should switch to using SDL2ffmpeg, ffmpeg-devel: switch to using SDL2
Type: updateenhancement

libsdl2 cannot build without the OS X 10.7 SDK, so switching the ffmpeg ports to libsdl2 would mean they can no longer be built on Mac OS X 10.6, 10.5, or 10.4, which I would consider to be a bad thing.

comment:2 in reply to:  1 Changed 6 years ago by dbevans (David B. Evans)

Status: newassigned

Replying to ryandesign@…:

libsdl2 cannot build without the OS X 10.7 SDK, so switching the ffmpeg ports to libsdl2 would mean they can no longer be built on Mac OS X 10.6, 10.5, or 10.4, which I would consider to be a bad thing.

Agreed. However, perhaps we could add a +sdl2 variant that is only available on 10.7 and up if people really think this is necessary. Does ffmpeg offer additional/improved features using sdl2 or is this just a desire to use the latest version? I'll take a look at it.

comment:3 Changed 6 years ago by thomas.c.jansen@…

I am not aware of any additional or improved features in ffmpeg when SDL2 is used, except that SDL(1) is no longer maintained and might contain unfixed bugs.

My main motivation for filing this bug report was a build conflict I got for a project which uses ffmpeg and SDL2. Because ffmpeg links SDL(1), I ended up with SDL and SDL2 being linked at the same time, giving me symbol resolution conflicts.

Giving the user an option (+sdl2) sounds reasonable.

comment:4 Changed 6 years ago by dbevans (David B. Evans)

Sorry for losing track of this ticket.

After looking at ffmpeg's configure, it is apparent that ffmpeg will only configure with libsdl not libsdl2. It checks for sdl.pc using pkg-config or failing that sdl-config. libsdl2 provides sdl2.pc and sdl2-config.

Further testing (using current ffmpeg 2.2.1 with libsdl dependency removed) shows

  • if only libsdl2 is active, ffmpeg does NOT configure the sdl outdev
  • if only libsdl is active, ffmpeg DOES configure the sdl outdev
  • if both are installed and active (they can install in parallel without conflict), ffmpeg configures the sdl outdev using libsdl

What's your basis for claiming that ffmpeg supports libsdl2?

Last edited 6 years ago by dbevans (David B. Evans) (previous) (diff)

comment:5 Changed 6 years ago by dbevans (David B. Evans)

Same story with ffmpeg-devel (current git master). In addition, both ffmpeg and ffmpeg-devel make explicit checks during configuration to ensure that the libsdl version is >= 1.2.1 and < 1.3.0.

comment:6 Changed 6 years ago by thomas.c.jansen@…

I have to admit that I did not do the same level of due diligence as you did. However, I simply changed the “libsdl” to “libsdl2” in the port files (via “sudo port edit ffmpeg-devel”) and reinstalled ffmpeg-devel after that. Building worked fine, “port installed” does show “libsdl2” and _no_ “libsdl" and “port deps ffmpeg-devel” shows..

 $> port deps ffmpeg-devel                                                                                                                                      
 Full Name: ffmpeg-devel @20140317_0+gpl2
 Build Dependencies:   pkgconfig, gmake, texi2html, yasm
 Library Dependencies: lame, libiconv, libvorbis, libopus, libogg, libtheora, libmodplug, schroedinger, libass, libbluray, gnutls, openjpeg15, fontconfig, freetype, speex, libvpx,
                       libsdl2, bzip2, zlib, XviD, x264

However, otool doesn’t show any dependency to SDL on the ffmpeg binary at all — neither SDL1 nor SDL2! The same is true for the dylibs..

otool -L /opt/local/bin/ffmpeg 
/opt/local/bin/ffmpeg:
        /opt/local/lib/libavdevice.55.dylib (compatibility version 55.0.0, current version 55.11.100)
        /opt/local/lib/libavfilter.4.dylib (compatibility version 4.0.0, current version 4.3.100)
        /opt/local/lib/libavformat.55.dylib (compatibility version 55.0.0, current version 55.34.101)
        /opt/local/lib/libavresample.1.dylib (compatibility version 1.0.0, current version 1.2.0)
        /opt/local/lib/libavcodec.55.dylib (compatibility version 55.0.0, current version 55.52.102)
        /opt/local/lib/libpostproc.52.dylib (compatibility version 52.0.0, current version 52.3.100)
        /opt/local/lib/libswresample.0.dylib (compatibility version 0.0.0, current version 0.18.100)
        /opt/local/lib/libswscale.2.dylib (compatibility version 2.0.0, current version 2.5.101)
        /opt/local/lib/libavutil.52.dylib (compatibility version 52.0.0, current version 52.67.100)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.14.0)
        /System/Library/Frameworks/VideoDecodeAcceleration.framework/Versions/A/VideoDecodeAcceleration (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.8.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
        /opt/local/lib/libnettle.4.dylib (compatibility version 4.0.0, current version 4.7.0)
        /opt/local/lib/libhogweed.2.dylib (compatibility version 2.0.0, current version 2.5.0)
        /opt/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0)
        /opt/local/lib/libxvidcore.4.dylib (compatibility version 4.0.0, current version 4.3.0)
        /opt/local/lib/libx264.142.dylib (compatibility version 0.0.0, current version 0.0.0)
        /opt/local/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.10.0)
        /opt/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.7.0)
        /opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.1.0)
        /opt/local/lib/libtheoraenc.1.dylib (compatibility version 3.0.0, current version 3.2.0)
        /opt/local/lib/libtheoradec.1.dylib (compatibility version 3.0.0, current version 3.4.0)
        /opt/local/lib/libspeex.1.dylib (compatibility version 7.0.0, current version 7.0.0)
        /opt/local/lib/libschroedinger-1.0.0.dylib (compatibility version 12.0.0, current version 12.0.0)
        /opt/local/lib/libopus.0.dylib (compatibility version 6.0.0, current version 6.0.0)
        /opt/local/lib/libopenjpeg.1.dylib (compatibility version 7.0.0, current version 7.0.0)
        /opt/local/lib/libopencore-amrwb.0.dylib (compatibility version 1.0.0, current version 1.3.0)
        /opt/local/lib/libopencore-amrnb.0.dylib (compatibility version 1.0.0, current version 1.3.0)
        /opt/local/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libmodplug.1.dylib (compatibility version 2.0.0, current version 2.0.0)
        /opt/local/lib/libfreetype.6.dylib (compatibility version 18.0.0, current version 18.2.0)
        /opt/local/lib/libfdk-aac.0.dylib (compatibility version 1.0.0, current version 1.4.0)
        /opt/local/lib/libfaac.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libbluray.1.dylib (compatibility version 7.0.0, current version 7.0.0)
        /opt/local/lib/libass.5.dylib (compatibility version 6.0.0, current version 6.0.0)
        /opt/local/lib/libgnutls.28.dylib (compatibility version 50.0.0, current version 50.2.0)
        /opt/local/lib/libfontconfig.1.dylib (compatibility version 10.0.0, current version 10.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)

So, why is there a dependency to SDL at all?

Last edited 6 years ago by thomas.c.jansen@… (previous) (diff)

comment:7 Changed 6 years ago by dbevans (David B. Evans)

libsdl is used to implement the sdl outdev (output device). Per the documentation (${prefix}/share/doc/ffmpeg/ffmpeg-devices.html, Section 4.8)

This output device allows one to show a video stream in an SDL window.
To enable this output device you need libsdl installed on your system when configuring your build.

When libsdl is installed at build time, it is what lets you play video interactively using ffmpeg or ffplay or programmatically using the libavdevice API. It is the only outdev that is built by default by our ffmpeg port.

So from what we both have said above, you have successfully built ffmpeg without this device support (no libsdl or libsdl2). I assume that the project you are working on uses ffmpeg for decoding of video and libsdl2 for display?

However, to be sure you are getting what you want, removing the dependency on libsdl is not enough. Other ports that use libsdl can install it behind your back (90+ of these). To prevent building this device whether libsdl is installed or not, it should be explicitly disabled using the configure option

--disable-outdev=sdl

I think you have a legitimate situation here so if I gave you a way to disable the sdl outdev, recognizing that it means you won't be able to display videos in a SDL window using ffmpeg or ffplay, would that meet your needs?

comment:8 Changed 6 years ago by thomas.c.jansen@…

You are assuming correct. SDL1 is no longer supported, so I started off my project with SDL2, which then gave me a bunch of runtime link errors (due to duplicate symbols in libsdl and libsl2). That’s why I started naively digging in the ports file. But you are right, any other port that installs libsdl again would link it at run-time, it seems — thanks for pointing that out.

The option you are proposing seems to be exactly what I need. I am not interested in the libsdl-based ffmpeg output device, so disabling that explicitly would work.

comment:9 Changed 6 years ago by dbevans (David B. Evans)

Resolution: wontfix
Status: assignedclosed

Status:

In addition to the sdl outdev, the bundled utility ffplay also uses libSDL as its output device. However, after applying the following configuration items

--disable-outdev=sdl
--disable-ffplay

the sdl outdev and ffplay are, indeed, disabled but configure still detects libsdl if it is installed and the various libraries link with it.

So it appears that there is no way to definitively disable references to libsdl other than it not being installed. Since we can't guarantee this in MacPorts, I'm afraid there's not much further to be done without some major hacking of the code.

I'm attaching my working patch to the current ffmpeg port in case you'd like to play with this yourself on your local port.

I also note that a ticket has been opened upstream requesting SDL2 support.

Closing as won't fix for now.

Changed 6 years ago by dbevans (David B. Evans)

Attachment: patch-sdl-variant.diff added

Work in progress patch for a +sdl default variant (not fully effective)

comment:10 Changed 6 years ago by thomas.c.jansen@…

Thanks a bunch for all your help on this one. I’ll keep an eye on the FFMPEG ticket.

Note: See TracTickets for help on using tickets.