Installing multimedia codecs on openSUSE Leap comes down to one community repository, Packman. Once it’s in place, the H.264 and H.265 videos that refused to play can be decoded by VLC, by GStreamer players such as GNOME Videos and by FFmpeg. By the end of this guide you’ll have the full FFmpeg build, the GStreamer codec add-ons and a Packman repository line that keeps working when Leap moves to its next minor release.
That last part is the reason for this update. The old command pinned Packman to the 16.0 folder, and on a 16.1 system that folder now drags in the wrong Mesa build. You’ll add Packman the version-proof way, switch your packages and install the codecs, and if you used the older line, you’ll re-point it. I went through every step again on a fresh openSUSE Leap 16.1 VM in November 2026, and they still hold with that one URL change.
See what Leap ships without
openSUSE can’t distribute the patent-encumbered codecs from its own servers, so Leap leaves them out. The main repository still carries open formats such as Opus, Vorbis, VP9 and AV1, and Leap adds a separate openh264 repository so Firefox can handle H.264 video calls. MP3 already plays on a stock install, and AAC works through a reduced openSUSE build of the FDK library. What’s missing is what most video files need: full H.264 and H.265 decoders in the FFmpeg libraries, the x264 and x265 encoders and a complete FFmpeg build.
You can see the gap for yourself before you change anything. The lab VM got VLC and the usual GStreamer plugins (good, bad, ugly and libav) from the openSUSE repositories, the same stack a desktop install pulls in. Then ask GStreamer for an H.264 decoder and encoder.
gst-inspect-1.0 avdec_h264
gst-inspect-1.0 x264encBoth come back empty. The lab install set had no ffmpeg command either, although the main repository does carry a stripped ffmpeg-7 package you may already have. The stock install does have openh264dec, but that’s Cisco’s limited decoder, and GStreamer apps such as GNOME Videos lean on the libav decoders for most real files. On a stock system, your two checks print this:
No such element or plugin 'avdec_h264'
No such element or plugin 'x264enc'VLC is installed at this point, but rpm -qi vlc lists its vendor as openSUSE, which is the stripped build. If you see the same two “No such element” lines, that’s normal for a stock install and exactly what the next steps fix.
Add the Packman repository
Packman publishes one folder per Leap minor release on its mirrors. Before you write the repository line, it pays to check which folders actually exist on the main mirror at ftp.gwdg.de, because a guessed path fails at refresh time with a confusing metadata error. Both release folders answer, while a plain openSUSE_Leap_16 folder does not exist.
That result decides the URL you should use. The table sums up each form on a 16.1 system, based on the mirror check above and the dry runs later in this guide.
| Repository path | On the mirror | What happens on Leap 16.1 |
|---|---|---|
openSUSE_Leap_16.0/ | 200 OK | Refreshes, then zypper dup hits 6 Mesa dependency problems |
openSUSE_Leap_16.1/ | 200 OK | Works on 16.1, but goes stale after the next minor upgrade |
openSUSE_Leap_$releasever/ | Expands to 16.1 | Works now and follows the system version on upgrade |
openSUSE_Leap_16/ | 404 Not Found | Refresh fails |
The $releasever form is the one to use. zypper replaces the variable with your installed version every time it reads the repository, so the same line points at the 16.1 folder today and the next folder after an upgrade. There’s one condition: Packman has to publish the new release folder before you upgrade, otherwise the refresh gets a 404 and zypper refuses to run dup while an enabled repository fails. Check the folder first, the same way as above. Keep the single quotes, otherwise your shell expands $releasever to an empty string before zypper ever sees it. The -p 90 gives Packman a higher priority than the default 99, because a lower number wins in zypper:
sudo zypper addrepo -cfp 90 'https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/' packmanzypper prints the URI already expanded to openSUSE_Leap_16.1, while the file it writes under /etc/zypp/repos.d/ keeps the literal variable. That second part is what makes the line survive upgrades:
Now refresh so zypper downloads the Packman metadata. Your first refresh stops to ask whether you trust the Packman signing key.
sudo zypper refreshCheck that the fingerprint reads F887 5B88 0D51 8B6B 8C53 0D13 45A1 D067 1ABD 1AFB, the one Packman publishes on its help page, then type a to trust it always, as in this capture. The key name reads PackMan Project (signing key), and in the lab it showed an expiry of 1 January 2027, so do not be surprised if zypper asks about a renewed key around then:
Once the key is trusted, confirm the repository is enabled with the raised priority. This also shows you the expanded URL, so it is the quickest way to see which release folder zypper is really reading.
zypper lr -u packmanThe URI should end in your release folder and the priority should read 90:
URI : https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_16.1/
Enabled : Yes
GPG Check : (r ) Yes
Priority : 90 (raised priority)The (r ) under GPG Check means the metadata signature check is in force. Before the first successful refresh the column reads ( p): there’s no valid metadata signature yet, so zypper checks each package instead. If it still says ( p) after you refreshed, the key was never accepted, and the next section explains why that happens.
Signature verification failed for repomd.xml
This is the part that trips people up when they script the setup. The first lab attempt piped the answer into zypper refresh, and the answer arrived before zypper showed its prompt, so zypper hit the end of its input. It printed Cannot read input: bad stream or EOF and left the key untrusted. The next dup and install ran with -n (non-interactive), which answers the key prompt with the default r for reject, so both failed like this:
Repository 'packman' is invalid.
[packman|https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_16.1/] Failed to retrieve new repository metadata.
History:
- Signature verification failed for repomd.xmlRun the refresh in a normal terminal and answer the prompt yourself. For an unattended script, import the key explicitly with sudo zypper --gpg-auto-import-keys refresh packman, but only after you’ve checked the fingerprint once by hand, because that flag trusts whatever key the mirror serves.
Switch your media packages to Packman
This is the step that does the real work. The multimedia libraries already on your system came from openSUSE in a reduced form, and installing codecs on top of them leaves you with a mix of two vendors that do not fully agree. A distribution upgrade restricted to Packman, with vendor changes allowed, replaces them with the Packman builds in one transaction.
sudo zypper dup --from packman --allow-vendor-changeOn the 16.1 lab VM zypper planned 21 upgrades, 21 vendor changes and 4 new libraries, a 34.2 MiB download. The screenshots show zypper’s -n flag because the lab ran unattended. Leave it off and answer y yourself, since -n would also reject any new signing key:
Read the list before you confirm. The FFmpeg 7 libraries (libavcodec61 and friends) and the VLC packages move to Packman, which you’d expect, but so does Mesa, the graphics stack. That’s fine as long as Packman’s Mesa matches your release, and on 16.1 it does: both sides were version 26.0.7. Three of the four new packages, libx264-165, libx265-215 and libvvenc1_14, are the encoders openSUSE can’t ship. The fourth, libxvidcore4, comes from the openSUSE repository as a dependency.
Skip this step and run only the install below, and you end up with Packman codec plugins loading openSUSE’s reduced libraries. Playback then fails in ways that look random. Run the dup --from packman first, every time you set up a new machine.
Install the codec set
With the libraries switched, install the pieces that carry the actual codecs: the full FFmpeg and the two GStreamer add-ons, gstreamer-plugins-bad-codecs and gstreamer-plugins-ugly-codecs, which GNOME Videos and other GStreamer apps use:
sudo zypper install --from packman --allow-vendor-change ffmpeg gstreamer-plugins-bad-codecs gstreamer-plugins-ugly-codecsYou don’t need to know the exact package name for FFmpeg. zypper reports that ffmpeg isn’t a package name, resolves it as a capability and picks ffmpeg-8, so 20 new packages come in at 13.1 MiB:
Notice that FFmpeg 8 brings its own library set (libavcodec62), while the FFmpeg 7 libraries from the previous step stay installed. That isn’t a conflict. VLC and other apps built against FFmpeg 7 keep using the 7 libraries, the ffmpeg command uses the 8 series, and both sets now come from Packman. You’ll also notice the Packman -codecs add-ons are version 1.28.8 while openSUSE’s base GStreamer plugins are 1.28.5; that pairing worked in the lab, because Packman only ships the add-ons and openSUSE ships the base.
Check that the codecs work
Start with FFmpeg, since it’s the quickest way for you to see whether the patent-encumbered formats are really there. Ask for its version, then filter its codec list for the four formats worth checking.
ffmpeg -version | head -2
ffmpeg -hide_banner -codecs 2>/dev/null | grep -E ' (h264|hevc|aac|mp3) 'You should see FFmpeg 8.1.3 and a line for each codec with both decoders and encoders, including libx264, libx265, libfdk_aac and libmp3lame:
The vendor check at the bottom of that capture matters more than the version. Run the same query on your machine:
rpm -q --qf '%{NAME} %{VERSION} %{VENDOR}\n' libavcodec61 libavcodec62 ffmpeg-8 vlc gstreamer-plugins-libavIf vlc or libavcodec61 still reads SUSE LLC or openSUSE, the vendor switch didn’t run, so go back one section. gstreamer-plugins-libav staying with SUSE is expected, because Packman has no build of it for 16.1. Next, make a short H.264 video with AAC audio from the Packman FDK encoder, which proves both encoders work and gives you a file to test playback with:
ffmpeg -hide_banner -f lavfi -i testsrc=duration=2:size=320x240:rate=15 -f lavfi -i sine=frequency=440:duration=2 -c:v libx264 -pix_fmt yuv420p -c:a libfdk_aac -y test.mp4
ffprobe -v error -show_entries stream=codec_name,profile,pix_fmt -of compact test.mp4The -pix_fmt yuv420p matters: without it libx264 keeps the test pattern’s full colour and writes High 4:4:4, a profile many hardware and software decoders refuse. The run ends with the libx264 statistics, and ffprobe confirms what landed in the file. If either encoder were missing, FFmpeg would stop with an unknown encoder error instead:
[libx264 @ 0x563ccb44b6c0] kb/s:38.34
stream|codec_name=h264|profile=High|pix_fmt=yuv420p
stream|codec_name=aac|profile=LCDesktop players do not use the ffmpeg command, so you should test the GStreamer side too. This is where the lab turned up the one surprise of the refresh. Ask GStreamer for its libav H.264 decoder again:
gst-inspect-1.0 avdec_h264If any GStreamer tool ran before the vendor switch, as in the first section of this guide, it still prints No such element or plugin 'avdec_h264'. Nothing is broken. GStreamer keeps a per-user registry cache in ~/.cache/gstreamer-1.0 and only rescans a plugin when the plugin file itself changes. The vendor switch replaced libavcodec61 underneath the libav plugin without touching the plugin, so the cache still lists the decoders the stripped openSUSE library offered. On a desktop, expect this even if you skipped that check, because thumbnailers and media apps build the cache as soon as you log in. Delete the cache and GStreamer rebuilds it on the next run:
rm -rf ~/.cache/gstreamer-1.0
gst-inspect-1.0 avdec_h264 | head -3Now force a real decode. The video/x-raw and audio/x-raw caps make the pipeline fail unless a decoder turns the file into raw frames, which a plain decodebin ! fakesink test doesn’t check. The last command asks VLC which decoder modules it picked for the same file:
gst-launch-1.0 -q filesrc location=test.mp4 ! decodebin ! video/x-raw ! fakesink && echo VIDEO_DECODE_OK
gst-launch-1.0 -q filesrc location=test.mp4 ! decodebin ! audio/x-raw ! fakesink && echo AUDIO_DECODE_OK
timeout 20 cvlc -vv --play-and-exit --vout dummy --aout dummy test.mp4 2>&1 | grep -E 'using (video )?decoder module|using audio decoder' | sort -uAfter the cache reset, avdec_h264 shows up with primary rank, both decode tests pass, and VLC reports its avcodec module for the video:
On a desktop, close and reopen any media app that was already running, since each app reads the registry when it starts. The same cache lists avdec_h265 and avdec_aac too, so H.265 and AAC files play through the same plugin.
Before moving on, run down this checklist:
- You see FFmpeg 8.1.3 or newer, with libx264 and libx265 among the encoders.
- You see
http://packman.links2linux.deas the vendor forvlcandlibavcodec61. - You get
VIDEO_DECODE_OKandAUDIO_DECODE_OKfrom the GStreamer test file. - You can open one of your own MP4 or MP3 files in VLC or GNOME Videos and it plays.
If all four hold, you’re done with the core setup and can delete test.mp4. The remaining sections only matter if you added Packman with the older 16.0 line, or you want to know what happens on the next upgrade.
Re-point a Packman repo you added for 16.0
Earlier versions of this guide, like most guides written for 16.0, hard-coded openSUSE_Leap_16.0 in the repository URL. After you upgrade to 16.1, that line keeps refreshing without a single warning, which is why it’s easy to miss. To see what it does, the lab VM got the 16.0 folder added on top of 16.1, followed by a dry run of the vendor switch.
zypper stops with 6 problems. The 16.0 tree offers Mesa 24.3.3, built against a SPIRV-Tools library that 16.1 no longer ships, while your system runs Mesa 26.0.7. The first proposed solution starts by removing your installed Mesa, so answer c at the Choose from above solutions prompt if you ever see it on a desktop. Don’t pick a solution just to make the error go away.
You cannot change a repository URL with zypper modifyrepo, so the fix is to remove the old entry and add the version-proof one. Your installed packages and the trusted key stay where they are:
- Remove the pinned entry with
sudo zypper removerepo packman. - Add the
$releaseverline from the Add the Packman repository section, single quotes included. - Refresh and run the vendor switch again so every media package moves to the matching 16.1 build.
Here are the same three steps as commands you can paste in one go:
sudo zypper removerepo packman
sudo zypper addrepo -cfp 90 'https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/' packman
sudo zypper refresh packman
sudo zypper dup --from packman --allow-vendor-changeCheck the result with grep baseurl /etc/zypp/repos.d/packman.repo. It should print the line with $releasever still in it:
baseurl=https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/On the lab VM, where the 16.0 dry run had been cancelled, that last dup was the full 21-package vendor switch shown earlier. A machine that already took packages from the 16.0 tree should get the same 16.1 builds from it, though that path wasn’t tested here. If you’re about to move a 16.0 machine to 16.1, re-point Packman before the upgrade rather than after. The Leap upgrade guide covers the minor-version dup itself.
Keep the codecs working after upgrades
Do I still need Packman if Leap already has the openh264 repository?
Yes. The openh264 repository gives Firefox and GStreamer a basic H.264 decoder for video calls, but you don’t get the full FFmpeg, the x264 and x265 encoders or the Packman VLC build from it. You can see the difference in the before and after gst-inspect-1.0 checks above: x264enc and the libav avdec_h264 only appear once the Packman packages are in.
Will a normal system update undo the switch?
No. Packman has priority 90 and zypper keeps a package with its current vendor, so sudo zypper up keeps pulling the Packman builds. After a minor-version upgrade it’s a good habit to run sudo zypper dup --from packman --allow-vendor-change once more, so anything the upgrade pulled from openSUSE moves back to Packman. With the $releasever line you won’t have to touch the repository itself.
Once your media plays, the rest of the desktop setup is in things to do after installing Leap 16, and apps that bundle their own codecs are easier to get through Flatpak and Flathub on Leap. For more repository work like this, keep the zypper command reference nearby, and if you haven’t installed the system yet, the Leap 16 installation walkthrough starts from the ISO. The Packman project lists its mirrors and package search on the Packman website.
