2023-12-18, 01:03 PM
(This post was last modified: 2023-12-18, 01:04 PM by razorsharp79TM. Edited 1 time in total.)
Greetings,
I am using Jellyfin since about 6 months. I am using it to access my media collection both inside my home via my home network (1 Gbps LAN) and while I am mobile (VPN tunneling into my home network). At home, as there is no bandwidth problem, all my content is played as it is. But when I am travelling and I tunnel into my home network, I select a maximum bandwidth of 5mbps.
With this 5mbps, transcoding kicks in on my Jellyfin server. That is ok.
I am using an i5-9400F CPU as a "jack of all trades", running my proxmox VM server, where the JellyFin runs as a VM on Debian. Three host cores are dedicated to the VM running the JellyFin server to be used for x264 transcoding. Being an "F" variant, my I5 does not have an IGPU, so CPU transcoding it is.
I have noticed that one can select an X264 preset on the server side, or let things on "Auto" and the preset shall be selected automatically. Doing some experiments, I have noticed that leaving things on "Auto" makes the selected preset be "veryfast". Now, since my media is mostly of very high quality, and given the fact that I set the H264 CRF to 21 (from the default 23), on 1080p@5mbps transcodes, I have nothing to complain about the received quality.
But - I tried playing with the presets too. I noticed something weird: no matter what preset (other than AUTO) I select (medium, or slow, or even cranking up things to veryslow), the logs show that while the ffmpeg *does* get the "-preset xxxxxx" added at the beginnig, it also gets the "-x264opts subme=0:ref=1:..." line added on *later* which means that these later added options basically *nulify* every setting that the selected preset comes with!
I did some more investigation and turns out the the later added options, belong to the "veryfast" preset which in my case is exactly the preset that would get selected automatically.
So - is this a bug? Or is this a safe-guard against folks that might not know what they are doing?
Executive summary: when using x264 transcoding, any selected preset has its options canceled out in the ffmpeg command line by -x264opts added later that overrides it with "veryfast" preset options.
I am attaching a screenshot of the jellyfin server log when x264 slow preset is expressly chosen.
A quick look at x264 preset values: beandog's x264 preset reference
If I were to allocate more cores, say 4 instead of the current 3, would the "Auto" setting of the x264 preset actually select a preset other than the current "veryfast"?
I am using Jellyfin since about 6 months. I am using it to access my media collection both inside my home via my home network (1 Gbps LAN) and while I am mobile (VPN tunneling into my home network). At home, as there is no bandwidth problem, all my content is played as it is. But when I am travelling and I tunnel into my home network, I select a maximum bandwidth of 5mbps.
With this 5mbps, transcoding kicks in on my Jellyfin server. That is ok.
I am using an i5-9400F CPU as a "jack of all trades", running my proxmox VM server, where the JellyFin runs as a VM on Debian. Three host cores are dedicated to the VM running the JellyFin server to be used for x264 transcoding. Being an "F" variant, my I5 does not have an IGPU, so CPU transcoding it is.
I have noticed that one can select an X264 preset on the server side, or let things on "Auto" and the preset shall be selected automatically. Doing some experiments, I have noticed that leaving things on "Auto" makes the selected preset be "veryfast". Now, since my media is mostly of very high quality, and given the fact that I set the H264 CRF to 21 (from the default 23), on 1080p@5mbps transcodes, I have nothing to complain about the received quality.
But - I tried playing with the presets too. I noticed something weird: no matter what preset (other than AUTO) I select (medium, or slow, or even cranking up things to veryslow), the logs show that while the ffmpeg *does* get the "-preset xxxxxx" added at the beginnig, it also gets the "-x264opts subme=0:ref=1:..." line added on *later* which means that these later added options basically *nulify* every setting that the selected preset comes with!
I did some more investigation and turns out the the later added options, belong to the "veryfast" preset which in my case is exactly the preset that would get selected automatically.
So - is this a bug? Or is this a safe-guard against folks that might not know what they are doing?
Executive summary: when using x264 transcoding, any selected preset has its options canceled out in the ffmpeg command line by -x264opts added later that overrides it with "veryfast" preset options.
I am attaching a screenshot of the jellyfin server log when x264 slow preset is expressly chosen.
A quick look at x264 preset values: beandog's x264 preset reference
If I were to allocate more cores, say 4 instead of the current 3, would the "Auto" setting of the x264 preset actually select a preset other than the current "veryfast"?
![[Image: GitHub%20Sponsors-grey?logo=github]](https://img.shields.io/badge/GitHub%20Sponsors-grey?logo=github){kind=icon}