Recent searches
Search options
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.)
@aral
I am under the impression that the GNOME Shell screen recorder is optimized for variable framerate recording with minimum amount of information encoded, resulting in very small filesizes compared to other screen recorders.
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.
@nekohayo Hi Jeff, thanks for taking the time to reply and for providing background but I hope you realise this is exactly why I stopped filing bugs for issues like this on #GNOME projects. It makes perfect sense for a tool made for the GNOME team to be for “quick partial recordings to attach to bug reports” where quality doesn’t matter. For anyone else who uses a screen recorder, quality is what matters. But were I to report it, my issue would be closed with this justification.
@nekohayo (Case in point: the exact issue that made me lose a day of work was reported three years ago: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3371 and the reason it’s still an issue is not because of an inability to fix the issue but a reluctance to see the problem as an issue since, given the use case you stated above, the low quality isn’t a bug but a feature as the tool is optimised for a different use case to one that people outside the GNOME dev team have.)
@aral 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".
@aral
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: https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/c61685e617
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
@nekohayo 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.
@aral you do realize that the person who worked on and maintaining OBS Studio's screencasting code is also the person working on GNOME Shell's screencasting, right?
To name that person, Georges Stavracas, i.e. "Someone on GNOME team" as you like to put it.
And please, don't shame us for making you "lose a day of work". At least you get money from using GNOME. Most of us don't get paid for developing anything within the GNOME umbrella.
Ok, pretend I didn’t say anything. And you heard nothing.
No, some of us (rightfully) can't pretend we haven't heard from someone with 43K followers who keeps spamming the "#GNOME" hashtag in their posts.
@aral @nekohayo lots of FOSS seems to me to be technology-centric, rather that user-valie-centric.
Software is designed around what (selected) tech can do, rather than making tech to do what user needs.
With that focus in mind of programmers, FOSS often contains lots of options and features, but fails to let user do the most value task(s) efficiently (or at all).
@aral @nekohayo It's understandable, lots of FOSS developers aren't product developers, but technical people - coders and programmers, that have difficulty to look at things from perspective of the end user.
But, that's not a blame. They do it and contribute for free, because they believe in FOSS values. It just needs to add product people to the mix.
I, as a software developer, love, if product owners do this job, because they can do it better than me.
@aral @nekohayo IMO, the whole GNOME 3 rework got it much better with UX.
Yes, the first releases up to around GNOME 3.18 (don't remember exactly) were buggy and lacked lots of features.
But, it's easy to use by non-technical people.
My wife uses it, and loves it. Especially the activity overview showing all windows at once.
@aral @nekohayo 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.
@aral @nekohayo
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).
