commit 3ce1b298921f8cd8b8d55273f277c5e85ffba8ac
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 01:08:57 2026 +0200

media-libs/rocDecode: new package, add 10.0.0

Hardware video decode (H.264, HEVC, AV1, VP9) on the GPU's VCN block through
VA-API, leaving frames in device memory for a downstream HIP consumer.
Companion to media-libs/rocJPEG: same hardware block, same VA-API path, same
AMD CMake template, video streams instead of still images. ::gentoo carries
neither.

Shares rocJPEG's swallow-everything guard -- the whole add_library() sits in
`if(HIP_FOUND AND Libva_FOUND AND Libdrm_amdgpu_FOUND AND Threads_FOUND)` with
no else branch -- so src_install asserts librocdecode.so exists rather than
trusting a zero exit. USE=ffmpeg is asserted the same way: the host decoder is
skipped with only a yellow message when FFmpeg is missing, so passing
-DROCDECODE_ENABLE_HOST_DECODER=ON proves nothing on its own.

Also inherits rocJPEG's CONFIG-vs-MODULE trap, and the ebuild says so
explicitly: HIP must NOT be steered at the legacy FindHIP module here, because
the link line needs the hip::device imported target that only hip-config.cmake
defines.

src_install drops share/rocdecode/{video,frames}: upstream installs its test
fixtures, and they are ~89M of one AMD demo reel re-encoded per codec plus
reference frames -- 95% of the install tree, which goes 94.1 MiB -> 4.9 MiB
without them. The sample SOURCES stay, since the documentation refers to them.

Verified on gfx1150 in three ways rather than by exit status alone. objdump -p
on librocdecode.so.1.9.0 accounts for every declared dependency (libva.so.2,
libva-drm.so.2, libdrm_amdgpu.so.1, librocprofiler-register.so.0,
libamdhip64.so.7). Upstream's own videoDecode sample, configured against the
INSTALLED tree, resolves find_package for hip, rocdecode, rocdecode-host and
rocprofiler-register -- so the installed cmake configs are correct and
discoverable. And rocDecGetDecoderCaps returns a real hardware query rather
than a stub: AVC 64x64..4096x4096, HEVC/VP9/AV1 up to 8192x4352, MPEG2/MPEG4
unsupported, which is exactly VCN 4.0 on this part.