trickplay hardware accelartion / decoding issue

[eshirvana]

Description of the bug

actually there are 2 issues that I encountered

1. hardware decoding for trickplay fails for some files and I get below error message

2. when hardware decoding is enabled and it can't use hardware acceleration and falls back to software decosing , the cpu usage goes to %100 and I think it doesn't respect process priority ( set to below normal)
   while hardware decoding is not selected cpu usage is at about steady %20 .

hardware acceleration works both for playing media and trickplay except for above cases.

jellyfin settings :
Transcoding : VA-API
VA-API Device: /dev/dri/renderD128
Enable hardware decoding for:

• H264

• MPEG2

• VC1

• VP8

• Enable VPP Tone mapping

• Enable Tone mapping

Reproduction steps

1. enable hardware accelaration
2. enable hardware decoding for trickplay
3. run scheduled task generate trickplay images

What is the current bug behavior?

1. fails on some files with hardware decoding enabled
2. cpu usage goes to 100% when it falls back to software decoding

What is the expected correct behavior?

No failures and cpu should respect the below normal priority

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

10.10.5

Specify the build version

10.10.5 (e8e4ff0ca)

Environment

- OS: rocky linux 9.5
- Linux Kernel:  Linux 5.14.0-503.22.1.el9_5.x86_64
- Virtualization: docker  (linuxserver.io container)
- Clients: web
- Browser: Firefox
- FFmpeg Version: 7.0.2-Jellyfin 
- Playback Method:
- Hardware Acceleration: VA-API
- GPU Model: Intel core i5-4590S
- Plugins:
- Reverse Proxy:
- Base URL:
- Networking:
- Storage:

Jellyfin logs

[2025-01-31 03:00:06.138 +00:00] [INF] [32] Jellyfin.Server.Implementations.Trickplay.TrickplayManager: Creating trickplay files at 320 width, for "/media/movie Bluray-720p.mkv" [ID: e59b72fb-0501-e8c3-af28-abf2699e69a1]
[2025-01-31 03:00:06.138 +00:00] [INF] [32] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: Trickplay generation: "/usr/lib/jellyfin-ffmpeg/ffmpeg -loglevel error -init_hw_device vaapi=va:/dev/dri/renderD128,driver=i965 -hwaccel vaapi -hwaccel_output_format vaapi -noautorotate -i file:\"/media/movie Bluray-720p.mkv\" -noautoscale -an -sn -vf \"fps=0.10000000149011612,setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_vaapi=w=320:h=180:format=nv12:out_range=pc:mode=hq:extra_hw_frames=24\" -threads 1 -c:v mjpeg_vaapi -global_quality:v 91 -fps_mode passthrough -f image2 \"/tmp/jellyfin/1bbe502a201e4a60a934d05d12104170/%08d.jpg\""
[2025-01-31 03:00:06.772 +00:00] [ERR] [29] Jellyfin.Server.Implementations.Trickplay.TrickplayManager: Error creating trickplay images.
System.ArgumentException: Can't create trickplay from 0 images.
   at Jellyfin.Server.Implementations.Trickplay.TrickplayManager.CreateTiles(IReadOnlyList`1 images, Int32 width, TrickplayOptions options, String outputDir)
   at Jellyfin.Server.Implementations.Trickplay.TrickplayManager.RefreshTrickplayDataInternal(Video video, Boolean replace, Int32 width, TrickplayOptions options, LibraryOptions libraryOptions, CancellationToken cancellationToken)

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

[gnattu]

Fallback to software will happen for formats you did not enable acceleration for and goes to 100% is intended behavior. Below normal does not prevent it to use all cores when there is no other processing competing for resources.

For the specific failed files, are these files really supported by your hardware in first place? (e.g, if you play that file and lower the bitrate limit to force transcoding, does that file even play?)

[eshirvana]

Fallback to software will happen for formats you did not enable acceleration for and goes to 100% is intended behavior. Below normal does not prevent it to use all cores when there is no other processing competing for resources.

Thank you for the reply, then how come when hardware decoding is not enabled cpu usage is about 20%? and not %100?

For the specific failed files, are these files really supported by your hardware in first place? (e.g, if you play that file and lower the bitrate limit to force transcoding, does that file even play?)

good point , actually I just noticed that trickplay has generated the images for these failed ones , so maybe I get these logs when hwaccl fails and it falls into software decoding anyway? I don't have any other logs related to it though
interestingly I am able to play that file with hw acceleration with lower bitrate so seems like trickplay can't use hardware decoding for some reason.

/usr/lib/jellyfin-ffmpeg/ffmpeg -analyzeduration 200M -probesize 1G -ss 00:03:48.000 -noaccurate_seek -f matroska -init_hw_device vaapi=va:/dev/dri/renderD128,driver=i965 **-hwaccel** vaapi -hwaccel_output_format vaapi -noautorotate -i file:"/media2/data/media/movie WEBDL-2160p.mkv" -noautoscale -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_vaapi -rc_mode CBR -b:v 2616000 -maxrate 2616000 -bufsize 5232000 -profile:v:0 main -level 51 -sei -a53_cc -force_key_frames:0 "expr:gte(t,n_forced*3)" -vf "setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_vaapi=w=1920:h=1080:format=nv12:extra_hw_frames=24" -codec:a:0 libfdk_aac -ac 2 -ab 256000 -af "volume=2" -copyts -avoid_negative_ts disabled -max_muxing_queue_size 2048 -f hls -max_delay 5000000 -hls_time 3 -hls_segment_type fmp4 -hls_fmp4_init_filename "9f77453f2edd02999d4f1b393ec8aff8-1.mp4" -start_number 76 -hls_segment_filename "/config/cache/transcodes/9f77453f2edd02999d4f1b393ec8aff8%d.mp4" -hls_playlist_type vod -hls_list_size 0 -y "/config/cache/transcodes/9f77453f2edd02999d4f1b393ec8aff8.m3u8"


ffmpeg version 7.0.2-Jellyfin Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04)
  configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-ptx-compression --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto=auto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-opencl --enable-libdrm --enable-libxml2 --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libharfbuzz --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libsvtav1 --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-vaapi --enable-amf --enable-libvpl --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
  libavutil      59.  8.100 / 59.  8.100
  libavcodec     61.  3.100 / 61.  3.100
  libavformat    61.  1.100 / 61.  1.100
  libavdevice    61.  1.100 / 61.  1.100
  libavfilter    10.  1.100 / 10.  1.100
  libswscale      8.  1.100 /  8.  1.100
  libswresample   5.  1.100 /  5.  1.100
  libpostproc    58.  1.100 / 58.  1.100
Input #0, matroska,webm, from 'file:/media2/data/media/movie WEBDL-2160p.mkv':
  Metadata:
    title           : movie UHD 4K Upscaled x264 AC3 Soup
    encoder         : libebml v0.7.8 + libmatroska v0.8.1
    creation_time   : 2016-02-16T04:21:35.000000Z
  Duration: 02:45:22.94, start: 0.000000, bitrate: 12770 kb/s
...

[gnattu]

Well it looks like the mjpeg encoder implementation on your hardware (or its driver) is not quite good, but that is expected to have hardware acceleration quirks on older platforms. My suggestion is to just disable hardware decoder and encoder for trickplay and enable the keyframe only option. That will be the fastest option on your system. Trust me, on your system, hardware "acceleration" for trickplay is likely to slow things down instead of speed it up. You can have a try with a smaller sized test library and check if that is really the case. On older hardware platform, the acceleration quirks is usually out of our control due to complicated reasons, especially the vendor choose to abandon support for such old platform.

[eshirvana]

that's true. enabling mjpeg encoding will cause failures all together on my machine , I knew that. but since it was working for most of my files except couple of them I thought It might be a bug or some config issues...
thank you anyways

[felix920506]

Closing this as it is not a bug with Jellyfin