Electron Capture v2.23.2

What's New in v2.23.2

New Features

ASIO Audio Capture (Windows)

• Capture audio from professional ASIO audio interfaces (ASIO4ALL, Focusrite, RME, etc.)
• Low-latency audio capture for professional audio workflows
• Integrates with VDO.Ninja for streaming professional audio sources

DPI Compensation

• Automatic DPI scaling compensation - renders content at 1:1 scale regardless of system DPI (e.g., 150% scaling)
• New --nodpi flag to disable DPI compensation if needed

Window Bounds Persistence

• Window size and position now saved between sessions
• Restored on startup when no explicit dimensions given

Improvements

Custom Electron v39.2.16-qp20 (Windows)

• Improved overlay capture - DWM border hidden when window loses focus
• Cleaner captures for OBS and screen capture tools
• Border handling moved to native C++ implementation
• Embedded checksum for faster startup (skips manifest fetch)

Permission Handling

• Added speaker-selection and window-management permissions
• Improved device permission handling for media access
• Added secure origin for dev.versus.cam

Bug Fixes

• Fixed --help flag not showing help (#96)
• Fixed native module loading in packaged app
• Fixed permission handler partition mismatch
• Fixed Linux build to use stock Electron correctly
• Fixed security vulnerabilities (tar, lodash, undici)

Infrastructure

• GitHub Actions workflow for automated builds
• New documentation website with feature guides

Downloads

• Windows Installer: elecap_win_v2.23.2_installer.zip
• Windows Portable: elecap_win_v2.23.2_portable.zip
• Linux AppImage: elecap-2.23.2-x86_64.AppImage
• Linux Debian: elecap-2.23.2-amd64.deb
• macOS Universal Binary (Intel + Apple Silicon)

Electron Capture v2.23.1

Changes

• DPI Compensation: Automatic content scaling to render at 1:1 pixel ratio regardless of Windows display scaling (fixes oversized fonts/UI at high DPI)
• Window Persistence: Window size and position now remembered between sessions
• New flag: --nodpi to disable automatic DPI compensation if needed

Downloads

• elecap_win_v2.23.1_portable.zip - Portable Windows executable
• elecap_win_v2.23.1_installer.zip - Windows installer
• elecap-2.23.1.exe - Standalone installer

Electron Capture v2.23.0

What's New

Bug Fixes

• Fixed transparent frameless window resize - Upgraded to custom Electron v39.2.8-qp20 which restores the ability to resize transparent frameless windows when resizable: true is set.
  • This was a regression from Electron PR #48378
  • GitHub Issues: electron/electron#48554, electron/electron#49173

Windows-Only Features

• Custom Electron v39.2.8-qp20 with:
  • Near-lossless WebRTC encoding (max QP 20)
  • NVENC/HEVC hardware encoding support
  • Cursor suppression for getDisplayMedia()
  • Adaptive scaling controls via field trials
• Application Audio Capture (capture audio from specific apps without virtual cables)

Downloads

• Windows Installer: elecap_win_v2.23.0_installer.zip
• Windows Portable: elecap_win_v2.23.0_portable.zip
• Linux AppImage: elecap-2.23.0-x86_64.AppImage
• Linux Deb: elecap-2.23.0-amd64.deb

🤖 Generated with Claude Code

Electron Capture v2.22.0 - Application Audio Capture

What's New in v2.22.0

Application Audio Capture (Windows)

• Native application audio capture - Capture audio directly from any Windows application without virtual audio cables
• Uses Windows Audio Session API (WASAPI) loopback capture for clean, per-process audio

Custom Electron v39.2.7-qp20 (Windows)

• Built on Electron 39.2.7 with enhanced WebRTC quality patches
• QP-cap patches - Near-lossless video encoding (max QP = 20)
• NVENC hardware encoding - H.264, HEVC/H.265, and AV1 support
• Adaptive scaling controls - Lock resolution/framerate to prevent quality drops

Bug Fixes

• Fixed --help flag not displaying help text (#96)

Downloads

Windows (Custom Electron with QP-cap + NVENC):

• elecap_win_v2.22.0_portable.zip - Portable, no installation required
• elecap_win_v2.22.0_installer.zip - NSIS installer
• elecap-2.22.0.exe - Direct installer

Linux (Stock Electron 39.2.7):

• elecap-2.22.0-x86_64.AppImage - Universal Linux package
• elecap-2.22.0-amd64.deb - Debian/Ubuntu package

2.21.5

Version 2.21.5

• added a drag-bar to the top of the app when there isn't one already
• added --defaultDragRegion / --dragbar to the CLI so you can launch with elecap.exe --dragbar=false --url … to suppress the injected drag strip; the same flag works via deep links like electroncapture://...?dragbar=false

Version 2.21.3

Window Reuse & Targeting – You can now pass a windowName (via CLI or electroncapture:// deep links)
to reopen and retarget an existing window instead of spawning a new one. The main process tracks
named windows, keeps immutable webPreferences aligned, and reapplies size/position/pin/fullscreen/
minimize states while respecting per-monitor scale. A new test-window-reuse.html helper builds sample
links so you can try the flow quickly.

Standalone Launches – Added the --multiinstance flag (alias --standalone) so power users can opt out
of the single-instance lock. Use it when you truly need a completely separate Electron process with
its own main windows; default behavior remains unchanged.

Deep Link Quality-of-Life – Deep links gain first-class windowName parsing plus better normalization
of URL, window geometry, and pin/minimize toggles, making scripted launches more predictable across
monitors.

Version 2.21.0

This is an experimental release. 🧪

• application audio capture (windows)
• tried increased the maximum and minimum allowed video encoder quality
• h265 video encoder support enabled
• more command line parameters (see audio application branch's readme for details)
• chromium engine updated to more secure stable version that still supports transparencies
• experimental nvenc support enabled. *see below for my personal notes on this all

When using the app in Administrator Mode + Elevated Privileges Mode (node-integration enabled via --node), the app can capture isolated window-audio within Windows; not just system audio. https://vdo.ninja/alpha/ as well needed

Why this release is awesome? Well, it makes screen capture more powerful, without needing OBS and virtual audio cables. A better more-refined version is coming, but consider this a test version.

Windows-only audio capture. Linux support is untested, but I tried to add lossless encoding support also. Mac support is absent.

🎈

* Technical notes on the NVEnc logic

Requirements: Hardware acceleration must stay enabled in Electron (do not call app.disableHardwareAcceleration()), and the process must run on a machine with an NVENC-capable GPU + recent driver. Windows only. (NOT LINUX; NOT MAC)

MediaRecorder

• Blink routes MediaRecorder video through the GPU VideoEncodeAcceleratorAdapter, which picks the hardware encoder when it is allowed. That adapter talks to the GPU process, so on Windows it lands on the NVENC-backed Media Foundation MFT.
• Request an NVENC-friendly codec (H.264 or HEVC). Example:

    const mimeType = 'video/mp4;codecs="avc1.640028"';
    if (!MediaRecorder.isTypeSupported(mimeType)) throw new Error('H.264 not enabled');
    const recorder = new MediaRecorder(stream, {
      mimeType,
      videoBitsPerSecond: 20_000_000, // drives the QP floor from our patch
    });

• Inspect chrome://media-internals while recording: the entry should show VideoEncoder as GpuVideoAccelerator/
  MediaFoundationVideoEncodeAccelerator with Implementation: Hardware. If it falls back to software, lower the resolution/bitrate or
  confirm the GPU driver exposes H.264 export.

WebCodecs VideoEncoder

• WebCodecs uses the same accelerator adapter when hardwareAcceleration is 'prefer-hardware' or 'require-hardware'.
• Configure H.264/HEVC (or AV1 if your board exposes NVENC AV1) and check support before starting:

    const config = {
      codec: 'avc1.640028',
      width,
      height,
      bitrate: 15_000_000,
      framerate: 60,
      hardwareAcceleration: 'require-hardware',
    };
    const {supported, config: resolved} = await VideoEncoder.isConfigSupported(config);
    if (!supported) throw new Error(resolved.notSupportedErrorMessage);
    const encoder = new VideoEncoder({
      output: chunk => {/* ... */},
      error: e => console.error(e),
    });
    encoder.configure(resolved.config);

• Call encoder.encode and watch encoder.flush(). During runtime, encoder.encodeQueueSize should stay low; encoder.ondequeue events expose metadata.encoderImplementation (expect media::VideoEncodeAccelerator or similar). If support comes back unsupported, NVENC isn’t exposed for that profile/driver combo.

WebRTC (RTCPeerConnection / getUserMedia)

• WebRTC consults the GPU factories to enumerate hardware encoder profiles. When H.264/HEVC is available, it prefers the hardware-backed implementation.
• To force H.264 so the NVENC path is selected:

    const pc = new RTCPeerConnection();
    const sender = pc.addTrack(stream.getVideoTracks()[0], stream);
    const h264 = RTCRtpSender.getCapabilities('video').codecs
                   .filter(c => c.mimeType === 'video/H264');
    sender.setCodecPreferences(h264);

• After the call starts, open chrome://webrtc-internals, locate your peer connection, and check videoEncoderImplementationName or
  EncoderImplementation. It should report Hardware (on recent Chromium builds it will say MediaFoundationVideoEncoder with vendor
  NVIDIA). The quantizer telemetry should reflect the patched 0–20 window.
• If you see software implementations, confirm the capture format is supported (NVENC blocks some odd frame sizes), the bitrate isn’t
  set below a couple of Mbps, and no SDP munging reorders codecs back to VP8/VP9.

2.21.4

Version 2.21.4

• pending release

Version 2.21.3

Window Reuse & Targeting – You can now pass a windowName (via CLI or electroncapture:// deep links)
to reopen and retarget an existing window instead of spawning a new one. The main process tracks
named windows, keeps immutable webPreferences aligned, and reapplies size/position/pin/fullscreen/
minimize states while respecting per-monitor scale. A new test-window-reuse.html helper builds sample
links so you can try the flow quickly.

Standalone Launches – Added the --multiinstance flag (alias --standalone) so power users can opt out
of the single-instance lock. Use it when you truly need a completely separate Electron process with
its own main windows; default behavior remains unchanged.

Deep Link Quality-of-Life – Deep links gain first-class windowName parsing plus better normalization
of URL, window geometry, and pin/minimize toggles, making scripted launches more predictable across
monitors.

Version 2.21.0

This is an experimental release. 🧪

• application audio capture (windows)
• tried increased the maximum and minimum allowed video encoder quality
• h265 video encoder support enabled
• more command line parameters (see audio application branch's readme for details)
• chromium engine updated to more secure stable version that still supports transparencies
• experimental nvenc support enabled. *see below for my personal notes on this all

When using the app in Administrator Mode + Elevated Privileges Mode (node-integration enabled via --node), the app can capture isolated window-audio within Windows; not just system audio. https://vdo.ninja/alpha/ as well needed

Why this release is awesome? Well, it makes screen capture more powerful, without needing OBS and virtual audio cables. A better more-refined version is coming, but consider this a test version.

Windows-only audio capture. Linux support is untested, but I tried to add lossless encoding support also. Mac support is absent.

🎈

* Technical notes on the NVEnc logic

Requirements: Hardware acceleration must stay enabled in Electron (do not call app.disableHardwareAcceleration()), and the process must run on a machine with an NVENC-capable GPU + recent driver. Windows only. (NOT LINUX; NOT MAC)

MediaRecorder

• Blink routes MediaRecorder video through the GPU VideoEncodeAcceleratorAdapter, which picks the hardware encoder when it is allowed. That adapter talks to the GPU process, so on Windows it lands on the NVENC-backed Media Foundation MFT.
• Request an NVENC-friendly codec (H.264 or HEVC). Example:

    const mimeType = 'video/mp4;codecs="avc1.640028"';
    if (!MediaRecorder.isTypeSupported(mimeType)) throw new Error('H.264 not enabled');
    const recorder = new MediaRecorder(stream, {
      mimeType,
      videoBitsPerSecond: 20_000_000, // drives the QP floor from our patch
    });

• Inspect chrome://media-internals while recording: the entry should show VideoEncoder as GpuVideoAccelerator/
  MediaFoundationVideoEncodeAccelerator with Implementation: Hardware. If it falls back to software, lower the resolution/bitrate or
  confirm the GPU driver exposes H.264 export.

WebCodecs VideoEncoder

• WebCodecs uses the same accelerator adapter when hardwareAcceleration is 'prefer-hardware' or 'require-hardware'.
• Configure H.264/HEVC (or AV1 if your board exposes NVENC AV1) and check support before starting:

    const config = {
      codec: 'avc1.640028',
      width,
      height,
      bitrate: 15_000_000,
      framerate: 60,
      hardwareAcceleration: 'require-hardware',
    };
    const {supported, config: resolved} = await VideoEncoder.isConfigSupported(config);
    if (!supported) throw new Error(resolved.notSupportedErrorMessage);
    const encoder = new VideoEncoder({
      output: chunk => {/* ... */},
      error: e => console.error(e),
    });
    encoder.configure(resolved.config);

• Call encoder.encode and watch encoder.flush(). During runtime, encoder.encodeQueueSize should stay low; encoder.ondequeue events expose metadata.encoderImplementation (expect media::VideoEncodeAccelerator or similar). If support comes back unsupported, NVENC isn’t exposed for that profile/driver combo.

WebRTC (RTCPeerConnection / getUserMedia)

• WebRTC consults the GPU factories to enumerate hardware encoder profiles. When H.264/HEVC is available, it prefers the hardware-backed implementation.
• To force H.264 so the NVENC path is selected:

    const pc = new RTCPeerConnection();
    const sender = pc.addTrack(stream.getVideoTracks()[0], stream);
    const h264 = RTCRtpSender.getCapabilities('video').codecs
                   .filter(c => c.mimeType === 'video/H264');
    sender.setCodecPreferences(h264);

• After the call starts, open chrome://webrtc-internals, locate your peer connection, and check videoEncoderImplementationName or
  EncoderImplementation. It should report Hardware (on recent Chromium builds it will say MediaFoundationVideoEncoder with vendor
  NVIDIA). The quantizer telemetry should reflect the patched 0–20 window.
• If you see software implementations, confirm the capture format is supported (NVENC blocks some odd frame sizes), the bitrate isn’t
  set below a couple of Mbps, and no SDP munging reorders codecs back to VP8/VP9.

Screenshare working again

Just reverting some recent changes to screen share and window positioning - I moved those upcomign feature changes to a branch

Security updates and minor patches

Downloads are available below, under Assets

Fixes for multi-start + screenshare autostart

• Fixes for multi-start via command line
• screenshare auto-start via command line fixed
  • eg: elecap.exe --node 1 --url="https://vdo.ninja/v26/?ss=1&push=name123456&password=name&autostart
• Chromium (electron.js) engine updated to newest stable version

Download links are below, under Assets. Different options for different systems.

IP camera support added

While there are some library updates in this release, they aren't major.

The main feature added to this version is a custom API that allows the following website to access CORS-protected websites. It also allows to access cross-mixed remote resources.

https://vdo.ninja/alpha/ipcam

The point of this all is to allow users to use IP cameras (mjpeg-based) as camera sources for VDO.Ninja. So for example you can share a local IP security camera with others on the Internet, via WebRTC/VDO.Ninja, bypassing firewalls and with optimized bandwidth controls.