Opened 8 years ago

Closed 8 years ago

#50694 closed defect (fixed)

ffmpeg: issues updating to version 3.0

Reported by: dbevans (David B. Evans) Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: alfredh (Alfred E. Heggestad), aguynamedryan+pianobar@…, eu@…, Ionic (Mihai Moldovan), toy, jeremyhu (Jeremy Huddleston Sequoia), kurthindenburg (Kurt Hindenburg), Liontooth (David Liontooth), mkae (Marko Käning), mojca (Mojca Miklavec), NicosPavlov, ranauei@…, RJVB (René Bertin), ryandesign (Ryan Carsten Schmidt), stromnov (Andrey Stromnov), paumard, mopihopi
Port: baresip cmus ffmpegthumbs FreeRDP goldendict gpac libdlna libextractor libquicktime-devel mlt moc OpenSceneGraph pHash py27-bob-io-video transcode VLC VLC-devel wxsvg xine-lib xmms2 yorick-av

Description (last modified by 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.

Attachments (2)

patch-ffmpeg-3.0.diff (1.2 KB) - added by dbevans (David B. Evans) 8 years ago.
Patch to update ffmpeg to version 3.0
patch-ffmpeg-3.0.1.diff (1.2 KB) - added by dbevans (David B. Evans) 8 years ago.
Patch to update ffmpeg to version 3.0.1 for testing

Download all attachments as: .zip

Change History (59)

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

Attachment: patch-ffmpeg-3.0.diff added

Patch to update ffmpeg to version 3.0

comment:1 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

comment:2 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

transcode fixed in r145941.

comment:3 Changed 8 years ago by ddennedy (Dan Dennedy)

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

comment:4 in reply to:  3 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

Replying to dan@…:

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

Confirmed, thanks.

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

Description: modified (diff)

FreeRDP fixed in r145942.

comment:6 Changed 8 years ago by 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.

comment:7 in reply to:  6 ; Changed 8 years ago by 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.

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

Description: modified (diff)

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

comment:9 in reply to:  7 Changed 8 years ago by 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.

comment:10 in reply to:  7 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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.

comment:11 Changed 8 years ago by mojca (Mojca Miklavec)

Description: modified (diff)
Version: 2.3.4

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.

comment:12 Changed 8 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

comment:13 Changed 8 years ago by RJVB (René Bertin)

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

ERROR: libx265 version must be >= 68.

comment:14 in reply to:  13 Changed 8 years ago by 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).

comment:15 Changed 8 years ago by paumard

Description: modified (diff)

yorick-av fixed in r145965

comment:16 Changed 8 years ago by ddennedy (Dan Dennedy)

Cc: dan@… removed

Cc Me!

comment:17 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

libdlna fixed in r145993.

comment:18 Changed 8 years ago by 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.

I tried to fetch from GIT

  • Portfile

     
    55PortGroup               waf 1.0
    66
    77name                    xmms2
    8 version                 0.8DrO_o
    9 revision                10
    108categories              audio
    119# Mostly LGPL, some plugins and clients are GPL
    1210license                 LGPL-2.1+ GPL-2+ GPL-2
     
    1311maintainers             nomaintainer
    1412homepage                http://xmms2.org/
    1513platforms               darwin
    16 master_sites            sourceforge:project/xmms2/xmms2/[regsub {^([0-9.]+)} ${version} {\1%20}]
    17 use_bzip2               yes
    1814
     15fetch.type              git
     16git.url                 git://git.xmms2.org/xmms2/xmms2-devel.git
     17git.branch              ece0baf0f56f705bdf9a3d174ac170d194bfe0b0
     18version                 1.8.11
     19
    1920description             CrossPlatform Music Multiplexer System
    2021long_description        Next generation audio player of XMMS
    2122
    22 checksums               rmd160  35513d7eddd5f79146cb8aa5c6c0bb35369619ec \
    23                         sha256  c77e41e7bd5788889d5a2f78331ca8c748b8721bd2e59f36c36ad4c7cae8694a
    24 
    2523depends_build-append    port:pkgconfig
    2624
    2725depends_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.
Last edited 8 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:19 Changed 8 years ago by 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.

comment:20 Changed 8 years ago by 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).

comment:21 in reply to:  18 ; Changed 8 years ago by 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 .

comment:22 in reply to:  18 Changed 8 years ago by 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

     
    55PortGroup               waf 1.0
    66
    77name                    xmms2
    8 version                 0.8DrO_o
    9 revision                10
    108categories              audio
    119# Mostly LGPL, some plugins and clients are GPL
    1210license                 LGPL-2.1+ GPL-2+ GPL-2
     
    1311maintainers             nomaintainer
    1412homepage                http://xmms2.org/
    1513platforms               darwin
    16 master_sites            sourceforge:project/xmms2/xmms2/[regsub {^([0-9.]+)} ${version} {\1%20}]
    17 use_bzip2               yes
    1814
     15fetch.type              git
     16git.url                 git://git.xmms2.org/xmms2/xmms2-devel.git
     17git.branch              ece0baf0f56f705bdf9a3d174ac170d194bfe0b0
     18version                 1.8.11
     19
    1920description             CrossPlatform Music Multiplexer System
    2021long_description        Next generation audio player of XMMS
    2122
    22 checksums               rmd160  35513d7eddd5f79146cb8aa5c6c0bb35369619ec \
    23                         sha256  c77e41e7bd5788889d5a2f78331ca8c748b8721bd2e59f36c36ad4c7cae8694a
    24 
    2523depends_build-append    port:pkgconfig
    2624
    2725depends_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.

comment:23 in reply to:  21 Changed 8 years ago by 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.

comment:24 Changed 8 years ago by 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.

comment:25 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

comment:26 in reply to:  24 Changed 8 years ago by 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.

comment:27 Changed 8 years ago by 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

comment:28 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

comment:29 Changed 8 years ago by 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?)

comment:30 in reply to:  29 Changed 8 years ago by 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.

comment:31 Changed 8 years ago by 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.)

comment:32 Changed 8 years ago by 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.

comment:33 Changed 8 years ago by mojca (Mojca Miklavec)

Description: modified (diff)
Port: VLC-devel added; FreeRDP gpac libdlna mlt transcode wxsvg xmms2 yorick-av removed

comment:34 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

mpd +ffmpeg is compatible with ffmpeg 3.0

comment:35 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

baresip fixed in r146154.

comment:36 Changed 8 years ago by dbevans (David B. Evans)

Port: FreeRDP gpac libdlna mlt transcode wxsvg xmms2 yorick-av added

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.

comment:37 Changed 8 years ago by 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.

comment:38 Changed 8 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

comment:39 in reply to:  37 ; Changed 8 years ago by 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?

comment:40 in reply to:  39 Changed 8 years ago by 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).

comment:41 Changed 8 years ago by mopihopi

Cc: mopihopi@… added

Cc Me!

comment:42 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

Fix for goldendict proposed in #51197.

comment:43 Changed 8 years ago by 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.

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

Attachment: patch-ffmpeg-3.0.1.diff added

Patch to update ffmpeg to version 3.0.1 for testing

comment:44 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

Fix for libextractor proposed in #51198.

comment:45 in reply to:  43 Changed 8 years ago by 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

Last edited 8 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:46 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

comment:47 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

comment:48 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

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

comment:49 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

comment:50 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

comment:51 Changed 8 years ago by mkae (Marko Käning)

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

comment:52 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

comment:53 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

Fixes committed:

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

comment:54 Changed 8 years ago by dbevans (David B. Evans)

Description: modified (diff)

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

comment:55 Changed 8 years ago by g5pw (Aljaž Srebrnič)

Cc: g5pw@… removed

comment:56 Changed 8 years ago by 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)

comment:57 Changed 8 years ago by dbevans (David B. Evans)

Resolution: fixed
Status: newclosed

Closing as fixed. VLC issues continue in #50697.

Note: See TracTickets for help on using tickets.