---
# System prepended metadata

title: "\n Media Source Extension\n "

---

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

![](https://i.imgur.com/BjwC5Az.png)


<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
 