3e4f29c297
When exporting H.264 with audio, try the gpu-video-encoder ZeroCopyEncoder: render each frame to RGBA and hardware-encode it into a VAAPI surface inline, on the encoder's own VAAPI-capable wgpu device — no GPU->CPU readback, no swscale, no software-encoder thread. Falls back to the existing software path verbatim when VAAPI/the device is unavailable (non-Linux, non-H264, or init failure), so it's additive. - VideoExportState gains zero_copy: Option<ZeroCopyVideo> (encoder + its own vello renderer + ExportGpuResources + a reused RGBA target, all on the encoder's device). - start_video_with_audio_export builds it for H.264 and skips spawning the software encoder thread when present. - render_next_video_frame routes to a zero-copy arm that reuses render_frame_to_gpu_rgba on the encoder's device, then encode_rgba; on the last frame finish() writes the temp .mp4 and sets video_progress=Complete so the existing mux runs. video_thread=None makes the mux join a no-op. Separate export device (vs modifying the eframe device) keeps this contained to export. Video-only export stays on the software path for now. Runtime verification (an actual H.264 export) is pending — cannot run the editor in the dev container. |
||
|---|---|---|
| .. | ||
| beamdsp | ||
| egui_node_graph2 | ||
| gpu-video-encoder | ||
| lightningbeam-core | ||
| lightningbeam-editor | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| build-static.sh | ||
| build-windows.bat | ||