-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transcoding stuck #10560
Comments
Hmm, I agree this seems like a bug in FFmpeg. Have you tried restarting the container? |
No, I killed the ffmpeg with -9 and it retried with software transcoding. And it continue transcoding with HW accel normally. |
Same bug here. Had to restart container. But after restart it again starts to transcode and stuck. |
Which acceleration API were you using? |
vaapi.
|
Interesting, I wonder if it's specific to VAAPI then. I'll take a look at their issue tracker to see if this is a known issue. |
Can both of you clarify the following:
The only relevant info I've seen online is this issue along with the kernel bug it links to. But since the issue is quite old, I'm not sure if this is really it. |
There's also this issue that seems relevant. |
|
|
It makes sense that it only fails for HDR videos since the command will only have the Does disabling hardware decoding (and keeping hardware encoding enabled) avoid the issue? |
Also worth noting that we use bleeding edge versions for the relevant dependencies following this PR. It may be interesting to try different versions of these to see if it affects the behavior. |
Can you advice how to set such config? |
In the transcoding settings, there is a setting for the hardware acceleration API, and a setting for hardware decoding below it. If hardware decoding is disabled but you set it to use an acceleration API, it will accelerate encoding only and handle decoding and tone-mapping on CPU. |
It's said |
Hmm, that's a good point: the common thread here isn't OpenCL. We know that:
That leaves QSV/VAAPI encoding as the most likely culprit. But that depends on whether the issue persists when hardware decoding for QSV is disabled. If it doesn't, it would poke a hole in this hypothesis. |
It's also possible that these are just two different issues that happen to both cause FFmpeg to hang. |
Coming here from the issue I opened (#10738) since this one originally seemed like a qsv issue when I was searching. A few points I can add to the convo here:
|
Any news regarding this issue? |
If it's a bug in FFmpeg, it might be fixed once we update to 7.0. There's a draft PR for this upgrade that needs to go through testing. |
I have the same issue with small videos from animated photos. I disabled the Acceleration API to "disabled" and it used a lot of CPU for a while and it went through all the stuck videos.
|
Is this still an issue as of 1.118.2? |
It seems to have been solved, for me transcoding ran without any issues after updating to 1.118.2 |
Nice! I’m marking this as closed, but feel free to chime in if there are still cases where this happens on 1.118.2 or later. |
@mertalev No Error message, just:
And then it gets stuck and doesnt continue to process. A restart doesnt resolve the issue it gets stuck on the same video which is recorded by the same mobile phone which has created videos that were transcoded without issues. Is there any way to increase logginh on the ffmpeg level? |
Hmm, you can set the log level to debug in the admin settings and restart immich. |
Yup. |
Ok i did some investigation: Please notice that I had to slightly adjust the command in order to make it work (remove -n 10 /usr/bin/ffmpeg) I am not sure why it is there in the first place but thats maybe another discussion. This is the output of a file where everything worked:
Thats the output of a file where it gets stuck and it does not go past the last line:
Anything interesting that can be derived from that analysis? (Other than its most likely an issue with ffmpeg) |
@mertalev
File which got stuck:
File that worked:
The trained eye sees a difference in the
Which led me to the stuipid idea to set the framerate in the ffmpeg to the standard frame rate of 29.97 as part of the ffmpeg command (I had to remove -fps_mode passthrough to resolve the conflict)
And the file got transcoded without any errors and with VAAPI enabled. IS THIS THE SOLUTION??? What does speak against setting -r 29.97 as a default setting and not preserve the initial frame rate? |
Huh, interesting! Could you try |
Also tried auto and cfr, both fail as well. |
Okay, some other things to try: |
I tried all 4 options and all got stuck the same way. No luck. Here the commands I tried
|
Is there anything useful in dmesg or journalctl? |
Nope. No error. No message. Nothing. Would have been too easy i guess :-D |
Haha I guess so. What if you change |
Also, does it just immediately get stuck, or does it make any progress first? |
Did not work as well, sorry :-(
It shows immediately |
Well this is weird. What do you get if you set the FFmpeg verbosity to |
I tried setting -r to a couple of different values (1, 5, 10, 30, 50, 100, 500) and it worked each time without an issue. |
What happens if you set it to the original fps (I believe 28.46)? |
Works smoothly.... |
That has to mean the FPS is variable, right? Or setting the FPS wouldn't have any effect. Can you output the individual frames with FFprobe to see if there's anything weird going on? Probably just around the start since it affects the transcoding immediately. |
The bug
It seems like ffmpeg running into deadloop.
Ffmpeg running at 100% CPU usage for hours, and the output file size is only 48 bytes.
HW decoding and encoding switch are all ON.
Have accured two times, both have the same behavior.
The OS that Immich Server is running on
OMV7
Version of Immich Server
v1.106.4
Version of Immich Mobile App
v1.106.4
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Relevant log output
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: