v1.7.0

A feature release on top of 1.6.0. It adds a Discord tab and keeps streams close to live when latency builds up.

Features

• Discord tab. A new tab runs a Discord bot that sends the sound of any audio input into a voice channel: a microphone, a virtual cable such as VB-Cable, a line input, or on Windows what the PC itself plays. It has a noise gate, a level meter and mute, and mute is also in the tray. It can also play the channel on your speakers, with its own output device and volume. Per server, the bot can join a channel after logging in or follow a person from channel to channel. In stage channels it becomes a speaker or asks to speak. It starts muted, and nothing about it runs until you log in, so the cameras work the same whether you use it or not. The bot can log in with the app, also with --headless. Its settings and the bot token (encrypted, like stream passwords) are kept in discord.json next to config.json. Setup, including how to create a private bot: documentation/manual/discord.md. Status: logging in, joining (with DAVE) and following have been checked against Discord on Windows. The sound has not yet been checked by ear, and Linux and macOS build but have not been run yet.
• Streams catch up with live. The app now measures how far pictures fall behind the camera. If a stream drifts past a cap of 350 ms, pictures are decoded but not shown until it is back within half the cap. If that takes more than a second, or it keeps losing ground, it skips to the next key frame. Latency no longer keeps building up on a slow network or a busy PC.
• Latency report in the stream details. The details show the time from arrival to picture, the decoder time, the drift behind live with its trend and range over the last 30 seconds, and how often the stream caught up.

Fixes

• Windows cameras no longer freeze when a frame can't be delivered. When the camera couldn't send a sample, the request was lost and the app using the camera waited for a frame that never came. The camera now retries once. If that fails, it reports the error so Windows reopens the stream.
• Building from source now needs CMake (libopus for the Discord tab is built from source), plus libasound2-dev on Linux. To build without the Discord tab: cargo build -p rtspcam-app --no-default-features. The Windows build still needs no extra DLLs.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept, and config.json is unchanged. The Discord tab adds its own discord.json. The installer updates the camera DLL with the fix above. The pipe protocol is unchanged.
• Linux: install the new .deb or .rpm over the previous version.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.7.0-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.6.0...v1.7.0

v1.6.0

A feature release on top of 1.5.0: 60 fps output, and a "Source" resolution that passes the camera's own picture size through.

Features

• 60 fps output. Streams can now output at 60 fps as well as 30 and 15. On Windows every camera offers all three rates at every size (36 formats instead of 24), with the stream's choice still listed first. The high-resolution frame timer keeps 60 fps frames 16.7 ms apart.
• "Source" resolution. Besides 1920×1080, 1280×720 and 640×480, a stream's output can be set to Source: the camera's own picture size with no scaling, such as a 4:3 or 1440p camera, up to 4096×2160. Larger pictures are shrunk to fit and keep their shape. The size is learned on the first connection and remembered. Until then the camera offers 1920×1080. If the camera's size changes, the virtual camera picks up the new size once no app is using it. On Windows the Source size is offered alongside the usual sizes. On Linux the device uses it directly.
• Clearer stream details. The details now show the size the camera is offering. They also say when the camera sends fewer frames than the output rate, in which case apps see some pictures twice.

Fixes

• Re-creating a camera on Windows no longer fails with "access is denied". When a camera needed to be re-made (for example when a Source camera picked up a new size), the old pipe could still be open as the new one was created, and Windows refused it. The camera is now re-made while its pipe keeps running. When a pipe does have to be served again, the app waits until the old one has closed. The app's count of connected clients also stays correct when a connection is cancelled.
• New documentation comparing these virtual cameras with RealTimeWebCam's, 1080p60 test streams for the local test server, and more tests.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept. Streams set to "Source" store one extra setting that older versions ignore (they fall back to 1920×1080). The installer updates the camera DLL with the new formats. The pipe protocol is unchanged.
• Linux: install the new .deb or .rpm over the previous version.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.6.0-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.5.0...v1.6.0

v1.5.0

A feature release on top of 1.4.1: smoother video from the Windows virtual camera, and more formats for apps to choose from.

Features

• YUY2 and I420 on the Windows camera. Besides NV12 and RGB32, the camera now also offers YUY2 (the format most USB webcams use, which some apps look for first) and I420, at the same sizes and frame rates. NV12 is still listed first, so apps that just take the first format are unaffected.

Fixes

• Smoother frame pacing on Windows. The camera used to time frames with a wait that Windows rounds to about 15.6 ms, so frame gaps at 30 fps ranged from about 30 ms to 48 ms. It now uses a high-resolution timer, and gaps stay within 1 ms of the frame interval.
• Evenly spaced timestamps. Frames are stamped at exact multiples of the frame interval instead of whenever they were sent, which helps apps that record or re-encode the camera.
• Less memory churn while streaming. The camera reuses its frame buffers and takes samples from a pool instead of allocating a new one for every frame.
• New documentation comparing these virtual cameras with OBS Studio's, and more tests for frame timing and the new formats.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept. The camera DLL is updated by the installer; the pipe protocol is unchanged.
• Linux: install the new .deb or .rpm over the previous version. Nothing on Linux changed in this release.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.5.0-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.4.1...v1.5.0

v1.4.1

A fix release on top of 1.4.0, tightening up the new hardware decoding.

Fixes

• Steadier frame delivery to apps on Windows. Waiting for a slightly late picture used a short sleep that Windows rounds up to about 15.6 ms, longer than half a frame slot at high frame rates. Cameras now wake as soon as the picture is ready, in the app and in rtspcam-cli vcam. A freeze-frame resend of a cached picture also no longer counts as a second reader.
• Hardware decoding gives up less eagerly, and recovers faster. A single decode error before the first picture no longer drops a stream to software decoding; two failed key frames in a row do (each one costs a key frame interval with no picture). The decoder is flushed after an early error so the retry at the next key frame starts clean.
• Lower GPU memory use. The GPU scaler releases decoder surfaces it no longer uses, and is dropped entirely when no scaling is needed, instead of holding on to old pictures after the size limit is lifted.
• Correct resolution in stream details. Stream stats report the camera's resolution rather than the decoder's (smaller) output size; rtspcam-cli bench shows both.
• Size limit no longer lost. A size limit worked out while a stream was starting could be dropped, leaving the stream decoding at full size.
• Less lock contention when copying pictures off the graphics card, and the copy can no longer leave a texture mapped if it fails part-way.
• The preview no longer jitters. The stream info panel next to the preview has a fixed width, so the live stats changing don't resize the preview (#10).
• More tests for the size-limit bookkeeping, and some internal cleanup.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept, and the camera DLL and pipe protocol are unchanged.
• Linux: install the new .deb or .rpm over the previous version.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.4.1-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.4.0...v1.4.1

v1.4.0

A performance release on top of 1.3.0: on Windows, cameras now decode on the graphics card.

Features

• Hardware decoding on Windows. H.264 and H.265 streams are now decoded on the graphics card (Direct3D 11) when it can, and pictures are shrunk there to the size the apps using the camera ask for. A 1080p camera costs about 5 % of one CPU core instead of 30–90 %. The stream details show D3D11 when it is in use.
• "Use hardware decoding" setting. Settings shows which graphics card is used and lets you turn hardware decoding off. It is on by default and saved in the config as settings.hardware_decoding. If the card can't decode a stream, or the hardware decoder stops working, that stream switches to software decoding without reconnecting.
• Faster software scaling on every OS: resizing pictures on the CPU is about a third faster, and converted pictures are cached per output format.
• rtspcam-cli bench measures where the CPU goes, per stage, with streams read the way virtual cameras read them. probe and view take --hardware on|off.

Fixes

• Fewer dropped frames to apps. A picture that arrives slightly late is now still sent to the camera in the same frame slot instead of being skipped.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept (hardware decoding is on by default; turn it off in Settings if a camera misbehaves), and the camera DLL and pipe protocol are unchanged.
• Linux: install the new .deb or .rpm over the previous version. Hardware decoding is Windows-only for now; Linux gets the faster scaler.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.4.0-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.3.0...v1.4.0

v1.3.0

A light/dark theme, plus two Linux fixes, on top of 1.2.1.

Features

• Light and dark theme. A "Dark mode" / "Light mode" button in the toolbar switches the window's colours, and Settings has a new Theme choice (System, Light or Dark). By default the app follows the OS. Toggling back to the theme the OS uses returns to following it. The choice is saved in the config as settings.theme.

Fixes

• Linux: cameras are cleaned up at logout and shutdown. The app used to ignore SIGTERM, so logging out, shutting down, kill or systemctl stop left its v4l2loopback devices behind until the next start. It now quits on SIGTERM or SIGHUP the same way as the tray's Quit (or Ctrl+C when headless), removing its devices.
• Linux: editing a stream keeps its camera device. Any edit used to remove the virtual camera and add it again. If an app was using it in a call, the removal failed, and on v4l2loopback 0.12 the stream could come back on a different device, so the call kept reading a device nobody wrote to. An edited stream now keeps the same device and the app in the call keeps getting pictures.
• Docs: the README has been rewritten with a quickstart and screenshot up front.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept (the new theme setting defaults to following the OS), and the camera DLL and pipe protocol are unchanged.
• Linux: install the new .deb or .rpm over the previous version.

The notes for v1.2.0, including what is not yet verified on Linux, still apply.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.3.0-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.2.1...v1.3.0

v1.2.1

A small fix release on top of 1.2.0.

Fixes

• "Start with Windows" on profiles without a Run key. Turning on start at login failed with "The system cannot find the file specified" when HKCU\Software\Microsoft\Windows\CurrentVersion\Run didn't exist yet. The app now creates the key when it needs it.
• CI: two frame-pacing tests no longer fail on slow macOS runners. They still check that frames never burst and that the last picture repeats before the "No signal" placeholder replaces it.

Upgrading

• Windows: install over any 1.x. Config, streams and passwords are kept, and the camera DLL and pipe protocol are unchanged.
• Linux: install the new .deb or .rpm over 1.2.0.

Nothing else changed since 1.2.0. Its notes, including what is not yet verified on Linux, still apply: see v1.2.0.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.2.1-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.2.0...v1.2.1

v1.2.0

RTSP Cam streams can now be webcams on Linux too, through v4l2loopback. Windows behaves as in 1.1.

Changes

• Linux virtual cameras. Each stream gets its own /dev/videoN, named after the stream, that browsers, call apps and OBS can pick. With v4l2loopback 0.13+ the app creates the devices itself; with 0.12 it uses spare "RTSP Cam N" devices made at boot. Devices left behind by a crash are reused rather than piling up, and if the module is missing the status line says what to install. Streams connect on demand, when an app starts reading the camera.
• Linux packages. A .deb (Ubuntu 22.04+, Debian 12+) and an .rpm (Fedora), which recommend v4l2loopback and install a boot service that loads the module, a udev rule so cameras can be added without root, and a desktop entry.
• Shared frame pusher (groundwork for Linux and macOS): paces frames to the camera, repeats the last one until it goes stale, then shows the "Connecting..." placeholder, the same one the Windows camera uses.
• macOS still previews streams but has no virtual cameras yet (phase M in doc 11).

Upgrading

• Windows: install over 1.1 or 1.0.x. Config, streams and passwords are kept, and the camera DLL and pipe protocol are unchanged.
• Linux: install the .deb or .rpm. On Secure Boot systems, v4l2loopback-dkms asks you to enrol a key (MOK) and reboot before the cameras appear.

Not yet verified

The Linux cameras were checked against the real module (v4l2loopback 0.15.3) with ffmpeg and v4l2-ctl, and the packages install cleanly on Ubuntu 22.04/24.04, Debian 12 and Fedora 42. They have not yet been tried in Chrome, Firefox, Zoom, Teams, Discord or OBS on a real desktop, nor with 0.12 on its own kernel. On logout the app's devices stay behind until the next start (then they are reused). See doc 13 §5.

Downloads

The release workflow attaches these when its builds finish:

• RtspCam-1.2.0-setup.exe: the Windows installer.
• .deb and .rpm: the Linux packages (x86_64, glibc 2.35+).
• macOS: build from source as described in the README.

Full changelog: v1.1.0...v1.2.0

v1.1.0

RTSP Cam now builds and runs on Windows, Linux and macOS. On Windows it still turns each RTSP stream into a webcam, as before.

Changes

• New interface on every OS. The app window, tray and dialogs are rebuilt with Slint, replacing the Windows-only interface. Dialogs now open inside the main window. The tray opens the window on a single click, and the one-time "still running in the tray" notification is gone.
• Linux and macOS (early): the app runs, with live preview, Find cameras (ONVIF), import/export, encrypted passwords (Secret Service / Keychain, or a private key file) and start at login. Virtual cameras are Windows-only for now. On Linux and macOS, streams preview but don't appear as cameras in other apps; doc 11 plans them. Only H.264 streams decode there.
• Overlay text (name and time on the picture) now uses the Inter font on every OS, so it looks slightly different from the Segoe UI text in 1.0.
• CI builds, lints and tests on Windows, Linux and macOS.

Upgrading on Windows

Install over 1.0.x. Your config, streams and passwords are kept, and the camera DLL and pipe protocol are unchanged.

Not yet verified

The camera has been checked through the Windows camera service, but not yet in Discord, Teams or OBS with this build. The tray and start at login haven't been re-checked by hand. The macOS app has not been run on a Mac yet. See doc 10 §4.

Downloads

• RtspCam-1.1.0-setup.exe: the Windows installer. The release workflow attaches it when its build finishes.
• Linux and macOS: no packages yet. Build from source as described in the README.

v1.0.1

chore: bump version to 1.0.1

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>