Hardware Acceleration does not seem to work on Windows

[hanjo]

Hi,

It seems like the Hardware acceleration does not work on Windows. There aren't really any entries in the log file that it fails, but I can see in the Windows Task Manager and the Process Explorer that the GPU is not used by the process (and CPU usage is relatively high). Here are the entries from the log:

2026/01/16 12:03:56.928083 [Cam1] ffmpeg options: buffer_size=1048576 fflags=+nobuffer+discardcorrupt+genpts flags=+low_delay max_delay=500000 probesize=5000000 reorder_queue_size=0 rtsp_flags=prefer_tcp rtsp_transport=tcp stimeout=5000000 use_wallclock_as_timestamps=1
2026/01/16 12:03:57.846615 [Cam1] ffmpeg video options: err_detect=careful flags2=+showall hwaccel=nvdec skip_frame=default
2026/01/16 12:03:57.890292 scaler ready: 1920x1080 yuvj420p -> BGRA

I also tried setting the FFmpeg params to -chwaccel=qsv -chwaccel_output_format=qsv or -chwaccel=cuda -chwaccel_output_format=cuda, but that didn't change anything.

Thanks for looking into this!

[e1z0]

Hi,

Thanks for the thorough investigation — Task Manager, Process Explorer, FFmpeg flags, the whole CSI kit. Unfortunately, the conclusion is less exciting than the detective work.

TL;DR:
Yes, the GPU is idle.
No, it’s not broken.
Yes, this is exactly what the software is supposed to do right now.

Hardware acceleration on Windows is not implemented in this project.
It is also not advertised, not promised, and not secretly enabled by magic flags.

FFmpeg doing this:

hwaccel=nvdec
hwaccel=qsv
hwaccel=cuda

means exactly nothing unless the application:

• Creates and manages a GPU device context
• Statically linked with build of FFmpeg that is compiled with the correct HW backends
• Negotiates GPU frame formats
• Keeps the entire decode → scale → render pipeline on the GPU
• And doesn’t immediately pull frames back to the CPU like a raccoon stealing snacks
• None of that exists on Windows here. So FFmpeg politely nods, logs your options, and then decodes on the CPU anyway — silently, efficiently, and with zero complaints.

Important context that cannot be overstated 🚨

This software is v0.1.
That is:

• Alpha
• Prototype
• “Some buttons work, some are optimistic”
• “Features may exist philosophically”

Some things are:

• Incomplete
• Experimental
• Occasionally on fire
• Aspirational

If something looks like it should work but doesn’t — congratulations, you’ve found an alpha-grade feature.

So, before this turns into a legend:

• ❌ Not a bug
• ❌ Not a regression
• ❌ Not FFmpeg ignoring your flags
• ❌ Not Windows conspiring against you
• ✅ Unsupported functionality
• ✅ Expected behavior
• ✅ Alpha software doing alpha things

Want this fixed fast?

If you want Windows hardware acceleration implemented sooner rather than later, the fastest path is simple:

Implement it yourself and open a PR.

Seriously.

If you add proper Windows HW accel support (NVDEC / CUDA / QSV), wire it correctly, and it works:

• I’ll review it
• I’ll accept it
• I’ll merge it into master

Open-source development has a beautiful feature called “scratch your own itch” — and this one is very scratchable 😉

When (and if) Windows HW acceleration lands officially, it will be:

• Clearly implemented
• Clearly documented
• Obvious in logs
• Impossible to miss in GPU graphs

Until then, high CPU usage on Windows is not a failure — it’s the default.

Thanks for the report and the effort.
The GPU remains innocent and entirely unemployed 😄

[hanjo]

Ah, bummer! 😂

All right, I get your point. Unfortunately developing this is way past my programming skills. In that case, let me elevate this to a feature request. Maybe you'll find the time for this at some point.

Thanks!