Vad orsakar att ljudet hamnar ur synk först efter omkodning?
Ljudet hamnar ur synk efter omkodning när den genererade ljudtidslinjen inte längre fortskrider exakt i samma takt eller vid samma tidsstämplingsgränser som videon.
Direktuppspelning kan dölja problemet eftersom klienten använder originalbehållaren och dess inbyggda tidsinstruktioner, medan omkodning avkodar, samplar om, kodar om, tidsstämplar, segmenterar och muxar om den ena eller båda strömmarna. Börja med att avgöra om felet är en fast förskjutning, en gradvis ökande drift eller ett hopp som uppstår när du söker eller återupptar uppspelningen. Dessa mönster pekar på olika delar av medieflödet.
Klassificera synkroniseringsfelet innan du ändrar omkodaren
Spela upp från början utan att söka och notera förskjutningen nära början, mitten och slutet. Använd en scen med en synlig stöt eller en tydlig konsonant i talet i stället för att uppskatta utifrån bakgrundsmusik.
En fast förskjutning som förblir konstant tyder på en ursprunglig tidsstämpel, en redigeringslista, en fördröjning i mottagaren eller en klientinställning. Ett avstånd som växer stadigt tyder på inkompatibla klockfrekvenser, feltolkning av bildfrekvensen, ljudtöjning eller omsampling. Ett plötsligt hopp efter sökning eller återupptagning pekar på segment- och omstartstidsstämplar.
Upprepa mätningen med undertexterna avstängda och klientens manuella ljudfördröjning inställd på noll. Att korrigera en föränderlig drift med en enda statisk förskjutning döljer bara symptomet vid en viss tidpunkt.
Verifiera att originalfilen är synkroniserad
Spela upp källan lokalt i en tillförlitlig skrivbordsspelare och använd direktuppspelning genom en kompatibel medieklient. Testa samma tidsintervall som hamnar ur synk under omkodningen.
Om källan också hamnar ur synk lokalt bör du granska eller reparera mediefilen innan du ändrar servern. Om källan förblir synkroniserad överallt utom i den omkodade sökvägen bör du behålla filen och samla in medieserverns uppspelningsbeslut, FFmpeg-kommandot och klientversionen.
Använd en andra fil med samma kodekar och en välfungerande tidslinje som kontroll. Om en enda titel har problem pekar det mot källans tidsstämplar eller behållarmetadata; om många titlar misslyckas på en klient pekar det mot en gemensam omkodare, segmenterare eller uppspelningssökväg.
Identifiera vilka strömmar som faktiskt konverteras
Kontrollera om sessionen utför ljudomkodning med videoströmmen kopierad, en ommuxning utan kodekkonvertering eller en fullständig omkodning av både video och ljud. Dessa sökvägar skapar olika tidsgränser.
Enbart ljudkonvertering kan fortfarande orsaka synkroniseringsfel efter en sökning. Ett Jellyfin-ärende återskapade ljud som hamnade ur synk efter sökning när E-AC-3 eller DTS konverterades till AAC medan videoströmmen kopierades.
Byt till ett ljudspår som stöds av klienten, utan att ändra video, kvalitet eller undertexter. Om sessionen då blir direktuppspelning och driften försvinner bör du fokusera på ljudtidsstämplar, omsampling, kanalkonvertering eller den genererade leveransbehållaren i stället för videokodningsprestanda.
ZimaSpaces översikt över ljudomkodningsflödet beskriver den närliggande mekanismen för att tolka detta test på strömnivå.
Testa uppspelning från början, efter sökning och efter återupptagning
Kör tre kontrollerade sessioner med samma klient och fil: oavbruten uppspelning från noll, en sökning förbi det buffrade området och återupptagning från en sparad position. Notera exakt när synkroniseringen förändras.
Det har rapporterats att omkodad 4K-uppspelning förblir synkroniserad från början men förskjuts efter spolning, kapitelbyten eller återupptagning. Den avgörande omständigheten är en förändring av tidslinjen under omkodning, inte den faktiska förmågan att avkoda mediet.
En separat Jellyfin-rapport visar synkroniseringsproblem som endast uppstår vid återupptagning, även när själva källfilen är korrekt. Det mönstret avgränsar hanteringen av återupptagning innan någon ommuxning av hela biblioteket görs.
Om endast sökning eller återupptagning misslyckas kan du testa en annan leveransbehållare eller klientspelare när programmet erbjuder det alternativet. Låt oavbruten uppspelning vara kontrollen så att resultatet kan kopplas till beteendet vid omstart av tidsstämplar.
Granska källans tidsinformation, bildfrekvens och metadata för ljudtöjning
Använd ett medieanalysverktyg för att registrera videons bildfrekvens och tidsbas, ljudets samplingsfrekvens, strömmarnas starttider, längd, negativa tidsstämplar, redigeringslistor samt eventuella värden för spårfördröjning eller töjning. Jämför de första och sista presentationstidsstämplarna.
Vissa Matroska-spår innehåller avsiktligt en linjär tidsjustering för att matcha ljud från en källa med en annan bildfrekvens. Ett Jellyfin-ärende beskriver linjärt förskjutna ljudspår som förblir användbara i originalbehållaren men hanteras felaktigt under omkodning.
Om ljudets längd skiljer sig proportionellt från videons längd kan du skapa en korrigerad testkopia som uttryckligen samplar om eller tidstänjer ljudet en gång och sedan muxar om det med rena tidsstämplar. Behåll originalet och testa en titel innan du tillämpar någon massreparation.
Kontrollera tidsstämplarnas beteende i HLS- eller fMP4-segment
Granska omkodarkommandot efter sökflaggor, kopiering av tidsstämplar, hantering av negativa tidsstämplar, HLS-segmenttyp, segmentlängd och om en ny omkodningsprocess startar när klienten flyttar sig bortom det buffrade innehållet.
En Jellyfin-undersökning av tidsstämplar visade att oprecis sökning kunde starta om en HLS-ström med en förskjutning från den ursprungliga tidslinjen. Det centrala felet var feljusterade omkodade tidsstämplar, vilket sedan påverkade klientens tidsstyrning.
Kopiera inte kommandoradsflaggor från en orelaterad version till en produktionsbehållare. Uppdatera eller återställ först servern och klienten inom de sökvägar som stöds, rensa endast återskapningsbara omkodningssegment och jämför MPEG-TS-, fMP4- eller uppspelning med den inbyggda spelaren när programmet erbjuder dessa alternativ.
Tillämpa den minsta korrigeringen och verifiera hela uppspelningen
Använd den gren som testerna visar är problemet: välj ett kompatibelt ljudspår eller en kompatibel klient, undvik den felande sök- eller återupptagningssökvägen, ändra den streamingbehållare som stöds, uppdatera eller lås medieserverversionen eller normalisera en källa med felaktig tidsmetadata.
Koda inte om alla filmer bara för att en TV-app hamnar ur synk. Ett klientspecifikt fel bör korrigeras på klient- eller uppspelningsprofilnivå, medan en källspecifik linjär drift hör hemma i en tidsreparation av den filen.
Verifiera den reparerade sökvägen från början till slut och upprepa sedan en sökning och återupptagning nära den ursprungliga felpunkten. Problemet är löst först när förskjutningen förblir stabil under hela uppspelningen, de genererade segmenten bevarar den förväntade tidslinjen och samma inställningar fungerar efter att klienten startats om och servern återskapats.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
