> The patch already supports passing a file descriptor and a PipeWire node ID > directly via the "fd" and "node" options. The portal is only used if these > values are not provided by the user. > > The original motivation for adding these options was to allow communication > with the portal to be handled outside of FFmpeg, but I imagine they could also > be used on e.g. Weston to bypass the portal entirely.
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? 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. On Fri, Aug 2, 2024 at 3:41 PM François-Simon Fauteux-Chapleau <francois-simon.fauteux-chapl...@savoirfairelinux.com> wrote: > > ----- On Aug 2, 2024, at 12:11 PM, Quack Doc quackdoct...@gmail.com wrote: > > Pipewire video capture is more generic. Some compositors like weston > > support pipewire as a backend without portals. Gamescope also creates a > > pipewire output without need for portals, it would be *really* nice to > > support gamescope capture with this. Pipewire also gives access to video > > devices directly as well without needing portals, which allows > > ergonomically letting multiple apps accsess v4l2 devices for instance like > > firefox and say discord. So being able to support the file descriptor > > directly, or using target-object much like the pipewiresrc gstreamer would > > be greatly appreciated. > > The patch already supports passing a file descriptor and a PipeWire node ID > directly via the "fd" and "node" options. The portal is only used if these > values are not provided by the user. > > The original motivation for adding these options was to allow communication > with the portal to be handled outside of FFmpeg, but I imagine they could also > be used on e.g. Weston to bypass the portal entirely. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
