Bezpośrednie odtwarzanie a transkodowanie na serwerze dla użytkowników zdalnych przy ograniczonej prędkości wysyłania

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.

Direct Play vs Server Transcoding for Remote Users on Limited Upload - Zima Store Online

W przypadku użytkowników zdalnych korzystających z ograniczonego wysyłania danych z domu funkcja Direct Play jest najlepsza tylko wtedy, gdy oryginalny plik mieści się w dostępnym paśmie wysyłania, a klient potrafi go dekodować. Transkodowanie na serwerze staje się lepszym rozwiązaniem, gdy przepływność źródła jest wyższa niż możliwy do utrzymania limit wysyłania, ponieważ jej zmniejszenie może umożliwić dostarczenie zdalnego strumienia, który w innym przypadku byłby niemożliwy do odtworzenia. Wybór powinien więc opierać się najpierw na zmierzonym zapasie przepustowości wysyłania, a następnie na zgodności klienta i wydajności transkodowania serwera.

Zmierz limit wysyłania, zanim wybierzesz sposób odtwarzania

Zdalny strumień przechodzi przez domowe połączenie internetowe, zanim dotrze do klienta. Jeśli serwer ma 20 Mb/s niezawodnej przepustowości wysyłania, a oryginalny plik regularnie przekracza ten limit, funkcja Direct Play może powodować buforowanie, mimo że zużywa niemal żadnych zasobów obliczeniowych serwera.

Plex udostępnia ustawienia wysyłania po stronie serwera i zdalnych limitów przepływności właśnie dlatego, że łącze wychodzące może być zasobem ograniczającym. Zalecenia Jellyfin dotyczące wyboru sprzętu również traktują przepustowość wysyłania jako wymóg zdalnego dostępu, zamiast zakładać warunki typowe dla szybkości sieci LAN.

Jeśli przykładowy plik źródłowy mieści się w zmierzonym limicie wysyłania z zapasem, wybierz Direct Play. Jeśli nie, szybszy klient nie zwiększy przepustowości wysyłania; przed odtworzeniem trzeba albo zmniejszyć przepływność multimediów, albo pozwolić serwerowi na transkodowanie do mniejszego zdalnego strumienia.

Direct Play wygrywa, gdy oryginalny plik mieści się w budżecie łącza WAN

Direct Play zachowuje oryginalne strumienie wideo i audio oraz eliminuje konieczność ponownego kodowania. Dzięki temu sprawdza się idealnie, gdy klient obsługuje użyte kodeki, a domowe połączenie może dostarczyć źródłową przepływność z wystarczającym zapasem na typowe wahania sieci.

Ta ścieżka zachowuje również jakość źródłową, ponieważ serwer nie tworzy nowej, skompresowanej wersji. Jej słabością jest brak elastyczności: remuks 4K lub inne źródło o wysokiej przepływności pozostaje źródłem o wysokiej przepływności, nawet gdy zdalne połączenie jest znacznie węższe.

Wybierz Direct Play, gdy przepustowość wysyłania znajduje się wyraźnie powyżej rzeczywistych wartości szczytowych pliku, a nie tylko powyżej jego deklarowanej średniej. Wybór zmienia się, gdy powtarzające się przeciążenie sieci, a nie obciążenie serwera, staje się główną przyczyną buforowania.

Transkodowanie wygrywa, gdy zmniejszenie przepływności rozwiązuje rzeczywiste ograniczenie

Transkodowanie na serwerze zamienia zasoby obliczeniowe na przepustowość. Serwer dekoduje źródło i koduje wyjście o niższej przepływności, które łatwiej przesłać przez ograniczone łącze wychodzące, przekształcając wąskie gardło WAN w zadanie obliczeniowe.

Potok kodeków i sterowania wyjściem FFmpeg odzwierciedla mechanizm tego kompromisu: generowany jest nowy strumień wyjściowy, a oryginalne pakiety nie są jedynie przekazywane dalej. Ta praca wymaga zasobów procesora lub akceleratora sprzętowego, ale zapewnia serwerowi kontrolę nad parametrami wyjścia.

To lepsza droga, gdy oryginalna przepływność po prostu nie mieści się w przepustowości łącza, a serwer ma wystarczający zapas mocy do transkodowania w czasie rzeczywistym. Nie jest to lepsza opcja, gdy oryginał już się mieści, ponieważ dodatkowe ponowne kodowanie zwiększa obciążenie i pogarsza jakość, nie rozwiązując problemu z przepustowością.

-15% OFF

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

Single board computer zimaboard2

Testuj stabilną przepustowość, a nie nazwę pakietu operatora

Deklarowana przez operatora prędkość wysyłania nie jest tym samym co stabilna przepustowość aplikacji. Przeciążenie, Wi-Fi po stronie serwera, działanie routera, inne wysyłane dane, kopie zapasowe w chmurze i rozmowy wideo domowników mogą zmniejszyć zapas dostępny dla zdalnej sesji multimedialnej.

Narzędzie do pomiaru sieci iperf3 firmy ESnet służy do pomiaru osiągalnej wydajności sieci. W przypadku domowych multimediów najważniejsze jest ustalenie powtarzalnego limitu, zanim obwinisz szybkość transkodera lub dekodowanie po stronie klienta.

Przestań dostrajać serwer multimediów, jeśli łącze wychodzące jest niestabilne nawet przy strumieniu testowym o niskiej przepływności. Najpierw napraw ścieżkę sieciową. Jeśli natomiast sieć jest stabilna, ale transkodowana sesja nie może utrzymać przetwarzania w czasie rzeczywistym, ograniczenie przeniosło się z przepustowości na moc obliczeniową serwera.

Zgodność klienta może wyeliminować potrzebę transkodowania wideo

Ograniczone łącze wysyłające nie oznacza, że każdy strumień należy transkodować. Jeśli klient obsługuje oryginalne wideo, audio, kontener i napisy, Direct Play pozostaje najtańszą ścieżką, o ile przepływność mieści się w limicie.

Przewodnik ZimaSpace dotyczący wąskich gardeł ścieżki odtwarzania i zgodności klienta wyjaśnia, dlaczego możliwości klienta należy sprawdzić przed zakupem większej mocy transkodowania. Zgodne urządzenie końcowe może wyeliminować niepotrzebną konwersję, ale nie poradzi sobie z plikiem źródłowym, którego przepływność przekracza budżet WAN.

Wykorzystuj zgodność, aby unikać zbędnego transkodowania, a transkodowanie — aby rozwiązywać rzeczywiste niedopasowanie przepływności. Traktuj te kwestie jako dwa oddzielne warunki, zamiast zakładać, że jedna opcja jest zawsze lepsza.

Wstępnie zakodowane wersje zdalne mogą być lepsze niż oba skrajne rozwiązania

Istnieje też trzecia możliwość operacyjna, choć nie jest ona głównym przedmiotem porównania: zachowaj wysokiej jakości kopię lokalną i wcześniej utwórz wersję o niższej przepływności do użytku zdalnego. W ten sposób przenosisz obciążenie obliczeniowe poza okno odtwarzania na żywo.

Proces kodowania ze stałą jakością w HandBrake ilustruje podejście offline. Może być przydatny, gdy zdalne odtwarzanie jest częste, ale serwer jest zbyt słaby, aby obsłużyć kilka transkodowań w czasie rzeczywistym.

Korzystaj z tego hybrydowego rozwiązania tylko wtedy, gdy upraszcza ono powtarzające się ograniczenie; nie duplikuj całej biblioteki z powodu jednego sporadycznego zdalnego odtwarzania przy wąskim łączu. Główna decyzja pozostaje taka sama: Direct Play, gdy przepustowość wystarcza, oraz transkodowanie w czasie rzeczywistym, gdy nie wystarcza, ale dostępna jest moc obliczeniowa.

Wybierz pierwsze wąskie gardło na zdalnej ścieżce

Wybierz Direct Play, gdy plik źródłowy mieści się w stabilnym limicie wysyłania, a klient potrafi go dekodować. Zachowuje to jakość źródłową i ogranicza zużycie zasobów serwera.

Wybierz transkodowanie na serwerze, gdy przepływność źródła przekracza dostępną przepustowość wysyłania, a serwer może w czasie rzeczywistym utworzyć wymagany strumień o niższej przepływności. Jeśli żaden z tych warunków nie jest spełniony, żadna z opcji nie rozwiązuje rzeczywistego problemu.

Granicę można zmierzyć: gdy test zdalny wykazuje stabilny zapas przepustowości wysyłania, zgodnego klienta i ścieżkę odtwarzania utrzymującą się przed czasem rzeczywistym, dalsze modernizowanie serwera nie poprawi niezawodności. Modernizuj tylko ten zasób, którego faktycznie zaczyna brakować.