<h1>
Media Source Extension
</h1>

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.


<h2>
HTTP Live Streaming
</h2>

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.
<h3>
Architektura
</h3>

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".

<h2>
Dynamic Adaptive Streaming over HTTP
</h2>

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

<h1>
HTML5 Video Element
</h1>

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

<h1>
Real-time Transport Protocol
</h1>

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.

<h1>
Real Time Streaming Protocol
</h1>

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.

<h1>
Web Real Time Communication
</h1>

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)

<h1>
Źródła
</h1>

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