Direct Play kontra Direct Stream kontra omkodning: Vilken väg använder serverresurser?

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.

Direct Play vs Direct Stream vs Transcoding: Which Path Uses Server Resources? - Zima Store Online

Direct Play använder minst serverberäkningskraft eftersom originalmediet kan levereras utan att dess strömmar ändras. Direct Stream kräver mer serverarbete eftersom servern paketerar om mediet och kan konvertera en inkompatibel ljud- eller undertextström, men videon kan fortfarande lämnas orörd. Fullständig omkodning kräver mest beräkningskraft eftersom videon måste avkodas, bearbetas och kodas om. Den rätta vägen är därför inte den som har lägst CPU-användning till varje pris, utan den lättaste vägen som klienten, nätverket och de valda mediespåren faktiskt kan acceptera.

Direct Play fungerar bara när hela filen passar klienten

Direct Play är den första vägen att försöka bevara eftersom den skickar originalvideo och originalljud utan omkodning. Serverarbete krävs fortfarande – lagringsläsningar, autentisering, protokollhantering och nätverksleverans – men den kostsamma videokonverteringsprocessen förblir inaktiv.

Plex definierar Direct Play som den väg där mediet kan användas av klienten utan konvertering, medan deras översikt över strömning skiljer detta från Direct Stream och omkodning. Den direkta leveransvägen för originalmediet gör klientens funktioner till den avgörande faktorn, snarare än serverns beräkningskraft.

Direct Play faller bort när klienten inte accepterar något väsentligt: videokodек, ljudkodek, behållarformat, profil, upplösning, bithastighet, undertextbeteende eller någon annan uppspelningsbegränsning. När något obligatoriskt element inte fungerar måste servern antingen paketera om mediet eller skapa en ny ström.

Direct Stream är mellanvägen när videon kan lämnas intakt

Direct Stream, som ofta kallas remuxning eller transmuxning, används för filer där videon kan kopieras men där paketet eller någon annan ström behöver justeras. Servern extraherar kompatibla strömmar och paketerar om dem i en form som klienten kan acceptera, vilket är mycket mindre krävande än att avkoda och koda om videon.

Embys dokumentation om uppspelning beskriver Direct Stream som ompaketering i realtid, där videospåret lämnas orört medan ljud eller undertexter kan konverteras. Deras remuxväg med kopierad video är en användbar gräns: ”strömning” betyder inte automatiskt videoomkodning.

Den här vägen passar bäst när det enda som inte stämmer är behållarformatet eller ljudkompatibiliteten. Den är inte längre tillgänglig när själva videon måste ändras, när undertexter måste brännas in i bildrutorna eller när den levererade bithastigheten eller upplösningen måste sänkas mer än vad strömkopiering kan åstadkomma.

Omkodning börjar när videon måste byggas om

Fullständig videoomkodning är den resurskrävande grenen. Servern avkodar källan och kan skala, tonmappa, avfläta, bränna in undertexter eller på annat sätt filtrera bildrutorna, för att sedan koda en ny videoström för klienten. Ljudet kan kopieras eller konverteras samtidigt.

Jellyfins dokumentation om omkodning skiljer maskinvaruacceleration från programvarubearbetning och noterar att moderna GPU:er kan avlasta stödda processer. Den realtida konverteringsprocessen förklarar varför samma film kan vara en lätt nätverksuppgift på en klient och en tung beräkningsuppgift på en annan.

Omkodning är motiverad när kompatibilitet eller bandbredd faktiskt kräver en ny videoström. Om klienten kan acceptera originalvideon och nätverket kan bära den, kan en påtvingad kvalitetsminskning skapa serverbelastning som inte fanns tidigare.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Jämför de tre vägarna utifrån fyra gemensamma resurser

De serverresurser som påverkas är beräkningskraft, minnesöverföringar, tillfällig lagring för omkodning och nätverksbandbredd. Direct Play minimerar konverteringsberäkningar men kan leverera källan med full bithastighet. Omkodning kan minska den utgående bithastigheten samtidigt som CPU- eller GPU-arbetet ökar. Direct Stream hamnar mellan dessa eftersom ändringar av paketeringen vanligtvis är lätta, medan eventuell ljudkonvertering tillför viss beräkningsbelastning.

Uppspelningsväg	Videobearbetning	Typiskt beräkningsbehov	Nätverksbeteende	Huvudsaklig begränsning
Direct Play	Originalvideo och originalljud	Lägst	Källans bithastighet	Inkompatibilitet mellan klient och fil
Direct Stream	Videon kopieras; paketet och eventuellt ljudet ändras	Lågt till måttligt	Ofta nära videons ursprungliga bithastighet	Själva videon behöver konverteras
Omkodning	Videon avkodas och kodas om	Högst	Kan riktas mot lägre bithastighet eller upplösning	Beräknings- eller acceleratorgenomströmning

FFmpeg:s översikt över maskinvaruacceleration dokumenterar särskilda API:er som NVENC/NVDEC och QSV för videobearbetning. Detta lager för maskinvaruavlastning är bara relevant vid omkodning; det gör inte Direct Play mer direkt.

Rangordna inte vägarna utifrån en enda resurs. En fjärranvändare med långsam uppladdning kan behöva omkodning även när servern har gott om beräkningskraft, medan en lokal 4K-klient på trådbundet Ethernet kan ha större nytta av Direct Play med originalets bithastighet.

Undertexter och ljud kan ändra vägen utan att filmfilen ändras

En användare kan välja ett annat undertext- eller ljudspår och därmed flytta sessionen till en annan gren. Textbaserade undertexter som klienten kan återge kan bevara Direct Play, medan bildbaserade undertexter eller inkompatibelt undertextbeteende kan kräva inbränning och därmed videoomkodning. Inkompatibelt flerkanalsljud kan utlösa ljudkonvertering medan videon fortfarande kopieras.

HandBrakes dokumentation om prestanda är användbar här eftersom den skiljer det kostsamma videokodningsarbetet från annan bearbetning och visar att filter fortfarande kan vara flaskhalsar även med en maskinvarukodare. Den separata belastningen från filter och kodare förklarar varför ”maskinvaruomkodning aktiverad” inte gör varje steg kostnadsfritt.

När en titel oväntat använder mer serverresurser än en annan bör du jämföra de valda spåren och orsaken till uppspelningen innan du jämför CPU:er eller GPU:er. Den synliga upplösningen kan vara identisk samtidigt som bearbetningsvägen är helt annorlunda.

Använd uppspelningspanelen som beslutsunderlag

Dra inte slutsatser om vägen enbart utifrån CPU-användningen. Öppna medieserverns sessionsinformation och notera om videon använder Direct Play, kopieras eller paketeras om, eller omkodas. Kontrollera sedan om ljudet kopieras eller konverteras och om undertexterna återges av klienten eller bränns in i videon.

ZimaSpaces guide om hög CPU-användning vid medieuppspelning tillämpar samma princip: identifiera bearbetningsbeslutet innan hög belastning tolkas som brist på maskinvarukapacitet.

Kör en representativ lokal session, en fjärrsession eller session med begränsad bandbredd och en session med mycket undertexter. Om panelen redan visar Direct Play och uppspelningen ändå buffrar bör du sluta jämföra omkodningskapacitet och i stället undersöka lagring, leverans eller klienten.

Välj den lättaste vägen som uppfyller leveranskravet

Föredra Direct Play när klienten stöder hela mediefilen och nätverket kan bära dess bithastighet. Det bevarar källan och lämnar mest serverkapacitet tillgänglig för andra användare.

Använd Direct Stream när videokompatibiliteten redan är löst men behållarformatet, ljudet eller paketeringen behöver justeras. Använd omkodning endast när själva videon måste ändras på grund av kompatibilitet, bandbredd, upplösning, HDR/SDR-konvertering, inbränning av undertexter eller något annat verkligt leveranskrav.

Ingen väg vinner alltid. Direct Play minimerar beräkningsbehovet, Direct Stream löser paketeringsproblem billigt och omkodning ger kompatibilitet och kontroll över bithastigheten på bekostnad av serverresurser. Den rätta medieserverdesignen maximerar de två första vägarna samtidigt som den behåller tillräcklig omkodningskapacitet för sessioner som inte kan undvika den tredje.