Dlaczego odtwarzanie HDR z napisami zmienia harmonogramowanie zasobów Jellyfin

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why HDR Playback With Subtitles Changes Jellyfin Resource Scheduling - Zima Store Online

Odtwarzanie HDR z napisami często zmienia sposób planowania zadań przez Jellyfin, ponieważ wypalanie napisów i mapowanie tonów może przekształcić lekkie żądanie Direct Play w połączony potok konwersji.

Telewizor w salonie może bezpośrednio dekodować plik 4K HDR do momentu wybrania graficznej ścieżki napisów, podczas gdy tablet może wymagać obrazu SDR z tego samego źródła. Jellyfin musi wtedy jednocześnie spełnić ograniczenia dotyczące obrazu, kolorów, napisów i przepływności. Problem planowania nie polega po prostu na tym, że „HDR jest wymagający”, lecz na tym, czy każdy etap działa na obsługiwanym sprzęcie, czy też przechodzi na współdzielone zasoby procesora.

Kompatybilność napisów decyduje o konieczności ponownego przetworzenia obrazu

Napisy tekstowe można czasami przesyłać osobno, ale formaty graficzne lub nieobsługiwane style mogą wymagać renderowania napisów przez Jellyfin na każdej klatce obrazu. Po zmianie pikseli serwer nie może już wysłać oryginalnego, zakodowanego obrazu bez zmian i musi ponownie go zdekodować, połączyć z napisami oraz zakodować.

Macierz obsługiwanych funkcji klientów ma znaczenie, ponieważ wypalanie napisów graficznych jest opisywane jako wyzwalacz pełnego transkodowania, a nie niewielkie zadanie ograniczone do tekstu. To przejście wyjaśnia, dlaczego wybranie napisów może natychmiast spowodować skok użycia procesora lub karty graficznej.

Efekt zależy od klienta: ten sam plik napisów może pozostać zewnętrzny na jednym odtwarzaczu, a na innym zostać wypalony w obraz. Dlatego planowanie powinno traktować sposób obsługi napisów jako wymiar obciążenia, a nie kosmetyczną preferencję dodawaną po dostarczeniu obrazu.

HDR dodaje zależność od konwersji kolorów

Gdy źródło HDR musi być odtwarzane na wyświetlaczu SDR, serwer może potrzebować mapowania tonów, aby dopasować jasne partie obrazu i zakresy kolorów do urządzenia docelowego. Jeśli napisy są również wypalane w obrazie, etapy konwersji kolorów i łączenia napisów muszą mieć zgodny format pikseli oraz obsługę sprzętową przed końcowym kodowaniem.

Praktyczny przegląd transkodowania wskazuje, że mapowanie tonów HDR zależy od zgodnej obsługi dekodowania, filtrowania i kodowania, a nie od samej obecności dowolnej karty graficznej. Częściowo sprzętowa ścieżka nadal może przekazywać kosztowny filtr do procesora.

Ten łańcuch zależności zmienia planowanie z pojedynczego zadania akceleratora w zadanie korzystające z wielu rodzajów zasobów. Samo użycie karty graficznej może wyglądać umiarkowanie, podczas gdy etap jednowątkowy lub transfer danych między pamięciami ogranicza liczbę klatek dostarczanych do kodera.

Dlaczego płynność spada, zanim średnie użycie zasobów osiągnie maksimum

Odtwarzanie wymaga stałego generowania danych z prędkością wyższą niż rzeczywista, a nie dobrego wyniku średniego obliczonego dla kilku minut. Krótkie skoki obciążenia związane z renderowaniem napisów, złożonością scen, odczytem z pamięci masowej lub inną sesją mogą opóźnić utworzenie segmentu na tyle, że niewielki bufor klienta się opróżni.

Doniesienia o problemach z synchronizacją napisów pokazują, że widoczna awaria może dotyczyć synchronizacji lub ciągłości odtwarzania, a nie wyraźnego komunikatu o wyczerpaniu zasobów. Średnie wartości procentowe użycia procesora mogą ukrywać jeden przeciążony etap albo krótkie opóźnienia w planowaniu zadań.

Dlatego płynność zależy od zapasu mocy i najgorszych klatek. Potok osiągający średnio 1,2-krotność prędkości odtwarzania może nadal się zacinać, jeśli w złożonych scenach prędkość wielokrotnie spada poniżej 1,0, a klient nie może zgromadzić wystarczającego bufora pomiędzy nimi.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Gdzie akceleracja sprzętowa nie wystarcza

Akceleracja sprzętowa pomaga tylko wtedy, gdy wybrane urządzenie obsługuje kodek źródłowy, głębię bitową, ścieżkę mapowania tonów, sposób łączenia napisów oraz kodek wyjściowy używany przez daną sesję. Nieobsługiwane kombinacje mogą przełączać przetwarzanie na oprogramowanie lub powodować wielokrotne przenoszenie klatek między pamięcią procesora i karty graficznej.

Ta granica wyjaśnia, dlaczego szerszy model buforowania Jellyfin traktuje odtwarzanie jako kompleksową ścieżkę, a nie wyłącznie problem karty graficznej. Pamięć masowa, zapisy w pamięci podręcznej i buforowanie po stronie klienta mogą nadal ograniczać wydajność po włączeniu akceleracji. Osobny raport terenowy również przemawia za wykonywaniem testów napisów i mapowania tonów, zamiast zakładania, że widoczny objaw wskazuje konkretne wąskie gardło.

Przetestuj jeden reprezentatywny tytuł HDR z wyłączonymi napisami, z włączonymi napisami tekstowymi oraz z włączonymi napisami graficznymi. Dla każdego przebiegu zanotuj tryb odtwarzania, prędkość transkodowania, obciążenie procesora, obciążenie silnika wideo oraz dostarczany format kolorów; rezerwuj zasoby na podstawie najwolniejszej prawidłowej kombinacji, a nie najłatwiejszego wyniku Direct Play.