H.265 Native on client player

[flynnz]

:: I am sure this has been asked in one way or another many times on this forum, but I did search around first and couldn't really find any posts that answered this question. But I do want to apologize in the event that this is an exhausted topic ::

Does anyone know if we will ever see h.265 decoding (and other codecs that need to be transcoded) on the Jellyfin playback clients?

Needing a GPU or beefy modern CPU to transcode on a file/media server is far from ideal (cost, heat, electricity).
and even if you have a hefty setup, I imagine you will still be severely limited to how many streams you can encode at one time. For example, I share my server with my large family and friends and can hit over 10 connections at one time. This isn't a problem for files just being served up, even with my old CPU, but I imagine if I had to encode 10 video streams at a time, even a fairly decent GPU/CPU would have issues.

As it stands now, I am hand-converting all my video files using Handbrake so I don't have to encode anything in real time on my server. The issue is, that I will never get to all the video files, there are just too many. Plus having to deal with future files also seems very daunting.

So will we ever see a day when we won't need to transcode in real time or is there a technical reason the client playback software can't decode certain codecs? (licensing perhaps?) 

Also as a newcomer, I was just wondering how people here set up their servers to deal with this. Do you just throw tons of horsepower at the issue? Or do you re-encode files so they don't need to be transcoded in real time?

[LambTalk]

I have H265 decoding on all my Jellyfin clients. What client are you using that doesn't support it?
I never have to transcode when watching anything from my Jellyfin server

[flynnz]

I have H265 decoding on all my Jellyfin clients. What client are you using that doesn't support it?
I never have to transcode when watching anything from my Jellyfin server

Seems like pretty much anything that is not the desktop client causes transcoding (Browser, Android, etc). And it's not just H.265, there are containers and audio it needs to transcode as well. 

You can see the list here;
https://jellyfin.org/docs/general/client...c-support/

To make sure, I playback a file, then check to see on my server if my ffmpeg launches and how much my CPU gets pinned heh. Then I convert and the playback of the file is fine with no hit to CPU at all, nor does it launch ffmpeg. But currently, all my testing is in the Chrome browser because that is what my family and friends use the most.

[LambTalk]

Browsers don't support HEVC, so you're out of luck there.
Android definitely does though. You just need to make sure you're using the integrated player and not the web player in your Android client settings.

Container "transcoding" (remuxing) isn't an intensive task either, and happens pretty transparently. So if your device supports HEVC, but doesn't like mkv containers, then a simple remux to mp4 during playback shouldn't cause any strain.
Same with audio transcoding, it's not intensive at all.

But yeah, using Chrome is going to be your issue. You're not going to get direct play of HEVC there at all. At best, you will get Direct Stream (simply remuxing the container and leaving the streams intact), but I believe there may be a PR still waiting to be merged for that.

The only time a client would transcode is if you're trying to play a stream (video, audio or subtitles) that uses a codec or format not supported by the client.

[flynnz]

I get the same issue of transcoding all the time when using the Android JF app, not just browser. I assume that is what you mean, but correct me if there is another method on Android you are referring to.  

Container "transcoding" (remuxing) isn't an intensive task either, and happens pretty transparently. So if your device supports HEVC, but doesn't like mkv containers, then a simple remux to mp4 during playback shouldn't cause any strain.
Same with audio transcoding, it's not intensive at all.

I do notice a lot of transcoding just for audio and the like, and while it doesn't pin the processor, if I have a few people transcoding at once, it does still very much become an issue

The only time a client would transcode is if you're trying to play a stream (video, audio or subtitles) that uses a codec or format not supported by the client.

and yes, of course, but the issue is, I have a huge library with tons of videos that arent supported as do many others from what I read, so I was just wondering more how people deal with it. When you get a file/codec that's not supported, do you just throw horse power at it? or do you re-encode it? I understand if you are using a client that works with everything you probably don't bother.

If your use case is just for viewing yourself I understand it's probably not an issue, but if you have a varied collection of users and files it makes using JF a bit more of a challenge, so I was specifically talking within that context. (and as far as I can tell, even if I had everyone switch to the Android app instead of browser I would still have tons of transcoding going on)

[Efficient_Good_5784]

I think you're confused on what transcoding is and why it's needed.

Digital media codecs (be it for video, audio, images, etc.) are a set of standards and instructions on how to build, hold, and play said media. As more newer codecs are invented, software that plays media (clients) need to have developers add updates to tell the media player how to read (decode) an encoded stream. Clients are capable of direct playing things using the CPU as long as developers give it code that understands how to natively read the codec.

GPUs (for HWA) on the other hand, have support for codecs added or removed physically. It's up to the GPU makers to implement support for any codec type. From my understanding, you can't code your way to allow a GPU to direct play a codec that the manufactuers didn't implement physically.

Think about this analogy:
Let's say I only speak Spanish and you only speak English. We're going to need a translator to "transcode" between the two of us so we can talk to each other. We're never going to direct play ("talk") to each other without the translator until one of us learns the opposite language.

I remember writing a post similar to this that might help clear up your question: https://forum.jellyfin.org/t-unsure-abou...62#pid3762

Also, Handbrake lets you add a folder and it will load all video files in all the subfolders within it. You can then add all the videos to be encoded in one go. Just let your computer run until all the videos have been encoded. There's even programs online that lets you automate media being sent to Handbrake and the final encode stored in a sorted location.

[flynnz]

I think you're confused on what transcoding is and why it's needed.

Not sure how you reached this conclusion that I don't understand why transcoding is needed. I am fully aware it needs to be "translated" via transcoding in real time on the server if the client can't speak the same "language". My question was why is the client lacking other "languages" on certain platforms and if we will ever see those clients updated to understand said language. Much how VLC plays back anything that is thrown at it, it doesn't need it to be translated first as it is multi-lingual


None of this is a deal breaker, more of just general thoughts on how others view the issue and/or how they go about getting around it.

[flynnz]

Also, Handbrake lets you add a folder and it will load all video files in all the subfolders within it. You can then add all the videos to be encoded in one go. Just let your computer run until all the videos have been encoded. There's even programs online that lets you automate media being sent to Handbrake and the final encode stored in a sorted location.

This is exactly what I have been doing, but I still need to go through and find out which files are problematic first and that is the biggest pain. So for now I test on the lowest common denominator (the browser) and re-encode as needed.

[Efficient_Good_5784]

Not sure how you reached this conclusion that I don't understand why transcoding is needed.

Sorry, I read too much into it and assumed so because of this:

So will we ever see a day when we won't need to transcode in real time or is there a technical reason the client playback software can't decode certain codecs? (licensing perhaps?)  

Basically, I read the "is there a technical reason" part of this quote and thought you didn't know.

Also, Handbrake lets you add a folder and it will load all video files in all the subfolders within it. You can then add all the videos to be encoded in one go. Just let your computer run until all the videos have been encoded. There's even programs online that lets you automate media being sent to Handbrake and the final encode stored in a sorted location.

This is exactly what I have been doing, but I still need to go through and find out which files are problematic first and that is the biggest pain. So for now I test on the lowest common denominator (the browser) and re-encode as needed.

The biggest issue you'll face here is that the same problamatic files can be a problem in some clients, and be fine in others. As of right now, if you want the most compatibility for all clients, your best bet is to encode everything to AVC (H.264).

Also, there's things that force a transcode like certain subtitle types and special audio files not being compatible with the client. Like how ASS subs can't be direct played on browsers.

[flynnz]

The biggest issue you'll face here is that the same problamatic files can be a problem in some clients, and be fine in others. As of right now, if you want the most compatibility for all clients, your best bet is to encode everything to AVC (H.264).

Also, there's things that force a transcode like certain subtitle types and special audio files not being compatible with the client. Like how ASS subs can't be direct played on browsers.

yeah that is what I have been using and everything has worked perfect after re-encoding from Handbrake.