[Support]: Auto-detected VAAPI on Intel Iris Xe crashes ffmpeg every ~10 min with "Failed to sync surface" / hwdownload -5; explicit QSV is a clean workaround

[pbhwheeler]

Checklist

• I have updated to the latest available Frigate version. (0.17.1)
• I have cleared the cache of my browser. (N/A — backend ffmpeg crash, not a UI issue.)
• I have tried a different browser to see if it is related to my browser. (N/A.)
• I have tried reproducing the issue in incognito mode. (N/A.)
• I have asked the AI at https://docs.frigate.video about my issue.

Describe the problem you are having

On a fresh Frigate 0.17.1 install on Home Assistant OS with an Intel Iris Xe (Gen 12) iGPU, Frigate's automatic hwaccel detection picks vaapi. The resulting ffmpeg detect workers crash periodically (≈ every 10 minutes per camera, both cameras affected simultaneously since they share the iGPU). Each crash takes the camera offline in HA for 10–20 seconds while the watchdog restarts ffmpeg. ~150 crash-recovery cycles per camera per day, ≈ 42 min total downtime/camera/day.

The error signature in ffmpeg.<camera>.detect:

[AVHWFramesContext @ 0x7faf100772c0] Failed to sync surface 0xc: 1 (operation failed).
[hwdownload @ 0x7faf20003980] Failed to download frame: -5.
[vf#0:0 @ 0x55dd27012d00] Error while filtering: Input/output error
[vf#0:0 @ 0x55dd27012d00] Task finished with error code: -5 (Input/output error)
watchdog.<camera> INFO : Restarting ffmpeg...

Surface IDs vary across crashes (0xa, 0xc, 0x10, 0x11, 0x12, 0x15 observed) — consistent with VAAPI surface-pool churn rather than a single bad surface. The record-role ffmpeg workers do not crash (they use -c:v copy, no decoding).

Workaround that completely fixes it: explicitly setting hwaccel_args: preset-intel-qsv-h264 at the camera level (Intel QuickSync) on the same iGPU. With QSV, 9.5 hours of monitoring produced zero drop-recovery pairs (vs. ~57 expected at the VAAPI baseline). Reporting it because the auto-detection picks the broken path, not the working one, on commodity Intel hardware.

Steps to reproduce

1. Install Frigate 0.17.1 as a Home Assistant OS Supervisor add-on on hardware with a Gen 12 Intel iGPU (e.g., OptiPlex 7090 with Iris Xe).
2. Configure two cameras with separate detect and record roles (record h265, detect h264 substream).
3. Do not set hwaccel_args anywhere — let auto-detection run.
4. Start Frigate. The startup log will show:

   frigate.util.services INFO : Automatically detected vaapi hwaccel for video decoding
   

5. Wait ~10 minutes. ffmpeg crashes begin.
6. Verify the workaround: set cameras.<name>.ffmpeg.hwaccel_args: preset-intel-qsv-h264 for each camera, restart Frigate. Crashes stop.

Version

0.17.1-416a9b7 (stable; from the HA add-on store).

In which browser(s) are you experiencing the issue with?

N/A — backend ffmpeg crashes, not a UI issue.

Frigate config file (minimal repro)

mqtt:
  enabled: false

detectors:
  coral:
    type: edgetpu
    device: usb

go2rtc:
  streams:
    cam1:     [rtsp://admin:PW@192.168.1.84:554/h265Preview_01_main]
    cam1_sub: [rtsp://admin:PW@192.168.1.84:554/h264Preview_01_sub]

cameras:
  cam1:
    ffmpeg:
      # With this commented out, auto-VAAPI is picked and crashes.
      # With `hwaccel_args: preset-intel-qsv-h264`, no crashes.
      inputs:
        - path: rtsp://127.0.0.1:8554/cam1
          input_args: preset-rtsp-restream
          roles: [record]
        - path: rtsp://127.0.0.1:8554/cam1_sub
          input_args: preset-rtsp-restream
          roles: [detect]
    detect:
      width: 640
      height: 360
      fps: 5

docker-compose file or Docker CLI command

N/A — running as a Home Assistant Supervisor add-on (slug ccab4aaf_frigate).

Relevant Frigate log output

Sustained pattern of crashes (timestamps span ~5 minutes; alternating between the two cameras):

[02:38:30] frigate.video                  ERROR : carport_east: Unable to read frames from ffmpeg process.
[02:38:30] frigate.video                  ERROR : carport_east: ffmpeg process is not running. exiting capture thread...
[02:38:38] watchdog.carport_east          ERROR : Ffmpeg process crashed unexpectedly for carport_east.
[02:38:38] ffmpeg.carport_east.detect     ERROR : [AVHWFramesContext @ 0x7fbc00076b80] Failed to sync surface 0x10: 1 (operation failed).
[02:38:38] ffmpeg.carport_east.detect     ERROR : [hwdownload @ 0x7fbc08003980] Failed to download frame: -5.
[02:38:38] ffmpeg.carport_east.detect     ERROR : [vf#0:0 @ 0x564195867f40] Error while filtering: Input/output error
[02:38:38] ffmpeg.carport_east.detect     ERROR : [vf#0:0 @ 0x564195867f40] Task finished with error code: -5 (Input/output error)
[02:38:38] ffmpeg.carport_east.detect     ERROR : [vf#0:0 @ 0x564195867f40] Terminating thread with return code -5 (Input/output error)
[02:38:38] watchdog.carport_east          INFO  : Restarting ffmpeg...
[02:40:02] frigate.video                  ERROR : carport_west: Unable to read frames from ffmpeg process.
[02:40:02] frigate.video                  ERROR : carport_west: ffmpeg process is not running. exiting capture thread...
[02:40:08] watchdog.carport_west          ERROR : Ffmpeg process crashed unexpectedly for carport_west.
[02:40:08] ffmpeg.carport_west.detect     ERROR : [AVHWFramesContext @ 0x7f120c077340] Failed to sync surface 0x11: 1 (operation failed).
[02:40:08] ffmpeg.carport_west.detect     ERROR : [hwdownload @ 0x7f1210003980] Failed to download frame: -5.
[02:40:08] ffmpeg.carport_west.detect     ERROR : [vf#0:0 @ 0x55ae14bca6c0] Error while filtering: Input/output error
[02:40:08] ffmpeg.carport_west.detect     ERROR : [vf#0:0 @ 0x55ae14bca6c0] Task finished with error code: -5 (Input/output error)
[02:40:08] watchdog.carport_west          INFO  : Restarting ffmpeg...

Quantified comparison (same hardware, same RTSP sources, same Frigate version):

Setting	Drops/24h/camera	Total downtime/24h/camera	Worst single drop
Auto (= VAAPI)	~152	~42 min	211 s
preset-intel-qsv-h264 (explicit)	0 in 9.5 h observed	0	n/a

Relevant go2rtc log output

03:04:02.827 ERR github.com/AlexxIT/go2rtc/internal/webrtc/webrtc.go:48 > error="listen udp [fe80::d4eb:24ff:feef:6048%eth0]:8555: bind: cannot assign requested address"

(Single startup warning about IPv6 link-local UDP bind; unrelated to the decode crashes — included for completeness.)

Operating system

Home Assistant OS

Install method

Home Assistant Add-on

Network connection

Wired

Camera make and model

Reolink (h265 main + h264 sub via the go2rtc restream — IPs 192.168.1.84 and 192.168.1.85; both PoE wired ethernet, gigabit switch). Both cameras drop together because they share the iGPU; this is not a camera or network issue.

Screenshots of the Frigate UI's System metrics pages

I will attach screenshots of the System / Cameras / Detectors tabs in a follow-up comment within 24 hours. Posting now so the diagnostic data lands while it's fresh.

Any other information that may be helpful

Hypothesis about root cause: likely a wrong LIBVA_DRIVER_NAME (e.g., i965 instead of iHD) in the Frigate 0.17.1 container for Gen 12 iGPUs, or a stale iHD driver in the bundle. The pattern of varying surface IDs failing across crashes — combined with QSV (different code path on the same iGPU) working perfectly — points at the VAAPI userspace driver rather than the kernel i915 layer or hardware.

A docs note or release-notes pin suggesting preset-intel-qsv-h264 for Gen 12 hardware would save downstream users the discovery cost. Right now the auto-detector picks the broken path, the cameras "mostly work" (record/detect both technically alive between crashes), and the underlying ~3% downtime is silent unless you happen to wire up external reachability monitoring (which is how I noticed).

Tested workaround:

cameras:
  cam1:
    ffmpeg:
      hwaccel_args: preset-intel-qsv-h264
      inputs:
        - path: ...
          roles: [record]   # record streams are -c:v copy, hwaccel doesn't apply
        - path: ...
          roles: [detect]   # detect substream goes through QSV cleanly

Happy to test patches or pre-release builds against this same hardware if useful.

[inkeep-ai-assistant[bot]]

Your diagnosis and workaround are correct. For Intel Gen 12 (Iris Xe) and newer iGPUs, the recommended preset is preset-intel-qsv-* rather than preset-vaapi. (1)

The hardware acceleration documentation specifies the following for Intel CPUs: (1)

• gen8 - gen12: preset-vaapi is listed as recommended, but preset-intel-qsv-* can also be used
• gen13+ and Intel Arc GPU: preset-intel-qsv-* is the recommended preset

For H.264 streams specifically: (1)

ffmpeg:
  hwaccel_args: preset-intel-qsv-h264

(1)

For H.265 streams: (1)

ffmpeg:
  hwaccel_args: preset-intel-qsv-h265

(1)

The default driver is iHD. If you experience issues, you may need to change the driver to i965 by adding the environment variable LIBVA_DRIVER_NAME=i965 to your docker-compose file or in the config.yml for HA App users. (1)

Your explicit QSV configuration is the correct approach for your Gen 12 hardware: (1)

cameras:
  cam1:
    ffmpeg:
      hwaccel_args: preset-intel-qsv-h264

(1)

The VAAPI surface sync failures you're experiencing (Failed to sync surface) with auto-detection suggest the VAAPI code path has compatibility issues with your specific iGPU/driver combination. Since QSV uses a different code path on the same hardware and works reliably, your workaround is the appropriate solution. (1)

The hwaccel presets not only replace longer args but also give Frigate hints about available hardware, allowing optimizations for encoding the birdseye restream or scaling streams. (2)

📚 Sources:

1. Video Decoding
2. FFmpeg presets

---

Have another question? Just tag @inkeep.

[NickM-27]

To be clear this is not a bug, vaapi is a best guess effort, currently there is no dynamic GPU hardware acceleration selection where we know exactly which Intel generation is used and which preset to use. Configuration can always be needed given specific hardware

[pbhwheeler]

Attaching the System-metrics screenshots the bug-report template asks for. These were captured after the preset-intel-qsv-h264 workaround was applied — they document the healthy steady-state under QSV rather than the original VAAPI failure (the failure is captured by the ffmpeg log signature in the body, which I didn't want to re-introduce just to screenshot).

This Frigate build has three System tabs (General / Storage / Cameras) — detector info is folded into General. All three attached:

System → General

Shows intel-qsv 0.0% GPU usage (proves QSV is the active hwaccel — auto-VAAPI is no longer in the picture), Coral at 10ms inference / 0% CPU / 1% memory, version 0.17.1-416a9b7, "System is healthy" banner.

System → Cameras

This is the headline screenshot for the report. Note skipped = 0 across the board (overall row + both Carport East and West) — the metric that would have been climbing every ~10 min under the broken auto-VAAPI path. ffmpeg CPU is ~1% per camera, capture/detect FPS matches the configured 5fps. Stable PIDs, no churn.

System → Storage

Included for template completeness (not directly bug-relevant).

---

For pre-fix comparison: the ffmpeg crash signature, periodicity (~150 crash-recovery cycles/24h per camera), and total downtime (~42 min/24h per camera) are all quantified in the original post. If maintainers want a side-by-side "before" capture from this same hardware I can temporarily revert to auto-VAAPI to grab it — just say the word.

[pbhwheeler]

Thanks both — especially @NickM-27 for the WAI clarification. That reframes my report: this isn't a defect, it's the expected "auto-detect is a best-guess, configure explicitly for your hardware" path. Calling it a [Bug]: was the wrong framing in retrospect; "Gen 12 Iris Xe needs explicit preset-intel-qsv-h264" is the more accurate ticket.

Two corrections to the original post, for the next person who lands here with the same Failed to sync surface symptom:

1. I hypothesized in the body that the container ships LIBVA_DRIVER_NAME=i965 and that's what was crashing on Gen 12. That was inverted. Per the docs and @NickM-27's clarification: iHD is the modern default (and is what was active in my failing case). i965 is what you'd switch to as a fallback for older architectures. My environment was using iHD correctly; the VAAPI path with that driver had compatibility issues that QSV sidesteps on the same iGPU.
2. The hwaccel-presets-as-hardware-hints detail (presets unlock optimizations for birdseye restream / scaling) is genuinely useful information I didn't know — worth knowing for anyone deciding between explicit presets vs. raw ffmpeg arg lists. Thanks for the heads-up.

QSV (preset-intel-qsv-h264) is in place on both my carport cameras and stable: 9.5 hours of overnight monitoring after the switch produced zero drop-recovery transitions on either camera (vs. ~152/24h/camera on auto-VAAPI). Marking @NickM-27's reply as the answer.