Ondertitel burn-in verhoogt de transcodingkosten van de mediaserver omdat de ondertitels niet langer als een aparte selecteerbare track worden geleverd. De server moet elke cue in het video-beeld renderen, waardoor nieuwe pixels ontstaan die vereisen dat de bron wordt gedecodeerd, gefilterd en gecodeerd in een vervangende stream.
Dit kan een anders compatibele Direct Play- of Direct Stream-sessie veranderen in volledige videotranscodering. De kosten hangen af van resolutie, codec, framerate, ondertitelindeling, styling, hardwareversnelling en of de client de ondertiteltrack lokaal had kunnen weergeven.
Wat verandert er wanneer ondertitels in video worden ingebrand?
ingeprente ondertitels worden onderdeel van elk frame. Ze zijn niet langer een onafhankelijke tekst- of bitmapstream die de speler kan in- of uitschakelen, van grootte kan veranderen of kan vervangen zonder de video te wijzigen.
Een aparte ondertiteltrack bevat timing plus tekst, styling of afbeeldingen. De client kan die track combineren met gedecodeerde video tijdens het afspelen wanneer het formaat en de weergavefuncties worden ondersteund.
Burn-in verplaatst de compositiestap naar de server. De mediaserver moet een nieuwe videorepresentatie creëren waarvan de gecomprimeerde frames al de glyphs, contouren, kleuren, positionering en animatie bevatten.
Waarom veroorzaakt burn-in volledige videotranscodering?
ondertitel burn-in veroorzaakt volledige videotranscodering omdat gecomprimeerde videopakketten meestal niet kunnen worden gewijzigd door er ondertiteltekst aan toe te voegen. De ondertitel moet worden toegepast na decodering en vóór een nieuwe encodering.
Remuxing kan compatibele videopakketten kopiëren naar een andere container, en audiotranscodering kan de video ongemoeid laten. Burn-in is anders omdat het de daadwerkelijke beeldinhoud van de videostream verandert.
Zelfs wanneer de bronresolutie en bitrate acceptabel blijven, vereisen de gewijzigde pixels een nieuwe gecomprimeerde bitstream. De server kan de oorspronkelijk gecodeerde video niet behouden en tegelijkertijd beweren dat de ondertitels in elk weergegeven frame zitten.
Welke fasen maken de transcoding-pijplijn duur?
de server decodeert, filtert en hercodeert video. Ondertitelparsing en -weergave worden ingevoegd in de filterfase tussen bron-decodering en output-encodering.
Bij 4K of hoge framerates verwerkt de pijplijn miljoenen pixels per frame. Fontvormgeving, omtrekken, schaduwen, schalen, kleurconversie, tonemapping en herschaling kunnen worden gecombineerd met de ondertitel-overlay.
De server moet ook sneller dan realtime blijven en een uitvoerbuffer onderhouden. Een pijplijn die encodeert met 0,8x afspeelsnelheid komt uiteindelijk vast te zitten, zelfs als de eerste paar seconden succesvol starten.
Waarom veranderen ondertitelingsformaten de kosten?
Beeldondertitels vereisen pixel-overlays. PGS en VobSub bevatten al bitmapgrafieken, terwijl ASS of SSA lettertypen, posities, kleuren, effecten en geanimeerde styling kunnen bevatten.
Eenvoudige SRT- of WebVTT-tekst is voor veel clients gemakkelijker direct te renderen. Complexe ASS-styling wordt mogelijk niet ondersteund of anders gerenderd, waardoor de server het moet inbranden om het bedoelde uiterlijk te behouden.
Beeldondertitelingssporen kunnen ook niet worden omgezet in gewone tekst zonder herkenning. De server moet hun bitmap-aanwijzingen op het juiste moment samenstellen en ze schalen met de video-uitvoer.
Waarom kan hardwareversnelling toch een bottleneck veroorzaken?
Hardwareversnelling kan slechts een deel van de pijplijn dekken. Decodering en codering kunnen op een GPU of media-engine draaien, terwijl ondertitelingsanalyse, fontrendering of sommige filterbewerkingen op de CPU blijven.
Wanneer frames van hardware-decodering naar systeemgeheugen gaan voor een CPU-overlay en vervolgens terug naar hardware-codering, kunnen geheugen-kopieën en synchronisatie een deel van het versnellingsvoordeel tenietdoen. Een zero-copy pad is moeilijker te onderhouden wanneer één filter geen hardware-ondersteuning heeft.
Het resultaat kan misleidende monitoring zijn: GPU-decodering en -codering zijn actief, maar één CPU-gebonden ondertitelingsfase beperkt de hele pijplijn. Het totale CPU-gebruik kan matig lijken wanneer de beperkende renderer slechts een klein aantal threads gebruikt.
Hoe kan een thuis mediaserver de kosten van burn-in vermijden?
Client-compatibele ondertitels vermijden frame-rendering. Tekstformaten zoals SRT of WebVTT zijn vaak de gemakkelijkste opties wanneer de afspeelclient ze ondersteunt.
Kies clients die de gangbare ondertitelingsformaten van de bibliotheek renderen, houd externe tekstondertitels naast de media, of maak compatibele ondertiteltracks tijdens de bibliotheekvoorbereiding. Voor vaak bekeken content kan een vooraf gegenereerde versie de encodeerkosten buiten de afspeeltijd verplaatsen.
Controleer de reden voor transcodering van de sessie voordat u snellere hardware koopt. ondertitelverwerking kan de bottleneck voor buffering worden, terwijl hetzelfde bestand soepel Direct Play kan afspelen wanneer ondertitels zijn uitgeschakeld of door een andere client worden gerenderd.
| Ondertitelingspad | Videobewerking | Typische serverkosten |
|---|---|---|
| Client-gerenderde tekst-ondertitel | Originele video kan ongewijzigd blijven | Laag |
| Client-gerenderde afbeelding-ondertitel | Originele video kan ongewijzigd blijven wanneer ondersteund | Lage tot matige clientkosten |
| Gebrande tekst- of ASS-ondertitel | Decoderen, renderen, samenstellen en coderen | Volledige videopijplijn |
| Gebrande PGS of VobSub | Bitmap aanwijzingen decoderen, schalen, samenstellen en coderen | Volledige pijplijn plus afbeelding-overlay werk |
Veelgestelde vragen
Veroorzaakt elke ondertiteltrack video-transcodering?
Nee. Compatibele clients kunnen veel tekst- en afbeelding-ondertitelingsformaten onafhankelijk renderen. Burn-in treedt op wanneer de client de geselecteerde track niet kan renderen of wanneer de server is geconfigureerd om dit af te dwingen.
Kan hardwaretranscodering ondertitel burn-in voorkomen?
Nee. Hardware kan decoderen, schalen en coderen versnellen, maar het parseren en overlayen van ondertitels kan nog steeds extra verwerking toevoegen of frameoverdrachten tussen hardware en systeemgeheugen vereisen.
Waarom kan SRT direct worden afgespeeld terwijl ASS burn-in veroorzaakt?
SRT bevat eenvoudige getimede tekst die door veel clients wordt ondersteund. ASS kan lettertypen, positionering, stijlen en effecten vereisen die een client niet kan reproduceren, dus rendert de server het bedoelde resultaat in de video.
Zal het converteren van ondertitels de beeldkwaliteit verminderen?
Het converteren van een afbeelding-ondertitel naar tekst kan stijlverlies veroorzaken of herkenningsfouten bevatten. Het converteren van complexe ASS naar SRT verwijdert meestal geavanceerde opmaak, maar kan toestaan dat de originele video ongewijzigd blijft.
Belangrijkste conclusie
Ondertitel burn-in is duur omdat het videopixels verandert, niet alleen metadata. De mediaserver moet de bron decoderen, getimede aanwijzingen renderen, deze op elk getroffen frame samenstellen en snel genoeg een nieuwe stream coderen voor weergave. Clientcompatibiliteit, eenvoudigere ondertitelingsformaten, volledige hardwarefilterondersteuning en vooraf gegenereerde versies kunnen voorkomen dat een lichte stream verandert in een volledige realtime transcode.
Tech & AI HUB
Meer om te lezen

Runtime State vs Persistent State in Home Assistant: What Must Survive Restart?
Home Assistant does not persist every live value; config, registries, selected restored states, history, and deployment data play different restart roles.

How Does Home Assistant Authenticate Local and Remote Sessions?
Local and remote Home Assistant sessions use the same server-side identity model; remote access changes the route and TLS boundary, not the core token...

Why Can Home Assistant History Queries Slow as Recorder Data Grows?
Recorder growth can raise History query cost when the requested range touches more rows, cache misses increase, or storage and index work become slower.

