Jellyfin Forum
Jellyfin FFMPEG isn't using the correct number of threads - Printable Version

+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: Troubleshooting (https://forum.jellyfin.org/f-troubleshooting)
+--- Thread: Jellyfin FFMPEG isn't using the correct number of threads (/t-jellyfin-ffmpeg-isn-t-using-the-correct-number-of-threads)



Jellyfin FFMPEG isn't using the correct number of threads - khatharsis - 2024-11-15

Exactly what the title says. I have 8 cores, and I want to limit jellyfin's usage to 2 or 4 cores. However, even though jellyfin-ffmpeg *does* have the -threads 2 option in the cmdline, it's using all 8 of my cores Confused-face
I've attached a screen to show I'm not saying bollocs.

Here's the full cmdline for the jellyfin-ffmpeg command, idk why it's missing spaces, but it isn't supposed to.
Code:
/usr/lib/jellyfin-ffmpeg/ffmpeg-analyzeduration200M-probesize1G-ss00:10:09.000-ifile:/<path to file>.mkv-map_metadata-1-map_chapters-1-threads2-map0:0-map0:1-codec:v:0libx265-tag:v:0hvc1-presetveryfast-crf28-maxrate3371143-bufsize6742286-profile:v:0main-x265-params:0subme=3:me
range=25:rc-lookahead=10:me=star:ctu=32:max-tu-size=32:min-cu-size=16:rskip=2:rskip-edge-threshold=2:no-sao=1:no-strong-intra-smoothing=1:no-scenecut=1:no-open-gop=1:no-info=1-force_key_fra
mes:0expr:gte(t,n_forced*3)-vfsetparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale=trunc(min(max(iw\,ih*a)\,min(1920\,1080*a))/2)*2:trunc(min(max(iw/a\,ih)\,min(1920/a\,10
80))/2)*2,format=yuv420p,subtitles=f='/var/lib/jellyfin/data/subtitles/b/bec59084-f9b2-2704-9687-a11115dd4306.ass':fontsdir='/var/cache/jellyfin/attachments/c25d55ed928b1cd3c370390b0903e3c6
'-start_at_zero-codec:a:0copy-copyts-avoid_negative_tsdisabled-max_muxing_queue_size2048-fhls-max_delay5000000-hls_time3-hls_segment_typempegts-start_number203-hls_segment_filename/var/lib/
jellyfin/transcodes/e04f3513ae64d140f097c68c8067a981%d.ts-hls_playlist_typevod-hls_list_size0-y/var/lib/jellyfin/transcodes/e04f3513ae64d140f097c68c8067a981.m3u8



RE: Jellyfin FFMPEG isn't using the correct number of threads - TheDreadPirate - 2024-11-15

libx264 and libx265 don't encode the same way.  When threads is set with libx264 each frame is sliced into that many threads.  libx265 does not work by slicing frames.  They have a concept called WPP.

https://x265.readthedocs.io/en/stable/threading.html#wavefront-parallel-processing

When threads is set in libx265, each WPP is assigned that many threads.  Depending on the resolution of the video, the number of WPPs can vary.  In my testing, a 480i video had 8 WPPs and a 4K video had 34 WPPs.  So setting threads to 1 on that 480i video would result in 8 threads.  One per WPP.  And 34 threads for the 4K video.

Quote:chris@rat-trap: /media/storage2/rips/wip/Dune$ ffmpeg -y -init_hw_device vaapi=va:,driver=iHD,kernel_driver=i915 -hide_banner -stats -fflags +genpts+igndts -loglevel error -i Dune_t00.mkv -map_chapters 0 -map 0:v -c:v libx265 -threads 1 -c:a libopus -vbr on -compression_level 10 -application audio -map 0:a:1 -map 0:a:3 -map 0:a:0 -map 0:a:2 -c:s copy -map 0:s:0 -map 0:s:1 -map '0:t?' -disposition:s 0 -max_muxing_queue_size 2048 -max_interleave_delta 0 -avoid_negative_ts disabled test.mkv                                                                                                                                                         
x265 [info]: HEVC encoder version 3.5+1-f0c1022b6
x265 [info]: build info [Linux][GCC 13.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Turning on repeat-headers for HDR compatibility
x265 [info]: Main 10 profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features      : 1 / wpp(34 rows)    ##### THIS HERE #####
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge        : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb      : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=8 deblock sao
frame=  765 fps=6.1 q=30.8 Lsize=    8188KiB time=00:00:10.90 bitrate=6149.7kbits/s speed=0.0874x   
x265 [info]: frame I:      4, Avg QP:29.86  kb/s: 5665.92
x265 [info]: frame P:    220, Avg QP:31.43  kb/s: 1921.49
x265 [info]: frame B:    541, Avg QP:34.65  kb/s: 452.46 
x265 [info]: Weighted P-Frames: Y:6.8% UV:2.7%
x265 [info]: consecutive B-frames: 14.7% 15.6% 12.9% 26.8% 29.9%

encoded 765 frames in 124.58s (6.14 fps), 902.18 kb/s, Avg QP:33.70



RE: Jellyfin FFMPEG isn't using the correct number of threads - khatharsis - 2024-11-16

Oh wow ! Thanks for the answer !
That seems really arbitrary though ? That means that trying to transcode a 4k video on a 48 threads machine would yield better results with threads=1 than threads=2, since having more threads than your system has will actually slow things down...
Would you know of any way to solve this ? I don't want my server to get overloaded every time I have to transcode some subtitles... I was thinking of using a docker rather than going bare-metal, but I've heard it leads to some issues if I ever want to use GPUs later down the line


RE: Jellyfin FFMPEG isn't using the correct number of threads - TheDreadPirate - 2024-11-16

Using Docker with GPUs does not cause "problems". It just takes a little extra configuration.

The temporary solution is to disable HEVC encoding for transcodes and only allow H264 encoding so that you get the system load you're expecting.

The long time solution is to get a GPU to handle transcoding.