* Fix macOS Big Sur crash with CVBufferCopyAttachments
Add FFmpeg patch to use weak_import for CVBufferCopyAttachments API
to prevent dyld crash on macOS Big Sur (11.x).
The CVBufferCopyAttachments function is only available on macOS 12+.
Even though FFmpeg has a runtime check with __builtin_available, the
symbol is still resolved at load time, causing immediate crash on older
macOS versions.
With weak_import attribute, the function pointer will be NULL on
macOS < 12, allowing the code to safely fall back to the deprecated
CVBufferGetAttachments API.
Fixes: #13377
* update common
* Fix ffmpeg videotoolbox wrong log when changing bitrate
* Let qsv support abr, and it's safe for qsv to changing bitrate.
Signed-off-by: 21pages <sunboeasy@gmail.com>
1. Fix this issue occurs on FFmepg qsv, FFmpeg nvenc and SDK mfx, other
codecs don't have this problem. Clear cache is needed.
Signed-off-by: 21pages <sunboeasy@gmail.com>
* Possible Causes
* GPU API Call Hangs: This could occur, though it's less likely.
* Infinite Loop: If `QueryOutput` always fails and `hwsurfaces_in_queue_max` is zero, the loop will continue indefinitely.
* Proposed Solution
* A query_timeout patch has been added to FFmpeg with a value of 1000ms, which exceeds the time required to encode a single frame. This allows us to remove the loop.
* Test
* After removing the loop, no frame encoding failures were encountered during testing. A single call to QueryOutput is sufficient, as it typically consumes about 12ms on a 2K screen.
Signed-off-by: 21pages <sunboeasy@gmail.com>
1. version changes:
* vcpkg: 2024.07.12 -> 2024.11.16
* aom (except linux sciter): 3.9.1 -> 3.11.0
* libvpx: 1.14.1 -> 1.15.0
* libyuv: not update because compiled failed on arm64, and didn't apply
different version on different archs
* opus: already the latest version
* ffmpeg: 7.0.2 -> 7.1
2. other changes:
* android 5.0 required, otherwise crash when start, because FFmpeg 7.1 link to mediandk directly
3. Tests:
* Except arm, arm64, linux amf, ios, all the other codecs are tested
* Compile on arm32 linux is not tested, ci is failed before vcpkg
install
* Tested windows FFmpeg qsv, still no memory leak
Signed-off-by: 21pages <sunboeasy@gmail.com>
1. Linux dynamic load libva, which can fix lack of libva dependency for
appimage or flatpak, also fix libva version mismatch between build
and run.
2. Remove libvdpau, it's not used, and add libva2 explicitly for deb and
appimage
3. Print FFmpeg configure log to know the actual codecs.
Test
* ubuntu 22.04 x64
- [x] deb
- [x] flatpak
- [x] appimage
* ubuntu 18.04
* deb: fcntl64 not found
- [x]:appimage
- [ ]: platpak
hwcodec example:
- [x]: combination of lacking any of libva2, libva-x11-2, libva-drm2,
intel-media-va-driver
- [ ] federa
- [ ] arch
- [ ] arm64: my ci can't finish arm64 building
Signed-off-by: 21pages <sunboeasy@gmail.com>
* fix qsv memory leak by updating ffmpeg
* Memory leaks occur when destroying FFmpeg QSV VRAM encoders. This issue is resolved with FFmpeg version 7.
* FFmpeg requires ffnvcodec version 12.1.14.0 or higher, and an NVIDIA driver version greater than 530. For more details, https://github.com/FFmpeg/nv-codec-headers/tree/n12.1.14.0.
* The code of NVIDIA VRAM encoder is not changed, still use Video Codec SDK version 11, which is unaffected by FFmpeg. Drivers newer than 470 can support this, but we may consider an update later, as the support check by sdk code may not be accurate for FFmpeg RAM encoders.
* The issue is related to FFmpeg, not libmfx. FFmpeg version 7 recommends using libvpl, but vcpkg currently lacks ports for libvpl. We can add these in the future.
* D3D11 Texture Rendering: The "Shared GPU Memory" in the task manager continue increasing when using D3D11 texture render, which can exceed the GPU memory limit (e.g., reaching up to 100GB). I don't know what it is and will try to find it out.
* Roughly tests on Windows, Linux, macOS, and Android for quick fix. Further testing will be performed, and I will share the results in this pr.
Signed-off-by: 21pages <sunboeasy@gmail.com>
* update flutter_gpu_texture_render, fix shared gpu memory leak while
rendering
Signed-off-by: 21pages <sunboeasy@gmail.com>
---------
Signed-off-by: 21pages <sunboeasy@gmail.com>
