Intel Quick Sync Support #736
Comments
|
@mrlt8 I rewrote my docker - intel - qsv container. I know FFMpeg with qsv works, because this command works ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf hwdownload,format=nv12 -pix_fmt yuv420p output.yuv When I run this ffmpeg command Stream mapping: Any thoughts? |
Does this help |
[front-door] FFMPEG stopped |
|
fwiw @mrlt8 frigate's ffmpeg and docker lets me use intel qsv with no issue. My Docker image uses same ffmpeg If it helped, frigate seems to use these params |
|
do you need to add |
No dont think so, my test commands from the FFMPEG website didn't require it... Im thinking its something with this line https://github.com/blakeblackshear/frigate/blob/9e531b0b5bf34634dc6c44e7eca7e5eaf5a52a25/frigate/ffmpeg_presets.py#L113C6-L113C6 |
|
that's mostly a video filter..? Your previous reference shows frigate using |
Here is the command that works natively in my container... https://trac.ffmpeg.org/wiki/Hardware/QuickSync
Theres no need to pass a device... When I run intel_gpu_top the GPU gets activated |
|
The would something like this work? - FFMPEG_CMD=ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i - -c:v h264_qsv -b:v 4000k -vf 'format=nv12|vaapi,hwupload' -rtsp_transport tcp -f rtsp rtsp://0.0.0.0:8554/{cam_name}or - FFMPEG_CMD=ffmpeg -hwaccel qsv -c:v h264_qsv -i - -c:v h264_qsv -b:v 4000k -rtsp_transport tcp -f rtsp rtsp://0.0.0.0:8554/{cam_name} |
|
@mrlt8 So FFMPEG might support qsv ( intel gen 11+ ) or vaapi (sub intel 11).. but you still need the intel drivers in the docker image . Here is what my docker file looks like https://gist.github.com/mitchross/5dc213dc6d4165704f379be414044235 ... Its based on Frigate's docker file. So the errors I reported above are based on my docker image... You can build it yourself or I can give a docker hub image... If you take the docker file, you can shell into it. run 'intel_gpu_top' to get GPU activity. If you download a sample mp4, then run 'ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -vf hwdownload,format=nv12 -pix_fmt yuv420p output.yuv' you will see GPU monitor tool spike. This 'intel_gpu_top' in the container or on the host itself. |
|
Some of the ENVs were moved to an external file in v2.3.5. Would something like this work? |
Ill give this a try tonight... do you have a sample docker compose for me to try also? Just want to ensure our testing is 1:1 |
|
@mrlt8 Results Latest-hw Image ( 2.3.5 ) + "ffmpeg -hwaccel qsv -c:v h264_qsv -i - -c:v h264_qsv -b:v 4000k -rtsp_transport tcp -f rtsp rtsp://0.0.0.0:8554/{cam_name}" Results in the error below ( which I expect as the intel drivers are not present Now If I use the command "ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i - -c:v h264_qsv -b:v 4000k -vf 'format=nv12|vaapi,hwupload' -rtsp_transport tcp -f rtsp rtsp://0.0.0.0:8554/{cam_name}" I get Next I tried your new docker image, I had to hard code the URL for MTX, I think something is busted with the env vars? i was getting 404's on the curl for MTX. After I got that build I am seeing this |
|
There were some changes that moves the default ENVs. Can you try to build with v2.3.5 or the dockerfiles branch? |
Yea my last messages were built on the 2.3.5 branch, not my own... The last error in the my last post was based on the dockerfiles branch.. I see you made a commit so ill try again tonight! |
|
I believe you'll also need to set the ENV |
|
When I build/run the compose file I get |
|
hmm, I wonder if it's not reading the MTX_TAG from the .env file for some reason..? btw, the Dockerfile.qsv file should now be in the main branch: https://github.com/mrlt8/docker-wyze-bridge/blob/main/app/Dockerfile.qsv |
|
Prebuilt images with the intel drivers should be available on dockerhub or ghcr.io using the |
|
Running the prebuilt image pulled with :latest-qsv, got this error: App version shown in the log is 2.3.7 |
Docker compose needs the .env file at the same level as the docker-compose.yml file. This means you'd need to move it to root level or move compose to the app folder... Next the intel drives need to be part of the final image docker-wyze-bridge/app/Dockerfile.qsv Line 9 in 0bb52a9 When you are installing intel-media-driver it should be in the last FROM otherwise its dismissed |
|
@392media could you try the latest image? @mitchross I'm able to build with docker-compose using: build:
context: ./app
dockerfile: Dockerfile.qsvor |
got it... you still need to move the intel drives down to the last FROM RUN echo 'deb http://deb.debian.org/debian testing main non-free' >/etc/apt/sources.list.d/debian-testing.list |
|
I believe they should be in the final image:
|
|
@mitchross what's model of you Intel CPU? |
Intel 5095 |
* Start from index 1 for cruise_point/waypoint #835 * update_snapshot via MQTT * fix camera status always online #907 #920 * Additional MQTT entities #921 * QSV related changes * i965-va-drivers #736 * FIX power status #921 * Fix cruise_point type #921 Thanks @jhansche * return index from command payload #921 * Update docker-image.yml * Monitor and set preferred bitrate #929 * Default to `-` for cruise_point #921 * clear out stale entities #921 * changelog
Rotate Camera still doesn't work. These are my input params, ignore the format, they get passed this way to my k8s cluster, but they are docker env compatible. |
|
@mitchross |
|
This is the command that breaks rotation.. ( do note it rotates fine without these values ) I get these logs... (front-door) is the camera to troubleshoot |
|
What's the output of |
stated earlier/ extra context - I have zero issues with Frigate container . QSV works, GPU acceleration works, etc no VA info in the container On the nuc itself |
|
Added Testing would be appreciated. |
|
new |
|
root@wyze-bridge-b45bfb685-6vfrp:/app# vainfo |
|
should be available in the latest dev-qsv |
|
Ok now its there ..... ROTATE DOOR still does not work with
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.1 () |
|
@mitchross I see you have multiple cameras. Could you test if it works when serving only the doorbell? |
|
@mrlt8 It seems the code convert all letters to lower case for the FFMPEG_CMD variable? If so this might break something where a parameter needs capital letters. |
|
@392media FFMPEG_CMD should be case sensitive now |
* PTZ using cover #921 * set min max for rotate button? #921 * only show pan_tilt for pan_cam * Add extra intel packages #736 * Update Dockerfile.hwaccel * Revert "Update Dockerfile.hwaccel" This reverts commit d7de34c. * Update Dockerfile.qsv * Update Dockerfile.qsv * Update Dockerfile.qsv * Fix typo #736 * copy bins #736 * fix typing warnings * remove dot from version check * DEBUG_FFMPEG to FFMPEG_LOGLEVEL * case sensitive FFMPEG_CMD #736 * Add ffmpeg filter_complex config #919 * Adjust bitrate * Skip audio buffer check #388 * Revert "Skip audio buffer check #388" This reverts commit 79ace0c. * changelog
|
Anything I can do to help bump this? I've been running |
I've been running it for awhile as well and was hoping we would get the rotate video piece working so my doorbell video is normal again. other than rotate, it has worked flawlessly |
* audio latency #388 * Motion Events * Log number of cams from API #974 * Store and reuse s3 thumbnail from events #970 * better error handling * Increase MTX_WRITEQUEUESIZE #984 * MOTION_START for HA * limit login attempts * pass exceptions upstream * motion images for webhooks/ntfy in header * REST API motion endpoint * Additional audio codecs * keep stream alive if livestream enabled #985 * Catch RuntimeError #994 * assert bitrate value * refactor av_send_io_ctrl * Refactor API client and use battery from device_info * motion_ts endpoint * use .pipe instead of .wav for audio pipe * update frame size if not preferred_frame_size * Exclude battery cams from RTSP snapshots #970 * revert changes * buffer mtx event data #990 * Match all 11.x or newer firmware #975 * MOTION_WEBHOOKS * clean * revert changes * Media MTX changes * ffmpeg v6 * Use ffmpeg-for-homebridge in QSV build #736 * remove unneeded packages * don't return none * Adjust queue size and compression #388 * Adjust sleep, queue, and fifo for lag * Catch other HTTPErrors for events * Revert "Adjust sleep, queue, and fifo for lag" * Update ffmpeg.py * Update tutk.py * adjust thread_queue_size #388 * Add build date time * Update ffmpeg.py * Additional queue tweaks and fifo options #388 * Catch RequestException in motion events * Update MediaMTX version from v1.1.0 to v1.1.1 (#1007) (#1008) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: mrlt8 <mrlt8@users.noreply.github.com> * Fix ETag header for MediaMTX 1.1.1 * Don't use wallclock #388 * remove asetpts * audio #388 * Update ffmpeg.py * allow wallclock flag in FFMPEG_FLAGS #388 * changelog * Update .env
Can you share your env configs ? |
Sorry I missed your reply for so long. Running this on unraid so the format is a little weird but here's the env configs
|
converted it to markdown for easier reading and remove irrelevant columns.
@mitchross any ideas? |
|
Is there anything beyond pulling latest-qsv, and using environment variable H264_ENC=h264_qsv needed to get this working? I've done this and mapped /dev/dri:/dev/dri but it doesn't seem like it's using qsv. I don't see anything about it in logs and I don't see any activity using intel_gpu_top. I don't have any errors, it's working, but I don't think it's using hardware acceleration. |
i haven't worked on it in a while. gave up and bought nest cameras |
Hello -
I would like to know the commands to use Intel Quick Sync with this project
https://jellyfin.org/docs/general/administration/hardware-acceleration/#intel-quicksync
https://deploy-preview-4055--frigate-docs.netlify.app/configuration/hardware_acceleration
I previously opened up...
#548
The text was updated successfully, but these errors were encountered: