Support Apple's New HKSV Open Source Compatibility Guide (WebRTC live view + HEVC/H.264 + Opus)

[SemoTech]

Requesting tracking and eventual implementation of Apple’s new HomeKit Secure Video Open Source Compatibility Guide (Developer Preview, June 2026), which defines a new WebRTC-based live view path with mandatory HEVC alongside H.264 and Opus audio.

This would allow Scrypted-bridged cameras (especially newer H.265-only or H.265-preferred cameras like 16MP UniFi Protect G6 models) to work with HomeKit and HKSV without forced H.264 transcoding, while keeping the existing legacy HomeKit bridge path until the new stack is stable.

I use Scrypted in Docker to expose UniFi Protect cameras to HomeKit with HomeKit Secure Video (HKSV) cloud recording.

After adding a UniFi Protect G6 180 camera, Scrypted logs:

G6 180 Driveway video codec must be h264 but is h265.
This stream may fail. Read the instructions in the HomeKit Plugin to properly configure your camera codec.

The G6 180 is sending H.265 (HEVC) because UniFi Protect Enhanced encoding uses H.265 for efficiency at high resolution (16MP panoramic stream). Scrypted’s current HomeKit plugin targets the legacy HomeKit camera protocol, which expects H.264 for live view and the existing HKSV pipeline.

Workaround today: Set the camera to Standard (H.264) in UniFi Protect (Settings → Video/Recording → Encoding → Standard). This works but:

• Uses significantly more NVR storage and bandwidth vs Enhanced/H.265
• Feels like a step backward on newer G6 hardware designed around HEVC
• Does not scale well as more Protect cameras default to Enhanced encoding

Alternative workaround in use now: Enable transcoding in Scrypted (HomeKit debug transcoding + Rebroadcast decode/encode). This adds CPU/GPU load, latency, and potential quality loss — especially painful for high-resolution streams like the G6 180.

I understand this is a large effort, not a small codec change:

• Home hub support (Apple TV / HomePod) must also adopt the new path — Scrypted alone cannot enable it
• Scrypted already has some WebRTC and H.265 building blocks, but the HomeKit plugin would need substantial new work

I am not expecting a quick fix; this is just a tracking/feature request for visibility and prioritization

Thank you for your consideration.

Related prior discussions (not duplicates)

I searched existing Scrypted threads before opening this. Several cover H.265/HEVC vs HomeKit, but none address Apple’s new HomeKit Secure Video Open Source Compatibility Guide (Developer Preview, June 2026). This is not a duplicate—it asks for the new protocol stack (WebRTC over HAP, mandatory HEVC + H.264, Opus), not another legacy-bridge workaround.

• #1507 — Protect H.264 stream while recording H.265; closed no. Different: Protect-plugin split-stream, not Apple’s new HKSV spec.
• #337 — HEVC transcoding setup. Different: workaround guide, not native HEVC via new Apple path.
• #1690 — Rebroadcast / codec must be h264 but is h265. Different: bug on current pipeline, not new spec implementation.
• go2rtc #2297 — Same Apple spec tracked elsewhere. Related ecosystem context; Scrypted would need its own HomeKit plugin work.

Apple spec: https://developer.apple.com/download/files/HomeKit-Secure-Video-Open-Source-Compatibility-Guide.pdf

[arcticfoxwp]

I have iOS 27 and MacOS 27 and set all my Unifi cameras to Encoding > Enhanced and while I don't use HKSV, they all steam in Apple Home perfectly.

But I agree, there should be an update so Scrypted can better handle this.

[SemoTech]

@arcticfoxwp you are correct that the enhanced streams (H.265) reach Apple Home (HKSV) through Scrypted, but to get there Scrypted must use ffmpeg and transcode from H.265 to H.264, and that takes CPU and RAM plus slows things down (see my detailed notes above). Apple has acknowledged their current implementation of HKSV which expects only H.264 is antiquated, so they defined a new process to receive H.265 "natively". That is the reason for my request for alignment with the new Apple standards in development.

[arcticfoxwp]

@arcticfoxwp you are correct that the enhanced streams (H.265) reach Apple Home (HKSV) through Scrypted, but to get there Scrypted must use ffmpeg and transcode from H.265 to H.264, and that takes CPU and RAM plus slows things down (see my detailed notes above). Apple has acknowledged their current implementation of HKSV which expects only H.264 is antiquated, so they defined a new process to receive H.265 "natively". That is the reason for my request for alignment with the new Apple standards in development.

Ok I understand now, thank you. You should turn this into an issue - it will likely be addressed sooner if so.

H.265 support seems like it would be an obvious update.

[SemoTech]

Most welcome @arcticfoxwp but I followed the posting process laid out by @koush for bringing such concerns into the light.

Specifically since Apple has not yet fully implemented their changes this would not be a feature Scrypted could just implement outright, and must wait until such time as Apple has finalized their part and design.

This is meant to open a parallel track bring awareness and cast light on the possibilities of the near future.

[Chrisalvir1]

Muy mal, porque si la cámara es 2k o 4k pero no tiene audio Opus no funciona aunque la cámara sea compatible con H265, Scrypted aún no actualiza esos Codec y solución y no está actualizado a los nuevos requerimientos y complementos webrtc y más.

Yo intenté poniendo mi cámara en H265 y exportarlo crudo ya que al fin HomeKit puede recibir cámaras sin transcodificar pero el audio muy mal y los bit es otro problema.

[SemoTech]

@Chrisalvir1 This is exactly why I opened this discussion, to provide reference, feedback and a path for @koush to improve the awesome tool that is Scrypted.