overthinkos/wl-record-pixelflux
selkies/skills/wl-record-pixelflux/SKILL.md
Desktop video recorder via selkies WebSocket capture bridge for selkies-desktop. Use when working with the wl-record-pixelflux candy.
development
Updated Jun 27, 2026
$ install --global
skillsauthnpx skillsauth add overthinkos/overthink-plugins wl-record-pixelfluxInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 27, 2026, 5:36 AM160.9s1 file scanned
SKILL.md
- name:
- wl-record-pixelflux
- description:
- |
wl-record-pixelflux -- Desktop video recording via selkies capture bridge
Candy Properties
| Property | Value |
|----------|-------|
| Install files | charly.yml, task:, pixelflux-record (Python script) |
| Depends | selkies (capture bridge + WebSocket stream), ffmpeg (MP4 muxing) |
What It Does
Provides pixelflux-record for recording desktop video on selkies-desktop. Connects to the capture bridge at /tmp/charly-capture.sock which relays the same H.264 frames that the browser sees via the selkies WebSocket stream. No direct ScreenCapture API access -- taps into the existing selkies streaming pipeline to avoid creating a second capture instance (the Rust backend only supports one active capture at a time).
Why not wf-recorder? labwc running nested inside pixelflux can't deliver wlr-screencopy frames. The capture bridge bypasses this by tapping into the selkies WebSocket stream directly.
How It Works
- Connects to Unix socket at
/tmp/charly-capture.sock(started byselkies-capture-server) - Sends
STREAM\nto request continuous H.264 frame data - Receives frames as
4-byte length + raw H.264 datapairs - Pipes raw H.264 data to ffmpeg with
-use_wallclock_as_timestamps 1 - ffmpeg re-encodes to MP4 with correct wall-clock timing
- SIGINT/SIGTERM triggers graceful shutdown: closes socket, waits for ffmpeg to finalize MP4
Key Properties
| Property | Value |
|----------|-------|
| Depends | selkies (capture bridge + stream), ffmpeg (muxing) |
| Install | ~/.local/bin/pixelflux-record (Python script) |
| Capture | Via /tmp/charly-capture.sock (selkies WebSocket bridge) |
| Output | MP4 (H.264 video + optional AAC audio) |
| Audio | PulseAudio monitor source via ffmpeg |
CLI Usage
# Direct usage
pixelflux-record output.mp4 # 30fps, video only
pixelflux-record output.mp4 --fps 60 # 60fps
pixelflux-record output.mp4 --audio # video + audio
pixelflux-record output.mp4 --fps 60 --audio # 60fps + audio
# Stop with Ctrl-C
Integration with the record: check verb
Author record: plan steps (the declarative verb served out-of-process by
candy/plugin-record — no host charly check subcommand for it) and run them with
charly check live selkies-desktop --filter record. A record: start step with
record_mode: desktop + record_audio: true auto-detects pixelflux-record; desktop
interaction is driven with the cdp:/wl: verbs (which keep their host subcommands);
record: stop + artifact: copies the .mp4 out:
pixelflux-rec-start:
check: a desktop recording with audio starts
record: start
context: [deploy]
record_name: demo
record_mode: desktop
record_audio: true
pixelflux-rec-stop:
check: the desktop recording is captured
record: stop
context: [deploy]
record_name: demo
artifact: demo.mp4
artifact_not_uniform: true
Architecture
selkies process (single ScreenCapture singleton — process-wide)
├── ScreenCapture (captures full composited desktop)
├── WebSocket server :8081 (broadcasts H.264 frames)
└── Capture bridge thread (internal WebSocket client)
└── Unix socket /tmp/charly-capture.sock
└── pixelflux-record connects here (STREAM mode)
└── pipes H.264 frames to ffmpeg
Singleton note: The ScreenCapture instance is process-wide and lives inside the selkies Python process. pixelflux-record never spawns its own capture; it only attaches to the existing STREAM socket. This is architecturally important because pixelflux's WaylandBackend construction is expensive (EGL context + dmabuf allocators + GPU texture pools) and was the subject of a memory leak fix in commits 6be85eb (singleton enforcement) and 7977b91 (per-frame cleanup_texture_cache()). If you ever see two selkies-capture processes inside the container, that's a regression — see /charly-selkies:selkies (Pixelflux Memory Management) for the diagnostic recipe.
Included In
selkies-desktopmetalayer
Used In Boxes
/charly-selkies:selkies-labwc(viaselkies-desktopmetalayer)/charly-selkies:selkies-labwc-nvidia(viaselkies-desktopmetalayer)
Cross-References
/charly-check:record-- therecord:check verb (record_mode: desktop) auto-detects pixelflux-record/charly-core:charly-update-- Per-instance update pattern used to roll out the per-framecleanup_texture_cache()fix across live instances/charly-selkies:wl-screenshot-pixelflux-- Screenshot companion (same capture bridge, same singleton)/charly-selkies:wf-recorder-- Alternative for sway-desktop (wlr-screencopy)/charly-selkies:selkies-- Parent candy (provides capture bridge, WebSocket stream, and the ScreenCapture singleton — see Pixelflux Memory Management)/charly-selkies:selkies-desktop-layer-- Metalayer that composes this recorder into the full browser-accessible desktop/charly-selkies:ffmpeg-- Required dependency (MP4 muxing)
When to Use This Skill
Use when the user asks about:
- Desktop video recording on selkies-desktop
- The pixelflux recording pipeline
- The
wl-record-pixelfluxcandy
Related
/charly-image:layer— candy authoring reference (charly.ymlschema, task verbs, service declarations)/charly-check:check— declarative testing (check:block,charly check box,charly check live)
Related Skills
overthinkos/plugin
tools
VerifiedTrustedCommunity
Use when authoring or modifying a charly PLUGIN — a candy with a `plugin:` block that contributes Providers (verbs/kinds/deploy-targets/steps/builders/commands), its own CUE schema, builtin (compiled-in) or external (out-of-tree git repo). Covers the unified Provider model, the per-plugin CUE-schema contract (single source → Go params for dev + schema-over-Describe RPC for runtime), the SDK, and the loader.
SKILL.mdUpdated Jun 22, 2026
overthinkos/cue
tools
VerifiedTrustedCommunity
The CUE data-validation / configuration CLI (cue), pinned to v0.16.1. Use when working with the cue candy, installing the cue binary into a box or onto a target:local dev host, or running the offline schema-vendoring pipeline that feeds charly's egress validation.
SKILL.mdUpdated Jun 16, 2026
overthinkos/egress
tools
VerifiedTrustedCommunity
CUE EGRESS validation — validating (and, where it adds value, generating) the config files charly WRITES to a system BEFORE the bytes hit disk. MUST be invoked before working on charly/egress.go, the vendored schemas under candy/plugin-egress/egress-schemas/vendor/, the ValidateEgress / registerVendoredEgressKind path, the offline `task cue:vendor` pipeline, or adding an egress schema for any written artifact (cloud-init, k8s manifests, traefik routes, runtime config, install ledger, systemd/quadlet units, ssh_config, libvirt XML).
SKILL.mdUpdated Jun 16, 2026
overthinkos/check-k8s
tools
VerifiedTrustedCommunity
Kubernetes cluster-probe declarative check verb — the `kube:` check verb (nodes, pods, ingress, storage class, addon health, apply/delete, and arbitrary resource GETs) served out-of-process by the candy/plugin-kube plugin (vendored client-go; no external kubectl required).
SKILL.mdUpdated Jun 14, 2026