Server Version#: 1.19.1.2645
Player Version#: Plex Web 4.32.2, also tested on Roku Ultra
“The Chronicles of Riddick Director’s Cut” BluRay version, transcoded 1080p VC1 to 1080p H.264, about 28 to 30 minutes in, fairly dark scene with a lot of explosions and combat, heavy pixelation when hardware transcode is on. FreeBSD 12.1 (TrueNAS Core 12.0), Xeon 1225v6 (Kaby Lake) with P630 iGPU.
Tested on all four transcoder quality settings: Automatic, Prefer Speed, Prefer Quality, Make my CPU hurt.
Also tested on FreeBSD 11.3 (FreeNAS 11.3), same result.
Scene renders correctly when hardware transcode is turned off, and uses roughly 80% CPU for the software transcode.
I can think of many words and letters to describe VC-1, but the most appropriate are “PITA”.
Most of us (around here) eradicate VC-1 on arrival - by encoding it to something else. Yes, it’s painful, considering it’s a Single Thread Operation with VC-1, but that’s better than having to deal with that crap every time it plays on something.
Roku Ultra —> VC-1 ----> Transcode City (and not the nice part of town).
I do this at 3750Kbps and can’t tell the difference, but I’m using the eyeballs in my head - they won’t work at your house. Adjust as necessary.
I can tell ya, if you’re so inclined, you could make an HEVC Main 10 Version at 3750Kbps - it may take a while (just shy of an eternity), but you’ll be hard pressed to see the difference:
AN HEVC Main 10 from a 4K source - will look better than the version you have now - if you can get your hands on such a thing (I’ve probably been stumbling over them all week).
Oh, for sure. I’ve solved my specific playback issue by encoding the file to H.264. It’s still worth tracking down why the HWT has issues with that specific file. It seems to be high contrast, dark scenes with sudden flashes of brightness, that trigger it.
This with tell PMS to use the i965 instead of the iHD driver for your system. After you have made the change, please try the VC-1 transcode again and let me know if it resolves your issue.
Well, that solves the quality issue - by turning hardware transcode off lol. It uses software transcode with that setting.
I told it to go back to iHD.
The driver does exist:
root@Plex-Transcode:~ # find / -name ‘i965’
/usr/local/share/plexmediaserver/lib/dri/i965_drv_video.so
For now, I’ll just use the pre-converted H.264, and do the same for other VC1 files that may have issues.
Looks like the ball is in Intel’s court to fix the driver. I’m not going to hold my breath on that.
For years and years Intel shipped a buggy driver on Linux for their GPUs which resulted in hardware decode of VC-1 to go blocky in certain points. I’ve seen it in playback using hardware decoding of VC-1 on certain titles. It’s always in the same place and fairly rare with being on the level of 1-2 points in a movie.
For me the key example was the Jurassic Park (the very first one) BD in the scene where the raptors are being loaded into the cage. When the handler is shouting to other to “shoot her,” there’s a lot of flashes, smoke, and motion and the playback gets quite blocky for a few seconds.
Anyway, Intel finally corrected this driver a couple or so years ago and it made it into the Linux kernel then. I suspect the buggy Intel driver code was ported over to FreeBSD long ago and the fix has not made it over yet.
Interesting. I’m on an older kernel which may be why I’ve not seen it recur (or maybe I’ve just not played enough VC-1 content recently to notice it).
So I tried the same hardware on Ubuntu 20.04 (previously I was on 18.04) and the hardware decoder fails to open with VC1 (works with other codecs). I wonder if they changed it to recognize the issue and refuse to allow the decoder to open in this version.
It’s not necessarily “back”, as that’s a different driver than the one we were previously using, however, that issue is present in the new driver. I notice it in particular with the opening scene of The Bourne Identity. We’re really dependent on Intel resolving this at the moment. I’m on Ubuntu 18.04 with a Kaby Lake G processor.
