SOLVED: issue

[fencer]

Hello, I've never been able to get hardware transcoding to work with Jellyfin.

- I'm using the latest version 10.8.13 on a synology ds1019+. Installed through the community apps.
- It has a celeron J3455 CPU, which is capable of hwaccel. I know it definitely can do this because I installed plex using a free 30 day trial. hwaccel worked there out of the box, 4k transcodes used at most 20% CPU.
- Given it's based on linux, I'm using VAAPI. I've tried the other options though.
- below is the ffmpeg log, as far as I can tell it IS using /dev/dri/renderD128 as it's supposed to, but it must be falling back to software,  and single stream transcodes max out the CPU

ffmpeg version 4.4.4-49 Copyright © 2000-2023 the FFmpeg developers
  built with gcc 8.5.0 (GCC)
  configuration: --target-os=linux --cross-prefix=/home/spksrc/ffmpeg4-dsm6-fix/spksrc/toolchain/syno-x64-7.1/work/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- --prefix=/var/packages/ffmpeg/target --extra-cflags=-I/home/spksrc/ffmpeg4-dsm6-fix/spksrc/spk/ffmpeg4/work-x64-7.1/install/var/packages/ffmpeg/target/include --extra-ldflags=-L/home/spksrc/ffmpeg4-dsm6-fix/spksrc/spk/ffmpeg4/work-x64-7.1/install/var/packages/ffmpeg/target/lib --extra-libs='-lxml2 -ldl -lm' --pkg-config=/usr/bin/pkg-config --ranlib=/home/spksrc/ffmpeg4-dsm6-fix/spksrc/toolchain/syno-x64-7.1/work/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ranlib --enable-cross-compile --enable-rpath --enable-pic --enable-shared --enable-gpl --enable-version3 --enable-avresample --disable-debug --disable-static --disable-doc --extra-version=49 --extra-cflags=-DSYNO_VIDEOSTATION --extra-cflags=-fno-if-conversion --extra-cflags=-O3 --extra-cflags=-Wno-deprecated-declarations --x86asmexe=nasm --enable-libcodec2 --enable-libxml2 --enable-demuxer=dash --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libopenjpeg --enable-libmp3lame --enable-libbluray --enable-libspeex --enable-libtheora --enable-libcaca --enable-libdc1394 --enable-libvorbis --enable-libwebp --enable-libzmq --enable-gnutls --enable-libopenh264 --enable-libopus --enable-libsoxr --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librabbitmq --enable-libtwolame --enable-libzvbi --enable-libx264 --enable-libx265 --enable-libvpx --enable-libshine --enable-chromaprint --enable-libdav1d --enable-librist --enable-libzimg --enable-libfdk-aac --enable-nonfree --enable-libaom --enable-libsvtav1 --enable-libsvthevc --arch=x86_64 --enable-vaapi --enable-libmfx --enable-libdrm --enable-libass --enable-frei0r
  libavutil      56. 70.100 / 56. 70.100
  libavcodec    58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter    7.110.100 /  7.110.100
  libavresample  4.  0.  0 /  4.  0.  0
  libswscale      5.  9.100 /  5.  9.100
  libswresample  3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
Guessed Channel Layout for Input Stream #0.1 : 5.1
Input #0, matroska,webm, from 'file:/volume1/movies/thriller/Deep.Cover.1992.1080p.BluRay.DD+5.1.x264-iFT.mkv':
  Metadata:
    title          : Deep.Cover.1992.1080p.BluRay.DD+5.1.x264-iFT
    encoder        : libebml v1.4.2 + libmatroska v1.6.4
    creation_time  : 2021-07-21T17:12:11.000000Z
  Duration: 01:47:48.46, start: 0.000000, bitrate: 20959 kb/s
  Chapters:
    Chapter #0:0: start 0.000000, end 167.292000
      Metadata:
        title          : 1. Opening credits
    Chapter #0:1: start 167.292000, end 293.251000
      Metadata:
        title          : 2. "Cleveland, 1972"
    Chapter #0:2: start 293.251000, end 473.223000
      Metadata:
        title          : 3. "Cincinnati, 20 Years Later"
    Chapter #0:3: start 473.223000, end 634.425000
      Metadata:
        title          : 4. "Los Angeles, Two Weeks Later"
    Chapter #0:4: start 634.425000, end 875.792000
      Metadata:
        title          : 5. "Hollywood, Hollywood"
    Chapter #0:5: start 875.792000, end 1187.853000
      Metadata:
        title          : 6. "We got a problem, David"
    Chapter #0:6: start 1187.853000, end 1343.384000
      Metadata:
        title          : 7. James and his mother
    Chapter #0:7: start 1343.384000, end 1637.094000
      Metadata:
        title          : 8. Interrogation and court
    Chapter #0:8: start 1637.094000, end 1958.290000
      Metadata:
        title          : 9. "Come on, Eddie, tell the truth!"
    Chapter #0:9: start 1958.290000, end 2253.293000
      Metadata:
        title          : 10. "You're a drug dealer! Deal drugs!"
    Chapter #0:10: start 2253.293000, end 2466.964000
      Metadata:
        title          : 11. Betty
    Chapter #0:11: start 2466.964000, end 2813.894000
      Metadata:
        title          : 12. An eye for an eye
    Chapter #0:12: start 2813.894000, end 3297.169000
      Metadata:
        title          : 13. A chemical variant
    Chapter #0:13: start 3297.169000, end 4180.885000
      Metadata:
        title          : 14. The deal goes bad
    Chapter #0:14: start 4180.885000, end 4961.498000
      Metadata:
        title          : 15. Gallegos
    Chapter #0:15: start 4961.498000, end 5244.239000
      Metadata:
        title          : 16. "What's happening, Reverend?"
    Chapter #0:16: start 5244.239000, end 5906.400000
      Metadata:
        title          : 17. Down to the docks
    Chapter #0:17: start 5906.400000, end 6146.182000
      Metadata:
        title          : 18. "Madam Chairman, my assignment was..."
    Chapter #0:18: start 6146.182000, end 6228.597000
      Metadata:
        title          : 19. Blood money
    Chapter #0:19: start 6228.597000, end 6468.462000
      Metadata:
        title          : 20. End credits/"Deep Cover"
  Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1038, SAR 1:1 DAR 320:173, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
    Metadata:
      BPS            : 20318400
      DURATION        : 01:47:48.462000000
      NUMBER_OF_FRAMES: 155088
      NUMBER_OF_BYTES : 16428600098
      _STATISTICS_WRITING_APP: mkvmerge v59.0.0 ('Shining Star') 64-bit
      _STATISTICS_WRITING_DATE_UTC: 2021-07-21 17:12:11
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1, fltp (default)
    Metadata:
      title          : 5.1 Surround Upmix
      BPS            : 640000
      DURATION        : 01:47:34.272000000
      NUMBER_OF_FRAMES: 201696
      NUMBER_OF_BYTES : 516341760
      _STATISTICS_WRITING_APP: mkvmerge v59.0.0 ('Shining Star') 64-bit
      _STATISTICS_WRITING_DATE_UTC: 2021-07-21 17:12:11
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:2(eng): Subtitle: subrip
    Metadata:
      title          : Full .srt
      BPS            : 77
      DURATION        : 01:40:38.199000000
      NUMBER_OF_FRAMES: 1570
      NUMBER_OF_BYTES : 58221
      _STATISTICS_WRITING_APP: mkvmerge v59.0.0 ('Shining Star') 64-bit
      _STATISTICS_WRITING_DATE_UTC: 2021-07-21 17:12:11
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  Stream #0:3(eng): Subtitle: subrip
    Metadata:
      title          : SDH .srt
      BPS            : 88
      DURATION        : 01:45:16.059000000
      NUMBER_OF_FRAMES: 1822
      NUMBER_OF_BYTES : 70238
      _STATISTICS_WRITING_APP: mkvmerge v59.0.0 ('Shining Star') 64-bit
      _STATISTICS_WRITING_DATE_UTC: 2021-07-21 17:12:11
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
  Stream #0:1 -> #0:1 (eac3 (native) -> aac (libfdk_aac))
Press [q] to stop, [?] for help
Output #0, hls, to '/volume1/@appdata/jellyfin/data/transcodes/c0ff8545f357b1276111368de772300d.m3u8':
  Metadata:
    encoder        : Lavf58.76.100
  Stream #0:0: Video: h264 (High), vaapi_vld(tv, bt709, progressive), 1920x1038 [SAR 1:1 DAR 320:173], q=2-31, 7616 kb/s, 23.98 fps, 90k tbn (default)
    Metadata:
      encoder        : Lavc58.134.100 h264_vaapi
  Stream #0:1: Audio: aac, 48000 Hz, stereo, s16, 384 kb/s (default)
    Metadata:
      encoder        : Lavc58.134.100 libfdk_aac

That was a transcode of a 1080 stream to 720 and was pegging the CPU at 92%.

I'm really not sure where to go. I understand if it falls back to software it will say so in the logs. This CPU is capable of hwaccel 4k, as shown in this comptaibility spreadsheet. I've ensured the files I'm trying to test are appropriate. Am I missing something in the logs? Should I install the docker variant instead?

[Efficient_Good_5784]

If you want to, you can try running the official Jellyin Docker image using Synology's Container Manager to see if it works there.

Is your DS1019+ running DSM7? I wrote a guide on how to accomplish this if you would like to follow it.

Just so you know, if you can play videos with HWA enabled, it's not broken. If you play a video (with HWA enabled) and you get a message on screen saying the media can't be played, then HWA is not working.
So from the sound of it, it looks like your HWA is set up correctly.

It's important to understand that using HWA doesn't mean that your CPU will never get any load during a transcode. The GPU can only accelerate the video part of the transcode.

• If there's subs that need to be burned into the video, the CPU will need to do all that work as the GPU can't handle this.
  
• Audio tracks that the client can't handle will be transcoded by the CPU.
  

[TheDreadPirate]

The CPU usage is likely from the audio transcode. It's possible that the Plex client you were using was direct playing the audio and the Jellyfin client you were using wasn't.

[fencer]

Thanks for the responses.

I've disabled subtitles entirely, hopefully disabling them means they are never even loaded and there is never a chance that jellyfin will try to transcode them.

@ Efficient_Good_5784  what you said makes sense, if the video plays at all with hwaccel active it must be using hwaccel, or it would fail to initialise the transcode I don't know why audio transcoding would choke it up so hard though, video playback stutters some on 1080 and chokes entirely on 4k. Audio transcoding should happen at easily 30-40x playback speed. Also looking at another log from ffmpeg, I don't think it is transcoding the audio, the video is still playing back like a powerpoint though.

Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s (default)
    Metadata:
      BPS            : 384000
      DURATION        : 01:45:09.408000000
      NUMBER_OF_FRAMES: 197169
      NUMBER_OF_BYTES : 302851584
      _STATISTICS_WRITING_APP: mkvmerge v63.0.0 ('Everything') 64-bit
      _STATISTICS_WRITING_DATE_UTC: 2022-08-12 04:05:54
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
  Stream #0:0 -> #0:0 (hevc (native) -> h264 (h264_vaapi))
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (libfdk_aac))
Press [q] to stop, [?] for help
Output #0, hls, to '/volume1/@appdata/jellyfin/data/transcodes/d313ea5e16ceaed15e3b368d4d43d1f5.m3u8':
  Metadata:
    encoder        : Lavf58.76.100
  Stream #0:0: Video: h264 (High), vaapi_vld(tv, bt709, progressive), 1280x534 [SAR 512373:513920 DAR 1919:803], q=2-31, 2616 kb/s, 23.98 fps, 90k tbn (default)
    Metadata:
      encoder        : Lavc58.134.100 h264_vaapi
  Stream #0:1: Audio: aac, 48000 Hz, stereo, s16, 384 kb/s (default)
    Metadata:
      encoder        : Lavc58.134.100 libfdk_aac

I've also discovered that enabling hardware DEcoding seems to choke it up even more. Below are the speeds with all the hardware decoding options disabled

frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A speed=  0x   
frame=  15 fps=0.0 q=-0.0 size=N/A time=00:00:00.59 bitrate=N/A speed=0.609x   
frame=  31 fps= 21 q=-0.0 size=N/A time=00:00:01.40 bitrate=N/A speed=0.95x   
frame=  50 fps= 25 q=-0.0 size=N/A time=00:00:02.06 bitrate=N/A speed=1.04x   
frame=  65 fps= 26 q=-0.0 size=N/A time=00:00:03.00 bitrate=N/A speed=1.21x   
frame=  84 fps= 28 q=-0.0 size=N/A time=00:00:03.66 bitrate=N/A speed=1.22x   
frame=  102 fps= 29 q=-0.0 size=N/A time=00:00:04.30 bitrate=N/A speed=1.23x   
frame=  117 fps= 29 q=-0.0 size=N/A time=00:00:05.05 bitrate=N/A speed=1.26x   

Same file, with it enabled.

frame=  307 fps=8.9 q=-0.0 size=N/A time=00:00:00.37 bitrate=N/A speed=0.0108x   
frame=  311 fps=8.8 q=-0.0 size=N/A time=00:00:00.60 bitrate=N/A speed=0.0173x   
frame=  316 fps=8.8 q=-0.0 size=N/A time=00:00:00.82 bitrate=N/A speed=0.023x   
frame=  320 fps=8.8 q=-0.0 size=N/A time=00:00:00.88 bitrate=N/A speed=0.0244x   
frame=  324 fps=8.8 q=-0.0 size=N/A time=00:00:01.14 bitrate=N/A speed=0.031x   
frame=  329 fps=8.8 q=-0.0 size=N/A time=00:00:01.37 bitrate=N/A speed=0.0368x   
frame=  332 fps=8.8 q=-0.0 size=N/A time=00:00:01.63 bitrate=N/A speed=0.0431x   
frame=  338 fps=8.8 q=-0.0 size=N/A time=00:00:01.63 bitrate=N/A speed=0.0425x   

[Efficient_Good_5784]

Have you added a 2nd piece of ram to your Synology NAS? By default, these come with a single stick of ram which causes the CPU to run with a single channel of ram. I added a 2nd stick of ram to my Synology NAS (which means the CPU now runs with dual channel ram) and the transcoding fps improved a bit (like 15fps more on average on 1080p to 1080p transcodes).

If it helps to bring context the the power of the CPUs in Synology units, I have a DS920+. The DS920+ has an Intel Celeron J4125 which is 4 years old at this point. You can see Intel's spec for it here.

When Jellyfin HWA transcodes a 1080p stream (with around ~3Mbps bitrate) to 1080p on the DS920+, the J4125 CPU utilization jumps to around 25%-40%.
I built a new server for Jellyfin that uses the AMD 5600G CPU, and it uses twice as much watts than my DS920+. But when the 5600G HWA transcodes the same videos as on the DS920+, the CPU utilization is only around ~5%-10%.

Your Synology unit (DS1019+) has an older CPU with lower specs than the one in the DS920+. See here for the Intel Celeron J3455 specs.
This CPU is 7 years old now. Intel even lists a recommended selling price of $31USD (~$47AUD) on their spec listings for it.

The point here is that Synology (and most other pre-made NAS brands) focus on keeping the NAS boxes to a minimum with power usage. People buying these things generally want it to use as little power as possible. So these "underpowered" CPUs are used.
These CPUs do fine with basic NAS file storage usage, but not so much with transcoding video (especially with high-bitrate video).

I would check if you have any background tasks running on your Synology unit at the same time that you're transcoding. Like if you have any scrubbing going on or another application doing something else that might slow down the system.
Otherwise, having a high CPU utilization % with the J3455 while HWA transcoding seems normal (maybe not 95% usage as with your case however).

[fencer]

Yeah I appreciate it's an old CPU and was not a superstar when it launched either. I have got 16GB of ram, upgraded from the standard 8GB. I'm very confident that neither of those things are the bottleneck though, as I said I used a 1 month free plex trial (promo code ASUSTOR-PLEX30 by the way). The hardware transcoding through Plex did work. A 61mbps 4k stream could be transcoded down to 720p @ 4mbps using 20% or so CPU, which is expected as the CPU should be able comfortably transcode 3-4 4k streams at once give it's an Intel chip with iGP quicksync etc. It's quite impressive how much the hardware acceleration allows these old cheap chips to punch upwards really.

Looking at Plex's less user helpful transcoding logs, it appears to have roughly the same parameters. I believe Plex uses their own version of ffmpeg like Jellyfin does. So I have to conclude this is either a bug in Jellyfin, or much more likely, misconfiguration in my own setup.

I was wrong about audio for sure as looking into it further, down mixing is apparently a bit more resource intensive. I wouldn't expect it to grind to a complete halt though. The fact that hardware decoding causes the transcoding rate to crater is also very odd.

To be honest it's not the end of the world if I can't this working as software encoding at 1080 and below for one stream works. I don't really want to watch a beautiful high quality 70mbps 4k HDR masterpiece transcoded down to 480p SDR using inflight wifi anyway :P I'm not a big fan of Plex either so I wouldn't want to purchase their service.

[TheDreadPirate]

If possible could you switch from the community app, which is using a very old ffmpeg version, to the linuxserver.io docker image? And add the Intel OpenCL mod to the docker config. I'm wondering if the community app's ffmpeg version is just not new enough.

[fencer]

That did it mate! I initially tried pointing jellyfin-community to the latest ffmpeg but ended up going with docker it was too much hassle. Unfortunately the inbuilt Synology docker manager is pretty slim so after getting portainer working I was able to have jellyfin/jellyfin:latest up and running with the correct devices passed through. Transcoding works. Some tonemapping settings are causing it to break but with those disabled it works, I'll dig a bit deeper there and report back on anything I find. I feel like I've never had a totally smooth experience with these Synology community apps. I might just have to bite the bullet and shift it all to docker. Thank you both for your help.

[TheDreadPirate]

Ah. I had suggested the Linuxserver.io image because the official Jellyfin/Jellyfin image has a new Intel OpenCL driver package that deprecated support for Linux kernel 4.4.x, which is what most Synology NASes are still running.

IIRC, the LSIO image with their OpenCL mod still has support for Linux kernel 4.4.

[fencer]

I didn't even look at the ffmpeg version. I had assumed a few things. The community package was the latest Jellyfin release, so I assumed it would have the most recent version of ffmpeg. And that Jellyfin only used the customised Jellyfin-ffmpeg, so I wouldn't be able to use the latest build of ffmpeg if I wanted anyway. As it stand hwaccel iss working despite this device being on kernel 4.4.302.