Varför HDR och inbränning av undertexter ökar Jellyfins iGPU-belastning

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why HDR and Subtitle Burn-In Raise Jellyfin iGPU Load

Jellyfin kan använda betydligt mer iGPU-kapacitet när HDR-konvertering och inbränning av undertexter sker i samma uppspelningssession.

GPU:n utför inte en enda generell ”omkodning”. Den kan avkoda källan, tonmappa HDR till SDR, lägga samman undertexter, skala bildrutor och koda resultatet, samtidigt som ett steg som inte stöds flyttar tillbaka arbetet till CPU:n; kapacitetstestet måste återskapa exakt den sökvägen. Håll klienten, undertextspåret, HDR-målet och utdatakvaliteten fasta så att förändringen i iGPU-belastning beror på de tillagda stegen.

HDR-tonmappning lägger till ett separat bearbetningssteg

En HDR-fil som inte kan förbli i HDR på klienten kan behöva tonmappas innan servern kan leverera en användbar SDR-ström. Konverteringen lägger till arbete även när grundläggande avkodning och kodning av kodeken redan är hårdvaruaccelererade.

Ett system som hanterar vanlig 4K-konvertering kan få mindre marginal när tonmappningsbelastning läggs till i omkodningsprocessen.

Jämför samma källa med HDR-konvertering aktiverad och inaktiverad, och registrera GPU-motorernas användning i stället för enbart den totala CPU-användningen.

Inbränning av undertexter kan göra en lätt sökväg till fullständigt videarbete

Textundertexter som klienten kan återge är kostnadsbesparande för servern, men bildundertexter eller textformatering som inte stöds kan tvinga Jellyfin att rita in undertexterna i varje bildruta. Då förändras arbetsbelastningen från remuxning eller Direct Play till videobearbetning.

Bildbaserade format som PGS utlöser ofta inbränning av undertexter och fullständig omkodning när uppspelningsklienten inte kan återge dem direkt.

Spela upp filen igen med undertexter avstängda, med ett enkelt SRT-spår och med det faktiska undertextspåret. Om iGPU-användningen ökar endast i det sista fallet är undertextkomposition en del av kapacitetsgränsen.

Klientens funktioner avgör vilka steg servern måste köra

Samma media kan använda olika mycket serverresurser på en TV, i en webbläsare eller på en telefon eftersom varje klient stöder olika uppsättningar av kodekar, behållarformat, HDR-format och undertextlägen. Serverkapacitet kan inte skiljas från klientens funktioner.

En klient kan rapportera en ofullständig funktionsprofil, vilket kan få Jellyfin att välja en tyngre serversökväg även när enheten har hårdvaruavkodare.

Använd en välfungerande Direct Play-klient som kontroll och testa sedan klienten som skapar den tunga sökvägen. En stabil baslinje för hårdvaruacceleration gör det lättare att isolera de extra HDR- eller undertextstegen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Dimensionera iGPU-marginalen utifrån den svåraste realistiska kombinationen

Ett syntetiskt test av mediemotorn kan missa den exakta överlappning som är viktig hemma: HDR-tonmappning, inbränning av undertexter, skalning och en andra ström. Kapacitetsmålet bör vara den mest belastade återkommande kombinationen i hushållet, inte ett genomströmningspåstående från leverantören.

Metoden för användning och mättnad ger ett praktiskt sätt att skilja hög men hälsosam GPU-användning från en kö utan kvarvarande servicemarginal.

Kör den svåraste förväntade sessionen ensam och lägg sedan till det normala antalet samtidiga strömmar, en i taget. Behåll bara den marginal som den uppmätta latensen eller gränsen för tappade bildrutor visar behövs.