Screen casting on Asahi Linux fails

[Edowndotdown]

When using this app on Asahi Linux with a MacBook Air M2, the streaming agent encounters issues. It correctly identifies devices such as Apple TV 4K and displays the screen-sharing options, like app or screen, but after selecting share, the Apple TV screen turns black and the AirPlay connection ends. Screen sharing never begins. Using Gnome on Wayland.

[barattac]

I think this may be the same root cause as a failure I just finished debugging on a different VA-API-less machine (headless Ubuntu 24.04 VM, virtio-gpu, GNOME/Wayland, Apple TV 4K / AppleTV14,1). The symptoms match exactly: device is found, the share dialog appears, and the stream dies immediately without ever rendering.

Root cause: the Wayland capture pipeline hardcodes vapostproc (a VA-API element) even when the software encoder is selected — and even with -hwaccel none.

gst-launch-1.0 --quiet pipewiresrc fd=3 path=NN do-timestamp=true ! vapostproc ! video/x-raw,format=I420
  ! videoconvert ! videorate ... ! x264enc tune=zerolatency speed-preset=superfast ... ! h264parse ... ! fdsink fd=1
                                   ^^^^^^^^^^^^ VA-API element, while the chosen encoder is x264enc (software)

On a host with no usable VA-API device that element doesn't exist, so the pipeline can't be built and the capture subprocess exits instantly. The user-visible error hides this completely:

streaming error: capture process exited unexpectedly (EOF)

Running with GST_DEBUG=2 reveals the real failure:

ERROR  GST_PIPELINE grammar.y:630:gst_parse_element_make: no element "vapostproc"
WARNING: erroneous pipeline: no element "vapostproc"

To confirm this is the same issue, on the failing machine:

gst-inspect-1.0 va    # if it reports "0 features", the va plugin registers no elements -> vapostproc can never exist
vainfo                # no usable driver

The va plugin loads fine (it ships in gst-plugins-bad) but registers zero elements when there's no VA device — which is why installing more GStreamer packages doesn't help. I'd expect Asahi to show the same, since there's no VA-API driver for it.

Suggested fix: fall back to videoconvert when VA isn't available — it performs the same I420 conversion in software. Ideally -hwaccel none would force that path too; today it appears to affect only the encoder selection, not the post-processor, so there's no way to opt out of vapostproc from the CLI.

Verified workaround, no rebuild required. Since doubletake shells out to gst-launch-1.0 rather than linking libgstreamer, a shim earlier on $PATH is enough:

#!/usr/bin/env bash
# rewrite vapostproc -> videoconvert for hosts with no VA-API
args=()
for a in "$@"; do
    [[ "$a" == "vapostproc" ]] && a="videoconvert"
    args+=("$a")
done
exec /usr/bin/gst-launch-1.0 "${args[@]}"   # exec matters: preserves fd 3 (the portal's pipewire fd)

With that shim in place everything works: 1920x1080@30 to the Apple TV, ~20% of one core for software x264 encoding. Happy to open a PR if a fallback like that would be welcome.

Two smaller things found along the way, in case they help others landing here:

• gstreamer1.0-plugins-bad is required but missing from the README's apt list — h264parse lives there, and without it the pipeline fails with the same opaque capture process exited unexpectedly (EOF).
• pulseaudio-utils is needed for audio — without pactl it logs no PulseAudio monitor source found and silently continues video-only.

[omarroth]

Thanks both for tracking this down. Updated README, expecting this to be fixed with #13 and #15.