add dependencies to allow for HandBrake QSV support

[DZaremba14600]

This is my first git/github submission ever.

I apologize if I miss any protocols, my intent is not to irritate.

I tried to comment appropriately, if its too much/not enough just let me know.

If the project maintainers would prefer other protocols or policies be followed, just let me know.

An earlier version of these changes was used by me to process close to 60 BluRay movies and they processed very quickly (less than 2 hours per disk average over parts of 4 days (on 2 machines) and without error. I tweaked the code, cleaned up the comments, and ran several Docker Image builds to make sure there weren't any errors in the builds. I had to get up on how git worked. So here's my submission.

Added support for Handbrake to support use of QSV.

The only file changed is scripts/install_mkv_hb_deps.sh

Added code to add repository for Intel graphics GPU support. This will allow latest packages to be pulled.
Added an update/upgrade step to get latest packages index list and upgrade all existing packages.
Added step to install packages for OneVPL Compute Runtime, Media, and Mesa packages, misc utils, for QSV use in HandBrake.
Added step to install specific QSV packages as called for by HandBrake's website.
Added step to install new HandBrake version 1.9 dependencies. These seem identical to the previously included HandBrake dependencies installed at line 21. Identical packages will be upgrade/skipped; any different packages will be installed (this being the case, line 21 could actually be removed/merged with line 78. I decided to code this way to ensure everything is shown to be working through widespread use, and in the next update these redundant lines could be merged or line 21 removed/replaced.
Added step to include GTK library packages (used in HandBrake GUI). Even though this is CLI only, there is functionality in place to allow easy use of custom PRESETS on the handbrake args line using .json files exported from the GUI version. During testing there seemed to be issues unless these were included. They can be removed if further use show them to be unnecessary.

Testing shows this builds and the Docker Container comes up and runs. Obviously I didn't test every function of ARM, but I did run ARM and processed the BluRay of 'Unforgiven', using latest Handbrake 1.9, a custom preset that utilizes QSV, and the job completed without errors.

Thank you.

[microtechno9000]

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

[DZaremba14600]

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: ***@***.*** ***@***.***> >

[microtechno9000]

Pulled this PR and ran a quick test, the new image takes a little longer to build and is ~700MB larger, which is ok, noting users are ripping DVD and Bluray images 10x as large.

Initial test on my non QSV machine, the rip appeared to take over a day for a DVD, which would typically take 4-5 hours (not the fastest machine). Need to re-run the test again because they were different discs.
However, if enabling QSV on a non-supported system increases the ripping time 2-3 times that is definitely not ideal.

$ docker image ls
REPOSITORY                                 TAG           IMAGE ID       CREATED          SIZE
automaticrippingmachine/arm-dependencies   1.2.2         2ec395155423   2 days ago       3.3GB
automaticrippingmachine/arm-dependencies   1.2.1         5172bfb8ec35   2 days ago       2.63GB

[DZaremba14600]

I just saw this. Let me shoot over a quick response – I need to get going. Let me review this when I get home. Image size looks the same as what I had. 3.3 gig. The only thing this should affect is encoding. Ripping is via MakeMKV and these GPU packages should not affect that. Odd. I did not test on DVD’s. I have 2 I need to rip. Let me test. I did not see any noticeable increase in ripping a BluRay disk. Let me run some testing with a known disk, timing tests, and see what I get. The Handbrake processing should be MUCH faster using QSV. Again let me benchmark and get you the hardware I’m using. It could be the higher memory footprint affected ripping time. Let me do some benchmarking and report back. Let me see if I can see where QSV would affect ripping. That doesn’t make any sense. MakeMKV rips, Handbrake encodes, and QSV is related to encoding/Handbrake, not MakeMKV. I’ll do some testing and report back. I’ll try a suite of testing on DVD, Bluray, using just stand alone MakeMKV and Handbrake and then the two of those in this Docker container, both with QSV and without. Might take me some time. Thanks for your time with this. Thanks for this info. I’ll report back as soon as I can. From: Mtech ***@***.***> Sent: Saturday, December 28, 2024 6:52 AM 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) Pulled this PR and ran a quick test, the new image takes a little longer to build and is ~600MB larger, which is ok, noting users are ripping DVD and Bluray images 10x as large. Initial test on my non QSV machine, the rip appeared to take over a day for a DVD, which would typically take 4-5 hours (not the fastest machine). Need to re-run the test again because they were different discs. However, if enabling QSV on a non-supported system increases the ripping time 2-3 times that is definitely not ideal. $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE automaticrippingmachine/arm-dependencies 1.2.2 2ec395155423 2 days ago 3.3GB automaticrippingmachine/arm-dependencies 1.2.1 5172bfb8ec35 2 days ago 2.63GB — Reply to this email directly, view it on GitHub <#356 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4MFQVOH4SNVU5MSQG5IZJD2H2GHRAVCNFSM6AAAAABTT45AXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGMYDKNZZGM> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/A4MFQVON25HXAGKKJDILQMT2H2GHRA5CNFSM6AAAAABTT45AXCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUY3AZYC.gif> Message ID: ***@***.*** ***@***.***> >