HDR Tone Mapping not compatible with HW Accelerated transcoding anymore (DS920+)

I just got it. Thank you.

Just had chance to test

Using the sample you provided

  1. With tonemapping enabled. (hable)

  2. With tonemapping disabled.

Correct?

First question.. Are you seeking into the playback or are you letting it play normally?

Hmm. That looks perfect. So I wonder if that is good news or bad news for me :sweat_smile:

I’m not seeking at all. I just start playback and while it is already running in direct stream mode, I change quality setting. Hable is a tone mapping algorithm right? I wonder where you are able to see that? I only know it from kodi but have never seen such a setting in plex?

I didn’t notice that either until now.

Yes, Hable is the tonemapping algorithm currently being used.

I don’t know why it doesn’t exist for the GeminiLake since it can tonemap.

I’ll ask the engineer and see what can be done for the next update.

As info, when we upgrade FFMPEG, we’ll probably go to BT.2390 which, on a computer monitor, is as good (IMHO) as watching it on the OLED TV.

I just gave it one more try without running tonemap disabled at first - to get a more clean log. The server just started up and I directly started playback. In the log I can already see

Sep 07, 2024 00:30:49.303 [139698336549688] DEBUG - [Req#1bc/Transcode] TPU: hardware transcoding: enabled, but no hardware decode accelerator found

when direct stream is still running. Later, when I just selected transcoding, it actually seems the hardware decoder was just started but then it throws a opencl error.

Sep 07, 2024 00:32:29.291 [139698429147960] DEBUG - [Req#6b1/Transcode] TPU: hardware transcoding: using hardware decode accelerator vaapi
Sep 07, 2024 00:32:29.291 [139698429147960] DEBUG - [Req#6b1/Transcode] TPU: hardware transcoding: zero-copy support present
Sep 07, 2024 00:32:29.291 [139698429147960] DEBUG - [Req#6b1/Transcode] TPU: hardware transcoding: using zero-copy transcoding
...
Sep 07, 2024 00:32:37.195 [139698317622072] ERROR - [Req#6dc/Transcode/f2t9zxniplt0bcz6xmlyk7s9/b5fd2421-2ed5-4074-80e1-9bafdb46c078] [Parsed_tonemap_opencl_3 @ 0x7f5024b47900] Failed to finish command queue: -5.
Sep 07, 2024 00:32:37.701 [139698330278712] ERROR - [Req#706/Transcode/f2t9zxniplt0bcz6xmlyk7s9/b5fd2421-2ed5-4074-80e1-9bafdb46c078] Error while filtering: I/O error
Sep 07, 2024 00:32:37.701 [139698317622072] ERROR - [Req#707/Transcode/f2t9zxniplt0bcz6xmlyk7s9/b5fd2421-2ed5-4074-80e1-9bafdb46c078] Failed to inject frame into filter network: I/O error
Sep 07, 2024 00:32:37.702 [139698343402296] ERROR - [Req#708/Transcode/f2t9zxniplt0bcz6xmlyk7s9/b5fd2421-2ed5-4074-80e1-9bafdb46c078] Error while processing the decoded data for stream #0:0
Sep 07, 2024 00:32:38.249 [139698450037560] DEBUG - Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 642 is 1 (failure)
Sep 07, 2024 00:32:38.250 [139698406046520] DEBUG - Streaming Resource: Changing client to use software decoding

Plex Media Server.log (840.2 KB)

Sep 07, 2024 00:30:27.169 [139698452233016] INFO - Plex Media Server v1.40.5.8921-836b34c27 - Docker Docker Container x86_64 - build: linux-x86_64 debian - GMT 02:00
Sep 07, 2024 00:30:27.170 [139698452233016] INFO - Linux version: 6.6.13+bpo-amd64, language: en-US

You stated 6.9 kernel?
You’re in docker ?

Why to each please ?

PMS in docker can be a ROYAL P.I.T.A
Kernels which I know work are 6.5 and 6.8

6.9 isn’t even on the kernels.org list

https://www.kernel.org/

Ah good catch. I was trying different ones and other stuff and was not aware it is still 6.6 enabled in this try. Perhaps was too tired already.

Debian stable is still 6.1, the general info here was to use at least 6.5. Current Debian bpo was 6.6 back then. Tried it. No luck. I assumed if it was a driver issue, updating Kernel may be worth a try. So when the latest PMS updates released, stating hw tonemap should work now on Gemini Lake too, I also switched to the latest bpo (6.9 back then). I was just trying to cover everything what could be the problem on my side. So I‘m giving 6.5 and 6.8 a try today.

What exactly do you mean by 6.9 isn’t even on the kernel.org list? It was in the stable field when 6.10 was mainline. The latest stable is listed there only I think.

Using docker is a no brainer for me. There is a ton of services running on my server. It is not Plex only.

This isn’t about running “mainline”… it’s about running “vetted” kernels.
That’s the key.

The main distros take a mainline kernel, tweak / fix things, and then vet it as the release kernel.

Those are what you want to run.

As for the 6.9 reference, look here:

I know 6.8 isn’t listed either but Ubuntu has taken custodianship of it for their distros. That’s what we have to go by.

In general, please stay with the distro releases and not kernel.org.
I’ve seen far too many problems by jumping off the beaten path.

Ok so just to sort things out, you actually came up with kernel.org what just confused me a bit. :sweat_smile: I’m not fiddling around with this Kernels at all :wink: I always stick to Debian ones and since their current stable is still 6.1 I go for backports. I think it’s the common way to go isn‘t it?

Unfortunately there seem to be no builds for 6.5 and 6.8 available. Actually all I can do is what we see in this list: https://tracker.debian.org/pkg/linux

Edit: So the sources seem to be available still but I’m not sure if compiling it myself would be the way to go
https://snapshot.debian.org/package/linux/

If Debian doesn’t offer releases of 6.5 or 6.8 then go with what they have.
Remember, there are other drivers which go along with the kernel.
It all has to play together.

When in doubt, I will always defer to those who maintain the distro.

I will test tomorrow and see what happens.

So that would be 6.10 - still the same :confused:

Plex Media Server.log (925.9 KB)

Here I am, on a DS920, with 4.4 kernel, native app because they don’t allow “docker” anymore.

Sep 07, 2024 12:52:59.393 [140265871653688] DEBUG - [Req#204/Transcode] [Universal] Using local file path instead of URL: /volume1/Media/media/uhd/American Sniper (2014) [2160p]/American Sniper (2014) [2160p].mkv
Sep 07, 2024 12:52:59.393 [140265871653688] INFO - [Req#204/Transcode] Preparing driver icr for GPU GeminiLake [UHD Graphics 600]
Sep 07, 2024 12:52:59.393 [140265871653688] DEBUG - [Req#204/Transcode/DriverDL/icr] Skipping download; already exists
Sep 07, 2024 12:52:59.394 [140265871653688] DEBUG - [Req#204/Transcode] Codecs: hardware transcoding: testing API vaapi for device '/dev/dri/renderD128' (GeminiLake [UHD Graphics 600])
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x32315659 -> yuv420p.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x30323449 -> yuv420p.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x3231564e -> nv12.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x32595559 -> yuyv422.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x59565955 -> uyvy422.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x48323234 -> yuv422p.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x58424752 -> rgb0.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x58524742 -> bgr0.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Format 0x30313050 -> p010le.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Created surface 0x4000000.
Sep 07, 2024 12:52:59.395 [140265871653688] DEBUG - [Req#204/Transcode] [FFMPEG] - Direct mapping possible.
Sep 07, 2024 12:52:59.420 [140265871653688] INFO - [Req#204/Transcode] Preparing driver ivd for GPU GeminiLake [UHD Graphics 600]
Sep 07, 2024 12:52:59.420 [140265871653688] DEBUG - [Req#204/Transcode/DriverDL/ivd] Skipping download; already exists
Sep 07, 2024 12:52:59.421 [140265871653688] DEBUG - [Req#204/Transcode] TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi
Sep 07, 2024 12:52:59.421 [140265871653688] DEBUG - [Req#204/Transcode/JobRunner] Job running: EAE_ROOT=/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/tmp/pms-03d3f545-28ce-49bf-a579-c854009356d5/EasyAudioEncoder EnableAIL=0 FFMPEG_EXTERNAL_LIBS='/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex\ Media\ Server/Codecs/b8ae7ab-0d1793f7046f5e4affa102c2-linux-x86_64/' LIBVA_DRIVERS_PATH="/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex Media Server/Cache/va-dri-linux-x86_64" NEOReadDebugKeys=1 OCL_ICD_VENDORS="/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex Media Server/Cache/cl-icds-linux-x86_64" X_PLEX_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cl_cache_dir="/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex Media Server/Cache/Shaders/icr-c1ce521bd2f6ba1389f1f892-linux-x86_64/" "/volume1/@appstore/PlexMediaServer/Plex Transcoder" -codec:0 hevc -hwaccel:0 vaapi -hwaccel_fallback_threshold:0 10 -hwaccel_output_format:0 vaapi -hwaccel_device:0 vaapi -codec:1 truehd_eae -eae_prefix:1 hv4gxps47z6cef1bote9qkms_ -analyzeduration 20000000 -probesize 20000000 -i "/volume1/Media/media/uhd/American Sniper (2014) [2160p]/American Sniper (2014) [2160p].mkv" -filter_complex "[0:0]hwupload[0];[0]scale_vaapi=w=2276:h=1280:format=p010[1];[1]hwmap=derive_device=opencl[2];[2]tonemap_opencl=tonemap=mobius:format=nv12:m=bt709:p=bt709:r=tv[3];[3]hwmap=derive_device=vaapi:reverse=1[4];[4]hwupload[5]" -map "[5]" -metadata:s:0 language=eng -codec:0 h264_vaapi -b:0 14124k -maxrate:0 18833k -bufsize:0 37666k -r:0 23.975999999999999 -force_key_frames:0 "expr:gte(t,n_forced*1)" -filter_complex "[0:1] aresample=async=1:ochl='stereo':rematrix_maxval=0.000000dB:osr=48000[6]" -map "[6]" -metadata:s:1 language=eng -codec:1 aac -b:1 175k -f dash -seg_duration 1 -dash_segment_type mp4 -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 1 -time_delta 0.0625 -manifest_name "http://127.0.0.1:32400/video/:/transcode/session/hv4gxps47z6cef1bote9qkms/c9de15c5-d6ea-4dec-b624-cf35a62674f8/manifest?X-Plex-Http-Pipeline=infinite" -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -init_hw_device vaapi=vaapi:/dev/dri/renderD128,driver=i965 -filter_hw_device vaapi -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/hv4gxps47z6cef1bote9qkms/c9de15c5-d6ea-4dec-b624-cf35a62674f8/progress
Sep 07, 2024 12:52:59.421 [140265871653688] DEBUG - [Req#204/Transcode/JobRunner] In directory: "/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex Media Server/Cache/Transcode/Sessions/plex-transcode-hv4gxps47z6cef1bote9qkms-c9de15c5-d6ea-4dec-b624-cf35a62674f8"
Sep 07, 2024 12:52:59.422 [140265871653688] DEBUG - [Req#204/Transcode/JobRunner] Jobs: Starting child process with pid 20571

Now look very carefully here. This is the singularly most common problem with GLK and GLK Refresh

Sep 07, 2024 12:52:59.854 [140265882200888] DEBUG - [HCl#9c] HTTP requesting GET https://66-109-219-109.c7ddb81a9c1a4b1e94b86448ea0db176.plex.direct:32472/library/sections/5/all?excludeElements=Director%2CProducer%2CWriter%2CRole%2CGenre%2CCountry&excludeFields=summary&type=1&X-Plex-Container-Size=200&X-Plex-Container-Start=0
Sep 07, 2024 12:52:59.911 [140265871653688] ERROR - [Req#217/Transcode/hv4gxps47z6cef1bote9qkms/c9de15c5-d6ea-4dec-b624-cf35a62674f8] [AVHWDeviceContext @ 0x7ff1421b8bc0] No matching devices found.
Sep 07, 2024 12:52:59.975 [140265939938104] DEBUG - [HttpClient/HCl#9c] HTTP/1.1 (0.1s) 200 response from GET https://66-109-219-109.c7ddb81a9c1a4b1e94b86448ea0db176.plex.direct:32472/library/sections/5/all?excludeElements=Director%2CProducer%2CWriter%2CRole%2CGenre%2CCountry&excludeFields=summary&type=1&X-Plex-Container-Size=200&X-Plex-Container-Start=0 (reused)

They (intel) screwed up the driver.

Sometimes it works, sometimes it wont detect the OpenCL.

In this instance, it didn’t.

We have multiple tickets open with them but, given the layoffs, don’t know if/when there will be work performed as this team got hit very hard.

I think I might have been assuming you know the same things I do (you’re pretty technical) but might not so I’ll share what’s important to PMS.

  1. We rely on the kernel for the distro to group the Intel QSV elements together
    – With 6.8 kernel, this is where the first break occurred because the kernel now has a “simple-framebuffer” device which it never had, nor needed, before.

  2. Injection & enumeration of this device as ‘card0’ broke a lot of transcoders for everyone (I’ve checked emby and jellyfin – they’re also broken on these)

  3. This is my AlderLake box. AlderLake-S QSV with Nvidia RTX2000

[chuck@lizum docker.2008]$ ls -la /dev/dri/by-path/
total 0
drwxr-xr-x 2 root root 140 Sep  7 13:36 ./
drwxr-xr-x 3 root root 160 Sep  7 13:18 ../
lrwxrwxrwx 1 root root   8 Sep  7 13:18 pci-0000:00:02.0-card -> ../card1
lrwxrwxrwx 1 root root  13 Sep  7 13:18 pci-0000:00:02.0-render -> ../renderD128
lrwxrwxrwx 1 root root   8 Sep  7 13:36 pci-0000:01:00.0-card -> ../card2
lrwxrwxrwx 1 root root  13 Sep  7 13:18 pci-0000:01:00.0-render -> ../renderD129
lrwxrwxrwx 1 root root   8 Sep  7 13:18 platform-simple-framebuffer.0-card -> ../card0
[chuck@lizum docker.2009]$ 
  1. We’re changing the transcoder to resolve to the PCI addresses rather than the names. You’ll see this work in about the late-1.41 or 1.42.0 timeframe (lot of work). Once completed, we won’t care what names the kernel puts on QSV or other GPU devices.

  2. What’s Intel going to do with older QSV? Probably let it die on the vine.

  3. I bought the new AlderLake (NUC12DCMi9) to replace my aged NUC8i7HVK but, most importantly, I bought a N100 ($169) B-link miniPC 4x4 for mobile platform testing, It’s an AlderLake-N GPU.

While I loathe suggesting it, it might be time to upgrade your machine as I just had to do. I am retired and didn’t like spending $3000 on new hardware

1 Like

Darn it’s unfortunate, just built the DS920+ with all upgrades and purchased all 4 bays worth of storage within the past few months to a year ago. And feeling more and more like an idiot for having purchased the Synology…should have just built a NAS, just wasn’t confident having just started at the time. And was familiar with Synology since I worked with a small business that utilized one.

Warning: This turned out to be full dump of possibilities. Did NOT mean it to be that way. ASK if questions.

Don’t feel bad. Synology was a GOOD name until about 2020.
Around that time, they stopped making good video transcoding “Appliances”.
They started downsizing to “NAS-only” boxes.

It is possible to take your existing drives out of the Syno.
You’ll need to learn how Linux does it but it’s not that hard.

You can get better hardware, (I got a BeeLink N100 box – AlderLake-N CPU)
and with Linux, can get a USB-3 (USB-C works best) enclosure, plug in the Syno drives and use them AS-IS.

I simply mount the drives using the “Linux Raid” commands syno does.
Problem solved.

Maintenance will require support from the GUI or you having read the commands to tell the raid what to do. It’s not that hard.

-OR-

Depending on how much data you have already and how stored,
you might be able to shuffle things around such that you get 2 drive empty

With those two drives, and installing XPENology on a BeeLink N100, you have the DSM environment, where you can setup the raid on the two drives.

Then you plug in the drives one by one as external USB only and COPY the contents into the RAID set.

When done, you ADD that drive to the RAID volume.

Repeat until all drives copied and imported (added) to the RAID volume.

To show you how much Synology matches Linux , except for the names:

  1. All the storage in my DS418
chuck@ds418:~$ df -h
Filesystem                 Size  Used Avail Use% Mounted on
/dev/md0                   2.3G  1.2G  999M  55% /
devtmpfs                   476M     0  476M   0% /dev
tmpfs                      495M   40K  495M   1% /dev/shm
tmpfs                      495M   16M  479M   4% /run
tmpfs                      495M     0  495M   0% /sys/fs/cgroup
tmpfs                      495M  748K  494M   1% /tmp
tmpfs                       99M     0   99M   0% /run/user/196791
/dev/vg1000/lv             7.2T  2.1T  5.2T  29% /volume1
/dev/vg1/volume_2          7.2T  506G  6.7T   7% /volume2

What the RAID sees:

chuck@ds418:~$ cat /proc/mdstat
Personalities : [raid1] 
md2 : active raid1 sdb5[3] sda5[2]
      3902187456 blocks super 1.2 [2/2] [UU]
      
md3 : active raid1 sdc5[2] sdd5[3]
      3896291584 blocks super 1.2 [2/2] [UU]
      
md5 : active raid1 sdb6[0] sda6[1]
      3901103040 blocks super 1.2 [2/2] [UU]
      
md4 : active raid1 sdc6[0] sdd6[1]
      3906998912 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sdb2[0] sdc2[3] sdd2[2] sda2[1]
      2097088 blocks [4/4] [UUUU]
      
md0 : active raid1 sdb1[0] sdd1[3] sdc1[2] sda1[1]
      2490176 blocks [4/4] [UUUU]
      
unused devices: <none>
chuck@ds418:~$ 
  1. What it really looks like to the RAID software
    — OS is on md0
    — Swap is on md1
    — volume1 is on md2 and also md3 (logical volume ‘mapper’)
    — volume2 is on 'md4' and also 'md5 (logical volume mapper)
    (that’s how they do it .. logical volumes are easily expanded by adding drives)

Now look at my big NAS.
Only difference is: Ubuntu Linux and more drives (HDD and SSD)
md0 = OS, md1 = “/home” partition, md2 = VM SSD array, md3 = main HDD storage (110 TB usable)

Personalities : [raid0] [raid10] [raid1] [raid6] [raid5] [raid4] 
md0 : active raid1 sda2[0] sds2[2] sdr2[4] sdt2[3]
      243539968 blocks super 1.2 [4/4] [UUUU]
      
md3 : active raid6 sdj[2] sdi[12] sdh[13] sdg[10] sdl[1] sdm[11] sdf[4] sdo[14] sdk[5] sdp[8] sdn[0] sdq[7]
      117187532800 blocks super 1.2 level 6, 1024k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
      
md1 : active raid10 sdd[0] sde[3] sdc[1] sdb[2]
      976508960 blocks super 1.2 16K chunks 2 near-copies [4/4] [UUUU]
      
md2 : active raid0 nvme1n1[1] nvme0n1[0]
      2000145056 blocks super 1.2 16k chunks
      
unused devices: <none>
[chuck@glockner ~.2000]$ 

So you see, Same as Synology. You can do it.
Several years ago, I pulled out my syno drives and put them into USB enclosures. Started up my workstation and there they were – all the syno files – fully intact

IF you go this route, you can sell the DS920+ . They fetch a darn good price

AND another option:

  1. Buy a $159 Beelink HTCP Alderlake 12
    Amazon.com

  2. Transfer PMS from the Syno to the Beelink ( I will help with that .. it’s trivial)

  3. Run your Beelink as the Plex server (with superb CPU) and the Syno as the NAS (which Synology seems to want us all to do)

Thanks for your intense support and detailed explanation. In fact I‘m already planning to upgrade anyway. Sth like a Intel Gold 8505 or N100. But the bad state of that driver topic actually makes me wonder if I should maybe think about something different than INTEL. I really don’t wanna end up again in that situation :thinking:

Go with the beelink option. Bought one a year ago. Chuck helped me get it all set up. Works perfectly and i also have a 920+ that i ran plex on for many years. The move took a few hours. Setting up all my automated backups etc. took the most time which isn’t a requirement. just getting plex up and able to see the media on the synology was 30 minutes or so.

and everything is fine as long as you dont update to the cutting edge on everything. I haven’t updated ubuntu yet nor plex in the past several months while all of the issues are being sorted. just tracking the threads until all is well. and so many people have that s12pro just for plex so i wouldn’t be worrie that it will eventually not be supported correctly.

Intel’s drivers for the older processors (e.g. GeminiLake , CoffeeLake, and especially CoffeeLake Refresh) are the problem. – anything pre -10xxx CPU

The AlderLake’s are the last stable CPUs before the RaptorLake and MeteorLake debacle (I’ll never buy one of those)

Intel’s massive layoff has had a nice side effect; there’s almost nobody left in that team to do major overhauls and break stuff.

We got PMS updated just before that layoff and are likely going to hold firm for quite some time … possibly cherry-pick bug fixes if/as needed.

My little N100 BeeLink Pro 12 is solid. I cannot complain (except that I loaded proxmox to help those guy. :roll_eyes: lol)

1 Like

But there is only high end cpus affected isn’t it?

no. The lower-end mobile CPUs ( J-series ) are impacted.

The Raptor Lake (-13xxx) and MeteorLake (-14xxx) have problems because of how the chips are made. Internally, the wires are not connected correctly to the pins. They end up burning.

1 Like