Update dependencies

[RytoEX]

Description

Update dependencies that have patch updates available. We are not updating minor/major versions at this time.

• deps.ffmpeg: Update zlib to 1.3.1
• deps.ffmpeg: Update aom to 3.8.1
• deps.ffmpeg: Update mbedTLS to 3.4.1
• deps.qt: Update Qt6 to 6.6.2 for Windows
• deps.qt: Update Qt6 to 6.6.2 for macOS

The update from libpng 1.6.40 to 1.6.42 has been left out because it would require adjustments to our patch. I would rather us spend time and effort getting that upstreamed.

Motivation and Context

Patch updates should be safe for us to adopt.

How Has This Been Tested?

I haven't tested these beyond checking that the deps build on my fork. I haven't tested building/running OBS with these yet. Testing appreciated.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[gxalpha]

What are your thoughts on reverting https://codereview.qt-project.org/c/qt/qtbase/+/525424 for macOS (see https://bugreports.qt.io/browse/QTBUG-121351)?

[RytoEX]

What are your thoughts on reverting https://codereview.qt-project.org/c/qt/qtbase/+/525424 for macOS (see https://bugreports.qt.io/browse/QTBUG-121351)?

I would want a bit more context.

[gxalpha]

In Qt 6.5, Qt added the native dialogs for QMessageBox, which made use of the native OS API's to display the message box. Imo, this looks far superior to the non-native version.
Then, at QTBUG-120054 someone complained that stylesheets no longer work (which makes sense, it's a native OS dialog after all). Unfortunately, that report made Qt change the behavior between 6.6.1 and 6.6.2 (and future versions) so that when a stylesheet is in use, the dialog will show the non-native version (this is the Qt PR I linked above). Unfortunately, it's now no longer possible at all to get a native dialog if a stylesheet is in use.
I filed QTBUG-121351 a while back to complain about this, but unfortunately that does not yet have any replies by Qt on how this could be handled in the future, if at all.

In short, this patch update will make us lose native dialogs unless the commit is reverted (qt/qtbase@1b71e2d in dev or qt/qtbase@04dda6c in 6.6).

[RytoEX]

And we have confirmed that this actually happens with Qt 6.6.2 and OBS? Do we have a simple reproducer for the QTBUG that isn't OBS itself?

[gxalpha]

And we have confirmed that this actually happens with Qt 6.6.2 and OBS?

I have confirmed that this actually happens with OBS, yes. I also now reconfirmed with the artefact of this PR.

Do we have a simple reproducer for the QTBUG that isn't OBS itself?

Seeing that I did not attach it to the QTBUG I don't think it exists, but it should be trivial to create one if required.

It did just cross my mind that in theory, we could

widget->setAttribute(Qt::WA_StyleSheet, false);

on a QMessageBox on the OBS side before displaying it. This would be quite the hack and have to be done everywhere QMessageBox is used, but should be possible if you would prefer it to a Qt patch/revert.

[RytoEX]

And we have confirmed that this actually happens with Qt 6.6.2 and OBS?

I have confirmed that this actually happens with OBS, yes. I also now reconfirmed with the artefact of this PR.

Do we have a simple reproducer for the QTBUG that isn't OBS itself?

Seeing that I did not attach it to the QTBUG I don't think it exists, but it should be trivial to create one if required.

It did just cross my mind that in theory, we could

widget->setAttribute(Qt::WA_StyleSheet, false);

on a QMessageBox on the OBS side before displaying it. This would be quite the hack and have to be done everywhere QMessageBox is used, but should be possible if you would prefer it to a Qt patch/revert.

I'll have to mull over which I prefer.

On the QTBUG side, I find they're more apt to address bugs for which there is a trivial reproducer attached so they can quickly observe the issue.