ffmpeg: issues updating to version 3.0

[dbevans (David B. Evans)]

FFmpeg 3.0 was released this past week. As with most FFmpeg major releases, this release is ABI-incompatible with the previous 2.8 release series and there are API changes as well. In particular, symbols deprecated during the 2.0 release series have now been removed. Ports that have not upgraded to the recommended replacements will break in 3.0.

See ​FFmpeg doc/APIchanges for details.

I've created a ​preliminary ffmpeg 3.0 port and have used it to test the various dependents. There are some issues and I'd like to get the majority of them fixed before unleasing ffmpeg 3.0 on the world!

The following dependent ports build without problems with ffmpeg 3.0 and will just need to be revbumped when ffmpeg 3.0 is committed due to the ABI break.

• aubio
• audacious-plugins
• audacity
• chromaprint
• gegl
• gegl-0.3
• gegl-devel
• kfilemetadata
• minidlna
• MP4Joiner
• mpd +ffmpeg
• mpv
• nepomuk-core
• opencv
• pianobar
• strigi

The following ports have various issues which I'm either attempting to address or am documenting in other tickets. If you are a maintainer of one of these ports, please take a look and/or work with the upstream developers to resolve any issues. Patch attached to update ffmpeg to version 3.0 for testing purposes.

• baresip (db.org:aeh) #50693 r146154
• cmus (g5pw openmaintainer) #51212 r148065
• ffmpegthumbs (nicos openmaintainer) r146293
• FreeRDP (nomaintainer) r145942
• goldendict (ryandesign openmaintainer) #51197 r148140
• gpac (nomaintainer) r145947
• libdlna (nomaintainer) r145993
• libextractor (ryandesign openmaintainer) #51198 r148141
• libquicktime-devel (jeremyhu) #51215 r147998
• mlt (dennedy.org:dan) #50696, r145945
• moc (martinvazquez.net:eu) #51207 r148143
• OpenSceneGraph (nomaintainer) #51223 r148093
• OpenSceneGraph-devel (nomaintainer) #51223 r148093
• pHash (workisfun.ru:ivan) #51213 r148144
• py-bob-io-video (idiap.ch:andre.anjos idiap.ch:laurent.el-shafey idiap.ch:tiago.pereira) #51221 r148336
• transcode (cogweb.net:lionteeth devans) r145941
• VLC (gmail.com:rjvbertin openmaintainer) #50697
• VLC-devel (nomaintainer) #50697 r148364
• wxsvg (mojca) r145950
• xine-lib (ryandesign openmaintainer) #51206 r148142
• xmms2 (nomaintainer) r146012
• yorick-av (thibaut openmaintainer) r145965

[dbevans (David B. Evans)]

Patch to update ffmpeg to version 3.0

[dbevans (David B. Evans)]

transcode fixed in r145941.

[ddennedy (Dan Dennedy)]

See ticket #50696 for mlt. It should work with ffmpeg 3.0.

[dbevans (David B. Evans)]

Replying to dan@…:

See ticket #50696 for mlt. It should work with ffmpeg 3.0.

Confirmed, thanks.

[dbevans (David B. Evans)]

FreeRDP fixed in r145942.

[RJVB (René Bertin)]

Which VLC port is seeing issues with ffmpeg 3?

I think that some thought could be given to possible ways in which MacPorts could provide multiple ABI-incompatible FFMpeg versions concurrently. FFMpeg isn't wholly incomparable to, say, Python, in the sense that a distribution system like MacPorts cannot really hope to force all "upstreams" to update before "they" feel ready, for the sole reason that MacPorts wants the latest and supposedly greatest and nothing else. As a distribution system it makes sense to ship the latest version of libraries that can support (most) all dependent ports, but that's not to say it shouldn't be possible to move on if only a handful of pivotal/popular ports remain stuck on an older version of a library.

On Linux the usual approach would be to provide a package with just the runtime binaries, but that isn't feasible when you also need to support building a package (port) from source. I have been looking at a comparable situation with KDE4 ports that I'd like to be co-installable with KF5 versions as long as those aren't proper successors that truly replace the older version. For those KDE4 ports I have introduced a kf5compat/legacy variant. The principle is simple: configure to install to a subprefix (or only the conflicting components if the build system is fine-grained enough). Install symlinks to the regular locations for the non-conflicting runtime components so that dependent software continues to find them, possibly even without a forced rebuild. Use of a variant isn't in any way required of course; a hypothetical port:ffmpeg-<currentABIversion> (port:ffmpeg-2.4-8?) could do this by default. Done right, this would allow -1 ports requiring the "legacy" version to keep functioning, and to build even with FFMpeg 3 installed (possible requiring patches to their build system to ensure the correct install is found; headers and link libraries). -2 ports that can will use the latest version -3 optionally ports from point 1) don't even require a rebuild.

Would point 1) require building FFMpeg 3 with a comparable install layout, so that dependent software cannot include the wrong header file by accident?

NB: for port maintainers for whom a port like FFMpeg is just another (central) dependency it could also be *very* appreciable if updates to that dependency don't oblige us to rebuild a huge bunch of large ports esp. if we depend on those ports for our "real work". That's where point 3 comes in; my motivation to look at issues with VLC will depend very much on the amount of overhead required before I can start doing that.

[dbevans (David B. Evans)]

Replying to rjvbertin@…:

Which VLC port is seeing issues with ffmpeg 3?

VLC @2.1.5_9. I believe the current stable upstream version is now 2.2.2.

I think that some thought could be given to possible ways in which MacPorts could provide multiple ABI-incompatible FFMpeg versions concurrently. FFMpeg isn't wholly incomparable to, say, Python, in the sense that a distribution system like MacPorts cannot really hope to force all "upstreams" to update before "they" feel ready, for the sole reason that MacPorts wants the latest and supposedly greatest and nothing else. As a distribution system it makes sense to ship the latest version of libraries that can support (most) all dependent ports, but that's not to say it shouldn't be possible to move on if only a handful of pivotal/popular ports remain stuck on an older version of a library.

On Linux the usual approach would be to provide a package with just the runtime binaries, but that isn't feasible when you also need to support building a package (port) from source. I have been looking at a comparable situation with KDE4 ports that I'd like to be co-installable with KF5 versions as long as those aren't proper successors that truly replace the older version. For those KDE4 ports I have introduced a kf5compat/legacy variant. The principle is simple: configure to install to a subprefix (or only the conflicting components if the build system is fine-grained enough). Install symlinks to the regular locations for the non-conflicting runtime components so that dependent software continues to find them, possibly even without a forced rebuild. Use of a variant isn't in any way required of course; a hypothetical port:ffmpeg-<currentABIversion> (port:ffmpeg-2.4-8?) could do this by default. Done right, this would allow -1 ports requiring the "legacy" version to keep functioning, and to build even with FFMpeg 3 installed (possible requiring patches to their build system to ensure the correct install is found; headers and link libraries). -2 ports that can will use the latest version -3 optionally ports from point 1) don't even require a rebuild.

Would point 1) require building FFMpeg 3 with a comparable install layout, so that dependent software cannot include the wrong header file by accident?

NB: for port maintainers for whom a port like FFMpeg is just another (central) dependency it could also be *very* appreciable if updates to that dependency don't oblige us to rebuild a huge bunch of large ports esp. if we depend on those ports for our "real work". That's where point 3 comes in; my motivation to look at issues with VLC will depend very much on the amount of overhead required before I can start doing that.

In this particular case, VLC doesn't build with ffmpeg 3.0 because it is using API that has been deprecated for some time (years) and has finally been dropped. The preferred API has existed equally long so if the VLC code is modified to use it instead then it will build with either current ffmpeg 2.8.6 or the new ffmpeg 3.0.0. Once all of ffmpeg's dependents get to this stage, it will be an easy matter to upgrade to ffmpeg 3.0.0 with minimal fuss. Only a revbump will be required due to the change in versioning of the various ffmpeg libraries.

With respect to support multiple versions of ffmpeg, we do. ffmpeg is the current stable version and remains so until a major update occurs (as in this case). ffmpeg-devel is the unstable version which contains the newest changes and may or may not be API/ABI compatible with ffmpeg. However, it allows those who wish to work on future compatibility to do so.

Since you're the maintainer of VLC, I really haven't looked too closely at the current MacPorts version other than to note that it fails to build with ffmpeg 3.0. I didn't really expect you to fix the issue (unless you want to) as that is really the job of the upstream developers but was hoping that you could help by raising the issue with them. Since the current version of VLC on MacPorts is out of date, it may just be an issue of bringing the port up to the latest stable version.

Will file a separate ticket with the details when I get a chance and you can take it from there. Thanks for your response.

[dbevans (David B. Evans)]

gpac updated to version 0.6.0 in r145947. The new version is now ffmpeg 3.0 compatible.

[RJVB (René Bertin)]

Replying to devans@…:

With respect to support multiple versions of ffmpeg, we do. ffmpeg is the current stable version and remains so until a major update occurs (as in this case). ffmpeg-devel is the unstable version which contains the newest changes and may or may not be API/ABI compatible with ffmpeg. However, it allows those who wish to work on future compatibility to do so.

Well, that's not exactly what I meant, and I doubt you missed that. foo and foo-devel ports are typically mutually exclusive alternatives that may or may not be true drop-in replacements for each other. I've had the opportunity to interact with FFMpeg devs a couple of years ago, and there were a couple of people there who were very much convinced of the well-foundedness of their choices. It wouldn't surprise me if some of the removed APIs never got a (workable) replacement. I cannot assess to what extent this is really the case and to what extent dependent ports might have good reasons to stick to the older API for the time being, or even if there are user-facing changes in the command line utilities that could make someone want to stick with the 2.8.6 version. I just think it's a win-win situation if you can set up ffmpeg and ffmpeg-legacy (or ffmpeg-previous or whatever) ports that can be installed concurrently with only some trivial hacking and insignificant/negligible maintenance overhead.

Since you're the maintainer of VLC, I really haven't looked too closely at the current MacPorts version other than to note that it fails to build with ffmpeg 3.0. I didn't really expect you to fix the issue (unless you want to) as that is really the job of the upstream developers but was hoping that you could help by raising the issue with them. Since the current version of VLC on MacPorts is out of date, it may just be an issue of bringing the port up to the latest stable version.

This has come up before: I'm listed as a maintainer because I submitted a port update to VLC 2.2.1 ; it was never my intention to maintain the outdated version my port was supposed to replace, esp. since my main interest is in libVLC . Not the VLC app itself, which I think one best installs from the official installer, also given its flaky build system and Videolan's attitude towards MacPorts. I'll try to find some time to bump my port to 2.2.2 though so you can check whether it supports FFMpeg 3.0 .

I'll also have to check my proposed Audacity port but IINM that project ships a compatible version FFMpeg that we could allow it to use if push comes to shove.

[dbevans (David B. Evans)]

Replying to devans@…:

Replying to rjvbertin@…:

Which VLC port is seeing issues with ffmpeg 3?

Will file a separate ticket with the details when I get a chance and you can take it from there. Thanks for your response.

VLC build issue reported in #50697.

[mojca (Mojca Miklavec)]

wxsvg fixed in r145950.

I didn't find any bug tracker, so I wrote to their ​support forum. Basic compatibility is actually already there (fixed one day after the latest release), but I also patched another deprecated function reported by the compiler.

[RJVB (René Bertin)]

Here's another issue: using the +libx265 variant gives the following configure error:

ERROR: libx265 version must be >= 68.

[dbevans (David B. Evans)]

Replying to rjvbertin@…:

Here's another issue: using the +libx265 variant gives the following configure error:

ERROR: libx265 version must be >= 68.

Port x265 needs to be updated (#50600).

[paumard]

yorick-av fixed in r145965

[ddennedy (Dan Dennedy)]

Cc Me!

[dbevans (David B. Evans)]

libdlna fixed in r145993.

[mojca (Mojca Miklavec)]

The latest release of xmms2 is more than 4 years old (from 2011). The problems have most likely been fixed in the devel version (see ​https://git.xmms2.org/xmms2/xmms2-devel/), but I don't see any sign of a new release. We should probably open a separate ticket for that.

[NicosPavlov]

Unfortunately ffmpegthumbs is not straightforward, and there has been nearly no development on the repo these past few years. I filed a bug report at KDE ​https://bugs.kde.org/show_bug.cgi?id=359752.

If required, it could be possible to patch most of the issues which are only symbols replacement, but it would also be required to remove video deinterlacing, which requires more changes to the code.

[RJVB (René Bertin)]

And beware of subtle regressions that only show up as "something no longer working" in practice, as I experienced after getting (forcing) VLC to build against FFMpeg 3.0.0 .

FWIW, I filed a separate ticket with a PoC set of FFMpeg port modifications that should make it easier to support multiple installed FFMpeg versions; dependents that are locked into the previous ABI compatibility version only need to be patched to search for suffixed pkg-config data for FFMpeg (if they're written correctly and do not already provide a way to indicate how to locate these dependencies).

[RJVB (René Bertin)]

Replying to mojca@…:

I tried to fetch from GIT

But the port needs more effort than just that:

:info:configure src/lib/s4: b46e5975 (not initialized)
:info:configure The submodule 'src/lib/s4' is not initialized. Run `git submodule update --init` and try again.

In my experience it isn't trivial at all to fetch multi-module git repos using MacPorts "base". You'll probably need to roll your own fetch (extension). Maybe you can get some inspiration from my approach in my own qt5-creator-devel subport: ​https://github.com/RJVB/macstrop/blob/master/devel/qt5-creator/Portfile .

[dbevans (David B. Evans)]

Replying to mojca@…:

The latest release of xmms2 is more than 4 years old (from 2011). The problems have most likely been fixed in the devel version (see ​https://git.xmms2.org/xmms2/xmms2-devel/), but I don't see any sign of a new release. We should probably open a separate ticket for that.

I tried to fetch from GIT

Portfile

@@ -5 +5 @@
 PortGroup               waf 1.0
 
 name                    xmms2
-version                 0.8DrO_o
-revision                10
 categories              audio
 # Mostly LGPL, some plugins and clients are GPL
 license                 LGPL-2.1+ GPL-2+ GPL-2
@@ -13 +11 @@
 maintainers             nomaintainer
 homepage                http://xmms2.org/
 platforms               darwin
-master_sites            sourceforge:project/xmms2/xmms2/[regsub {^([0-9.]+)} ${version} {\1%20}]
-use_bzip2               yes
 
+fetch.type              git
+git.url                 git://git.xmms2.org/xmms2/xmms2-devel.git
+git.branch              ece0baf0f56f705bdf9a3d174ac170d194bfe0b0
+version                 1.8.11
+
 description             CrossPlatform Music Multiplexer System
 long_description        Next generation audio player of XMMS
 
-checksums               rmd160  35513d7eddd5f79146cb8aa5c6c0bb35369619ec \
-                        sha256  c77e41e7bd5788889d5a2f78331ca8c748b8721bd2e59f36c36ad4c7cae8694a
-
 depends_build-append    port:pkgconfig
 
 depends_lib             path:lib/pkgconfig/glib-2.0.pc:glib2 \

But the port needs more effort than just that:

:info:configure src/lib/s4: b46e5975 (not initialized)
:info:configure The submodule 'src/lib/s4' is not initialized. Run `git submodule update --init` and try again.

As you say, it looks like the hard part of updating this port (moving from avcodec_decode_audio3 to avcodec_decode_audio4 which involves moving from fixed buffers to AVFrames) has been already done upstream as part of a cleanup of deprecations. The changes are very localized to a specific plugin, so I'm working on just back porting the appropriate changes (as patches) along with any residual cleanup necessary.

This should fix the ffmpeg compatibility issues without getting into a bigger can of worms having to do with the updating the program in its entirety. Since there hasn't been a new release in a long time it would probably be wise to confer with the upstream developers to see if they would be willing to make one that they think is relatively stable.

[mojca (Mojca Miklavec)]

Replying to rjvbertin@…:

Replying to mojca@…:

I tried to fetch from GIT. But the port needs more effort than just that.

In my experience it isn't trivial at all to fetch multi-module git repos using MacPorts "base". You'll probably need to roll your own fetch (extension). Maybe you can get some inspiration from my approach in my own qt5-creator-devel subport: ​https://github.com/RJVB/macstrop/blob/master/devel/qt5-creator/Portfile.

I filed #50708. If David comes up with a patch, there's even no need to deal with git for this particular port anyway.

[dbevans (David B. Evans)]

xmms2 avcodec plugin patched through upstream commit fc66249 (2014-01-29) for ffmpeg-3.0 compatibility in r146012. Builds using both ffmpeg 2.8.6 and 3.0 and works for me during cursory testing using various ffmpeg encoded audio streams. If you're of a mind to do so, please give it a try and let me know if you find any glitches. Thanks.

[mojca (Mojca Miklavec)]

Replying to devans@…:

xmms2 avcodec plugin patched through upstream commit fc66249 (2014-01-29) for ffmpeg-3.0 compatibility in r146012. Builds using both ffmpeg 2.8.6 and 3.0 and works for me during cursory testing using various ffmpeg encoded audio streams. If you're of a mind to do so, please give it a try and let me know if you find any glitches. Thanks.

Thanks a lot. I have no clue yet about how to test the program.

Sorry for being off-topic, but: is the code seriously using "goto"??? I haven't seen that since the last century at least.

[RJVB (René Bertin)]

[OT] Heh, have you ever looked at code using some of Apple's older APIs, like the QuickTime API? That API is full of simple calls of which you need a whole series in order to achieve certain operations that would be functional building blocks in an OO approach. Most all of those functions return NO_ERR (0) in case of success, so unless you like to write insanely nested code or to repeat each and every cleanup action at each checkpoint, you'll find yourself using a goto bail; ...

I don't think there's anything particularly wrong with that either (a good optimiser would probably generate a very similar control flow). OT

[dbevans (David B. Evans)]

ports audacity, gegl-devel build with either ffmpeg 2.8.6 or ffmpeg 3.0.

[mojca (Mojca Miklavec)]

Given that versions 2.8 and 3.0 are not compatible and switching between one and the other leaves the ports in a broken state, wouldn't

path:lib/libavcodec.dylib:ffmpeg

better be expressed with a temporary variant like +ffmpeg_devel replacing ffmpeg with ffmpeg-devel as a dependency? Using ffmpeg-devel requires an "experienced developer" (someone who knows what he is doing because all dependent port have to be [re]compiled from source when switching back and forth) and is equally problematic to simply upgrading ffmpeg to version 3.0.

(Does the port list in this ticket also need an update?)

[dbevans (David B. Evans)]

Replying to mojca@…:

Given that versions 2.8 and 3.0 are not compatible and switching between one and the other leaves the ports in a broken state, wouldn't

path:lib/libavcodec.dylib:ffmpeg

better be expressed with a temporary variant like +ffmpeg_devel replacing ffmpeg with ffmpeg-devel as a dependency? Using ffmpeg-devel requires an "experienced developer" (someone who knows what he is doing because all dependent port have to be [re]compiled from source when switching back and forth) and is equally problematic to simply upgrading ffmpeg to version 3.0.

No, the point here is to allow either ffmpeg or ffmpeg-devel to satisfy the dependency, default is ffmpeg. This is the normal way of doing this. All dependencies for ffmpeg should be of this form. See dependencies for glib2 as another common example.

(Does the port list in this ticket also need an update?)

It has been. These two ports only need a revbump after moving to ffmpeg 3.0.

[mojca (Mojca Miklavec)]

I upgraded VLC to version 2.2.2 (#49051, r146098). Given René's earlier comments I didn't check compatibility with ffmpeg 3.0 (assuming it isn't functional just yet).

(The VLC-devel port might be at an even older version than VLC then, but it has a different set of dependencies etc. The devel port should probably switch to version 3 by now if there was anyone interested in working on it.)

[RJVB (René Bertin)]

I actually tried to do that at some point, but found little reason to pursue it (and may even have come across issues getting more recent commits to build, I cannot remember). In any case the 2.2.2 port should provide a better stepping stone than the current vlc-devel port.

[dbevans (David B. Evans)]

mpd +ffmpeg is compatible with ffmpeg 3.0

[dbevans (David B. Evans)]

baresip fixed in r146154.

[dbevans (David B. Evans)]

Port field restored to original list for indexing purposes. This only means that the ticket pertains to these ports, not whether they have been fixed or not. That information is recorded in the updated description.

[NicosPavlov]

I committed patches to have the code comply with ffmpeg 3.0 API in r146293. However, as this implies a regression, I kept the changes in a variant called ffmpeg3 for now, which can be activated in case ffmpeg 3 is committed. The changes will be improved if a better solution comes from upstream.

[dbevans (David B. Evans)]

Replying to nicos@…:

I committed patches to have the code comply with ffmpeg 3.0 API in r146293. However, as this implies a regression, I kept the changes in a variant called ffmpeg3 for now, which can be activated in case ffmpeg 3 is committed. The changes will be improved if a better solution comes from upstream.

I haven't tested this yet, but your deprecations patch should be compatible with both the current ffmpeg and ffmpeg 3.0 so I would take that one out of the variant.

It's the deinterlace patch that's the issue/regression. To be compatible with both versions the functionality of avpicture_deinterlace() needs to be re-written to use the yadif filter via the libavfilter API. ffmpeg provides an example of how to use this API in /opt/local/share/ffmpeg/examples/filtering_video.c. Hopefully, this is what the upstream developers will do.

Are they aware of the issue?

[NicosPavlov]

Replying to devans@…:

It's the deinterlace patch that's the issue/regression. To be compatible with both versions the functionality of avpicture_deinterlace() needs to be re-written to use the yadif filter via the libavfilter API. ffmpeg provides an example of how to use this API in /opt/local/share/ffmpeg/examples/filtering_video.c. Hopefully, this is what the upstream developers will do.

Indeed. There is a patch proposed in the KDE review board (​https://git.reviewboard.kde.org/r/126992/), but the patch apparently has its own issues at present, and is meant for the Qt5 version, so that it would need porting for use here, so that I did not include it for now.

Are they aware of the issue?

Yes. I also reported the issue in the bug tracker (see comment:19).

[mopihopi]

Cc Me!

[dbevans (David B. Evans)]

Fix for goldendict proposed in #51197.

[dbevans (David B. Evans)]

ffmpeg has now been updated to version 3.0.1 so I'd like to get these issues resolved so that update can be committed. With that in mind, I'm going to start pushing on the ports that remain broken with version 3.0+. If you maintain one of these ports please check to see if your upstream developers have dealt with the issue yet or at least give them a push. Thanks.

[dbevans (David B. Evans)]

Patch to update ffmpeg to version 3.0.1 for testing

[dbevans (David B. Evans)]

Fix for libextractor proposed in #51198.

[RJVB (René Bertin)]

Replying to devans@…:

If you maintain one of these ports please check to see if your upstream developers have dealt with the issue yet or at least give them a push. Thanks.

comment:ticket:50697:9

[dbevans (David B. Evans)]

Fix for xine-lib proposed in #51206, moc in #51207.

[dbevans (David B. Evans)]

Fix for cmus proposed in #51212, pHash in #51213.

[dbevans (David B. Evans)]

Fix for libquicktime-devel proposed in #51215, committed in r147998.

[dbevans (David B. Evans)]

Fix for py-bob-io-video proposed in #51221.

[mkae (Marko Käning)]

​This should help with OpenSceneGraph, where Ben Woods supplied a patch from ArchLinux. Thanks!

[dbevans (David B. Evans)]

Fixes for cmus committed in r148065, contributed patch for OpenSceneGraph, OpenSceneGraph-devel committed in r148093. Thanks.

[dbevans (David B. Evans)]

Fixes committed:

goldendict in r148140
libextractor in r148141
xinelib in r148142
moc in r148143
pHash in r148144
py-bob-io-video in r148336

[dbevans (David B. Evans)]

VLC-devel declared obsolete for now replaced by VLC in r148364. See #50697.

[dbevans (David B. Evans)]

ffmpeg updated to version 3.0.2 in r148824
most dependents rebuilt with version 3.0.2 in r148825
ffmpegthumbs rebuilt using +ffmpeg3 as default variant in r148826
gegl-devel updated to latest git master using 3.0.2 in r148827
MP4Joiner additional build fix committed in r148836
synfig rebuilt with version 3.0.2 in r148842

All dependents now rebuilt successfully except VLC (#50697)

[dbevans (David B. Evans)]

Closing as fixed. VLC issues continue in #50697.