https://bugs.kde.org/show_bug.cgi?id=476187
Eileen Yoon <e...@gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |e...@gmx.com
--- Comment #1 from Eileen Yoon <e...@gmx.com> ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
