ffmpeg command-line tools 99%

[tdjf]

Recently I've noticed that some media is pegging this service. My Jellyfin server doesn't have a dedicated video card and in this case I'm viewing the file over the network via nvidia shield (hard wired).

The file I'm playing shows the following under the dashboard:

Transcoding
The video's range type is not supported

Hardware Acceleration is set to none. I've enabled it and selected Intel quicksync as that's the supported CPU I have and while that does drop the CPU to about 38% while continuing to transcode, now I have purple/green video. The files are DV, HDR and 265.

It seems that w/o hardware acceleration it is able to correct/fix the colors but the CPU spikes to 99-100% but enabling hardware acceleration breaks the color/tone mapping?

I understand that the remote/client device doesn't support DV/HDR and that's why it can't direct play, but what's the solution for environments where there is a single server and the clients vary? I don't share with friends/family so I'm not worried about anyone connecting not meeting requirements, but I have at least 5-6 TV setups in my home and while some might be DV/HDR ready, not all are.

Do I need to have multiple formats of each show and watch based on which TV I'm at? Is there another option/more settings that I can toggle to fix the color/tone mapping when transcoding is happening?

Edit- I would like to add that other DV, HDR and 265 files don't have this same behavior and play fine (either direct play or don't spike the CPU) on the same setup where it does currently spike. I'm not sure why that is other than not all DV, HDR and 265 files are the same. Possibly different types of DV and/or HDR?

JF is running on windows 11 and was just updated a couple days ago to the latest version.

Thanks.

[linuxgaming]

To be honest your solution here is to have more CPU power - im running dual 6 core intel cpu's (total of 48 threads) and no GPU, so when transcoding required it's 100% cpu bound (and honestly, i seem to get better general behaviour when a video is fully transcoded rather than direct-play - wish there was a 'transcode everything' option!).

Anyway, when its transcoding a say 10kbit bitstream, it happily consumes 14 threads simultaneously to transcode the film and this means an entire 2hr film is transcoded in about 15mins) - no hardware acceleration.

Ive also run Jellyfin on a single core with 2 threads, and under the same circumstances it will consume 1 whole thread and about 70% of the second thread compute resource, and this leads to a "just in time" transcoding just a few seconds ahead of the viewers "viewing position" through the file.

So unless you have an actual problem with the CPU consumption then just leave it CPU transcoding.

With reference to the "other files that dont have this same behaviour and play fine" - probably smaller file sizes or smaller stream bitrates , and/or partially compatible with the end-device player.

Jellyfin seems to love unnecessarily "remuxing" the audio claiming that most files have an incompatible audio container when infact they dont - but it's no real problem and that ffmeg you see around the 20% cpu usage when a film plays is generally that audio remuxing underway.

[tdjf]

The computer was built in 2023 and I thought it was a very good (better than decent/average) CPU and thought it would be able to handle transcoding. I guess I was wrong (or something specific with this file). I ended up buying a GPU because I added (already done now) multiple monitors and now when I transcode I'm around 15-20%.

Even with plex web player the CPU jumps somewhat high, but if I run the plex windows app the file can be direct played so obviously the player is better than the limited browser (with plex).

This is mainly only an issue when I play local on the server, I don't notice as many issues when I run on set top boxes since they are almost always direct play and no transcode is needed.

[nyanmisaka]

> but enabling hardware acceleration breaks the color/tone mapping?

https://jellyfin.org/docs/general/post-i...ng-methods

The [Prefer OS native DXVA or VA-API hardware decoders] feature toggles between the native decoders and the QSV decoders. Dolby Vision support requires that this option be checked.