You should not have to “block” ( actually lock ) packages. Actually that might cause issues. Re. the Cisco stuff: search “openSUSE openh264 Cisco” on Google. All the info is out there.
No, it is not (anymore). That was the exact reason of introducing noopenh264 - to build components working with openh264 without requiring Cisco library itself.
I wanted to conclude my guides for those a bit unsure:
On my laptop, with stock and up-to-date Tumblweed, I can now play h264 videos. libopenh264-8 is not a dummy anymore, zypper serach h264:
With confidence from this and the recent posts of the library beeing available, I removed the locks on my main PC:
~> sudo zypper removelock ffmpeg-7 gstreamer-plugins-bad
2 locks have been successfully removed.
Thereafter, I updated with sudo zypper dup:
In my case (as i was lazy updating) there where a lot of upgrades, downgrades and removals. One specific package that was listed for removal is gstreamer-plugin-openh264, the package that kept h264 playback working until now. In the list of packages to update was libopenh264-8 the no-more-dummy package that should ensure h264 playback from now on.
It can be tough to find the libopenh264-8 in the long list, so i cheated with sudo zypper dup | grep "h264". The scrolling through the long list of text, the h264 was marked red by grep. I closed the command with CTRL-C.
After the update was done, I restarted (just to make sure no old library hanging around in memory could fool me), and tested playing a file needing h264 decoding, and it worked. Success!
I know it’s been a while since this issue has started. But it is safe now to remove gstreamer-plugin-openh264 now right and libopenh264-8 is the confirmed successor correct?
The following 3 packages are going to be upgraded:
gstreamer-plugins-bad gstreamer-plugins-bad-codecs gstreamer-plugins-bad-lang
The following 5 packages are going to be REMOVED:
gstreamer-plugin-openh264 libIex-3_2-31 libIlmThread-3_2-31 libOpenEXR-3_2-31 libOpenEXRCore-3_2-31
S | Name | Summary | Type
---+--------------------------------+------------------------------------------------+-----------
| gstreamer-1.20-plugin-openh264 | Gstreamer openh264 plugin | package
| gstreamer-1.20-plugin-openh264 | Gstreamer openh264 plugin | srcpackage
| gstreamer-1.22-plugin-openh264 | Gstreamer openh264 plugin | srcpackage
il | gstreamer-plugin-openh264 | Gstreamer openh264 plugin | package
| h264enc | An advanced CLI shell script for MEncoder | package
| h264enc | An advanced CLI shell script for MEncoder | srcpackage
| libheif-openh264 | Plugin OpenH264 decoder in HEIF | package
| libheif-openh264-debuginfo | Debug information for package libheif-openh264 | package
i | libopenh264-7 | H.264 codec library | package
i | libopenh264-8 | H.264 codec library | package
i | libopenh264-8-32bit | H.264 codec library (dummy implementation) | package
| libopenh264-devel | Development files for openh264 | package
i | mozilla-openh264 | H.264 codec support for Mozilla browsers | package
| openh264 | H.264 codec library | srcpackage
I do not know if it is safe as my use of video is such that I do not know if h264 is used. I did recently remove the Packman libraries.
I wanted to know more and downloaded Big_Buck_Bunny_1080_10s_10MB.mp4 from:
If I run vlc/kaffine from the command line I see that things are sometimes working but sometimes fine but pretty often I get:
[libopenh264 @ 0x7f1d6c01fa40] DecodeFrame failed
But that does not answer your question, your system is likely different, so why don’t you test h264 with you current install, if it is fine (try vlc/kaffine multiple times) do the update and try once more. If it does not work revert back to the previous state.