Problem
HomeKit Secure Video passes negotiated recording constraints (resolution, frame rate, and bitrate) to the FMP4 session. The HomeKit plugin also declares H.264 as an already supported input codec.
When a camera already provides H.264, node-av therefore selects stream-copy/remux mode. In that mode the requested video constraints are encoder settings and cannot be applied, so an input such as 2560x1920 at a high bitrate is forwarded into HKSV fragments unchanged even when HomeKit negotiated 1920x1080 and a lower bitrate.
This can produce multi-megabyte fragments and sustained native allocation pressure in long-lived HKSV prebuffers. It is particularly visible with several permanent prebuffer streams, but it is also a correctness issue independently of memory usage because the negotiated limits are not enforced.
Expected behavior
There should be a safe per-camera way to force HKSV video transcoding so that the negotiated resolution, frame-rate, and bitrate limits are actually applied.
The setting should:
- default to disabled to preserve existing stream-copy behavior and avoid unexpectedly increasing CPU/GPU usage;
- apply only to HKSV recording/prebuffer sessions;
- restart the camera's recording prebuffer when changed;
- keep the existing per-camera HKSV hardware-acceleration setting effective.
Proposed fix
Add an advanced per-camera Force Video Transcoding for HKSV setting. When enabled, pass an empty supportedVideoCodecs list while retaining AAC in supportedAudioCodecs. The camera.ui FMP4 adapter consequently advertises only AAC to node-av, so an H.264 input is encoded to H.264 with the already supplied HomeKit video constraints while compatible audio can still be remuxed.
Related allocator-pressure investigation: seydx/node-av#328.
Problem
HomeKit Secure Video passes negotiated recording constraints (resolution, frame rate, and bitrate) to the FMP4 session. The HomeKit plugin also declares H.264 as an already supported input codec.
When a camera already provides H.264, node-av therefore selects stream-copy/remux mode. In that mode the requested video constraints are encoder settings and cannot be applied, so an input such as 2560x1920 at a high bitrate is forwarded into HKSV fragments unchanged even when HomeKit negotiated 1920x1080 and a lower bitrate.
This can produce multi-megabyte fragments and sustained native allocation pressure in long-lived HKSV prebuffers. It is particularly visible with several permanent prebuffer streams, but it is also a correctness issue independently of memory usage because the negotiated limits are not enforced.
Expected behavior
There should be a safe per-camera way to force HKSV video transcoding so that the negotiated resolution, frame-rate, and bitrate limits are actually applied.
The setting should:
Proposed fix
Add an advanced per-camera
Force Video Transcoding for HKSVsetting. When enabled, pass an emptysupportedVideoCodecslist while retaining AAC insupportedAudioCodecs. The camera.ui FMP4 adapter consequently advertises only AAC to node-av, so an H.264 input is encoded to H.264 with the already supplied HomeKit video constraints while compatible audio can still be remuxed.Related allocator-pressure investigation: seydx/node-av#328.