KPipeWire currently only supports software h.264 encoding via libx264. libx264 cannot be safely distributed by default in countries with restrictive software patent legislation. OpenH264 is an open source h.264 encoder distributed by Cisco, making use of their H.264 license (https://www.openh264.org/). It allows distributions like Fedora to support h.264 without much fuss, and in particular for the Fedora Asahi Remix we have hooked it up to be installed automatically, so H.264 works out of the box in most apps. Since KPipeWire uses libavcodec, and libavcodec has openh264 integration, it should be pretty easy to generalize the code to not explicitly hardcode libx264 but rather allow openh264 as well. The codec name in this case is `libopenh264`. Quality controls have to be validated to make sure they work well on both codecs (see bug 476186 for the story on libx264, I don't know off the top of my head what the appropriate quality controls are for openh264 but I can investigate). Where libx264 is available, it should be preferred, since x264 is widely considered to be the best h.264 encoder in the world and particularly well optimized. In the future there will be more h.264 encoder options, e.g. for Fedora Asahi we plan to expose the internal hardware encoder as a h264_v4l2m2m implementation. This is also supported by ffmpeg. So it might be worth setting things up so that, at the very least as a fallback, "any codec that can encode h.264" is selected. I believe this should be possible with ffmpeg by requesting the `h264` codec and letting it pick an appropriate encoder. That will make h.264 encoding at least work (if perhaps without ideal quality control) on any machine that has a usable codec, without explicitly handling them all in KPipeWire.
(In reply to Hector Martin from comment #0) > at the very least as a fallback, "any codec that can encode h.264" is selected. I think we should be a bit more cautious since this is lossy encoding we are talking about. I found out about a week ago that openh264 only supports Constrained Baseline Profile, which is the lowest class intended for low-cost mobile applications like, a decade ago. And I'm not even talking about fancy alpha channels or high bitdepths, Baseline Profile very notably lacks B-frames. It's misleading to claim openh264 is a drop-in h264 replacement, not in this day and age. I'd be pressed to find out my screen recording was terribly compressed and full of artifacts (especially for text). The encoder's constraints should at least be clear to the end-user and other available codecs should be favored. https://github.com/cisco/openh264/issues/2949#issuecomment-388658110 Also hwaccel is part of the same native/in-house ffmpeg encoder/decoder pipeline (it passes it off to hwaccel after parsing headers), so once we do our part IIUC avcodec_find_decoder() should default to hwaccel else it will fallback to native sw. So the generic avcodec init call sounds like a good idea, and no one should have no worry about V4L2M2M and whatnot.
OpenH264 supports constrained baseline, main, and high profiles. I know this because I implemented it for OBS Studio: https://github.com/obsproject/obs-studio/pull/8529
(In reply to Neal Gompa from comment #2) > OpenH264 supports constrained baseline, main, and high profiles https://github.com/cisco/openh264#encoder-features > Encoder Features > Constrained Baseline Profile up to Level 5.2 (Max frame size is 36864 macro-blocks)
Considering it also only lists CBP for *decoding* and yet it can obviously decode higher profiles (otherwise it would be useless for the web), I think that feature list is clearly not exhaustive.