Co powoduje rozjeżdżanie się synchronizacji dźwięku dopiero po transkodowaniu?

Dźwięk rozjeżdża się po transkodowaniu, gdy wygenerowana oś czasu dźwięku nie przesuwa się już dokładnie w tym samym tempie lub według tych samych granic znaczników czasu co obraz.

Odtwarzanie bezpośrednie może ukrywać problem, ponieważ klient korzysta z oryginalnego kontenera i jego natywnych instrukcji synchronizacji, podczas gdy transkodowanie dekoduje, ponownie próbuje, koduje, opatruje znacznikiem czasu, dzieli na segmenty i ponownie multipleksuje jeden lub oba strumienie. Zacznij od ustalenia, czy błąd jest stałym przesunięciem, stopniowo narastającym rozjazdem, czy skokiem pojawiającym się po przewinięciu lub wznowieniu odtwarzania. Te wzorce wskazują różne elementy potoku multimedialnego.

Sklasyfikuj błąd synchronizacji przed zmianą transkodera

Odtwórz materiał od początku bez przewijania i zapisz przesunięcie na początku, w środku oraz pod koniec. Użyj sceny z widocznym uderzeniem lub spółgłoską w wypowiedzi zamiast oceniać synchronizację na podstawie muzyki w tle.

Stałe przesunięcie, które się nie zmienia, sugeruje początkowy znacznik czasu, listę edycji, opóźnienie odbiornika lub ustawienie klienta. Luka, która stale narasta, wskazuje na niedopasowane częstotliwości zegara, interpretację liczby klatek, rozciąganie dźwięku lub ponowne próbkowanie. Nagły skok po przewinięciu lub wznowieniu wskazuje na znaczniki czasu segmentów i ponownego uruchomienia.

Powtórz pomiar przy wyłączonych napisach i z ręcznym ustawieniem opóźnienia dźwięku klienta równym zero. Korygowanie narastającego rozjazdu jednym stałym przesunięciem jedynie ukrywa objaw przy jednym znaczniku czasu.

Potwierdź, że oryginalny plik jest zsynchronizowany

Odtwórz źródło lokalnie w zaufanym odtwarzaczu komputerowym i za pomocą odtwarzania bezpośredniego przez zgodnego klienta multimedialnego. Sprawdź ten sam zakres znaczników czasu, w którym występuje rozjazd podczas transkodowania.

Jeśli źródło również rozjeżdża się lokalnie, sprawdź lub napraw plik multimedialny przed zmianą ustawień serwera. Jeśli źródło pozostaje zsynchronizowane wszędzie poza ścieżką transkodowania, zachowaj plik i zbierz informacje o decyzji serwera multimediów dotyczącej odtwarzania, poleceniu FFmpeg oraz wersji klienta.

Użyj drugiego pliku z tymi samymi kodekami i prawidłową osią czasu jako materiału kontrolnego. Problem dotyczący jednego tytułu wskazuje na znaczniki czasu źródła lub metadane kontenera; problemy wielu tytułów na jednym kliencie wskazują na wspólny transkoder, segmenter lub ścieżkę odtwarzacza.

Ustal, które strumienie są faktycznie konwertowane

Sprawdź, czy sesja wykonuje transkodowanie tylko dźwięku przy kopiowaniu strumienia wideo, remuksowanie bez konwersji kodeka, czy pełne transkodowanie obrazu i dźwięku. Te ścieżki tworzą różne granice synchronizacji.

Sama konwersja dźwięku nadal może powodować desynchronizację po przewinięciu. Zgłoszenie dotyczące Jellyfin odtworzyło przypadek desynchronizacji dźwięku po przewinięciu, gdy E-AC-3 lub DTS konwertowano do AAC, a strumień wideo pozostawał kopiowany.

Przełącz na obsługiwaną przez klienta ścieżkę dźwiękową, pozostawiając bez zmian obraz, jakość i napisy. Jeśli sesja przejdzie w tryb odtwarzania bezpośredniego, a rozjazd zniknie, skup się na znacznikach czasu dźwięku, ponownym próbkowaniu, konwersji kanałów lub wygenerowanym kontenerze dostarczania, a nie na wydajności kodowania obrazu.

Opis potoku transkodowania dźwięku w ZimaSpace przedstawia powiązany mechanizm pomocny w interpretacji tego testu na poziomie strumieni.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przetestuj odtwarzanie od początku, po przewinięciu i po wznowieniu

Przeprowadź trzy kontrolowane sesje z tym samym klientem i plikiem: nieprzerwane odtwarzanie od zera, przewinięcie poza buforowany obszar oraz wznowienie z zapisanej pozycji. Zapisz dokładnie moment, w którym zmienia się synchronizacja.

Zgłaszano, że odtwarzanie transkodowanego materiału 4K pozostaje zsynchronizowane od początku, ale rozjeżdża się po przewijaniu, zmianie rozdziału lub wznowieniu. Warunkiem rozstrzygającym jest zmiana osi czasu podczas transkodowania, a nie sama możliwość dekodowania materiału.

W innym zgłoszeniu dotyczącym Jellyfin opisano desynchronizację specyficzną dla wznowienia, mimo że sam plik źródłowy był prawidłowy. Ten wzorzec wskazuje na obsługę wznawiania jeszcze przed ponownym multipleksowaniem całej biblioteki.

Jeśli problem występuje tylko po przewinięciu lub wznowieniu, przetestuj inny kontener dostarczania albo odtwarzacz klienta, gdy aplikacja udostępnia taką opcję. Zachowaj nieprzerwane odtwarzanie jako próbę kontrolną, aby wynik można było przypisać zachowaniu znaczników czasu przy ponownym uruchomieniu.

Sprawdź synchronizację źródła, liczbę klatek i metadane rozciągania dźwięku

Za pomocą narzędzia do analizy multimediów zapisz liczbę klatek i bazę czasu obrazu, częstotliwość próbkowania dźwięku, początkowe znaczniki czasu strumieni, czas trwania, ujemne znaczniki czasu, listy edycji oraz wszelkie wartości opóźnienia lub rozciągnięcia ścieżki. Porównaj pierwszy i ostatni znacznik czasu prezentacji.

Niektóre ścieżki Matroska celowo zawierają liniową korektę synchronizacji, aby dopasować dźwięk ze źródła o innej liczbie klatek. W zgłoszeniu dotyczącym Jellyfin opisano liniowo rozjeżdżające się ścieżki dźwiękowe, które pozostają użyteczne w oryginalnym kontenerze, ale są nieprawidłowo obsługiwane podczas transkodowania.

Jeśli czas trwania dźwięku różni się proporcjonalnie od czasu trwania obrazu, utwórz poprawioną kopię testową, która jawnie ponownie próbuje lub rozciąga czasowo dźwięk, a następnie ponownie multipleksuje go z czystymi znacznikami czasu. Zachowaj oryginał i przetestuj jeden tytuł przed zastosowaniem naprawy zbiorczej.

Sprawdź zachowanie znaczników czasu segmentów HLS lub fMP4

Przeanalizuj polecenie transkodera pod kątem flag przewijania, kopiowania znaczników czasu, obsługi ujemnych znaczników czasu, typu segmentów HLS, długości segmentów oraz tego, czy po wyjściu klienta poza buforowaną treść uruchamiany jest nowy proces transkodowania.

Analiza znaczników czasu w Jellyfin wykazała, że nieprecyzyjne przewijanie może ponownie uruchomić strumień HLS z przesunięciem względem oryginalnej osi czasu. Kluczowym problemem były niezgodne znaczniki czasu transkodowanego materiału, które następnie wpływały na synchronizację renderowaną przez klienta.

Nie kopiuj flag wiersza poleceń z niepowiązanej wersji do kontenera produkcyjnego. Najpierw zaktualizuj lub wycofaj serwer i klienta w ramach obsługiwanych ścieżek, usuń tylko możliwe do odtworzenia segmenty transkodowania i porównaj zachowanie MPEG-TS, fMP4 lub natywnego odtwarzacza, gdy aplikacja udostępnia takie opcje.

Zastosuj najmniejszą poprawkę i przeprowadź weryfikację przez cały czas trwania materiału

Skorzystaj ze ścieżki potwierdzonej testami: wybierz zgodną ścieżkę dźwiękową lub klienta, unikaj problematycznej ścieżki przewijania lub wznawiania, zmień obsługiwany kontener przesyłania strumieniowego, zaktualizuj lub przypnij wersję serwera multimediów albo znormalizuj jedno źródło z uszkodzonymi metadanymi synchronizacji.

Nie koduj ponownie każdego filmu tylko dlatego, że jedna aplikacja telewizyjna powoduje rozjazd. Problem dotyczący konkretnego klienta należy korygować na poziomie klienta lub profilu odtwarzania, natomiast liniowy rozjazd dotyczący konkretnego źródła należy naprawić w metadanych synchronizacji tego pliku.

Zweryfikuj poprawioną ścieżkę od początku do końca, a następnie powtórz przewinięcie i wznowienie w pobliżu pierwotnego punktu awarii. Problem można uznać za rozwiązany dopiero wtedy, gdy przesunięcie pozostaje stabilne przez cały czas trwania materiału, wygenerowane segmenty zachowują oczekiwaną oś czasu, a te same ustawienia działają po ponownym uruchomieniu klienta i odtworzeniu serwera.