Prepare qt 6 recipe for FFMPEG transition to QtMultimedia

[mmcauliffe]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

As of Qt 6.7, the default backend for Qt Multimedia has switched to ffmpeg rather than the native backends: https://doc.qt.io/qt-6/qtmultimedia-index.html#target-platform-and-backend-notes

I've seen some issues with gstreamer on osx_arm64, so switching to ffmpeg should resolve those as well.

hmaarrfk's comment:

This modification has evolved toward allowing ffmpeg support for qt6. However, due to the large number of dependencies that FFMPEG pulls in, we are deciding to split this off as a separate package. For Qt 6.7.1, the qt6-main package will continue to provide gstreamer support. ffmpeg support is provided by the qt6-multimedia package.

For future package, no multimedia support will be provided through the qt6-main package and end users will have to use the qt6-multimedia package to get video and audio support.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[mmcauliffe]

Looks like OSX_64 is failing due to https://github.com/conda-forge/ffmpeg-feedstock/blob/main/recipe/build.sh#L92

[mmcauliffe]

@conda-forge-admin, please restart ci

[mmcauliffe]

@hmaarrfk thanks for merging the videotoolbox changes for ffmpeg! Hoping that should be the only change necessary to get OSX builds working, but it looks like linux_aarch64 is consistently failing for extracting the qt-everywhere tarball due to lack of space. Is this a transient known issue or is there some configuration that needs to get changed because ffmpeg and dependencies are larger than gstreamer and dependencies?

[hmaarrfk]

it should be pretty transient for qt6. tbh, i've never seen it before. Lets try again after this fails.

[hmaarrfk]

The other option which I was considering. Was to build qtmultimwdia as a separate package for these very reasons.

It would be "easy" from a packaging standpoint to do in 6.7

[mmcauliffe]

Hm, yeah it still is having space issues. What all would be involved in having a separate package for QtMultimedia? Would that be a separate feedstock?

As a simpler fix, I can add back in the gstreamer backend for linux_aarch64 since that worked for it and should let the rest be on ffmpeg?

[hmaarrfk]

See https://github.com/conda-forge/qt-charts-feedstock
and https://github.com/conda-forge/staged-recipes/pull/21050/files

[hmaarrfk]

As a simpler fix, I can add back in the gstreamer backend for linux_aarch64 since that worked for it and should let the rest be on ffmpeg?

this won't work for 6.7 so not so fun.

[mmcauliffe]

As a simpler fix, I can add back in the gstreamer backend for linux_aarch64 since that worked for it and should let the rest be on ffmpeg?

this won't work for 6.7 so not so fun.

It won't? It does say that the native support is still there, just limited: https://doc.qt.io/qt-6/qtmultimedia-index.html#native-backends, I think in the future it's likely that they'll drop it though.

[Tobias-Fischer]

Have you tried to set free_disk_space: True (https://conda-forge.org/docs/maintainer/conda_forge_yml/#azure)? I'm not sure if it affects linux-aarch64 as well, but might be worth giving it a shot.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[hmaarrfk]

Fingers crossed this passes.

[hmaarrfk]

its strange that this getting deleted. is gstreamer no longer getting pinned?

[h-vetinari]

Pretty sure that the selectors using the version are at fault here:

    - gstreamer                          # [unix and version == "6.7.1"]
    - pulseaudio                         # [linux and version == "6.7.1"]

This feedstock only builds one version at a time. Why are we trying to filter dependencies on the version at all?

In any case, if you want to keep that filter, maybe you'll have more success with:

    {% if version == "6.7.1" %}
    - gstreamer                          # [unix]
    - pulseaudio                         # [linux]
    {% endif %}

[mmcauliffe]

I'll try rerendering here but, maybe it's because of the version check with:

    - gst-plugins-base  {{ gstreamer }}  # [unix and version == "6.7.1"]
    # gstreamer plugin not supported on win32: https://bugreports.qt.io/browse/QTBUG-107073
    - gstreamer                          # [unix and version == "6.7.1"]

Is there a way to pin this with a conditional on version?

[mmcauliffe]

@conda-forge-admin please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/qt-main-feedstock/actions/runs/9201282415.

[hmaarrfk]

is ffmpeg being depended on here?

[hmaarrfk]

@conda-forge-admin please rerender

[hmaarrfk]

~~this logic doesn't match up with your tests below for windows. ~~

I think just delete the windows changes.

For windows users that want multi-media, they can install the qt6-multimedia package you made, and they will be off to the transition a version early.

Edit: I checked the logs of the last completed build, qt6multimedia.dll doesn't exist.

[mmcauliffe]

Ah yes there was a bug here, should be

IF "%PKG_VERSION%"=="6.7.1" (
   set "MODS=%MODS%;qtmultimedia"
)

For the conditional to check out. I can fix that and add tests for Qt6Multimedia.dll existence in 6.7.1, but if you think it's better to rely on conda-forge/staged-recipes#25992 for windows, I'm ok with that too

[hmaarrfk]

I think its better to "not add any features" here and just to leave it to qt6-multimedia if we can.

[hmaarrfk]

I'm not going to press the green button myself for a few days since I feel like I had too much of a heavy hand in the design of this recipe.

But i'm very eager to get this in. Thank you @mmcauliffe for persevering!

[mmcauliffe]

Sounds good, thanks @hmaarrfk! I do have the one outstanding question here: #256 (comment). In terms of the timing of merging this vs conda-forge/staged-recipes#25992, is the qt-multimedia recipe dependent on the changes here or can we get that merged in before this? There's some post-merged work for setting up the cross compiled builds for qt-multimedia and I want to also start testing out the ffmpeg backend with my projects.

[hmaarrfk]

is the qt-multimedia recipe dependent on the changes here or can we get that merged in before this?

I think it is now pretty independent, becaues we mostly made this recipe "remove gstreamer after 6.7.1"

There's some post-merged work for setting up the cross compiled builds for qt-multimedia and I want to also start testing out the ffmpeg backend with my projects.

are you on linux? you could build that package locally. and upload to your own channel during this time. it will "help" you prepare and test and maybe even find compatibility bugs that could change the my thoughts on this intermediate package.

[hmaarrfk]

Alright here goes, thanks for the patience.