Dlaczego odtwarzanie w Jellyfin różni się między klientem natywnym a przeglądarkowym
Odtwarzanie w Jellyfin różni się, ponieważ aplikacje natywne i przeglądarki deklarują inne możliwości w zakresie kodeków, napisów, HDR, dekodowania i buforowania.
Ten sam plik może być odtwarzany bezpośrednio w aplikacji telewizora, ale w przeglądarce może uruchomić remultipleksowanie lub pełne transkodowanie. Zmienia to zarówno format wyjściowy, jak i wykorzystywane zasoby serwera. Nie zmieniaj pliku multimedialnego, sieci ani serwera — zmieniaj tylko klienta, aby zaobserwowana różnica wynikała z jego możliwości lub sposobu renderowania.
Negocjacja możliwości wybiera ścieżkę odtwarzania
Jellyfin porównuje kontener źródłowy, obraz, dźwięk, tryb HDR i napisy z tym, co klient może zaakceptować. Brak jednej z możliwości zmienia tanią ścieżkę dostarczania w dodatkową pracę konwersyjną.
Przed oceną jakości odtwarzania zapisz tryb profilu możliwości klienta dla jednego znanego pliku na obu klientach.
Dlatego „te same multimedia” nie oznaczają takiego samego obciążenia serwera.
Ograniczenia przeglądarki mogą przenieść pracę na serwer
Przeglądarki często korzystają z węższego lub innego zestawu możliwości multimedialnych niż aplikacje natywne. Nieobsługiwany dźwięk, HDR, napisy lub kontenery mogą wymagać remultipleksowania albo transkodowania obrazu, nawet gdy sama przeglądarka działa szybko.
Rzeczywiste porównanie obciążenia transkodowaniem pomaga pokazać, kiedy obsługa po stronie klienta zmienia ścieżkę serwera.
Jeśli przypadek z przeglądarką korzysta z bardziej obciążającej ścieżki, różnica w danych wyjściowych wynika ze zgodności, a nie z tajemniczych preferencji serwera.
Dekodowanie po stronie klienta również wpływa na płynność
Natywne urządzenie może korzystać z dekodowania sprzętowego, podczas gdy przeglądarka używa innego dekodera lub strategii buforowania. Wpływa to na uruchamianie, przewijanie, pomijane klatki i baterię, niekoniecznie zmieniając przepustowość po stronie serwera.
Artykuł zachowanie klienta Jellyfin rozdziela obsługę kodeków, dekodowanie sprzętowe i responsywność interfejsu jako odrębne pomiary.
Testy odtwarzania i interfejsu przeprowadzaj osobno: szybka siatka plakatów nie dowodzi płynnego odtwarzania strumienia o wysokiej przepływności.
Użyj kontroli klienta dla znanego pliku
Odtwórz jeden plik w aplikacji natywnej i przeglądarce przy tych samych warunkach sieciowych i serwerowych. Zapisz tryb odtwarzania, czas do wyświetlenia pierwszej klatki, bufor w stanie ustalonym oraz zachowanie klatek po stronie klienta.
Skorzystaj z porównania klientów Jellyfin dopiero po ustaleniu ścieżki odtwarzania; w przeciwnym razie opóźnienie interfejsu można pomylić z problemem z dostarczaniem strumienia.
Zakończ analizę, gdy zmienione możliwości klienta wyjaśniają dane wyjściowe i metryki serwera. Nie dostosowuj sprzętu serwera do ograniczenia renderowania występującego wyłącznie po stronie klienta.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Dlaczego architektura Home Assistant zmienia się, gdy serwer domowy obsługuje więcej usług?
Więcej usług zmienia architekturę Home Assistanta, gdy dodają współdzielony stan, kolejki, urządzenia, cykle aktualizacji lub domeny awarii — a nie tylko więcej kontenerów.
Jak mierzyć wydajność Home Assistant, nie myląc pamięci podręcznej z możliwościami sprzętu
Ciepły wynik potwierdza ponowne wykorzystanie, a nie wydajność. Zmierz zimny start, ciepły stan ustalony, powtarzające się obciążenie, opóźnienie ogona oraz pierwszy zasób, który osiąga...
Ile równoległych automatyzacji potrzebuje Home Assistant do sterowania całym domem?
Większość automatyzacji obejmujących cały dom wymaga jedynie ograniczonego nakładania się uruchomień; określ maksymalną równoległość na podstawie czasu trwania uruchomienia × częstotliwości wyzwalania, a następnie...
