W ciągu ostatnich kilku lat w branży dużo mówiło się o transmisji strumieniowej w czasie rzeczywistym. Dostawcy próbowali twierdzić, że opóźnienia między transmisją a transmisją strumieniową, skutkujące przysłowiowym „słyszysz, jak ktoś wiwatuje, zanim zobaczysz bramkę”, wymagają podejścia o bardzo niskim opóźnieniu. Ile razy słyszałem, jak operatorzy transmisji strumieniowej dostarczający treści sportowe na żywo mówili: „Tak, opóźnienie jest ważne, ale niezawodność, skalowalność i jakość są o wiele ważniejsze”.
Kiedy zakłady sportowe online została otwarta w USA, ci sami dostawcy wiwatowali: „Tak, streaming w czasie rzeczywistym będzie ogromny”. Niestety, zakłady nie cieszą się dużym powodzeniem. W rzeczywistości można argumentować, że rozwinęło się ono tak samo jak interaktywne przesyłanie strumieniowe. Według Statisty przewiduje się, że wskaźnik penetracji wśród użytkowników zakładów sportowych online, który obecnie wynosi 1,9 % w 2024 r., do 2028 r. wzrośnie jedynie do 2,3 %.
Przypadki użycia charakteryzujące się bardzo niskimi opóźnieniami są istotne. Prawdę mówiąc, odbyłem na ten temat wiele rozmów ze streamerami sportowymi i niektórzy mówili mi, że zrównali swoje architektury dostarczania: częściowo HTTP (dla większości odbiorców) i częściowo WebRTC (lub inne podejście w czasie rzeczywistym dla części odbiorców, która chce grać lub wchodzić w interakcję). Problem z WebRTC zawsze jednak miał charakter skali. Infrastruktura WebRTC jest droższa. Dostarczanie jest droższe, a do obsługi przesyłania strumieniowego z bardzo niskimi opóźnieniami przy dużej współbieżności potrzeba znacznie więcej serwerów WebRTC niż serwerów HTTP. Ale koszt to nie jedyny problem. WebRTC po prostu nie ma takich samych możliwości funkcjonalnych jak przesyłanie strumieniowe HTTP.
W przypadku dużych operatorów transmisji sportowych WebRTC zapewnia prawdziwą szansę. Jednak ci sami operatorzy, którzy wydają miliardy na prawa licencyjne, nie mogą sobie pozwolić na zamianę możliwości strumieniowego przesyłania treści w czasie rzeczywistym na podstawowe funkcje OTT, takie jak SSAI i DRM.
Ponieważ WebRTC jest droższym protokołem do dostarczania, operatorzy przesyłania strumieniowego nadal będą musieli dokonać trudnego wyboru, kto otrzyma strumień WebRTC, a kto otrzyma treść HTTP.