ffmpeg: update to 6.x

[janngobble]

Macports on 4.4.2, ffmpeg currently GM release is at 6.0.

[jmroot (Joshua Root)]

Livecheck works fine here, FWIW:

% port livecheck ffmpeg   
ffmpeg seems to have been updated (port version: 4.4.2, new version: 5.1)

[mascguy (Christopher Nielsen)]

The latest release is available via port ffmpeg-upstream. However, we haven't updated ffmpeg yet, as v5.x breaks a number of dependent ports.

You're welcome to try it though, via the following steps. But bear in mind that MacPorts will need to rebuild ports dependent on it, and you may see build failures for some of those. So caveat emptor!

$ sudo port -f deactivate ffmpeg
$ sudo port -N install ffmpeg-upstream

[Christopher Nielsen <mascguy@…>]

In b85e94093d61f6449e5eb779ee51d6c927e6e691/macports-ports (master):

ffmpeg-upstream: segregate to co-exist with ffmpeg/ffmpeg-devel
See: #65623

[mascguy (Christopher Nielsen)]

As an intermediate step, port ffmpeg-upstream has been segregated, so that it can now be installed alongside ffmpeg. And as a starting point, binaries are symlinked in ${prefix}/bin:

  /opt/local/bin/ffmpeg6
  /opt/local/bin/ffplay6
  /opt/local/bin/ffprobe6

There's still more work to be done - such as symlinking the manpages and such - but making progress.

[mohd-akram (Mohamed Akram)]

What are the issues with updating to FFmpeg 6? Perhaps there should be an ffmpeg4 port that lives in libexec for ports that require an old version, and otherwise update to 6.

[mascguy (Christopher Nielsen)]

Replying to mohd-akram:

What are the issues with updating to FFmpeg 6? Perhaps there should be an ffmpeg4 port that lives in libexec for ports that require an old version, and otherwise update to 6.

Upstream has made breaking API changes, such that we can't simply update the default ffmpeg port to version 5.x or 6.x. But yes, the longer-term plan is to create an ffmpeg4 port, and rename ffmpeg-upstream to ffmpeg6. Followed by updating all dependents to build with the appropriate one.

But that's going to take some time.

[mohd-akram (Mohamed Akram)]

Strangely, I didn't get a notification for your response. Perhaps we should assemble a list of ports that depend on ffmpeg, and tick off the ones that support version 6 upstream, linking to relevant PRs/commits. This way we have an idea of the scope of the compatibility issues at least. Just to get it started if there is no such list yet - port echo depends:ffmpeg | grep -v '^py[0-9]' returns:

• aubio ​Supported
• audacious-plugins ​Supported
• audacity ​Supported
• audacity-devel ​Supported
• audacity-legacy
• av1an ​Supported
• baresip
• blender [Supported]
• chromaprint
• cmus ​Pending
• dosbox-x
• dvbcut
• ffmpegthumbnailer
• ffmpegthumbs
• ffms2
• FreeRDP ​Supported
• geeqie
• gegl ​Builds
• gegl-0.3
• gegl-devel ​Builds
• gmic
• gmic-clib
• gmic-gimp
• gmic-lib
• gmic-qt
• goldendict
• gpac ​Supported
• kdemultimedia4
• kfilemetadata
• libdlna
• libextractor
• libopenshot
• libpiano
• libquicktime
• libquicktime-devel
• libvideogfx
• libVLC2
• mat2
• mediatomb
• mlt ​Supported
• mlt-qt5
• moc
• MP4Joiner
• mpv ​Supported
• musikcube ​Supported
• nepomuk-core
• netgen ​Supported
• notcurses
• octave-video
• opencv3
• opencv3-devel
• opencv4 ​Supported
• opencv4-devel ​Supported
• openimageio
• OpenSceneGraph ​Broken
• OpenSceneGraph-devel ​Broken
• Pangolin
• paraview
• pHash
• pianobar ​Supported
• py-imageio-ffmpeg
• qt5-qtwebengine
• qt6-qtmultimedia
• qt6-qtwebengine
• qt513-qtwebengine
• ReadyMedia [Supported]
• scrcpy
• SDRangel
• streamlink [CLI use]
• strigi
• synfig
• tovid
• transcode
• tumbler
• unpaper
• vapoursynth
• VLC2
• wxsvg
• xine-lib
• xmms2
• yorick-av ​Supported

Run Dependencies, likely work:

• beets
• beets-devel
• freac
• get_iplayer
• impressive
• reddsaver
• shenidam
• vcs
• vhs
• youtube-dl
• yt-dlp

[mohd-akram (Mohamed Akram)]

I've updated the list. Most ports are likely to build. Other package managers have also moved to updated FFmpeg versions, so it should be doable at this point. I've created some tickets for ports that require an update, so we can likely start with updating those.

[mascguy (Christopher Nielsen)]

Replying to mohd-akram:

I've updated the list. Most ports are likely to build. Other package managers have also moved to updated FFmpeg versions, so it should be doable at this point. I've created some tickets for ports that require an update, so we can likely start with updating those.

If you'd like folks to also migrate to ffmpeg6, you'll want to explicitly mention that in each ticket.

[mohd-akram (Mohamed Akram)]

My hope is that we can update ffmpeg to 6.0 directly, and make broken ports use ffmpeg4. How would one use ffmpeg6 or (the eventual) ffmpeg4 in a port? Is it a matter of updating configure.cppflags and configure.ldflags?

[mascguy (Christopher Nielsen)]

Replying to mohd-akram:

My hope is that we can update ffmpeg to 6.0 directly, and make broken ports use ffmpeg4.

I don't think that's feasible at this point, as there's far too great a chance that we'll cause significant breakage somewhere. Perhaps in the future, but I'm certainly not prepared to tackle that at this point. Simply too much potential mayhem, without much upside.

How would one use ffmpeg6 or (the eventual) ffmpeg4 in a port? Is it a matter of updating configure.cppflags and configure.ldflags?

Hopefully most can be updated to include the pkgconfig path for the desired version of ffmpeg, via logic similar to the following:

set ffmpeg_ver 6
configure.pkg_config_path ${prefix}/libexec/ffmpeg${ffmpeg_ver}/lib/pkgconfig

We'll also want to segregate ffmpeg too, via a new port ffmpeg4. Otherwise we'll have to deal with reversing the header and lib search order, which can be a royal pain.

Ultimately we'll get there, but it's going to be a big undertaking. (And a gradual migration will be far less painful to our users and members.) So your patience is appreciated!

[mascguy (Christopher Nielsen)]

Replying to mascguy:

How would one use ffmpeg6 or (the eventual) ffmpeg4 in a port? Is it a matter of updating configure.cppflags and configure.ldflags?

Hopefully most can be updated to include the pkgconfig path for the desired version of ffmpeg, via logic similar to the following:

set ffmpeg_ver 6
configure.pkg_config_path ${prefix}/libexec/ffmpeg${ffmpeg_ver}/lib/pkgconfig

p.s. To reduce the maintenance pain, I'm also planning to introduce a new ffmpeg portgroup - similar to our pg for boost - to ease the pain. That will also take time, but again, we'll get there.

[Tobias Pyndt Steinmann <tps@…>]

In 342e19a5a279ff77184962370898d14e39a77912/macports-ports (master):

ffmpeg6: Update ffmpeg6 to version to 6.1

Version 6.1 of ffmpeg introduces a fix for building on macOS 10.5 which
breaks our audiotoolboxenc.c patch. As the macOS version check is
different and our Portfile specifically mentions that AudioToolbox
requires 10.7+, I have updated the patch to the new upstream source
file.

Upstream commit:
​https://github.com/FFmpeg/FFmpeg/commit/35342dc390781f310daa53e6c850285863ab5829

Trac Ticket regarding ffmpeg 6.x:
#65623

[badger200]

@tobias : 6.1 breaks videotoolboxenc.c due to

libavcodec/videotoolboxenc.c:1185:40: error: use of undeclared identifier 'kVTCompressionPropertyKey_EncoderID';

Which is 10.13 specific. I’m building on 10.9. 6.0 is built and installed currently.

[janngobble]

Replying to badger200:

@tobias : 6.1 breaks videotoolboxenc.c due to

libavcodec/videotoolboxenc.c:1185:40: error: use of undeclared identifier 'kVTCompressionPropertyKey_EncoderID';

Which is 10.13 specific. I’m building on 10.9. 6.0 is built and installed currently.

see: ​https://trac.macports.org/ticket/68720

In essence, kVTCompressionPropertyKey_EncoderID was introduced in 10.13. So, if there's no version test when using using kVTCompressionPropertyKey_EncoderID then it will break.

[mohd-akram (Mohamed Akram)]

Any update on this? FFmpeg 7 has been released.

​https://ffmpeg.org/download.html#release_7.0

[mascguy (Christopher Nielsen)]

Replying to janngobble:

Replying to badger200:

@tobias : 6.1 breaks videotoolboxenc.c due to

libavcodec/videotoolboxenc.c:1185:40: error: use of undeclared identifier 'kVTCompressionPropertyKey_EncoderID';

Which is 10.13 specific. I’m building on 10.9. 6.0 is built and installed currently.

see: ​https://trac.macports.org/ticket/68720

In essence, kVTCompressionPropertyKey_EncoderID was introduced in 10.13. So, if there's no version test when using using kVTCompressionPropertyKey_EncoderID then it will break.

FYI, this was fixed a few days ago, per the following: comment:10:issue:68720

[i0ntempest]

I already migrated two of my ports (av1an and mpv) to link with ffmpeg v6. mpv would crash in certain cases if linked with ffmpeg v4, which I think could be a sign of devs ditching old versions of ffmpeg (at least not explicily targeting/testing).

I know this will be a huge undertaking but I really would like to see this migration process starts soon, especially now v7 is released.

[andlabs (Pietro Gagliardi)]

FWIW I recently ran across an issue where some YouTube videos download in a format not supported by ffmpeg 4. The yt-dlp maintainers are expecting everyone to be on 6.1.1 at least. Perhaps that port can be moved to depend on ffmpeg 6? ​https://github.com/yt-dlp/yt-dlp/issues/8641

In the meantime you can use --ffmpeg-location /opt/local/bin/ffmpeg6. Unfortunately 6.1.1 also doesn't work for the video I'm trying, though; will report upstream if ffmpeg 7 can't either... EDIT The video I'm trying *does* work in ffmpeg 7, so I will repeat the request to bump ffmpeg6. I did have to patch libavdevice/avfoundation.m due to conflicting type names on 10.12 with Xcode 9 (change the parameter of getDevicesWithMediaType() on line 765 to be of type NSString *).