thanks, I thought it was only me.
I’m on haswell iGPU, and still the video quality at 8Mbit was abysmal, and I’m not sure if it’s me, or every GPU transcode is this bad.
fingers crossed for better drivers down the line.
So if they release 2.0 driver, it will work with plex right away?
I have a Skylake running Ubuntu 17.04 and PMS 1.9.3. All my media are full quality remuxes. I transcode to 20Mbps and haven’t seen artifacts since I have been testing for some time. Seems lower bitrate sources transcoded result in more artifacts. Newer Intel iGPUs are suppose to have higher quality QSV.
@LSL1337 said:
I’m on haswell iGPU, and still the video quality at 8Mbit was abysmal, and I’m not sure if it’s me, or every GPU transcode is this bad.
As you can see in the mentioned post, the user has an Haswell CPU and a Braswell CPU and both have the same artifacts under Linux, while Haswell works well under Windows. That’s easy to infer that even Braswell could work well under Windows since Braswell and Haswell share the same GPU AFAIK. There is people who are having good results in Linux, but AFAIK they are all on a more recent build, like Ubuntu 16.10 or 17.04 .
fingers crossed for better drivers down the line.
So if they release 2.0 driver, it will work with plex right away?
The problem is that we are on a LTS release, I don’t see new drivers coming sooner than the next major LTS update, which is 18.04. I don’t feel like messing with drivers and libraries on LTS distros, I had to do it for a bug in Python filling Kodi logs but I’ll just wait and ditch hw transcoding, or shift to a “normal” Ubuntu release. Oh or WIndows, but I’ll hate doing that 
@zpaolo11x said:
@LSL1337 said:
I’m on haswell iGPU, and still the video quality at 8Mbit was abysmal, and I’m not sure if it’s me, or every GPU transcode is this bad.As you can see in the mentioned post, the user has an Haswell CPU and a Braswell CPU and both have the same artifacts under Linux, while Haswell works well under Windows. That’s easy to infer that even Braswell could work well under Windows since Braswell and Haswell share the same GPU AFAIK. There is people who are having good results in Linux, but AFAIK they are all on a more recent build, like Ubuntu 16.10 or 17.04 .
fingers crossed for better drivers down the line.
So if they release 2.0 driver, it will work with plex right away?The problem is that we are on a LTS release, I don’t see new drivers coming sooner than the next major LTS update, which is 18.04. I don’t feel like messing with drivers and libraries on LTS distros, I had to do it for a bug in Python filling Kodi logs but I’ll just wait and ditch hw transcoding, or shift to a “normal” Ubuntu release. Oh or WIndows, but I’ll hate doing that
Look into Ubuntu HWE LTS kernels.
@Achilles said:
The problem is that we are on a LTS release, I don’t see new drivers coming sooner than the next major LTS update, which is 18.04. I don’t feel like messing with drivers and libraries on LTS distros, I had to do it for a bug in Python filling Kodi logs but I’ll just wait and ditch hw transcoding, or shift to a “normal” Ubuntu release. Oh or WIndows, but I’ll hate doing that
Look into Ubuntu HWE LTS kernels.
Oh, I had no idea that this existed, I thought kernel and X stack was updated regularly when LTS gets points updates, but from this sentence:
“The 16.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop.”
it seems that you need to enable HWE to get these updates from a previous installation, while you get the latest kernel + stack when you install a point release from scratch.
well, I’m pretty new to linux. I’m running unraid, and docker.
My understanding is that the docker uses the ‘pre-packaged’ plex provided drivers, which is still at 1.8.1
is this true? For me that means that I have to wait for a newer PMS release, which will eventually use the latest (2.0, when it’s stable) libva, and these artifacts will hopefully be fixed.
reading the posts, it seems that the earlier hw preview version were giving better quality, so not sure what happened, which made this worse.
I have the exact same issue on my NAS, I assume it uses a “linux-like” environment.
What can I do that might help you understanding this issue ?
Artifacts are, 99% of the time, the direct result of too low input bitrate. QSV is not a high quality tranform. If it were, Intel would not have called it Quick Sync Video. There is data loss. Whatever is input, less will come out. If the input is too low, the result is unwatchable. Simple mathematical fact.
As for Docker on Linux: In my view, it’s a ‘bag of hurt’ which isn’t needed. Docker may provide a way to ‘export containers’ and be portable. For as much as that may be true, a simple backup (tar or zip) backup of PMS’s Library directory is infinitely more portable and a lot easier to obtain. Running PMS in Docker on Linux , just because it can be done, begs problems. Run it native and be done. Get out of the schroot environment it created and take full advantage of what Linux gives.
Most NAS boxes now are Linux, not ‘Linux-like’. That said, take advantage of it.
@ChuckPA said:
Artifacts are, 99% of the time, the direct result of too low input bitrate. QSV is not a high quality tranform. If it were, Intel would not have called it Quick Sync Video. There is data loss. Whatever is input, less will come out. If the input is too low, the result is unwatchable. Simple mathematical fact.
But since the same CPU/GPU on Windows doesn’t show the same amount of “blockiness” (if that is a word) I suspect the issue is not only in the source material, but also in the library used in Linux. AFAIK there’s no user lamenting this blocky artifacts on Windows or Mac OS (I can check on Mac OS, I don’t have windows though).
It would be nice to know if there’s people not affected by this issue on Linux, they could tell their environment (Linux distro and driver/library versions) or even share a sample video so we can check it on other CPU/Distros/libraries.
Windows has had this capability for a long time. Somebody (presumably Microsoft, maybe graphics card companies, or even Intel themselves) paid for the ‘drivers and libraries’ to be written because there was money to be made. Linux is free.
That said. Someone (a user) did find the bug in Intel’s Linux driver a couple months ago. Since then , Intel has been pouring a lot of time & effort into updating and upgrading it. This is VA-API. If you follow it on Github, you’ll see all the activity… it’s blistering. When 2.0.0 is released, It will be up to date and have all the hardware included. At that point , I would fully expect Windows and Linux to be at parity again.
For those folks who have made custom configuration changes (amd or nvidia drivers, X windows configuration changes, etc), they have a lot more functionality.
Why not just wait a little while longer and see what the new VAAPI library gives or download it yourself and see what you get.
There are those who are doing precisely this. Download, compile, install, and use their own.
wow, I don’t run docker cos I can… I run it, cos it’s great!
btw that’s some great support man. I just shouldn’t use it. even when the problem doesn’t even have anything to do with docker…
yeah, talk to me about bitrate starve, when it’s clear, that it’s a driver error. 8mbit on windows is ‘almost’ transparent to bluray, and 8mbit on intel QS is close to 500kbit youtube from 2008…
whatever, let’s wait for VAAPI 2.0, and hope it fixes this linux error.
thanks for the help btw, cos this topic had some helpful information.
until this, I wasn’t even sure, that other people have this same exact problem, or
gpu encoding is inferior means that it’s just ■■■■. I was thinking ok, it’s maybe 10% worse then a same bitrate cpu encode, but what i saw (on linux) that it’s 95% worse.
so you can confirm that this issue is on plex’s radar, and when intel does something about it, it will eventually be included in PMS and the docker build?
that is GREAT news, thank you very much!
and yeah, docker is the future for everything headless
Interesting reply.
PMS on Windows in Docker?. Yeah it works… But if if Docker is so great, why did they either a) leave out mutexes and file locking in the Container-Host translation layer or b) allow it to continue to exist with bugs. Look around the forum and see how many users have Docker-Plex database corruption problems. These are 100% attributable to incorrect mutex/file locking implementation in the Docker container-host API layer.
Yes, I can and will confirm, VA-API 2.0.0 is on our radar. I brought it to the team’s attention when the roadblock bug in the existing VA-API release was found. Since then, Intel has been advancing at break-neck speed bringing it up to date with all processors and their other library implementation
I cannot, nor will not venture to guess, about Docker-Plex and hardware transcoding. At present, the user must be fully aware of what he/she is doing with regard to /dev/dri and all the ramifications thereof.
Docker isn’t the future of everything. It’s a technology designed for specific usage cases just like everything else. Nothing more. Therefore it cannot nor will ever be the end-all be-all.
@ChuckPA said:
That said. Someone (a user) did find the bug in Intel’s Linux driver a couple months ago. Since then , Intel has been pouring a lot of time & effort into updating and upgrading it. This isVA-API. If you follow it on Github, you’ll see all the activity… it’s blistering. When 2.0.0 is released, It will be up to date and have all the hardware included. At that point , I would fully expect Windows and Linux to be at parity again.
Thank you for the insightful info. It would be very useful to add some sort of note about this in the release notes of PMS for Linux, since until VAAPI update hardware transcoding is pretty useless for people affected by the bug.
Also, can you give some clarification about how do you have this updates in Ubuntu? I am on 16.04 LTS but I have recently added HWE so Kernel and X are “up to date” with the rolling release. Will I receive VAAPI 2.0 from the usual apt update/apt upgrade?
Again thank you for your help, it’s good to know there’s a chance that quality will improve on Linux PMS 
Thanks for the info.
BTW I wasn’t talking about docker for windows, I was just referencing windows in my previous post, as reference on what the onboard hw (igpu) can do on other platforms.
ps: and ofc docker won’t be the future of everything, but for single server applications, it’s pretty good. wonder how far it will go in the enterprise space in 10 years.
@ChuckPA I think I have something worth testing.
When I was running the previews on my Synology DS916+ I grabbed several worst case videos from my library, most of these videos do NOT hw decode as they are not supported codecs. I hadn’t really notices persistent blocking.
I have been doing more tests… Content that is hw–>hw seems to suffer major blocking in fast action, scene changes and panning… Content that is sw–>hw seem to suffer some blocking during initial playback but after that the quality is not bad.
As I can only trigger this with DIFFERENT videos I wondering if you could intentionally disable HW decoding and do a side by side with identical content to see if what I am seeing is consistent or just a difference in the action in the videos I am testing.
If it is, it might be a workaround to allow users to enable and disable accelerated decoding and encoding independently.
I am not going test that which I already know the outcome will be.
Any hardware trancode operation , whether it be decode or encode , is, by its nature, more lossy than software transcoding. This is because software get two passes at the data PLUS the hardware is still evolving. Hardware operations are nothing more than 1-pass matrix transforms.
Now, couple low bit rate input with this, you will have anomalies come through that software, since it has a ‘second pass’ at the data, won’t introduce.
When supplying high bit rate input to HW transcode, there is so much overwhelming data, the error rate (although a constant percentage) is not readily visible.
All my input is 25+ Mbps and I don’t have issues. I’m also using a 6th generation GPU (SkyLake) with its Intel® HD Graphics 530 as compared to your Intel N3710 with its Intel® HD Graphics 405.
I’m not putting you down but look at the specs. Synology didn’t use a good enough class CPU/GPU to overcome the bitrates being fed to it. Secondly, it’s not perfect but then neither is the i7-6700. It just has a lot more transisters to do finer grain matrix operations
To quote the support page:
The video quality may be lower, appearing more blurry or blocky. This is especially true and more noticeable when streaming at low quality levels below 720p. (Hardware-accelerated video encoders are faster, but lower quality than software encoders.)
https://support.plex.tv/hc/en-us/articles/115002178853-Using-Hardware-Accelerated-Streaming
Wasn’t suggesting it would make it as good but you literally made the case for doing your self.
First you state that both hardware decode and encode are MORE lossy than software.
You also state that higher quality input creates less noticeable degidation as your source inputs are high quality.
So if you trade the poor he decoder for software but keep the fast bur poor hardware encoder you should always get a better result that doing both in hw.
With the exception of HVEC, decoding most codecs in software isn’t that costly to CPU but encoding is.
I think it would be a worthwhile test. The code for fallback to software is literally already there.
I may try and do a clean blueray R.I.P. and then do an encode to an unsupported codec just to see what happens.
We all understand that HW transcoding will always be more lossy software.
It’s not necessary to repeat that :
- You don’t have the latest intel cheap that’s why it’s lossy
- Low bitrate
The **unique **(or unix :)) reason is because linux doesn’t have the latest/optimize driver.
The debate is closed.
All intel cheap are able to handle low bitrate (with acceptable quality) on windows => the unique reason is linux driver.
We have to wait new intel driver ( livaapi 2.0).
The only question that plex is able to answer is " Will plex adapt the transcoder if the new driver improve the quality ?"
( livaapi 2.0 breaks the compatibility with livapi 1.0)
thanks for your help
@maxime.wantiez said:
It’s not necessary to repeat that :
- You don’t have the latest intel cheap that’s why it’s lossy
- Low bitrate
Especially since a guy with 20 Mbps source video reported that he saw blocks as well, both when transcoding to 2 Mbps and to 8 Mbps
All intel cheap are able to handle low bitrate (with acceptable quality) on windows => the unique reason is linux driver.
We have to wait new intel driver ( livaapi 2.0).
I honestly wonder how this went under Plex radar (it was reported as early as preview 4 was released to plex pass users as a forum only test version) and maybe it was not a good idea to release it to all Linux versions. Every user of 16.04LTS I know has the experience that “Plex hardware transcoding on Linux sucks”, this is not so good and not deserved after all the development that Plex put into that.
@zpaolo11x said:
@maxime.wantiez said:
It’s not necessary to repeat that :
- You don’t have the latest intel cheap that’s why it’s lossy
- Low bitrate
Especially since a guy with 20 Mbps source video reported that he saw blocks as well, both when transcoding to 2 Mbps and to 8 Mbps
All intel cheap are able to handle low bitrate (with acceptable quality) on windows => the unique reason is linux driver.
We have to wait new intel driver ( livaapi 2.0).I honestly wonder how this went under Plex radar (it was reported as early as preview 4 was released to plex pass users as a forum only test version) and maybe it was not a good idea to release it to all Linux versions. Every user of 16.04LTS I know has the experience that “Plex hardware transcoding on Linux sucks”, this is not so good and not deserved after all the development that Plex put into that.
Intel had some notes for vaapi driver 1.8.0 that improves quality for Broadwell and Braswell H264 QSV encoding. I don’t know if Intel will go back further to Sandy Bridge, Ivy Bridge and Haswell to improve the drivers for QSV on those older generation CPUs.
