Transcoding stuck about immich HOT 19 OPEN

Hmm, I agree this seems like a bug in FFmpeg. Have you tried restarting the container?

from immich.

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.

from immich.

Same bug here. Had to restart container. But after restart it again starts to transcode and stuck.
Had to terminate job.
I was using HW transcode

from immich.

Same bug here. Had to restart container. But after restart it again starts to transcode and stuck.

Had to terminate job.

I was using HW transcode

Which acceleration API were you using?

from immich.

Which acceleration API were you using?

vaapi.
Disabled it for now.

Started encoding video 0885652b-e0c9-45ee-b837-32d0ea69c623 {"inputOptions":["-init_hw_device vaapi=accel:/dev/dri/card0","-filter_hw_device accel"],"outputOptions":["-c:v h264_vaapi","-c:a copy","-movflags faststart","-fps_mode passthrough","-map 0:1","-map 0:0","-g 256","-v verbose","-vf format=nv12,hwupload,scale_vaapi=1080:-2","-compression_level 7","-qp:v 23","-global_quality:v 23","-rc_mode 1"],"twoPass":false}

from immich.

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.

from immich.

Can both of you clarify the following:

1. Was transcoding concurrency set above 1?
2. What kernel version does the server have?
3. What model is the processor (or GPU if it's a discrete GPU)?

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.

from immich.

There's also this issue that seems relevant.

from immich.

Can both of you clarify the following:

1. Was transcoding concurrency set above 1?
2. What kernel version does the server have?
3. What model is the processor (or GPU if it's a discrete GPU)?

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.

1. The transcoding concurrency is 1
2. Linux b35022ea1bc4 6.8.4-3-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.4-3 (2024-05-02T11:55Z) x86_64 GNU/Linux
3. J3455

from immich.

There's also this issue that seems relevant.

I have done more tests and it seems that it's all related to HDR videos.
I also open this issue under media-driver project.
When transcoding HDR video, it failed about 5 times and stuck 1 time in average.

from immich.

Can both of you clarify the following:

Was transcoding concurrency set above 1?
What kernel version does the server have?
What model is the processor (or GPU if it's a discrete GPU)?

1. transcoding concurrency is 1
2. Linux 6.1.0-22-amd64 (omv 7)
3. AMD Ryzen 5 5600G

from immich.

It makes sense that it only fails for HDR videos since the command will only have the tonemap_opencl filter for HDR videos. Seems like that filter is where the issue lies, but I'm not sure what the root cause is.

Does disabling hardware decoding (and keeping hardware encoding enabled) avoid the issue?

from immich.

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.

from immich.

Does disabling hardware decoding (and keeping hardware encoding enabled) avoid the issue?

Can you advice how to set such config?

from immich.

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.

from immich.

It's said Applies only to NVENC and RKMPP. But i have VAAPI on my AMD

from immich.

Hmm, that's a good point: the common thread here isn't OpenCL.

We know that:

• QSV also uses VAAPI
• The VAAPI command uses software decoding and tone-mapping without OpenCL
• @Goodwu tested QSV with hardware decoding and tone-mapping with OpenCL
• Software transcoding doesn't cause FFmpeg to hang

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.

from immich.

It's also possible that these are just two different issues that happen to both cause FFmpeg to hang.

from immich.

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:

• I have been using vaapi acceleration within immich for a while now - it only stopped working somewhat recently (unsure exactly when but within the past few months).
• I think my issues are also related to HDR videos since my phone records HDR by default.
• I also leverage vaapi transcoding for HDR content on the same device via Jellyfin (with no issues, just tested) using a similar config (passing /dev/dri to the container via docker compose).

from immich.