[MacPorts] #50694: ffmpeg: issues updating to version 3.0

[MacPorts]

#50694: ffmpeg: issues updating to version 3.0
-------------------------------------------------+-------------------------
  Reporter:  devans@…                            |      Owner:  devans@…
      Type:  defect                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:  2.3.4
Resolution:                                      |   Keywords:
      Port:  baresip cmus ffmpegthumbs FreeRDP   |
  goldendict gpac libdlna libextractor           |
  libquicktime-devel mlt moc OpenSceneGraph      |
  pHash py27-bob-io-video transcode VLC wxsvg    |
  xine-lib xmms2 yorick-av                       |
-------------------------------------------------+-------------------------

Comment (by devans@…):

 Replying to [comment:6 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/50694#comment:7>
MacPorts <https://www.macports.org/>
Ports system for OS X