# ScreenRecorder: a Windows screen capture tool with hardware encoding

> ScreenRecorder is a C# and WPF application for recording the screen and audio on Windows, using the Windows Graphics Capture API through FFmpeg. It defaults to H.264 with NVENC or QuickSync when the hardware supports it, falls back to software encoding when it does not, and ships as a self-contained installer with no separate .NET runtime needed.

**akon47/ScreenRecorder** — ⏺️ A simple recording program with the ability to record screens and audio on your computer.

- Repository: https://github.com/akon47/ScreenRecorder
- Stars: 551 · Forks: 57
- Language: C#
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/akon47-screenrecorder

## A small Windows application, deliberately

Screen Recorder is described as a simple recording program with the ability to record screens and audio on your computer, and the readme says it is a simple recording program with the ability to record the screen.

Simple is doing real work in that description, because the alternative category of software exists and is large. A screen recorder can be a consumer app with effects, a browser extension, a streaming tool integrated into a broadcasting platform, or a developer utility. This one is a small desktop application with two screenshots in the readme, one showing default settings and one showing advanced settings, and a usage description that takes two sentences.

The usage section says that pressing the round button starts recording and stops when pressing the square button, and that pressing the Cogwheel button in the lower right corner displays a pop-up menu for recording settings. That is the whole interaction model, and it is the right one for a program whose purpose is to be reached for, record something, and get out of the way.

The technology choices explain why it is Windows only. It is C# with WPF, it uses the Windows Graphics Capture API, and it requires DirectX 11 or later for that API. The supported platform is Windows 10 64bit version 1903 or newer, with version 2004 or later recommended specifically so that self-window exclusion works reliably.

That last detail is worth dwelling on. The feature list says the program itself is recorded without being included in the recording screen, and the system requirements say version 2004 or later is recommended for that. So there is one feature whose reliability depends on a specific Windows build, and the readme tells you which one rather than leaving you to discover that the window flickers into its own recording.

The project is GPL-3.0, the primary language is C#, the default branch is develop, and there is a Korean translation of the readme alongside the English one. The recent releases are 2.1.0 and 2.0.1, both on 2026-07-08, and 2.0.0 on 2026-06-25.

## Codec selection and the hardware fallback

The codec behaviour is the most substantive part of the feature list, and it is the part that determines whether a recording is smooth on your machine.

By default the video codec is H.264. If your computer supports hardware codecs for NVENC or QuickSync, the program uses them first. And if necessary, the H.265 codec can be selected from the advanced settings menu, with a warning that if hardware encoding is not supported, very high CPU load can occur.

So the ordering is hardware first, software second, and the readme is explicit that hardware encoding falls back to software, naming the specific encoders, libx264 and libx265, that it falls back to. That is the difference between a program that degrades quietly and one that fails or drops frames, and it is worth knowing which you have.

The hardware requirements are given precisely. For NVENC H.264 you need a GTX 600 series card or higher. For NVENC HEVC you need a GTX 950 series or higher. And the minimum required Nvidia driver for NVENC is 522.25 or newer.

Those numbers are useful because NVENC support is not simply a matter of having an Nvidia card. The hardware encoder arrived with the GTX 600 series, and HEVC encoding came later with the GTX 950 series, so a machine can be perfectly capable of NVENC H.264 and completely incapable of NVENC HEVC. The readme gives both floors so you know which option is open to you.

Audio works the same way. By default the audio codec is AAC, and MP3 can be selected from the advanced settings if needed. Microphone recording is supported and records the system default capture device, which is handled through NAudio and the WASAPI API.

The frame rate default is 60 fps, with 15, 24, 25, 30, 48, 50, 60, 120 and 144 fps available in the advanced settings. The list covering both broadcast standard rates and high frame rates for slow motion is a good sign about who the tool is for, since 24, 25, 30 and 50 are the rates that match film and broadcast delivery.

## What you can capture, and the region modes

The capture selection has three options, and they are worth distinguishing because each solves a different problem.

Capture Region lets the user specify a region by dragging it out, which is the mode for recording part of a window or a panel. Capture Window records a specific application window. Capture Display records the whole screen.

Recording a region is the most common need for most people, because the interesting content is rarely the whole desktop. It also produces the smallest file, and the smaller file is the one you can then edit.

Cursor capture is a separate setting, so you can set whether the mouse cursor is captured or not. That is a small feature with a real use: a cursor in the middle of a tutorial video draws the eye away from what you are pointing at, and in a demonstration where the mouse is irrelevant, hiding it is the difference between a clean recording and a distracting one.

The hotkey support is the other thing that makes a recorder pleasant to use. Recording function using hotkeys means you do not have to alt-tab to the application to start and stop, which matters because the moment you alt-tab, the alt-tab itself is on screen in the recording.

And then there is the self-exclusion feature, the program itself is recorded without being included in the recording screen. Every screen recorder has this problem, because the window you press record in is by definition visible. Most of them solve it by hiding the window for a moment, which produces a flicker in the output. Solving it properly is what the Windows 2004 recommendation is about.

The layering of these features tells you the priorities: the tool is aimed at someone making a demonstration video or a tutorial, where the content of the recording, the cursor behaviour, the region choice and the absence of the recorder's own window all matter.

## Building it, and the FFmpeg dependency you must supply

The build section is short and the important part is a dependency you have to provide yourself.

The requirements are the .NET 9 SDK for the win-x64 platform and Windows 10 64bit or newer. And then this: FFmpeg shared libraries are not committed. Before running or building, place the 5 FFmpeg 8.x shared DLLs, avcodec-62, avformat-62, avutil-60, swresample-6 and swscale-9, into Externals/ffmpeg/win-x64/, following the readme in that directory. The readme suggests the gyan.dev ffmpeg-8.1-full_build-shared build as a source.

The reasoning is understandable. FFmpeg's shared builds are large, they are platform specific, and the licence situation for redistributing them is not straightforward, so a project that ships an installer would rather not bundle them. The cost is that a contributor cannot clone and build without a second download step, and the exact DLL names and versions are specified so there is no ambiguity about what to fetch.

The build and run commands are:

```pwsh
# Build & run
dotnet run --project ScreenRecorder/ScreenRecorder.csproj

# Build the installer (publish + NSIS) — requires NSIS (makensis)
Installers\build_setup.bat 2.0.0
```

So the installer is produced by a batch script that takes the version number as an argument, and it needs NSIS with the makensis tool available. The readme notes the installer is self-contained and no separate .NET runtime is required, which is the right choice for a program you install on a machine that is not a developer machine.

The repository layout shows a reasonable separation. There is ScreenRecorder/, which is the WPF application, ScreenRecorder.Engine/, which is presumably the capture and encoding logic, and ScreenRecorder.EncoderHarness/, which sounds like a test harness for the encoder path specifically. There is an Installers/ directory, an Externals/ directory for the FFmpeg binaries, a Directory.Build.props at the root for shared build properties, ScreenRecorder.sln as the solution, and a CLAUDE.md.

Splitting the encoder into its own harness is a sensible thing to do for this kind of project. Encoding is the part that is hard to test through the user interface, and a harness lets you drive it directly.

## The libraries underneath and how the project is run

The third party libraries section names four projects, and each one maps to a specific capability.

FFmpeg comes through FFmpeg.AutoGen, which is the.NET binding generator that produces the P/Invoke layer for libavcodec and friends. So FFmpeg is doing the actual encoding and muxing, and the.NET side is a thin wrapper over it.

Vortice.Windows provides the Direct3D 11 and DXGI access, which is what the Windows Graphics Capture API hands you. The capture API returns Direct3D surfaces rather than bitmaps, so you need a graphics API to read them, and DXGI is the plumbing that gets a frame from a surface into something the encoder can use.

NAudio provides the WASAPI audio capture, which is how the microphone recording and the system audio work. WASAPI is the modern Windows audio API and it is what a native application should be using.

CommunityToolkit.Mvvm is the MVVM toolkit, which tells you the application is written with the Model-View-ViewModel pattern.

The project is also reviewed on two third party download sites, a Softpedia review of v1.0.4 and an ilovefreesoftware review, both linked under References. That is worth noting because those directories tend to list software by category, and being listed is a small signal about how the tool is perceived by the download sites people actually find it on.

On process, the readme asks for feature requests to be filed as issues with a Feature Request label, and for bugs to be reported on GitHub Issues. It states plainly that the project is open source and that anyone can contribute in any way.

The GitHub links at the top of the readme cover the usual ground, with a release version badge, a stars badge, a licence badge and a download counter pointing at kimhwan.kr. The release pattern is telling: three releases in a short window, 2.0.0 on 2026-06-25, then 2.0.1 and 2.1.0 both on 2026-07-08. That looks like a 2.0 release followed by a burst of fixes, and the default branch being develop rather than master suggests the release branch is cut from it.

## Conclusion

Adopt ScreenRecorder if you are on Windows and want a small, predictable screen recorder that uses the GPU when it can, since the codec selection and the hardware fallback are handled for you. Do not adopt it if you need cross-platform capture, because the whole implementation is built on Windows specific APIs, and check the frame rate options against your display, since the default of 60 fps is not always what you want for a static screen. Before you commit, read the system requirements, in particular the DirectX 11 requirement and the minimum Nvidia driver version for NVENC, and expect to supply the FFmpeg shared libraries yourself if you build from source.

## FAQ

### What is ScreenRecorder?

It is a simple recording program for Windows that can record the screen and audio, written in C# with WPF. You press a round button to start and a square button to stop, and a cogwheel button in the lower right corner opens the recording settings menu.

### Which codecs does ScreenRecorder use and does it support hardware encoding?

H.264 is the default video codec and AAC the default audio codec. If the computer supports NVENC or QuickSync, the hardware encoders are used first, and hardware encoding falls back to software, naming libx264 and libx265, when it is unavailable. H.265 and MP3 can also be selected from the advanced settings.

### What are the system requirements for ScreenRecorder?

Windows 10 64bit version 1903 or newer, with version 2004 or later recommended so that self-window exclusion works properly, and a graphics card compatible with DirectX 11 or later for the Windows Graphics Capture API. For NVENC H.264 you need a GTX 600 series or higher, for NVENC HEVC a GTX 950 series or higher, and Nvidia driver 522.25 or newer.

### What can ScreenRecorder capture?

Three modes: Capture Region, where the user specifies the area, Capture Window for a particular application window, and Capture Display for the whole screen. Cursor capture can be turned on or off separately, recording can be started and stopped with hotkeys, and microphone recording captures the system default device.

### How do I build ScreenRecorder from source?

You need the .NET 9 SDK for win-x64 and Windows 10 64bit or newer, and you must supply the FFmpeg shared libraries yourself because they are not committed. Place the five FFmpeg 8.x DLLs, avcodec-62, avformat-62, avutil-60, swresample-6 and swscale-9, into Externals/ffmpeg/win-x64/. Then use dotnet run to launch it, and Installers\build_setup.bat with a version argument to produce the NSIS installer.

## Sources

- [akon47/ScreenRecorder on GitHub](https://github.com/akon47/ScreenRecorder)
- [Issues](https://github.com/akon47/ScreenRecorder/issues)
- [License: GPL-3.0](https://github.com/akon47/ScreenRecorder/blob/develop/LICENSE)
- [README](https://github.com/akon47/ScreenRecorder/blob/develop/README.md)
- [Releases](https://github.com/akon47/ScreenRecorder/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/akon47-screenrecorder