Jak strumieniowanie dla wielu użytkowników zmienia przebieg transkodowania w Jellyfinie

Wielu użytkowników korzystających ze streamingu zmienia Jellyfin z pojedynczej ścieżki odtwarzania we współdzieloną kolejkę, której wąskie gardło zależy od zgodności każdego klienta i przepływności.

W gospodarstwie domowym w ciągu kilku minut może zostać uruchomiony jeden strumień telewizyjny odtwarzany bezpośrednio, jedna sesja na tablecie z napisami oraz jedna zdalna sesja na telefonie. Żądania te nie zużywają zasobów w równym stopniu: jedno może jedynie odczytywać dane z magazynu, drugie może obciążać system wypalaniem napisów podczas transkodowania wideo, a zdalny klient może dodatkowo ograniczać wysyłanie danych. Zrozumienie tej nierównomiernej pracy jest bardziej użyteczne niż samo liczenie użytkowników.

Jedno żądanie użytkownika może przebiegać czterema różnymi ścieżkami

Jellyfin najpierw porównuje kontener multimedialny, kodek wideo, kodek audio, napisy, rozdzielczość i przepływność z informacjami przekazanymi przez klienta o obsługiwanych możliwościach. Na tej podstawie wybiera odtwarzanie bezpośrednie, remultipleksowanie, konwersję dźwięku albo pełne transkodowanie wideo, dlatego dwóch użytkowników otwierających ten sam tytuł może wygenerować zupełnie różne obciążenie serwera.

Klient akceptujący oryginalny plik przeważnie zmienia serwer jedynie w czytnik plików, podczas gdy niezgodna przeglądarka może wymagać dekodowania i kodowania. Praktyczne wyjaśnienie działania odtwarzania bezpośredniego pokazuje, dlaczego uniknięcie konwersji usuwa ze ścieżki znaczną część przetwarzania.

Widocznym rezultatem jest asymetryczne obciążenie: liczba strumieni może rosnąć bez proporcjonalnego wzrostu użycia procesora, dopóki jedno z żądań nie przekroczy granicy zgodności. Właściwą jednostką nie są więc „użytkownicy”, lecz zestaw sesji odtwarzanych bezpośrednio, remultipleksowanych, z transkodowanym dźwiękiem i z transkodowanym wideo.

Równoległe transkodowania konkurują na określonych etapach potoku

Pełne transkodowanie to łańcuch obejmujący odczyt, dekodowanie, filtrowanie, kodowanie, zapisywanie tymczasowych fragmentów i ich dostarczanie. Równoległość ma znaczenie, gdy kilka sesji wymaga tego samego ograniczonego zasobu, takiego jak sprzętowy silnik wideo, programowy renderer napisów, pamięć podręczna transkodowania albo łącze sieciowe do wysyłania danych.

Akceleracja sprzętowa może przenieść dekodowanie i kodowanie z ogólnych rdzeni procesora, ale nie eliminuje kosztów filtrowania, napisów, magazynu ani sieci. Rzeczywiste opisy transkodowania z akceleracją sprzętową konsekwentnie odróżniają odciążenie procesora graficznego od całkowicie nieobciążonego potoku.

Gdy najwolniejszy współdzielony etap nie jest w stanie wytwarzać multimediów szybciej, niż odtwarzanie je zużywa, kolejki rosną, a klientom kończy się bufor. Szybszy komponent w innym miejscu nie rozwiąże problemu: wolne zasoby procesora nie naprawią nasyconego łącza wysyłania, a wolne pasmo nie naprawi programowego wypalania napisów.

Kontrola nad oprogramowaniem open source zmienia planowanie wydajności

Jellyfin udostępnia decyzję dotyczącą odtwarzania i wykorzystuje konwersję opartą na FFmpeg, nie ukrywając akceleracji sprzętowej za płatnym poziomem subskrypcji. Dzięki temu cały przepływ można analizować i konfigurować, ale operator musi samodzielnie dopasować sterowniki, dostęp do urządzeń, kodeki i zachowanie klientów.

Wartość tej kontroli ujawnia się, gdy serwer domowy obsługuje kilka aplikacji, a właściciel może zdecydować, które zadania współdzielą GPU lub kiedy uruchamiane są zadania w tle. Potok ograniczeń klienta stanowi podstawę dla pojedynczej sesji; planowanie dla wielu użytkowników dodaje konkurencję między tymi potokami. Ta sama granica działania jest zgodna z działaniem odtwarzania bezpośredniego, gdy uwzględni się całą ścieżkę dostarczania.

Open source zmienia więc to, kto może dostrajać system, ale nie fizyczny koszt konwersji. Większa liczba elementów sterujących nie tworzy automatycznie większej przepustowości, a nieprawidłowa ścieżka akceleracji może po cichu przełączać pracę na procesor, mimo że interfejs nadal wygląda na dostępny.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gdzie liczba użytkowników przestaje przewidywać wydajność

Liczba użytkowników jest słabym predyktorem, gdy większość klientów korzysta z odtwarzania bezpośredniego; dwie trudne sesje HDR z napisami mogą kosztować więcej niż wiele zgodnych sesji w rozdzielczości 1080p. Zależność ta przestaje obowiązywać również wtedy, gdy magazyn danych lub wysyłanie danych jest już nasycone, ponieważ zdolność transkodowania nie jest wtedy czynnikiem kontrolującym.

Równoległość zdalnych sesji należy sprawdzać względem rzeczywistej dostępnej przepustowości wysyłania, a nie deklarowanej szybkości pobierania. Przykład planowania pasma oparty na dzieleniu wysyłania przez przepływność strumienia jasno pokazuje tę zależność ograniczającą, choć skokowe przepływności źródłowe nadal wymagają zapasu. Osobny raport z praktyki również potwierdza, że zamiast zakładać, iż widoczny objaw wskazuje wąskie gardło, należy korzystać ze wskaźników transkodowania na poziomie sesji.

Przed zmianą sprzętu prowadź czterowierszowy rejestr sesji: dla każdego jednoczesnego klienta zapisz tryb odtwarzania, przepływność źródłową i dostarczaną, metodę obsługi napisów oraz aktywny silnik CPU/GPU. Modernizuj sprzęt dopiero wtedy, gdy powtarzane testy wskażą ten sam nasycony etap; w przeciwnym razie najpierw zmień niezgodnego klienta, wersję multimediów albo docelową przepływność.