| Summary: | OpenH264 codec support | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] KPipeWire | Reporter: | Hector Martin <marcan> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | aleixpol, deadmeu, eyn, jlp, m.kurz, m.mcnutt, nate, ngompa13, timaeos, zawertun |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kpipewire/-/commit/bdb1152e85fdfb7456c6aa65cf41fe0f375fe30b | Version Fixed In: | 6.2.0 |
| Sentry Crash Report: | |||
|
Description
Hector Martin
2023-10-28 08:20:03 UTC
(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. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/152 Git commit e17793a3b023f26411001093bb2d5934adf715c7 by Fabian Vogt. Committed on 16/07/2024 at 11:24. Pushed by fvogt into branch 'master'. Add encoder using libopenh264 On some distributions, libopenh264 is the only encoder available OOTB. Add support for it and use it as fallback. M +1 -0 src/CMakeLists.txt A +106 -0 src/libopenh264encoder.cpp [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] A +28 -0 src/libopenh264encoder_p.h [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] M +1 -1 src/pipewirebaseencodedstream.cpp M +11 -0 src/pipewireproduce.cpp https://invent.kde.org/plasma/kpipewire/-/commit/e17793a3b023f26411001093bb2d5934adf715c7 Git commit bdb1152e85fdfb7456c6aa65cf41fe0f375fe30b by Fabian Vogt. Committed on 17/07/2024 at 17:55. Pushed by fvogt into branch 'Plasma/6.1'. Add encoder using libopenh264 On some distributions, libopenh264 is the only encoder available OOTB. Add support for it and use it as fallback. (cherry picked from commit e17793a3b023f26411001093bb2d5934adf715c7) M +1 -0 src/CMakeLists.txt A +106 -0 src/libopenh264encoder.cpp [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] A +28 -0 src/libopenh264encoder_p.h [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] M +1 -1 src/pipewirebaseencodedstream.cpp M +11 -0 src/pipewireproduce.cpp https://invent.kde.org/plasma/kpipewire/-/commit/bdb1152e85fdfb7456c6aa65cf41fe0f375fe30b |