Mastodawn

elad Oct 15, 2023

@ebassi this basically reads "hello I'm writing malware plz help"

Emmanuele Bassi Oct 15, 2023

@elad either that, or it’s a case of somebody working in a terrible environment

@ebassi @elad I can actually see the use for this in another context (and have considered designing something like it): a timelapse app for artists.

In this context, their “work” is their art, not something imposed by an employer.

It should probably be built into the drawing app or whatever, but I could see the niftiness of a workflow timelapse that captures the various apps you use and whatnot over a long period of time, without having to sit and record an actual video of the entire process.

@ebassi @elad that said, I think such an app could actually just request the screen share portal and then only actually capture an image every minute or however often?

Emmanuele Bassi Oct 15, 2023

@cassidy @elad that’s probably a better option, given that the screen share portal has a permanent user visible component, unlike the screenshot for which only the flash can be used

@ebassi @elad yeah, makes sense. So perhaps they're using some old tool for artists that uses screenshots when it really should use the screen share portal. It sounds terrifying at first but I sometimes watch those kinds of timelapses and feel like it would be a neat tool. 😅

But uh, yeah, hacking the Shell or whatever to just *not* give any feedback of a screenshot is the wrong way for them to go about it. 😜

Mike Rochefort

* #Krita: https://docs.krita.org/en/reference_manual/dockers/recorder_docker.html

@ebassi @cassidy @elad Screen and window capture is useful if you want the entire app view, however some apps provide native canvas or viewport capture for timelapse purposes. For example:

There are also a handful of related add-ons for #Blender that can assist since the native screencast feature was removed in 2.8.

Recorder Docker

The recorder docker allows recording time lapses in Krita.

@omenos @ebassi @elad yeah I'm thinking more like a whole desktop workflow thing where someone might use multiple apps on a big display, or jump between apps as part of their workflow.

Mike Rochefort

@cassidy @ebassi @elad Would this be to record each application into their own stream/save file separately rather than a traditional complete screen capture that can be achieved with tools like OBS?

@omenos @ebassi @elad I hadn't considered each window as its own stream, no. Just like a whole-screen timelapse capture that doesn't have the overhead of actually recording *every* frame to disk.

Mike Rochefort

@cassidy @ebassi @elad For my own clarification, would using OBS set to 1 fps recording or less (e.g 1/60 for 1 frame per minute) and outputting to an image sequence rather than a video format cover this use case?

Oct 16, 2023

@omenos @ebassi @elad yeah I think so

Ian Douglas Scott Oct 15, 2023

@cassidy
@ebassi @elad
If you only need one frame a minute, I think with screencast you'd still have a pipewire stream producing frames at a normal framerate, and just be ignoring most of them? So not a very resource efficient solution, if that matters

(I think you may be able to negotiate a framerate of 1/60 fps over pipewire if both ends support it, but I don't think implementations typically would.)

@ids1024 @ebassi @elad hm, still less disk thrashing than recording the entire thing as a video and timelapsing it later. No idea what the overhead for having the stream open would be though.

Ian Douglas Scott Oct 15, 2023

@cassidy
@ebassi @elad
Yeah. And video encoding overhead, which is probably the largest overhead for actual screencasting and is avoided here. Still non trivial overhead here though if it means copying 60 frames per second from a discrete GPU to main memory for each of 3 4k monitors only to ignore most frames (for the worst case scenario here).

Ivan Molodetskikh Oct 16, 2023

@ids1024 @cassidy @ebassi @elad mutter negotiates max framerate. If the other side wants low fps it will only record and send low fps. Currently minimum-capped at 1 fps in the code though.

It has to do it because it has to set the regular fps property to 0 to mean "variable framerate".

Ian Douglas Scott Oct 16, 2023

@YaLTeR @cassidy @ebassi @elad
It looks like framerate in Pipewire is indeed an `spa_fraction`, so I think it is possible to negotiate a framerate of 1/60 fps or whatever. And then have the client fallback to a higher rate if the desktop environment doesn't support that.

So yeah, seems like a viable solution. Probably not hard to add support for in gnome-shell if it already can negotiate fps with a minimum of 1.

Ivan Molodetskikh Oct 16, 2023

@ids1024 @cassidy @ebassi @elad yeah, just need to lower that minimum fraction a bit, then a client negotiating a low max max fps (yes those are two maxes) should just work, assuming there's no bug in mutter's scheduling

Alonely0 🦀 🇪🇺Oct 15, 2023

@cassidy @ebassi @elad sketchbook on android has an option for this. I've never used it, though.

Jo Shields Oct 15, 2023

@ebassi I think some online exam taking webapps do this

Julia :v_bi::therian:Oct 30, 2023

@ebassi ... Dear god