wcap is a screen recorder built on the Windows compositor and Media Foundation

A recorder in a dozen source files

wcap is described as a small and efficient screen recording utility for Windows 10 and 11, and the repository layout matches that claim. The root holds wcap.c and wcap.h, and then a set of headers that each cover one part of the pipeline: wcap_audio_capture.h, wcap_config.h, wcap_encoder.h, wcap_screen_capture.h, wcap_shaders.hlsl, wcap_tex_resize.h and wcap_yuv_convert.h. There is a wcap.manifest for the application manifest, a wcap.rc resource script, two icon files, a build.cmd, a CHANGELOG.md and the licence file.

There is no framework here, no runtime, and no dependency tree. A screen recorder is a surprisingly self-contained program once you know the two Windows APIs it needs, and this one is the size of thing you can read in an afternoon.

The licence is the Unlicense, which places the work in the public domain: anyone is free to copy, modify, publish, use, compile, sell or distribute it, in source form or as a compiled binary, for any purpose, commercial or not. For a utility of this kind that is a coherent choice, since there is nothing here to protect and a permissive licence removes the question of what a user may do with the binary.

The binaries are published as loose executables, wcap-x64.exe and wcap-arm64.exe, linked from the repository wiki, and there are no GitHub releases, so the wiki links are the distribution channel. The last push was on 2026-06-16 and the repository is not archived.

One warning sits at the top of the readme and should be read before anything else: Windows Defender or other antivirus software might report a false positive detection. That is a common outcome for a small unsigned program that captures the screen, and it is a practical problem for anyone who installs it on a managed machine.

Three hotkeys, and a tray icon for settings

The interaction model is what you would expect from a Windows utility, and it is worth listing because it is the whole user interface.

Ctrl and PrintScreen starts recording the current monitor, the one where the mouse cursor is currently positioned. Ctrl, Win and PrintScreen starts recording the currently active window. Ctrl, Shift and PrintScreen lets you select a fixed region on the current monitor and record that. Pressing any of those same combinations again stops the recording, so the same key both starts and stops.

Settings are reached by right-clicking or double-clicking the tray icon, which means there is no configuration file to hunt for and no menu bar.

The recording options in that dialog are the ones that separate a toy from a usable tool. For a window capture you can record the full window area, including the title bar and the borders, or just the client area, which for a standard window style excludes the title bar and the borders. You can exclude the mouse cursor from the capture, disable the recording indication border, and on Windows 11, disable the rounded window corners.

You can also put limits on the recording itself: a maximum length in seconds, a maximum file size in megabytes, a maximum width, a maximum height, and a maximum framerate. When you set a maximum width or height, the captured frames are downscaled automatically, and there is a gamma correct resize option for that path. There is also an optional improved color conversion, which adjusts the output YUV values to better match the brightness of the original RGB input, a detail that matters because the capture path works in YUV and the conversion back to RGB for display is where a washed out recording comes from.

Capture from the compositor, encode through Media Foundation

The technical core is short, and it is the reason the tool is efficient.

wcap uses the Windows.Graphics.Capture API, available since Windows 10 version 1903, the May 2019 Update, also known as 19H1, to capture the contents of a window or a whole monitor. The captured texture is then submitted to Media Foundation to encode the video into an mp4 file with a hardware accelerated codec. Using capture from the compositor and a hardware accelerated encoder allows it to consume very little CPU and memory.

That sentence describes a design where the expensive work never touches the CPU in the first place. The compositor already has the window contents as a GPU texture, so there is no screen readback, and the encoder is a hardware block. The result is a recorder that can run while you do something else, which is the property that separates a capture API from a screen scraping loop.

The recorded video size is determined by the initial window size, and the frame rate comes from the compositor unless you set a limit, where zero means the compositor framerate, which is typically the monitor refresh rate.

Two of the features are version gated, which is the kind of detail the readme is careful about. Capture of the mouse cursor can be disabled only when using Windows 10 version 2004, the May 2020 Update, or newer. And on Windows 11 version 24H2 you can enable secondary window capture, which matters when the secondary window intersects the main window in the window only capture mode, so that popups and tool windows such as an Open File dialog are captured too.

The lower the framerate, the higher the quality for the same bitrate and the lower the GPU usage, and if you notice dropped frames during recording the readme's advice is to reduce the video resolution and the framerate.

Codecs, the software fallback and the HEVC store extension

Video is encoded using H264/AVC, H265/HEVC or AV1, with 10-bit support for HEVC and AV1, and audio is encoded using AAC or FLAC.

The hardware encoder is enabled by default and can be disabled in the settings. The guidance around that is practical: make sure your GPU drivers are up to date if something is not working with hardware video encoding, and if you then fall back, the video is encoded with the Microsoft Media Foundation H264 software encoder. You might want to explicitly use the software encoder on older GPUs, because their hardware encoder quality is not great.

Audio capture uses WASAPI loopback recording, so it records what the system is playing, and it is encoded with the Media Foundation AAC encoder, or with the undocumented Media Foundation FLAC encoder, which the readme notes seems to always be present in Windows 10 and 11.

One limitation is specific to window capture: it can record application local audio, and no other system or process audio is included. So a window recording captures the sound of that application, not the whole desktop mix.

HEVC is where the most surprising requirement appears. HEVC encoding in software, on the CPU, requires installing the HEVC Video Extensions from the Windows Store, and it supports only 8-bit encoding. The readme then gives instructions for getting the installer package directly without using the Store application: open a third party Store mirror site, search for the Microsoft Store product identifier, pick the Retail channel, and download and run the .appxbundle package it gives you.

That is worth pausing on as an adopter, because the instructions point at a third party site rather than at a Microsoft download. The package identifier and the Retail channel are Microsoft specific and the extension is the one the Store normally installs, so the mechanism is the same one the Store would use, but the route is not one Microsoft published for this purpose.

Fragmented mp4 is the crash proof choice, and it costs you

There is a setting for fragmented mp4, and it is available only for the H264 codec. The explanation of why is the clearest statement of risk in the whole readme.

A fragmented mp4 file does not require finalizing it, which means that if the application or the GPU driver crashes, or if you run out of disk space, the partial mp4 file is still valid for playback. With a normal mp4, the index is written at the end, and a file that never got its index is unplayable, so a crash during a long recording loses everything up to that point.

The cost is stated just as clearly. A fragmented mp4 file is a bit larger than the normal format, and seeking is slower. So the choice is between a file that always plays and a file that is smaller and scrubs faster, and the readme presents it as a setting rather than a recommendation.

That is a well designed choice for a recorder, because the failure mode it protects against is the one that matters. A screen recorder is often used at exactly the moment something goes wrong, and a recorder that loses the file when the machine becomes unstable is not much use.

The same reasoning explains the limits on recording length and file size. Bounding the recording means a long unattended capture cannot fill a disk, which is both a practical limit and a protection for the fragmented format case.

Building it, and the batch file that makes a gif

Building the binary from source needs Visual Studio installed, and the instruction is to run build.cmd. That is the whole build, which is what you would expect from a program with no dependencies outside the Windows SDK.

The readme also ships a practical extra, a batch file for turning a recorded mp4 into a gif. The command is:

ffmpeg.exe -hide_banner -nostdin -loglevel fatal -stats -y -i %1 -filter_complex "[0]fps=15,split[v0][v1];[v0]palettegen=stats_mode=full[p];[v1][p]paletteuse" %~n1.gif

And there is a second variant that creates a new palette for every frame, for more colours at the cost of a larger file:

ffmpeg.exe -hide_banner -nostdin -loglevel fatal -stats -y -i %1 -filter_complex "[0]fps=15,split[v0][v1];[v0]palettegen=stats_mode=single[p];[v1][p]paletteuse=new=1" %~n1.gif

You put the line in a make_gif.bat file, place the ffmpeg executable next to it, and then drag and drop an mp4 file on top of it. The %1 is the input file that drag and drop supplies, and the %~n1 is the output name. The fps value can be changed to the desired gif frame rate, or removed to use the original video frame rate, and the readme points at the paletteuse filter documentation for the different dithering methods.

The palettegen and paletteuse pair is the standard way to make a gif with a good colour table, and the two variants are the two useful settings: one palette for the whole clip, which compresses better, or a palette per frame, which keeps more colour accuracy at the price of size.

Editorial conclusion

wcap suits a Windows user who wants a recorder that consumes very little CPU and memory, and a developer who wants to read a complete screen capture and encode pipeline in C rather than in a framework. It is the wrong choice if you are not on Windows, since the whole thing is built on the Windows.Graphics.Capture API, and a poor match if you need a signed installer, because the project publishes loose binaries and warns that antivirus software may report a false positive. Before downloading, check that your system is at least Windows 10 version 1903, and if you plan to use HEVC in software, install the HEVC Video Extensions first, since the encoder is otherwise unavailable.

Frequently asked questions

Official sources

1. Issues
2. License: Unlicense
3. mmozeiko/wcap on GitHub
4. README