cmdline utility?

[JohannesBuchner]

Hi Jonathan,

Thanks for this cool project. I managed to play with it a bit.

Currently, there seems to be no command line tool out there which can record from wayland. See for example https://stackoverflow.com/questions/58754385/record-linux-wayland-drm-screen-using-ffmpegs-kmsgrab-device-with-superimposed

So I tried to create one in this fork based on your repository. Mostly I removed code. It sort of works, but I still have a few issues (mentioned in the commit):

1. the shut down is not graceful. For mkv this leaves a video file that can be played but the index is broken, while mp4 cannot be played. Good enough for me.
2. the dialog to select a monitor/window pops up, although I only ever have one choice: the "built-in" source, everything. Can I avoid raising this dialog?

In any case, the framework you have developed here for recording is very nice and powerful.

Now for my question:
Would you be interested in adding to your repository a command line utility that allows automatic recording, without displaying a Gtk window?

My interest is in building a recording tool for zoom telecons to keep track of speaking time of each participant (from the participant window). So ideally I would like pipe the output of wayfarer into another postprocessing program that walks through frame by frame.

Cheers,
Johannes

[stronnag]

I (probably) have no interest in maintaining a command line tool, in part because of video integrity issues mentioned. However, please feel free to reuse the wayfarer code in your project.

To your other questions:

1. You need to "catch" application shutdown and enforce EOS on the gstreamer instance; only exiting once the stream has shutdown. If you can't do this, the affects described cannot be avoided.
2. The dialog is generated by the xdg-portal. If you do this once and save / reuse the token, then you can (mainly) avoid further dialogs.

During wayfarer development I built a couple of CLI tools, to speed up development. IIRC, these worked OK (with the token, catching exit etc.). So it is doable. I'm not sure these are in a usable state anymore; the use of portal in particular has changed as it evolved. And because of the requirement to define a recording area, select audio device, other UI options, a GUI seemed more appropriate for most use cases.

I also think "pipe the output" (at least in terms of a classic "streaming" Unix pipe) may be problematic; as you've seen the integrity of the video file is only assured when the stream cleanly terminated.