Jak internet nauczył się grać na żywo: od modemów do streamingu

Zewnętrzny analogowy modem 56K używany do łączenia się z internetem przez linię telefoniczną
Analogowy modem 56K. Fot. Digitalsignal, Wikimedia Commons, licencja CC BY-SA 3.0.

Jeszcze trzy dekady temu dźwięk w internecie był czymś niemal egzotycznym. Połączenie telefoniczne miało niewielką przepustowość, każda minuta blokowała domowy telefon, a pobranie krótkiego pliku audio potrafiło trwać dłużej niż jego późniejsze odtworzenie. Mimo to właśnie w epoce piszczących modemów powstała idea, dzięki której dziś można jednym kliknięciem uruchomić stację radiową, podcast albo transmisję na żywo.

Streaming nie pojawił się jako gotowy wynalazek. Był rezultatem kilku zmian zachodzących równolegle: lepszej kompresji dźwięku, rozwoju protokołów sieciowych, szybszych łączy i stopniowego przenoszenia odtwarzacza z osobnego programu bezpośrednio do przeglądarki. Historia tej technologii pokazuje, że internet nie zawsze był naturalnym środowiskiem dla mediów. Musiał się tego nauczyć.

Najpierw trzeba było pobrać cały plik

W pierwszych latach World Wide Web dźwięk działał podobnie jak dokument albo archiwum ZIP. Użytkownik klikał odnośnik, czekał na pobranie całego pliku, a dopiero później otwierał go w odpowiednim programie. Przy modemie 14,4 lub 28,8 kb/s nawet mocno skompresowane nagranie wymagało cierpliwości. Transmisja na żywo w takim modelu nie miała większego sensu, ponieważ odbiorca zawsze znajdował się za nadawcą o długość całego pobieranego materiału.

Kluczowa zmiana polegała na umożliwieniu odtwarzania danych jeszcze podczas ich odbierania. Zamiast czekać na kompletny plik, program gromadził niewielki zapas danych w buforze, rozpoczynał odtwarzanie i jednocześnie pobierał kolejne fragmenty. Jeśli dane docierały wystarczająco szybko, słuchacz otrzymywał ciągły dźwięk. Jeśli łącze nie nadążało, pojawiała się cisza, komunikat o buforowaniu albo jakość była obniżana.

Dzisiaj ten mechanizm jest prawie niewidoczny, lecz jego podstawowe zadanie pozostaje takie samo: wyrównać różnice pomiędzy tempem przesyłania danych a tempem ich odtwarzania.

RealAudio i dźwięk w czasie rzeczywistym

Jednym z symboli pierwszej fali internetowego audio był RealAudio, wprowadzony w 1995 roku. Format został zaprojektowany tak, aby przesyłać dźwięk także przez powolne połączenia telefoniczne. Jakość pierwszych transmisji nie dorównywała płycie CD, a często nawet dobremu odbiorowi FM, ale ważniejsze było coś innego: użytkownik nie musiał już pobierać całego nagrania przed rozpoczęciem słuchania.

W praktyce potrzebny był osobny program lub dodatek do przeglądarki. Strona internetowa przekazywała mu adres strumienia, a odtwarzacz zajmował się połączeniem z serwerem, buforowaniem i dekodowaniem dźwięku. Dla użytkowników przyzwyczajonych do statycznych stron była to istotna zmiana. Sieć zaczynała przypominać medium działające tu i teraz, a nie wyłącznie bibliotekę plików.

Rozwój streamingu wymagał też sposobu sterowania transmisją. Opublikowany w 1998 roku dokument RFC 2326 opisujący RTSP przedstawiał protokół działający w pewnym sensie jak sieciowy pilot. Pozwalał inicjować sesję, rozpocząć odtwarzanie, zatrzymać je i zakończyć połączenie. Sam RTSP zwykle nie przenosił całego dźwięku, lecz kontrolował dostarczanie mediów innymi mechanizmami. To rozdzielenie sterowania od właściwego strumienia było ważne dla ówczesnych serwerów multimedialnych.

MP3 uprościł internetowe radio

RealAudio nie było jedyną drogą. Rosnąca popularność MP3 sprawiła, że dźwięk można było skutecznie kompresować, zachowując jakość wystarczającą do muzyki. Powstały serwery zdolne wysyłać ciągły strumień MP3 do wielu odbiorców. Dla stacji radiowej oznaczało to możliwość przekazania programu poza zasięg nadajnika FM, bez budowania kolejnej infrastruktury antenowej.

Wczesne radio internetowe nadal wymagało od słuchacza pewnej wiedzy. Trzeba było mieć zgodny odtwarzacz, czasem pobrać niewielki plik listy odtwarzania, a później liczyć na to, że zapora sieciowa nie zablokuje nietypowego portu. Zerwane połączenia i ponowne buforowanie były zwykłą częścią doświadczenia. Internet nie był jeszcze usługą stale obecną w tle, lecz połączeniem, które uruchamiało się celowo i często rozliczało według czasu.

Mimo tych ograniczeń streaming zmienił zasięg radia. Lokalna rozgłośnia mogła być odbierana w innym kraju, a stacja tworzona wyłącznie w internecie nie potrzebowała częstotliwości. To właśnie wtedy słowo „radio” zaczęło oznaczać nie tylko sposób nadawania fal elektromagnetycznych, ale również format programu: prowadzących, ramówkę, muzykę, serwisy informacyjne i kontakt ze słuchaczami.

HTTP wygrał dzięki swojej zwyczajności

Z czasem coraz większą rolę zaczął odgrywać zwykły protokół HTTP, ten sam, który służy do pobierania stron i obrazów. Było to praktyczne: ruch internetowy przez standardowe porty łatwiej przechodził przez routery, serwery pośredniczące i firmowe zapory. Dostawcy mogli też wykorzystywać istniejące serwery WWW oraz sieci CDN zamiast utrzymywać całkowicie odrębną infrastrukturę.

Współczesne rozwiązania często dzielą transmisję na krótkie segmenty i publikują listę informującą odtwarzacz, które fragmenty ma pobrać. Dobrym przykładem jest HTTP Live Streaming. RFC 8216 opisuje przesyłanie potencjalnie niekończących się strumieni multimedialnych przy użyciu plików i list odtwarzania. Apple podkreśla, że HLS może korzystać ze zwykłych serwerów internetowych i sieci dystrybucji treści, a odtwarzanie może dostosowywać się do aktualnej jakości połączenia.

Adaptacja ma ogromne znaczenie zwłaszcza w sieciach komórkowych. Zamiast uparcie pobierać wersję o wysokiej jakości i co chwilę zatrzymywać dźwięk, odtwarzacz może wybrać wariant o mniejszej przepływności. Gdy warunki się poprawią, wraca do lepszej jakości. Słuchacz zwykle niczego nie ustawia, ponieważ decyzje są podejmowane automatycznie na podstawie dostępnych wariantów i obserwowanej szybkości transmisji.

Odtwarzacz przeniósł się do przeglądarki

Przez wiele lat strony korzystały z wtyczek i zewnętrznych programów. Powodowało to problemy z kompatybilnością, bezpieczeństwem i wygodą. Standaryzacja multimediów w HTML stopniowo zmieniła sytuację. Element <audio> pozwolił osadzić odtwarzacz bezpośrednio w dokumencie i wskazać jedno lub kilka źródeł dźwięku. Jak wyjaśnia dokumentacja MDN, przeglądarka może wybrać obsługiwane źródło i udostępnić użytkownikowi własne przyciski odtwarzania, pauzy, regulacji głośności oraz przewijania.

To pozornie niewielka zmiana, ale usunęła istotną barierę. Odbiorca nie musi wiedzieć, jaki program otwiera dany format ani ręcznie kopiować adresu strumienia. Na komputerze i telefonie wystarcza przeglądarka, a strona może uzupełnić standardowy odtwarzacz o informacje o stacji, aktualnej audycji lub wykonawcy.

Właśnie dlatego współczesne słuchanie jest bardziej związane z interfejsem niż z technicznym adresem transmisji. Użytkownik wybiera nazwę i naciska przycisk, natomiast strona w tle łączy się z odpowiednim źródłem. Przykładem takiego podejścia jest radio.biz.pl, gdzie różne polskie stacje można uruchamiać z jednego katalogu bez ręcznego szukania adresów strumieni i zgodnych odtwarzaczy.

Co nadal może pójść źle

Streaming stał się prostszy, ale nie jest pozbawiony ograniczeń. Nadawca musi utrzymać serwer lub usługę zdolną obsłużyć równoczesnych słuchaczy. Każdy odbiorca zużywa pasmo, chyba że dystrybucję przejmuje wyspecjalizowana sieć. Dochodzą różnice formatów, certyfikaty HTTPS, zasady automatycznego odtwarzania w przeglądarkach oraz ograniczenia regionalne wynikające z licencji.

Transmisja na żywo zawsze wymaga też kompromisu pomiędzy opóźnieniem a odpornością na chwilowe pogorszenie łącza. Większy bufor ogranicza przerwy, ale sprawia, że słuchacz otrzymuje program później. Mniejszy bufor zbliża odbiór do czasu rzeczywistego, lecz zwiększa ryzyko zacięć. Dla muzyki kilkanaście sekund różnicy zwykle nie ma znaczenia. Przy wiadomościach, transmisjach sportowych lub interaktywnych audycjach opóźnienie staje się znacznie bardziej widoczne.

Modem zniknął, idea została

Od pierwszych prób przesyłania dźwięku przez linię telefoniczną do dzisiejszych odtwarzaczy minęło około trzydziestu lat. Zmieniły się kodeki, protokoły, urządzenia i oczekiwania odbiorców. Nie zmieniła się natomiast główna zasada: dane muszą docierać odrobinę szybciej, niż są odtwarzane, a niewielki bufor ma ukryć nierówności połączenia.

Największym sukcesem streamingu nie jest więc sama poprawa jakości. Jest nim zniknięcie technologii z pola widzenia. Dawniej słuchacz wybierał format, instalował program i obserwował wskaźnik buforowania. Dzisiaj wybiera stację. Cała reszta nadal działa, tylko wreszcie nie domaga się ciągłej uwagi.