Krótka odpowiedź: użyj RTMP, gdy koder ma publikować do punktu ingestu, WebRTC, gdy interakcja widza i ścieżka czasu rzeczywistego to uzasadniają, oraz HLS, gdy wybraną ścieżką jest dostarczanie odbiorcom przez HTTP. Usługa na żywo często używa więcej niż jednego protokołu; ich nazwy opisują różne granice.
Wybieraj od widza wstecz do źródła
| Pytanie | WebRTC | HLS | RTMP |
|---|---|---|---|
| Główny odbiornik | Interaktywny partner przeglądarki/aplikacji lub usługa mediów | Odtwarzacz obsługujący HTTP i ścieżka dostarczania | Serwer ingestu lub punkt końcowy platformy |
| Model transportu/dostarczania | Sesja mediów w czasie rzeczywistym negocjowana dla partnerów | Lista odtwarzania oraz segmenty mediów pobierane przez HTTP | Trwała sesja publikacji TCP |
| Rola przeglądarki | Zaprojektowany dla API mediów czasu rzeczywistego w przeglądarce | Dostarczany przez ścieżkę odtwarzacza; obsługa platform zależy od środowiska | Nie jest natywnym odtwarzaniem we współczesnej przeglądarce |
| Kontrola kodeka | Potwierdź obsługę przez przeglądarkę, usługę i negocjację | Potwierdź zgodność odtwarzacza, pakowania i wariantu | Potwierdź zgodność kodera i punktu ingestu |
| Kontrola sieci | Warunki sygnalizowania, ICE/STUN/TURN i zapory | Zachowanie originu, cache/CDN i żądań odtwarzacza | Osiągalność przypisanego hosta i portu ingestu |
| Pasuje, gdy | Interakcja jest częścią wymagania produktu | Dostarczanie odbiorcom jest zadaniem | Koder ma przekazać kanał odbiornikowi ingestu |
Co testować najpierw
| Wybór procesu | Punkt końcowy do testu | Pierwsza kontrola odbioru |
|---|---|---|
| Interaktywna kontrybucja lub odbiorcy: WebRTC | Skonfigurowany punkt końcowy widza/sesji WebRTC | Sygnalizowanie i łączność ICE/TURN, potem audio/wideo programu |
| Szerokie odtwarzanie w przeglądarce: HLS | https://example.invalid/live/master.m3u8 | Pobranie manifestu i zamierzony wariant odtwarzacza |
| Ingest kodera/platformy: RTMP | rtmp://example.invalid/app plus przypisany klucz | Stan nadawcy, potem jawnie wybrane wyjście HLS lub WebRTC |
To formy punktów końcowych, a nie adresy udostępniane przez Callaba. Dla bazowych modeli dostarczania zobacz W3C WebRTC, IETF HLS oraz specyfikację RTMP.
Szybka decyzja: wybierz protokół według zadania
Dla interaktywnej kontrybucji lub uczestnictwa odbiorców przetestuj sygnalizowanie WebRTC i ICE/TURN przed wyborem. Dla szerokiego odtwarzania w przeglądarce przetestuj manifest HLS i odtwarzacz. Dla ingestu z kodera na platformę przetestuj RTMP w przypisanym punkcie końcowym, a następnie wybierz i przetestuj wyjście HLS lub WebRTC.
Jeśli pytanie brzmi „jak widzowie odbierają program w przeglądarce?”, zacznij od WebRTC lub HLS oraz ich wymagań dotyczących odtwarzacza, dostępu i dostarczania. Jeśli brzmi „jak ten koder publikuje na platformę?”, zacznij od kontraktu ingestu RTMP platformy. RTMP może zasilić późniejszy etap HLS lub WebRTC, ale sam go nie tworzy.
Częste fałszywe porównania
WebRTC vs HLS
To decyzja o dostarczaniu. WebRTC potrzebuje ścieżki sesji czasu rzeczywistego; HLS potrzebuje dostarczania listy odtwarzania/segmentów i zgodnego odtwarzacza. Przetestuj dokładny punkt końcowy odbiorców i jego model dostępu, a nie tylko kanał źródłowy.
RTMP vs WebRTC
Protokoły te zwykle zajmują różne końce procesu: RTMP jako ingest kodera, WebRTC jako interaktywne dostarczanie. Most jest skonfigurowaną funkcją serwera mediów lub usługi z własnymi kodekami, sygnalizowaniem i operacjami — nie właściwością żadnego URL.
HLS vs RTMP
HLS pakuje media do dostarczania przez HTTP; RTMP publikuje media do odbiornika ingestu. Widz, który nie może otworzyć URL RTMP, potrzebuje wybranej ścieżki wyjściowej HLS lub WebRTC, a nie innej przeglądarki.
Mieszany proces
Koder programu może publikować RTMP do kontrolowanego zasobu ingestu. Operator potwierdza aktywność źródła, a następnie konfiguruje osobne wyjście dostarczania odbiorcom — HLS dla procesu odtwarzacza HTTP lub WebRTC dla ścieżki interakcji. Waliduj każdą granicę kolejno: koder do ingestu, utworzenie przetwarzania/wyjścia, a potem rzeczywisty URL widza.
Lista kontroli protokołów przed produkcją
- Zapisz kodek źródła, liczbę klatek, audio i ograniczenia docelowego odbiornika.
- Przypisz właściciela poświadczeniom publikacji, sygnalizowaniu/dostępowi i testom odtwarzacza.
- Użyj prywatnej widowni próbnej i przetestuj odzyskiwanie po zatrzymaniu źródła.
- Wiąż twierdzenia o bezpośrednim odtwarzaniu w przeglądarce ze skonfigurowanym wyjściem, nigdy z URL źródła RTMP.
Wybierz następny krok
Dla ingestu kodera oraz dostępu nadawcy/odbiornika zobacz RTMP Server. URL publikacji RTMP może używać tej samej aplikacji i nazwy strumienia co URL odbiornika, ale nadawca i odbiornik wciąż mają różne role. Dla wyjścia przeglądarkowego zacznij od wskazówek Web Player; dla intencji pakowania zobacz RTMP do HLS. Jeśli procesem jest kontrybucja SRT zamiast publikacji RTMP, właściwym właścicielem jest SRT Server.
