I have seen this tried already directly with ffmpeg and other transcoders using QSV on Haswell and older. Bottom line you need new HW if you want better PQ with HW transcoding. Again there was tremendous improvement starting with Broadwell and later. PQ using QSV with Sandy Bridge, Ivy Bridge and Haswell is lackluster no matter what level you employ.
Thanks for the info. This is helpful. While Iâve seen lots of vague claims of improvements to QSV over the generations, quite a few pointed to a big improvement with Haswell, so I was hopeful to achieve something acceptable. I guess Iâll have to upgrade if I want to reap the benefits of QSV.
Have you had a chance to try this file?
(jellyfish-20-mbps-hd-hevc.mkv)
viewed hw encoded, the 20 mbps sample is significantly worse than the sw encoded.
hw
sw
This is severe quality drop.
To be honest, Iâve found Haswell accelerated transcoding to be acceptable on mobile. But on big screens, I preferred software transcoding. Iâve reached the point where all big screens use devices that direct-play though.
Once we reached Skylake, I always use hardware accelerated when available. Intel has made some nice strides.
One weird thought: If your computer is expandable (I canât remember), and you only need a couple transcode sessions, you could consider something like an Nvidia Geforce GT 710. Theyâre less than 50 bucks and can do two hardware acceleration sessions. (Or more if you use hacked drivers but it may require a full reinstall). The encode quality isnât Kaby Lake level but itâs not bad. And if you donât like it, you could return it.
There are limitations though. The GT710 cannot handle HEVC, so it would still require software decoding for that. As much as anything, it would be a cheap way to see if it fixes this problem.
I just purchased an i5-9600k and a asus prime z390-A to be my future plex server, but thatâs another project (my OS of choice (xpenology) is not playing friendly with hardware coding at all on that future system.
Unfortunately the lenovo TS140 systems I currently use only have 2 PCIE E slots (10-Gig Ethernet, and an HBA)
I will eventually spin up another test plex server on my windows 10 laptop with 7200u kaby lake (620) I am just trying to control the number of variables here.
I am hoping that folks with Intel haswell CPUâs + SQV working will grab these samples, and try it for themselves, let me know if they see it as well.
Heck, I would gladly invite anyone who is interested in seeing it for themselves to see it off of mine. it might take some coordination, try opening it a few times etc. but as soon as Plex uses hw encoding on that 20 Mbps sample, the quality is terrible.
It does not just happen on that sample of course, but I finally found a publicly hosted royalty free clip that triggers the issue! now I just need some fellow testers interested in hardware trans-coding in Plex 
I tested the jellyfish-20-mbps-hd-hevc out with a geforce 1080, using nvidia decode(DXVA2 cuz windows) â> nvenc encoding, no noticeable quality problems there. Unfortunately my intel processors all lack integrated GPUs, so Iâm not able to test QSV.
I have two guesses for this: First, Plex could be using weird ffmpeg/transcoder options in that specific scenario. Can you go through your Plex Media Server.log file and find where it starts the transcode for jellyfish and post it here? With debug enabled itâll show you all the options, itâll look something like this:
(This is for a different file, not the jellyfish file)
C:\Program Files (x86)\Plex\Plex Media Server\PlexTranscoder.exe -codec:#0x01 h264 -probesize 10000000 -i "I:\Test\test.mkv" -filter_complex [0:#0x01]scale=w=1280:h=720[0];[0]format=pix_fmts=yuv420p|nv12[1] -map [1] -codec:0 libx264 -crf:0 23 -maxrate:0 3204k -bufsize:0 6408k -r:0 23.975999999999999 -preset:0 veryfast -level:0 5.1 -x264opts:0 subme=1:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none -force_key_frames:0 expr:gte(t,0+n_forced*3) -map 0:#0x02 -metadata:s:1 language=eng -codec:1 copy -copypriorss:1 0 -f dash -min_seg_duration 3000000 -skip_to_segment 1 -time_delta 0.0625
The second guess is that as others have alluded to, it might be an issue on the silicon. Itâs been a while, but I do remember reading forum posts elsewhere about haswell putting out atrocious quality in some scenarios.
:edit: Ah, found some mentions of this in old reviews: QuickSync Gets Open Source Support, Regresses in Quality - Intel's Haswell - An HTPC Perspective: Media Playback, 4K and QuickSync Evaluated
Quote:
In our opinion, the QuickSync results on HD4600 appear to be worse than what is obtained on the HD4000. With Haswell, Intel introduced seven levels of quality/performance settings that application developers can choose from. According to Intel, even the lowest quality Haswell QSV settings should be better than what we had with Ivy Bridge. In practice, this simply isnât the case. Thereâs a widespread regression in image quality ranging from appreciably worse to equal at best with Haswell compared to Ivy Bridge.
for anyone concerned about HA quality;
if you are transcoding for STORAGE then simply use CPU transcoding for maximum quality.
if you are transcoding dynamically for on the fly viewing, who cares what quality is, itâs only for temporary viewing and you still have the original at whatever full quality/bitrate.
if you get a client that direct plays then you donât have to worry about quality loss.
if its going to remote or mobile user, again who cares the quality.
Thanks for that testing!
I will go through my logs and respond asap.
To you second point. the hw-encode quality (I believe its the encode that is the problem, not the decode) from the 3/5/10/15/25 mbps jellyfish samples is MUCH better the 20 mbps sample. I suspect this would indicate it is not the hardware.
I care because, on a few files, the quality is horrible. most are just a bit worse, but more than acceptable. I am OK with a small degradation, this is expected. I am worried about the odd file, or the odd piece of some files, that it is just terrible. Itâs not random, I can reproduce it, so hopefully, this can lead to a solution!
Is this the line? if not I have added the file.
the very last time I played that 30 second file (i pulled logs as it ended) was an example of when it used hw encoding and gave the severely bad picture.
Mar 03, 2019 21:00:54.764 [2900] DEBUG - Job running: EAE_ROOT=â\?\C:\Users\admin\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\EasyAudioEncoderâ FFMPEG_EXTERNAL_LIBS=âC:\Users\admin\AppData\Local\Plex\ Media\ Server\Codecs\a22632d-2034-windows-x86\â X_PLEX_TOKEN=âxxxxxxxxxxxxxxxxxxxxâ C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe -codec:0 hevc -hwaccel:0 dxva2 -hwaccel_fallback_threshold:0 10 -probesize 10000000 -i \ds2\media\samples\jellyfish-20-mbps-hd-hevc.mkv -filter_complex [0:0]scale=w=1920:h=1080[0];[0]format=pix_fmts=nv12[1] -map [1] -codec:0 h264_qsv -b:0 67095k -maxrate:0 89460k -bufsize:0 178920k -r:0 29.969999999999999 -force_key_frames:0 expr:gte(t,0+n_forced*1) -f dash -min_seg_duration 1000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/2qmgpilk983a9rgq8wa9whff/38620b21-a833-4d43-9ffe-c74028e273ed/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/2qmgpilk983a9rgq8wa9whff/38620b21-a833-4d43-9ffe-c74028e273ed/progress
single log file.zip (292.4 KB)
Iâve just tested the Jellyfish files. Iâm transcoding to a 4mbps target and donât see an appreciable difference using any of the Jellyfish files (the 20mbps one looks about the same as the 5 or 10 mbps ones do).
That said, as per usual, the picture quality is significantly better with software transcoding than hardware. But I donât see something uniquely bad with the 20mbps file.
I should have mentioned this much earlier, but Iâm running an i3-4130 and Plex 1.14 on Debian Linux.
I build another test server, this time with 1.1.4 the public PMS server. windows 10 e3-1275v3 QSV etc.
the same issue. the 20 meg sample, when it decides to use QSV, it is blocky as heck
I did notice one additional item!
It looks terrible when it is set to âconvert to 1080 HD (High) (Maximum.) 19.9 Mbps.â
It looks just fine when I select âconvert to 1080p HD (medium) 12 Mbpsâ or âconvert to 1080p HD 10 Mbpsâ or âconvert to 1080p HD 8 Mbpsâ
FWIW I just tried the 20mbps HEVC video HW transcoded to 19.9 Mbps and was unable to see the issues youâre complaining of. It looked fine to me at that bitrate.
Thank for looking. I am at a bit of a loss. can you look at my screen shots, do they look similar to you? I am not sure if I am been too picky but its night and day to me. were you using the web client?
A sign down at the local garage not only applies to auto repairs but kinda to transcoding too
You want high quality, fast itâs not going to be cheap
You want it done cheap and fast itâs not going to be high quality
You want high quality and done cheap itâs not going to be fast
Pick which ever your check book allows
1 Like
I see no unusual options for that, but it doesnât look like that particular line was restricted to 20 megabit, as the -b:0 67095k option suggests 67 megabit, which is what I would expect from plex converting a 20 megabit h265 file to h264 without a bitrate restriction.
Try to grab one that has -b:0 20000k (or some number inbetween 15000k and 25000k)
Actually, try and grab the transcoder.exe line for the convert to 19.9 Mbps option and one of the others.
While humorous, it does not describe the problem I am sharing. The hardware transcoder works properly on lower bitrate AND higher bitrate files. Hardware transcoding works correctly on 3/10/15/30/35/40/50/60 Mbps versions of this same clip. All of those bitrates result in an acceptable end product. The 20 Mbps version of this clip results in an end product that is much worse than ALL of those other versions.
The fact my Hardware/Software/Configuration can handle the more challenging 60 Mbps clip tells me that it should be beefy enough to easily handle the 20 Mbps clip.
The fact that I am satisfied with the end product of the 3 Mbps clip tells be my standards are not unreasonable.
Lastly, the fact that it happens every single time tells me that it is a configuration issue or a bug. Maybe a CPU hardware bug, maybe an Intel graphics driver bug, maybe an FFmpeg bug, or maybe how plex calls FFmpeg bug.
OK, here is a much smaller log file that contains only three viewings on my test plex server.
Windows 10 1809 build 17763.348 (patch to date 3-10-2019)
CPU Intel Xeon E3-1275v3 w integrated GPU P4600 QSV v3 graphics driver 20.19.15.5058
32GB ECC RAM
no additional graphics card.
Plex Media Server Version 1.15.1.710
The first viewing @ about 13:11 (20 Mbps sample)
Plexweb Chrome v3.89.2 client, quality: Convert Maximum
Dashboard confirmed direct/secure/Iocal/no hw decode, no hw encode.
Visual quality was good.
reviewing the Plex Media Server log
(I believe lines 1337-1895)
line 1337 (no joke)
Mar 10, 2019 13:11:43.058 [9176] DEBUG - Loading Movie 'jellyfish-20-mbps-hd-hevc' XML from C:\Users\admin\AppData\Local\Plex Media Server\Metadata\Movies\1\63833c08a1fd400e4a7e767ad048bec94720982.bundle\Contents/_combined
line 1421 (appears to play the file)
Mar 10, 2019 13:11:43.577 [9200] DEBUG - Job running: EAE_ROOT='\\?\C:\Users\admin\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='C\:\\Users\\admin\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\a22632d-2034-windows-x86\\' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe -codec:0 hevc -hwaccel:0 dxva2 -hwaccel_fallback_threshold:0 10 -probesize 10000000 -i \\ds2\media\samples\jellyfish-20-mbps-hd-hevc.mkv -filter_complex [0:0]scale=w=1920:h=1080[0];[0]format=pix_fmts=nv12[1] -map [1] -codec:0 h264_qsv -b:0 67095k -maxrate:0 89460k -bufsize:0 178920k -r:0 29.969999999999999 -force_key_frames:0 expr:gte(t,0+n_forced*1) -f dash -min_seg_duration 1000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/36w4o5ej0y9mvti9otrztsij/c6ccb047-fb0f-47fd-92cc-1d8314c32bad/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/36w4o5ej0y9mvti9otrztsij/c6ccb047-fb0f-47fd-92cc-1d8314c32bad/progress
line 1482 (appears to play the file, AGAIN)
Mar 10, 2019 13:11:44.483 [7224] DEBUG - Job running: EAE_ROOT='\\?\C:\Users\admin\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='C\:\\Users\\admin\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\a22632d-2034-windows-x86\\' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe -codec:0 hevc -probesize 10000000 -i \\ds2\media\samples\jellyfish-20-mbps-hd-hevc.mkv -filter_complex [0:0]scale=w=1920:h=1080[0];[0]format=pix_fmts=yuv420p|nv12[1] -map [1] -codec:0 libx264 -crf:0 16 -maxrate:0 89460k -bufsize:0 178920k -r:0 29.969999999999999 -preset:0 veryfast -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none -force_key_frames:0 expr:gte(t,0+n_forced*1) -f dash -min_seg_duration 1000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/36w4o5ej0y9mvti9otrztsij/c6ccb047-fb0f-47fd-92cc-1d8314c32bad/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/36w4o5ej0y9mvti9otrztsij/c6ccb047-fb0f-47fd-92cc-1d8314c32bad/progress
With two play lines for a single viewing my guess is that it tried to play it via hw transcoding, failed, and retried using sw, and succeeded.
The second viewing @ about 13:13 (30 Mbps sample)
(not the problem file, performed just to seperate the other important playbacks)
Plexweb Chrome v3.89.2 client, quality: Convert Maximum
Dashboard confirmed direct/secure/Iocal/no hw decode, no hw encode.
Visual quality was good.
reviewing the Plex Media Server log
(I believe lines 2384-2870)
line 2384 (loading file)
Mar 10, 2019 13:13:32.085 [4300] DEBUG - Loading Movie 'jellyfish-30-mbps-hd-hevc' XML from C:\Users\admin\AppData\Local\Plex Media Server\Metadata\Movies\6\3d624940dc23cba3456023ac528497e8f480564.bundle\Contents/_combined
line 2480 (appears to play the file)
Mar 10, 2019 13:13:32.382 [4300] DEBUG - Job running: EAE_ROOT='\\?\C:\Users\admin\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='C\:\\Users\\admin\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\a22632d-2034-windows-x86\\' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe -codec:0 hevc -hwaccel:0 dxva2 -hwaccel_fallback_threshold:0 10 -probesize 10000000 -i \\ds2\media\samples\jellyfish-30-mbps-hd-hevc.mkv -filter_complex [0:0]scale=w=1920:h=1080[0];[0]format=pix_fmts=nv12[1] -map [1] -codec:0 h264_qsv -b:0 102559k -maxrate:0 136746k -bufsize:0 273492k -r:0 29.969999999999999 -force_key_frames:0 expr:gte(t,0+n_forced*1) -f dash -min_seg_duration 1000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/m0q85uvm3hlulbrb82b8csfc/0856c0d6-67ec-4125-9d62-3891dc5245d6/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/m0q85uvm3hlulbrb82b8csfc/0856c0d6-67ec-4125-9d62-3891dc5245d6/progress
line 2566 (appears to play the file, AGAIN)
Mar 10, 2019 13:13:33.476 [4660] DEBUG - Job running: EAE_ROOT='\\?\C:\Users\admin\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='C\:\\Users\\admin\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\a22632d-2034-windows-x86\\' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe -codec:0 hevc -probesize 10000000 -i \\ds2\media\samples\jellyfish-30-mbps-hd-hevc.mkv -filter_complex [0:0]scale=w=1920:h=1080[0];[0]format=pix_fmts=yuv420p|nv12[1] -map [1] -codec:0 libx264 -crf:0 16 -maxrate:0 136746k -bufsize:0 273492k -r:0 29.969999999999999 -preset:0 veryfast -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none -force_key_frames:0 expr:gte(t,0+n_forced*1) -f dash -min_seg_duration 1000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/m0q85uvm3hlulbrb82b8csfc/0856c0d6-67ec-4125-9d62-3891dc5245d6/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/m0q85uvm3hlulbrb82b8csfc/0856c0d6-67ec-4125-9d62-3891dc5245d6/progress
With two play lines for a single viewing my guess is that it once more, tried to play it via hw transcoding, failed, and retried using sw, and succeeded.
The third viewing @ about 13:14 (20 Mbps sample)
(This is where I got terrible quality)
Plexweb Chrome v3.89.2 client, quality: Convert Maximum
Dashboard confirmed direct/secure/Iocal/(hw) decode, ( hw) encode.
reviewing the Plex Media Server log
(I believe lines 3166-3524)
line 3191 (appears to play the file)
Mar 10, 2019 13:15:15.328 [6592] DEBUG - Job running: EAE_ROOT='\\?\C:\Users\admin\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='C\:\\Users\\admin\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\a22632d-2034-windows-x86\\' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe -codec:0 hevc -hwaccel:0 dxva2 -hwaccel_fallback_threshold:0 10 -probesize 10000000 -i \\ds2\media\samples\jellyfish-20-mbps-hd-hevc.mkv -filter_complex [0:0]scale=w=1920:h=1080[0];[0]format=pix_fmts=nv12[1] -map [1] -codec:0 h264_qsv -b:0 67095k -maxrate:0 89460k -bufsize:0 178920k -r:0 29.969999999999999 -force_key_frames:0 expr:gte(t,0+n_forced*1) -f dash -min_seg_duration 1000000 -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/1iywk8zq8ejlqfoo397wsjbv/87055702-a5fc-4a8f-9b17-e2b685222ce7/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/1iywk8zq8ejlqfoo397wsjbv/87055702-a5fc-4a8f-9b17-e2b685222ce7/progress
line 3524 (file got played)
Mar 10, 2019 13:15:50.700 [6832] DEBUG - Library item 10366 'jellyfish-20-mbps-hd-hevc' got played by account 1!
With only one play line hw transcoding worked on the attempt.
Plex Media Server views 1-3.zip (70.4 KB)
I had a volunteer who connected remotely to my plex server and once he configured his client in the same way (plex web, chrome, maximum rate) he saw the same degradation in the same file when (hw) encode kicks in.
So, its not something with my client that is the issue.
