any plans for intel HW encoding

[letrain02]

i see there is an nvidia HW encoding container, and one for rasperrypi as well. any future plans for quicksync? if i knew what to do i'd add it in myself.

thanks

[mrlt8]

The bridge attempts to use copy whenever possible to avoid re-encoding the h264. However the bridge has to re-encode video for any rotation (e.g., doorbell) and that's where the HW encoding is used.

The base image uses ffmpeg from ffmpeg-for-homebridge which only has support for HW encoding on the pi.

If you want to try playing around with HW encoding, you could try the latest-hw images built with ffmpeg from FFmpeg-Builds which has support for more encoders.

I believe you'd then need to expose the HW encoders to the container in your docker-compose.yml:

devices:
- /dev/dri/renderD128:/dev/dri/renderD128
- /dev/dri/card0:/dev/dri/card0

You should then be able to pass a custom ffmpeg command for testing using:

- FFMPEG_CMD=ffmpeg -loglevel verbose -f h264 -hwaccel qsv -hwaccel_output_format qsv -i - -c:v h264_qsv -rtsp_transport tcp -f rtsp rtsp://0.0.0.0:8554/{cam_name}

[letrain02]

is --device=/dev/dri:/dev/dri in extra parameters enough? I am currently using UNRAID. its worked in both plex, and unmanic.

[mrlt8]

If it's working in the other containers, then that should be enough.

[letrain02]

h264 is working, curious about a variable for h265. ffmpeg offers hevc_qsv. does the variable need to be H264_ENC=hevc_qsv or do i change the variable to H265_ENC=hevc_qsv ?

i'm mainly looking at the recording feature.

[mrlt8]

The majority of the bridge is optimized for h264, so some changes may need to be made to allow for h265. In addition, switching to h265 could potentially break the previews in the WebUI as h265 doesn't seem to be supported in WebRTC.

May be able to do the conversion/save in MediaMTX which would run in addition to the main stream.