Jellyfin Forum
MKV support - Printable Version

+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Development (https://forum.jellyfin.org/f-development)
+--- Forum: Feature Requests (https://forum.jellyfin.org/f-feature-requests)
+--- Thread: MKV support (/t-mkv-support)



MKV support - Geroldm972 - 2023-11-26

My collection consists of at least 40 TByte on content. And 95% is compressed using HVEC (x265/h265) and stored as MKV container. Google told me that MKV is not natively supported. The only suggestion I found, was to re-encode everything to MP4. Now, I really like Jellyfin, but I dread the job of re-encoding to MP4. really dread. 

Why? Let me explain my hardware/software situation: I have only recently discovered Jellyfin and I made via ProxMox a Linux-based VM with Jellyfin. Then I created SMB shares to my (bare-metal) media server that runs Windows. Jellfin runs absolutely fine this way and I'm not inclined to change it. All 3 of my ProxMox nodes run on computers that are around 10 years old. 2 of these have AMD CPUs with built-in video-card and the node with Intel CPU has only a Geforce 210 card in it. Good enough for basic office tasks, but nothing else. The Windows-based media server is a 1st gen AMD Ryzen, also with a GeForce 210 card in it.

CPU encoding is slow, but higher quality. Luckily I live in a country where electricity is very cheap, so my media-server makes long hours. Before my discovery of Jellyfin I just used PotPlayer on Windows and MPV on Linux to watch the content. So, I have lots of weak to very weak hardware in my network. Unfortunately, video cards are very expensive in this country. Prices may have dropped in the rest of the world, here in South-America they didn't. 

As a family-man, my budget for this hobby is (strictly) limited. I rather feed the wife, kids and dogs and provide a roof, school and clothing for them.

With that lengthy explanation finally out of the way; I see that all MKV content is being transcoded in Jellyfin, when watched via Chrome (Amdroid), Firefox (Linux/Windows) and Vivaldi (Windows). And with the hardware at hand I probably need a year or two just to re-encode to MP4. Not an investment I'm willing to make. Yet I would rather like it if Jellyfin did not have the need to transcode MKV content. A lot of the content is 720p. Some of it is 480p. In the cities here internet aplenty. But in the country-side where I domicile, you are elated if 720p online content comes through. Heck, even 480p content "stutters" on occasion. And I live rather close to my local ISP. My neighbor lives much farther away and he's happy with 480p content. 

Watching content in a browser on a phone, 720p content is more than ok. For the kids at least. My eyes are aging, and I noticed that the wife also starts to reach for reading glasses more often than she likes to admit, so we rather watch on my (1080p) TV or monitor. And there the grain of transcoding is very noticeable. Re-encoding isn't lossless, hence I fully expect the graining to become permanent after re-encoding all MKV content to MP4.

MKV support would therefore be very appreciated.


RE: MKV support - TheDreadPirate - 2023-11-26

What do you mean "MKV is not natively supported"?

Android - Use the official Jellyfin app or Findroid.
Linux/Windows - Use Jellyfin Media Player

My entire library uses MKV and is encoded with HEVC and, recently, AV1. Except for browsers, everything is direct played. Firefox just doesn't support HEVC because of royalties and patents. Chrome on Windows technically does, but requires some encouragement to do so.


RE: MKV support - paulc - 2023-11-26

I stopped reading at "Google told me..." Just dropping by to give you the link to Jellyfin's codecs page. https://jellyfin.org/docs/general/clients/codec-support/


RE: MKV support - use7 - 2023-11-26

Just wanted to put a clarifier here; technically mkv isn't supported across all platforms (url the jellyfin codecs page as inserted by paulc above), but as long as your video/audio codecs are supported the remxing that JF will do is negligible, as in their own words, "If the container is unsupported, this will result in remuxing. The video and audio codec will remain intact but wrapped in a supported container. This is the least intensive process. Most video containers will be remuxed to use the HLS streaming protocol and TS containers. Remuxing shouldn't be a concern even for an RPi3."  Since the video/audio streams are left untouched there'll be no visual distortions.

The larger difficulty is that h265 is not universally supported by all platforms (due to licensing/etc) which isn't on JF; but using a player that supports a wide range of codecs (JMP as is DreadPirate's suggestion) will make it so you don't have to do on-the-fly transcoding (and thus cause potential artifacting as you mentioned).  That said, it seems like in your ask there's more than just local users, and at non-native resolutions.  These are going to require transcoding in some format.  As long as you only have 1 or 2 streams going, even CPU transcoding will be feasible even on dated hardware (I've personally had up to 3 1080 -> 720p streams on an older intel duo quad without issue); and you can tune the transcoding in setttings -> dashboard -> playback (namely encoding preset and the crf values) to attempt to circumvent visual artifacting.


RE: MKV support - tmsrxzar - 2023-11-26

(2023-11-26, 11:29 AM)use7 Wrote: Remuxing shouldn't be a concern even for an RPi3."  

unless of course the user sets their transcode folder to the sdcard (or any other user errors that are common for Pi owners)


RE: MKV support - TheDreadPirate - 2023-11-26

(2023-11-26, 04:41 PM)tmsrxzar Wrote:
(2023-11-26, 11:29 AM)use7 Wrote: Remuxing shouldn't be a concern even for an RPi3."  

unless of course the user sets their transcode folder to the sdcard (or any other user errors that are common for Pi owners)

If this is the case, the transcode directory is configurable in the Playback dashboard.


RE: MKV support - Kubwa - 2023-11-30

MKV doesnt matter in this case. It is only the container. Puttng your videos in another container doesnt take any cpu usage at all.
What is hungry is transcoding. Now it depends on your player devices. When your clients are supporting H265, everything is fine. Nothing has to be transcoded. If not, well, its not Jellyfins fault Smiling-face