Fundamentalne Wyzwanie: Streaming kontra Pobieranie

Zanim zgłębimy niuanse kompresji dla streamingu, kluczowe jest zrozumienie różnicy między pobieraniem pliku a jego strumieniowaniem. Kiedy pobierasz plik, na przykład film, Twój komputer zapisuje cały plik na dysku twardym. Musisz poczekać, aż cały plik dotrze, zanim będziesz mógł zacząć go oglądać. Streaming z drugiej strony to proces ciągły. Twój odtwarzacz wideo zaczyna odtwarzać początek pliku niemal natychmiast, podczas gdy reszta pliku nadal dociera w tle. To tworzy płynne doświadczenie, które kojarzymy z usługami takimi jak YouTube czy Netflix.

Ten model "odtwarzaj w trakcie pobierania" wprowadza kluczową zmienną, która jest mniej istotna przy prostym pobieraniu: czas. Aby streaming działał, dane muszą docierać do Twojego urządzenia co najmniej tak szybko, jak je oglądasz. Jeśli tak się nie dzieje, odtwarzanie zatrzyma się i zobaczysz znienawidzone kółko buforowania. Ten nieustanny wyścig z czasem nakłada wyjątkowe i intensywne presje na algorytmy kompresji używane do treści strumieniowych. Muszą one nie tylko zmniejszyć plik, ale zrobić to w sposób zoptymalizowany pod kątem dostarczania i odtwarzania w czasie rzeczywistym przez potencjalnie zawodne sieci.

Możemy dalej podzielić streaming na dwie szerokie kategorie, z których każda ma własny zestaw wyzwań i strategii kompresji: streaming na żądanie i streaming na żywo w czasie rzeczywistym.

Wielki Kompromis: Wydajność Kompresji kontra Opóźnienie

Świat kompresji strumieniowej rządzi się fundamentalnym i często bezlitosnym kompromisem. Z jednej strony mamy cel maksymalnej wydajności kompresji, czyli uczynienia pliku wideo jak najmniejszym, aby zaoszczędzić przepustowość. Z drugiej strony mamy wymóg niskiego opóźnienia, czyli minimalizacji opóźnienia między nadawcą a widzem. Te dwa cele są prawie zawsze w bezpośrednim konflikcie.

Dlaczego Wysokowydajna Kompresja Tworzy Opóźnienie

Najpotężniejsze narzędzia w arsenale kodeka wideo, które pozwalają mu osiągać niesamowite współczynniki kompresji, opierają się na predykcji międzyklatkowej, zwłaszcza przy użyciu klatek B.

• Klatki P (przewidywane): Oszczędzają miejsce, odwołując się do przeszłej klatki i kodując tylko różnice. Wprowadza to niewielkie opóźnienie, ponieważ dekoder potrzebuje kompletnej przeszłej klatki, aby skonstruować bieżącą klatkę P.
• Klatki B (dwukierunkowo przewidywane): To mistrzowie wydajności. Mogą odwoływać się zarówno do przeszłej, jak i przyszłej klatki, aby dokonać predykcji. Ten dwukierunkowy wgląd często skutkuje najmniejszym możliwym rozmiarem danych dla danej klatki.

I tu leży problem. Aby dekoder mógł skonstruować klatkę B, musi mieć nie tylko przeszłą klatkę referencyjną, ale musi również poczekać na nadejście przyszłej klatki referencyjnej. Koder wideo musi przechowywać bufor klatek, przetwarzać je w innej kolejności, aby stworzyć te zależności, a następnie je wysłać. Dekoder musi następnie odebrać i zbuforować te klatki, zmienić ich kolejność, a na koniec zdekodować i wyświetlić klatkę B. Cały ten proces buforowania i zmiany kolejności wprowadza znaczące opóźnienie. To jest latencja.

Dla streamingu na żądanie, jak Netflix, jest to całkowicie do przyjęcia. Gdy naciskasz play na filmie, kilka sekund początkowego buforowania to niewielka cena za wysokiej jakości strumień o niskiej przepustowości. System może używać złożonych układów klatek B, aby osiągnąć maksymalną kompresję, ponieważ kilkusekundowe opóźnienie na starcie nie stanowi problemu. Jednak dla komunikacji na żywo w czasie rzeczywistym, jak rozmowa na Zoomie czy transmisja sportowa na żywo na Twitchu, tego rodzaju opóźnienie to kompletna katastrofa. Pięciosekundowe opóźnienie uniemożliwiłoby rozmowę i oznaczałoby, że słyszysz reakcję znajomych na gola na długo przed tym, jak go zobaczysz na ekranie. Dlatego strategie kompresji dla streamingu na żywo muszą poświęcić część wydajności, aby utrzymać opóźnienie na absolutnym minimum.

Strategia 1 dla Transmisji na Żywo: Dostosowanie Kodeka

Pierwszym krokiem w celu zmniejszenia opóźnienia jest skonfigurowanie samego kodera wideo, aby priorytetem była szybkość, a nie ostateczna kompresja. Obejmuje to staranne dostosowanie sposobu wykorzystania różnych typów klatek.

Zarządzanie Grupą Obrazów (GOP)

Powtarzająca się sekwencja typów klatek w strumieniu wideo jest znana jako Grupa Obrazów (GOP). Struktura i długość GOP mają bezpośredni i dramatyczny wpływ zarówno na opóźnienie, jak i na kompresowalność.

• Długi GOP (Duże Opóźnienie, Wysoka Kompresja): Stosowany do treści na żądanie. Typowy GOP może mieć 2 sekundy długości, co oznacza, że klatka I jest wysyłana tylko raz na 60 klatek (dla wideo 30 kl./s). Taki GOP będzie wypełniony wieloma klatkami P i B. Pozwala to na maksymalną kompresję, ponieważ większość klatek to wysoko skompresowane predykcje, ale tworzy to również duże opóźnienie.
• Krótki GOP (Niższe Opóźnienie, Niższa Kompresja): W transmisjach na żywo rozmiar GOP jest często zmniejszany do 1 sekundy lub nawet krócej. Wysyłanie klatek I częściej skraca łańcuch zależności klatek przewidywanych, co może pomóc strumieniowi widza szybciej odzyskać sprawność po błędach. To nieznacznie zwiększa średni bitrate, ale zmniejsza opóźnienie i poprawia odporność.
• Profile o Zerowym Opóźnieniu (I-P-P-P...): W zastosowaniach o najniższym opóźnieniu, jak wideokonferencje, klatki B są często całkowicie wyłączone. GOP składa się tylko z klatek I i P. Ponieważ nie ma odniesień w przód, eliminowana jest potrzeba buforowania przyszłych klatek, co radykalnie zmniejsza opóźnienie.
• Tylko klatki I: W niektórych specjalistycznych przypadkach, jak profesjonalna edycja wideo lub niektóre systemy monitoringu wysokiego bezpieczeństwa, strumień może składać się wyłącznie z klatek I. Jest to w istocie Motion JPEG (M-JPEG). Zapewnia to najniższe możliwe opóźnienie i edycję z dokładnością do klatki, ale skutkuje bardzo wysokim bitrate'em.

Strategia 2: Adaptacyjny Streaming Bitrate'u (ABR)

Jednym z największych wyzwań dla każdego rodzaju streamingu jest nieprzewidywalność internetu. Połączenie sieciowe użytkownika może zmieniać się z chwili na chwilę. Może on przejść z silnego sygnału Wi-Fi na słaby sygnał komórkowy, lub ktoś inny w domu może rozpocząć duże pobieranie. Gdyby serwer wysyłał tylko jeden, wysokiej jakości strumień, każdy spadek wydajności sieci spowodowałby zamrożenie odtwarzania.

Adaptacyjny streaming bitrate'u (ABR) jest eleganckim rozwiązaniem tego problemu. Zamiast tworzyć tylko jedną wersję wideo, serwer tworzy wiele wersji, zwanych reprezentacjami, o różnej jakości i bitrate (np. 480p, 720p, 1080p, 4K).

Proces ten działa następująco:

1. Segmentacja: Każda z tych reprezentacji jest dzielona na małe, spójnej długości fragmenty lub segmenty, zazwyczaj o długości od 2 do 10 sekund.
2. Plik Manifestu: Serwer udostępnia również plik manifestu (jak M3U8 dla HLS lub MPD dla DASH). Ten plik jest "mapą" dla odtwarzacza wideo.
3. Inteligentny Odtwarzacz: Odtwarzacz wideo na Twoim urządzeniu (np. w aplikacji YouTube lub w przeglądarce internetowej) zaczyna od pobrania manifestu. Następnie stale monitoruje Twoją bieżącą przepustowość sieci.
4. Dynamiczne Żądanie Segmentów: Na podstawie warunków sieciowych, odtwarzacz inteligentnie żąda następnego segmentu wideo z reprezentacji o najwyższej jakości, jaką jego zdaniem może niezawodnie pobrać bez buforowania. Jeśli Twoja przepustowość jest wysoka, żąda segmentu 1080p. Jeśli Twoje połączenie nagle się pogorszy, dla następnego segmentu zażąda wersji 720p.

Wszystko to dzieje się płynnie w tle, co skutkuje płynnym doświadczeniem oglądania, które automatycznie dostosowuje się do prędkości połączenia, priorytetyzując ciągłość odtwarzania nad maksymalną jakością, gdy jest to konieczne. ABR jest podstawą nowoczesnych usług streamingowych zarówno dla treści na żądanie, jak i na żywo.

Strategia 3: Protokoły Niskiego Opóźnienia

Problem z TCP

Standardowym protokołem dla większości danych internetowych jest TCP (Transmission Control Protocol). TCP jest zaprojektowany z myślą o niezawodności. Jeśli pakiet zostanie utracony, TCP zatrzyma wszystko i retransmituje utracony pakiet, aby zapewnić, że plik dotrze w nienaruszonym stanie. Do pobierania pliku lub ładowania strony internetowej jest to dokładnie to, czego chcesz. Ale w przypadku rozmowy wideo na żywo jest to katastrofa. Jeśli mały pakiet audio zostanie utracony, znacznie lepiej jest go pominąć i iść dalej, niż wstrzymywać całą rozmowę, aby czekać na retransmisję dźwięku, który teraz byłby już nieaktualny.

Rozwój UDP i Protokołów Czasu Rzeczywistego

Dlatego aplikacje do streamingu w czasie rzeczywistym prawie powszechnie używają User Datagram Protocol (UDP). UDP to protokół typu "wystrzel i zapomnij". Wysyła pakiety bez żadnej gwarancji dostarczenia czy kolejności. Brzmi to źle, ale dla streamingu na żywo jest idealne. Pozwala to na jak najszybszy przepływ danych bez grzęźnięcia w retransmisjach. Utrata jednego pakietu może skutkować drobnym, chwilowym zakłóceniem wizualnym, co jest znacznie lepsze niż kilkusekundowe zamrożenie obrazu.

Aby dodać niezbędne funkcje, takie jak znaczniki czasu i numery sekwencyjne, na wierzchu UDP, aplikacje streamingowe używają protokołów wyższego poziomu:

• RTP (Real-time Transport Protocol): Jest to standard do przenoszenia właściwych danych medialnych (audio i wideo). Dodaje numery sekwencyjne, dzięki czemu odbiorca może wykryć utratę pakietów i uporządkować pakiety, które dotarły w złej kolejności, oraz dodaje znaczniki czasu do synchronizacji strumieni audio i wideo.
• RTCP (RTP Control Protocol): Działa razem z RTP. Okresowo wysyła raporty z powrotem do nadawcy, zawierające statystyki dotyczące połączenia, takie jak wskaźniki utraty pakietów i jitter. Ta informacja zwrotna pozwala nadawcy na adaptację swojego bitrate'u kodowania w czasie rzeczywistym.
• Nowsze Protokoły (SRT, WebRTC): Technologie takie jak Secure Reliable Transport (SRT) i Web Real-Time Communication (WebRTC) opierają się na tych koncepcjach, aby zapewnić jeszcze niższe opóźnienia (poniżej sekundy) i lepszą wydajność na niezawodnych publicznych połączeniach internetowych.