Build: Bump Qt6 from 6.8.1 to 6.9.1 (Automated PR)

[github-actions]

This automated Pull Request updates the used Qt6 version to version 6.9.1.

This PR was opened by the workflow Bump dependencies (create-prs)

CHANGELOG: Build: Updated bundled Qt6 to version 6.9.1

[github-actions]

PR has been updated for version 6.8.1 by the workflow Bump dependencies (create-prs).

[ann0see]

I'd assume that this breaks on every Qt6 build.

[github-actions]

PR has been updated for version 6.9.1 by the workflow Bump dependencies (create-prs).

[pljones]

Still failing -- are we turning on stuff that's not needed for audio?

Undefined symbols for architecture arm64:
  "_av_buffer_create", referenced from:
      QFFmpeg::VideoEncoder::processOne() in libQt6FFmpegMediaPluginImpl.a[arm64][47](qffmpegvideoencoder.cpp.o)
      -[QAVFSampleBufferDelegate captureOutput:didOutputSampleBuffer:fromConnection:] in libQt6FFmpegMediaPluginImpl.a[arm64][53](qavfsamplebufferdelegate.mm.o)

[ann0see]

Maybe that's needed. I thought they fixed it on the Qt side...

https://bugreports.qt.io/browse/QTBUG-129651 (?)

[ann0see]

Ah: https://codereview.qt-project.org/c/qt/qtmultimedia/+/630015

We might need to add add_ios_ffmpeg_libraries to the CONFIG variable

[pljones]

OK, having read up a bit I'm convinced we stick with the Qt-preferred approach and use FFmpeg...

Even if we did

export QT_MEDIA_BACKEND=darwin

that wouldn't remove the dependency, just tell the runtime to ignore FFmpeg and use darwin directly.

So yeah, https://doc.qt.io/qt-6/qtmultimedia-apple.html:

CONFIG += add_ios_ffmpeg_libraries

looks like it should do the trick -- although it sounds like that's also a deployment time issue:

FFmpeg binaries from the online installer must be embedded into the application's bundle.

I'm not sure how much it'll help at build time.

[pljones]

CoPilot took some convincing that it was wrong about this as usual (now out of date documentation being more prevalently referenced in once-correct answers).

It's suggested we'd need to amend autobuild.yml (and ios.sh potentially) to build/cache the ffmpeg libraries for the link stage to work.

[pljones]

I also asked if there were any existing actions - but none for iOS, according to CoPilot. It's top answer was:

iOS-Specific FFmpeg Build Scripts
There are community-maintained shell scripts and projects for building FFmpeg for iOS (arm64), such as:
- kewlbear/FFmpeg-iOS-build-script
- tanersener/ffmpeg-kit
These are not GitHub Actions per se, but can easily be wrapped in your own workflow step or custom action.

- name: Build FFmpeg for iOS
  run: |
    git clone https://github.com/kewlbear/FFmpeg-iOS-build-script.git
    cd FFmpeg-iOS-build-script
    ./build-ffmpeg.sh

https://github.com/copilot/share/42365326-43c0-8404-9102-2648a4486807

Now, given that the first of those is FFmpeg 4 and the current version is 7 and the second of those has been archived... I'm thinking we might want to brew from https://github.com/FFmpeg/FFmpeg -- but it'd need someone to knock up the build, possible from cobbling it up from the above.

(It does seem to be becoming increasingly difficult to support Qt6 as time progresses...)

---

https://doc.qt.io/qt-6/qtmultimedia-building-ffmpeg-ios.html -- there's actually an official page on how hard it is...

[ann0see]

I'd rather remove the qtmultimedia dependency on iOS if it's really that painful to support

[ann0see]

Let's check if this works.

[ann0see]

Ok. As expected, I get a black screen on iOS. I would suggest that we either:

• Remove sound alerts from iOS
• Use iOS native libraries to play sound alerts instead of Qtmultimedia
• Find out how to get the ffmpeg libraries which the online installer provides via aqt

[ann0see]

We might also want to debug the iOS build without Qtmultimedia. I've removed the qtmultimedia dependency and respective code. However, the screen still stays black and the debug console does not print anything (except for saying that it detected a hang)

[ann0see]

I'd like to modify this such that the Windows and macOS builds are updated, but iOS remains on 6.7.3

[pljones]

If we split x86_64 and arm64, could we run CodeQL on the arm64 build? Currently MacOS doesn't get covered except in the legacy build, which is going to get switched off at some point. Given we must have the code right for arm64, it feels like that's the architecture that should get checked?

[ann0see]

If we have both architectures, we produce universal builds which is way simpler for the user. We have one binary which runs on M series macs and intel macs. I would rather build those for a bit more (Partly also because I don't own an Apple Silicon mac).

Yes, it would be good to have CodeQL on the non legacy build. But note that arm and x86 builds would need to be signed.

[pljones]

Spin the CodeQL off into a separate flow from the signed build? If it's working off the same git checkout and uses the same build params (without signing), that'll be good enough. Anyway, separate issue.

[pljones]

So if we merge this with QT_VERSION here still 6.7.3, will that pin the version or is something else needed?

[ann0see]

If we leave it at 6.7.3 here, iOS will still use 6.7.3

[pljones]

I mean will github-actions stop pushing version bumps.

[ann0see]

No. I don't think so- but we could probably change the code to do so.

[pljones]

OK, so we need a PR with that in, too, I guess.