Upcoming ffmpeg-8.1 started to use the DisplayCapture.h header which
causes a build failure with <1.5.0. If really needed we could backport
the fix to 1.4.x but I do not see much of a reason to right now.
DisplayCapture.h:43:8: error: expected identifier or '(' [...]
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
ffmpeg with amf USE enabled
- can only built with amf-headers installed.
- can only use AMF ( the 'XXXX_amf' codecs) at runtime when 'amdgpu-pro-amf' is installed (the shared libs it installs are dlopen'ed by ffmpeg)
- can only use the AMF features that it has explicit code for
-> Runtime behavior entirely depends on closed source amdgpu-pro-amf binary that we have no control over
-> we verbump 'amdgpu-pro-amf' and 'amf-headers' straight to stable
This package is also useless on arm64 as it cannot actually be leveraged to use AMF on an AMD GPU:
it needs the proprietary package amdgpu-pro-amf that currently only exists on amd64
Signed-off-by: Adel KARA SLIMANE <adel.ks@zegrapher.com>
Part-of: https://github.com/gentoo/gentoo/pull/45565
Closes: https://github.com/gentoo/gentoo/pull/45565
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Tested on a 7900XTX with
```
$vulkan_wrapper ffmpeg -i '1 - foo-video-in.mp4' -vcodec $codec -b:v 4500000 foo-video-out.mp4
```
with the following combinations
- `$vulkan_wrapper` : `vk_radv` (mesa-26.0.1) and `vk_pro` (amdgpu-pro-vulkan-25.10.2203192)
- `$codec`: `h264_amf`, `hevc_amf` and `av1_amf`
- with both `ffmpeg-9999` (commit a9984fe) and `ffmpeg-8.0.1`
Signed-off-by: Adel KARA SLIMANE <adel.ks@zegrapher.com>
Part-of: https://github.com/gentoo/gentoo/pull/45565
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
ffmpeg with amf USE enabled
- can only built with amf-headers installed.
- can only use AMF ( the 'XXXX_amf' codecs) at runtime when 'amdgpu-pro-amf' is installed (the shared libs it installs are dlopen'ed by ffmpeg)
- can only use the AMF features that it has explicit code for
Given that amdgpu-pro-amf is on top of that a proprietary binary
-> we straight to stable when ver-bumping 'amdgpu-pro-amf' and `amf-headers'
Signed-off-by: Adel KARA SLIMANE <adel.ks@zegrapher.com>
Part-of: https://github.com/gentoo/gentoo/pull/45565
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Drop randstruct warnings wrt bug #969413 given NVIDIA added a fix
(note it is different than the suggested patch, they added padding
instead but should work in theory).
Note that 590.x and the unkeyworded 595.x beta are still affected.
590.x is a dead branch so it will not be fixed, but the next non-beta
595 version will likely be keyworded to replace it.
Bug: https://bugs.gentoo.org/969413
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
This workaround was already needed on Windows, but seems whatever
was causing this there was now added to the Linux drivers as well.
Previous libplacebo was not affected given using deferred alloc is
new to this version, so this just reverts to the previous state for
NVIDIA users and lets it be used for other cards.
I'd hope there will be a new release soon, but given this sometimes
drag may as well backport right away.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Needed for cross-compiling when -flto is in *FLAGS including LDFLAGS.
We already try to disable LTO for the CBUILD Python we build for
cross but not in LDFLAGS, so do that too to avoid a configure test
failure.
Signed-off-by: Sam James <sam@gentoo.org>