VC1 VAAPI decoder not working after 4.8.11.0 upgrade

[nojaha 1]

Hi guys

I've been using the VAAPI decoder over QuickSync for my VC-1 decoding needs for a while now, since using QuickSync would result in massive audio delays (talking several minutes here). I upgraded the server today from version 4.8.10.0 to version 4.8.11.0, and now the VAAPI decoder just fails whenever I try to transcode. It can still decode with QuickSync as it did before, with the preexisting issue with the audio delay. From what I can read, QuickSync doesn't seem to be the best at decoding VC-1 anyway

I've attached what I think are all the relevant logs, as well as a couple of screenshots of where it seems to fail in the transcode log, and when it fails on the user side. Please let me know if there is anything missing

System Setup
OS: Unraid 6.12.14
CPU: i3-1315U
RAM: 64 GB DDR4-3200
System Storage (Docker & Transcoding): Samsung 990 Pro SSD 4TB
Media Storage: WD Red Plus 12TB HDDs

ffmpeg-transcode-1a6f266f-ddd2-4940-8f42-c8a32f1d7837_1.txt embyserver.txt hardware_detection-63877405728.txt

[Luke 40082]

hi, can you try unchecking the quicksync encoder and see if that resolves it?

Failing that, can you provide a 4.8.10 log log of the same content for comparison purposes? Thanks.

[nojaha 1]

Unchecking the QuickSync encoder did indeed resolve it!

Do you have any idea why it seems to have worked before? Would like to be able to use QuickSync for encoding and decoding in general, and only using VAAPI for decoding VC-1, if possible

Edited March 12 by nojaha

[Luke 40082]

At some point we changed quicksync to be prioritized over vaapi. I didn't think that change had made it into 4.8 yet but I guess it must have.

[nojaha 1]

Is this a permanent change, and moving forward does this mean that I won't be able to have VAAPI selected for decoding VC-1, without also unchecking QuickSync completely from the encoders?

[Luke 40082]

4 minutes ago, nojaha said:

Is this a permanent change, and moving forward does this mean that I won't be able to have VAAPI selected for decoding VC-1, without also unchecking QuickSync completely from the encoders?

In our testing and development we believe qsv is generally a better option so that is why it is prioritized higher now. But there are always exceptions to the rule and that's why the options exist. In 4.8.10 it probably was encoding with vaapi so the end result is the same as unchecking qsv for it.

[Luke 40082]

Actually the change is still 4.9 only. If you could install 4.8.10 over the top real quick to test it and provide a log, we might learn something from that. Thanks.

[nojaha 1]

I'm sorry, over the top? Do you want me to downgrade, or spin up another Docker instance?

[Luke 40082]

You can just install 4.8.10 over your current install as a way of downgrading, yes. Then test it and provide the log, and then you should be able to upgrade again.

[nojaha 1]

Well, now it doesn't work on version 4.8.10.0 anymore either  Not sure if the logs will provide anything useful, since it seems to be failing in the exact same way now. Perhaps residual leftovers from the 4.8.11.0 upgrade?

ffmpeg-transcode-5357c63e-07f8-425d-9f0f-51a605c055fc_1.txt embyserver (1).txt

[nojaha 1]

I have a couple of server logs from before the upgrade, but no transcoding logs, unfortunately 

[Luke 40082]

No, did you update drivers recently? Try rolling that back.

[nojaha 1]

Well, I upgraded from version 6.12.13 to 6.12.14 of Unraid, which effectively changes the Linux kernel from 6.1.106 to 6.1.118. Want me to try downgrading?

[Luke 40082]

I think for now yes. We are currently investigating an issue with the latest drivers. Thanks.

[nojaha 1]

Tried downgrading to version 6.12.13 of Unraid, as well as trying with both 4.8.10.0 and 4.8.11.0 of Emby, and none of them work now Not sure what the hell went wrong

Pardon my ignorance here, and correct me if I'm wrong  It sounds like whatever decoder is used, it should be matched for the encoder as well? Shouldn't it automatically select the correct encoder based on which decoder is used? And that the priority weighting should be on the decoder side, if a decoder is indeed used?

ffmpeg-transcode-64f6904a-8512-4f73-852d-60865a3df8df_1.txt embyserver (2).txt

[Luke 40082]

@nojahaare you still having an issue with this?

[nojaha 1]

Last I checked, it still didn't work. So for now I've opted to disable hardware decoding for VC-1, and instead rely on software decoding, which seems to be working alright However, I have since then also gone through the process of manually transcoding all my VC-1 files to H.264. It is therefore technically not a problem anymore, since I don't have anymore VC-1 files

I've since then also upgraded to version 6.12.15 of Unraid, but haven't tried it with that version, since I had already transcoded all the VC-1 files at that time. Kernel version is 6.1.126 for this version of Unraid.

Would love not to have to transcode these files manually, but seeing as it is such an inefficient codec anyway, and having to deal with the hassle of it, I will be transcoding any VC-1 files immediately when I'm done ripping.

[Luke 40082]

OK we will also have an updated ffmpeg build on the server beta channel in the near future, just FYI.