Emmanuele BassiOct 15, 2023
This is utterly horrific holy fuck
Show threadeladOct 15, 2023
@ebassi this basically reads "hello I'm writing malware plz help"
Show threadEmmanuele BassiOct 15, 2023
@elad either that, or it’s a case of somebody working in a terrible environment
Show threadCassidy James   Oct 15, 2023

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

Show threadCassidy James   Oct 15, 2023
@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?
Show threadIan Douglas Scott

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

Oct 15, 2023 at 8:36pmWeb
Show threadCassidy James   Oct 15, 2023
@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.
Show threadIan Douglas ScottOct 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).
Show threadIvan MolodetskikhOct 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".

Show threadIan Douglas ScottOct 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.

Show threadIvan MolodetskikhOct 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