NB. Issue report below generated by Claude after I tried to troubleshoot an error I got after trying out doubletake. I'm happy to help, but I am out of my depth here. Keep in mind that some of this might be hallucinated by Claude. I tried to verify the parts I understand. Details about my system are correct.
**System:**
- doubletake: v0.4.0 (latest)
- GPU: AMD Radeon 840M (radeonsi, gfx1153)
- Mesa: 25.2.8-0ubuntu0.24.04.2 (current)
- OS: Ubuntu 24.04.4 LTS, GNOME on Wayland
- xdg-desktop-portal: 1.18.4-1ubuntu2.24.04.2
- xdg-desktop-portal-gnome: 46.2-0ubuntu1
- GStreamer: 1.24.2
- PipeWire: 1.0.5 (libpipewire)
- VA-API: 1.20 (libva 2.12.0) — `vainfo` confirms driver loads correctly
**Problem:**
Screen capture fails immediately with:
[GST] ERROR: from element /GstPipeline:pipeline0/GstPipeWireSrc:pipewiresrc0: Internal data stream error.
[GST] streaming stopped, reason not-negotiated (-4)
streaming error: capture process exited unexpectedly (EOF)
Happens with **both** `-hwaccel vaapi` and `-hwaccel none` — `-hwaccel none` only swaps the encoder (x264enc vs vah264enc); `vapostproc` remains in the pipeline either way and is what's failing. Actual pipeline from `-debug` (`-hwaccel none` run):
gst-launch-1.0 (wayland) --quiet pipewiresrc fd=3 path=85 do-timestamp=true ! vapostproc ! video/x-raw,format=I420 ! videoconvert ! videorate drop-only=true skip-to-first=true ! video/x-raw,framerate=30/1 ! queue max-size-buffers=1 max-size-bytes=0 max-size-time=0 leaky=downstream ! x264enc tune=zerolatency speed-preset=superfast bitrate=4147 vbv-buf-capacity=276 key-int-max=120 pass=0 option-string=vbv-maxrate=5183 bframes=0 sliced-threads=true byte-stream=true aud=true ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream,alignment=au ! fdsink fd=1 sync=false async=false
**Isolation (via `gst-launch-1.0`, same PipeWire portal fd):**
| Pipeline | Result |
|---|---|
| `pipewiresrc ! vapostproc ! video/x-raw,format=I420 ! videoconvert ! autovideosink` | ❌ not-negotiated |
| `pipewiresrc always-copy=true ! vapostproc ! ...` | ❌ not-negotiated |
| `pipewiresrc ! videoconvert ! video/x-raw,format=I420 ! autovideosink` | ✅ works |
| `pipewiresrc ! videoconvert ! videoscale ! video/x-raw,format=I420 ! autovideosink` | ✅ works |
`vapostproc` cannot negotiate the DMA-BUF (BGRx, 2880x1800, framerate=0/1) caps from `pipewiresrc` on this AMD/Mesa combo, but plain `videoconvert` handles the same DMA-BUF → I420 conversion in software without issue.
Possibly related to #40 (Intel GPU, different symptom — NULL-memory assertion rather than clean not-negotiated failure — but same root area: `vapostproc` + DMA-BUF import from the PipeWire portal).
**Suggested fix:**
Drop `vapostproc` from the capture pipeline and let `videoconvert` handle the DMA-BUF download + colorspace conversion. CPU overhead at 1080p30 is negligible relative to encoding cost, and it removes a driver-dependent failure point. Could gate this behind `-hwaccel none`, or remove it unconditionally if hardware colorspace conversion isn't providing meaningful benefit over `videoconvert`.
Happy to test a patch if useful — full `-debug` log available on request.
NB. Issue report below generated by Claude after I tried to troubleshoot an error I got after trying out doubletake. I'm happy to help, but I am out of my depth here. Keep in mind that some of this might be hallucinated by Claude. I tried to verify the parts I understand. Details about my system are correct.