Hardware encoder fails with window sharing

[vchernin]

System Info

• 2.0.1
• Fedora 35
• GNOME 41, HiDPI (200% scaling) setup
• Wayland
• Flatpak

Describe the bug Experimental hardware encoder fails with window being shared but not full screen. Bug only when using hardware encoder, without it this works.

To Reproduce

1. Launch Kooha with experimental hardware encoder
2. Try to share a specific window
3. See error:

ERROR kooha::backend::recorder > Error from record bus: Error { domain: gst-stream-error-quark, code: 1, message: "Internal data stream error." } (debug Error(Message { ptr: 0x7fbc94003b20, type: "error", seqnum: 113, src: Some("pipewiresrc0"), structure: Some(GstMessageError, gerror=(GError)NULL, debug=(string)"../libs/gst/base/gstbasesrc.c\(3127\):\ gst_base_src_loop\ \(\):\ /GstPipeline:pipeline0/GstPipeWireSrc:pipewiresrc0:\012streaming\ stopped\,\ reason\ error\ \(-5\)", details=(structure)"details\,\ flow-return\=\(int\)-5\;";) }))

Expected behavior Window sharing works with hardware encoder, like sharing full screen does.

Screenshots

Additional context

Relevant log:

0:00:10.872354236     2 0x7f4a6408f920 FIXME                default gstutils.c:4025:gst_pad_create_stream_id_internal:<pipewiresrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
[I][20739.624393][     impl-node.c:  358 node_update_state()] (kooha-0) creating -> running
 INFO  kooha::backend::recorder          > Pipeline state set from Null -> Ready
 INFO  kooha::backend::recorder          > Pipeline state set from Ready -> Paused
0:00:12.080447710     2 0x7f4a640732a0 FIXME               basesink gstbasesink.c:3388:gst_base_sink_default_event:<filesink> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
 INFO  kooha::backend::recorder          > Pipeline state set from Paused -> Playing
0:00:12.412239282     2 0x7f4a6408f980 ERROR                default video-frame.c:181:gst_video_frame_map_id: invalid buffer size 0 < 14745600
0:00:12.412281147     2 0x7f4a6408f980 WARN             videofilter gstvideofilter.c:296:gst_video_filter_transform:<videoconvert0> warning: invalid video buffer received
0:00:12.419118383     2 0x7f4a6408f980 ERROR                default video-frame.c:181:gst_video_frame_map_id: invalid buffer size 0 < 14745600
0:00:12.419156882     2 0x7f4a6408f980 WARN             videofilter gstvideofilter.c:296:gst_video_filter_transform:<videoconvert0> warning: invalid video buffer received
0:00:12.432534911     2 0x7f4a6408f980 ERROR                default video-frame.c:181:gst_video_frame_map_id: invalid buffer size 0 < 14745600
0:00:12.432573893     2 0x7f4a6408f980 WARN             videofilter gstvideofilter.c:296:gst_video_filter_transform:<videoconvert0> warning: invalid video buffer received
0:00:13.324468026     2 0x7f4a6408f980 ERROR                default video-frame.c:181:gst_video_frame_map_id: invalid buffer size 0 < 14745600
0:00:13.324522291     2 0x7f4a6408f980 WARN             videofilter gstvideofilter.c:296:gst_video_filter_transform:<videoconvert0> warning: invalid video buffer received

[SeaDve]

I haven't found yet the exact root cause of the issue, but I could reproduce it. It's also one of the main reason why hardeare encoding is still not the default