Following @dcurtisfra’s discussion above about Packman and the future of the upstream libheif project (Iinked to this topic)…
Open to correction here, but AFAIU frameworks (like glycin or GIMP plugins) that talk to ffmpeg or libavcodec can decode mobile HEVC files directly through the VLC repository’s version of FFmpeg.
My understanding as well, see converting-heic-file-fails #24
As long as you have any h265 decoder, the OSS libheif will do.
Bruno, yes, that did the trick – I moved my copy of the ffmpeg-8 package from the openSUSE OSS repository to the https://download.videolan.org/SuSE/Tumbleweed repository and, everything is now, AFAICS after a quick .heic file check, OK.
The following packages were also moved over to the VideoLAN repository as a consequence of the FFmpeg move:
AFAICS, “kimageformats” is also OK with this solution.
Can anybody explain why this is in Open Chat? I don’t get it.
@knurpht I think it’s because of the way the topic was originally presented. It didn’t really come across as a request for help with a specific problem, but more as a discussion/speculation about what will happen to HEIF/HEVC support when Packman is discontinued.
However, as I explained already a viable alternative is using ffmpeg from the VLC repository which can facilitate HEVC decoding through libheif-ffmpeg.
I got that, but …
Well, it’s easy enough for me to move… now that technical advice was provided. 
Anyway, I can do that now.
Because, at first I was simply reporting the situation with the libheif developer responsible for the source code currently used by the Packman project.
OK, Deano and Bruno both offered a solution.
And now … ???
BTW, (assuming that anyone will be interested) – the reason why I accepted the VideoLAN solution is as follows:
The VideoLAN project is supported by the VideoLAN organization, based in France.
VideoLAN is NOT a US-based organization and is therefore outside US jurisdiction.
Patents and codec licenses
Neither French law nor European conventions recognize software as patentable (see French section below).
Therefore, software patents licenses do not apply on VideoLAN software.NB: libaacs is not shipped in VLC.
So, there you are – as a European Union citizen, I have a nice warm and cosy feeling … 
For those users who are located outside of the European Union, they may well have a different view on the situation.
Yes, and for others who come searching…
https://en.opensuse.org/SDB:Installing_ffmpeg_from_the_VLC_repository
Well their national motto is “Liberté, Égalité, Fraternité”. So perhaps it’s entirely appropriate that the French VLC repository is helping to liberate your codecs.
That is a nice piece of work, thanks.
free to do what you’re told, outstanding!
Good news regarding the libheif project →
> rpm --query --changelog libheif1 | less
* So Sep 06 2026 Andreas Stieger <andreas.stieger@gmx.de>
- Update to version 1.23.4:
* CVE-2026-XXXXX: The max_items security limit was not enforced
for the child boxes of iinf, so a file could declare an
unbounded number of items.
* CVE-2026-XXXXX: Unbounded recursion in the reference-cycle
check crashed the parser on a long chain of derived items,
without bound when the item-count limit is disabled.
* CVE-2026-XXXXX: Permanent decoder deadlock through a lock-order
inversion in parallel grid tile decoding (enabled by default).
* CVE-2026-XXXXX: Heap out-of-bounds read in the encoder pluginsi
for images whose luma and chroma bit depths differ.
* CVE-2026-XXXXX: Unreclaimable memory leak in
heif_track_get_next_raw_sequence_sample().
* CVE-2026-XXXXX: Heap out-of-bounds read in the WebCodecs
decoder plugin
- includes fixes from 1.23.3:
* CVE-2026-XXXXX: Heap buffer overflow (write) in the
uncompressed (unci) mixed-interleave decoder when the two
chroma components declare different bit depths.
* CVE-2026-XXXXX: Permanent decoder deadlock through a reference
cycle between an image and its alpha auxiliary image.
* CVE-2026-XXXXX: Heap out-of-bounds read in the YCbCr 4:2:0 to
16-bit interleaved RGB conversion when the chroma planes have a
lower bit depth than luma
* CVE-2026-XXXXX: Heap buffer overflow in the SVT-AV1 encoder
plugin when encoding a high-bit-depth alpha channel, and a
double free on its send-picture error path.
* CVE-2026-84451: Incomplete fix: the tile range check of the
unci decoder (without icef) could still overflow, allowing an
out-of-bounds read
* CVE-2026-XXXXX: Heap out-of-bounds read when converting odd-
height 4:2:0 frames of an uncompressed (uncv) image sequence to
RGB.
* CVE-2026-XXXXX: Out-of-bounds read in the RGB to YCbCr identity-
matrix color conversion when the R, G, and B planes have
different bit depths
* CVE-2026-84450: A clap property combined with an oversized ispe
reached an assert() in the Fraction arithmetic and aborted the
process (incomplete fix). An error is returned instead.
* Fix Several smaller findings
* Fix Undefined behavior (negative shift) in the HDR bit-depth
up-conversion for target bit depths above 16. Such conversions
are now rejected.
* A number of bug fixes
* Do Aug 27 2026 Andreas Stieger <andreas.stieger@gmx.de>
- Update to version 1.23.2:
* CVE-2026-84383: Heap buffer overflow in
scale_nearest_neighbor() via duplicate alpha planes from
nested iden/auxl items. (boo#CVE-2026-84383)
* Out-of-bounds read and write in derived-item and pixel-plane
handling. Through iden and auxl item chains, a crafted file
could attach pixel planes whose size differs from the image
geometry; crop, scale, and plane-extraction code then indexed
those planes with the wrong size. A working code-execution
exploit was confirmed. Plane sizes are now validated wherever
they are consumed. (boo#1279444)
* CVE-2026-84384: brotli/zlib decompression of mime metadata
and unci image data had no effective output-size limit, so a
decompression bomb could exhaust memory. Decompressed output
is now bounded by the security limits. (boo#1279445)
* CVE-2026-84447: Chains of derived-image references (grid,
iovl, iden) bypassed decode caching and memory limits, causing
CPU and memory amplification. (boo#1279446)
* CVE-2026-84446: Sequence sample-timing initialization could
produce non-terminating decode loops and unbounded memory,
bypassing max_sequence_frames. (boo#1279447)
* CVE-2026-84444: Out-of-bounds write in the unci encoder when
heif_context_add_image_tile() is given a tile whose planes do
not match its declared size. (boo#1279448)
* CVE-2026-84448: Heap out-of-bounds read in the inline-mask
region API when mask_data_len does not match the region
geometry. (boo#1279449)
* C++ exceptions such as std::bad_alloc can no longer escape the
C API read/decode entry points; they are returned as a
heif_error instead of aborting the process
* assert()s in the pixel-image plane allocation were replaced by
runtime errors
* stts/ctts tables describing more samples than the track can
have are rejected
* pclr (JPEG 2000 palette) box: the number of palette entries is
bounded by the box size
* BitReader::skip_bytes() is now constant time (fixes a fuzzer
timeout on bogus alignment values)
* iden items now validate the decoded image size like all other
items
* The uncompressed (unci) encoder rejects images without pixel
planes
* meta, mini, and moov boxes with size 0 (extending to the end of
the file) are now parsed correctly
* Fixed an integer overflow when probing the file size
* Fixed undefined behavior (signed shift) when reading the NAL
unit length in the OpenH264 decoder
* heif_region_item_add_region_inline_mask_data() now requires
non-zero width and height and the mask_data_len must equal
the expected (width * height + 7) / 8; otherwise it returns
an error instead of storing the mask
* heif_image_add_plane() returns an error instead of aborting
for bit depths outside 1..128 or interleaved component counts
outside 1..255