Videos: Improve FFmpeg parameters for Intel QSV hardware transcoding #2222
Comments
ffmpeg_photoprism-20220405135107.mp4 |
lastzero
changed the title
|
I think all that is required is to remove the following parameters |
This commit also removes PHOTOPRISM_FFMPEG_BUFFERS as it is only used/required by Video4Linux. 64 seems to be a good value, so we pass it statically as for the other encoders. Examples have been updated.
lastzero
added
please-test
|
Removed Thanks for your advice and becoming a sponsor! 👍 |
|
Note that this change also removes the |
|
Ran a test now and it's not good news :(
... and, indeed, when I try to play the file in the UI, the sidecar file is now obviously present and plays. So, I was extremely cocksure that I'd found the issue, but it seems I've been proven wrong, or at least come up against another issue. Both are run inside the docker container, but something is preventing the VAAPI device being created when invoked from PhotoPrism but not when invoked from bash, inside the container. I'll need to think this through and family calls so might return to it tonight and redo the steps above just to make sure I've not done something silly. As it stands, I've teetered over the limit of my docker + linux knowledge. Perhaps something is brought in when bashing into the container that doesn't exist outside this... |
|
Permission issues? Running the command as root in the terminal while PhotoPrism is running as non-root user? |
|
🤦♂️ Yes, it could be. I’m certainly root when logging into the container. Not sure what that implies for PhotoPrism if so. |
|
Trying to re-run the container with:
.. and unfortunately get the same result. But my plex container runs with a restricted user, non-root/admin, and employes ffmpeg transcoding just fine. Any ffmpeg experts around? |
|
Couple of issues/PRs in Jellyfin that could relate to this: ... it could be a Synology specific issue, although why it works when I bash into the shell and run the same command line is still beyond me. Will try to set permissions on the render devices (by bashing into the container, running chmod before making a video serve request on the UI), but it will have to be after work - lunch break is over :) |
|
Ok, it's probably a Synology issue and probably related to the jellyfin issues I posted in the comment above. I had forgotten that root and admin is not the same on a Synology. When I change the PhotoPrism container to run as UID=0 (root), the ffmpeg invocation using QSV works fine and indeed the video transcodes MUCH quicker. This is why the call succeeds when bashing into the container - one arrives as root when running So the answer is something along the lines of what jellyfin is doing in https://github.com/linuxserver/docker-jellyfin/pull/112/files. If you look at the comments in linuxserver/docker-jellyfin#26:
It's exactly the same issue as I've described. So: iterate over the drivers and ensure the current user has access to them. This is a solution specific to Synology - or at least all devices where the renderD128 doesn't have RW permissions by default. @lastzero up to you whether you want to add a specific fix for Synology like what Jellyfin is doing. Until then, Synology users who wish to transcode with QSV need to run as root. |
|
We can't make any more changes for the next release. However, I took the opportunity to refactor video transcoding along the way when implementing this today: There used to be an automatic fallback to the software encoder, which should now work again if hardware transcoding failed. Logging has been improved too. Happy indexing/testing! :) |
Understood - I'll open a specific improvement issue for the Synology fix so you can prioritise this one separately.
Automatic fallback is awesome 👍 |
|
Synology improvement proposal here: #2228 |
Adds the following video-related libs to the ARMv7 base image: libwebm1, libmatroska7, libdvdread8, libebml5, libgav1-0, libatomic1, libx264-163, libx265-199
Also installs the following, additional packages: - libcuda1 - libnvcuvid1 - mesa-va-drivers
graciousgrey
added
released
|
I am seeing issues /w QSV, it is complaining about incorrect parameters. This is an example, but it happened a bunch of times on my server.
|
|
Would be great if you can share more details, such as your Linux kernel version / operating system, CPU type and model, and anything else that could help to reproduce this. It may also help to change the user PhotoPrism is running as in case this is a permissions issue. |
|
CPU: Intel(R) Core(TM) i5-9400
Plex transcodes fines, but I know they use a customized ffmpeg. I will try to identify what the issue is, but no luck so far. |
|
You could try one of our other Docker images based on a different Debian version as it could depend on that as well. |
No change /w bullseye or jammy. |
|
Just to be sure: you installed the drivers and shred ALL required devices as shown in our example docker-compose.yml? |
|
This is my full .env file for photoprism: My photoprism in my docker-compose. |
|
What logs do you see when starting the container for the first time? You should see information about the drivers getting installed. Note init only runs once on the first start the variable was defined. Otherwise use docker-compose up --force-recreate Also note that while I've added magic to make the installation work as UID 1000, you should generally use the PHOTOPRISM_UID env variable for switching to the UID after init as installing drivers requires the container to start as root. Starting as UID 1000 and expecting distribution packages and device access to work 100% is experimental to say the least. |
|
I recommend trying as root, just to exclude the possibility of a permission or privilege issue after all, since these are the single most common cause for problems. Especially for transcoding and device access. |
|
Hello everyone, I can't succeed to make hardware acceleration works on my NAS Asustor 5202T, the CPU is an Intel® Celeron™ CPU @ 2.00GHz my log when finishing a transcode is my docker compose file contains this :
I tried also previously with here are my logs when first starting the container :
|
|
Hardware transcoding is one of the special features that causes a very high support and maintenance overhead for our team. To account for that, it's currently only available to sponsors. |
|
Changed to root... runnng convert to get more low level details now... |
|
This took longer than expected.... I think running it as root worked... so I assume don't use user in docker-compose lol. |
|
One last follow up, using PHOTOPRISM_UID causes it to break again so Ill just stay root. |
|
Hi, I'm also having issues with using QSV transcoding on my QNAP-TS451+ which has an Intel Celeron J1900. According to Intel it supports QSV. I believe Photoprism is by far a better solution but I could use your help with hardware transcoding. When executing ffmpeg as root user inside the container as follows I get an error message: An excerpt of my When powering up photoprism I see the following messages: Am I doing everything correctly? It looks like I am running it as root. Looking forward to your support. |
lastzero
added
plus-feature
The current parameters cause ffmpeg to fail on an Synology 718+ w/Intel J3455 - I will open a bug for this.
I think what is happening is that the current invocation of ffmpeg attempts to create a hardware device called qsv (-init_hw_device) which it attempts to set to just "hw" ... but as far as I understand -init_hw_device, the short-hand device name you are creating has to be set to an actual device (quoting from ffmpeg.org's site):
So I think the reason ffmpeg spits out
Failed to set value 'qsv=hw' for option 'init_hw_device': Generic error in an external libraryis that hw is not an actual device.-filter_hw_device is then trying to pass a device to all filters in ffmpeg's filter-chain ... I presume this was meant to be the 'qsv' device (which is incorrectly set), not the generic 'hw' device which doesn't actually exist. From ffmpeg.org:
So I simply cannot understand how anyone has been able to get HW decoding/encoding to work using these parameters, whatever their configuration. As far as I can decode ffmpeg's docs, this won't work on any system.
If I remove the init_hw_device and -filter_hw_device gubbins and simply invoke...
... which is PhotoPrism's invocation but without a named hardware device being passed to all filters (or at least without the attempt to create a named hardware device and pass it to all filters, ffmpeg works.
If I additionally remove the -qsv_device parameter, ffmpeg continues happily and at same speed as with the -qsv_device parameter. It's only when I switch to
-c:v h264that the speed dramatically drops due to libx264 now being used instead of the QSV hardware (3 fps instead of 20 fps).Originally posted by @sunbeam60 in #1337 (comment)
The text was updated successfully, but these errors were encountered: