Jellyfin keeps more work on the home server because local processing can reduce latency and data exposure while serving clients that cannot handle the source directly.
A television, browser, and phone may accept different codecs, HDR modes, or subtitles, so the server becomes the place where those differences are reconciled. Local control also makes the processing path inspectable. The trade-off is that the compute, storage, and maintenance cost remains on the operator’s hardware.
Client Limits Create Server-Side Work
The server sees the gap between the media and the client capability profile. If the client cannot decode a codec, render a subtitle, or accept HDR, Jellyfin may remux, convert audio, or run a full video pipeline before delivery.
A known client capability profile makes the path visible: compare the same file on clients that Direct Play and clients that trigger conversion.
Local processing is therefore not an arbitrary preference; it is the mechanism that lets one library serve heterogeneous endpoints.
Local Processing Reduces Path Variability
Keeping the conversion close to the media can avoid an extra upload, hosted conversion service, or client-specific dependency. It also lets the operator choose when jobs run, which accelerator they use, and where intermediate data is stored.
The broader multi-app resource model shows why inspectable pipelines help capacity planning, but control does not create throughput by itself.
The benefit is strongest for latency-sensitive, private, or frequently reused workloads. It is weaker when the server is already compute-bound or when clients can Direct Play.
Privacy and Control Are Separate From Capacity
A local server can keep media and generated state on storage the operator controls, but it still consumes electricity, needs updates, and may depend on identity, metadata, or remote-access services. Local processing changes custody and control; it does not erase operational responsibility.
Use the home-server ownership distinction between local ownership and complete offline independence when defining the actual requirement.
A privacy-first goal may justify local work even when it is not the fastest path, but the claim should name which data or operation must remain local.
Where Local Processing Stops Helping
Local processing falls short when the server cannot sustain the conversion path, when remote upload is the actual limit, or when a client limitation forces a heavy pipeline for every session. Moving work locally is not a substitute for measuring the first saturated stage.
Use cold and warm benchmark to compare a real workload before and after changing the processing location.
Stop treating “local” as automatically better when the observed bottleneck is elsewhere. The useful decision is whether local control solves the stated privacy or latency problem within the available resource margin.
Tech & AI HUB
More to Read

Why Does Home Assistant Perform Differently on LAN and Remote Connections?
LAN and remote Home Assistant sessions use different network paths; remote latency adds DNS, encryption, WAN, proxy or VPN, and reconnect behavior.

Does Home Assistant Work Reliably Behind CGNAT or Double NAT?
CGNAT and double NAT usually do not affect local Home Assistant control; they mainly change how remote clients can create an inbound path to...

How Does Network Latency Affect Home Assistant During Internet Outages?
Internet loss and network latency are different failures: local device paths can stay fast while DNS, cloud integrations, gateways, or remote clients wait.

