+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: Troubleshooting (https://forum.jellyfin.org/f-troubleshooting)
+--- Thread: SOLVED: issue (/t-solved-issue--4805)
issue - fencer - 2024-03-09
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
Quote: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?
RE: issue - Efficient_Good_5784 - 2024-03-09
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.
RE: issue - TheDreadPirate - 2024-03-09
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.
RE: issue - fencer - 2024-03-10
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.
Quote: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
Quote: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.
Quote: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
RE: issue - Efficient_Good_5784 - 2024-03-10
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).
RE: issue - fencer - 2024-03-10
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.
RE: issue - TheDreadPirate - 2024-03-10
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.
RE: issue - fencer - 2024-03-11
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.
RE: issue - TheDreadPirate - 2024-03-11
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.
RE: issue - fencer - 2024-03-11
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.