Optionally enable hardware video encoding

[alba4k]

This could be done by allowing to specify extra arguments for wf-recorder. Normally, hw video encoding is enabled via wf-recorder -c h264_vaapi -d /dev/dri/renderD128 (as per their readme)
The benefits could be lower latency, cpu usage and lower power usage. Assuming this can work with the rest of the pipeline. Platforms that use xdg-video-portal for screen capture should be already accelerated by default (can xdph not be used on hyprland over wf-recorder?)

[alba4k]

Ok I tested this a bit and the latency seems to be quite a lot higher when using this (like, 1-2 seconds higher), likely due to h264_vaapi being slower than rawvideo. I think a faster encoding might actually end up outperforming the uncompressed stream in usecases where the network speed is the bottleneck

I did notice cpu usage from wf-recorder going down from 40-50% to around 25%, which would probably also result in considerable power saving.

I can open a pr if you think this is worth investigating further (maybe handled by a --enable-wf-recorder-vaapi flag).

If I were to open a pr, may I ask what the wf-recorder command in capture.py is used for? should that one be touched?

[IlyaP358]

Hello @alba4k, thanks for testing this and sharing the results!

On capture.py that file is only used for the DLNA and Chromecast protocols (HLS streaming). For WFD, the wf-recorder command lives in wfd.py in _start_desktop_wf_recorder() there wf-recorder outputs rawvideo to stdout, and ffmpeg reads it, encodes with libx264 (-tune zerolatency) and sends it over RTP. You'd only need to touch wfd.py.

On vaapi: the +1–2s latency you measured is unfortunately a dealbreaker for WFD as a default, latency is the primary metric for Miracast. That said, as an opt-in flag (e.g. --wfd-wf-recorder-vaapi) for users who consciously want CPU/power savings at the cost of latency, it makes sense. A PR along those lines is welcome =]

also regarding wf-recorder on Hyprland. xdg-desktop-portal-hyprland is already supported. You can use it right now with --wfd-capture-backend portal on Hyprland but it is quite unstable and sometimes during tests I have breaks, why so far I have not been able to figure out and focused specifically on supporting wf-recorder.

wf-recorder is just the default there because it's more straightforward and reliable on wlroots-based compositors.

[alba4k]

I found everything I would need to change already, dw :)

I had also tried the portal backend and it wasn't working, not even opening the picker (while obs works perfectly fine). doesn't really matter tho

I'll clean things up and open a pr when I have time then :)