Avoiding transcoding ...

[Efficient_Good_5784]

First let me say that the above link says that h.265 / HEVC on Safari or iOS is "is only supported in MP4, M4V, and MOV containers."
That does not seem to be true!
-> I can play H265 from a MKV container and it will be shown as "direct" in the JF dashboard! 

I also want to point out that Jellyfin will show "direct" next to the video if it's not being transcoded.
You're misinterpreting things though. It's just saying that the video stream is direct, not that the whole container is being direct played.

But then, h.264 should work in any container.
That does not seem to be true!
-> I can play H264 from a MKV as "direct" but it still get's remixed!

Something is wrong here.

For this, I created both H264 and H265 videos in a MKV container - and the Dashboard in both cases says that the video is played "Direct".

Also, in both cases, the video get's remuxed - because of the container!
I repeated the same with videos without any audio and then even without any subtitles, just to be sure - same behaviour!

Nothing is wrong. As you stated before, Safari on iOS only supports some codecs in MP4, M4V, or MOV containers.
Jellyfin is taking that into account to make sure you can direct stream your video.

It just switches the MKV container to one that is supported.

If you want to avoid this specifically on Safari on iOS, switch your containers to MP4.

A lot of things in life has trades and balances. By switching to MP4, you will be losing out on some other things such as not being able to include certain audio or subtitle tracks along with the video as what MKV provides.
Just let Jellyfin transcode/remux when it's needed for you. That's why Jellyfin has that capability. It's to make your life easier instead of having to worry about making all your files compatible with every single device.

And just in case, and to repeat again, the most compatible format for most clients is as follows:

Video: H264 (AVC) 8-bit
Audio: AAC 2.0 (128kbps total / 64kbps per channel)
Subtitles: SRT
Container: MP4

[jellyfin]

That's expected behavior. MKVs are not widely supported by all clients to begin with. MP4 are, so there's way less of a chance that MP4 containers will cause a remux.

All people I ever met in person or online rips their DVDs and BluRays with makemkv, mostly because it is the best container.

I find it strange that such an important container type is not supported by a client for a server that services such rips - it seems to be the most logical thing to FIRST support MKV, simply as most content will be available in this container format.

I never bothered before, as I locally just use VLC to play anything.
But after I found Jellyfin, I liked the idea of such a server - and even a way to watch from remote.
But I cannot do that with such an amount of remux files ...

That means, either ditch Jellyfind or re-encode ALL my stuff as MP4, loosing most subtitle track.
I will need some days to get over that.

What Jellyfin is doing is remuxing your MKV container to MP4 so that the client can play it.
This is not a bug. The client just can't handle MKV containers most likely.

MP4 can only handle ONE subtitle track, which makes it ... totally unusable.

Thanks for the explanation!

---

Just to clarify, remuxing is not the same as transcoding. Remuxing when a client reports it is not compatible with the container is the expected behavior and remuxing uses *very few* cycles (i.e., small amount of CPU or GPU). Transcode/remux files in cache are temporary and cleared out on whatever schedule is set in your Scheduled Tasks. I would not fret about this, very much the expected behavior.

Yes, I know - but constant creation of immense amounts of new files is nearly as bad, just the CPU usage and time is smaller without transcodes.

You may not know, but constantly writing new files in a large number and in terms of total size is surely going to kill your disk, regardless if HD or SSD - and your whole Mac with M* CPU, as normally you cannot replace it's disk.

It is totally unacceptable to me (and sure most people) that such files get created - I need to remove both transcoding and remuxing!

[jellyfin]

First let me say that the above link says that h.265 / HEVC on Safari or iOS is "is only supported in MP4, M4V, and MOV containers."
That does not seem to be true!
-> I can play H265 from a MKV container and it will be shown as "direct" in the JF dashboard! 

I also want to point out that Jellyfin will show "direct" next to the video if it's not being transcoded.
You're misinterpreting things though. It's just saying that the video stream is direct, not that the whole container is being direct played.

No, I did not misinterprete.
I know this and I noticed the "remux" in the playback information - also the files in the transcoding cache.
What I tried to say here is, that from the Codec information page, H265 should NOT directly playable from a MKV container - but it is (with remux because of the container).
At least, this is how I read the table.
More clear?

But then, h.264 should work in any container.
That does not seem to be true!
-> I can play H264 from a MKV as "direct" but it still get's remuxed!

Something is wrong here.

For this, I created both H264 and H265 videos in a MKV container - and the Dashboard in both cases says that the video is played "Direct".

Also, in both cases, the video get's remuxed - because of the container!
I repeated the same with videos without any audio and then even without any subtitles, just to be sure - same behaviour!

Nothing is wrong. As you stated before, Safari on iOS only supports some codecs in MP4, M4V, or MOV containers.
Jellyfin is taking that into account to make sure you can direct stream your video.

It just switches the MKV container to one that is supported.

If you want to avoid this specifically on Safari on iOS, switch your containers to MP4.

A lot of things in life has trades and balances. By switching to MP4, you will be losing out on some other things such as not being able to include certain audio or subtitle tracks along with the video as what MKV provides.
Just let Jellyfin transcode/remux when it's needed for you. That's why Jellyfin has that capability. It's to make your life easier instead of having to worry about making all your files compatible with every single device.

No, I sure don't want Jellyfin to either transcode or remux anything!
Instead, I will need to re-encode Terabytes of data, which let's me freeze in horror.
I need encodings that will not need transcoding or remuxing anymore ....

And just in case, and to repeat again, the most compatible format for most clients is as follows:

Video: H264 (AVC) 8-bit
Audio: AAC 2.0 (128kbps total / 64kbps per channel)
Subtitles: SRT
Container: MP4

Thanks for this, this ensures me in what to do best with my stuff.

So, for DTS 5.1ch, AAC with 384 would be best?
This is only half or a quarter of the DTS tracks, which seems ... a bit low.
EDIT 2: That does not seem to be needed, as DTS can also be played directly when in a MP4 container! No transcoding, no remux. I stay at passthrough as much as possible and will only otherwise use AAC with 64 per channel!
EDIT 3: I tested this and as it seems, the Jellyfin client on iPadOS cannot play DTS from MP4 without transcoding!

I need to recover from this new information about MKV always needing remux.
That was a hard strike.

EDIT: For some reason either my Mac, Safari or this webpage enabled "automatic corrections" so that all my typing of "remux" got changed to "remix".
I tried to fix that.

[Efficient_Good_5784]

All people I ever met in person or online rips their DVDs and BluRays with makemkv, mostly because it is the best container.

I find it strange that such an important container type is not supported by a client for a server that services such rips - it seems to be the most logical thing to FIRST support MKV, simply as most content will be available in this container format.

I never bothered before, as I locally just use VLC to play anything.
But after I found Jellyfin, I liked the idea of such a server - and even a way to watch from remote.
But I cannot do that with such an amount of remux files ...

That means, either ditch Jellyfind or re-encode ALL my stuff as MP4, loosing most subtitle track.
I will need some days to get over that.

If want, take this up with Apple as they are the ones that created Safari and what it supports.

Yes, I know - but constant creation of immense amounts of new files is nearly as bad, just the CPU usage and time is smaller without transcodes.

You may not know, but constantly writing new files in a large number and in terms of total size is surely going to kill your disk, regardless if HD or SSD - and your whole Mac with M* CPU, as normally you cannot replace it's disk.

It is totally unacceptable to me (and sure most people) that such files get created - I need to remove both transcoding and remuxing!

What happens in the future when you buy a different device that doesn't work with your current files?
Are you going to convert them all again to work on the new devices?

Transcoding exists for this reason.

No, I did not misinterprete.
I know this and I noticed the "remux" in the playback information - also the files in the transcoding cache.
What I tried to say here is, that from the Codec information page, H265 should NOT directly playable from a MKV container - but it is (with remux because of the container).
At least, this is how I read the table.
More clear?

No it's not. The whole reason the remux happens is because Safari cannot play HEVC (H265) content inside an MKV container.
That's why Jellyfin switches to using an MP4 container.

You are misinterpreting the act of the video being direct as it being from inside an MKV container.
The client is direct playing it from inside the new MP4 container that is sent to it.
The MKV container was long since ditched and never reached the client.

No, I sure don't want Jellyfin to either transcode or remux anything!
Instead, I will need to re-encode Terabytes of data, which let's be freeze in horror.
I need encodings that will not need transcoding or remuxing anymore ....

The only choice you have is to use a client that can direct play your MKV files.

You should check out Jellyfin Media Player. It uses MPV as the player, so it can direct play MKV files.
https://github.com/jellyfin/jellyfin-media-player

So, for DTS 5.1ch, AAC with 384 would be best?
This is only half or a quarter of the DTS tracks, which seems ... a bit low.

No. You need 2 channels only. 5.1 channels does not work everywhere.

You need to transcode the audio to always be 2.0 if you want the most chances of not needing a transcode or remux.

[jellyfin]

...

About Transcodings:

No, I want my stuff to play without transcoding or remuxing!
Both is an absolute no-go.
And I want to avoid any re-encoding too! At best, I want to use my pristine rips from media, which are MKV.


I was so frustrated, you would cannot believe.


And then, I found a solution!

Without needing to re-encode terabytes of data.

I just want to play movies on my iPad (both locally in my LAN / WLAN and remotely) on on my desktop (where I can use VLC).

I only ever tested the Jellyfin client for iPad.

And it does not work OK with MKV containers.
As you say, it internally uses Safari - and you gave me a link to a desktop client (which I don't need as here I can simply use VLC as always).

But ...

I found the Swiftin client for iPads - and wonder oh wonder, it can simply play MKV containers, without triggering transcode or remux on the server!

Problem solved.
Just get a working client.

That saves me from skipping to Plex too - as I read Plex can work with MKV without transcoding or remuxing.