+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions)
+--- Thread: Avoiding transcoding ... (/t-avoiding-transcoding)
RE: Avoiding transcoding ... - Efficient_Good_5784 - 2025-01-14
(2025-01-14, 05:48 PM)jellyfin Wrote: 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."I also want to point out that Jellyfin will show "direct" next to the video if it's not being transcoded.
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!
You're misinterpreting things though. It's just saying that the video stream is direct, not that the whole container is being direct played.
(2025-01-14, 05:48 PM)jellyfin Wrote: But then, h.264 should work in any container.Nothing is wrong. As you stated before, Safari on iOS only supports some codecs in MP4, M4V, or MOV containers.
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!
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
RE: Avoiding transcoding ... - jellyfin - 2025-01-14
(2025-01-14, 06:33 PM)Efficient_Good_5784 Wrote: 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.
(2025-01-14, 06:33 PM)Efficient_Good_5784 Wrote: 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!
(2025-01-14, 06:33 PM)bitmap Wrote: 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!
RE: Avoiding transcoding ... - jellyfin - 2025-01-14
(2025-01-14, 06:49 PM)Efficient_Good_5784 Wrote:(2025-01-14, 05:48 PM)jellyfin Wrote: 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."I also want to point out that Jellyfin will show "direct" next to the video if it's not being transcoded.
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!
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?
(2025-01-14, 06:49 PM)Efficient_Good_5784 Wrote:(2025-01-14, 05:48 PM)jellyfin Wrote: But then, h.264 should work in any container.Nothing is wrong. As you stated before, Safari on iOS only supports some codecs in MP4, M4V, or MOV containers.
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!
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 ....
(2025-01-14, 06:49 PM)Efficient_Good_5784 Wrote: 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.
RE: Avoiding transcoding ... - Efficient_Good_5784 - 2025-01-14
(2025-01-14, 07:43 PM)jellyfin Wrote: All people I ever met in person or online rips their DVDs and BluRays with makemkv, mostly because it is the best container.If want, take this up with Apple as they are the ones that created Safari and what it supports.
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.
(2025-01-14, 07:43 PM)jellyfin Wrote: 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.What happens in the future when you buy a different device that doesn't work with your current files?
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!
Are you going to convert them all again to work on the new devices?
Transcoding exists for this reason.
(2025-01-14, 07:59 PM)jellyfin Wrote: No, I did not misinterprete.No it's not. The whole reason the remux happens is because Safari cannot play HEVC (H265) content inside an MKV container.
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?
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.
(2025-01-14, 07:59 PM)jellyfin Wrote: No, I sure don't want Jellyfin to either transcode or remux anything!The only choice you have is to use a client that can direct play your MKV files.
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 ....
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
(2025-01-14, 07:59 PM)jellyfin Wrote: So, for DTS 5.1ch, AAC with 384 would be best?No. You need 2 channels only. 5.1 channels does not work everywhere.
This is only half or a quarter of the DTS tracks, which seems ... a bit low.
You need to transcode the audio to always be 2.0 if you want the most chances of not needing a transcode or remux.
RE: Avoiding transcoding ... - jellyfin - 2025-01-14
(2025-01-14, 08:57 PM)Efficient_Good_5784 Wrote: ...
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.