Direct Play a Direct Stream a transkodowanie: która opcja wykorzystuje zasoby serwera?

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 Direct Stream vs Transcoding: Which Path Uses Server Resources? - Zima Store Online

Direct Play wykorzystuje najmniej zasobów obliczeniowych serwera, ponieważ oryginalne multimedia mogą zostać dostarczone bez zmiany ich strumieni. Direct Stream wymaga większego nakładu pracy serwera, ponieważ serwer przepakowuje multimedia i może konwertować niezgodny strumień audio lub napisów, ale nadal może pozostawić obraz bez zmian. Pełne transkodowanie wykorzystuje najwięcej zasobów, ponieważ obraz musi zostać zdekodowany, przetworzony i ponownie zakodowany. Właściwą ścieżką nie jest więc ta z najniższym użyciem CPU za wszelką cenę, lecz najlżejsza ścieżka, którą klient, sieć i wybrane ścieżki multimedialne mogą rzeczywiście obsłużyć.

Direct Play działa tylko wtedy, gdy cały plik jest zgodny z klientem

Direct Play należy zachować w pierwszej kolejności, ponieważ przesyła oryginalny obraz i dźwięk bez ponownego kodowania. Praca serwera nadal jest konieczna — obejmuje odczyt danych z pamięci masowej, uwierzytelnianie, obsługę protokołu i dostarczanie danych przez sieć — ale kosztowny proces konwersji obrazu pozostaje nieaktywny.

Plex definiuje Direct Play jako ścieżkę, w której klient może użyć multimediów bez konwersji, a w swoim omówieniu przesyłania strumieniowego odróżnia ją od Direct Stream i transkodowania. Ta ścieżka dostarczania oryginalnych multimediów sprawia, że decydujące znaczenie ma możliwość obsługi przez klienta, a nie moc serwera.

Direct Play przestaje być możliwe, gdy klient odrzuca istotny element: kodek obrazu, kodek audio, kontener, profil, rozdzielczość, bitrate, sposób obsługi napisów lub inne ograniczenie odtwarzania. Gdy którykolwiek wymagany element jest niezgodny, serwer musi albo przepakować multimedia, albo utworzyć nowy strumień.

Direct Stream to rozwiązanie pośrednie, gdy obraz może pozostać bez zmian

Direct Stream, często nazywany remultipleksowaniem lub transmuksowaniem, jest przeznaczony dla plików, których obraz można skopiować, ale których opakowanie lub inny strumień wymaga dostosowania. Serwer wyodrębnia zgodne strumienie i przepakowuje je do formy akceptowanej przez klienta, co jest znacznie lżejsze niż dekodowanie i ponowne kodowanie obrazu.

Dokumentacja odtwarzania Emby opisuje Direct Stream jako przepakowanie w czasie rzeczywistym, podczas którego ścieżka obrazu pozostaje niezmieniona, a audio lub napisy mogą zostać przekonwertowane. Jego ścieżka remultipleksowania z kopiowaniem obrazu wyznacza użyteczną granicę: „przesyłanie strumieniowe” nie oznacza automatycznie transkodowania obrazu.

Ta ścieżka najlepiej sprawdza się, gdy jedyną niezgodnością jest kontener lub audio. Przestaje być dostępna, gdy sam obraz musi zostać zmieniony, gdy napisy muszą zostać wypalone w klatkach albo gdy dostarczany bitrate lub rozdzielczość musi zostać zmniejszona bardziej, niż pozwala na to kopiowanie strumienia.

Transkodowanie rozpoczyna się, gdy obraz trzeba zbudować od nowa

Pełne transkodowanie obrazu jest najbardziej kosztowną ścieżką. Serwer dekoduje źródło, może zmieniać skalę, mapować tony, usuwać przeplot, wypalać napisy lub w inny sposób filtrować klatki, a następnie koduje nowy strumień obrazu dla klienta. Audio może być kopiowane lub konwertowane równolegle.

Dokumentacja transkodowania Jellyfin rozróżnia akcelerację sprzętową od przetwarzania programowego i wskazuje, że nowoczesne układy GPU mogą odciążać obsługiwane ścieżki. Proces konwersji w czasie rzeczywistym wyjaśnia, dlaczego ten sam film może być lekkim zadaniem sieciowym na jednym kliencie, a wymagającym zadaniem obliczeniowym na innym.

Transkodowanie jest uzasadnione, gdy zgodność lub przepustowość rzeczywiście wymaga utworzenia nowego strumienia obrazu. Jeśli klient może zaakceptować oryginalny obraz, a sieć może go przesłać, wymuszenie niższej jakości może wygenerować obciążenie serwera, którego wcześniej nie było.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Porównaj trzy ścieżki pod kątem czterech wspólnych zasobów

Zasoby serwera, których zużycie się zmienia, to moc obliczeniowa, przenoszenie danych w pamięci, tymczasowa przestrzeń na transkodowanie oraz przepustowość sieci. Direct Play minimalizuje obciążenie związane z konwersją, ale może dostarczać źródło z pełnym bitrate’em. Transkodowanie może zmniejszyć wychodzący bitrate, zwiększając jednocześnie obciążenie CPU lub GPU. Direct Stream plasuje się pomiędzy nimi, ponieważ zmiany opakowania są zwykle lekkie, a konwersja audio wymaga tylko pewnej ilości mocy obliczeniowej.

Ścieżka odtwarzania	Przetwarzanie obrazu	Typowe zapotrzebowanie na moc obliczeniową	Zachowanie sieci	Główna granica niezgodności
Direct Play	Oryginalny obraz i dźwięk	Najniższe	Bitrate źródłowy	Niezgodność klienta lub pliku
Direct Stream	Obraz kopiowany; zmienione opakowanie i ewentualnie audio	Niskie do umiarkowanego	Zwykle zbliżone do bitrate’u obrazu źródłowego	Sam obraz wymaga konwersji
Transkodowanie	Obraz dekodowany i ponownie kodowany	Najwyższe	Możliwość ustawienia niższego bitrate’u lub rozdzielczości	Wydajność obliczeniowa lub akceleratora

Omówienie akceleracji sprzętowej FFmpeg opisuje dedykowane interfejsy, takie jak NVENC/NVDEC i QSV, służące do przetwarzania obrazu. Ta warstwa sprzętowego odciążania ma znaczenie tylko na ścieżce transkodowania; nie sprawia, że Direct Play staje się bardziej bezpośrednie.

Nie oceniaj ścieżek na podstawie tylko jednego zasobu. Użytkownik zdalny korzystający z wolnego łącza wychodzącego może potrzebować transkodowania nawet wtedy, gdy serwer ma dużo mocy obliczeniowej, podczas gdy lokalny klient 4K podłączony przez Ethernet może lepiej działać z Direct Play przy oryginalnym bitrate’cie.

Napisy i audio mogą zmienić ścieżkę bez zmiany pliku filmu

Użytkownik może wybrać inną ścieżkę napisów lub audio i przenieść sesję na inną ścieżkę przetwarzania. Napisy tekstowe, które klient potrafi renderować, mogą zachować Direct Play, natomiast napisy obrazkowe lub nieobsługiwany sposób ich wyświetlania mogą wymagać wypalenia, a tym samym transkodowania obrazu. Nieobsługiwane wielokanałowe audio może uruchomić konwersję dźwięku, podczas gdy obraz nadal będzie kopiowany.

Dokumentacja wydajności HandBrake jest tu przydatna, ponieważ oddziela kosztowne kodowanie obrazu od innych operacji i pokazuje, że filtry mogą pozostać wąskim gardłem nawet przy użyciu kodera sprzętowego. Podział obciążenia między filtry i koder wyjaśnia, dlaczego „włączone transkodowanie sprzętowe” nie oznacza, że każdy etap jest bezkosztowy.

Gdy jeden tytuł niespodziewanie zużywa więcej zasobów serwera niż inny, przed porównywaniem procesorów lub kart graficznych porównaj wybrane ścieżki i przyczynę odtwarzania. Widoczna rozdzielczość może być identyczna, podczas gdy ścieżka przetwarzania będzie całkowicie inna.

Użyj panelu odtwarzania jako narzędzia decyzyjnego

Nie określaj ścieżki wyłącznie na podstawie wykorzystania CPU. Otwórz szczegóły sesji w serwerze multimediów i sprawdź, czy obraz jest odtwarzany przez Direct Play, kopiowany/remultipleksowany czy transkodowany; następnie sprawdź, czy audio jest kopiowane lub konwertowane oraz czy napisy są renderowane przez klienta, czy wypalane w obrazie.

Poradnik ZimaSpace dotyczący wysokiego użycia CPU podczas odtwarzania multimediów stosuje tę samą zasadę: najpierw ustal decyzję dotyczącą przetwarzania, a dopiero potem traktuj wysokie użycie zasobów jako brak mocy sprzętowej.

Uruchom jedną reprezentatywną sesję lokalną, jedną sesję zdalną lub ograniczoną przepustowością oraz jedną sesję z dużą ilością napisów. Jeśli panel już informuje o Direct Play, a odtwarzanie nadal się buforuje, przestań porównywać moc transkodowania i sprawdź pamięć masową, dostarczanie danych lub samego klienta.

Wybierz najlżejszą ścieżkę spełniającą wymagania dostarczania

Wybieraj Direct Play, gdy klient obsługuje cały plik multimedialny, a sieć może przesłać jego bitrate. Zachowuje ono źródło i pozostawia najwięcej mocy serwera dla innych użytkowników.

Użyj Direct Stream, gdy zgodność obrazu jest już zapewniona, ale kontener, audio lub opakowanie wymagają dostosowania. Transkodowanie stosuj tylko wtedy, gdy sam obraz musi zostać zmieniony ze względu na zgodność, przepustowość, rozdzielczość, konwersję HDR/SDR, wypalanie napisów lub inne rzeczywiste ograniczenie dostarczania.

Żadna ścieżka nie wygrywa w każdej sytuacji. Direct Play minimalizuje obciążenie obliczeniowe, Direct Stream tanio rozwiązuje niezgodności opakowania, a transkodowanie zapewnia zgodność i kontrolę nad bitrate’em kosztem zasobów serwera. Właściwie zaprojektowany serwer multimediów maksymalnie wykorzystuje dwie pierwsze ścieżki, zachowując jednocześnie wystarczającą wydajność transkodowania dla sesji, które nie mogą uniknąć trzeciej.