Intel Arc GPU compatibility issues with FFMPEG?

Hosting
#1

I’m running Channels DVR inside an LXC on Proxmox, and everything works perfectly except browser playback. Live TV works, app playback works, transcoding works, and hardware acceleration is active — but browser playback fails immediately.

My hardware is a Minisforum system with an Intel Core Ultra 125H (Intel Arc Graphics 140T).
This GPU uses Intel’s newer iHD VAAPI driver (intel-media-va-driver-non-free).

The issue appears to be specific to the FFmpeg parameters used for browser HLS transcoding. Other transcoding paths work fine.

Here’s the relevant transcoder log from a failed browser playback attempt:

2026/03/04 23:12:23.390325 [ENC] Starting encoder for ch8.1 in /mnt/DVR/Streaming/sessions/ch8.1-dANY-ip192.168.0.101-1206237781/encoder-1-2739513289 at 1 (1.136100) (encoder=h264_vaapi, codec=h264, acodec=aac, resolution=1080, deinterlacer=hardware, bitrate=9488, segment_size=0.01)
2026/03/04 23:12:24.390063 [HLS] ffmpeg: ch8.1-dANY-ip192.168.0.101-1-h264-aac---9488-256-1080-6-0---false-false-0.01-0:  [h264_vaapi @ 0x46a41d80] Failed to map output buffers: 24 (internal encoding error).
2026/03/04 23:12:24.390091 [HLS] ffmpeg: ch8.1-dANY-ip192.168.0.101-1-h264-aac---9488-256-1080-6-0---false-false-0.01-0:  [h264_vaapi @ 0x46a41d80] Output failed: -5.
2026/03/04 23:12:24.390094 [HLS] ffmpeg: ch8.1-dANY-ip192.168.0.101-1-h264-aac---9488-256-1080-6-0---false-false-0.01-0:  [vost#0:0/h264_vaapi @ 0x46a418c0] Error submitting video frame to the encoder
2026/03/04 23:12:24.395145 [HLS] ffmpeg: ch8.1-dANY-ip192.168.0.101-1-h264-aac---9488-256-1080-6-0---false-false-0.01-0:  [aac @ 0x46a3e000] 2 frames left in the queue on closing
2026/03/04 23:12:24.395307 [HLS] ffmpeg: ch8.1-dANY-ip192.168.0.101-1-h264-aac---9488-256-1080-6-0---false-false-0.01-0:  [aac @ 0x46a40e80] 2 frames left in the queue on closing
2026/03/04 23:12:24.451375 [ENC] Encoder stopped for ch8.1 in /mnt/DVR/Streaming/sessions/ch8.1-dANY-ip192.168.0.101-1206237781/encoder-1-2739513289 after encoding 1 to 2
2026/03/04 23:12:24.451417 [ENC] Next segment to pre-encode of 3 is 4.506133333s from the last request of 1

I think the key error is:
[h264_vaapi] Failed to map output buffers: 24 (internal encoding error)

This only happens during browser playback. All other transcoding paths work normally.

From what I can tell, this looks like a VAAPI parameter incompatibility between the FFmpeg command used for browser HLS transcoding and the newer Intel iHD driver used by Meteor Lake / Core Ultra GPUs.

Any help getting this resolved to full functionality is greatly appreciated.

#2

IF you are using Chrome as your browser, this started happening sometime towards the end of last year. Some change in Chrome caused it.

The only "fix" for it, is to use a different browser that's NOT based on Chrome. In my case, it works perfectly in FireFox.

Technically, Channels browser based watching is NOT supported by the devs, so it is, what it is.

#3

If you use Windows, I'm working on a way to watch Channels media including live TV.

#4

I'm using Firefox, but have tried Chrome as well. Neither of them fix this issue. I think it has less to do with the browser and more to do with the incompatibility of the Channels commands to FFMPEG that are not compatible with the new GPU drivers.

Thanks for the idea to check the browser.

#5

I'm less interested in having a regular use solution on Windows, and more interested in fixing the Channels web interface playback just as an administrative tool. Having the Windows client would provide a potential solution, albeit less integrated. If there was a way for Channels to select an alternate player when launching a stream from the web interface, that might also be a reasonable solution.

Part of the problem is that browsers force some type of transcoding (HLS passthrough?) that isn't handled well by the latest video driver... the parameters are passed to ffmpeg and then to the video driver and there's some sort of incompatibility. As a note, I have Channels hosted on my Synology NAS (older CPU and GPU, thus older drivers) and it plays back fine through the browser... so it is related to the more recent GPUs and drivers that is causing the issue.

Thanks for offering a potential work-around... much appreciated.

#6

This is happening when running ffmpeg transcoding using "-hwaccel qsv -hwaccel_output_format qsv" or possibly some other part of ffmpeg while using chrome. When I download a bunch of video files I then transcode them in the background. This used to work fine but lately it stopped working. I noticed it broke ffmpeg every time I would run chrome or edge while transcoding. If I run brave it works fine(probably an older version of brave). Once it breaks I have to reboot to get it to work again. FFmpeg reports an issue with finding the A770 gpu.

#7

I think this is likely a related problem to what I originally reported... an issue with HLS transcoding through ffmpeg and compatibility with the latest GPU drivers.

Is this just a matter of waiting for Channels to use a newer ffmpeg (and parameter calls) that is more compatible with the latest GPU drivers? Are we just in a holding pattern as things get updated in parallel?

Again, appreciate any comments/suggestions.