[FFmpeg-devel] [PATCH v2] libavfilter: add PipeWire-based grab

[François-Simon Fauteux-Chapleau]

----- On Aug 4, 2024, at 4:11 PM, Quack Doc quackdoctech at gmail.com wrote:
> I see, I tried to pull the patch and test it. How does invocation with
> node work? I'm a bit confused with the invocation. For testing I tried
> using "gamescope --headless -- glxgears" to generate a raw pipewire
> stream. (cameras will automatically create one with pipewire) used
> "pw-dump | jq '.[] | select(.info.props["node.name"] == "gamescope") |
> .id'" to get the node id and tried to use it but it still seemed to
> trigger the portal. If you have a camera installed I use the below
> command to dump all of the video sources, gamescope and cameras
> included
> 
> pw-dump | jq '.[] | select(.info.props["media.class"] ==
> "Video/Source") | .info.props."node.name" + " | " +
> .info.props."node.description" + " | " + (.id|tostring)'
> 
> does the current patch have a hard requirement on file descriptors to
> not use xdg?

Sorry for the ambiguity in my previous reply. The answer is yes: the current
version of the patch will try to use the XDG portal unless a file descriptor
is provided. The "node" option was meant to be used together with the "fd"
option, not as an alternative to it. So when I said that I thought these
options could be used to bypass the portal, I should have specified I was
thinking of the case where FFmpeg is used by a program as a library (which
is what we're doing at my company); we'll need a different solution if we want
this to work when using the command-line tool. Sorry again for the confusion.

> I did also test xdg capture on cosmic, it seems to only sporadically
> work, usually spitting out the below error. I can spam it to keep
> retrying it until it works
> 
> [Parsed_hwmap_0 @ 0x79fabc003600] Mapping requires a hardware context
> (a device, or frames on input).
> [Parsed_hwmap_0 @ 0x79fabc003600] Failed to configure output pad on
> Parsed_hwmap_0
> [vf#0:0 @ 0x55cf4daff480] Error reinitializing filters!
> [vf#0:0 @ 0x55cf4daff480] Task finished with error code: -22 (Invalid argument)
> [vf#0:0 @ 0x55cf4daff480] Terminating thread with return code -22
> (Invalid argument)
> [vost#0:0/h264_vaapi @ 0x55cf4db38080] Could not open encoder before EOF
> [vost#0:0/h264_vaapi @ 0x55cf4db38080] Task finished with error code:
> -22 (Invalid argument)
> [vost#0:0/h264_vaapi @ 0x55cf4db38080] Terminating thread with return
> code -22 (Invalid argument)
> [out#0/mp4 @ 0x55cf4db37800] Nothing was written into output file,
> because at least one of its streams received no packets.

Does it work reliably if you don't try to use hardware acceleration?
(You'll have to set the "enable_dmabuf" option to 0 for that.)