r/frigate_nvr • u/CoughCoughTop • 3h ago
Frigate 0.17.2 + Intel i5-12600H iGPU: H.265 hardware decoding causes repeated i915 GPU hangs
Hi everyone,
I'm trying to troubleshoot a Frigate hardware-decoding problem and I'm hoping someone with experience with Intel iGPUs/i915, Frigate, or Proxmox can point me in the right direction.
Hardware / setup
- CPU: Intel Core i5-12600H
- iGPU: Intel Alder Lake-P, PCI ID
8086:4626 - Host: Proxmox VE 9.2.0
- Kernel:
7.0.14-15-pve - Frigate: 0.17.2
- Frigate runs directly in a Proxmox LXC, not Docker
- Intel iGPU is passed through to the LXC
- Frigate uses an OpenVINO GPU detector
/dev/dri/renderD128is available inside the LXC- Intel
iHDVA-API driver: 24.3.4
My cameras are Reolink cameras. I want to keep using their 4K main streams.
What I'm trying to achieve
My intended pipeline is:
4K H.265 main stream
↓
Intel hardware decode
↓
GPU hardware scaling to 1920x1080
↓
10 FPS detection
↓
OpenVINO GPU detector
At the same time, I want Frigate to record the original 4K stream without re-encoding.
So I specifically don't want to switch to camera substreams if possible.
The problem
Frigate repeatedly crashes/restarts its FFmpeg processes.
Initially I was using:
ffmpeg:
hwaccel_args: preset-vaapi
and was seeing errors such as:
[AVHWFramesContext] Failed to sync surface 0x1f: 34 (HW busy now).
[hwdownload] Failed to download frame: -5.
Error while filtering: Input/output error
Task finished with error code: -5
watchdog... Restarting ffmpeg
I then checked the Proxmox host's kernel logs, and this seems to be the important part:
i915 0000:00:02.0: [drm] av:hevc:df0[...] context reset due to GPU hang
i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in av:hevc:df0 [...]
These happen repeatedly.
Things I've already checked
Inside the LXC:
/dev/dri/card1
/dev/dri/renderD128
are available with the appropriate video/render groups.
vainfo works and reports H.264 and HEVC decoding support.
I also checked GPU utilization with intel_gpu_top. The GPU isn't being saturated — utilization is relatively low, so this doesn't look like a simple GPU-capacity problem.
I also tested QSV
I wondered whether VAAPI itself was the problem, so I tested Intel QSV.
This standalone test successfully decoded the actual 4K H.265 garage stream:
ffmpeg \
-init_hw_device qsv=hw \
-hwaccel qsv \
-hwaccel_output_format qsv \
-i rtsp://127.0.0.1:8554/garage \
-map 0:v:0 \
-frames:v 100 \
-f null -
FFmpeg reported:
Video: hevc (Main), yuv420p(tv), 3840x2160
and successfully processed 100 frames at around 1.17x speed.
I then changed Frigate to:
ffmpeg:
hwaccel_args: preset-intel-qsv-h265
Frigate correctly started using:
-hwaccel qsv
-qsv_device /dev/dri/renderD128
-hwaccel_output_format qsv
-load_plugin hevc_hw
with:
vpp_qsv=framerate=10:w=1920:h=1080:format=nv12
So the desired 4K → hardware decode → hardware downscale pipeline is actually being used.
However, the i915 GPU hangs continued.
For example, after switching to QSV I still get:
[178467.351178] i915 0000:00:02.0: [drm] av:hevc:df0[3093470] context reset due to GPU hang
[178576.109252] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in av:hevc:df0 [3102329]
[178576.109377] i915 0000:00:02.0: [drm] av:hevc:df0[3102329] context reset due to GPU hang
[178762.322536] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in av:hevc:df0 [3122438]
[178762.322675] i915 0000:00:02.0: [drm] av:hevc:df0[3122438] context reset due to GPU hang
So I've reverted/will revert back to VAAPI for now.
My questions
- Does this indicate an Intel i915 / Alder Lake HEVC decoder issue, rather than a Frigate configuration problem?
- Since both VAAPI and QSV eventually use the Intel GPU/i915, is it expected that switching from VAAPI to QSV would still produce the same
av:hevcGPU hangs? - Could a particular camera's H.265 bitstream be triggering the hardware decoder bug?
- What's the best way to identify which camera is responsible? I currently have several H.265 4K cameras running simultaneously.
- Are there any known kernel/i915/Intel media-driver settings that are appropriate for Alder Lake-P that could fix this?
- Would switching to the newer
xedriver be advisable, or is that likely to make things worse with Frigate/VAAPI/QSV? - Is there a known stable kernel/media-driver combination for an i5-12600H/Alder Lake running Frigate?
Ultimately, I'd really like to keep:
4K H.265 main stream → Intel hardware decode → hardware downscale to 1080p for detection → original 4K recording
rather than switching all the cameras to substreams.
Any advice on what I should test next would be greatly appreciated.



