RTMP, SRT czy WebRTC — czym się różnią i co wybrać do transmisji
Trzy nazwy, które widujesz w ustawieniach OBS-a albo w mailu od klienta, i nikt nigdy nie tłumaczy, po co są trzy. A różnica nie polega na tym, który jest nowszy.
Trzech muszkieterów przesyłu obrazu
Jeżeli kiedykolwiek wysyłałeś stream z OBS-a na YouTube’a, użyłeś RTMP. Jeżeli klient z telewizji poprosił cię o „sygnał z plenerów”, prawie na pewno padło słowo SRT. A jeżeli w tym tygodniu byłeś na jakiejkolwiek rozmowie w przeglądarce — wchodzisz z linku, nic nie instalujesz, wszyscy się widzą i słyszą — to był WebRTC.
Czyli używasz wszystkich trzech od lat i nigdy nie musiałeś wiedzieć, jak się nazywają. I tak by mogło zostać, gdyby nie jedno: jesteś na tej stronie w poszukiwaniu czym różnią się ci trzej muszkieterowie, zapewne przez to, że klient z telewizji uparł się aby puszczać mu sygnał po SRT albo szukasz rozwiązania jak połączyć rozmówcę i móc z nim rozmawiać jak przez telefon.
Zła wiadomość jest taka, że w internecie znajdziesz na to głównie tabelki z rzędami „latency”, „packet loss recovery” i „firewall traversal” i gówno z tego rozumiesz. Dobra jest taka, że różnica między nimi nie ma nic wspólnego z tym, który jest nowocześniejszy.
Trzech kurierów i jedna paczka
Wyobraź sobie, że wysyłasz paczkę zwykłym kurierem. Jedzie tanio, dojedzie wszędzie – bo jedzie starą Ładą Nivą „gniotsa nie łamiotsa”, ale jak zgubi coś po drodze, nikt cię nie zawiadomi. Zauważysz sam, po fakcie. To jest RTMP — i to naprawdę wystarcza, kiedy paczka to obraz lecący na YouTube’a, a po drugiej stronie siedzi widz, który tylko patrzy.
Drugi kurier ma awizo i numer śledzenia. Jak coś się zgubi, dosyła to bez wysyłania całej przesyłki od nowa — a ty z góry mówisz, ile ma na to czasu. To jest SRT: ustawiasz sobie zapas, powiedzmy dwie sekundy, i przez te dwie sekundy protokół ma szansę pozbierać wszystko, co pogubiło się po drodze. Dlatego tym jeździ materiał z plenerów do stacji telewizyjnej, gdzie łącze bywa czym Bóg dał, a obraz ma dojść w całości.
Trzeci kurier jeździ na motorze i nie czeka na nic. Jak coś mu wypadnie, nie wraca po to, tylko jedzie dalej, bo cała jego robota polega na tym, żeby być na miejscu natychmiast. To jest WebRTC i dlatego działa na nim każda rozmowa: gdyby czekał, rozmowa by się rozjechała i wszyscy zaczęliby mówić jeden na drugiego. Płaci za to jakością — kiedy łącze siada, obraz robi się miękki i kwadratowy, ale leci dalej i nie stoi.
I to jest cała różnica. Nie „nowszy kontra starszy”, tylko: ile sekund opóźnienia kupujesz za pewność, że obraz dojdzie w całości. RTMP kupuje dużo, SRT tyle, ile mu każesz, WebRTC nie kupuje prawie nic, bo nie ma za co — musi zdążyć.
Skąd wiesz, którego wziąć
Zadaj sobie jedno zajebiście ważne pytanie: czy ktoś po drugiej stronie musi ci odpowiedzieć?
Jeżeli nikt nie odpowiada — bo to transmisja na Facebooka, konferencja do oglądania, msza, sesja rady miasta — to opóźnienie jest bez znaczenia. Nikt nie wie, że patrzy na coś sprzed dwudziestu sekund, bo nie ma z czym porównać. Wtedy bierzesz RTMP, bo przyjmuje go dosłownie wszystko, albo SRT, jeżeli nadajesz z miejsca, gdzie internet potrafi zamigotać, a druga strona SRT przyjmuje.
Jeżeli ktoś ma się odezwać — gość zdalny, drugi prowadzący, ekspert wpięty do studia, ktokolwiek, kto zareaguje na to, co przed chwilą padło — to opóźnienie przestaje być szczegółem technicznym i staje się treścią. Człowiek z sekundowym opóźnieniem brzmi jak człowiek, który się zastanawia. Człowiek z trzysekundowym brzmi jak człowiek, który nie zrozumiał pytania. Tu jedyne sensowne wyjście to WebRTC. Prędzej użyjesz go jako sygnału do wpuszczenia w mikser niż będziesz podawał go do widza.
Praktycznie sprowadza się to do tego, że gościa, który ma OBS-a albo vMiksa i wie, co robi, podłączasz przez RTMP — to jest branżowy standard, więc nikt nie musi szukać dziwnych ustawień. Ale gościa, który ma tylko laptopa i telefon do ciebie, wpuszczasz linkiem w przeglądarce, czyli przez WebRTC, i to nie dlatego, że tak ładniej, tylko dlatego, że on nic nie zainstaluje, a wy musicie ze sobą rozmawiać. Poza tym w RTMP musisz czekać około trzech sekund aż gość Ci odpowie, w SRT możesz ustawić low latency i zejść do sekundy, a WebRTC jest praktycznie instant pod warunkiem, że gość nie jedzie na neostradzie z 98 roku albo co gorsza nie łączy się telefonicznym modemem z początków internetu.
Dwie rzeczy, których nie ma w tabelkach
Pierwsza: RTMP potrafi po sobie nie posprzątać. Kiedy połączenie urywa się nagle — laptop się zawiesza, ktoś wyciąga kabel, łącze pada — serwer po drugiej stronie nie zawsze od razu zauważa, że przestałeś nadawać. Zostaje mu zajęte gniazdo, formalnie zarezerwowane pod twój strumień, i potrafi je trzymać godzinami. Objaw jest taki, że próbujesz wznowić transmisję tym samym kluczem strumienia, a serwer odpowiada, jakby ktoś tam nadal nadawał. Bo dla niego nadal nadaje. Uparte klikanie „start” nic tu nie da — czasem szybciej pomoże zmiana klucza.
Druga: SRT bywa blokowany przez sieci, w których pracujesz. Korporacyjne, hotelowe i konferencyjne firewalle nie lubią ruchu, którego nie rozpoznają, a SRT jest dla nich egzotyką. RTMP przechodzi, bo jest w internecie od zawsze i nikt go już nie sprawdza — mniej więcej z tego samego powodu, dla którego w niektórych urzędach nadal działa faks. Nie dlatego, że jest dobry.
Przy okazji ciekawostka, z wieloma telewizjami musisz się umówić na konkretne okienko czasowe, nawet jak masz link i klucz to nie podasz sygnału bo często czynnie z niego korzystają. Raz miałem sytuację, że miałem podać sygnał dla telewizji po SRT, ale opóźnił im się program i dopiero na 5 minut przed wejściem na żywo zwolnili kanał.
WebRTC dopiero się rozpycha i to jest do przewidzenia
Dzisiaj WebRTC spotkasz głównie tam, gdzie ludzie ze sobą rozmawiają: w przeglądarce, w narzędziach do wpuszczania gości, w studiach działających z poziomu strony. Na duże platformy raczej jeszcze nim nie wjedziesz — one od lat stoją na RTMP i dopiero zaczynają się rozglądać. Zanim postawisz na tym event, sprawdź to po drugiej stronie, a nie w tekście w internecie, łącznie z tym.
Ale kierunek widać gołym okiem. Jedyny prawdziwy argument za czekaniem dwudziestu sekund zawsze brzmiał: „łącza są kiepskie, więc trzeba mieć zapas”. Łącza przestają być kiepskie. Światłowód jest w kolejnych blokach, komórka w plenerze wyciąga rzeczy, o których dziesięć lat temu nikt by nie pomyślał, starlinkiem możesz nadać sygnał nawet ze wsi gdzie wrony zawracają a psy dupami szczekają, a jak zapas przestaje być potrzebny, to zostaje samo opóźnienie — czyli koszt bez korzyści.
Więc jeżeli za dwa czy trzy lata okaże się, że rozmawiamy na żywo z widzem bez tego głupiego zawieszenia, to nie stanie się dlatego, że ktoś wymyślił coś nowego. Stanie się dlatego, że stare rozwiązanie przestało mieć czego bronić. Na razie jednak w dziewięciu przypadkach na dziesięć klikniesz RTMP — bo zazwyczaj nie masz innego wyboru.
Tematy: streaming · warsztat