Support writing to video loopback: Libavdevice and set muxer

[Jamedjo]

What

• Add optional libavdevice support
• Adds --muxer option for setting output format when it can not be guessed from the filename
• Adds --pixel-format option needed to set yuv420p so video loopback output is compatible with zoom
• Fix segfault when codec->pix_fmts does not list any supported formats.

Why

Allows wf-recorder to write out to various devices, and in particular the video4linux2 loopback. This can be picked up as a virtual webcam in screen-sharing applications like zoom, or can be displayed within a window with programs like GUvcView.

Usage

1. Install libavdevice-dev and v4l2loopback. On my system the latter was packaged as v4l2loobpack-utils and v4l2loopback-dkms.
2. modprobe v4l2loopback
3. v4l2-ctl --list-devices to confirm the "Dummy video device" is present, and v4l2-ctl --device=/dev/video2 --info to get further info
4. wf-recorder --muxer=v4l2 --codec=rawvideo --file=/dev/video2 to start screen output. For zoom add pixel-format=yuv420p.
5. Watch it! I installed GUvcView to help with this: guvcview --device=/dev/video2 --gui=none. You can also ffplay /dev/video2.

[Jamedjo]

Two things of note to reviewers:

1. There are some warnings from FFmpeg in style of [video4linux2,v4l2 @ 0x7fe5b4000c80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28061 >= 28061
2. It might be preferable to limit the framerate if that is possible. While I was experimenting and had it set to AV_PIX_FMT_YUV420P it consumed 100% of a CPU core and and at higher FPS than would be needed

[ammen99]

Thanks for adding this, seems a useful thing to have 👍
I haven't had the time to test it yet, but the code looks good.

[ammen99]

@Jamedjo Sorry for the long delay, I had also forgotten there was already another rather big PR waiting to be merged. Can you please rebase this on top of master? I also merged #42 so you can drop it from this PR.

[klardotsh]

I tried using this with OBS and while the framerate hit in-game was mostly livable, the output recording was beyond the point of choppy (effectively PowerPoint mode). In X11 OBS records pretty fluidly.

Not sure if this is something even addressable in this PR, but figured I'd bring it up. I can put together a clean recording (lots of background noise in my test recording) for demo purposes if desired.

Update: compared against wlrobs - sway's CPU usage goes to 100% with wlrobs (unlike with wf-recorder), but the output recording is basically equally as smooth as what I see during gameplay on my actual monitor.

[ammen99]

@klardotsh I guess that piping through a file and then OBS picking that up can introduce significant delays. I would consider this a problem only if such choppy recording happens when using only wf-recorder to directly write to a file.

[klardotsh]

@ammen99 For giggles I went ahead and tested this branch/fork with recording straight to an MP4 file and it seems to be smooth, so indeed it's something with OBS's recordings. OBS's preview pane seems to render smoothly with this branch's V4L2 loopback device, so I'm assuming screensharing (ex. over Zoom/Hangouts/etc.) would be smooth too, and it's just OBS save-to-disk (and likely Twitch streaming, though I haven't tested that yet) that's broken.

tl;dr nevermind!

[RX14]

I've rebased this patch on master, and by turning off "use buffering" in the v4l2 source in obs, I have a silky smooth stream!

Could this be pushed for a merge? My rebase is here: https://github.com/RX14/wf-recorder/commits/jej/loopback-support

I edited the meson.build diff a bit, to make it cleaner.

[ammen99]

@RX14 thats great, thanks. Can you open a new PR?

[RX14]

Ended up finding https://hg.sr.ht/~scoopta/wlrobs, but, sure I'll open a PR of my branch.

[ammen99]

As discussed, we merged #53 which contains all of this PR. Thanks @Jamedjo for the initial work on this!

[tsujp]

This shows up as semi-reasonable quality for me on my end but the person viewing my "webcam" gets garbage, probably sub-320p-type quality. Is there a method using v4l2loopback and wf-recorder, similiar to that described here, that results in higher quality? This is not a bandwidth issue etc as on the same machine under the same network conditions using X I could stream 1440p meetings fine.