Media Source Extension

MSE to specyfikacja W3C, umożliwiająca przesyłanie strumieni bajtów do kodeków mediów w przeglądarkach internetowych wspierają audio i video HTML5 za pomocą JavaScriptu.

Przeglądarki wspierające MSE:

• Firefox
• Google Chrome
• Internet Explorer from version 11 on Windows 8.1
• Microsoft Edge since its launch in November 2015
• Opera since 9 June 2015
• Pale Moon from version 27.0, since 22 November 2016
• Safari 8 on OS X

MSE wspiera wszystko co można demultipleksować za pomocą JavaScriptu i wysłać do natywnych kodeków przeglądarki. Przeglądarki natywnie nie wspierają DASH i HLS, daltego aby ich użyć potrzebujemy odpowiednich bibliotek JavaScript np video.js.

MSE może również odczytywać pofragmentowane MP4 lecz niestety nie odczytuje manifestów.

Dlatego należy użyć aplikacji odtwarzacza do pobrania i parsowania manifestu, pobrania fragmentów wideo, a następnie przekazania ich przeglądarce, aby odtworzyły.

Twitch używa HLS ze strumieniami transportowymi, ale uruchamia niestandardowe oprogramowanie w przeglądarce, aby przekonwertować je na fragmenty MP4 (Lub strumienie flv w przypadku flasha).
Kiedy widzisz src typu blob, jest to normalne (nie podzielone na fragmenty) MP4 i jest zupełnie inne.

Safari jest wyjątkiem, może odtwarzać HLS za pomocą manifestu m3u8 jako źródła.

HTTP Live Streaming

HLS to protkół przesyłania strumieniowego bitów oparty na protokole HTTP. Jest wspierany przez większość współczesnych przeglądarek, w tym Google Chrome (natywnie w Androidzie/iOS, w pozostałych przypadkach za pomocą MSE). Jest to najpopularniejszy format przesyłania strumieniowego. Standard obejmuje również szyfrowanie danych i bezpieczną dystrybucję kluczy przy użyciu HTTPS.

Architektura

Zasada działania jest podobna jak w przypadku DASH, ponieważ działa dzieląc główny strumień na sekwencję małych plików pobrań opartych na HTTP. Każde pobranie ładuje mały fragment pliku wideo. Lista dostępnych strumieni jest wysyłana do przeglądarki w postaci pliku manifestu w formacie .m3u8 który jest rozszerzoną listą odtwarzania. Dzięki temu, że dane przesyłane są przez HTTP, strumień przechodzi przez standardową zaporę lub serwer proxy, który przepuszcza ruch internetowy - co jest jego ogromną zaletą w porównaniu do protokołów opartych na UDP, takich jak RTP. Dużą zaletą rozwiązania jest jego skalowalność - serwer generuje kilka wariantów jakości strumieni, co sprawia, że odtwarzacz może dostosować jakość wideo do danej przepustowości sieci. Dzieki takiemu rozwiązaniu video dostarczane jest płynnie.

Architektura obejmuje:

• serwer
  Jego zadaniem jest przygotowanie wideo do dystrybucji. W trakcie pobierania, wideo jest kodowane i segmentowane na fragmenty o różnej długości przechowywane jako pliki .ts. Tworzony jest również plik indeksu zawierający listę odwołań do pofragmentowanych plików, ma on format .m3u8.
• dystrybutor
  Jest to standardowy serwer WWW, którego zadaniem jest przyjmowanie żądań od klientów i dostarczanie zasobów takich jak plik .m3u8 i fragmenty pliku wideo w formacie .ts
• klient
  Najczęściej przeglądarka internetowa, która wysyła żądanie odtworzenia strumienia a następnie po odpowiedz dystrybutora pobiera plik indeksu i na jego podstawie składa sekwencję pofragmentowanych plików w video "na żywo".

Dynamic Adaptive Streaming over HTTP

To projekt open-source'owy stworzony jako alternatywa dla komerycjnego HLS. Zasada działania obu standardów jest podobna. Analogicznie - video przesyłane jest z zastosowaniem protokołu HTTP. Używa pliku manifestu w formacie XML jako listy odtwarzania plików MP4. Obsługuje również technologię Adaptive bitrate streaming, która pozwala na dostosowanie jakości video do przepustowości łącza odbiorcy, co zapewnia płynność odtwarzania. Dużą zaletą w porównaniu do HLS jest fakt, że DASH jest niezależny od kodeka

HTML5 Video Element

Wprowadzony został do standardu w HTML5. Służy do odtwarzania plików video bez konieczności instalacji dodatkowych wtyczek do przeglądarki.

Real-time Transport Protocol

RTP - protokół transportu w czasie rzeczywistym działający w warstwie aplikacji. Zapewnia kompleksowe funkcje transportu sieciowego odpowiednie dla aplikacji przesyłających dane w czasie rzeczywistym, takie jak dane audio, wideo lub dane symulacyjne, za pośrednictwem usług sieciowych multiemisji lub emisji pojedynczej. Z każdym strumieniem danych skojarzony jest oddzielny kanał, port. RTP nie zajmuje się rezerwacją zasobów i nie gwarantuje jakości usług dla usług w czasie rzeczywistym. RTP jest zaprojektowany tak, aby był niezależny od podstawowych warstw transportu i sieci. Protokół obsługuje użycie translatorów i mikserów na poziomie RTP. Protokół ten został zdefiniowany w dokumencie RFC 1889 a następnie w RFC 3550 jako Internet Standard.

Protokół RTP najczęściej używa UDP jako protokołu warstwy transportowej.Do opisu sesji RTP używa się protokołu SDP (RFC 4566) - umożliwia to negocjacje i ustanowienie połączenia. RTP nie gwarantuje QoS. Żeby je zagwarantować, jest on używany razem z innymi protokołami jak RTSP, SIP, H.323, RSVP, które służą do ustalenia połączenia, zanim dane będą mogły być przesłane za pomocą RTP. RTSP łączy w sobie koncepcję RTP i SDP, przenosząc je do następnego kroku dzięki dodaniu kontroli wykrywania i odtwarzania strumienia.

Real Time Streaming Protocol

Real Time Streaming Protocol (RTSP) to protokół na poziomie aplikacji, zapewniający rozszerzalną strukturę umożliwiającą kontrolowane dostarczanie na żądanie danych, takich jak audio i wideo, w czasie rzeczywistym. Źródła danych mogą obejmować zarówno transmisje danych na żywo, jak i przechowywane klipy. Ten protokół ma na celu kontrolowanie wielu sesji dostarczania danych, zapewnia środki do wybierania kanałów dostarczania, takich jak UDP, multiemisyjne UDP i TCP, oraz zapewnia środki do wybierania mechanizmów dostarczania opartych na RTP. W przypadku RTSP pojęcie połączenia nie występuje. Zamiast tego przyjmuje się, że serwer RTSP utrzymuje sesję oznaczoną odpowiednim ID, która łączy grupy strumieni mediów i ich stanów. Podczas jej trwania użytkownik może otwierać i zamykać wiele połączeń transportowych z serwerem. Strumienie sterowane przez RTSP mogą używać RTP do transportu swoich danych, jednocześnie operacje RTSP pozostają niezależne id mechanizmów transportowych używanych do transmisji danych.

Głównymi zadaniami RTSP są: zgłaszanie żadania transmisji i pozyskiwanie danych z serwera multimediów. Protokół pracuje w kilku trybach - unicast, multicast, multicast z wybraniem adresu. W pierwszym przypadku media transmitowane są bezpośrednio do źródła, które wysłało żądanie, z wykorzystaniem portu wybranego przez klienta. Jeśli chodzi o multicast serwer nadaje poprzez adres rozgłoszeniowy oraz port docelowy - jest to typowe dla usług Wideo na życzenie (VOD). Klienci łączą się z serwerem RTSP i uzyskują opis SDP strumieni multimediów dostępnych z serwera. Po wykonaniu tej czynności klient ma teraz pełny opis SDP wszystkich strumieni, dzięki czemu może używać RTP do łączenia.

Web Real Time Communication

WebRTC to technologia, która umożliwia aplikacjom i stronom internetowym przechwytywanie i opcjonalnie strumieniowanie multimediów audio i / lub wideo, a także wymianę dowolnych danych między przeglądarkami bez konieczności pośrednictwa. Zestaw standardów obejmujący WebRTC umożliwia udostępnianie danych i przeprowadzanie telekonferencji peer-to-peer, bez konieczności instalowania przez użytkownika wtyczek lub innego oprogramowania innych firm.
WebRTC składa się z kilku powiązanych ze sobą interfejsów API i protokołów, które współpracują ze sobą, aby to osiągnąć. WebRTC wspiera transmisję przy pomocy RTP (SRTP)

Źródła

https://en.wikipedia.org/wiki/HTTP_Live_Streaming
https://www.w3.org/TR/media-source/
https://tools.ietf.org/html/rfc3550
https://www.ietf.org/rfc/rfc2326.txt
https://developer.apple.com/documentation/http_live_streaming
https://www.wowza.com/blog/hls-streaming-protocol