Micro stutters / single frame drops

[podonnell]

I have been getting some very small frame drops, but they are consistent. I have tested with multiple devices, and both were using directstream without any transcode.

When there is a panning shot it is very clear that a single frame or two get dropped, or there's a quick hitch and the frames stick longer than they should.

There is no other activity on the server at this time, and I am within a gigabit network.

I have used an Android TV with Jellyfin app, an LG TV with Android app, and my PC using the web player. All of them experience the issue.

During a test I just ran to create some logs, I found there were about 15 different directstream entries, perhaps due to me jumping around?
Nevertheless, here is the last one, which I did have two instances where I saw frame stutter.

https://pastebin.com/qz4qNeCf

Thank you for any assistance!

[TheDreadPirate]

Are all your devices 4K + HDR10 capable?

[podonnell]

Are all your devices 4K + HDR10 capable?

Yes, both of them are and I checked player info to confirm they were displaying as such. Picture looks great other than the stutter.

[Efficient_Good_5784]

Have you actually seen the frame-drop counter increase in the playback info, or are you going by eye?

Could you try playing the same video locally on a PC using something like VLC? VLC can also display if there are frame drops and how much of those have happened.
This could help rule out the video from being the issue. If the same thing happens with VLC, good chance it's the video.

Though looking at your log, I see it's a BD remux that you're trying to play. How are your clients connected to the server? Are they all local or remote? Do they all have a wired connection to the server? I'm willing to bet it may be due to the large amount of data being handled at once. Maybe the frame drops happen when the network connection temporarily slows down enough to cause the issue. Can you also try re-encoding the video to a lower bitrate? You can use a program like Handbrake to re-encode the video to lower its bitrate.

[podonnell]

Have you actually seen the frame-drop counter increase in the playback info, or are you going by eye?

I actually just just saw they had that counter when troubleshooting another issue. I went back to make sure I wasn't seeing things, and I do in fact get +1 dropped frames every six seconds or so. So about ten per minute.

Could you try playing the same video locally on a PC using something like VLC? VLC can also display if there are frame drops and how much of those have happened.
This could help rule out the video from being the issue. If the same thing happens with VLC, good chance it's the video.

Great idea. Just tried this (using MPC-BE) over my local network. I just opened the movie file locally -- on the same PC I was playing it through to test moments ago. No dropped frames.

Though looking at your log, I see it's a BD remux that you're trying to play. How are your clients connected to the server? Are they all local or remote? Do they all have a wired connection to the server? I'm willing to bet it may be due to the large amount of data being handled at once. Maybe the frame drops happen when the network connection temporarily slows down enough to cause the issue. Can you also try re-encoding the video to a lower bitrate? You can use a program like Handbrake to re-encode the video to lower its bitrate.

In my tests, both client and server are within the same gigabit network. They both have 1.0 Gbps cards.
This gave me an idea, and instead of re-encoding it, I tried playing with the quality settings -- Anything that is directstream (60 Mbps and up) has the issue. When I go below that, it causes it to transcode due to the video file being a higher bitrate than I'm allowing being streamed. Does this help narrow anything down?

[TheDreadPirate]

It may not be a network issue, per se. But high bit rate video does require more compute power to decode for the client device.

[podonnell]

It may not be a network issue, per se.  But high bit rate video does require more compute power to decode for the client device.

Would this be CPU bound? Any other setting I can change to test this outside of replacing hardware?

[TheDreadPirate]

This would be the CPU/GPU/SoC on the client, not server.

Its extremely hard to find documentation for the SoCs built into Firesticks, Chromecasts, and Rokus, etc., but a lot of them will have a max bit rate they support decoding.

I almost guarantee if you recompressed your remuxes to a lower bit rate this problem goes away. The fact that it plays fine when you lower the "quality" on the client to a lower bit rate, triggering transcoding to that lower bit rate, kind of confirms that.

[podonnell]

This would be the CPU/GPU/SoC on the client, not server.

Odd. My PC is what is experiencing the issue, which is equipped with a 3080 GPU and a 10700k CPU, 32GB of RAM. Playing these videos directly on this device, no issue is present.
This happens in the Chrome player as well as the MPV Shim.

Its extremely hard to find documentation for the SoCs built into Firesticks, Chromecasts, and Rokus, etc., but a lot of them will have a max bit rate they support decoding.

I almost guarantee if you recompressed your remuxes to a lower bit rate this problem goes away.  The fact that it plays fine when you lower the "quality" on the client to a lower bit rate, triggering transcoding to that lower bit rate, kind of confirms that.

I've tested as low as 40 Mbps for a 1080p video, and the issue persists there. The issue seems to only go away when there is any transcoding involved.

[TheDreadPirate]

Let's try repackaging one of your files.

Code:

/usr/lib/jellyfin-ffmpeg/ffmpeg -fflags genpts -i "/path/to/video.mkv" -map 0:v -map 0:a -map 0:s -map_chapters 0 -c:v copy -c:a copy -c:s copy outputFile.mkv

This will copy the video/audio/subs unmodified into a new MKV container, new packet time stamps, etc.