First of all, don’t forget that the GPU needs to be passed into the container using a device= directive either on the command line when starting the container or in the Docker Compose file. I’ve attached the Docker Compose I use for reference. In the device block, the /dev/dri/render and the /dev/dri/card entries point to a specific card (the first GPU). The /dev/dri entry alone points to the folder containing references to ALL the GPUS and it seems that entry pick up both my cards – renderD128/card0 and renderD129/card1 respectively. This works for me and was gleaned from a lot of research and google searches. Yours may vary. devices: - /dev/sr0:/dev/sr0 - /dev/sr1:/dev/sr1 - /dev/sr2:/dev/sr2 - /dev/sr3:/dev/sr3 - /dev/dri:/dev/dri - /dev/dri/renderD128:/dev/dri/renderD128 - /dev/dri/card0:/dev/dri/card0 Interesting situation. I hadn’t considered systems without QSV hardware. My only thought would be that the container currently doesn’t have QSV support and runs fine on systems that both do and do not have QSV support. It seems Handbrake coordinates all that using either the older Media-SDK or the newer OneVPL SDK. If it detects QSV hardware, it will check to see if QSV support packages are installed. If they are fine, it offers QSV enabled encoders as an option. If it does not detect QSV hardware OR if it detects hardware but it does not detect QSV support packages, QSV enabled encoders are not offered as an available option. This seems to be a coordination between Handbrake and the OneVPL support that handles all this. Basically, if there is no QSV hardware, Handbrake should work fine, just offering no QSV enabled encoders. But I hadn’t thought of that. So, your testing will be great. Thanks for those ideas. In addition, if this QSV all tests fine, the block of code I added for QSV support would also likely work for AMD and NVidia accelerated support, placing appropriate blocks of code there. I do not have that hardware available to test. I actually have 2 QSV enabled GPU’s in my system, the integrated GPU with the CPU and a discreet QSV enabled GPU card. Handbrake chooses the more capable GPU to use. No problems with that configuration. Good luck with the testing. This does work for me. I’m using QSV to re-process/re-encode a bunch of disks and I’m using QSV. I’m re-encoding at a much higher video quality and using QSV to cut the processing time down significantly. Basically, a standard Bluray movie can be pulled off the disk in about 40 minutes and encoded by Handbrake using H.265 at a 1080p SuperHQ setting and the encoding takes about 20 to 25 minutes for the entire disk, both movie and extras. About an hour for the whole thing. So, it’s working for me. If there’s anything that will help, let me know. I can give you logs from a processing run for a BluRay and you can see how Handbrake sees both QSV enabled GPUs and seems to choose the more capable to use. Anything you need, let me know. If this passes muster, let me know if you’d like me to update the docs/wiki to show exactly what’s required – support on the host, commandline/compose settings, what to pick in handbrake, etc. Maybe I can pass on useful info. Good luck and have a happy and safe holiday with friends and family. Thanks. From: Mtech ***@***.***> Sent: Friday, December 20, 2024 5:39 PM To: automatic-ripping-machine/arm-dependencies ***@***.***> Cc: DZaremba14600 ***@***.***>; Author ***@***.***> Subject: Re: [automatic-ripping-machine/arm-dependencies] add dependencies to allow for HandBrake QSV support (PR #356) Thanks for the first commit There are no specific rules setup for the ARM dependencies I will check this on my machine to check it doesn't break containers with no QSV cards. Wont get to this till after Christmas Thanks for helping the community — Reply to this email directly, view it on GitHub <#356 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4MFQVKGTOJ3HIVVY7AVUVL2GSMCBAVCNFSM6AAAAABTT45AXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXHA2DINJSGY> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/A4MFQVPM2ADJCE2DRQL2CXL2GSMCBA5CNFSM6AAAAABTT45AXCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUYOWOC4.gif> Message ID: ***@***.*** ***@***.***> >