Strumieniowe protokoły wideo: Which to Use for Professional Broadcasting

Gdy zaczniesz pracę ze strumieniowaniem na żywo, zauważysz obfitość akronimów, które służą wielu różnym celom. Jest RTMP, HLS, HDS i wiele innych.

Wiele z tych akronimów odnosi się do różnych protokołów strumieniowania wideo. Zasadniczo, protokoły to procesy techniczne, które ułatwiają przesyłanie danych z jednego programu do drugiego. W przypadku przesyłania strumieniowego oznacza to transfer plików wideo do i z kodera, hosta strumieniowego i w końcu do odtwarzacza wideo, w którym widzowie oglądają strumień.

Dzisiaj zamierzamy zidentyfikować niektóre z najczęstszych protokołów strumieniowych, z którymi można się spotkać, co robią i kiedy należy ich używać. W celu zapewnienia odpowiedniego tła, aby pomóc Ci zrozumieć, wyjaśnimy również związek pomiędzy kodekiem a formatem kontenera.

Czy jesteś gotowy, aby zanurzyć się w protokołach streamingu na żywo?

Proszę zauważyć, że ten post został zaktualizowany, aby odzwierciedlić najnowsze osiągnięcia w protokołach streamingu wideo na listopad 2020.

Table of Contents

• What is a Video Streaming Protocol?
• Streaming Protocol vs. Codecs vs. Container Format
• Wspólne protokoły strumieniowania wideo
• Protokoły wideo do profesjonalnej transmisji strumieniowej na żywo
• Zakończenie

Co to jest protokół strumieniowania wideo?

Zanim przejdziemy dalej, przyjrzyjmy się nieco bliżej definicji protokołu strumieniowego przesyłania wideo. Większość cyfrowych materiałów wideo jest przeznaczona do dwóch rzeczy: przechowywania i odtwarzania. Prowadzi to do dwóch głównych kwestii, a mianowicie małego rozmiaru pliku i uniwersalnego odtwarzania.

Większość plików wideo nie jest przeznaczona do strumieniowania, co oznacza, że strumieniowanie wideo wymaga najpierw przekonwertowania go na plik nadający się do strumieniowania. Wiąże się to z podzieleniem go na małe fragmenty. Kawałki te są następnie dostarczane sekwencyjnie i odtwarzane w miarę ich odbierania. Jeśli przesyłasz strumieniowo wideo na żywo, źródłowy materiał wideo pochodzi prosto z kamery. W przeciwnym razie pochodzi z pliku dla treści VOD.

Protokół strumieniowego przesyłania wideo to standardowa metoda dostarczania służąca do dzielenia wideo na kawałki, wysyłania ich do widza i ponownego składania.

Protokoły strumieniowego przesyłania wideo mogą być znacznie bardziej złożone. Wiele z nich to na przykład protokoły „adaptive bitrate”. Ta technologia dostarczy najlepszą jakość, którą widz może obsługiwać w danym momencie.

Niektóre protokoły koncentrują się na zmniejszeniu opóźnienia, czyli opóźnienia pomiędzy wydarzeniem dziejącym się w rzeczywistości a tym, kiedy jest ono odtwarzane na ekranie widza. Niektóre protokoły działają tylko na określonych systemach, a inne skupiają się na zarządzaniu prawami cyfrowymi (DRM).

Podążając za niektórymi konkretnymi protokołami, przedstawimy te i inne cechy w perspektywie.

Protokół strumieniowy vs. Kodek vs. Format kontenera

Wśród innych, jedno z powszechnych źródeł nieporozumień w dziedzinie strumieniowego przesyłania wideo dotyczy różnicy między protokołem a kodekiem.

Praktycznie rzecz ujmując, termin „kodek” odnosi się do technologii kompresji wideo. Logicznie rzecz biorąc, różne kodeki strumieniowe są używane do różnych celów. Na przykład Apple ProRes jest często używany do edycji wideo, a H.264, najbardziej powszechny kodek wideo, jest szeroko stosowany w wideo online.

Tak jak w przypadku kodeka, termin „format” może być również mylący w kontekście protokołów strumieniowego przesyłania wideo. W wielu przypadkach, format odnosi się po prostu do formatu kontenera pliku wideo. Popularne formaty kontenerów to .mp4, .m4v i .avi.

W istocie, format kontenera funkcjonuje jak „pudełko”, które zazwyczaj zawiera plik wideo, plik audio i metadane. Jednak format kontenera nie jest tak istotnym pojęciem dla streamerów na żywo.

Zróbmy porównanie, aby łatwiej było zrozumieć związek między kodekiem, formatem kontenera i protokołem strumieniowym.

Wyobraźmy sobie, że jesteśmy kupcem i transportujemy odzież luzem (odzież reprezentuje zawartość wideo). Kodek strumieniowy jest odpowiednikiem maszyny, która kompresuje ubrania w pakiet, aby zaoszczędzić miejsce. Format kontenera to wagon, do którego pakowane są te wiązki. Protokół przesyłania strumieniowego jest analogiczny do torów kolejowych, sygnałów i kierowców, którzy dostarczają je do miejsca przeznaczenia.

Jako nadawca, chcesz, aby zawartość wideo na żywo funkcjonowała w zgodzie z kodekiem, formatem kontenera i protokołem strumieniowym.

Jest również ważne, aby zauważyć, że większość protokołów strumieniowych obsługuje tylko niektóre kodeki. Więcej na ten temat dowiemy się później.

Wspólne protokoły strumieniowania wideo

Teraz, gdy masz już lepsze pojęcie o celu protokołów strumieniowania wideo, zacznijmy nasze porównanie najbardziej powszechnych protokołów strumieniowania wideo.

W tym porównaniu, będziemy również oferować przypadki użycia dla każdego protokołu, kiedy tylko będzie to możliwe.

Real-Time Messaging Protocol (RTMP)

Pierwszy jest protokół weteranów: RTMP czyli Real-time messaging protocol. Protokół RTMP został opracowany przez firmę Macromedia w początkach streamingu i jest nadal szeroko stosowany.

Dzisiaj RTMP jest używany głównie do pobierania strumieni na żywo za pomocą kodera z obsługą RTMP. Mówiąc wprost, kiedy skonfigurujesz swój koder tak, aby wysyłał strumień wideo do platformy hostingowej, wideo dotrze do CDN za pomocą protokołu RTMP. Ta zawartość ostatecznie dociera do odbiorcy końcowego w innym protokole, zwykle w protokole strumieniowym HLS.

RTMP jest rzadko używany jako protokół strumieniowania wideo skierowany do widza, tak jak to było kiedyś. Dzieje się tak, ponieważ jest on zależny od wtyczki Flash, która od lat boryka się z problemami bezpieczeństwa i szybko staje się przestarzała.

Kto powinien używać RTMP?

RTMP jest protokołem strumieniowym, który zapewnia strumienie o bardzo niskich opóźnieniach. Jednakże, ponieważ wymaga on wtyczki Flash do odtwarzania, nie zalecamy jego stosowania. Ponownie, wyjątkiem jest pobieranie strumienia. Do tego celu RTMP jest nadal jedną z najlepszych opcji. Jest solidny i prawie powszechnie obsługiwany.

Real-Time Streaming Protocol (RTSP)

Mniej znany protokół strumieniowania wideo, Real-Time Streaming Protocol (RTSP) został po raz pierwszy opublikowany w 1998 roku. RTSP został opracowany do sterowania serwerami mediów strumieniowych w systemach rozrywki i komunikacji, a konkretnie.

W 2016 roku, zaktualizowany RTSP 2.0 stał się dostępny. Ogólnie rzecz biorąc, jest on znany jako protokół strumieniowania wideo do ustanawiania i kontrolowania sesji multimedialnych między punktami końcowymi.

RTSP jest pod pewnymi względami podobny do protokołu HTTP Live Streaming (HLS), który omówimy poniżej. Jednakże, przesyłanie danych strumieniowych na żywo nie jest tym, co RTSP osiąga samodzielnie. Zamiast tego, serwery RTSP często współpracują z protokołami RTP (Real-Time Transport Protocol) i RTCP (Real-Time Control Protocol) w celu dostarczania strumieni multimedialnych.

Kto powinien używać RTSP?

RTSP został zaprojektowany do obsługi strumieniowania o niskich opóźnieniach i jest dobrym wyborem dla przypadków użycia strumieniowania, takich jak transmisje z kamer IP (np. kamer bezpieczeństwa), urządzeń IoT (np. dron sterowany laptopem) i mobilnych zestawów SDK.

Jedną istotną wadą jest jednak ograniczona obsługa RTSP przez przeglądarki.

RTMP vs RTSP

RTMP i RTSP są protokołami strumieniowymi, co oznacza, że są to zestawy reguł, które rządzą tym, jak dane przemieszczają się z jednego systemu komunikacji do drugiego. Jeśli dane wideo, które próbujesz wysłać do swoich widzów to samochód, to protokół strumieniowy jest drogą, którą pokonuje samochód, aby dostać się z jednego miejsca do drugiego.

Zalety używania RTMP:

• Niskie opóźnienia: Niska latencja pozwala Twojemu strumieniowi wideo na żywo utrzymać stabilne połączenie i kanał wideo dla widzów, nawet jeśli połączenie internetowe jest zawodne. Zapewnia to Twoim widzom mniej „lagów” podczas oglądania filmów z chwiejnym połączeniem internetowym, pozwalając im szybko wznowić strumień, gdy ich połączenie internetowe się ustabilizuje.
• Możliwość dostosowania: Adaptowalny kanał oznacza, że Twoi widzowie nie są skazani na oglądanie Twoich kanałów w jednym liniowym kierunku. Możliwość adaptacji pozwala im na pomijanie i przewijanie części kanału lub dołączanie do strumienia na żywo po jego rozpoczęciu.
• Elastyczność: RTMP pozwala na integrację różnych typów mediów w jeden spójny pakiet, płynnie łącząc audio, wideo i tekst. Dodatkowo, możesz mieć wiele odmian kanałów medialnych, takich jak strumienie audio MP3 i AAC lub strumienie wideo MP4, FLV i F4V.

Cons of Using RTMP:

• Nie jest obsługiwany przez HTML5: RTMP jest obsługiwany przez odtwarzacze Flash, format, który jest na dobrej drodze do przestarzałości. Odtwarzacze HTML5 szybko stają się nowoczesnym standardem, ale RTMP nie może być odtwarzany przez odtwarzacze HTML5 bez konwertera, takiego jak HLS.
• Problemy z przepustowością: Strumienie RTMP mogą być szczególnie podatne na problemy związane z niską przepustowością. Może to powodować częste, frustrujące przerwy w strumieniach, które psują wrażenia widzom.
• Niezgodność z HTTP: Nie można bezpośrednio przesyłać strumienia RTMP przez połączenie HTTP. Aby używać strumienia RTMP na swojej stronie internetowej, musisz połączyć się ze specjalnym serwerem, takim jak Flash Media Server, i użyć sieci dostarczania treści (CDN) innej firmy.

Zalety używania RTSP:

• Strumieniowanie segmentowe: Zamiast zmuszać widzów do pobrania całego filmu przed jego obejrzeniem, strumień RTSP pozwala im oglądać Twoje treści przed zakończeniem pobierania.
• Dostosowanie: Wykorzystując inne protokoły, takie jak Transmission Control Protocol (TCP) i User Datagram Protocol (UDP), możesz tworzyć własne aplikacje do strumieniowego przesyłania wideo.

Cons of using RTSP:

• Mniej popularny: W porównaniu z innymi protokołami strumieniowania mediów, RTSP jest znacznie mniej popularny. Większość odtwarzaczy wideo i serwisów streamingowych nie obsługuje strumieniowania RTSP, co utrudnia nadawanie strumienia w przeglądarce. Aby transmitować strumień RTSP, musisz użyć oddzielnej usługi strumieniowania na żywo RTSP.
• Niezgodność z HTTP: Podobnie jak RTMP, nie można bezpośrednio przesyłać strumienia RTSP przez HTTP. Z tego powodu nie ma łatwego, prostego sposobu na strumieniowanie RTSP w przeglądarce internetowej, ponieważ RTSP jest przeznaczony bardziej do strumieniowania wideo w sieciach prywatnych, takich jak systemy bezpieczeństwa w firmie. Jednakże, możesz strumieniować RTSP używając dodatkowego oprogramowania, które jest osadzone na twojej stronie internetowej.

Wybór pomiędzy protokołami strumieniowymi RTMP i RTSP zależy w dużej mierze od indywidualnych potrzeb biznesowych użytkownika oraz od tego, ile dodatkowych kroków jest skłonny podjąć, aby umożliwić odtwarzanie treści na swojej stronie internetowej.

Dynamic Adaptive Streaming over HTTP (MPEG-DASH): przyszłościowy protokół

Na przeciwległym końcu spektrum mamy MPEG-DASH, jeden z najnowszych protokołów na scenie. Chociaż nie jest on jeszcze szeroko stosowany, protokół ten ma kilka dużych zalet.

Po pierwsze, obsługuje transmisję strumieniową z adaptacyjną przepływnością. Oznacza to, że widzowie zawsze otrzymają najlepszą jakość wideo, jaką może obsłużyć ich aktualne łącze internetowe. Prędkość ta zwykle zmienia się z sekundy na sekundę, a system DASH jest w stanie dotrzymać jej kroku.

MPEG-DASH rozwiązuje pewne długotrwałe problemy techniczne związane z dostarczaniem i kompresją. Kolejną zaletą jest to, że MPEG-DASH jest „codec agnostic”, co oznacza, że może być używany z prawie każdym formatem kodowania. Obsługuje również Encrypted Media Extensions (EME) i Media Source Extension (MSE), które są opartymi na standardach interfejsami API dla opartego na przeglądarce zarządzania prawami cyfrowymi (DRM).

Kto powinien używać MPEG-DASH?

Obecnie MPEG-DASH jest używany tylko przez ułamek profesjonalnych nadawców w porównaniu do HLS. Wierzymy jednak, że w przyszłości będzie to standardowa technologia.

Powód, dla którego ten protokół nie jest jeszcze niesamowicie popularny może być przypisany do kompatybilności (np. Apple Safari i urządzenia iOS nie obsługują go) i innych powiązanych kwestii.

Microsoft Smooth Streaming (MSS)

Następnym jest protokół Microsoft’s Smooth Streaming (MSS). Pierwotnie wprowadzony w 2008 roku, MSS był integralną częścią tegorocznych Letnich Igrzysk Olimpijskich. Jednak jego popularność spadła, z wyjątkiem deweloperów skupionych na Microsofcie i tych pracujących w ekosystemie Xbox.

Smooth Streaming obsługuje adaptacyjne strumieniowanie bitrate i zawiera kilka solidnych narzędzi do DRM. Ogólnie rzecz biorąc, jest to hybrydowa metoda dostarczania mediów, która działa jak strumieniowanie, ale jest oparta na pobieraniu progresywnym HTTP.

Kto powinien używać Smooth Streaming?

Jeśli Twoją główną grupą docelową nie są użytkownicy Xboxa lub nie planujesz tworzyć aplikacji dla Windows, nie zalecamy używania MSS jako głównego protokołu strumieniowania wideo.

HTTP Dynamic Streaming (HDS)

Wejściem firmy Adobe do świata protokołów strumieniowych jest HTTP Dynamic Streaming (HDS), następca RTMP. Podobnie jak RTMP, HDS jest protokołem strumieniowym opartym na technologii flash. Jednakże, dodaje on również wsparcie dla adaptacyjnego przesyłania strumieniowego i ma reputację protokołu wysokiej jakości.

HDS jest również jednym z lepszych protokołów, jeśli chodzi o opóźnienia. Z drugiej strony, opóźnienie nie jest tak niskie jak w przypadku RTMP z powodu fragmentacji i procesu szyfrowania, co czyni go mniej popularnym dla streamingu sportu i innych wydarzeń, gdzie sekundy mają znaczenie.

Kto powinien używać HDS?

Ogólnie nie zalecamy używania HDS. W ostatnich latach obsługa Flash stała się zbyt słaba, aby jakikolwiek nadawca mógł polegać na tej technologii w celu dotarcia do swoich odbiorców. Krótko mówiąc, budowanie wideo internetowego w oparciu o odtwarzacz Flash jest dziś po prostu złym wyborem.

HTTP Live Streaming (HLS)

Ostatnim protokołem strumieniowego przesyłania wideo, który omówimy, jest HTTP Live Streaming lub HLS. Apple pierwotnie udostępniło ten protokół w 2009 roku, aby umożliwić usunięcie Flasha z iPhone’ów. Od tego czasu HLS stał się najczęściej używanym protokołem strumieniowania.

Jest kilka powodów, dla których tak się dzieje. Po pierwsze, przeglądarki stacjonarne, inteligentne telewizory oraz urządzenia mobilne z systemami Android i iOS obsługują HLS. Odtwarzacze wideo HTML5 również natywnie obsługują HLS, w porównaniu do HDS i RTMP.

To pozwala na dotarcie z przekazem do jak największej liczby widzów, czyniąc HLS najbezpieczniejszym obecnie protokołem do skalowania przekazu na żywo do dużych odbiorców. Na przykład, można użyć tego protokołu do strumieniowania wideo na żywo na swojej stronie internetowej za pomocą prostego kodu embed.

Jeśli chodzi o funkcje, standard HLS obsługuje również strumieniowanie z adaptacyjnym bitrate, dynamicznie dostarczając najlepszą możliwą jakość wideo w każdym momencie. Dzięki ostatnim aktualizacjom, standard ten obsługuje teraz najnowszy i najlepszy kodek H.265, który zapewnia dwukrotnie wyższą jakość wideo przy tym samym rozmiarze pliku co H.264.

Obecnie jedynym minusem HLS jest to, że opóźnienie może być stosunkowo wysokie. Istnieją jednak metody na zmniejszenie opóźnień HLS.

Kto powinien używać HLS?

HLS jest obecnie najczęściej używanym protokołem, ponieważ jest solidny i efektywny. Na przykład, wiemy, że niewielu widzów powróci na stronę podczas strumienia, jeśli doświadczą awarii wideo. Użycie powszechnie kompatybilnego, adaptacyjnego protokołu, takiego jak HLS, zapewni widzom najlepsze możliwe wrażenia.

Chcielibyśmy również wspomnieć, że HLS jest obecnie domyślnym protokołem strumieniowania używanym w Dacast.

Protokoły wideo do profesjonalnej transmisji na żywo

Podsumowując, obecnie istnieje wiele protokołów strumieniowania wideo i wiele z nich może być używanych do strumieniowania wideo na żywo.

Jak wspomnieliśmy powyżej, wszystkie omawiane tu protokoły – RTMP, RTSP, MPEG-DASH, MSS, HDS i HLS – mają konkretne zastosowania dla konkretnych nadawców. Jednakże, biorąc wszystko pod uwagę, HLS wychodzi na prowadzenie, szczególnie pod względem kompatybilności kodeków, kompatybilności ze wszystkimi urządzeniami, natywnej obsługi odtwarzacza wideo HTML5 i możliwości strumieniowania z adaptacyjnym bitrate.

Nasze zalecenie jest proste: na razie prawie wszyscy nadawcy powinni trzymać się protokołu strumieniowania wideo HLS.

Oczywiście, niektórzy użytkownicy mogą znaleźć inne protokoły lepsze dla swoich potrzeb. Jednak bez względu na to, czy chcesz strumieniować wideo na żywo na swojej stronie internetowej, prowadzić transmisje na żywo z wydarzeń sportowych, czy też transmitować na żywo profesjonalne wydarzenia i spotkania, HLS jest generalnie najlepszym rozwiązaniem.

Pamiętaj, że MPEG-DASH jest opcją, która dopiero się rozwija. Zwróć uwagę na rosnące przyjęcie tego protokołu strumieniowego w najbliższej przyszłości.

Wnioski

Pomimo, że protokoły strumieniowe i związane z nimi technologie są nieco skomplikowane, są one całkowicie przystępne, gdy zostaną podzielone na mniejsze, strawne pomysły.

Mamy nadzieję, że ten post pomógł wyjaśnić cel protokołów strumieniowych wideo i związek między protokołem strumieniowym wideo, kodekiem i formatem kontenera. Wierzymy, że jesteś przygotowany do wyboru i używania odpowiedniego protokołu dla swoich potrzeb.

Aby przetestować strumieniowanie HLS na platformie Dacast, zapraszamy do zarejestrowania się na 30-dniowy bezpłatny okres próbny. W ten sposób można zapoznać się z funkcjami przed podjęciem zobowiązania/

ZACZNIJ ZA DARMO