ffmpeg: switch to ffmpeg_5

[vs49688]

Motivation for this change

Switching to FFmpeg 5.0

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[vs49688]

ping on this?

[trofi]

Looks like it broke at least mplayer, gst_all_1.gst-libav, ffmpegthumbnailer and openjfx15 in staging and staging-next. Failure example: https://hydra.nixos.org/build/166554514

../../../plugins/av/audiodecoder.c:719:15: error: implicit declaration of function 'avcodec_decode_audio4'; did you mean 'avcodec_decode_subtitle2'? [-Werror=implicit-function-declaration]
  719 |     num_dec = avcodec_decode_audio4(base->context, base->frame, &got_frame, &decoder->packet);
      |               ^~~~~~~~~~~~~~~~~~~~~

[vs49688]

In the case of ffmpegthumbnailer, I removed all the deprecated functions when I ported it to use ffmpeg4, but upstream hasn't tagged a release since before then. I'll look at the others and submit a PR in a bit.

[vs49688]

Submitted for ffmpegthumbnailer and mplayer: #158226

[vcunat]

Also qtwebengine looked like caused by ffmpeg: https://hydra.nixos.org/build/166530895

[trofi]

My naive grep shows that at least the following ~220 attributes use ffmpeg directly. Trying to build them against staging-next I see avcodec-related build failures in:

• PPSSPP
• acoustidFingerprinter
• alephone
• amarok (via qt515.qtwebengine depend)
• ardour (via harvid depend)
• attract-mode
• audacious
• baresip
• bino3d
• blender
• bombono
• cantata
• ccextractor
• citra
• clipgrab (via qt515.qtwebengine depend)
• devede (via mplayer depend)
• diffoscope (via openjxf15 depend)
• digikam (via libsForQt5.libqtav depend)
• dolphin-emu (and variants)
• electricsheep
• flowblade (via mlt depend)
• gnash
• guvcview
• harvid
• hedgewars
• hydron
• k3b
• kid3
• liblinphone (via mediastreamer depend)
• lightspark
• mediastreamer
• mixxx
• mlt
• moc
• mplayer
• musikcube
• musly
• obs-studio
• openboard
• openjfx
• openjfx11
• openjfx15
• openrw
• oven-media-engine
• ovito
• pangolin
• paraview
• pcsxr
• performous
• pianobar
• pulseaudio-modules-bt
• qmmp
• qmplay2
• qstopmotion
• qtox
• replay-sorcery
• retroarchBare
• sdrangel
• shotcut (via mlt depend)
• simplescreenrecorder
• spek
• squeezelite
• stepmania
• survex
• tenacity
• timg
• ultrastardx
• unpaper
• untrunc
• vbam
• wf-recorder
• wlroots
• wxSVG
• xine-lib
• xjadeo
• zoneminder

[vcunat]

I suspect that it's a bit early to switch the default to 5, meaning that it might need lots of work to fix everything.

a major effort underwent to remove the old encode/decode APIs

[trofi]

Collected full list of failures i could find: ~75 packages: #156705 (comment)

[jonringer]

I'm likely to revert the default bump, tired of going through failing builds and pinning the build to 4

[jonringer]

The better upgrade path will likely be to just bump ffmpeg to major version which upstream supports

[jonringer]

I partially reverted this in 4861bef

In the future, packages which link against ffmpeg should probably be pinned to a major version. It doesn't make sense having broken builds when wanting to increment ffmpeg

[vs49688]

I partially reverted this in 4861bef

In the future, packages which link against ffmpeg should probably be pinned to a major version. It doesn't make sense having broken builds when wanting to increment ffmpeg

Probably for the best. In that case, can I suggest we have a ffmpeg-cli package, which is essentially:

ffmpeg-cli = ffmpeg-full.override { inherit ffmpeg_5; };

so users can always have the latest version of the command line tool? Then tools that only need the CLI (e.g. youtube-dl and navidrome) can just use that.

[milahu]

I suspect that it's a bit early to switch the default to 5, meaning that it might need lots of work to fix everything.

can we document this in pkgs/top-level/all-packages.nix?

{
  ffmpeg_4 = callPackage ../development/libraries/ffmpeg/4.nix {
    inherit (darwin.apple_sdk.frameworks) Cocoa CoreMedia VideoToolbox;
  };
  ffmpeg_5 = callPackage ../development/libraries/ffmpeg/5.nix {
    inherit (darwin.apple_sdk.frameworks) Cocoa CoreMedia VideoToolbox;
  };

  # Aliases
  # Please make sure this is updated to the latest version on the next major
  # update to ffmpeg
  # Packages which use ffmpeg as a library, should pin to the relevant major
  # version number which the upstream support.
  ffmpeg = ffmpeg_4;