SOLVED: Jellyfin buffering... is my hardware acceleration working?

[RitzyMage]

I just noticed you are on 10.8.9, which is why you don't see "delete segments".  That was added in 10.9.

I highly recommend you upgrade to 10.9.10.  At a minimum, 10.8.13.  There were several security vulnerabilities that were patched leading up to 10.8.13.  And the problem you are having may have been a bug that's been resolved in a later release. 

I actually upgraded all packages when I updated the Linux version and am on 10.9.10 now.

 110.9.100.9.1010.9.10now.

Your specs and your Internet connection seem to be up to the task for the media you are serving.

For sure, but I occasionally use the server when traveling and have a less fast internet connection (and also have another user who has a worse connection than I do). This works 95% of the time, but when it does stop, it tends to skip frames instead of lowering the quality, which I assume is because it's not encoding.
010.9.10.9.110.9.10

[TheDreadPirate]

On the client you can manually select a lower bit rate. AFAIK, the client's won't detect that the connection is slow and adjust in real time. This would trigger a transcode, which we got setup properly now.

[RitzyMage]

Here's what I tried:


- Set the "internet quality" on my client to 10 mbps (I think that is the bitrate setting?)
- Changed hardware decoding from "Copy" to "Enabled" on the client and also clicked "Always Force Transcode"
- Clicked "Throttle Transcodes" on the server settings

Still don't see any GPU usage when streaming.

I'm not really sure what else to try, other than maybe trying a different codec (AVI instead of H264?). What do other people use?

[TheDreadPirate]

You should be using Intel Quicksync. VAAPI should still work, but QSV is more performant on Intel GPUs.

I'd have to see your logs to see what is happening. But 10Mbps is well above your video's bit rate. The screenshot you included before showed that the video bitrate was only 1.7Mbps (plus the audio, not shown). So setting the quality to 10Mbps wouldn't trigger a transcode since the video is below that.

But setting "Always force transcode" sounds like it should. I'm looking at the JMP code related to that setting and all it does is not include any information about what the client can direct play. I'm wondering if there is some server side logic that sees that the original video codec is already H264 and ignores that? IDK.

[RitzyMage]

OK some more investigation revealed some things. I figured the way to enforce encoding was to use a codec incompatible with the client, so I encoded a file as H265 and tried viewing it in the firefox client. Lo and behold, GPU usage and files in the transcodes folder! Streaming this was extremely fast and I could even skip around the video with no buffering. 

So what I learned:

• my GPU settings *are* correct
  
• the video will encode if the client does not support the codec
  
• @The Dread Pirate was right and the video was just copying over
  

As for what to do about this... it seems pretty silly to try and encode all of my videos in an incompatable format so they get encoded. Especially since I usually use the Desktop client, which supports all codecs.  But perhaps I should look into the efficiency of different codecs.

[TheDreadPirate]

Transcoding does NOT improve video quality and does not increase responsiveness. You shouldn't be aiming for more transcoding. The goal is to direct play as much as possible. Transcoding allows for client flexibility.

But there are other considerations if you have come limitations. You'd change the codecs if, for example, you're running low on disk space or you have a slow upload speed.

For me, I'm using AV1 because I only have 40Mbps upload, the fastest I can get at the moment. Both my phone and my wife's phones support AV1, and my friend's Roku 4802X supports AV1. So all my remote clients support direct playing my content in the, currently, most efficient codec to minimize the use of my limited upload. All my Android TV devices in my house don't support AV1 (yet) so I'm transcoding a lot of the time on those devices. But those are on LAN so that isn't a concern.

So don't re-encode just to trigger more transcoding for the sake of more transcoding.

[RitzyMage]

So don't re-encode just to trigger more transcoding for the sake of more transcoding.

OK that makes sense! I haven't really seen the buffering since setting this up, but I haven't tested on a slower connection either. I just assumed that transcoding is good when it lowers the bitrate on a slower connection. But I'll mark this issue as resolved. Thanks!

[RitzyMage]

After some more experimentation, I found that the "Always force transcode" option on the client actually *does* work. Not sure what was wrong before.

Although as a note, this will only result in GPU usage at the beginning of a stream. After it's encoded, the GPU will go back to 0.