Hardware transcoding on Qnap TVS-672XT

You bet! I will make this in two posts to keep the files separate. Maybe you can just look at the second post if you know what you’re after.

First post here the transcoding IS working properly on the stock qpkg version 1.16.6.1592. Logs are attached below. The playback area to look at is: 9/24/2020 with time code 20:40:00 to 20:40:35.

Also, here is the process for the transcode from a ps x grep is:

7329 admin 190336 S /share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Plex Transcoder -codec:0 hevc -hwaccel:0 vaapi -hwaccel_fallback_threshold:0 10 -hwaccel_output_format:0 vaapi -codec:1 aac_lc -ss 1610 -analyzeduration 20000000 -probesize 20000000 -i /share/Movies/Movies/[Deleted for google].2160p.4K.BluRay.x265.10bit.AAC5.1.mkv -filter_complex [0:0]hwupload[0];[0]scale_vaapi=w=1920:h=804:format=nv12[1];[1]hwupload[2] -filter_complex [0:1] aresample=async=1:ocl=‘stereo’:osr=48000[3] -map [2] -codec:0 h264_vaapi -b:0 5472k -maxrate:0 7296k -bufsize:0 14592k -r:0 23.975999999999999 -force_key_frames:0 expr:gte(t,1610+n_forced*1) -map [3] -codec:1 aac -b:1 161k -f dash -min_seg_duration 1000000 -skip_to_segment 1611 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/ljcgddqwwdyo3dvvchx9jd3q/13c071b7-7537-44d4-9077-7022f2631f6d/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -y -vaapi_device /dev/dri/renderD128 -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/ljcgddqwwdyo3dvvchx9jd3q/13c071b7-7537-44d4-9077-7022f2631f6d/progress

Second post here the transcoding IS NOT working properly after upgrading the qpkg version to v1.20.1.3252 (latest). Logs are attached below and are using the same playback file. The playback area to look at is: 9/24/2020 with time code 20:46:30 to 20:47:50.

Also, here is the process for the transcode from a ps x grep:

1029 admin 867704 R /share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Plex Transcoder -codec:0 hevc -ss 1850 -analyzeduration 20000000 -probesize 20000000 -i /share/Movies/Movies/[Deleted for google].2002.2160p.4K.BluRay.x265.10bit.AAC5.1.mkv -filter_complex [0:0]scale=w=3058:h=1280[0];[0]format=pix_fmts=yuv420p|nv12[1] -map [1] -codec:0 libx264 -crf:0 16 -maxrate:0 18502k -bufsize:0 37004k -r:0 23.975999999999999 -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,1850+n_forced*1) -map 0:1 -codec:1 copy -copypriorss:1 0 -f dash -seg_duration 1 -init_seg_name init-stream$RepresentationID$.m4s -media_seg_name chunk-stream$RepresentationID$-$Number%05d$.m4s -window_size 5 -delete_removed false -skip_to_segment 1851 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/pa7c787rfcexqcfjsrfi3nc7/f1016326-ad54-48d7-8f84-325b0aa21c5b/manifest?X-Plex-Http-Pipeline=infinite -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -y -init_hw_device vaapi=vaapi: -hwaccel_device vaapi -filter_hw_device vaapi -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/pa7c787rfcexqcfjsrfi3nc7/f1016326-ad54-48d7-8f84-325b0aa21c5b/progress

do not upgrade to 1.20.2 — yet.

There is a build issue. It’s being worked on.
Watch the announcements.

This isn’t cool at all. TLS errors. Nothing is going to work without it.

Sep 24, 2020 20:43:05.856 [0x7effe19e9700] ERROR - Error issuing curl_easy_perform(handle): 7
Sep 24, 2020 20:43:05.856 [0x7effe19e9700] WARN - HTTP error requesting GET https://192-168-1-49.03d1e9ca5fbe4dc4863840e9c6cb2d80.plex.direct:32400 (7, Couldn't connect to server) (Failed to connect to 192-168-1-49.03d1e9ca5fbe4dc4863840e9c6cb2d80.plex.direct port 32400: No route to host)
Sep 24, 2020 20:43:06.399 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:06.399 [0x7f004ab7d700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/bandwidth?timespan=6 (31 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:06.399 [0x7f00721b9700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/bandwidth?timespan=6 (31 live) GZIP 0ms 881 bytes (pipelined: 30)
Sep 24, 2020 20:43:07.441 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:07.441 [0x7f004b447700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/resources?timespan=6 (30 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:07.441 [0x7f00721b9700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/resources?timespan=6 (30 live) GZIP 0ms 530 bytes (pipelined: 31)
Sep 24, 2020 20:43:07.460 [0x7f0071aad700] DEBUG - HTTP requesting GET https://plex.tv/api/v2/shared_sources/owned?machineIdentifier=939431e8fce3a055c59c1761a3f51bc91ba2022f
Sep 24, 2020 20:43:07.752 [0x7effe1cd7700] ERROR - Error issuing curl_easy_perform(handle): 28
Sep 24, 2020 20:43:07.752 [0x7effe1cd7700] DEBUG - HTTP simulating 408 after curl timeout
Sep 24, 2020 20:43:07.862 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:07.959 [0x7f0071aad700] DEBUG - HTTP 200 response from GET https://plex.tv/api/v2/shared_sources/owned?machineIdentifier=939431e8fce3a055c59c1761a3f51bc91ba2022f
Sep 24, 2020 20:43:07.960 [0x7f0071aad700] DEBUG - HTTP requesting GET https://plex.tv/api/v2/server/access_tokens?auth_token=xxxxxxxxxxxxxxxxxxxx&includeProfiles=1&includeProviders=1
Sep 24, 2020 20:43:08.500 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:08.500 [0x7f004ab7d700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET 

it is screaming .

Sep 24, 2020 20:43:25.649 [0x7f00724a7700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /media/providers (32 live) GZIP 0ms 3854 bytes (pipelined: 43)
Sep 24, 2020 20:43:25.671 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert bad certificate
Sep 24, 2020 20:43:26.886 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:27.047 [0x7f00724a7700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:27.047 [0x7f004b447700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/bandwidth?timespan=6 (33 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:27.047 [0x7f00724a7700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/bandwidth?timespan=6 (33 live) GZIP 0ms 993 bytes (pipelined: 44)
Sep 24, 2020 20:43:28.080 [0x7f00724a7700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:28.080 [0x7f004b447700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/resources?timespan=6 (32 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:28.081 [0x7f00724a7700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/resources?timespan=6 (32 live) GZIP 0ms 601 bytes (pipelined: 45)
Sep 24, 2020 20:43:28.343 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:29.114 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:29.114 [0x7f004b447700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/bandwidth?timespan=6 (32 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:29.115 [0x7f00721b9700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/bandwidth?timespan=6 (32 live) GZIP 0ms 1014 bytes (pipelined: 46)
Sep 24, 2020 20:43:29.935 [0x7f00724a7700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:30.579 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:32.149 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert bad certificate
Sep 24, 2020 20:43:32.750 [0x7f00724a7700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:32.750 [0x7f004ab7d700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /media/providers (31 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:32.751 [0x7f00724a7700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /media/providers (31 live) GZIP 0ms 3854 bytes (pipelined: 47)
Sep 24, 2020 20:43:32.784 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert bad certificate
Sep 24, 2020 20:43:32.879 [0x7f00724a7700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:33.237 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:33.237 [0x7f004b447700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/bandwidth?timespan=6 (32 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:33.238 [0x7f00721b9700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/bandwidth?timespan=6 (32 live) GZIP 0ms 1022 bytes (pipelined: 48)
Sep 24, 2020 20:43:33.317 [0x7f00724a7700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:33.897 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:34.263 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:34.263 [0x7f004ab7d700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/resources?timespan=6 (34 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:34.263 [0x7f00721b9700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/resources?timespan=6 (34 live) GZIP 0ms 614 bytes (pipelined: 49)
Sep 24, 2020 20:43:34.822 [0x7f00721b9700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:34.823 [0x7f00724a7700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown
Sep 24, 2020 20:43:35.306 [0x7f00721b9700] DEBUG - Auth: authenticated user 1 as madfusker
Sep 24, 2020 20:43:35.306 [0x7f004ab7d700] DEBUG - Request: [192.168.1.3:56098 (Subnet)] GET /statistics/bandwidth?timespan=6 (35 live) GZIP Signed-in Token (madfusker)
Sep 24, 2020 20:43:35.307 [0x7f00721b9700] DEBUG - Completed: [192.168.1.3:56098] 200 GET /statistics/bandwidth?timespan=6 (35 live) GZIP 0ms 1035 bytes (pipelined: 50)
Sep 24, 2020 20:43:36.833 [0x7f00724a7700] DEBUG - CERT: incomplete TLS handshake: sslv3 alert certificate unknown

Is this your certificate ?

Nope, no certs installed. This is a freshly initialized NAS just yesterday, and all I have done to it is install a SSD and Plex Server app. I guess I also installed a newer version of FFMEG hoping that would fix my problem, but it didn’t.

I have 2 NAS here, and I am trying to determine which one to keep. The TS-877 is powerful but no hardware transcode, while the 872XT is less powerful overall but it has incredible hardware transcoding for Plex using QuickSync. I want to keep this 872XT, but transcode has to work vs powering through it with the TS-877 Ryzen 7 with 16 cores. Without QuickSync the 872XT doesn’t work well for 4K content going down to lower res over slow connections.

Is this TLS handshake something goofy between the server and the browser trying to play the file? I believe I was using chrome to play the file and firefox to watch the stats. Appreciate the help!

It could be because nothing is setup for outside connection yet. I haven’t setup anything given I am only testing locally for performance to make a decision. I see it now screaming in the logs.

Ok. that explains a lot.

Plex really needs those outside connections to get a proper cert. The preloaded cert will cause the same errors I’m seeing if not updated (connected to internet at PMS startup).

None of the Ryzens have hardware transcoding because there is no MESA support yet. It’s hoping Engineering can find the time but they’ve not given any indications

Any other ideas to check on the transcoding? Something changed in the implementation, but the versions from Plex base app the the latest stable are pretty wide to know what it could be.

@ChuckPa Take a look at these logs starting at 9/25 @ timecode 1:47:00. This is a docker install that was in production on the 877 and I just moved the drives over to the 872XT stratight-away. It should have cleaner logs and results are the same with no hw transcoder found. When I hit play it started in direct stream, so I forced it to 720p or something lower to force the transcode. It looks like it’s just not seeing the hardware.

Codecs: hardware transcoding: testing API nvdec
Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: Unknown error occurred
Codecs: hardware transcoding: testing API vaapi
TPU: hardware transcoding: enabled, but no hardware decode accelerator found
TPU: hardware transcoding: final decoder: , final encoder:

@mafuzker

You’re using a container

Sep 25, 2020 01:25:00.239 [0x7f862d4ae700] INFO - Plex Media Server v1.20.1.3252-a78fef9a9 - Docker Docker Container (LinuxServer.io) x86_64 - build: linux-x86_64 debian - GMT -05:00
Sep 25, 2020 01:25:00.240 [0x7f862d4ae700] INFO - Linux version: 4.14.24-qnap, language: en-US
Sep 25, 2020 01:25:00.240 [0x7f862d4ae700] INFO - Processor Intel(R) Core(TM) i5-8400T CPU @ 1.70GHz
Sep 25, 2020 01:25:00.240 [0x7f862d4ae700] INFO - /usr/lib/plexmediaserver/Plex Media Server
Sep 25, 2020 01:25:00.167 [0x7f8636ca3f80] DEBUG - BPQ: [Idle] -> [Starting]

Did you map /dev/dri into the container when created in Container Station?

Hi Chuck, I’m having a similar issue with my QNAP. With HW transcoding disabled, I can transcode from 4k all the way down to 720p with no issues (upgraded from Pentium Gold to i5-9500T) but if I enable HW transcoding it can’t keep up and is constantly buffering.
I tried the Pentium Gold processor with a MSI GTX 1050 TI and couldn’t get it to work so I returned it and bought the i5. Any assistance would be appreciated. What logs can I upload?

@vtdanokim

Responded in your original thread.

1 Like

@ChuckPa,

What would the syntax look like in the container syntax for this line given my two devices I show above in the ls - l? I’ll give it a try. Maybe we can make it work with a container, but I’d also want to make sure we fix it for the standard qpkg as well for everyone else. If you have anything else to try on the qpkg I will put my SSD back in and try it.

It looks like this:

Given the -9xxx CPUs don’t have proper drivers (which make sense given QNAP’s product line), I would go the proper route of getting a supported CPU in it first.

I faced the same thing with the initial TVS-1282 i7-6700 vs i7-7700.

The Intel® Core™ i5 8400T 6-core 1.7 GHz processor is fully supported as shown above with Plex Server v1.16 qpkg, however something has changed in Plex code. The old plex version does absolutely flawless 4K hardware transcode, and the CPU runs at about 5%! Without it the CPU pegs at 99%. I don’t want to be stuck running a very old version of plex to get hw support. There has to be a way to fix the latest qpkg and/or container version.

The difference is the implementation of the iHD driver to support the -9xxx CPUs.

This is why I suggest trying to turn off the iHD driver.
The same problem exists on all J4xxx CPUs (the ASIC and interface are different than J3xxx / -8xxx CPUs)

Is this iHD driver turned off in the preferences.xml file in Plex? Or how is this done in the Plex configuration on plex server?

Thanks for the help.

1 Like

The setting in Preferences.xml tells the transcoder which one to use.

By asserting VaapiDriver="i965" in the preference, we are telling it to use the older, established, driver.

Q29 (above) in the FAQ shows how to set the preference (change) through the GUI.

Specific to Docker:
I was able to finally solve this by passing dri device in docker, and changing the permissions on the /dev/dri. Transcoding now works in the docker. Here is what I did:

  1. chmod -R 777 /dev/dri to change permissions (critical step for use in Docker!)

  2. vim /share/docker/appdata/linuxserver-plex/config/Library/Application\ Support/Plex\ Media\ Server/Preferences.xml (this is my custom location for my docker). add VaapiDriver=“i965” to end of file as ChuckPa suggested.

Thanks a lot of the help @ChuckPa!

Code for my docker:

docker pull linuxserver/plex

docker run --restart unless-stopped -d
–name=“plex”
–restart always
–net=host
–cpus=“6”
-e TZ=“America/Chicago”
-e PLEX_CLAIM=“claim-not.for.real.dhVdBXssnjjZ”
-e VERSION=public
-e PUID=1010 -e PGID=100
-v /share/docker/appdata/linuxserver-plex/config:/config:rw
-v /share/docker/appdata/linuxserver-plex/transcode:/transcode:rw
-v /share/Movies/Movies:/share/Movies/Movies:ro
–device=/dev/dri:/dev/dri
linuxserver/plex

suggestion:

  1. Look at the default group for /dev/dri (render or video)
  2. add the Plex user (PUID 1010 in this case) to that group.

another way, if udev available in the container, is to create a default /lib/udev/rules.d rule like we do for plex.

admin@moesern:/lib/udev/rules.d$ cat 60-fix-plex-hw-transcoding.rules 
SUBSYSTEM=="drm", GROUP="video"
admin@moesern:/lib/udev/rules.d$ 

In this case, on this host, username plex is a member of the video group to access the drm (display rendering manager) subsystem. The normal Plex installer detects the group and writes the appropriate rules file.