homebridge-hikvision-dvr 1.2.2 → 1.4.0

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # Changelog
 
+## 1.4.0
+
+Better live video on a PC or server (anything that isn't a Raspberry Pi), including encoding on an Intel/AMD GPU. Raspberry Pi behaviour is unchanged.
+
+- **GPU encoding (VAAPI / Intel Quick Sync).** With *Video processing* on Automatic, a PC or server with a GPU (`/dev/dri/renderD*`) encodes H.264 on the GPU when an ffmpeg with `h264_vaapi` is available and a real one-second test encode succeeds. Streams are decoded in software, scaled and encoded on the GPU, so a 1080p stream costs about 0.3 of a core where libx264 at 720p costs 0.6-0.8 and at 1080p more than one. A new *Intel/AMD GPU encoder (VAAPI)* choice under *Video processing* asks for it explicitly. GPU *decoding* was tested and is not used: it was only slightly cheaper and the picture was blockier.
+- **How ffmpeg is chosen.** *Custom ffmpeg path* always wins. Otherwise the plugin uses its bundled ffmpeg, except that on a non-Pi machine with a GPU it first looks for a system ffmpeg (`ffmpeg` on the PATH, `/usr/bin/ffmpeg`, `/usr/local/bin/ffmpeg`) that has both `h264_vaapi` and `libx264` and passes the test encode, and uses that one. The bundled ffmpeg has no VAAPI. The log says which encoder and which ffmpeg are in use.
+- **Fallback.** If a GPU encode produces no video within 8 s or ffmpeg exits, that stream switches to libx264 (at most 1280x720). After three failures in a row with no GPU stream working, the GPU is left alone for 10 minutes.
+- **Higher quality on a PC/server.** The viewer gets the size it asks for (up to 1920x1080 on the GPU, 1280x720 with libx264, since the DVR's 960x1080 main stream has no more detail) from the main stream for up to 4 viewers at once; a fifth viewer gets the sub stream. Minimum bitrates by size: GPU 5000 kbps for 1080p, 3000 kbps for 720p; libx264 2000 kbps for 720p (the GPU encoder needs roughly twice the bitrate of libx264 `veryfast` for the same sharpness). *Minimum bitrate* still overrides. 1080p streams are labelled H.264 level 4.0.
+- **Even frame timing (all fast hosts).** libx264 and GPU streams use a two-stage pipeline: the encoder outputs a constant 25 fps and a copy-only second ffmpeg stamps the frames exactly 40 ms apart for SRTP. DVRs deliver about 20 fps with irregular gaps, and passing that timing through showed as judder.
+- **Abandoned streams stop sooner.** A stream whose viewer stops sending RTCP (for example an Apple TV tile it gave up on without sending a stop) is now ended after 15-30 s (it was at least 30 s and up to ten report intervals), so HomeKit can start a new one. The log says how many reports had arrived.
+
+## 1.3.0
+
+Smoother live video when Homebridge runs on a PC or server (anything that isn't a Raspberry Pi).
+
+- On a machine with 4 or more cores and no Pi hardware encoder, software-encoded streams use libx264 with the `veryfast` preset (a cleaner picture than `ultrafast`) in a single ffmpeg process, passing the DVR's frame timestamps through to the viewer (`-fps_mode passthrough`) instead of forcing a constant frame rate.
+- Raspberry Pi behaviour is unchanged.
+
 ## 1.2.2
 
 Fixes video freezing and high load on a Raspberry Pi when several cameras are opened at once (for example the 4-camera grid on an Apple TV).

package/README.md

@@ -31,9 +31,9 @@ Only the IP address, username and password are needed. Everything else is option
 | Motion sensors | on | A motion sensor per camera, from the DVR's own motion detection (see below) |
 | Motion reset | 30 s | How long motion stays on after the DVR's last motion event |
 | Verification code | read from DVR | Only needed if the plugin can't read it. Use the 6-letter code on the DVR's sticker, or the one set in Hik-Connect / HiLook |
-| Video processing | Automatic | Uses the Raspberry Pi hardware encoder when available (for views wider than 640 px; smaller views use libx264, which starts faster), otherwise libx264. With several viewers at once (e.g. an Apple TV camera grid) it automatically uses smaller output and the DVR's sub stream so a Pi keeps up (see below). *No transcoding* passes the DVR's stream through untouched (lowest CPU, experimental) |
+| Video processing | Automatic | Uses the Raspberry Pi hardware encoder when available (for views wider than 640 px; smaller views use libx264, which starts faster); on a PC/server with an Intel/AMD GPU and a VAAPI ffmpeg, the GPU (see [PC / server](#pc--server-with-an-intelamd-gpu)); otherwise libx264. With several viewers at once (e.g. an Apple TV camera grid) it automatically uses smaller output and the DVR's sub stream so a Pi keeps up (see below). *No transcoding* passes the DVR's stream through untouched (lowest CPU, experimental) |
 | Use sub stream up to width | 0 (never) | e.g. `320` serves Apple Watch views from the low-res sub stream |
-| Minimum bitrate | automatic | iOS often asks for only ~300 kbps; the plugin uses at least 1200 kbps for 720p+. `0` = exactly what iOS asks |
+| Minimum bitrate | automatic | iOS often asks for only ~300 kbps; the plugin uses at least 1200 kbps for 720p+ (2000-3000 kbps for 720p and 5000 kbps for 1080p on a PC/server). `0` = exactly what iOS asks |
 | Max viewers per camera | 2 | |
 | Web console / port | off / 8100 | Serves the DVR's web page with live view, playback and motion areas working (see below) |
 | Web console: log in automatically | off | Skips the console's login page by logging in with the plugin's DVR account. Anyone on your network can then use the console (see below) |
@@ -91,8 +91,35 @@ picks a path for every stream as it starts, depending on how many are being view
 | 3 or more | sub stream | 640x360, 800 kbps, hardware encoder; a fifth and later stream is passed through unchanged |
 
 If the hardware encoder fails for one stream, only that stream falls back to libx264. If it is wedged (nothing is encoding in hardware),
-it is avoided for 10 minutes and then tried again. The DVR itself delivers only a few Mbit/s in total, so several main streams at once
-would be slow even with a faster computer. Hardware video *decoding* on the Pi was tried and made things slower.
+it is avoided for 10 minutes and then tried again. The Pi's own network and CPU limit it to a few Mbit/s of DVR video in total, so several main streams at once are slow there. (A PC or server has no such limit; see below.) Hardware video *decoding* on the Pi was tried and made things slower.
+
+## PC / server with an Intel/AMD GPU
+
+On anything that isn't a Raspberry Pi the plugin serves up to 4 viewers from the main stream at the size they ask for (up to 1920x1080
+on the GPU, 1280x720 with libx264), with the frames stamped evenly at 25 fps. With *Video processing* on Automatic it encodes on the
+GPU (VAAPI, Intel Quick Sync) when all of these hold: there is a render node (`/dev/dri/renderD128`), an ffmpeg with `h264_vaapi` and
+`libx264` can be found, and a real one-second test encode on the GPU works. Otherwise it uses libx264. The log tells you which:
+`Video: transcoding on the GPU (h264_vaapi, /dev/dri/renderD128) with /usr/bin/ffmpeg`. If a GPU encode ever fails to produce video,
+that stream continues with libx264.
+
+The ffmpeg bundled with Homebridge has no VAAPI, so a system ffmpeg is needed; the plugin looks for `ffmpeg` on the PATH, then
+`/usr/bin/ffmpeg` and `/usr/local/bin/ffmpeg` (or set *Custom ffmpeg path*, which is used as is). Typical setup:
+
+- **Bare metal / VM:** `sudo apt install ffmpeg intel-media-va-driver-non-free vainfo` (on Debian/Ubuntu the driver is in `non-free`/`multiverse`) and make sure the Homebridge user can read `/dev/dri/renderD128` (group `render`). Check with `vainfo`.
+- **Docker:** pass `/dev/dri` into the container (`devices: ["/dev/dri:/dev/dri"]`; add the `render` group unless the container runs as root, as the official Homebridge image does) and build a small image on top of the official one, for example
+  ```dockerfile
+  FROM homebridge/homebridge:2026-09-25
+  RUN apt-get update && apt-get install -y --no-install-recommends ffmpeg intel-media-va-driver-non-free vainfo libva-drm2 \
+   && rm -rf /var/lib/apt/lists/*
+  ENV LIBVA_DRIVER_NAME=iHD LIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri
+  ```
+  The image keeps its own static ffmpeg in `/usr/local/bin`; the distro one in `/usr/bin/ffmpeg` is the one the plugin picks.
+
+Measured on a Core i5-9500T (UHD 630) with a 4-channel DVR (960x1080 main streams, ~2 Mbit/s each), replaying the DVR's real stream:
+one 1080p stream uses about 30% of a core on the GPU path, four use about 115%; libx264 at 720p uses 60-80% of a core per stream
+(four: about 240%) and about 115% at 1080p. Start time (first output frame) is 50-100 ms on both. The GPU encoder needs roughly twice the
+bitrate of libx264 for the same sharpness, which is why the minimum bitrates are higher on the GPU path (5000 kbps at 1080p).
+Four main streams at once were delivered by the DVR at full frame rate (about 9 Mbit/s in total).
 
 ## How it works
 

package/config.schema.json

@@ -72,6 +72,7 @@
         "oneOf": [
           { "title": "Automatic (recommended)", "enum": ["auto"] },
           { "title": "Raspberry Pi hardware encoder", "enum": ["h264_v4l2m2m"] },
+          { "title": "Intel/AMD GPU encoder (VAAPI)", "enum": ["h264_vaapi"] },
           { "title": "Software encoder (libx264)", "enum": ["libx264"] },
           { "title": "No transcoding (lowest CPU, may look stretched)", "enum": ["copy"] }
         ]

package/lib/camera.js

@@ -6,6 +6,8 @@ const { RtspClient } = require('./rtsp');
 const { HikDecryptor } = require('./hikcrypt');
 const { FlvWriter } = require('./flv');
 const { run, spawn, AnnexBSplitter } = require('./ffmpeg');
+const fs = require('fs');
+const os = require('os');
 
 const START_CODE = Buffer.from([0, 0, 0, 1]);
 const PROFILES = ['baseline', 'main', 'high'];
@@ -20,6 +22,12 @@ const PREPARE_TTL = 10000; // a prepared-but-not-started session counts towards
 const MAIN_MAX_VIEWERS = 2; // up to this many concurrent viewers get the main stream
 const SMALL = { width: 640, height: 360, bitrate: 800 }; // light path: sub stream scaled up, hardware encoded
 const MAX_HW_SESSIONS = 4; // hardware encodes at once; further viewers get the sub stream passed through
+// A PC or server (not a Pi: no V4L2 M2M encoder node, 4+ cores) has CPU to spare for software encoding.
+const FAST_HOST = os.cpus().length >= 4 && !fs.existsSync('/dev/video11');
+const GPU_MAIN_MAX_VIEWERS = 4; // PC/server: up to this many concurrent viewers get the main stream (the DVR delivered 4 main streams at full frame rate)
+const GPU_FAIL_LIMIT = 3; // consecutive GPU-encode failures (with no GPU stream working) before the GPU is left alone for HW_RETRY
+const SW_FAST_MAX = [1280, 720]; // libx264 on a PC/server: biggest picture (the DVR's 960x1080 main stream has no more detail; 1080p x264 costs ~1.6 cores a stream)
+const GPU_MAX = [1920, 1080]; // GPU encode: whatever the viewer asks for, up to this
 const MAX_SW_SESSIONS = 2; // libx264 encodes at once while the hardware encoder is marked broken or one hardware encode failed
 // Hardware DECODE (-c:v h264_v4l2m2m before -i) was measured on the Pi 3 A+ and is deliberately not used: with the DVR's FLV pipe
 // input it was slower to start (2-7 s vs 1.5 s), used 2.5-3.3 cores instead of ~1 (ffmpeg copies every frame out of the codec's
@@ -28,7 +36,7 @@ const MAX_SW_SESSIONS = 2; // libx264 encodes at once while the hardware encoder
 
 /** Per-platform streaming state shared by all cameras (kept on the platform object). */
 function streamState(platform) {
-  if (!platform.streamState) platform.streamState = { active: new Set(), prepared: new Map(), hwBrokenUntil: 0 };
+  if (!platform.streamState) platform.streamState = { active: new Set(), prepared: new Map(), hwBrokenUntil: 0, gpuBrokenUntil: 0, gpuFails: 0 };
   return platform.streamState;
 }
 
@@ -198,7 +206,21 @@ class HikCamera {
     let cap = null; // [maxWidth, maxHeight, maxBitrate] of the output
     let why = '';
     const count = (m) => [...st.active].filter((x) => x.mode === m).length;
-    if (mode === 'h264_v4l2m2m' && p.encoderAuto) {
+    if (mode === 'h264_vaapi') {
+      // PC/server with a GPU encoder: full-size main streams for several viewers, the GPU does the work.
+      if (now < st.gpuBrokenUntil) {
+        mode = 'libx264';
+        if (viewers > GPU_MAIN_MAX_VIEWERS) { sub = true; cap = [SMALL.width, SMALL.height, SMALL.bitrate]; } else cap = [SW_FAST_MAX[0], SW_FAST_MAX[1], Infinity];
+        why = 'GPU encoder marked broken, libx264';
+      } else if (viewers <= GPU_MAIN_MAX_VIEWERS) {
+        cap = [GPU_MAX[0], GPU_MAX[1], Infinity];
+        why = `${viewers} viewer${viewers > 1 ? 's' : ''}, main stream on the GPU`;
+      } else {
+        sub = true;
+        cap = [1280, 720, Infinity];
+        why = `${viewers} viewers, sub stream on the GPU`;
+      }
+    } else if (mode === 'h264_v4l2m2m' && p.encoderAuto) {
       const hwOk = now >= st.hwBrokenUntil;
       if (!hwOk) {
         sub = true;
@@ -221,6 +243,16 @@ class HikCamera {
           why = `${viewers} viewers, sub stream passed through`;
         }
       }
+    } else if (mode === 'libx264' && p.encoderAuto && FAST_HOST) {
+      // PC/server without a (working) GPU encoder: CPU to spare, so main streams for several viewers at up to 720p.
+      if (viewers <= GPU_MAIN_MAX_VIEWERS) {
+        cap = [SW_FAST_MAX[0], SW_FAST_MAX[1], Infinity];
+        why = `${viewers} viewer${viewers > 1 ? 's' : ''}, main stream`;
+      } else {
+        sub = true;
+        cap = [SMALL.width, SMALL.height, SMALL.bitrate];
+        why = `${viewers} viewers, light sub-stream path`;
+      }
     } else if (mode === 'libx264' && p.encoderAuto && viewers > MAIN_MAX_VIEWERS) {
       // No hardware encoder at all (e.g. a Mac or a PC): keep CPU use bounded the same way.
       sub = true;
@@ -250,8 +282,15 @@ class HikCamera {
     let outH = plan.height;
     const fps = Math.min(video.fps, 25);
     // iOS often asks for ~300 kbps even on Wi-Fi, which looks poor; apply a resolution-based floor.
-    const floor = p.minBitrate !== undefined ? p.minBitrate : outW >= 1280 ? 1200 : outW >= 640 ? 600 : 300;
-    const bitrate = Math.min(Math.max(video.max_bit_rate, floor, 100), Math.max(plan.maxBitrate, floor));
+    // PC/server (GPU or fast CPU): sensible floors by picture size so a larger view is not starved; the Pi keeps the old ones.
+    // The GPU encoder needs ~1.5x the bitrate of libx264 veryfast for the same sharpness (measured SSIM).
+    let floor;
+    if (p.minBitrate !== undefined) floor = p.minBitrate;
+    else if (mode === 'h264_vaapi') floor = outW >= 1600 ? 5000 : outW >= 1280 ? 3000 : outW >= 640 ? 1000 : 400;
+    else if (FAST_HOST && mode === 'libx264') floor = outW >= 1280 ? 2000 : outW >= 900 ? 1400 : outW >= 640 ? 800 : 400;
+    else floor = outW >= 1280 ? 1200 : outW >= 640 ? 600 : 300;
+    let bitrate = Math.min(Math.max(video.max_bit_rate, floor, 100), Math.max(plan.maxBitrate, floor));
+    const levelStr = () => (outW > 1280 ? '4.0' : LEVELS[video.level] || '3.1'); // 1080p is only legal at level 4.0
     const log = this.log;
     const tag = `[${this.name}]`;
 
@@ -280,9 +319,74 @@ class HikCamera {
       if (mode === 'copy') {
         // DVR main streams are often anamorphic (e.g. 960x1080 "1080P Lite"); tell the player the display aspect is 16:9.
         first = this.spawn(session, [...input, '-c:v', 'copy', '-bsf:v', `h264_metadata=sample_aspect_ratio=${useSub ? '16/11' : '2/1'}`, ...srtpOut]);
+      } else if (mode === 'h264_vaapi') {
+        // GPU path: software decode (a few % of a core), GPU scale and GPU encode: ~30% of a core per 1080p stream versus 60-80% for libx264 720p.
+        // GPU decoding (-hwaccel vaapi) was measured too: ~10% per stream, same start time, but visibly blockier output (SSIM 0.894 vs 0.918 at 1080p/4 Mbit/s).
+        // Same two-stage timing model as libx264 above: constant 25 fps out of the encoder, copy-only sender stamps frames evenly.
+        // VAAPI encodes put SPS/PPS before every IDR themselves (checked), so no re-insertion is needed.
+        const device = (p.vaapi && p.vaapi.device) || '/dev/dri/renderD128';
+        const sender = this.spawn(session, [...logLevel, '-fflags', '+nobuffer', '-probesize', '32', '-analyzeduration', '0', '-max_probe_packets', '1',
+          '-f', 'h264', '-framerate', String(fps), '-i', 'pipe:0', '-c:v', 'copy', '-copyinkf', ...srtpOut]);
+        const vaProfile = ['constrained_baseline', 'main', 'high'][video.profile] || 'main';
+        const vaLevel = levelStr().replace('.', '');
+        first = this.spawn(session, [...input, '-vaapi_device', device, '-vf', `format=nv12,hwupload,scale_vaapi=w=${outW}:h=${outH}:format=nv12`, '-r', String(fps), '-c:v', 'h264_vaapi',
+          '-profile:v', vaProfile, '-level', vaLevel, '-bf', '0', '-g', String(fps * 2),
+          '-b:v', `${bitrate}k`, '-maxrate', `${bitrate}k`, '-bufsize', `${bitrate * 2}k`, '-f', 'h264', 'pipe:1']);
+        first.stdout.on('data', (chunk) => {
+          write(sender, chunk);
+          clearTimeout(session.hwTimer);
+          session.hwFallback = null;
+          if (!session.hwOutput) st.gpuFails = 0;
+          session.hwOutput = true;
+        });
+        // No output in HW_TIMEOUT, or ffmpeg exited first: this session falls back to libx264 (smaller picture, lower bitrate).
+        // Only repeated failures with no GPU stream working make the GPU off limits for everyone, and then only for HW_RETRY.
+        session.hwFirst = first;
+        session.hwFallback = (why) => {
+          session.hwFallback = null;
+          clearTimeout(session.hwTimer);
+          if (session.stopped) return;
+          const othersWorking = [...st.active].some((x) => x !== session && x.mode === 'h264_vaapi' && x.hwOutput);
+          if (!othersWorking) st.gpuFails++;
+          const broken = !othersWorking && st.gpuFails >= GPU_FAIL_LIMIT;
+          if (broken) st.gpuBrokenUntil = Date.now() + HW_RETRY;
+          log.warn(`${tag} GPU encoder ${why}${session.lastErr ? ` (${session.lastErr.split('\n').pop().slice(0, 160)})` : ''}; this stream switches to libx264${broken ? ` and the GPU is not used for ${HW_RETRY / 60000} min` : ''}`);
+          for (const proc of session.procs.splice(0)) {
+            proc.replaced = true;
+            proc.kill('SIGTERM');
+            setTimeout(() => proc.exitCode === null && proc.kill('SIGKILL'), 5000).unref();
+          }
+          started = false;
+          keyRequested = false;
+          requestKeyFrame();
+          session.mode = 'libx264';
+          session.hwOutput = false;
+          if (outW > SW_FAST_MAX[0]) {
+            outH = Math.round((outH * SW_FAST_MAX[0]) / outW / 2) * 2;
+            outW = SW_FAST_MAX[0];
+            scale = `scale=${outW}:${outH}:flags=fast_bilinear,format=yuv420p`;
+          }
+          bitrate = Math.min(bitrate, 2500);
+          launch('libx264');
+        };
+        session.armHw = () => {
+          session.hwTimer = setTimeout(() => session.hwFallback && session.hwFallback(`produced no video in ${HW_TIMEOUT / 1000}s`), HW_TIMEOUT);
+        };
+      } else if (mode === 'libx264' && FAST_HOST) {
+        // PC or server: the same two-stage path the Pi's hardware encoder uses, with libx264 (a better preset; CPU to spare).
+        // The encoder outputs constant 25 fps and the copy-only sender stamps frames evenly by count, which smooths out the
+        // DVR's uneven frame delivery (it sends ~20 fps with irregular gaps). Sending the encoder's timestamps directly
+        // (single process) passes that unevenness to the viewer as judder. repeat-headers puts SPS/PPS before every IDR.
+        const sender = this.spawn(session, [...logLevel, '-fflags', '+nobuffer', '-probesize', '32', '-analyzeduration', '0', '-max_probe_packets', '1',
+          '-f', 'h264', '-framerate', String(fps), '-i', 'pipe:0', '-c:v', 'copy', '-copyinkf', ...srtpOut]);
+        first = this.spawn(session, [...input, '-vf', scale, '-r', String(fps), '-c:v', 'libx264', '-preset', 'veryfast', '-tune', 'zerolatency',
+          '-profile:v', PROFILES[video.profile] || 'main', '-level:v', levelStr(), '-bf', '0',
+          '-g', String(fps * 2), '-b:v', `${bitrate}k`, '-maxrate', `${bitrate}k`, '-bufsize', `${bitrate * 2}k`,
+          '-x264-params', 'repeat-headers=1', '-f', 'h264', 'pipe:1']);
+        first.stdout.on('data', (chunk) => write(sender, chunk));
       } else if (mode === 'libx264') {
         first = this.spawn(session, [...input, '-vf', scale, '-c:v', 'libx264', '-preset', 'ultrafast', '-tune', 'zerolatency',
-          '-profile:v', PROFILES[video.profile] || 'main', '-level:v', LEVELS[video.level] || '3.1', '-bf', '0',
+          '-profile:v', PROFILES[video.profile] || 'main', '-level:v', levelStr(), '-bf', '0',
           '-r', String(fps), '-g', String(fps * 2), '-b:v', `${bitrate}k`, '-maxrate', `${bitrate}k`, '-bufsize', `${bitrate * 2}k`,
           ...srtpOut]);
       } else {
@@ -421,16 +525,19 @@ class HikCamera {
       callback(e);
     });
 
-    // Stop if the iPhone stops sending RTCP (app closed, network gone).
-    const timeoutMs = Math.max(video.rtcp_interval * 10, 30) * 1000;
+    // Stop if the viewer stops sending RTCP receiver reports (app closed, tile abandoned, network gone) so HomeKit can start a fresh
+    // session. A live viewer reports every rtcp_interval seconds (usually 0.5-5), so 15 s of silence (at most 30) means it has gone.
+    // (This used to be rtcp_interval x 10, at least 30 s, which left an abandoned Apple TV tile streaming for a minute or more.)
+    const timeoutMs = Math.min(Math.max((Number(video.rtcp_interval) || 1) * 5, 15), 30) * 1000;
+    let reports = 0;
     const kick = () => {
       clearTimeout(session.timer);
       session.timer = setTimeout(() => {
-        log.info(`${tag} No RTCP from viewer for ${timeoutMs / 1000}s, stopping stream`);
+        log.info(`${tag} No RTCP from viewer for ${timeoutMs / 1000}s (${reports} reports received), stopping stream`);
         this.forceStop(sessionID);
       }, timeoutMs);
     };
-    info.socket.on('message', kick);
+    info.socket.on('message', () => { reports++; kick(); });
     kick();
   }
 

package/lib/ffmpeg.js

@@ -31,6 +31,63 @@ function run(ffmpeg, args, { input, timeout = 15000 } = {}) {
   });
 }
 
+const VAAPI_CANDIDATES = ['ffmpeg', '/usr/bin/ffmpeg', '/usr/local/bin/ffmpeg'];
+
+function isPi() {
+  return fs.existsSync('/dev/video11'); // the Pi's V4L2 M2M encoder node
+}
+
+/** The first DRM render node (normally /dev/dri/renderD128), or null when there is no usable GPU. */
+function findRenderNode() {
+  try {
+    const nodes = fs.readdirSync('/dev/dri').filter((n) => /^renderD\d+$/.test(n)).sort();
+    return nodes.length ? `/dev/dri/${nodes[0]}` : null;
+  } catch (e) {
+    return null;
+  }
+}
+
+function listEncoders(ffmpeg) {
+  return new Promise((resolve) => {
+    execFile(ffmpeg, ['-hide_banner', '-encoders'], { timeout: 10000 }, (err, stdout) => resolve(err ? '' : stdout));
+  });
+}
+
+/** Real 1-second GPU encode, exactly the way a stream uses it (software frames uploaded to the GPU). */
+async function testVaapi(ffmpeg, device) {
+  await run(ffmpeg, ['-hide_banner', '-loglevel', 'error', '-init_hw_device', `vaapi=va:${device}`, '-filter_hw_device', 'va',
+    '-f', 'lavfi', '-i', 'testsrc=size=640x360:rate=25', '-t', '1', '-vf', 'format=nv12,hwupload', '-c:v', 'h264_vaapi',
+    '-b:v', '500k', '-f', 'null', '-']);
+}
+
+/**
+ * Looks for an ffmpeg that can encode H.264 on the Intel/AMD GPU (VAAPI) and proves it with a real test encode.
+ * Never on a Raspberry Pi. When the user set videoProcessor only that ffmpeg is tried; otherwise the bundled ffmpeg
+ * (which has no VAAPI) is skipped in favour of a system ffmpeg that has it. The ffmpeg must also have libx264 (the fallback).
+ * Resolves to { ffmpeg, device } or null.
+ */
+async function findVaapi(configured, log) {
+  if (isPi()) return null;
+  const device = findRenderNode();
+  if (!device) return null;
+  const candidates = configured ? [configured] : VAAPI_CANDIDATES.filter((c, i) => !c.startsWith('/') || fs.existsSync(c) || i === 0);
+  for (const ffmpeg of candidates) {
+    const encoders = await listEncoders(ffmpeg);
+    if (!/h264_vaapi/.test(encoders)) continue;
+    if (!/libx264/.test(encoders)) {
+      log.debug(`${ffmpeg} has h264_vaapi but no libx264 (needed as the fallback), skipping it`);
+      continue;
+    }
+    try {
+      await testVaapi(ffmpeg, device);
+      return { ffmpeg, device };
+    } catch (e) {
+      log.debug(`GPU encode test with ${ffmpeg} on ${device} failed: ${e.message}`);
+    }
+  }
+  return null;
+}
+
 /** Pick the best working H.264 encoder: Raspberry Pi hardware encoder if it actually works, else libx264. */
 async function detectEncoder(ffmpeg, log) {
   const encoders = await new Promise((resolve) => {
@@ -81,4 +138,4 @@ function findStart(buf, from) {
   return { begin, end: i + 3 };
 }
 
-module.exports = { resolveFfmpeg, run, detectEncoder, AnnexBSplitter, spawn };
+module.exports = { resolveFfmpeg, run, detectEncoder, findVaapi, isPi, AnnexBSplitter, spawn };

package/lib/platform.js

@@ -2,7 +2,7 @@
 
 const { Isapi } = require('./isapi');
 const { HikCamera } = require('./camera');
-const { resolveFfmpeg, detectEncoder } = require('./ffmpeg');
+const { resolveFfmpeg, detectEncoder, findVaapi } = require('./ffmpeg');
 const { AlertStream } = require('./events');
 const { WebConsole } = require('./webconsole');
 
@@ -95,9 +95,18 @@ class HikvisionPlatform {
       }
 
       const mode = this.config.encoder || 'auto';
-      this.encoder = mode === 'auto' ? await detectEncoder(this.ffmpeg, this.log) : mode;
+      this.vaapi = null;
+      if (mode === 'auto' || mode === 'h264_vaapi') {
+        // PC/server with an Intel/AMD GPU: encode there when an ffmpeg with VAAPI exists and a real test encode works.
+        this.vaapi = await findVaapi(this.config.videoProcessor, this.log);
+        if (this.vaapi) this.ffmpeg = this.vaapi.ffmpeg;
+        else if (mode === 'h264_vaapi') this.log.warn('Encoder "h264_vaapi" was chosen but no working GPU encode was found (needs /dev/dri and an ffmpeg with VAAPI); using libx264');
+      }
+      if (this.vaapi) this.encoder = 'h264_vaapi';
+      else if (mode === 'auto' || mode === 'h264_vaapi') this.encoder = await detectEncoder(this.ffmpeg, this.log);
+      else this.encoder = mode;
       this.encoderAuto = mode === 'auto';
-      this.log.info(`Video: ${this.encoder === 'copy' ? 'passing DVR stream through (no transcoding)' : `transcoding with ${this.encoder}`}`);
+      this.log.info(`Video: ${this.encoder === 'copy' ? 'passing DVR stream through (no transcoding)' : this.encoder === 'h264_vaapi' ? `transcoding on the GPU (h264_vaapi, ${this.vaapi.device}) with ${this.ffmpeg}` : `transcoding with ${this.encoder} (${this.ffmpeg})`}`);
 
       const overrides = new Map((this.config.cameras || []).filter((x) => x && x.channel).map((x) => [Number(x.channel), x]));
       channels = channels

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "homebridge-hikvision-dvr",
   "displayName": "Hikvision DVR / NVR Cameras",
-  "version": "1.2.2",
+  "version": "1.4.0",
   "description": "Hikvision, HiLook and other Hik-based DVR/NVR cameras in HomeKit, with automatic camera discovery and support for encrypted (Hik-Connect / HiLook) streams.",
   "main": "index.js",
   "license": "MIT",