Kompresja Strumieniowa

Streaming i pobieranie plików

Przy pobieraniu pliku odbiorca otrzymuje dane do zapisania i może rozpocząć odtwarzanie po zgromadzeniu wymaganego fragmentu. Cały plik może zostać zapisany przed użyciem, zależnie od aplikacji, a odtwarzacz może swobodnie przeskakiwać po już pobranych danych. Streaming dostarcza dane w trakcie prezentacji. Odtwarzacz pobiera początkowy bufor, rozpoczyna odtwarzanie, a kolejne fragmenty docierają w tle. Ten model stosują między innymi YouTube i Netflix.

Model "odtwarzaj w trakcie pobierania" wprowadza ograniczenie czasowe. W dłuższym okresie przepływ danych musi odpowiadać tempu odtwarzania, a bufor może pochłaniać krótkie wahania przepustowości. Większy bufor zmniejsza ryzyko zatrzymania, lecz wydłuża start i opóźnienie. Gdy bufor się wyczerpie, odtwarzanie czeka na kolejne dane. Kompresja musi więc ograniczać bitrate i opóźnienie dostarczania w sieciach o zmiennej jakości. Poziom bufora nie zastępuje pomiaru aktualnej przepustowości.

Streaming obejmuje treści na żądanie oraz transmisje na żywo. Pierwsza kategoria toleruje bufor początkowy i pobieranie z wyprzedzeniem, a druga wymaga utrzymania ograniczonego opóźnienia między źródłem i odbiorcą. W transmisji na żywo opóźnienie obejmuje przechwycenie obrazu, kodowanie, transport, bufor odbiorcy i wyświetlenie. Odtwarzacz musi też obsłużyć pojawianie się kolejnych fragmentów oraz ewentualne przerwy w ich publikacji.

Wydajność kompresji, przepustowość i opóźnienie

Projekt transmisji łączy mały bitrate z niskim . Silniejsza kompresja może zmniejszyć wymagany bitrate, lecz często wymaga większego bufora, bardziej złożonej predykcji, dłuższego kodowania lub zmiany kolejności klatek. Trzeba uwzględnić także moc urządzenia, koszt kodowania oraz odporność na chwilową utratę przepustowości. Te zależności dobiera się do treści na żądanie albo do komunikacji interaktywnej.

Predykcja międzyklatkowa a opóźnienie

Wysoką efektywność daje predykcja międzyklatkowa. Klatki P odwołują się do obrazów referencyjnych, a klatki B mogą korzystać z referencji z przeszłości i przyszłości. Koder oraz dekoder muszą uwzględnić kolejność kodowania, dekodowania i wyświetlania.

Klatki P (przewidywane): Odwołują się do jednej lub kilku wcześniejszych klatek referencyjnych i zapisują predykcję oraz dane rezydualne. Dekoder musi mieć dostęp do wymaganej klatki referencyjnej, aby odtworzyć bieżący obraz.
Klatki B (dwukierunkowo przewidywane): Mogą odwoływać się do klatek z przeszłości i przyszłości. Dwie referencje często poprawiają predykcję i zmniejszają dane rezydualne, lecz nie gwarantują najmniejszego rozmiaru każdej klatki. Kodek może używać także innych układów referencji.

Klatka B wymaga dostępnej klatki referencyjnej z przyszłości względem jej czasu wyświetlania. Koder buforuje obrazy i może wysłać je w kolejności dekodowania, a dekoder buforuje je do chwili wyświetlenia. Buforowanie i zmiana kolejności zwiększają opóźnienie całego toru, zwłaszcza gdy referencja przychodzi później niż obraz zależny.

Dla streamingu na żądanie, takiego jak Netflix, kilka sekund buforowania przed startem może być akceptowalne. Koder może używać klatek B i większego bufora, aby zmniejszyć bitrate. W komunikacji na żywo w czasie rzeczywistym, na przykład podczas rozmowy w Zoomie albo transmisji sportowej na Twitchu, pięciosekundowe opóźnienie utrudnia reakcję na zdarzenia i rozmowę. Ten profil wymaga ograniczenia buforowania i opóźnienia kosztem części efektywności kompresji.

Strategia 1: konfiguracja kodeka dla transmisji na żywo

Zmniejszenie opóźnienia zaczyna się od konfiguracji kodera wideo. Ustawienia określają kompromis między szybkością kodowania, bitrate, użyciem poszczególnych typów klatek oraz długością GOP. Wymagania zależą od tego, czy odbiorca ogląda materiał na żądanie, czy uczestniczy w rozmowie.

Grupa obrazów (GOP)

Powtarzająca się sekwencja typów klatek w strumieniu wideo jest znana jako . Struktura i długość GOP wpływają na bitrate, punkty dostępu, możliwość szybkiego przewijania oraz opóźnienie związane z referencjami i buforowaniem.

Długi GOP (mniej punktów dostępu, wysoka kompresja): Pasuje do treści na żądanie. Przykładowy GOP długości 2 sekund zawiera jedną klatkę I na 60 klatek przy 30 kl./s. Pozostałe klatki mogą być predykcyjne, więc bitrate spada, lecz odtwarzacz ma mniej punktów dostępu i może potrzebować dłuższego bufora. Odbiorca może rozpocząć dekodowanie dopiero przy dostępnym punkcie dostępu.
Krótki GOP (szybszy dostęp, niższa kompresja): W transmisjach na żywo stosuje się krótsze GOP-y, gdy potrzebne jest szybkie odzyskiwanie i przełączanie. Częstsze klatki I skracają łańcuch zależności i pomagają wznowić dekodowanie po błędzie. Zwiększają przy tym średni bitrate, lecz upraszczają szybkie przełączanie reprezentacji.
Profile o niskim opóźnieniu (I-P-P-P...): W wideokonferencjach klatki B bywają wyłączone. GOP zawiera wtedy klatki I i P, a brak referencji z przyszłości ogranicza buforowanie i zmianę kolejności. Nadal pozostaje koszt kodowania oraz transportu.
Tylko klatki I:W profesjonalnej edycji albo wybranych systemach monitoringu strumień może składać się wyłącznie z klatek I. M-JPEG jest przykładem sekwencji niezależnych obrazów JPEG. Ten układ upraszcza dekodowanie i montaż, lecz wymaga wysokiego bitrate'u.

Strategia 2: adaptacyjny bitrate (ABR)

Przepustowość połączenia użytkownika zmienia się w czasie. Przejście z Wi-Fi do sieci komórkowej albo inne pobieranie może zmniejszyć dostępne pasmo. Jeden strumień o stałej jakości mógłby wtedy wyczerpać bufor i zatrzymać odtwarzanie. Odtwarzacz obserwuje pobieranie, czas segmentu i poziom bufora, lecz pomiary zawsze opisują także wcześniejsze warunki.

rozwiązuje ten problem przez przygotowanie wielu reprezentacji tego samego materiału. Reprezentacje mają różną jakość, rozdzielczość, liczbę klatek i bitrate, na przykład 480p, 720p, 1080p oraz 4K. Serwer koduje je z odpowiednimi punktami dostępu, aby przełączanie było możliwe na granicach segmentów. Odtwarzacz nie musi pobierać całego materiału w najwyższej jakości.

Proces obejmuje następujące etapy.

Segmentacja: Każda reprezentacja jest dzielona na segmenty o określonym czasie trwania. HLS publikuje docelowy czas segmentu za pomocą tagu #EXT-X-TARGETDURATION, a wpis playlisty wskazuje segment, który odtwarzacz może pobrać niezależnie. Granice segmentów powinny odpowiadać punktom, w których dekoder może zmienić reprezentację. Usługa dobiera długość segmentu do opóźnienia, buforowania i narzutu żądań, więc standard nie narzuca jednej uniwersalnej wartości.
Manifest: Serwer udostępnia , na przykład playlistę M3U8 dla HLS albo dokument MPD dla DASH. Odtwarzacz odczytuje z niego reprezentacje, segmenty i dane potrzebne do ich pobrania. Manifest może opisywać także szyfrowanie, czas trwania i kolejność fragmentów. W transmisji na żywo playlisty są aktualizowane.
Odtwarzacz: Odtwarzacz pobiera manifest, mierzy przepustowość i obserwuje stan bufora. Uwzględnia także możliwości urządzenia, rozdzielczość ekranu i przewidywany czas pobierania kolejnego segmentu.
Żądanie segmentów: Na podstawie pomiarów odtwarzacz żąda kolejnego segmentu z reprezentacji, którą może pobrać bez wyczerpania bufora. Przy wysokiej przepustowości może wybrać 1080p, a po pogorszeniu połączenia 720p. Zmiana następuje zwykle między segmentami, aby zachować zgodność czasową.

Odtwarzacz zmienia reprezentację między segmentami. Gdy ciągłość odtwarzania ma pierwszeństwo przed jakością, wybiera niższy bitrate. Przy stabilnym zapasie bufora może wrócić do wyższej jakości, lecz zbyt częste zmiany pogarszają odbiór. Ogranicza to niepotrzebne wahania jakości. Algorytm może stosować margines bezpieczeństwa, aby nie reagować na każdy chwilowy spadek. ABR stosuje się w usługach z treściami na żądanie oraz w wybranych transmisjach na żywo.

Strategia 3: protokoły o małym opóźnieniu

TCP i blokowanie kolejności

TCP zapewnia niezawodny, uporządkowany strumień bajtów. Po utracie segmentu retransmisja przywraca ciągłość, a odbiorca nie przekazuje aplikacji późniejszych bajtów przed brakującym fragmentem. To head-of-line blocking. Mechanizm pasuje do pobierania plików i stron, natomiast w rozmowie na żywo retransmisja spóźnionego pakietu audio może być mniej użyteczna niż przejście do bieżącego dźwięku. Niezawodność TCP chroni kompletność danych, lecz może zwiększyć czas oczekiwania po stracie i opóźnić późniejsze dane tego samego strumienia.

UDP i protokoły czasu rzeczywistego

Aplikacje czasu rzeczywistego często używają wraz z mechanizmami aplikacyjnymi. UDP przekazuje datagramy bez gwarancji dostarczenia i kolejności. Brak retransmisji na poziomie UDP pozwala aplikacji zdecydować, czy spóźniony pakiet pominąć, czy odzyskać go inną metodą. Utrata pakietu może dać chwilowy artefakt, lecz nie musi zatrzymać całego odtwarzania. Wyższa warstwa może użyć numerów sekwencyjnych, bufora odtwarzania, korekcji nadmiarowej albo wybranych retransmisji.

RTP i RTCP dostarczają funkcji potrzebnych do obsługi mediów nad UDP.

RTP (Real-time Transport Protocol): Przenosi dane audio i wideo. Numery sekwencyjne pomagają wykrywać utratę i porządkować pakiety, a znaczniki czasu wspierają synchronizację strumieni. RTP nie zapewnia kompletności danych, więc aplikacja dobiera reakcję na straty.
RTCP (RTP Control Protocol): Działa obok RTP i wysyła raporty o utracie pakietów, najwyższym numerze sekwencyjnym oraz jitterze. Aplikacja może wykorzystać te informacje do zmiany bitrate'u albo ustawień bufora. Raporty tworzą kanał informacji zwrotnej, lecz nie zastępują kodowania odpornego na straty. RTP i RTCP są odrębnymi rodzajami komunikatów.
SRT i WebRTC: Secure Reliable Transport używa UDP, bufora opóźnienia i retransmisji ARQ do odzyskiwania wybranych pakietów. WebRTC używa RTP oraz SRTP i negocjuje ścieżkę przez ICE. Oba podejścia obsługują konfiguracje o małym opóźnieniu, lecz wynik zależy od sieci, kodeka, bufora i ustawień. Żaden z tych protokołów nie gwarantuje jednej wartości opóźnienia w każdym wdrożeniu.