FFS, GNOME! Just wasted a day of editing video because the built-in screen recorder records screencasts at such a low quality that I ended up with keyframe artefacts / ghosting in my captures.
Bloody hell…
And is there any way to set the quality? Is there ever!
[Edit] Use OBS. (Thanks everyone in the replies.)
(Don’t use GNOME’s built-in screen recorder if you’re posting HD+ videos.)
#gnome #video #screenRecorder #quality #linux #foss
The quality of the screen capture in GNOME’s screen recorder
Just wasted a day of editing thanks to this. See the ghosting in the latter part of the video and the low quality in general.Vimeo
This entry was edited (1 week ago)
Jeff Fortin T.
in reply to Aral Balkan • • •It is light on resources (I suspect it is much more efficient for encoding) and great for quick partial recordings to attach to bug reports (small filesizes), which is my primary usecase for it; it does not seem to be meant for files intended for editing in a NLE.
Aral Balkan
in reply to Jeff Fortin T. • • •Aral Balkan
in reply to Aral Balkan • • •Screencast produces video with very low FPS and frequent graphical artifacts (#3371) · Issues · GNOME / gnome-shell · GitLab
GitLabJeff Fortin T.
in reply to Aral Balkan • • •I think you misunderstand.
I'm not a GNOME Shell developer, it was just my educated guess of the probable practical performance+legal tradeoff that occurred a decade ago.
Nobody closed nor opposed @YaLTeR's issue 3371 that you linked there, nor other issues AFAIK. It's just impossible without HW encoding for VP9/AV1, IMHO.
VP8 is the only usable "in software" Free codec out there. I know because (from experience) you typically can't encode VP9 realtime "in software".
Jeff Fortin T.
in reply to Jeff Fortin T. • • •As a user, I remember the era between 2015 and 2020 where GNOME Shell's video screen recorder was *literally unusable* because the VP9 encoder could never keep up and would lock up your computer by filling up the RAM within a minute. I'm not making things up; this commit proves it: gitlab.gnome.org/GNOME/gnome-s…
So, *very much* a technical limitation.
I would have appreciated if you had simply asked politely to begin with, & assumed good faith, rather than immediately publicly smearing #GNOME
Revert "recorder: Switch to vp9" (c61685e6) · Commits · GNOME / gnome-shell · GitLab
GitLabAral Balkan
in reply to Jeff Fortin T. • • •And this is the other reason why I don’t file bug reports any longer.
Me: this feature is not fit for purpose.
Someone on GNOME team: actshaully, according to technical reason #3096… why are you publicly smearing GNOME!
Ok, pretend I didn’t say anything. And you heard nothing.
Jonas
in reply to Aral Balkan • • •Turns out doing real time encoding in software is a hard problem to solve, and turns out most of the good codecs out there are patent encumbered and can't be shipped by default.
Maybe instead of directing rants at volunteers, you could ask *why* things are as they are instead of expecting every feature to be on-par with commercial OSes.
Jonas
in reply to Jonas • • •In case you're actually be interested in what's happening rather than just ranting:
Quite a few people (including me) have been working their asses off on gnome-shell/gstreamer/pipewire for the last two years in order to use hardware encoders out of the box (no large project dared to use hw encoders on linux by default so far). Also we're using the faster h264 sw encoder instead of vp8 in gnome-shell now when available (it must be manually installed on Fedora because patents).