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

[Quack Doc]

> 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.

Ah I see, It would indeed be nice to have

> 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.)

while it does start reliably, and seems to get the proper dimensions,
it doesn't actually connect to the pipewire video source node,
encoding just black frames. below is the ffmpeg output. I am currently
running pipewire-git commit hash 3e5a85b3 as well as stable 1:1.2.2-1

This issue may be a cosmic specific issue however.

[Parsed_pipewiregrab_0 @ 0x647dc471c440] stream state: "connecting"
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Starting screen capture ...
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Library version: 1.3.0
[Parsed_pipewiregrab_0 @ 0x647dc471c440] stream state: "paused"
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Ignoring non-Format param change
    Last message repeated 1 times
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Negotiated format:
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Format: 11 (Spa:Enum:VideoFormat:RGBA)
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Size: 1280x960
[Parsed_pipewiregrab_0 @ 0x647dc471c440] Framerate: 60/1
[Parsed_pipewiregrab_0 @ 0x647dc471c440] stream state: "error"
[Parsed_pipewiregrab_0 @ 0x647dc471c440] PipeWire core error: error
alloc buffers: Invalid argument (id=2, seq=15, res=-32: Broken pipe)


On Tue, Aug 6, 2024 at 11:34 AM François-Simon Fauteux-Chapleau
<francois-simon.fauteux-chapleau at savoirfairelinux.com> wrote:
>
> ----- 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.)
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".