Was verursacht, dass der Ton erst nach der Transkodierung nicht mehr synchron ist?

Der Ton driftet nach der Transkodierung, wenn die erzeugte Audio-Timeline nicht mehr exakt mit derselben Rate oder an derselben Zeitstempelgrenze wie das Video fortschreitet.

Direct Play kann das Problem verbergen, da der Client den ursprünglichen Container und dessen native Timing-Anweisungen verwendet, während die Transkodierung einen oder beide Streams decodiert, neu sampelt, neu codiert, mit Zeitstempeln versieht, segmentiert und neu muxed. Stellen Sie zunächst fest, ob es sich um einen festen Versatz, einen allmählich zunehmenden Drift oder einen Sprung nach dem Suchen oder Fortsetzen handelt. Diese Muster weisen auf unterschiedliche Bereiche der Medienpipeline hin.

Synchronisationsfehler klassifizieren, bevor Sie den Transcoder ändern

Starten Sie die Wiedergabe am Anfang, ohne zu suchen, und notieren Sie den Versatz nahe dem Anfang, in der Mitte und am Ende. Verwenden Sie eine Szene mit einem sichtbaren Aufprall oder einem Sprachlaut statt einer Schätzung anhand von Hintergrundmusik.

Ein fester Versatz, der konstant bleibt, deutet auf einen anfänglichen Zeitstempel, eine Edit-Liste, eine Empfängerverzögerung oder eine Client-Einstellung hin. Eine Lücke, die gleichmäßig größer wird, weist auf nicht übereinstimmende Taktraten, eine falsche Bildrateninterpretation, Audio-Stretching oder Resampling hin. Ein plötzlicher Sprung nach dem Suchen oder Fortsetzen deutet auf Segment- und Neustart-Zeitstempel hin.

Wiederholen Sie die Messung mit deaktivierten Untertiteln und einer manuellen Audioverzögerung des Clients von null. Einen zunehmenden Drift mit einem einzigen statischen Versatz zu korrigieren, kaschiert das Symptom nur an einem bestimmten Zeitstempel.

Nachweisen, dass die Originaldatei synchron ist

Geben Sie die Quelle lokal in einem vertrauenswürdigen Desktop-Player wieder und verwenden Sie sie über einen kompatiblen Medienclient per Direct Play. Testen Sie denselben Zeitbereich, in dem die Transkodierung den Drift verursacht.

Wenn die Quelle auch lokal driftet, prüfen oder reparieren Sie die Mediendatei, bevor Sie den Server ändern. Bleibt die Quelle überall synchron, außer über den transkodierten Pfad, bewahren Sie die Datei auf und erfassen Sie die Wiedergabeentscheidung des Medienservers, den FFmpeg-Befehl und die Clientversion.

Verwenden Sie als Kontrolle eine zweite Datei mit denselben Codecs und einer nachweislich korrekten Timeline. Ein einzelner problematischer Titel deutet auf Quellzeitstempel oder Container-Metadaten hin; bei vielen Titeln, die auf einem Client fehlschlagen, liegt die Ursache eher in einem gemeinsamen Transcoder-, Segmentierungs- oder Wiedergabepfad.

Ermitteln, welche Streams tatsächlich konvertiert werden

Prüfen Sie, ob die Sitzung nur den Ton transkodiert und den Videostream kopiert, ob ein Remuxing ohne Codec-Konvertierung erfolgt oder ob Video und Audio vollständig transkodiert werden. Diese Pfade erzeugen unterschiedliche Timing-Grenzen.

Auch eine reine Audiokonvertierung kann nach dem Suchen zu einer Desynchronisierung führen. Ein Jellyfin-Problem reproduzierte eine Desynchronisierung des Tons nach dem Suchen, wenn E-AC-3 oder DTS in AAC konvertiert wurde, während der Videostream kopiert blieb.

Wechseln Sie zu einer vom Client unterstützten Audiospur, ohne Video, Qualität oder Untertitel zu verändern. Wird die Sitzung dadurch zu Direct Play und verschwindet der Drift, konzentrieren Sie sich auf Audiozeitstempel, Resampling, Kanalumwandlung oder den erzeugten Auslieferungscontainer statt auf die Leistung der Videocodierung.

Die ZimaSpace-Übersicht zur Audiotranskodierungspipeline erklärt den angrenzenden Mechanismus zur Interpretation dieses Stream-Tests.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Wiedergabe vom Anfang, nach dem Suchen und nach dem Fortsetzen testen

Führen Sie mit demselben Client und derselben Datei drei kontrollierte Sitzungen durch: ununterbrochene Wiedergabe ab null, einen Sprung über den gepufferten Bereich hinaus und das Fortsetzen an einer gespeicherten Position. Notieren Sie genau, wann sich die Synchronisation ändert.

Es wurde berichtet, dass die transkodierte 4K-Wiedergabe vom Anfang an synchron bleibt, sich aber nach dem Verschieben des Wiedergabepunkts, Kapitelwechseln oder dem Fortsetzen verschiebt. Ausschlaggebend ist eine Änderung der Timeline während der Transkodierung, nicht die grundsätzliche Fähigkeit, das Medium zu decodieren.

Ein separater Jellyfin-Bericht zeigt eine Desynchronisierung speziell beim Fortsetzen, obwohl die Quelldatei selbst korrekt ist. Dieses Muster grenzt die Ursache auf die Fortsetzungsbehandlung vor einem allgemeinen Remuxing ein.

Wenn nur das Suchen oder Fortsetzen fehlschlägt, testen Sie einen anderen Auslieferungscontainer oder Client-Player, sofern die Anwendung diese Option anbietet. Verwenden Sie die ununterbrochene Wiedergabe als Kontrolle, damit das Ergebnis eindeutig dem Verhalten beim Neustart der Zeitstempel zugeordnet werden kann.

Quell-Timing, Bildrate und Audio-Stretching-Metadaten prüfen

Verwenden Sie ein Medienanalysewerkzeug, um Bildrate und Zeitbasis des Videos, Audio-Samplerate, Startzeiten der Streams, Dauer, negative Zeitstempel, Edit-Listen sowie Verzögerungs- oder Stretching-Werte der Spuren zu erfassen. Vergleichen Sie den ersten und letzten Präsentationszeitstempel.

Einige Matroska-Spuren enthalten absichtlich eine lineare Timing-Anpassung, um den Ton an eine Quelle mit anderer Bildrate anzupassen. Ein Jellyfin-Problem beschreibt linear driftende Audiospuren, die im ursprünglichen Container weiterhin nutzbar sind, während sie bei der Transkodierung fehlerhaft behandelt werden.

Wenn sich die Audiodauer proportional von der Videodauer unterscheidet, erstellen Sie eine korrigierte Testkopie, in der der Ton einmal ausdrücklich neu gesampelt oder zeitlich gedehnt wird, und muxen Sie ihn anschließend mit sauberen Zeitstempeln neu. Bewahren Sie das Original auf und testen Sie zunächst nur einen Titel, bevor Sie eine Stapelreparatur anwenden.

Zeitstempelverhalten von HLS- oder fMP4-Segmenten prüfen

Prüfen Sie den Transcoder-Befehl auf Suchoptionen, das Kopieren von Zeitstempeln, den Umgang mit negativen Zeitstempeln, den HLS-Segmenttyp, die Segmentdauer und darauf, ob ein neuer Transkodierungsprozess startet, nachdem der Client den gepufferten Bereich verlässt.

Eine Untersuchung von Jellyfin-Zeitstempeln ergab, dass ungenaues Suchen einen HLS-Stream mit einem Versatz zur ursprünglichen Timeline neu starten konnte. Der entscheidende Fehler waren fehlerhaft ausgerichtete transkodierte Zeitstempel, die anschließend das vom Client dargestellte Timing beeinflussten.

Übernehmen Sie keine Befehlszeilenoptionen aus einer nicht verwandten Version in einen Produktionscontainer. Aktualisieren Sie zunächst den Server und den Client innerhalb unterstützter Pfade oder führen Sie ein Rollback durch, löschen Sie ausschließlich regenerierbare Transkodierungssegmente und vergleichen Sie MPEG-TS-, fMP4- oder native-Player-Verhalten, sofern die Anwendung diese Auswahlmöglichkeiten bietet.

Die kleinste Korrektur anwenden und über die gesamte Dauer prüfen

Verwenden Sie den durch Tests bestätigten Ansatz: Wählen Sie eine kompatible Audiospur oder einen kompatiblen Client, vermeiden Sie den fehlerhaften Such- oder Fortsetzungspfad, ändern Sie den unterstützten Streaming-Container, aktualisieren oder fixieren Sie den Build des Medienservers oder normalisieren Sie eine Quelle mit fehlerhaften Timing-Metadaten.

Codieren Sie nicht jeden Film neu, nur weil eine Fernsehanwendung driftet. Ein clientspezifischer Fehler sollte auf der Client- oder Wiedergabeprofil-Ebene behoben werden, während ein quellenspezifischer linearer Drift in der Timing-Reparatur dieser Datei korrigiert werden sollte.

Prüfen Sie den reparierten Pfad vom Anfang bis zum Ende und wiederholen Sie anschließend einen Suchvorgang sowie das Fortsetzen nahe dem ursprünglichen Fehlerpunkt. Das Problem ist erst behoben, wenn der Versatz über die gesamte Dauer stabil bleibt, die erzeugten Segmente die erwartete Timeline beibehalten und dieselben Einstellungen auch nach einem Neustart des Clients und einer Neuerstellung des Servers bestehen bleiben.