Playback stuck after couple of minutes

[bugsyb]

This seems to be a problem related most likely to "pausing" issued by Jellyfin, option:

Throttle Transcodes
When a transcode or remux gets far enough ahead from the current playback position, pause the process so it will consume less resources. This is most useful when watching without seeking often. Turn this off if you experience playback issues.

Logs as presented below, shows that encoding is paused an resumed and it works couple of times and then there's no resume and playback gets stuck. It happens after couple of minutes of playback, not initially.

SSH connection is kept established, there's no connectivity issue, as if playback is stopped or quit, at network layer, within same ssh session, rffmpeg sends all commands (no other ssh session gets established) and encoding gets terminated, within same set of logs. So network connectivity can be excluded.

It purely looks like related to that throttling/pausing which breaks after couple of minutes and it is really good Jellyfin functionality. Using latest Jellyfin amr64 docker image (Digest: 24742feeeec6, linux/arm64/v8, 171.37 MB).

Now, an interesting portion comes, after mangling with settings, disabling VAAPI acceleration and disabling throttling - it worked fine. Re-enabled back both, VAAPI and throttling and it seems to work for last couple of tries.

Any thoughts on how to troubleshoot it further in case if it would happen again?

frame= 6605 fps= 81 q=27.0 size=N/A time=00:04:24.17 bitrate=N/A speed=3.24x    
frame= 6658 fps= 81 q=27.0 size=N/A time=00:04:26.28 bitrate=N/A speed=3.24x    
frame= 6707 fps= 81 q=28.0 size=N/A time=00:04:28.24 bitrate=N/A speed=3.24x    
Transcoding is paused. Press [u] to resume.



frame= 6759 fps= 81 q=26.0 size=N/A time=00:04:30.33 bitrate=N/A speed=3.25x    

[q] command received. Exiting.

[hls @ 0x557f10813c40] Opening '/ram_transcode/5ba1e2011fbd7d15a9dda2faaaf279db377.ts' for writing
[hls @ 0x557f10813c40] Opening '/ram_transcode/5ba1e2011fbd7d15a9dda2faaaf279db378.ts' for writing
frame= 6760 fps= 81 q=-1.0 Lsize=N/A time=00:04:30.40 bitrate=N/A speed=3.24x    
video:78387kB audio:12679kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[libx264 @ 0x557f108141c0] frame I:28    Avg QP:24.36  size: 59950
[libx264 @ 0x557f108141c0] frame P:6732  Avg QP:27.39  size: 11674
[libx264 @ 0x557f108141c0] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 0x557f108141c0] mb P  I16..4: 13.1%  0.0%  0.0%  P16..4: 21.3%  0.0%  0.0%  0.0%  0.0%    skip:65.5%
[libx264 @ 0x557f108141c0] coded y,uvDC,uvAC intra: 12.2% 13.7% 1.3% inter: 5.8% 4.2% 0.0%
[libx264 @ 0x557f108141c0] i16 v,h,dc,p: 37% 21% 20% 22%
[libx264 @ 0x557f108141c0] i8c dc,h,v,p: 56% 16% 21%  6%
[libx264 @ 0x557f108141c0] kb/s:2374.77
==> rffmpeg.log <==
2024-02-19 22:27:23,008 - rffmpeg[31497] - DEBUG - Using SQLite as database.
2024-02-19 22:27:23,065 - rffmpeg[31497] - DEBUG - SQLite connection closed.
2024-02-19 22:27:23,072 - rffmpeg[31497] - INFO - Finished rffmpeg with return code 0

[joshuaboniface]

I'm not actually sure how Jellyfin's throttling works in detail (@nyanmisaka could you comment perhaps?), but it definitely looks like it isn't playing nicely with the ffmpeg over SSH. Perhaps while it pauses the SSH PTY freezes or gets disconnected somehow.

Though, I would also like to understand the usecase a bit. Part of the point of rffmpeg is to offload to something powerful enough that you wouldn't need something like ffmpeg throtting (which is designed to be more "fair" if too many people are transcoding at once), so that seems odd to me and probably why it's never been brought up before. Are you sure you need that functionality?

[nyanmisaka]

When the ffmpeg process is running, jellyfin server pauses it by entering the character p to the STDIN of the ffmpeg process, and enters u or any character to unpause it.

This type of issue will occur if rffmpeg blocks these two characters or the client does not report the correct playback progress to the server (if the transcoding progress is 180 seconds ahead of the playback progress, it will be paused, otherwise continue transcoding).