Direct Play vs. Direct Stream vs. transcoderen: welke optie gebruikt serverbronnen?

Direct Play gebruikt de minste serverrekenkracht, omdat de originele media kunnen worden geleverd zonder de streams te wijzigen. Direct Stream vereist meer serverwerk, omdat de server de media opnieuw verpakt en mogelijk een incompatibele audio- of ondertitelstream omzet, maar de video daarbij ongemoeid kan laten. Volledige transcoding gebruikt de meeste rekenkracht, omdat de video moet worden gedecodeerd, verwerkt en opnieuw gecodeerd. De juiste route is daarom niet per se degene met het laagste CPU-gebruik tegen elke prijs, maar de lichtste route die de client, het netwerk en de geselecteerde mediatracks daadwerkelijk kunnen accepteren.

Direct Play werkt alleen als het volledige bestand bij de client past

Direct Play is de eerste route die je wilt behouden, omdat de originele video en audio zonder hercodering worden verzonden. Er is nog steeds serverwerk nodig — opslag lezen, authenticatie, protocolafhandeling en netwerklevering — maar de intensieve videoconversiepijplijn blijft inactief.

Plex definieert Direct Play als de route waarbij de media door de client kunnen worden gebruikt zonder conversie, terwijl het streamingoverzicht dit onderscheidt van Direct Stream en transcoding. Die leveringsroute voor originele media maakt de mogelijkheden van de client doorslaggevend, in plaats van de rekenkracht van de server.

Direct Play valt weg wanneer de client iets essentieels weigert: videocodec, audiocodec, container, profiel, resolutie, bitrate, gedrag van ondertitels of een andere afspeelbeperking. Zodra een vereist element niet wordt ondersteund, moet de server de media opnieuw verpakken of een nieuwe stream maken.

Direct Stream is de tussenoplossing wanneer de video intact kan blijven

Direct Stream, ook wel remuxing of transmuxing genoemd, is bedoeld voor bestanden waarvan de video kan worden gekopieerd, maar waarvan de verpakking of een andere stream moet worden aangepast. De server haalt compatibele streams eruit en verpakt ze opnieuw in een vorm die de client kan accepteren. Dat is veel minder belastend dan de video decoderen en opnieuw coderen.

De afspeeldocumentatie van Emby beschrijft Direct Stream als real-time herverpakking waarbij de videotrack ongemoeid blijft, terwijl audio of ondertitels mogelijk worden omgezet. De remuxroute waarbij de video wordt gekopieerd vormt een nuttige grens: “streamen” betekent niet automatisch dat de video wordt getranscodeerd.

Deze route past het best wanneer alleen de container- of audiocompatibiliteit niet klopt. De route is niet meer beschikbaar wanneer de video zelf moet worden gewijzigd, wanneer ondertitels in de videobeelden moeten worden ingebrand of wanneer de geleverde bitrate of resolutie verder moet worden verlaagd dan met streamkopie mogelijk is.

Transcoding begint zodra de video opnieuw moet worden opgebouwd

Volledige videotranscoding is de zwaarste tak. De server decodeert de bron, kan de beelden schalen, tone-mappen, de-interlacen, ondertitels inbranden of de frames op een andere manier filteren, en codeert vervolgens een nieuwe videostream voor de client. Audio kan daarbij worden gekopieerd of omgezet.

De transcodingdocumentatie van Jellyfin maakt onderscheid tussen hardwareversnelling en softwareverwerking en vermeldt dat moderne GPU's ondersteunde processen kunnen overnemen. De real-timeconversiepijplijn verklaart waarom dezelfde film op de ene client weinig netwerkbelasting kan veroorzaken en op een andere client veel rekenkracht kan vereisen.

Transcoding is gerechtvaardigd wanneer compatibiliteit of bandbreedte daadwerkelijk een nieuwe videostream vereist. Als de client de originele video kan accepteren en het netwerk deze kan vervoeren, kan het afdwingen van een lagere kwaliteitsinstelling serverbelasting veroorzaken die er eerder niet was.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vergelijk de drie routes op vier gedeelde middelen

De servermiddelen die veranderen zijn rekenkracht, geheugentransport, tijdelijke transcodeopslag en netwerkbandbreedte. Direct Play minimaliseert de conversierekenkracht, maar kan de bron met de volledige bitrate leveren. Transcoding kan de uitgaande bitrate verlagen, terwijl het CPU- of GPU-gebruik toeneemt. Direct Stream zit ertussenin, omdat wijzigingen aan de verpakking meestal licht zijn, terwijl eventuele audioconversie wel wat rekenkracht toevoegt.

Het overzicht van FFmpeg voor hardwareversnelling documenteert speciale API's zoals NVENC/NVDEC en QSV voor videobe verwerking. Die hardwareversnellingslaag is alleen relevant voor de transcodeertak; Direct Play wordt er niet directer door.

Rangschik de routes niet op basis van slechts één middel. Een gebruiker op afstand met een trage uploadsnelheid kan transcoding nodig hebben, zelfs wanneer de server voldoende rekenkracht heeft, terwijl een lokale 4K-client op bekabeld ethernet beter af kan zijn met Direct Play op de originele bitrate.

Ondertitels en audio kunnen de route wijzigen zonder het filmbestand te veranderen

Een gebruiker kan een andere ondertitel- of audiotrack selecteren en de sessie daarmee naar een andere tak sturen. Tekstondertitels die de client zelf kan weergeven, kunnen Direct Play behouden, terwijl afbeeldingsondertitels of niet-ondersteund ondertitelgedrag kunnen vereisen dat de ondertitels worden ingebrand en de video dus wordt getranscodeerd. Niet-ondersteunde meerkanaalsaudio kan audioconversie activeren terwijl de video gekopieerd blijft.

De prestatiedocumentatie van HandBrake is hier nuttig, omdat deze onderscheid maakt tussen intensief videocodeerwerk en andere verwerking en laat zien dat filters zelfs met een hardware-encoder knelpunten kunnen blijven. De scheiding tussen filter- en encoderbelasting verklaart waarom “hardwaretranscoding ingeschakeld” niet betekent dat elke fase kosteloos is.

Wanneer de ene titel onverwacht meer servermiddelen gebruikt dan de andere, vergelijk dan eerst de geselecteerde tracks en de reden voor het afspelen voordat je CPU's of GPU's vergelijkt. De zichtbare resolutie kan identiek zijn, terwijl het verwerkingspad volledig anders is.

Gebruik het afspeeldashboard als beslisinstrument

Leid de route niet alleen af uit het CPU-gebruik. Open de sessiedetails van de mediaserver en noteer of de video Direct Play gebruikt, wordt gekopieerd/geremuxed of wordt getranscodeerd. Controleer vervolgens of audio wordt gekopieerd of omgezet en of ondertitels door de client worden weergegeven of in de video worden ingebrand.

De ZimaSpace-gids over hoog CPU-gebruik tijdens het afspelen van media past dezelfde regel toe: stel eerst vast welke verwerkingsbeslissing is genomen voordat je hoog gebruik als een hardwaretekort beschouwt.

Voer één representatieve lokale sessie uit, één sessie op afstand of met beperkte bandbreedte en één sessie met veel ondertitels. Als het dashboard al Direct Play meldt en het afspelen toch buffert, vergelijk dan niet langer de transcodekracht, maar controleer de opslag, levering of client.

Kies de lichtste route die aan de leveringsbeperking voldoet

Geef de voorkeur aan Direct Play wanneer de client het volledige mediabestand ondersteunt en het netwerk de bitrate ervan kan dragen. Zo blijft de bron behouden en blijft de meeste servercapaciteit beschikbaar voor andere gebruikers.

Gebruik Direct Stream wanneer de videocompatibiliteit al is opgelost, maar de container, audio of verpakking moet worden aangepast. Gebruik transcoding alleen wanneer de video zelf moet worden gewijzigd vanwege compatibiliteit, bandbreedte, resolutie, HDR/SDR-conversie, het inbranden van ondertitels of een andere echte leveringsbeperking.

Geen enkele route is universeel de beste. Direct Play minimaliseert de rekenbelasting, Direct Stream lost verpakkingsproblemen goedkoop op en transcoding biedt compatibiliteit en controle over de bitrate ten koste van servermiddelen. Een goed ontwerp voor een mediaserver maximaliseert de eerste twee routes en behoudt voldoende transcodecapaciteit voor sessies die de derde niet kunnen vermijden.