Update dependencies

[RytoEX]

Description

Update dependendies as available:

• deps.ffmpeg: Update libpng to 1.6.43
• deps.ffmpeg: Update opus to 1.5.2
• deps.ffmpeg: Update libvpx to v1.14.0
• deps.ffmpeg: Update SVT-AV1 to 2.0.0
• deps.ffmpeg: Update aom to 3.9.0
• deps.ffmpeg: Update libdatachannel to v0.21.0
• deps.ffmpeg: Update AMF to 1.4.33
• deps.ffmpeg: Update FFmpeg to 7.0
• deps.macos: Update LuaJIT to 2.1 5790d25397
• deps.macos: Update libpng to 1.6.43
• deps.macos: Update Asio to 1.30.2
• deps.macos: Update Sparkle to 2.6.1
• deps.windows: Update curl to 8.7.1
• deps.windows: Update LuaJIT to 2.1 5790d25397
• deps.windows: Update Asio to 1.30.2
• deps.windows: Update Zstandard to 1.5.6
• deps.windows: Update VPL to v2.10.2
• deps.qt: Update Qt6 to 6.6.3 for Windows
• deps.qt: Update Qt6 to 6.6.3 for macOS

Motivation and Context

Want to keep our deps up to date.

Supersedes #246
Closes #246

Note that neither SRT/libsrt nor mbedTLS are updated here. Building SRT 1.5.x against mbedTLS 3.5.0+ fails because of changes in mbedTLS that needed addressed in libsrt, but there is no new libsrt tag with the needed changes.
Haivision/srt#2842

I initially updated RNNoise, but dropped it because the Windows build actually uses an old PR that added CMake support. We'll either have to rewrite CMake support for the latest stable tag, or we'll have to change our build script to use their preferred build system (autotools).

I did not update librist because versions 0.2.8-0.2.10 have a bug, and there is no new tag. See:

• Update dependencies #228 (comment)

Will post test notes in a follow-up comment.

How Has This Been Tested?

Built deps locally. Built OBS against those deps on Windows 11.

Types of changes

• 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.

[RytoEX]

Good news

OBS builds in Debug, RelWithDebInfo, and Release.

These worked:

• Encoders
  • AOM
  • SVT-AV1
  • QSV
  • x264
• Recording
  • Standard
    • MKV
    • MP4
    • Fragmented MP4
  • Custom FFmpeg Output
    • MP4 + libx264 + aac
    • MKV + libx264 + libvorbis
    • webm + libvpx-vp9 + libopus
• Streaming
  • RTMP
  • RTMPS
  • HLS
  • SRT (local network)
  • RIST (local network)
• Sources
  • Browser
    • Default
    • FishGL/Aquarium
  • Color
  • Display Capture
    • WGC
  • Game Capture
  • Image
    • Animated GIF
    • JPG
    • PNG
  • Image Slide Show
  • Media
    • FLV
    • MP4
    • SRT ingest on local network (OBS to OBS)
    • RIST ingest on local network (OBS to OBS)
    • webm with transparency
  • Text (FreeType 2)
  • Text (GDI+)
  • Video Capture Device
  • VLC
    • playlist of files
  • Window Capture
    • BitBlt
    • WGC
• Filters
  • Chroma Key
  • Color Correction
• webm stingers
• Scripting
  • Python
  • Lua

Everything in my typical tests for those features worked.

Bad News

These do not work:

• Streaming
  • WHIP

Apparently there are build errors on macOS at the moment. The Qt download failure seems like a sporadic failure. Will re-run CI later after trying to address the diverged patch for libpng.

On Windows, while I can build in RelWithDebInfo and Release, I cannot start the application.

It looks like the RelWithDebInfo and Release builds somehow marked the Qt Debug DLLs (e.g., Qt6Cored.dll) as the necessary runtime DLLs instead of the Release DLLs (Qt6Core.dll). This seems to be a side effect of this change in Qt:
qt/qtbase@d08fa86

This results in these files inside the obs-studio\build_x64\.qt dir:

QtDeploySupport-Debug.cmake
QtDeploySupport-MinSizeRel.cmake
QtDeploySupport-Release.cmake
QtDeploySupport-RelWithDebInfo.cmake
QtDeployTargets-Debug.cmake
QtDeployTargets-MinSizeRel.cmake
QtDeployTargets-Release.cmake
QtDeployTargets-RelWithDebInfo.cmake

Since I locally built Qt in Release first and then in Debug, these files all pointed to the Qt Debug DLLs as the "obs-studio_RUNTIME_DLLS":

set(__QT_DEPLOY_TARGET_obs-studio_RUNTIME_DLLS C:/dev/obsproject/obs-deps/windows/obs-dependencies-x64/bin/libcurl.dll;C:/dev/obsproject/obs-studio/build_x64/UI/obs-frontend-api/RelWithDebInfo/obs-frontend-api.dll;C:/dev/obsproject/obs-studio/build_x64/libobs/RelWithDebInfo/obs.dll;C:/dev/obsproject/obs-deps/windows/obs-ffmpeg-x64/bin/avcodec-61.dll;C:/dev/obsproject/obs-deps/windows/obs-ffmpeg-x64/bin/avutil-59.dll;C:/dev/obsproject/obs-deps/windows/obs-ffmpeg-x64/bin/avformat-61.dll;C:/dev/obsproject/obs-studio/build_x64/deps/w32-pthreads/RelWithDebInfo/w32-pthreads.dll;C:/dev/obsproject/obs-deps/windows/obs-ffmpeg-x64/bin/swscale-8.dll;C:/dev/obsproject/obs-deps/windows/obs-ffmpeg-x64/bin/swresample-5.dll;C:/dev/obsproject/obs-deps/windows/obs-qt-x64/bin/Qt6Widgetsd.dll;C:/dev/obsproject/obs-deps/windows/obs-qt-x64/bin/Qt6Svgd.dll;C:/dev/obsproject/obs-deps/windows/obs-qt-x64/bin/Qt6Guid.dll;C:/dev/obsproject/obs-deps/windows/obs-qt-x64/bin/Qt6Xmld.dll;C:/dev/obsproject/obs-deps/windows/obs-qt-x64/bin/Qt6Networkd.dll;C:/dev/obsproject/obs-deps/windows/obs-qt-x64/bin/Qt6Cored.dll)

Not sure what to do about that. Additionally, there are some known QTBUGs with Qt 6.7.0 that won't be fixed until 6.7.1 or 6.7.2, so I might revert that and go with Qt 6.6.3 unless 6.7.1 becomes available before we freeze deps.

Todo

• Encoders
  • TODO: AMF
  • TODO: NVENC

Also, building and testing on macOS.

[PatTheMav]

We already add an entire CMakeLists.txt for one dependency via a patch, I forgot which one, but if necessary we can do the same for RNNoise.

[RytoEX]

I reverted these updates:

• deps.macos: Update RNNoise to v0.2
• deps.qt: Update Qt6 to 6.7.0 for Windows
• deps.qt: Update Qt6 to 6.7.0 for macOS
• deps.windows: Update RNNoise to v0.2

I changed the deps.qt update to:

• deps.qt: Update Qt6 to 6.6.3 for Windows
• deps.qt: Update Qt6 to 6.6.3 for macOS

I changed libdatachannel to:

• deps.ffmpeg: Update libdatachannel to v0.21.0

On Windows, we had been using an outdated PR which added CMake support, but did not keep up with the host repo's changes. We'll either have to rewrite the CMake support from scratch, or use RNNoise's autotools build system on Windows. Since I prefer to keep the dependencies in sync, I reverted both deps.macos and deps.windows changes.

Qt 6.7.0 is a bit too unstable for me to do meaningful testing, so I went with Qt 6.6.3 for now. Qt 6.7.1 might be stable enough, but we can just save the 6.7.x update for later.

The libdatachannel change supposedly fixes the issue I ran into, or fixes other known issues. Will confirm in my testing.

[RytoEX]

I'm still getting some odd issues with Qt 6.6.3 if I locally build both Debug and Release separately:

.\Build-Dependencies.ps1 -PackageName qt -Shared -Configuration Debug
.\Build-Dependencies.ps1 -PackageName qt -Shared

This was an OBS Studio build in Debug:

After that, building and running in RelWithDebInfo was fine.

I've had no issues building OBS Studio against the stock distribution of Qt 6.7.0. I recently discovered that Qt themselves still uses their configure script as a CMake wrapper and that they still build in -debug-and-release. I'm wondering if there's something special in their CMake about multi-config builds that circumvents these issues. Unfortunately, if I recall correctly, when I originally implemented the Qt build scripts on CI, I could not do a single -debug-and-release build for some reason (possibly because the runner ran out of disk space?).

I might have to re-run this with Seeking Testers or do some bisecting locally.

[RytoEX]

I've retested locally and it seems my build/runtime issues with Qt may have been some issues with unclean build dirs and not building the full archive in the correct order of operations. I've successfully built and run Debug, RelWithDebInfo, and Release with Qt 6.6.3.

I've also now successfully tested WHIP with two implementations.

I've also tested AMF and NVENC.

I updated Sparkle from 2.6.0 to 2.6.1 at their recommendation. Though I do not believe we were immediately affected by the issue (our macOS updates are served via HTTPS), their recommendation was to update anyway.
https://github.com/sparkle-project/Sparkle/releases/tag/2.6.1