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
• chromaprint
• gegl
• gegl-0.3
• kfilemetadata
• minidlna
• MP4Joiner
• 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
• cmus (g5pw openmaintainer)
• ffmpegthumbs (nicos openmaintainer)
• FreeRDP (nomaintainer) r145942
• goldendict (ryandesign openmaintainer)
• gpac (nomaintainer) r145947
• libdlna (nomaintainer)
• libextractor (ryandesign openmaintainer)
• libquicktime-devel (jeremyhu)
• mlt (dennedy.org:dan) #50696
• moc (martinvazquez.net:eu)
• OpenSceneGraph (nomaintainer)
• pHash (workisfun.ru:ivan)
• py27-bob-io-video (idiap.ch:andre.anjos idiap.ch:laurent.el-shafey idiap.ch:tiago.pereira)
• transcode (cogweb.net:lionteeth devans) r145941
• VLC (gmail.com:rjvbertin openmaintainer) #50697
• VLC-devel (nomaintainer)
• wxsvg (mojca) r145950
• xine-lib (ryandesign openmaintainer)
• xmms2 (nomaintainer)
• yorick-av (thibaut openmaintainer)

[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.