https://bugs.kde.org/show_bug.cgi?id=476186
jidc...@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jidc...@gmail.com
--- Comment #12 from jidc...@gmail.com ---
I hope this question is still relevant.
I also notice that the quality when recording in h264 is indeed terrible. It’s
acceptable for personal use, but if you want to record video for documentation,
it looks awful. Overall, I understand that it's done this way to ensure quick
performance and general functionality.
I'll attach some examples of window captures recorded in h264 and vp9:
https://drive.google.com/drive/folders/1Qo5bKJvvQLNpFmeZhx_-7B4CfpI5hgL9?usp=sharing
You can see that vp9 records much better, but my laptop is fairly old and
starts to lag on vp9, resulting in jerky screen-captured videos. I’ve also
included a screenshot showing CPU utilization during video encoding.
Some information about my system:
- **Operating System:** openSUSE Tumbleweed 20241025
- **KDE Plasma Version:** 6.2.2
- **KDE Frameworks Version:** 6.7.0
- **Qt Version:** 6.8.0
- **Kernel Version:** 6.11.5-1-default (64-bit)
- **Graphics Platform:** Wayland
- **Processors:** 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
- **Memory:** 23.3 GiB of RAM
- **Graphics Processor:** Mesa Intel® UHD Graphics 620
- **Manufacturer:** LENOVO
- **Product Name:** 20L8A03KMZ
- **System Version:** ThinkPad T480s
Perhaps we should try detecting hardware acceleration support, and if
available, use it.
For example, in openSUSE Tumbleweed, ffmpeg is compiled with support for all
popular hardware acceleration technologies.
ffmpeg -hide_banner -hwaccels
Hardware acceleration methods:
vdpau
cuda
vaapi
qsv
drm
vulkan
ffmpeg -hide_banner -encoders 2>&1| grep 264
V....D libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
(codec h264)
V....D libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
RGB (codec h264)
V....D libopenh264 OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
(codec h264)
V....D h264_amf AMD AMF H.264 Encoder (codec h264)
V....D h264_nvenc NVIDIA NVENC H.264 encoder (codec h264)
V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel
Quick Sync Video acceleration) (codec h264)
V..... h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264)
V....D h264_vaapi H.264/AVC (VAAPI) (codec h264)
So, we only need to detect if ffmpeg supports it, and if it does, whether
there’s a graphics card available for the required encoder. In the case of
VAAPI/Intel, we could perhaps call `vainfo`. For AMD or NVIDIA, unfortunately,
I don’t have experience or equipment to investigate further.
Then, we could write a switch case for each scenario, ensuring stable and fast
performance on systems without HW acceleration and good quality without
performance loss on systems with HW acceleration. In the settings, we could
note whether hardware acceleration is detected, such as VAAPI/Intel, etc., or
indicate if it’s unavailable and that video quality may be poor.
What do you think?
--
You are receiving this mail because:
You are watching all bug changes.
