Notices by Jeff Fortin T. (nekohayo@mastodon.social)

@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

@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
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.

@aral @nah @fvsch @sonny @matt

Two GNOME cycles, when people are actively working on accessibility this year, is a long time.

Before panicking, consider: a reason it's been targetted to GNOME 48 (a year from now) and not 47 is, devs are collectively aware that not everything is ready for this to happen in 47, and that it is reasonably likely that a11y would be working by 48.

The cited link (!99) says pointblank it is a blocker.

@aral @farshidhakimy
It's a bug, generally speaking.
These are the relevant issues you can subscribe to:

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/85
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6187
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2318

@aral Did you see https://blogs.gnome.org/a11y/2023/10/27/a-new-accessibility-architecture-for-modern-free-desktops/ a few months ago?

Seeing #FOSDEM photos streaming across my Mastodon feed does not spark joy in me this year. Not that I have FOMO (you can't convince me to cross the oceans for "spend 2 days unsuccessfully looking for each other in jampacked hallways & rooms while jetlagged"), but rather because nobody is wearing masks in the pictures I've seen so far, and I worry about this laissez-faire 12,000-attendees indoors event potentially leading to more of my fellow FLOSS community members riddled with long CoViD.

A list of recent hostile moves by #Google's #Chrome team; handy for sharing with your entourage, to explain why they should stop using #Chromium / #GoogleChrome and use #Firefox or #Epiphany as their main #web #browser :

* The "Manifest v3" sabotage of content blocking extensions: https://www.theverge.com/2022/6/10/23131029/mozilla-ad-blocking-firefox-google-chrome-privacy-manifest-v3-web-request
* The attempted sabotage of #JPEGXL: https://www.cnet.com/tech/computing/chrome-banishes-jpeg-xl-photo-format-that-could-save-phone-space/
* #WebEnvironmentIntegrity a.k.a. #DRM for whole websites would hurt the web, #opensource browsers and OSes: https://arstechnica.com/gadgets/2023/07/googles-web-integrity-api-sounds-like-drm-for-the-web/