Multiple transcodes after seeking causes stuttering/buffering

[kelnos]

Describe the bug

I'm running Jellyfin on a Raspberry Pi 4. I've set up Jellyfin to use the OpenMAX HWA for encoding for H264 (the Pi 4 does not have any HWA decoding available). When I start casting a video to my TV, playback is fine and smooth. There is one transcode running in the background.

If I seek forward to another part of the video, Jellyfin starts a second transcode process that starts at the seek-to point. However, the Pi 4 cannot encode two H264 streams simultaneously in realtime, so, after seeking, the video will play ok for a few seconds, then pause for a few seconds, play for a few seconds, and so on.

I've tried enabling the "Throttle Transcodes" option in the Jellyfin transcoding configuration, but this doesn't change anything.

If I ssh into the RPi and run kill -STOP $PID_OF_OTHER_FFMPEG, I can get smooth streaming performance, but of course this isn't something I should have to do; at any rate, a few minutes after doing this, playback fails and stops completely; I assume Jellyfin gets upset that it can't communicate with the main ffmpeg process, or something.

If I stop everything, on an otherwise-idle system, and run the same ffmpeg command Jellyfin uses, I note that ffmpeg is only able to encode at around 1.4x or so of real-time speed, which supports the idea that it cannot transcode two streams simultaneously in real-time.

To Reproduce

1. Enable HWA encoding on a Raspberry Pi 4 running Jellyfin
2. Use an app (I used the Android app, but I imagine the behavior will be the same with others) to start casting to a Chromecast.
3. Immediately seek forward in the video by 10 minutes or so.
4. Playback continues at the expected location, but every few seconds playback will pause for buffering.

Expected behavior

Playback should be smooth after seeking.

I understand why Jellyfin continues the "main" transcode process after seeking, but this just isn't ever going to work properly on some hardware, so ideally there should be a way to disable that behavior, or Jellyfin should be able to drop the priority & thread count of the "non foreground" transcode so the "foreground" transcode gets as much CPU time as it needs.

Additionally, I would expect Jellyfin to just not transcode at all when the target device supports the content being played, which I believe is the case for the file in question.

Logs

No particularly relevant logs, but this shows the multiple transcodes running:

$ ps ax|grep ffmpeg
26964 ?        Rl    14:15 /usr/lib/jellyfin-ffmpeg/ffmpeg -i file:/path/to/some/video.mkv -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_omx -force_key_frames expr:gte(t,n_forced*5) -vf scale=trunc(min(max(iw\,ih*dar)\,1920)/2)*2:trunc(ow/dar/2)*2 -copyts -avoid_negative_ts disabled -start_at_zero -b:v 10360000 -maxrate 10360000 -bufsize 20720000 -vsync -1 -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 copy -y /var/lib/jellyfin/transcoding-temp/3e42065231dfb44d07fc2a2b7705a711.mkv
27847 ?        Rl    10:11 /usr/lib/jellyfin-ffmpeg/ffmpeg -ss 01:18:18.054 -i file:/path/to/some/video.mkv -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_omx -force_key_frames expr:gte(t,n_forced*5) -vf scale=trunc(min(max(iw\,ih*dar)\,1920)/2)*2:trunc(ow/dar/2)*2 -copyts -avoid_negative_ts disabled -start_at_zero -b:v 10360000 -maxrate 10360000 -bufsize 20720000 -vsync -1 -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 copy -y /var/lib/jellyfin/transcoding-temp/f1a381d261bb38a375db214d8cde353f.mkv

Screenshots n/a

System (please complete the following information):

• OS: Raspbian buster
• Browser: n/a
• Jellyfin Version: 10.5.5 (from Debian packages)
• Cast client: Cromecast Ultra, cast initiated from Android app

Additional context

(Context included in bug description)

[neopc10]

Can you try this with the nightly/unstable/CAF chromecast client accessible from the user playback settings please? I believe this is addressed by that.

[kelnos]

I am so sorry for never getting back to this. Has the code from when you last posted been promoted to stable? If so, unfortunately I still see the issue today, with jellyfin 10.8.10. Looks like the only other available option right now is "Unstable"; I can give that a try if you think that will help.

Edit: just a note, in case it matters: in the intervening time I've moved my Jellyfin install from The RasPi4 over to an old Intel Mac Mini running Debian. It's using VAAPI for hwaccel, but given the age of the hardware (~2012) it can only do H264 and VC1. Even when hwaccel is being used, two simultaneous transcodes (one of them "stale" after seeking) can cause video stuttering.